DevOps最近成了热词,望文生义,你也能猜个八九不离十,它就是在说"研发团队"与"运维团队"之间的那点事儿。那么,到底什么是"DevOps"呢?
WikiPedia上说:"DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。"这恰好体现了精益管理中的客户价值原则,即:以客户的观点来确定企业从设计到生产交付的全部过程,实现客户需求的最大满足。我们也可以把DevOps看作是一种能力,在缺乏这种能力的组织中,开发与运维之间存在着信息"鸿沟"。
如何获得这种能力呢?关键有两点:一是全局观:要从软件交付的全局出发,加强各角色之前的合作;二是自动化:人机交互就意味着手工操作,应选择那些支持脚本化、无需人机交互界面的强大管理工具,比如各种受版本控制的script,以及类似于Nagios这样的基础设施监控工具,类似于Puppet、Chef这样的基础设施配置管理工具。
有人评论说:"针对目前国内情况,DevOps还是很遥远。也许只有行业顶尖的公司,或者新成立的公司会有这样的尝试。大多数的企业还未开始进行敏捷的推进,传统的重重阻碍会使敏捷的推进进程遥遥无期。" DevOps真的离我们有那么远吗?DevOps应该从哪里开始呢?
让我们看一看百度某产品线在半年内的变化吧。首先要说明两个百度术语。"提测"是指某个项目开发完成后,在正式上线前,将其提交给测试组进行测试的活动。对于客户来说,"提测"这个动作本身并不增加什么价值,但也需要花费一定的时间。"上线"是指某个项目验证合格后,将其部署到服务器的过程,其中包括"上线申请"和"实际部署"两个活动。也许在各公司中对这两个活动叫法不同,但在软件生命周期中,"提测"、"上线"这两件事无论花长时间,大家可能都不会感到奇怪。下面两张图是该产品线进行改进之后的对比数据。
从图中不难看出,提测和上线部署的效率已大大提高。象百度这样的互联网企业,产品线多得数不清,几乎每个产品线每周都有新功能部署。仅从这两个数据来看,其收益可想而知。那么,半年前的状况是什么样的呢?
既然DevOps关注于价值交付的全过程,那就让我们看看该产品线常见的交付过程吧。
对于单个项目来说,它大体上是一个典型的瀑布开发过程。首先是需求收集与整理,撰写MRD(Marketing Requirement Document)或总体设计后,进行评审。如果涉及到多模块,每个模块的开发人员会对各自负责的模块进行详细设计,给出大致的开发计划,并商定联调时间点。之后,开发人员会从主干上拉出项目分支,并在该分支上进行开发。当到最后联调点时,几个开发人员才会在将代码合在一起,进行联调。当调通之后,开发人员再申请提测。测试人员接到提测申请单后,进行测试,记录Bug,通知开发人员修复,直致质量达到标准。之后,开发人员会填写上线申请单,经运维人员确认后,运维人员操作进行上线部署工作。如图所示。
开发的复杂性还在于:该产品线有很多并行项目,为了避免互相干扰可能带来的冲突,每个项目启动后都会重新在主干上拉出分支,在上线前才进行合并。如下图所示。
另外,并行项目太多,导致每个开发人员会同时参与多个处于不同阶段的项目。那些周期较长的项目虽然会被分解成多个迭代,但每个迭代内都是同样的开发流程,只是最后仅有一次上线而已。
总而言之,突出的问题表现在:
从精益思想出发,为了尽早交付价值,必须首先找出整个流程中的浪费,并将其消除,从而提高流程效率,让"一个想法从提出到实现"可在最短时间里完成。那么,浪费到底表现在哪里呢?
另外,该产品的一个重要特征是需要不断地尝试调整程序算法策略,以得到最佳的流量效果,而这种调整的频率较高(至少每周一次)。当需要调整策略时,开发人员修改代码后重新进行编译打包,由于产品代码发生变化,所以测试人员仍需要进行大量的回归测试,而运维人员在部署时也需要将对二进制文件包进行整体部署,整个周期比较长。
从上面这些内容中,我们不难发现,流程中更倾向于将问题推迟到后面解决(比如最后集成联调),将工具(平台、邮件、即时通讯)作为协作的基础,而角色间的沟通几乎完全依赖于前一个环节的产物(比如MRD、产品代码、上线步骤)。那么我们使用哪些对策进行优化,达到消除浪费的目的呢?
新的开发流程如下图所示。
分支开发策略变更为Single Branch模式。
通过以上改进措施,让团队的合作方式发生了重大变化,从"碉堡防御"走向了"战线统一"。
原来,各角色仅关注于自己本身的工作,虽然大家都同处于一个项目中,但各自划分了"领地",产品经理就应该将MRD写得清清楚楚,如果开发人员认为不清楚,那就回去再改。开发人员只管按照MRD上的内容进行开发,很少考虑可测性和易测性问题。测试人员只管按照MRD中内容来测试,有问题通过内部工作流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的"交付物"。
现在,各角色都能够共同合作,以项目的最终交付为目标,积极讨论需求,优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。开发人员耐心为产品经理解释技术实现,说明计划安排,测试人员与开发人员共同讨论验收条件,避免遗漏需求。开发人员让运维人员了解架构设计, 细心听取运维人员的建议,进行技术改造,使部署工作更快捷有效。
通过这些活动,大家都认识到原有内部管理平台仅是个公文流转的支撑平台,要想提高工作效率,就要将这种"办公自动化工具"进一步提升为"全面自动化工具",使所有人更关注于端到端的价值,而非各角色之间的分界点。
百度刚刚开始敏捷之旅,还没人谈及"DevOps"运动,虽然还没有什么强大的工具支撑,但基于"提高效率"的朴素思想进行的过程改进也带来了"DevOps"效果。可见,DevOps听上去很神秘,但其实并不难。只要本着精益思想,聚焦于快速交付价值,不断发现并消除浪费,你也一定会有很大收获。