引言
DevOps自从2009年诞生以来，经过多年摸索开始逐步变成一种主流运维模式。网上也有很多关于DevOps的讨论，但大多数都停留在思想层面，真正可落地的方法并不多，本文作者对自身从业经验和唯品会的落地实践加以总结，希望给读者一定的思考和帮助。
?在本文开始之前，需先明确几个概念，后文会用到。
ITIL:一种以流程为基础的运维模式，基本思想是PDCA。
服务：能够独立提供完整的一个或者多个功能模块，这里特指业务研发编写可上线运行的代码。
组件：能够独立部署，但需要和其他组件联合才能提供服务的基本单位。
?本文主要回答两个方面问题：
1，为什么需要DevOps？
2，DevOps如何落地？
?本文建议的阅读者：有一定开发和运维经验的工程师，最好是经历过实际生产困难后面临转型困境的人员。
在回答这个问题之前，我们先了解一下什么是运维模式。所有模式是对待人和事物的态度后得到的方法论，比如我对人性是持悲观的态度，那么我就需要建立流程制度对人加以约束，使他们在做事时尽量减少自己的主观意志，客观去完成所分配的任务。反之，如果我对人性持有乐观态度，那么我可能更多地去激励，让人员发挥主观能动性，形成共同的价值观、行为准则，通过系统方式给予落地。这里需要注意的是：人是很复杂的动物，往往不能单一而论，大多时需要两者结合，合适自己的才是最好的。
在流程约束上，目前做得最好的运维模式是ITIL理论，它通过流程驱动运维落地，同时有很好的落地实践，包括要建设哪些系统都有清晰的注明。我记得我第一次接触ITIL理论时，惊为天人，因为在复杂运维场景下能够抽象出一套完善理论是一件很不容易的事。对于很多初成立的团队，我建议选择这种模式作为伊始。ITIL的优点除了上面易落地外还有以下原因，值得尝试：
●见效快，比如只需要建立一个变更流程，就能立即大幅度提升生产质量。
●运维部门主导，在ITIL模式下的绝大多数系统和流程只需要运维部门实施即可，甚至最关键的CICD，ITIL体系也只关注于最后发布到生产那一块。
●管理落地，流程落地的过程就是管理落地的过程，在这个过程中，管理者可以把自己的经验和方法完整地实践下来，可以最大屏蔽执行者的差异。
ITIL主要关注质量和效率之间的质量，兼顾效率。这句话的理解是，当质量和效率发生冲突时，ITIL会优先保障质量。所以当要求效率优先时，ITIL会比较困难，这也就为DevOps发展提供了空间。当然ITIL本身也有其他问题，比如流程反弹、边际效益等，但由于不是本文重点因此不展开讲，如果想了解可以私信我。
而DevOps模式的本质是对开发、测试及运维角色的分工挑战。如果我们把重心放到最终产出物，即如何快速提供新服务给用户时，就会遇到一个非常大的挑战--开发、测试、运维需要融为一体。让以上三种角色协同其实不是一件容易的事情，因为三方的KPI、行事风格及语言体系并不相同，这就是我们常说的那堵部门墙。
举个生产变更的例子：
?小D：业务研发
?小O：应用运维
他们实施的是DO分离（DO分离也是一个很大的概念，如果以后有空，再单独讲），
?Step1，小D会提交一个变更需求申请，在申请中写明要干什么事情，然后经过小D的上级审批，工单流转到小O；
?Step2，小O收到申请，然后他需要写变更执行步骤，在写的时候，他需要确认一下业务影响，所以他线下找到小D问为什么要这样做;
?Step3，小D解答自己这么做的原因，并且贴出自己的代码，说明在哪里引用;
?Step4，在交流过程中小O发现一个额外步骤，既改完环境变量需要重启应用，而应用重启需要小D发布新的代码，这时他告诉小D，变量更改完，下次你们发代码后生效;
?Step5，几轮后二者达成一致，小O开始做变更，做完后，等待小D验收;
?Step6，小D无法验收，因此要求代码发布日那天，小O要在场，出现问题及时回滚。
这只是生产最平常也是最简单的一个变更场景。在这个场景中有两个问题，其一，二者沟通的信息有效么？或者更进一步说，当变更完成后，这次变更中所交流的所有信息对以后工作有促进么？其二，这一件工作真的需要二者一起完成么？
