运维DevOps体系解析与落地实践

DevOps自从2009年诞生以来，经过多年摸索开始逐步变成一种主流运维模式。网上也有很多关于DevOps的讨论，但大多数都停留在思想层面，真正可落地的方法并不多，本文作者对自身从业经验和唯品会的落地实践加以总结，希望给读者一定的思考和帮助。

在本文开始之前，需先明确几个概念，后文会用到。

• ITIL：一种以流程为基础的运维模式，基本思想是PDCA。
• 服务：能够独立提供完整的一个或者多个功能模块，这里特指业务研发编写可上线运行的代码。
• 组件：能够独立部署，但需要和其他组件联合才能提供服务的基本单位。

本文主要回答两个方面问题：

• 为什么需要DevOps?
• DevOps如何落地?

本文建议的阅读者：有一定开发和运维经验的工程师，最好是经历过实际生产困难后面临转型困境的人员。

为什么需要DevOps?

在回答这个问题之前，我们先了解一下什么是运维模式。所有模式是对待人和事物的态度后得到的方法论，比如我对人性是持悲观的态度，那么我就需要建立流程制度对人加以约束，使他们在做事时尽量减少自己的主观意志，客观去完成所分配的任务。反之，如果我对人性持有乐观态度，那么我可能更多地去激励，让人员发挥主观能动性，形成共同的价值观、行为准则，通过系统方式给予落地。这里需要注意的是：人是很复杂的动物，往往不能单一而论，大多时需要两者结合，合适自己的才是最好的。如果你想和更多DevOps技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

在流程约束上，目前做得最好的运维模式是ITIL理论，它通过流程驱动运维落地，同时有很好的落地实践，包括要建设哪些系统都有清晰的注明。我记得我第一次接触ITIL理论时，惊为天人，因为在复杂运维场景下能够抽象出一套完善理论是一件很不容易的事。对于很多初成立的团队，我建议选择这种模式作为伊始。ITIL的优点除了上面易落地外还有以下原因，值得尝试：

• 见效快，比如只需要建立一个变更流程，就能立即大幅度提升生产质量。
• 运维部门主导，在ITIL模式下的绝大多数系统和流程只需要运维部门实施即可，甚至最关键的CICD，ITIL体系也只关注于最后发布到生产那一块。
• 管理落地，流程落地的过程就是管理落地的过程，在这个过程中，管理者可以把自己的经验和方法完整地实践下来，可以最大屏蔽执行者的差异。

ITIL主要关注质量和效率之间的质量，兼顾效率。这句话的理解是，当质量和效率发生冲突时，ITIL会优先保障质量。所以当要求效率优先时，ITIL会比较困难，这也就为DevOps发展提供了空间。当然ITIL本身也有其他问题，比如流程反弹、边际效益等，但由于不是本文重点因此不展开讲。

而DevOps模式的本质是对开发、测试及运维角色的分工挑战。如果我们把重心放到最终产出物，即如何快速提供新服务给用户时，就会遇到一个非常大的挑战--开发、测试、运维需要融为一体。让以上三种角色协同其实不是一件容易的事情，因为三方的KPI、行事风格及语言体系并不相同，这就是我们常说的那堵部门墙。

举个生产变更的例子：

• 小D：业务研发
• 小O：应用运维

他们实施的是DO分离(DO分离也是一个很大的概念，如果以后有空，再单独讲)，现在小D要做个变更需求，假设增加一个环境变量，用做代码使用，他们实施的过程会是什么样的呢?

• Step1，小D会提交一个变更需求申请，在申请中写明要干什么事情，然后经过小D的上级审批，工单流转到小O;
• Step2，小O收到申请，然后他需要写变更执行步骤，在写的时候，他需要确认一下业务影响，所以他线下找到小D问为什么要这样做;
• Step3，小D解答自己这么做的原因，并且贴出自己的代码，说明在哪里引用;
• Step4，在交流过程中小O发现一个额外步骤，既改完环境变量需要重启应用，而应用重启需要小D发布新的代码，这时他告诉小D，变量更改完，下次你们发代码后生效;
• Step5，几轮后二者达成一致，小O开始做变更，做完后，等待小D验收;
• Step6，小D无法验收，因此要求代码发布日那天，小O要在场，出现问题及时回滚。

这只是生产最平常也是最简单的一个变更场景。在这个场景中有两个问题，其一，二者沟通的信息有效么?或者更进一步说，当变更完成后，这次变更中所交流的所有信息对以后工作有促进么?其二，这一件工作真的需要二者一起完成么?

其实，答案都是否定的，很多在变更过程中的质疑和沟通都是无效的，只不过二者所处的角色导致信息必须对称才能做好一个变更，最后造成效率低下，解决沟通最优的方式不是提升双方技巧，而是舍弃沟通。如果，运维能够提供一个系统或者平台，在上面设置好各种运维场景，开发可以在上面可视化操作，那么则无需沟通，这也是很多人的思路，即系统化是落地DevOps的途径。

在这里，我复述一遍：DevOps的本质是系统化，我个人比较认同这个理念。但在实际操作中落地过程并不顺利，那么问题来了，为什么都明白这个道理，但依然做不好DevOps?

DevOps如何落地?

事实上，DevOps的方法论并不清晰，其所有思想都停留在较为抽象的层面，系统化算是很好的一种落地思路，但是很多公司系统化后DevOps之路并不顺利，究其原因，主要是没有找到运维和研发的切入点，导致无法罗列出所有运维和研发的使用场景，最后只能不断打补丁，疲于应对，没法持续改进。CICD是一个很好的切入点，它是刚需，场景明确单一，同时也最大化解决开发痛点，利于推广实施，网上也有很多讨论，所以这个不是本文重点，大家自己去找即可，这里主要讲在生产治理尤其是生产变更场景下的DevOps落地方案。

请大家思考一个问题，在变更场景下，如果我们要找到一个开发和运维都共同关心的事物，那是什么?

不是代码，代码运维并不关心，即使想关心，也是有心无力;不是操作系统，对于大多数研发而言，编写代码需要屏蔽底层差异，如果真的存在这类事物，那么只能是和代码产生直接关系的组件，比如中间件Tomcat、缓存Redis、Mc、数据库Mysql等，实际上绝大多数开发的变更需求也是围绕这些组件实施的。这个很好理解，因为代码层次变更开发可以自己掌控，只有这些直接关联的组件需要运维配合实施，因此做好这些组件的变更场景系统，则能满足百分之九十以上的开发变更需求。

唯品会实践

下面一部分将结合唯品会的实践，来阐述如何去做。

如何基于组件实施DevOps?

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!