花钱的年华

江南白衣,公众号:春天的旁边

站在岸上看DEVOPS

| Filed under 工作 技术

今年项目要试水(X)AAS,尝试运维自己的产品,便离不开这几年最热的单词—DEVOPS。趁还在岸上,理解下DEVOPS对开发人员来说意味着什么。

因为没有实战,也就纸上谈兵一下,真正有经验的人, @连城404:为了分摊黑锅,运维发明了devops和full stack。

What is DEVOPS ?

十年前,敏捷出现,以反瀑布流程的方式模糊了需求、架构、开发、测试之间的界限,但对整个软件价值链的最后一环,交付与运维并没有太多的强调,造成一个有趣的现象是,产品以三周为迭代进行开发并交付给客户,但只充当与客户演示并收集反馈的媒介,而客户仍然会有自己独立的上线周期。

十年后,越来越多的互联网站与手机应用,需要频繁而持续的发布,每次发布需要部署到大量的机器集群上,需要不中断和破坏当前服务,在发布前能提供本次发布质量的证明,在发布后对系统有实时的监控,支持错误转移、服务降级,支持快速定位和修复故障。

显然,只靠传统运维人员的知识技能集(操作系统、网络、Shell脚本编写) 以及开发人员编写的的产品管理手册已不足以满足上述的需求了。好在,有敏捷的先例,解决方法是现成的——把开发拖下水吧:

1. 人员上,运维人员要更懂产品的架构与内在,而不只是那份管理员手册。开发人员要懂实际的运维,从实际部署、上线流程,到故障的定位与解决。当然,最重要是打通两个部门间的隔阂。

2. 产品特性上,运维所需的功能甚至运维的基础设施,成为了产品非功能性需求的重要一部分。

3. 流程上,产品交付与运维,接入整个软件生产周期构成一个完整的环。
 

What should developer do?

现在大家最关心的问题来了,DEVOPS的大旗下,开发人员到底要参与多少运维?

这幅图,又是零到一百之间的选择,各个组织根据自己的人员、技术,文化,找到自己最合适的那个平衡点。

理论上,开发人员在DEVOPS中可以有两种的参与:

一,为运维而开发。

比如,在代码中加入Metrics收集的代码,向Graphite吐出服务的调用次数与延时,通常是与运维协作的第一步——运维可以在CPU,内存占用与应用日志之外,不那么黑盒的看待应用了。

又比如,要和运维商量着,在代码端需要做些什么,才能实现监控,无中断升级,动态节点扩展,故障转移,服务降级,跨机房容灾。这些功能以前可能也是要的,但现在需求的采集更注重实效。甚至,运维的一些基础设施,也可以由开发代劳了。

又比如,环境与流程的统一,原来只在简版的集成测试环境上跑完功能测试就完事的开发闭环,现在需要考虑至少延伸到一台从服务器配置到数据库部署模型等都贴近生产环境的Staging服务器,又比如测试环境的安装部署,也会用和运维一样的基于Ansible 或 Saltstack。

二,开发直接参与运维。

也是最存在争议的地方,比如系统的上线升级,日常的运维操作,故障的即时修复。

开发人员参与运维,可以吃自己的狗粮,可以更深切的了解运维功能的需求,开发人员的故障修复更快,但是——

程序员是不是应该做更有创造性的事情?程序员做运维会不会感到厌烦?社会化分工还是不是一个无需争辩的现代社会真理?

其实类似的争论已发生过一次,在开发与测试的分工上。起码在我司,专门的测试人员仍然有不可动摇的作用,而开发人员,则承担了从持续的单元测试和功能测试,最后到手工的性能测试与稳定性测试,总体80%以上的测试工作量,很自然的合作。

所以,还是没有绝对,还是各个组织自己去通过不断的尝试,找到自己最合适的那个平衡点。

 

Reference

发表评论

您的电子邮箱不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>