“做好DevOps即是用好一种工具”的认知误区

任何变革都需要时间，DevOps亦然。在经过数年的蛰伏期之后，DevOps终于成为了业界聚焦点；不过，从知其然到知其所以然，再到最终完美实现DevOps，依然前路漫漫。

在普元信息高级软件架构师胡帅看来：DevOps 概念很大，几乎可以成为软件工程的代名词；但可惜的是，目前存在着“做好DevOps即是用好一种工具”的认知误区。近日，国内著名技术社区InfoQ对胡帅进行了采访，他认为DevOps是在理念层面对开发运维一体化进行倡导：好工具的运用诚然会对工作产生积极影响，但是更重要的是它会改变人的做事思维和人与人之间的协作方式，也只有这样才能发挥DevOps的最终好处——打通软件生命周期的数据链路。

DevOps从本质来讲只是倡导开发运维一体化的理念（MindSet）。这个理念的提出是为了解决很多企业面临的转型挑战，也就是将业务数字化，并且缩短数字化业务上线的周期，快速试错，快速占领市场。

DevOps并没有改变固有的软件生命周期：需求，设计，开发，测试，交付。但伴随着基础设施，软件设计方法等的改变，软件开发的思路，或者方式产生了比较大的变化。

那么DevOps带来哪些改变呢？

• 以Viktor倡导的DevOps 2.0举例，以PaaS平台为基础设施，用微服务的架构进行应用开发正当其时。当然这本书是以工具（Toolkit）的角度来讲DevOps，如果再加上敏捷的心法，就更加有操作性了。
• 另外在以前，软件过程实践都会详细定义每个阶段的参与者、工件等。而敏捷并没有这么做，一个原因是敏捷会将不同阶段打碎后揉在一起。但认真思考，我们发现这种大而化之的方式需要用例如Workitem等更快速的定义工作，并且建立工件之间的联系，贯穿软件生产交付过程始终。

这不仅仅是运维和开发的结合。从顶层视角看，这是业务和生产的紧密结合。以前从业务和开发是脱节的。想要查看需求的实现进度，需要大量的人工汇报，更别提运营了。而现在以一个微服务实现一个特性的粒度来看，可以从需求，开发，测试，部署一直追溯到这个特性运营情况。这也是DevOps成为数字化企业基因的原因，业务和生产实现了完美的结合。

从敏捷实践的角度来讲，你会发现开发组织中参与者好似生物体中的神经元，大家各司其职，自成一体，接受反馈，并向外主动反馈。团队的自组织使得工作更加自然，能产生更大的效能。由以前的项目经理驱动，改为自我驱动的协作方式。每个人都可以给相关的团队以及责任人提需求，大家有机的协调在一起。

谈到DevOps适用性的问题，其实DevOps并不存在不适用的问题，只有做的好不好的问题。试问哪个组织不想让开发和业务结合的更紧密呢？我想这个问题更多的是如何选择软件过程的问题。用目前比较流行也饱受争议的敏捷为例，我们知道敏捷的两大精髓是“自组织文化，和集体责任感”。所以在实施敏捷之前我们必须考虑以下几点：

• 需要严格设计和详细文档的项目：敏捷利用逐步细化的方式来拥抱不断变化的需求，也就是说敏捷不太适合需要一开始就将所有的需求分析，系统设计做的非常详细的项目。
• 自组织文化：如果一个组织长期采用命令式的管理方式，一线团队的开发人员没有决定权，那敏捷是无法实行的。一个团队中缺乏自主意识，自组织的文化很难形成。
• 快速试错：用软件模拟试错的代价相对较小，但是用硬件试错的代价比较大。所以是否能控制敏捷所带来的成本风险，也是企业需要考虑的问题。

然而一些以前很传统的企业，比如说银行，汽车制造等瀑布模型的忠实粉丝们也正在逐步进行敏捷转型，总之，没有什么是万灵药，要因地制宜的进行软件过程，设计方法，以及工具平台的选择。

这里给大家分享一个改造案例，公司A存在的问题：

1. 软件交付周期很长，一年只能交付一个大版本，以及一个小版本。

2. 人员分工不明确，一个决定的做出往往需要很多人参与。

3. 用大量的时间挖掘需求。在真正的开发期，会发现用户的需求仍在改变。需求分析的时间被浪费。

4. 采用瀑布模式开发，在不同时期，某些角色的人员会无事可做。

5. 在软件交付过程中，开发与运维人员需要花费大量的时间去协调产品安装，配置中出现的问题。

改造步骤：

第一阶段：

行动：为了实行DevOps，公司A为不同的生命周期购置了支撑工具，涵盖JIRA, PagerDuty，GitHubEnterprise，Jenkins等。公司针对每个工具都进行了专门培训，专人管理。

结果：大家开始将不同的工具应用到软件生产的各个环节中，统一的工具塑造了统一的工作方式，创造了工作契约。统一工具的运用确实对软件交付带来了一些积极的改变。

第二阶段：

问题：各个工具仍旧是割裂的，代码管理和任务管理无法协调。开发人员声明已经完成的工作，测试人员却发现无法找到构建来完成测试。运维人员和开发人员只是利用了同一种工具，而没有做到工作产物的共享。

行动：公司A开始关注工具所提供的能力而不是功能，将不同工具的关键交付物连接起来，形成可追溯的管理。开发人员发现提交的代码可以产生可用构建后才声明功能完成。并且用同一个任务来追溯开发到上线的工作。尤在开发与运维结合方面，运维人员可以利用开发人员已经实现的部署设计，进行发布演练，确保软件平滑交付。

第三阶段：

问题：有了好的工具，但是公司A发现虽然开发到运维的路通了，但是软件质量却难以保证，甚至在产品发布日期邻近的时候，仍有很多未完成的任务，测试团队顶着很大的压力，最终还是会发生不少测试逃逸，产品的技术欠债比较大。

行动：在开发阶段采取分支开发的方法，功能实现并且通过一定的代码测试之后才能合并到主干。开发人员负责部分的测试任务，由于对产品比较熟悉，所以加快了测试效率。专门的测试团队会承担例如性能测试等更加专业的测试任务。有节奏的控制软件开发的进度，在软件发布的稳定期严格控制代码提交，每个新功能的开发负责人会和运维人员一起进行发布演练，DevOps的好处终于开始见效。

第四阶段：

问题：团队前期在需求分析中会花费大量的时间进行文档编写，但开发开始后，开发人员会花费大量的时间对文档进行理解，并且用户对需求的调整最终导致文档失去维护的意义；大家的主动性不强，需要领导的督促才能进行工作安排。

行动：公司A意识到他们之前只是采用看似敏捷的方式，实际瀑布的方式做开发。比如说项目经理变成了Scrum主管，周会变成了每天的站会。在进行调研分析后，公司A决定开始进行敏捷实践。分阶段的按照重要程度以及优先级进行需求规划，周期性的互动使得客户在第一时间可以看到期望的需求被逐步实现，双方都避免最后一科的意外。开发人员发现可以对自己负责的任务有话语权之后，大大激发了积极性，大家开始主动的从Backlog中寻找重要的任务去实现。

其实从以上的例子可以看出，一个好工具的运用会对工作产生积极的影响，但是更核心的是人做事思维，以及人与人之间的协作方式才会体现DevOps的好处，我想从这点大家可以看到为什么DevOps是一种Mindset。

怎么看待微服务、容器对DevOps的重要性呢？其实并不是说DevOps就一定要以敏捷的软件过程开发过程来驱动微服务开发，并且以容器为物理交付单位，运行在PaaS平台上。而是他们结合在一起形成了一个敏捷化的企业软件开发体系，为企业的业务敏捷提供了开发保障。

• 微服务只是一种设计思路，或者说他给出了如何用正确的方法来进行SOA的实施（SOAdone right）。理论上来讲他的确和DevOps没什么关系，但是从如何实践DevOps的角度来讲，微服务是非常有意义的。此外，随着诸如Spring Cloud以及微软Fabric等SDK的完善，微服务开发模式也逐步完善，实现了概念的落地。
• Docker可谓是一种敏捷化的虚拟化技术（较之虚拟机而言）。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案，所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度，这恰好解决了粒度小，数量多的微服务所带来的运维难题。再加上K8S，Swarm等容器云的支持，docker容器已经形成了事实上的标准。

• 如何利用这个强大的运行环境帮助企业敏捷，推进业务数字化，并且加快业务的投产？ DevOps为上面所说的开发模式提供了软件生产线。

所以总结的来讲，企业业务敏捷是DevOps发展的直接推动力，容器云，以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。

对于团队的拆分，这个问题真的要结合产品规模来看。团队的拆分有很多办法，贝索斯说的two pizza team，是建议一个团队中的人尽可能少，不要超过两个Pizza能吃饱的规模。用敏捷实践来讲，可以分为多个特性团队，以及维护团队，不同的团队各司其职，合理分工。在我以前的实践中，三个人可以做一个Feature，来交付一个月迭代的工作量。

当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。

因为理论上的微服务的设计对现有的团队组织结构，以及工程师设计能力都带来了一定的挑战。有些组织按照DDD（领域驱动的设计）的方式去实践微服务，会发现以前一个应用的复杂度变得很高，对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是，大家宣称做微服务（MicroService）的时候，实际上做的是迷你服务（MiniService）。迷你服务的粒度较之微服务的粒度更粗一些，关注度由一个域Domain，变成了能力。一个迷你服务提供一种能力，这种能力的提供也许是跨越多个域的。

• 最好的方法是以一个团队能承担的任务划定微服务的界限比较好，这样以来，不论是任务管理，代码构建，产品部署都会比较好做。
• 更关注服务的能力，这样也会减少因为跨域而带来的复杂事物处理。

我认为DevOps概念对市场的教育工作已经完成了，并且它宣传在国内有点泛滥的趋势，甚至一些以前做项目管理工具的厂商也宣传他们在做DevOps。究其原因在于DevOps的概念太大，几乎可以成为软件工程的代名词。

至于落地的痛点，我觉得有以下几个：

1.  DevOps对于组织来讲是一个系统工程化的投入，在贯彻的过程中，需要一个组织建立标准，统一纪律，而这个过程往往需要组织中的强力部门自始至终的贯彻执行。

2.  DevOps对组织现存的管理方式，或者人员知识结构多少带来了一些挑战。

3.  认为购置了工具就是DevOps，却忽略了工具产物之间的联系。

4.  认为有了全生命周期的工具就是DevOps，忽略了软件过程方法的运用，所以很多组织停留在用旧的方法使用新的工具上。

开启DevOps工具和文化缺一不可。DevOps的最高目标是让组织内的人都具有相同的工作理念，最终形成一种工作文化。而有些倡导者谈到如何去培养这种文化就显得有点空谈了。我认为在形成DevOps文化的过程中，敏捷实践必不可少。过去的敏捷实践更多的是在开发阶段，而现在DevOps的理念下，其实可以很顺畅的将部署阶段的事情也纳入敏捷实践中。让合适的人去做合适的事。当然团队文化的改变需要一个过程。有本说中说文化的改变很难，还是从行为的改变开始吧。我认为以敏捷方法为核心配合以下三个方面来开启DevOps。

• 看板：以任务的状态为核心，管理在制品的生产情况。任务是自组织团队的工作契约。
• 基线：以工件的版本为核心，选取合格的交付物。比如说开发团队决定哪个代码提交版本，或者编译的构建版本为最终交付的版本。度量指导基线的产生。
• 流水线：以生命周期的阶段为核心，控制基线交付物的投产。比如说一个合格的代码基线目前处于编译态，还是部署态。自动化工具围绕管道互相集成。

其实工具和文化最终的落实还是要靠人的提高，特别是通过上一段举出的例子。

DevOps会重新塑造IT组织的研发系统，从工具到文化，再到方法。因此参与这个生态系统的所有人都应该关注。

• 从开发的角度看：开发人员会变得更加业务化，有更多的机会和客户交流。开发人员将从以前对代码负责，转向编译构建负责，对测试负责，甚至对部署物负责。敏捷可以让需求足够的小，这样就可以让一个开发人员变得全生命周期化了。
• 从运维的角度看：其实运维的前景是有些悲观了，至少运维的规模要缩减很多。原因有三。首先，自动化部署工具的发展，使得部署工作提前了，以前碎片化的脚本，被更加规范化的部署设计代替，用设计驱动脚本生成，这都是自动化的。其次，基础环境的改善使得开发环境和生产环境的差异性极大缩小了，企业完全可以制造一个和生产环境一样的预发环境，来保证交付的成功率。容器技术的不可变配置也保证了同样的镜像在不同的环境中不会出现太大的差异。最后，运维工作相对开发工作来讲，可以自动化，甚至运用人工智能的空间都比较大。我们已经看到百度已经开始AIOps。

国内很多开发组织对于产品规划和开发设计把控很严格。相反，对于开发过程管理不够。不能认为使用了某个工具，就万事大吉地实现了DevOps，这样只能带来更多的问题。

DevOps可以帮助企业的开发和业务紧密结合，加快数字化业务上线的时间，从而快速试错、快速占领市场。但是，速度快了并不一定可以确保质量。DevOps是一把双刃剑：就好比有了好的厨房，并不意味着一定能做出一桌好的饭菜。关注点还是应该放到如何提高厨师技能方面来。

如何做才能避免DevOps所带来的负面问题并把控好风险？

所谓的工程化，用标准和自动化来规避人员能力差异所带来的风险，并且提高单个参与者的效能。工程化的重要途径就是软件度量，在文章开篇胡帅就阐明：DevOps带来一个实质变化就是数据链路的形成。如何能利用好这些数据？如何向开发者和管理者提供决策支持？这是DevOps未来发展的一个重要方向。