2010年，我曾在IBM供职，开始参与DevOps相关的产品研发与实施工作。今天看来，我也许是国内较早的DevOps践行者。这两年DevOps在国内开花结果的时候，我见到了很多错误转型的乱象。本文中，将为大家分享自己对DevOps行业发展的观察，并向介绍DevOps转型的路途中都有哪些陷阱。希望通过本文，大家能更够拨云见日，真正的使DevOps成为企业生产力增长的助推器。
本文目录： 一、软件工程的发展 二、DevOps转型陷阱 三、DevOps核心实践 四、DevOps生态环境
一、软件工程的发展
1、工具的发展
首先说DevOps并不是一种工具，而是一种理念或者团队文化。为了实现这一种理念，于是就有一系列的软件工程的支持工具(Computer Aid Software Engineering)。说到CASE，就不得不说一说，两个软件巨头：微软和IBM。我们以他们的软件工程之路，来说明行业的发展历程。
早在1997年微软就推出了可视化的开发工具，Visual Studio(VS)，相信写过C或者C++的同学们一定不会对这个工具陌生。接下来.Net框架的诞生，让微软统一了开发平台的架构，整个VisualStudio所支持的C#, VB, C++等可以编译成中间语言，托管在.Net Framework之上运行。可惜那时微软足够有钱，还在走闭门造车的路子。
.Net不仅不跨平台，整个VS的架构也比较封闭，只有商用的软件才会为VS生产插件。与此风格截然不同的IBM，走开放路子的Eclipse在2004年诞生了，Eclipse的诞生渐渐拉开了开源软件对抗企业软件的序幕。
进入2005年左右，软件工具进入协同开发的阶段，微软推出了服务器端TFS (Team Foundation Server)。TFS的推出，使得多个程序员可以方便的进行代码配置管理，任务管理，以及数据分析，构建等工作。这时软件开发工具已经开始和软件过程相结合，将敏捷的思想注入到工程实践中。在IBM一方，Eric Gamma(相信看过GOF设计模式，以及一些列Eclipse书籍的同学们不会对这个名字陌生)等大师将Eclipse中单人持续交付的体验拓展到整个团队，使得整个团队在一个统一过程，同一平台，统一计划中，交互性的完成工作。
Rational Team Concert诞生了，它使得大规模(500人以上)工程化的软件开发与设计变得更加容易。一直到2012年左右，DevOps文化渐渐在市场中盛行起来。其实对于传统软件来讲，做部署并不擅长，所以这两家巨头都不约而同的收购了两个做持续交付软件的公司：In Release和 Urban Code。于是全生命周期的协同开发工具已经完备，DevOps 从概念到落地都有了完整的链路。从两个巨头的软件工程之路可以看到，DevOps的出现是一个渐进的过程。它的内生原因是人们不断追逐软件生产的工程化，产业成本降低以及效率的提升。
过去20年，软件开发工具的发展趋势是不断的将软件生命周期不同阶段的工具整合起来，形成一个大而全的软件生产平台。一个企业采用单一的生命周期工具有时候会受到学习成本，遗留系统，集成壁垒等诸多原因的制约。而微服务化的DevOps开发工具则帮助用户解决这一问题，诸多PaaS平台上的DevOps实践就是以微服务工具链的形式推出。可以说微服务的设计方法与相关的支持工具，和DevOps这种小团队，持续迭代持续交付的理念简直是天作之合。
2、组织的变化
团队组织结构也在这些年发生了微妙的变化。不管是全栈工程师还是流行的NoOps都在说明专业的界限被打破，开发团队由技术向业务转型。
对于很多测试人员来说，这是一个忧伤的话题。很多IT公司的功能测试部门FVT已经被开发人员所取代。取代的基础是用各种自动化软件，做到更好的单元测试，冒烟测试。并且在迭代的后期利用开发人员的闲暇时间来完成手动测试。传统的测试人员需要培养自身承担自动化测试用例，性能测试用例，系统测试等复杂测试工作的能力。
当DevOps相关的平台统一后，开发验证阶段的产品部署架构，部署模式可以无缝切换到生产态。对于实际的生产态部署来说也许就是一个环境的切换，为了确保万无一失，在一个准生产系统之上演练上线工作。因此传统的开发和运维人员之间的界限会越来越模糊，以及云平台对于服务FailOver策略的处理越来越成熟。
今后的运维团队可能非常的轻量级。软件工程的大方向是被经济利益所驱动的，所以DevOps运用之后很多开发人员也许会“被迫”去做更多测试，运维的工作，是不是有点无奈?
3、软件过程的发展
直至今天，瀑布开发模式仍旧是许多组织采纳的方式。不用质疑，瀑布方式在中国有一定的文化基础。但是渐渐的我们意识到严格的瀑布模式往往会造成一定的资源浪费。比如在相同的人员和相同的时间长度下，传统过程交付可能花费大量的时间去完成是一份完整的需求文档，但是留给软件开发的时间少之又少，再加上需求的变化。回头来看需求文档往往已经过时。
类似RUP(Rational Unified Process)的迭代开发模式就是尽可能的早的获得用户的意见，控制风险。它其实是介于敏捷和瀑布之间的一种模型，不如敏捷灵活但是控制性比敏捷更强。RUP的迭代虽然允许需求和开发并行，但是他仍然强调大部分需求内容都应该在主要开发工作之前完成，而不是敏捷中代码就是设计，需求和开发互为彼此，不断完善的方式。显而易见敏捷需求的时间大大减少了，所以后期调整需求的代价较之瀑布和迭代来讲也更低。
XP极限编程甚至不太推崇大家做过度的设计，类似于一个CRUD的功能，程序员有时会不自觉的追求更高的拓展性，搞出了一个框架来。这让我想起来一个很有意思的问题。那就是项目与产品的细微区别。做项目大多是为了追求短期利益，满足客户功能需求为先，良好的拓展性并不是项目的核心需求。不必要的设计会影响接纳需求变化的能力，这和拥抱改变的想法有些不一致。类似在ThoughtWorks这种做敏捷咨询的公司，客户会另外付钱购买代码重构的effort。而产品研发的需求相对固定，并且一个产品要有良好的发展，必须培养一个良好的生态系统，拥抱未来不同的拓展需求。长期来看框架和平台化反而符合产品的利益。所以敏捷中倡导有些原则有时要辩证的看。
敏捷方法在国内还没焐热，大规模敏捷的软件过程已经诞生。然而在很多敏捷大师的眼中，SAFe和Less只不过是穿了马甲的RUP。敏捷不能大规模开展吗?其实不是不能开展，而是如何开展的问题。大家知道敏捷推崇的是小团队文化，类似亚马逊倡导的Two-pizza团队，建议团队规模维持在7人左右。然而动辄几千人的跨国研发组织，如何开展敏捷的确是一个问题，这就是大规模敏捷存在的意义。
二、DevOps转型陷阱
DevOps简单的来翻译就是运维开发一体化。但是究竟如何来一体化，怎么做才能一体化?可能不同人对DevOps有着不同的理解，这取决于大家在哪个场合被什么人安利的。认识的盲点也就造成了实践的误区。
比如说自动化，基础设施即编码，配置管理数据库的应用，看板方法在运维中的应用等等，可以说这一切都是有关DevOps的实践，而又不是DevOps的全部。向DevOps转型的路上有很多坑，我们先从文化转型谈起。
1、文化转型陷阱
很多人好奇敏捷和DevOps是什么关系。敏捷是一种软件开发过程，最初只是在软件开发中推广，很多人提出由开发敏捷转型到运维敏捷，从而到业务敏捷。这个提议毋庸置疑，不管从文化，流程以及工具层面都是很好的延伸。可以说敏捷方法，敏捷工具为DevOps理念提供了很好的理论指导和工具支持。近些年来很多公司逐渐开始进行敏捷实践，比如说项目经理变成了Scrum主管，用户故事替代了以前的需求，开发计划变成了更短的冲刺计划。以前每周一次的组会变成了每天的站会。一开始大家都精神满满，久而久之觉得每天的站会太麻烦。而Scrum主管还是以前那个逼着大家干活儿的项目经理。冲刺使得开发周期变短了，能做的功能也变少了。频繁上线给运维人员带来更大的压力，生产环境的Bug似乎比以前还要多。
“如果不了解团队自治，责任共担，面向交付，那就不了解DevOps文化。”
2、工具转型陷阱
不论是之前的敏捷，还是现在的DevOps，很多人对于CASE工具都有一个误区，觉得用了这个工具，就具有相应的软技能。但是用了一阵子之后才发现完全不是这回事儿。为什么会出现这种假象呢?
我们知道工具仅仅是现实工作中的一部分，如果仅仅是部署了DevOps工具，然而人员和整个工作流程并未改变会出现什么?很可能出现的情况下是，大家用共同的工具进行工作，当然也取得了比之前好一点的效果，但是工具壁垒并没有消除。
“如果CASE工具只是孤岛，那就很难帮助企业培养好的DevOps实践。”
3、DevOps的双刃剑
其实风险本身并不可怕，可怕的是拒绝风险，或者放任风险。大家可能已经看过很多DevOps宣传，觉得实行DevOps之后可以做到万无一失，从开发到交付是分分钟搞定的事情。其实这里有个陷阱。那就是工具可以帮助生产到交付快速进行，但是从另一个角度讲，如果一旦出现问题，错误也可能会很快传递到生产环境中。所以如何快速捕捉问题，解决问题，而不是让问题传递，这才是DevOps要处理的问题。另外尽早的在持续交付的初期发现问题，比如说有价值的缺陷，然后把它作为单元测试的目标去防范，这对于团队来说是一个不断成长的过程。
“精益的侧面是控制风险，所以要小心风险和DevOps流程一起传递。”
三、DevOps核心实践
刚才说了很多DevOps转型中的陷阱，也就是说一不小心就会栽到坑里，觉得DevOps就是那样了，做着挺别扭，更没带来什么好处。要知道DevOps实际上是一种面向软件交付的理念。文化转型真的挺难，到底该怎么做呢?我们从三个维度讲述DevOps的核心实践。
1、自治的小型化团队
这点对于很多公司，特别是目前国内的诸多公司来讲也许很难做到。组织的自治意味着控制力的减弱。控制力的减弱加上人类天生的惰性将导致项目的失败。这可能是团队转型中存在的共同问题。实际上自治并不是说缺乏管理，而是说对目标做出正确的期望，对结果做出合理评价。中间的过程通过一系列的检查点做出指导和纠正。其余的工作交给团队去协调完成。
首先敏捷实践中将用户故事，任务等明确责任人，这是非常好的做法。明确了责任，大家才能向目标迈进。而另一个责任共担的好办法是让每个人参与团队计划的制定，大家帮助任务的负责人共同估算出故事点。这样不仅会培养团队成员的责任感，并且最终估算的结果会比项目经理自己做出的决策更加准确。在项目执行的时候，看板等工具的运用使团队中每个参与者的工作都具有相同的可见性。以看板中待办项以及任务状态确定每天站会的内容。而不是架构师汇报技术难点，项目经理汇报开发状态，大多数人被忽略的情况。
不超过10人的小团队被很多企业证明是一个良好的实践。可以让对的人去做擅长的事，如果团队过大很多人无法承担合适自己的角色也是一种浪费。另外随着持续交付的演进，产品总有新的需求，也有旧的问题。如何合理分配人员从而做到一石二鸟?一些组织开始将团队分为若干个特性团队和维护团队。这样能带来以下好处：
- 每个特性团队都有一个架构师，同时也是Scrum主管。由于人数小所以很容易做到工作进度与工作量的管理。
- 特性团队和维护团队，互相轮岗。在维护团队中，成员可以接触客户，新成员可以通过修复Bug熟悉产品，对产品足够成熟后再轮岗到特性团队。
- 不同的小团队甚至可以不用在一个地方。
- 从DevOps的角度，一个大的产品团队就可以完成项目开发到上线的整个交付工作。
2、可控的全程追溯工具
用一句之前流行的话来说，那就是有了这么多高大上的工具之后，还是做不好DevOps。如何正确的使用DevOps工具呢?核心的概念其实就是让我们在工具上所做的事情在不同的生命周期时可以做到全链路的可追溯，因此我们给出以下实践：
- 从需求出发，驱动任务执行。
- 任务和代码生产相结合，进行追溯。
- 以任务为单位进行持续集成。
- 以需求为单位进行持续交付。
- 以质量为纲，进行系统验收。
- 运维规范化。
- 随时随地的沟通。
- 持续监控，持续改进。
参照上面的实践，我们来举个例子。开篇我们讲了两个业界著名的DevOps支持平台，他们是紧耦合DevOps工具。随着开源软件越来越多，功能越来越强大，甚至某些已经超过了商业软件的能力。因此越来越多的公司都会基于本公司原有的开源工具之上构建DevOps环境。我们尽量的选取了公有云和私有云中都有的工具版本进行说明。
通过上面的实践，就可以将一个DevOps平台搭建起来了。根据用户的需要可以在私有云和公有云的不同选择不同的版本进行平台建设。只有将这些核心工件集成起来才能形成有效的可追溯链路。
|
源工具 |
目标工具 |
核心工件 |
说明 |
|
ZenHub |
GitHub |
TaskID, CommitID |
通过任务可以看到相关的代码提交。 |
|
GitHub |
Jenkins |
CommitID, BuildID |
哪些提交被哪些构建包括，一个构建包括哪些实际的需求。 |
|
Jenkins |
Swarm |
BuildID, InstanceID |
一个环境上部署的是哪些新的功能。 |
|
Swarm |
SauceLabs |
InstanceID, TestCaseID |
一个环境上的部署实例经过了哪些测试，以及测试的结果。 |
|
ITOP |
所有工具 |
IT资源信息 |
用CMDB进行核心资源的统一管理 |
|
MatterMost |
所有工具 |
团队协作 |
|
|
oneAlert |
所有工具 |
各种事件消息 |
实时监控预警 |
这种集成方式给运维带来的改变可能要多于传统的研发，因为传统的运维在方法论，工具，规范程度等方面还远不及开发，比如说：
- 与很多成熟的开发流程脱节，以及生产环境的相对隔离造成了运维的黑账本(碎片化的脚本)。
- 环境部署后，使用者和管理者的信息不同步造成了很多僵尸系统。
近些年来，基础设施既编码(IaC)以及配置管理数据库(CMDB)的应用实际上就是为了解决上面问题。既然运维实际采用一系列的脚本来部署和管理系统，那么就应该把这些脚本和开发代码一样统一化管理，甚至纳入。而CMDB的作用就是将运维的工作成果和企业的其他IT资产统一管理，消除那些僵尸系统。
3、实时的度量驱动
软件开发过程中充满了各种各样不确定的因素，有时一个小情况的出现就会成大程度影响软件产品的按时交付。对于中高层管理者来讲，只能通过重复的人工周报月报来获取信息。然而不及时，且掺杂人工数据的报告讲给决策支持带来很大的误导。DevOps就是要将数据链路打通，为管理者提供实时，准确的生命周期数据。使管理者在风险到来之前有效的对其管控。
可能在传统的印象中度量不就是一堆报表吗?其实这里有个很大的误区，那就是度量的方法更多的是通过数据看趋势，事先为管理决策作出支持，而不是事后分析。比如说项目经理在看到缺陷打开不断呈现上升趋势就应该去寻找问题，进行干预。Scrum主管在看到任务周转时间要长于原先的预估时间，那就要评估原先的冲刺计划是否能达成。实施度量正是切合敏捷的拥抱变化的理念，帮助项目的参与者尽早的发现问题，在需要的时刻做出干预。有关于度量更多的信息，请参看我以往的微课堂记录。
4、三者融合的最佳实践
用什么方法能将三者融合起来呢?我们发现使用Kanban(看板)Baseline(基线)和Pipeline(管道)这三种方法可以将任务管理，版本控制，过程管理紧密的联系在一起。
- 看板：以任务的状态为核心，管理在制品的生产情况。任务是自组织团队的工作契约。
- 基线：以工件的版本为核心，选取合格的交付物。比如说开发团队决定哪个代码提交版本，或者编译的构建版本为最终交付的版本。度量指导基线的产生。
- 管道：以生命周期阶段为核心，控制基线交付物的投产。比如说一个合格的代码基线目前处于编译态，还是部署态。自动化工具围绕管道互相集成。
那什么又是将这三者融合在一起的方法呢?答案就是工作项(WorkItem)。它涵盖了需求(长篇故事，特性，用户故事)，开发(任务，缺陷),测试(测试用例，测试计划)等。
- 工作项是看板展示的最小单元，看板的泳道就是工作项的状态。
- 基线是通过需求工作项规划，任务工作项生产，测试工作项验收的最终产物。
- 工作项是生命周期不同交付物的容器，交付物的最终投产通过管道体现。
四、DevOps生态环境
最近这几年可以说IT行业发生了一个质的改变。不论从方法论，还是软件工具以及基础设施都让软件开发这件事与业务结合的越来越紧密。可以说DevOps就是云平台开发运营的指导思想。在人员角色方面，推崇全栈工程师，让开发者更贴近业务。在开发方法方面，而在这个平台之上从开发到运营流转的交付物就是以微服务方法开发的应用。在物理形态方面，以容器的方式交付到生产部门运营。对于使用者来讲，这种业务的最终交付形态可能就是一系列的API接口，或者直接可用的应用。一切都变得平滑起来。
如需成为EAii架构研究院会员加入微信群参与架构设计与讨论直播，享受微课堂PPT抢先下载等权益，请直接回复您的微信号至此公众号。
关于作者：
胡帅
普元信息高级软件架构师，计算机软件与理论硕士。曾供职于IBM中国开发实验室，参与Rational Team Concert, Rational Insight等产品研发，曾经担任著名开源BI产品BIRT社区顾问。为工行，招行，建行，美国通用等大型企业提供DevOps以及BI产品咨询实施服务。在DevOps以及BI方面积累了丰富的研发与实施经验。
