【扯淡篇】DevOps，值得运维拥抱！

原计划是写名字服务相关的一篇文章，但因为周末出去培训，实在没法完成。公司组织大家出去讨论关于协同效率问题，之前在腾讯也讨论过部门墙的问题。随着公司的日益增大，这类问题会一直存在，且一直在解决而不能彻底解决。此时，我从运维的角度来谈DevOps还是比较应景的，它恰好给这个问题提出了一个全新的解决方案。结合之前自己总结的一个DevOps PPT，在这个文章中，我通过我的PPT逐步来谈谈我对DevOps的理解（部分来自于自己的总结，部分来自于之前的读书笔记）：DevOps到底是什么?给运维带来了什么样的改变和影响？

一、DevOps是什么？

1、DevOps的初印象

DevOps在很多人看来就是一个代号，先不管它的到底是什么，但这个代号有一个很大的好处，统一了沟通交流术语，如同之前的敏捷。另外从字面上第一次把DevOps放在一起来看，抛弃了之前的一些概念，比如说运维，甚至更早期的D/O分离等等。

DevOps和Dev/Ops、Dev & Ops是有着一些区别。首先、Dev/Ops、Dev & Ops都强调两个独立的职能角色；其次Dev/Ops用分离的视角来看研发和运维，最典型的后果就是研发只看功能需求，不考虑可运维性，而Dev & Ops在一定程度上两个团队的合作能力是更强了(平行团队)，但是还没有做到真正的跨职能。把DevOps融入到各自的日常活动中，无论是研发、测试和运维都需要面向共同的目标、价值观、思维模式等等。

2、DevOps是一种文化(Culture)

单纯的说是一种文化，非常空洞。文化的表现必须是通过一种运动的形式来表达其内在的价值诉求，就如同文艺复兴和五四新文化运动一样。同样在DevOps领域，也是因为多种运动不断催生的产物，比如说一天10次部署运动、平台及服务运动、持续迭代运动等等，最终达到其文化价值的传递，比如说高质量、高效率的服务交付。从我的角度来说，持续集成、XX(架构、监控)及服务及运维数据化是DevOps的核心，可视化是其最终的呈现。

3、DevOps是一种价值观（ValueSet）

价值观是DevOps需要恪守的准则：

（1）持续优化。任何一个工作都不存在完美的状态，应该持续的推动他，自动化平台的建设如此，数据驱动DevOps更是如此，因时而变。

（2）合作共赢。把彼此的合作放在第一位，完成面向用户的共同价值输出，而非个人所在部门的利益达成。

（3）杜绝浪费。任何停滞都是一种浪费，不作为更是一种浪费。

（4）关注用户。用户的价值为最终的导向，并且让用户的价值反向传导到内部工作流节点上。

4、DevOps是一种思维模式(MindSet)

在早前我写过一篇文章探讨过互联网+和云+之间的关系。我也特意对两者的思维模式做了一个对比。

其实在思维角度来说，这两种思维也有很大的相近之处。互联网思维，雷军的七字诀不做过多的解释。在DevOps的思维层面上来说，我也做了一个总结，大致如下：

第一、精益

精益思想（Lean Thinking）源于20世纪80年代日本丰田发明的精益生产（Lean Manufacturing）方式。丰田的精益制造有14项基本原则，后面有人对其的管理思想进行提炼，总结出精益思想有五项基本原则:

（1）从客户的角度来定义产品价值。价值由客户定义，而非自己定义。

（2）识别价值流。精益思想识别价值流的含义是在价值流中找到那些是真正增值的活动、那些是可以立即去掉的不增值活动。精益思想将所有业务过程中消耗了资源而不增值活动叫做浪费。识别价值流就是发现浪费和消灭浪费。

（3）让价值流流动起来。精益将所有的停滞作为企业的浪费，因此要求创造价值的各个活动（步骤）流动起来，强调的是不间断地“流动”。

（4）拉动式价值创造。按照客户的需求进行生产，设置好对应的投入和产出。

（5）持续改进式到尽善尽美。“通过尽善尽美的价值创造过程为用户提供尽善尽美的价值”。

在很多管理思想上，原理是互通的，PDCA、全面质量管理、六西格玛等等，甚至是所遵循的方法论，DevOps也是如此。

第二、价值

当互联网思维在强调他的用户口碑的时候，而我们的技术服务则强调他对用户的价值输出，从而为产品赢得口碑。价值在上面也提到是用户关注的价值，而不是我们认为的价值。高可用、稳定的服务是质量的根本，质量则是价值的一部分，而不断的满足用户需求的服务才是重中之重，这就让各自的团队有了一个共性的衡量标准。

第三、跨界

其实互联网思维的专注是让你对事情有更深入的理解，才能做到极致。而在DevOps所倡导的思维模式，并不是让你去失去专注，而是在此基础上让你更加跨界。在强调职能分工的企业中，过多的限制在某个岗位上行驶某个职能，不利于事务的整体推动。而运维是那个全局观能力最强的人，恰恰需要这个时候从整个价值链的活动来全局观察，并提出方案。同样，研发和测试也需要不断跨出自己的职责区，去和运维一起优化产品和技术方案。

第四、敏捷

业务要求快，技术则要求敏捷，无论是流程的敏捷，还是服务交付都需要非常敏捷。传统的敏捷观点是要技术如何更好服务业务部门的需求，是Dev和Biz的之间的合作模式，而现今的敏捷则从持续集成、持续交付、持续部署等多个层次对敏捷提出了新的要求，是Dev、Test、Ops甚至是产品部门一部协奏曲。

5、DevOps是一种工具观（ToolSet）

DevOps首先倡导的原则是自动化一切，但数据化同样重要，并且我提出要把他们都可视化呈现出来。自动化是可视化一切价值流的过程，数据化则可视化价值节点的状态。这个在之前的文章【运维的本质---可视化】，有全面的阐述。

二、DevOps的最佳实践

Damon列举了一系列实践与举措，对于这些举措，我也用几个词做了备注。这些实践与举措在那些成功应用了DevOps的组织中已经成为它们日常工作的一部分，如下：

• 去除“完成”这个词，服务是永不停止的，它们一直在运行并应该得到持续关注【持续优化】
• 将运维需求与功能需求一样视为一等公民，使运维方能够及早发现需求影响【合作共赢】
• 将工作流程可视化，使所有人对全局有了解，瓶颈自然显现【可视化】
• 协同匹配价值流，这样才能理解系统全局并发现浪费【价值驱动】
• 将信息流变为产品流，以降低信息传递中的歧义并澄清人员间必须的交流【拒绝浪费】
• 将相关数据组合起来形成有意义的指标，让组织中不同利益相关者都能意识到【数据可视化】
• 通过将变更关联到相应指标并将它们图形化来提升对变更的认知【数据可视化】
• 有目的地妆点办公室墙，使每个人都感觉到自己是整个系统的一分子【工作满意度】
• 去中心化管控，让产品的开发者和运维者就责任达成一致（例如：开发者负责代码的正常运行，运维负责平台的正常运行，诸如此类）【共享责任文化】
• 举行内部小型会议，大家可以在会上就已经完成和可以完成的事项达成一致，会上也鼓励大家就变更发表自己的意见。【共同参与】
• 强制在运维的帮助下对所有开发提交的服务进行部署验证检查，以避免在运维时才出现问题【持续部署】
• 释放你的猴子，这能使你对自己的服务承诺产生巨大的自信【信任】
• 在问题发生时不仅在管内（pipeline flow）流转（要引入更多的变更和工作），而是关注在找到瓶颈发生的真正原因并加以修正【杜绝浪费】
• 保证对客户透明，在出现问题时勇于担当，在问题解决后保持警惕，客户自然有理由心满意足【关注用户】
• 在团队和日常工作流以外建立良好关系，例如通过“Guess the Admin”游戏或与公司内不同的人一起共进午餐【合作与分享】

2013年puppetLabs做了一次DevOps调查，也谈到了最佳实践，汇总如下：

三、DevOps和ITIL对比

DevOps和ITIL有着明显的不同，从这个不同的也也可以看出，DevOps代表着未来，ITIL已经不适用互联网的业务运维模式（传统企业还不敢说）。ITIL应该算是运维第一个阶段的指导思想，但在日益快速变化的互联网运维面前，它已经无法胜任。当然现在有些文章也在表达ITIL的思想和DevOps思想的相同之处，比如说也在强调服务生命周期的管理，最佳实践也是在指导系统平台的建设。但我觉得从本质上来讲，ITIL完全没法覆盖运维的活动，其次没有从价值链的传导过程设计运维实践，比如说持续集成，这些都是其致命的弱点。

四、DevOps的核心技术指标（吞吐率和延时）

从DevOps的最佳实践及自动化要求来看，DevOps本质上就是为了更好地解决组织的吞吐率（Throughout）和延时(Latency)问题！在前面也谈到过，我们可以把所有的运维活动提炼成面向用户的价值流（flow），这些流从技术层面上来说，真的有点类似于我们线上应用系统的一次请求。对于技术请求来说，对其性能的衡量就是吞吐率和延时，那么对于运维服务性能(Ops performance)来说，也可以转换成吞吐率和延时。那么这两个指标具体有代表什么呢？

1、吞吐率

第一、持续集成性能，可以从不同的团队角色出发提炼出不同的指标。

从研发团队来说，每天触发持续构建及单元测试的数量、....；

从测试团队来说，每天回归测试的数量、每天自动化测试的数量、....；

从运维的角度来说，每天持续部署的数量、生成持续反馈报告的数量、....；

第二、其他的变更性能

一个运维人或者团队，一定周期内的运维变更能力，比如说可以支持多少个业务多少个变更能力。不过这个变更能力取决于两个方面能力，一个是工具的自动化能力；另外一个取决于线上服务公共化的能力。前者大家很好理解，后者大家就不好理解了。举个例子，当一个被调用服务需要扩容的时候，此时这个服务被前端服务放在配置文件中还是DNS服务中，这个变更的复杂度完全是不一样的。

所以对一个运维团队来说，在构建自动化平台的同时，也别忘了和研发一起做架构上的优化，提升运维的吞吐能力。

2、延时

第一、持续集成延时

之前提到过把能力不断前置，其实是把服务的延时不断降低，类似技术架构中的cache机制。我们都知道，为了让业务访问数据库更快，就不断的把数据推到离应用程序更近的地方；为了让用户下载更快，我们把文件通过CDN分布到离用户一公里。过往的实践告诉我们，打破原有的思维定势非常必要。在过去的观点中，运维应该是应用环境的第一负责人和执行人，但在持续部署平台完善的情况下，发布工作可以不断往前推置；DNS服务的管理也可以不断的交给应用运维自己去管理，甚至直接开放API供应用程序直接调度修改使用。这些工作都需要相关团队的彼此推进和结合，否则很难实现以上所说的角色转换。前置的最极致表现，就是用户的行为对系统产生影响的时候(高容量)，变更即刻自动化完成。

集中式也必须不断走向分散式，使用去中心化的管理模式。我们都知道中心化能带来良好的管理和控制，但是最大的影响就是效率，多对一的情况下，那个一很容易成为瓶颈。但在无平台的情况下，我不建议这种能力直接往前端推置，不同的人的管理很容易不统一，这个会给后期的统一自动化平台建设带来更大的成本，而在有平台的情况下，把相关的服务能力直接交付给前端。

第二、故障恢复延时

故障恢复越快越好，这就意味着对用户影响更小。但为了达到这个故障恢复延时很小，则需要监控平台、数据平台强大的支持。如果把故障分解成三阶段：发现故障、定位故障、解决故障，则每个步骤依赖的能力是不同的，缩短每一个阶段的延时，是我们日常运维在故障处理这块的工作重点之一。

更高吞吐率、更低延时的运维就是更好的运维，我们须持续不断的推动及优化！

五、DevOps，运维需要做的改变

1、组织的改变

按照以前职能分工的组织结构造成隔离的责任制文化，大家都只关注自己的岗位职责，而不去care其他。但在DevOps的要求之下，运维活动需要经常的跨职能进行，这也要求部门之间需要有一个共享责任的文化氛围去更好的衔接部门之间的关系。当前在国外的一些调查报告中可以看出，已经出现了独立的DevOps部门和DevOps工程师。从组织的角度来说，需要一些DevOps培训，如同组织引入敏捷培训一样。

2、个人的改变

当前每个人要认识到，运维不再是简单的参与维护职责，而是整体事务的推动者和解决者，此时需要利用运维人的全局观去把控整体项目的影响等等。

运维人也需要不断跳出舒适区，去跨界识别风险和提供优化方案；需要让自己变成善于整合资源的人，集中各团队的优势能力，让我们的运维交付更快、服务更稳定。面向问题和面向事务的运维需要往面向用户价值的运维转变！

3、工具观的改变

以前以ITIL为中心的流程系统建设方法论，需要彻底的改变，把持续集成自动化当作第一要务。有了持续集成的平台之后，不断去解决底层（如：操作系统安装）及上层应用调度的自动化，最终形成自底向上的自动化调度平台方案。

其实DevOps不就是那个协同效率的解决方案么？