导言

本次分享是《DevOps　Handbook》的第二部分，DevOps 从哪里入手，可以说这一章在全书中是承前启后的一章，主要想要解决的是我们要做什么的问题。

第一章简单回溯了 DevOps 的发展历史并提纲挈领的介绍了核心的三步工作法，第三章开始会深入每一步工作法并详细介绍里面的优秀实践。

在第二章里主要关注的是企业如何去选择合适的价值流，并在价值流中进行分析改进。同时关注整个企业组织架构的建设，因为企业组织架构和管理制度是领导者发挥卓越领导力的基础。

最后一部分会探讨 Dev 和 Ops 之间融合的实践方法。

上篇分享分四个部分的前两个部分，这篇主要分享后两个部分，第三部分主要关注组织架构，第四部分关注研发和运维能力整合的具体实践。

上半部分回顾：[  /s?__biz=MzI0Njc5ODkxMA==&mid=2247485581&idx=1&sn=139beeccf36cd61ca1cb463943e4b798&chksm=e9b887dcdecf0ecaf76561ec0c12c4d9b10d11cf60ed52c5f957ba0895fe6575b11e9250d565&scene=21#wechat_redirect]如何开始我们的 DevOps 转型之旅？[/url]

2.7、 根据康威定律构建组织和架构

第三部分，根据康威定律构建组织和架构。康威定律从诞生至今已经超过50年历史，随着微服务架构的兴起，对于康威定律的讨论不绝于耳，那么究竟什么是康威定律呢？

康威定律很简单，只有一句话：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

怎么理解这句话，在每个企业发展之初，相信每个人都是十项全能的选手，一个工程师可能研发运维一把抓，所有的事情都在他自己的脑袋里，这样的背景下整个组织的沟通成本是比较低的，效率也比较高。

随着企业规模扩大，为了提升效率，我们会把人员按照专业去细分，同时把知识进行积累，形成规模效应，结果就会形成一个一个的组织。

组织的边界逐步明确，就会导致很多优化是在组织内部，无法形成组织建的有效合作和闭环，导致一些紧偶合和强依赖。

以右上角这个图为例，三个团队，UI 团队、中间层团队和 DBA 团队，这显然是一个按照职能划分的组织结构，这样三个团队设计出来的系统往往是右面所示，会分三层去设计系统架构。

随着微服务理念的兴起，系统需要做拆分和解耦，通过系统调用或者接口定义的方式完成自服务或者自运维，这就要求组织会根据这样一种变化去进行调整，调整的基础就是要建立自组织、自交付的团队，为这个团队提供完整的支持，包括一些平台服务的通用平台，达到的目标是自组织团队可以独立完成价值交付、独立运维，而不是受限与其他组织。

当我们打破组织之间的沟通或减少不必要的协同时，整个组织的自运行的效率就会逐渐提升，也就是 DevOps 的一种理念，如何使用于微服务和 SaaS 平台等技术的推行，实际上跟康威定律是密不可分的。

Etsy Sprouter And Conway’s Law

接下来分享一个案例来源于 Etsy，它也是在 DevOps 领域实践非常突出非常著名的一家公司。

这个案例起源于2007年，核心系统是 Sprouter，Sprouter 是存储过程导流的一个系统。在2007年时，Etsy 的系统架构是这样，开发团队在应用层会写一些PHP代码，然后 DBA 会在后端写存储过程，中间 Sprouter 起到的作用就是对应用层提供一个统一的数据库访问入口，同时会屏蔽很多数据库的信息。

这样做的结果，应用发布很多新功能，实际上都会依赖于后端的 DBA 团队去做相应的调整，这就带来了大量沟通协调，和优先级的问题，同时会有很多排队等待的浪费，会伴随很多会议和长的交付时间。

同时数据库团队也依赖于中间层这个 Sprouter，本来是两个团队可以完成的工作，现在分成了三个团队，造成这样一个系统架构的根因是，当时 Etsy 团队的组织架构分成两块，一块是前端的PHP团队，另外一块是后端的 DBA 团队，本来这个 Sprouter 的存在是想调和两个团队之间的问题，但是反而造成了开发和 DBA 之间的强依赖，导致总体效率的下降。

在2009年 Etsy 有一个非常著名的 CTO 入职，他发起了一个 Etsy culture transformation 运动，相当于整个企业文化的转变。在这个过程中他们识别出原本的这种设计不能满足企业发展的需求，所以重新对 Etsy 的系统架构做了调整。

在 Web 层开发了通用接口模块，通过这样一种接口模块，前端的应用开发可以直接调用后端的数据库。这样就增加了组织自服务的能力，减少了原本在多个团队之间频繁的沟通和移交的工作，减少了外部的依赖和解耦合，进而提升了产品部署效率。

这个活动前后经历了两年时间才真正完成，也可以看出 DevOps 转型并不是一蹴而就的，很多现有系统的转型实际上需要循序渐进去做。

大家可能也会有两个问题，第一个问题，研发如果不会写 SQL 语句怎么办，在最下面的链接里是当时分享的 PPT 的原文，他们也提到了如何解决研发不会写 SQL 的问题，根因不在技术，而在于他到底想不想去做。

因为通过人才的交叉培训和T型人才的打造，实际上研发可以掌握SQL 书写规则，这不应该成为组织的瓶颈。另外随着系统架构的演进，DBA团队似乎消失了，DBA 团队的工作是不是就被前端开发替代了呢？

实际上并不是这样，因为在原有的架构中，整个 DBA 团队的工作被开发上线的需求充满，所以他们疲于应付系统上线的需求，去跟研发配合前后端并发的调用和功能的上线。

当整个系统进行解耦之后，DBA 团队反而有时间去做真正的后端数据库的优化，包括把 Postgres SQL 切换成 MySQL，进行 Master-Master Replication 的方式，提高数据可用性和吞吐量。

同时通过 Database Sharding 的方式进行分库分表，进一步提升系统响应速度和可以同时支持的用户数量。DBA 真正把他的工作抓住于价值创造环节里，而不是像以前那样完全依赖于研发的工作。整个改进的结果是 Etsy 从2009年到现在一直发展的比较顺利，企业目标也得到了非常良好的体现。

三类组织原型

书中提出了三种组织原型，第一种是职能导向的组织团队。这种团队是现在大多数企业所采取的方式，其原因刚才也提到过，随着企业扩大，专业人才和集中管理导致了这样一种人才的聚拢，同时职能团队导向的团队，往往会伴随等级式的组织结构，每个员工的发展局限在职能团队内部，技能发展轨迹也是沿着相同路径发展，自然他们的视野也收到约束。

第二种是混合型组织，也可以理解为矩阵式组织，在这个组织中会有两条管理轴线去正交，同时对这个组织成员去施加影响，但这样一种组织形态下容易产生一个问题，一仆二主的问题，每个人可能会有复杂的汇报关系，到底哪个目标更加优先，实际上是强依赖于顶层设计在组织目标定义还有绩效考核方面的调整，以适合整个组织的目标，去达到复杂的平衡。

第三种类型是市场导向的团队，这种团队更强调如何响应用户的需求，如何组建跨职能团队、扁平化组织架构。交付团队既负责功能开发，也负责服务支持，像亚马逊等一些知名的业界公司采取的就是这样一种扁平式的组织架构。这样一种组织也会有一些潜在的问题，比如组织冗余、重复建设、相同职能员工的技能如何快速分享和拉通，这也是扁平化组织带来的一些问题。

功能导向团队的潜在问题

先看一看功能导向，也就是职能团队所带来的潜在问题。

第一点，职能团队往往会有比较长的交付周期，因为每一个组织形成了一个筒仓效应，在组织之间交付的时候往往会以一种低效的方式进行，比如要给运维提一些需求，运维就会告诉我们去提一个 ticket，通过这种方式去做协同，工作效率会比较低。另外通过细分职能，很多工作需要在不同职能之间频繁移交，这样一个移交的过程隐含了一个隐含浪费在其中。

另外往往会有大量的队列等待，当工作需要从一个部门移交到另外一个部门时，另外一个部门也有自己现有的工作，如何调整工作优先级就是一个非常大的问题，这样就导致非优先的任务往往会在长期的等待，进一步加大了交付周期。

第二点缺乏全局视野，在这样一种组织结构中，每个人的工作实际上是上游指派下来的，他并不知道我做的优化真正对后端的用户价值带来多少提升，他只是去做分配下来的工作，被动性的完成工作，这样的方式容易导致创新和主动性的真空。

第三点，资源竞争，因为组织内部的资源往往是非常有限的，尤其像这种平台支持团队，他往往会支持很多平台和业务，所有人都会给他提需求，到底哪个才是优先处理，这就会导致一个怪圈，所有测试 KPI 的制定在于上报问题的数量和有效解决的数量，这样的结果是测试上报的问题全部是紧急和严重的，在研发那里一看到所有问题都是紧急和严重，原本的任务优先级犯而不重要了，怎么样去协调任务的处理优先级变成了领导之间的PK和关系的建立。

领导 PK 的结果就是工作频繁调整优先级，并行处理工作时往往会存在切换的浪费，频繁切换优先级也会导致一些问题，反而得不到长期的解决，进一步拖慢整体效率。本来目的是要以费用导向去优化整个企业的费用，但是这样的结果反而带来了费用的上升，没有达到组织的预期。

推荐市场导向团队

市场导向团队又是怎样运作的呢，他们更加关注企业交付速度优化，通过小团队安全，独立，快速的交付用户价值，每个自组织负责应用全生命周期活动，容易产生归属感，每个人知道自己的改动在用户那边的反馈和创造的价值有多少。

同时在小型的团队内部，更容易接触一线用户，得到一线用户的反馈，并及时响应用户需求。在敏捷迭代过程中有一个非常重要的概念是时间盒，在同样一个时间盒内，要保证我们发展的质量和发布的效率，而功能的发布反而不像原本瀑布式的开发模式下严格按照计划去进行发布，随着交付速度的上升，很多功能发布可以频繁进行，而不是依赖于几个月一次的交付窗口。

值得一提的是，真正要实现这样一种方式，并不需要大规模的组织重组，组织变革往往有很多潜在的风险，通过在团队内部嵌入专业工程师或者自服务平台的建立，赋予团队相同的部署、上线、环境准备的能力，这样就可以保证原有组织再不进行大规模组织调整的时候也可以完成快速的交付。

功能导向团队同样可以成功

在上边这个图中可以看到，随着权力的下放和团队能力的上升，企业组织可以获得更好的效能，也更符合 DevOps 的发展理念。

但是必须要强调的是功能导向的团队也就是职能团队也是可以成功的，典型案例比如谷歌或者 Etsy，他们依然提供了一个集中式的运维团队，并没有把整个团队拆成小型的组织。

他们为什么可以获得成功，核心的理念就在于高度互信的组织文化和透明的全局目标和一些自服务平台的搭建。

当上游业务需要有一个需求到达这个平台服务团队的时候，他们可以快速可靠的提供相应的服务。在1980年代的精益制造运动过程中，很多专家和学者非常奇怪，为什么丰田能获得成功，而且丰田的组织结构是一个非常传统的职能型的组织结构，但是他依然创造了 TPS 这样一个非常优秀的工作方法。

通过调研发现，其实组织的形态并非决定性的因素，之所以推荐面向市场或者小规模的团队自组织自交付的团队，因为他们更加适合比如像微服务或者 DevOps 的优秀实践中的形态，但是这并不是决定性的因素，因为在组织的背后核心还是企业的人和文化，丰田的成功并不源于他是一个非常先进的组织，而是丰田员工固有的一种能力和习惯，这种能力和习惯在于整个组织的成员会共享质量、共享可用性，安全目标是每一个人的职责，而不是单一团队的制作，很多工作是嵌入到团队日常的。后面我们也会借助研发和运维如何去建立互信，建立融合的机制，去展示我们如何达到功能导向团队去获得成功的方法。

什么样的组织是最好的

究竟什么样的组织才是最好的组织，这其实是一个非常大的难题，相信很多人都知道稻盛和夫，他把日航破产到扭亏为盈只经过了两年时间。

我们观察日航在稻盛和夫改进的前后，组织结构并没有发生太明显的变化，相同的矩阵型组织达到了显著差异的业务组织目标，这就体现了组织结构背后的组织有效性才是真正影响组织交付的核心理念。而其中人才是需要被额外重视的资源，这也是 DevOps 运动兴起的核心关注点，即尊重人的价值。

帮助团队快速成长

如何帮助团队快速成长，随着技术日新月异和快速发展，我们发现在更多的组织中会倡导一专多能，工程师的技能会向上下游拓展，以至于越来越多的工程师会冠以自己全栈工程师的 title，目前业界对于 DevOps 工程师的职责定义和能力要求还不甚清晰，但是我认为全栈能力或者一专多能是将来 DevOps 工程师必备的技能。

为什么会导致这样的结果，其背后有深层次的原因。在职能导向的企业中，他们更多的是培养专家，每一个专家会在自己的角色范围内去深耕技术，诚然专家能够解决一般工程师无法解决的问题，但是这样导致的结果就是组织内部存在很多移交和瓶颈，因为技术专家作为稀缺资源，很多业务会依赖于他，所以在他那个点就会导致一些瓶颈，而且这样的瓶颈就会引发整个组织的浪费。

另外随着技术的日新月异，过往某个领域的专家很有可能在新的领域没有达到相同的高度，对于人才的使用上造成了浪费，而解决这个问题的核心在于找到那些具备良好学习能力的人才。

之前的很多分享中也提到过T型人才，所谓T型人才相当于通才，不仅在一个领域内有非常深入的理解，同时普遍在各个领域也有一些自己的认知和技能的储备，这样就保证当开发遇到一些运维问题的时候，他是可以有一些自己的判断能力的，而不是说把所有跟运维相关的问题都移交到运维团队，避免了工作在多个团队中的频繁切换。

同时T型人才的储备也有助于面向市场这种小型的自服务自交付团队的建立。当然最终极的人才是E型人才，E型人才在各个领域都有非常深的技能储备，也自然更加可遇不可求。如何才能帮助团队快速成长，实际上有一些方法，比如可以创造内部学习和交叉培训的机会，组织对团队的发展提供技术支持，提供一些轮岗培训和鼓励创新、自主学习等，帮助团队的程序员不再专注于某一个具体领域，而是扩展他们的技能认知，帮助组织可以更快速的交付用户价值。

高效组织的四点建议

本章最后对高效能组织提出四点建议。

第一，产品和服务导向，而非项目导向。关注产品指标，比如用户价值、营收或用户留存等，当团队关心最终指标时，他们才会知道自己的改进到底是否真正有效，才能真正去迭代更有效的工作方式。

第二，建立松耦合架构，鼓励团队自治。团队之间可以减少依赖，独立开发测试和部署，独立进行生产发布，通过清晰的接口定义和一些服务型平台，可以帮助团队快速完成原本由专业团队才能完成的事情，把很多技能落到交付团队内部，帮助他们完成团队自治。

第三，根据康威定律设计组织边界，大型团队往往会带来低效或者大公司病，导致技能浪费，很多流程在设计过程中往往会把老板引入流程审批过程，实际上老板是远离整个业务价值交付的，让他去做决策，除了背锅没有什么其他的意义，更多的是要把决策权放到一线团队，精简不必要协同和交流，精简不必要的审批。

第四，保持小型团队，独立交付。在亚马逊有一个非常经典的例子，两个披萨的团队，在这背后体现了管理幅度的概念，一个人可以管理多少人，在传统的管理学中大概是6到7人左右，但实际上并没有这么简单，一个人到底可以管理多少人取决于很多因素，比如流程是否清晰，是否有标准化的流程，再比如团队的能力如何，主动性是否强，其实都会影响整个团队的规模，核心的理念在于团队如何去共享一个清晰的目标，所有人都知道我们在做的这个事情到底是为什么目标，要到达什么样的结果。

同时把这样的结果跟整个企业的核心业务目标去做匹配，来帮助企业达到最终的经营目标。在这样一个小型团队中可以锻炼和培养团队内部领导力，帮助更多的自组织团队可以成立和良好的运行。

本章总结 - 打造高效能组织

谈到团队自治，我能想到最有意思的就是这个变形金刚的图，他很好的体现了组织自治的理念，每一个组织都可以独立作战，都有独立的方式方法和能力，他们可以独立作战的同时也可以结合到一起，去达到更强大的组织目标，这样就可以实现整个组织从个体到整体的完美结合，进而提高价值产出。

核心点，第一是职能组织形态，第二是产品和服务导向，第三是快速独立交付用户价值，第四是培养员工进行内部学习并成为T型人才甚至是E型人才。

2.8、 将运维能力嵌入研发工作之中

最后一个章节，将运维能力嵌入研发工作中。我们一直在谈DevOps，其实就是在谈开发和运维，这章里提到很多实际可行的方法，帮助开发和运维相亲相爱。

这里放了一张美式橄榄球的图，如何理解开发和运维的关系，实际上可以参考这张图中的内容。前面这一排叫做 line man，是一条线，后面这个人是非常重要的角色，也就是四分卫，是团队的大脑，开发和运维作为一个团队，他们会共享同一个目标，也就是赢球的目标，运维的存在就是保证开发有足够的时间去创造更大的价值，团队意识是将开发和运维集成在一起的先决条件，我们不是对立的，而是共同为组织企业目标服务的团队。

方法1: 打造服务平台，提高研发生产率

第一个方法是打造服务平台，提高研发生产效率。

在之前谷歌和 Etsy 的例子中也提到，在他们的公司中一直保有非常庞大的平台服务型团队，比如运维团队，他们怎么去对外提供这种服务能力，就是通过打造一个通用的服务平台，这也是越来越多的公司开始关注企业内部的 PaaS 平台、SaaS 平台或者 DevOps 平台这样一种平台型系统建设的原因。

建设这样一个平台的时候会有几点值得关注

第一是自动化和自助式的服务，如果平台只是一个工作流系统，当外部用户提交一个需求时，仍然需要后台团队内部的人员手动去处理，这样是远远达不到当初设计这个平台的目的和初衷的，我们希望达到的目标是当用户提交了一个需求，这个需求可以通过自动化和自助式的服务完成，而不是依赖后端服务平台提供方的手动支持。

第二是团队内部的平台开发也需要以一个产品的思维进行，通过产品化提供良好的服务品质和易用性，并不是说团队内部系统就可以不关注易用性，因为所有的用户在使用这样的产品的时候，他的体验他的生产效率就决定了整个企业的生产效率，如果系统难用，用户很容易找到替代品或者拒绝使用，这就造成了更大范围的资源浪费。

第三是超出内部用户预期，在原有企业内部，团队有一套自己的工作方式方法，你很难说一次性通过强制的方式让大家抛弃原有的方法而迁移到这样一个平台上，只能这个平台的功能，超出部分用户的预期，提供更好的功能，提高更好的实现，满足他们之前手动或者原有的方法不能满足的方法，这样才能吸引大家愿意去使用你的平台，最重要的是我们在认可平台的前提下，可以共同去改进内部交付平台。

每一个企业内部的工作流程，它的价值交付流都是不同的，一个平台的适用性取决于是否满足这个企业内部价值交付的整个流程和团队组织架构，这也是为什么一个通用的 DevOps 平台很难去适用于所有企业的原因，因为每个企业都有不同的关注点。底下有一句话说得很好，用户可以依赖于我们的工具，但是他不能依赖于工具背后的人。这也是自服务平台的一个核心理念，就是要提供自助式和自动化的服务能力。

平台服务团队的定位

对于平台服务团队的定位，越来越的企业开始组建工程效率团队或者敏捷改进团队，也越来越注重这样一些平台型工程效率提升团队的建设，对于这样一些团队包括之前大的运维团队，该如何去明确自己的定位，这里面给出了四点建议。

第一是打造自服务系统，提高研发团队的创新速度，提高生产力。这里面就提到了自服务，这个系统提供出去可以满足用户自己使用，而不只是一个流程系统，而需要我们手动支持。越早的提供自服务系统就越能释放平支撑团队或者工程效率改进团队手工工作的压低，而释放他们自己本身的创新能力，也提高团队生产率。

第二，当这样一种自服务系统，不管是内部自研的还是外部引进的，整个平台支持团队要提供相应的技术指导和工具迁移、工程教练类的服务，这些服务可以帮助研发团队和终端用户快速适应使用这样一些自服务系统，从而提高大家使用的效率，激发团队内部的最佳实践。因为往往在真正用户开始使用这样一种平台的时候，我们才会发现有很多潜在的需求是没有被满足的，而且团队内部的一些好的经验方法没有在系统中得到体现，这样一种内部的交流和用户之间的沟通可以通过工具支持和工程教练方法做到。

第三点，注重标准化建设，加快研发上手速度，专注核心价值创造，我们不希望这样一个系统非常复杂，需要专业培训，而是比较简单直接可以自解释的一种方式，任何一个团队决定用这个系统的时候他可以用非常简单的方式使用这个方法，前提是通过标准化建设。最后一点是分析团队现有工具链，当一个组织足够大的时候，总有一些团队内部会有一些自己好的实践和自己的工具，如何识别这样的工具，并认为它可以在内部大规模推广和推荐给其他团队使用，从而让整个组织受益，这是我们团队需要重点关注的方向。

方法2: 将运维工程师嵌入产品交付团队

第二种方法比较直接，把运维工程师直接嵌入产品交付团队。通过把运维工程师嵌入产品交付团队，打造产品交付团队的对外服务和运维的能力。同时产品目标是决定开发运维工作优先级的尺子，所有团队的目标是符合于产品目标的。

其次，运维不再是一个成本中心，它是整个自服务交付团队其中的一员，他也可以促进整个组织加大对平台部门或者说后端部门的成本投入和支持。将开发和运维结对是团队赋能的最佳途径，只有当大家一起肩并肩工作的时候，彼此之间的交流和培训可以快速提升团队内部人员的技能水平，建立T型人才梯队。

运维需要体现出自己的价值，通过转变谈对固有工作和思维方式，可以帮助大家知道之前很多工作方法是不满足可部署性、可靠性的，通过前端的介入可以间接影响产品架构的设计，可以间接影响业务决策。右边罗列了一些运维工程师的职责供大家参考。

方法3: 建立运维接口人制度

往往这样一个运维团队没有足够的人力把运维人员直接拆分，我们无法支持每一个团队都有一个独立的运维人员，这里提出运维接口人制度。

运维接口人首先需要去熟悉产品目标，而且他对整个内部的运维、自服务平台、自服务系统有非常良好的技能储备，可以直接对接运维的系统。

有一些比较新的需求过程的时候，他也可以快速协调二线支持人员，提供更加专业的支持。同时他也相当于是一个服务产品的接口人，他可以评估这个自服务系统，真正用起来到底是好还是有什么问题，可以帮助把这些问题收集并反馈到后端的运维平台内部，帮助优化自服务平台建设的需求优先级。

同时帮助协调资源需求和时间冲突，比如已经预知到团队在未来周上线非常大的系统，他就可以在第一时间和后端的一些集中式运维平台进行沟通，提前准备相应的资源提前做规划。

运维参与研发日常活动

在研发执行敏捷的过程中，实际上有一些非常好的工程实践，DevOps 倡导团队去共享价值共享目标，运维也需要参加研发的一些日常活动，其中一个非常典型的活动就是每日站会，主要目标在于团队内部共享信息，对齐目标，找到瓶颈点，寻求解决方案，站会时领导都会参加，也容易解决资源和优先级冲突协调的问题。

运维参与的好处在于他可以更加直观的理解研发活动，做好运维规划，提前准备资源，应对发布需求，并从运维视角给出关注点和建议，协助解决当前系统问题。比如研发遇到了一些瓶颈，比如运维发现可以通过运维的一些手段帮助提供一些日志的反馈，来快速定位问题，帮助整个组织内部的目标达到协同。

第二迭代回顾会议，这个是在每个 sprint 结束之后召开的总结类似的会议，会议目标在于总结成功和待改进的问题并在内部推广，团队碰撞新的想法，总结试验结果，同时把试验潜在的问题和改进点纳入待办事项。运维参与的好处，可以受益于团队学习，获取新的知识，同时他可以从运维视角展示很多实际产品运行中的数据，建立运维开发反馈环，分析问题和缺陷并且发现潜在问题。

第三个是构想可视化看板，看板的价值在于可视化价值流动，投入这种可视化同步工作进展，明确目标，识别潜在的约束点和任务依赖，通过约束在制品数量，加快业务价值的流转。

当运维和开发共享一个可视化看板时，可以快速跟踪价值交付全流程，说明价值交付是只有在运维完成线上部署并对用户提供真正服务的时候，才真正完成整个价值交付的过程，而不应该是在开发完成之后就认为这个需求已经结束。其次可以通过可视化看板去跟踪运维侧工作事项和进展，通过把运维和开发的目标对其，整体识别整个系统中的瓶颈点，并进行及时改进。

本章总结 - DevOps的融合

本章最后提出一个概念，DevOps 的融合，未来在 DevOps 理念不断深入过程中，开发和运维到底会产生什么样的交集和关系，如图所示，可能是部分的开发和部分的运维，是一个共同融合的状态。在之前 Google SRE 的书中就提出，所有的运维工程师和开发工程师都有非常强的开发背景，只不过运维方面会更加关注一些系统方面的知识，包括操作系统、网络、存储等方面知识的积累。

SRE 工作就是开发和运维有效的结合，SRE 相当于 DevOps 非常好的实践思路，一方面通过完成传统运维的工作，类似于发布、部署、监控，同时由于他们具备开发能力和全局视野，可以通过更加自动化的手段，更加高效的完成传统的工作，同时开发和运维通过目标的协同去共享业务价值交付的计划，从不同的角度对业务价值交付提供技术支持。

同时由于他们是这些自服务系统的开发者和使用者，可以在实际的使用过程中不断总结问题，不断优化和调整，可以让自服务平台更加有效，这也是 DevOps 最终所要达到的目标展示和 DevOps 自身的魅力所在。

由于时间限制，这次快速完成了第二部分的介绍，简单回顾一下，第二部分更多是关注承前启后的环节，当我们决定要去做 DevOps 的时候我们应该在什么地方开始 DevOps 转型，如何去识别业务价值流，如何去识别其中的指标。

当我们明确了要去改进的方向时，根据康威定律去组织一些团队架构，减少团队之间的耦合和依赖，来共享团队组织的目标，来帮助整个组织快速交付用户价值。最后通过运维和开发的融合，来帮助实现组织最终的目标改善产出。

原创：石雪峰　Certified DevOps Master，Certified Jenkins Engineer，DevOps 时代社区核心成员，全开源端到端部署流水线主创成员，DevOpsDays 大会金牌讲师。现任某大型互联网创业公司配置管理与工程效率总监，负责公司 DevOps 与持续交付体系与平台建设。曾任职于华为、尼康，从事持续交付推进及工具链平台建设工作，拥有多年持续交付落地实践经验。

导言

本次分享是《DevOps　Handbook》的第二部分，DevOps 从哪里入手，可以说这一章在全书中是承前启后的一章，主要想要解决的是我们要做什么的问题。

第一章简单回溯了 DevOps 的发展历史并提纲挈领的介绍了核心的三步工作法，第三章开始会深入每一步工作法并详细介绍里面的优秀实践。

在第二章里主要关注的是企业如何去选择合适的价值流，并在价值流中进行分析改进。同时关注整个企业组织架构的建设，因为企业组织架构和管理制度是领导者发挥卓越领导力的基础。

最后一部分会探讨 Dev 和 Ops 之间融合的实践方法。

上篇分享分四个部分的前两个部分，这篇主要分享后两个部分，第三部分主要关注组织架构，第四部分关注研发和运维能力整合的具体实践。

上半部分回顾：[  /s?__biz=MzI0Njc5ODkxMA==&mid=2247485581&idx=1&sn=139beeccf36cd61ca1cb463943e4b798&chksm=e9b887dcdecf0ecaf76561ec0c12c4d9b10d11cf60ed52c5f957ba0895fe6575b11e9250d565&scene=21#wechat_redirect]如何开始我们的 DevOps 转型之旅？[/url]

2.7、 根据康威定律构建组织和架构

第三部分，根据康威定律构建组织和架构。康威定律从诞生至今已经超过50年历史，随着微服务架构的兴起，对于康威定律的讨论不绝于耳，那么究竟什么是康威定律呢？

康威定律很简单，只有一句话：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

怎么理解这句话，在每个企业发展之初，相信每个人都是十项全能的选手，一个工程师可能研发运维一把抓，所有的事情都在他自己的脑袋里，这样的背景下整个组织的沟通成本是比较低的，效率也比较高。

随着企业规模扩大，为了提升效率，我们会把人员按照专业去细分，同时把知识进行积累，形成规模效应，结果就会形成一个一个的组织。

组织的边界逐步明确，就会导致很多优化是在组织内部，无法形成组织建的有效合作和闭环，导致一些紧偶合和强依赖。

以右上角这个图为例，三个团队，UI 团队、中间层团队和 DBA 团队，这显然是一个按照职能划分的组织结构，这样三个团队设计出来的系统往往是右面所示，会分三层去设计系统架构。

随着微服务理念的兴起，系统需要做拆分和解耦，通过系统调用或者接口定义的方式完成自服务或者自运维，这就要求组织会根据这样一种变化去进行调整，调整的基础就是要建立自组织、自交付的团队，为这个团队提供完整的支持，包括一些平台服务的通用平台，达到的目标是自组织团队可以独立完成价值交付、独立运维，而不是受限与其他组织。

当我们打破组织之间的沟通或减少不必要的协同时，整个组织的自运行的效率就会逐渐提升，也就是 DevOps 的一种理念，如何使用于微服务和 SaaS 平台等技术的推行，实际上跟康威定律是密不可分的。

Etsy Sprouter And Conway’s Law

接下来分享一个案例来源于 Etsy，它也是在 DevOps 领域实践非常突出非常著名的一家公司。

这个案例起源于2007年，核心系统是 Sprouter，Sprouter 是存储过程导流的一个系统。在2007年时，Etsy 的系统架构是这样，开发团队在应用层会写一些PHP代码，然后 DBA 会在后端写存储过程，中间 Sprouter 起到的作用就是对应用层提供一个统一的数据库访问入口，同时会屏蔽很多数据库的信息。

这样做的结果，应用发布很多新功能，实际上都会依赖于后端的 DBA 团队去做相应的调整，这就带来了大量沟通协调，和优先级的问题，同时会有很多排队等待的浪费，会伴随很多会议和长的交付时间。

同时数据库团队也依赖于中间层这个 Sprouter，本来是两个团队可以完成的工作，现在分成了三个团队，造成这样一个系统架构的根因是，当时 Etsy 团队的组织架构分成两块，一块是前端的PHP团队，另外一块是后端的 DBA 团队，本来这个 Sprouter 的存在是想调和两个团队之间的问题，但是反而造成了开发和 DBA 之间的强依赖，导致总体效率的下降。

在2009年 Etsy 有一个非常著名的 CTO 入职，他发起了一个 Etsy culture transformation 运动，相当于整个企业文化的转变。在这个过程中他们识别出原本的这种设计不能满足企业发展的需求，所以重新对 Etsy 的系统架构做了调整。

在 Web 层开发了通用接口模块，通过这样一种接口模块，前端的应用开发可以直接调用后端的数据库。这样就增加了组织自服务的能力，减少了原本在多个团队之间频繁的沟通和移交的工作，减少了外部的依赖和解耦合，进而提升了产品部署效率。

这个活动前后经历了两年时间才真正完成，也可以看出 DevOps 转型并不是一蹴而就的，很多现有系统的转型实际上需要循序渐进去做。

大家可能也会有两个问题，第一个问题，研发如果不会写 SQL 语句怎么办，在最下面的链接里是当时分享的 PPT 的原文，他们也提到了如何解决研发不会写 SQL 的问题，根因不在技术，而在于他到底想不想去做。

因为通过人才的交叉培训和T型人才的打造，实际上研发可以掌握SQL 书写规则，这不应该成为组织的瓶颈。另外随着系统架构的演进，DBA团队似乎消失了，DBA 团队的工作是不是就被前端开发替代了呢？

实际上并不是这样，因为在原有的架构中，整个 DBA 团队的工作被开发上线的需求充满，所以他们疲于应付系统上线的需求，去跟研发配合前后端并发的调用和功能的上线。

当整个系统进行解耦之后，DBA 团队反而有时间去做真正的后端数据库的优化，包括把 Postgres SQL 切换成 MySQL，进行 Master-Master Replication 的方式，提高数据可用性和吞吐量。

同时通过 Database Sharding 的方式进行分库分表，进一步提升系统响应速度和可以同时支持的用户数量。DBA 真正把他的工作抓住于价值创造环节里，而不是像以前那样完全依赖于研发的工作。整个改进的结果是 Etsy 从2009年到现在一直发展的比较顺利，企业目标也得到了非常良好的体现。

三类组织原型

书中提出了三种组织原型，第一种是职能导向的组织团队。这种团队是现在大多数企业所采取的方式，其原因刚才也提到过，随着企业扩大，专业人才和集中管理导致了这样一种人才的聚拢，同时职能团队导向的团队，往往会伴随等级式的组织结构，每个员工的发展局限在职能团队内部，技能发展轨迹也是沿着相同路径发展，自然他们的视野也收到约束。

第二种是混合型组织，也可以理解为矩阵式组织，在这个组织中会有两条管理轴线去正交，同时对这个组织成员去施加影响，但这样一种组织形态下容易产生一个问题，一仆二主的问题，每个人可能会有复杂的汇报关系，到底哪个目标更加优先，实际上是强依赖于顶层设计在组织目标定义还有绩效考核方面的调整，以适合整个组织的目标，去达到复杂的平衡。

第三种类型是市场导向的团队，这种团队更强调如何响应用户的需求，如何组建跨职能团队、扁平化组织架构。交付团队既负责功能开发，也负责服务支持，像亚马逊等一些知名的业界公司采取的就是这样一种扁平式的组织架构。这样一种组织也会有一些潜在的问题，比如组织冗余、重复建设、相同职能员工的技能如何快速分享和拉通，这也是扁平化组织带来的一些问题。

功能导向团队的潜在问题

先看一看功能导向，也就是职能团队所带来的潜在问题。

第一点，职能团队往往会有比较长的交付周期，因为每一个组织形成了一个筒仓效应，在组织之间交付的时候往往会以一种低效的方式进行，比如要给运维提一些需求，运维就会告诉我们去提一个 ticket，通过这种方式去做协同，工作效率会比较低。另外通过细分职能，很多工作需要在不同职能之间频繁移交，这样一个移交的过程隐含了一个隐含浪费在其中。

另外往往会有大量的队列等待，当工作需要从一个部门移交到另外一个部门时，另外一个部门也有自己现有的工作，如何调整工作优先级就是一个非常大的问题，这样就导致非优先的任务往往会在长期的等待，进一步加大了交付周期。

第二点缺乏全局视野，在这样一种组织结构中，每个人的工作实际上是上游指派下来的，他并不知道我做的优化真正对后端的用户价值带来多少提升，他只是去做分配下来的工作，被动性的完成工作，这样的方式容易导致创新和主动性的真空。

第三点，资源竞争，因为组织内部的资源往往是非常有限的，尤其像这种平台支持团队，他往往会支持很多平台和业务，所有人都会给他提需求，到底哪个才是优先处理，这就会导致一个怪圈，所有测试 KPI 的制定在于上报问题的数量和有效解决的数量，这样的结果是测试上报的问题全部是紧急和严重的，在研发那里一看到所有问题都是紧急和严重，原本的任务优先级犯而不重要了，怎么样去协调任务的处理优先级变成了领导之间的PK和关系的建立。

领导 PK 的结果就是工作频繁调整优先级，并行处理工作时往往会存在切换的浪费，频繁切换优先级也会导致一些问题，反而得不到长期的解决，进一步拖慢整体效率。本来目的是要以费用导向去优化整个企业的费用，但是这样的结果反而带来了费用的上升，没有达到组织的预期。

推荐市场导向团队

市场导向团队又是怎样运作的呢，他们更加关注企业交付速度优化，通过小团队安全，独立，快速的交付用户价值，每个自组织负责应用全生命周期活动，容易产生归属感，每个人知道自己的改动在用户那边的反馈和创造的价值有多少。

同时在小型的团队内部，更容易接触一线用户，得到一线用户的反馈，并及时响应用户需求。在敏捷迭代过程中有一个非常重要的概念是时间盒，在同样一个时间盒内，要保证我们发展的质量和发布的效率，而功能的发布反而不像原本瀑布式的开发模式下严格按照计划去进行发布，随着交付速度的上升，很多功能发布可以频繁进行，而不是依赖于几个月一次的交付窗口。

值得一提的是，真正要实现这样一种方式，并不需要大规模的组织重组，组织变革往往有很多潜在的风险，通过在团队内部嵌入专业工程师或者自服务平台的建立，赋予团队相同的部署、上线、环境准备的能力，这样就可以保证原有组织再不进行大规模组织调整的时候也可以完成快速的交付。

功能导向团队同样可以成功

在上边这个图中可以看到，随着权力的下放和团队能力的上升，企业组织可以获得更好的效能，也更符合 DevOps 的发展理念。

但是必须要强调的是功能导向的团队也就是职能团队也是可以成功的，典型案例比如谷歌或者 Etsy，他们依然提供了一个集中式的运维团队，并没有把整个团队拆成小型的组织。

他们为什么可以获得成功，核心的理念就在于高度互信的组织文化和透明的全局目标和一些自服务平台的搭建。

当上游业务需要有一个需求到达这个平台服务团队的时候，他们可以快速可靠的提供相应的服务。在1980年代的精益制造运动过程中，很多专家和学者非常奇怪，为什么丰田能获得成功，而且丰田的组织结构是一个非常传统的职能型的组织结构，但是他依然创造了 TPS 这样一个非常优秀的工作方法。

通过调研发现，其实组织的形态并非决定性的因素，之所以推荐面向市场或者小规模的团队自组织自交付的团队，因为他们更加适合比如像微服务或者 DevOps 的优秀实践中的形态，但是这并不是决定性的因素，因为在组织的背后核心还是企业的人和文化，丰田的成功并不源于他是一个非常先进的组织，而是丰田员工固有的一种能力和习惯，这种能力和习惯在于整个组织的成员会共享质量、共享可用性，安全目标是每一个人的职责，而不是单一团队的制作，很多工作是嵌入到团队日常的。后面我们也会借助研发和运维如何去建立互信，建立融合的机制，去展示我们如何达到功能导向团队去获得成功的方法。

什么样的组织是最好的

究竟什么样的组织才是最好的组织，这其实是一个非常大的难题，相信很多人都知道稻盛和夫，他把日航破产到扭亏为盈只经过了两年时间。

我们观察日航在稻盛和夫改进的前后，组织结构并没有发生太明显的变化，相同的矩阵型组织达到了显著差异的业务组织目标，这就体现了组织结构背后的组织有效性才是真正影响组织交付的核心理念。而其中人才是需要被额外重视的资源，这也是 DevOps 运动兴起的核心关注点，即尊重人的价值。

帮助团队快速成长

如何帮助团队快速成长，随着技术日新月异和快速发展，我们发现在更多的组织中会倡导一专多能，工程师的技能会向上下游拓展，以至于越来越多的工程师会冠以自己全栈工程师的 title，目前业界对于 DevOps 工程师的职责定义和能力要求还不甚清晰，但是我认为全栈能力或者一专多能是将来 DevOps 工程师必备的技能。

为什么会导致这样的结果，其背后有深层次的原因。在职能导向的企业中，他们更多的是培养专家，每一个专家会在自己的角色范围内去深耕技术，诚然专家能够解决一般工程师无法解决的问题，但是这样导致的结果就是组织内部存在很多移交和瓶颈，因为技术专家作为稀缺资源，很多业务会依赖于他，所以在他那个点就会导致一些瓶颈，而且这样的瓶颈就会引发整个组织的浪费。

另外随着技术的日新月异，过往某个领域的专家很有可能在新的领域没有达到相同的高度，对于人才的使用上造成了浪费，而解决这个问题的核心在于找到那些具备良好学习能力的人才。

之前的很多分享中也提到过T型人才，所谓T型人才相当于通才，不仅在一个领域内有非常深入的理解，同时普遍在各个领域也有一些自己的认知和技能的储备，这样就保证当开发遇到一些运维问题的时候，他是可以有一些自己的判断能力的，而不是说把所有跟运维相关的问题都移交到运维团队，避免了工作在多个团队中的频繁切换。

同时T型人才的储备也有助于面向市场这种小型的自服务自交付团队的建立。当然最终极的人才是E型人才，E型人才在各个领域都有非常深的技能储备，也自然更加可遇不可求。如何才能帮助团队快速成长，实际上有一些方法，比如可以创造内部学习和交叉培训的机会，组织对团队的发展提供技术支持，提供一些轮岗培训和鼓励创新、自主学习等，帮助团队的程序员不再专注于某一个具体领域，而是扩展他们的技能认知，帮助组织可以更快速的交付用户价值。

高效组织的四点建议

本章最后对高效能组织提出四点建议。

第一，产品和服务导向，而非项目导向。关注产品指标，比如用户价值、营收或用户留存等，当团队关心最终指标时，他们才会知道自己的改进到底是否真正有效，才能真正去迭代更有效的工作方式。

第二，建立松耦合架构，鼓励团队自治。团队之间可以减少依赖，独立开发测试和部署，独立进行生产发布，通过清晰的接口定义和一些服务型平台，可以帮助团队快速完成原本由专业团队才能完成的事情，把很多技能落到交付团队内部，帮助他们完成团队自治。

第三，根据康威定律设计组织边界，大型团队往往会带来低效或者大公司病，导致技能浪费，很多流程在设计过程中往往会把老板引入流程审批过程，实际上老板是远离整个业务价值交付的，让他去做决策，除了背锅没有什么其他的意义，更多的是要把决策权放到一线团队，精简不必要协同和交流，精简不必要的审批。

第四，保持小型团队，独立交付。在亚马逊有一个非常经典的例子，两个披萨的团队，在这背后体现了管理幅度的概念，一个人可以管理多少人，在传统的管理学中大概是6到7人左右，但实际上并没有这么简单，一个人到底可以管理多少人取决于很多因素，比如流程是否清晰，是否有标准化的流程，再比如团队的能力如何，主动性是否强，其实都会影响整个团队的规模，核心的理念在于团队如何去共享一个清晰的目标，所有人都知道我们在做的这个事情到底是为什么目标，要到达什么样的结果。

同时把这样的结果跟整个企业的核心业务目标去做匹配，来帮助企业达到最终的经营目标。在这样一个小型团队中可以锻炼和培养团队内部领导力，帮助更多的自组织团队可以成立和良好的运行。

本章总结 - 打造高效能组织

谈到团队自治，我能想到最有意思的就是这个变形金刚的图，他很好的体现了组织自治的理念，每一个组织都可以独立作战，都有独立的方式方法和能力，他们可以独立作战的同时也可以结合到一起，去达到更强大的组织目标，这样就可以实现整个组织从个体到整体的完美结合，进而提高价值产出。

核心点，第一是职能组织形态，第二是产品和服务导向，第三是快速独立交付用户价值，第四是培养员工进行内部学习并成为T型人才甚至是E型人才。

2.8、 将运维能力嵌入研发工作之中

最后一个章节，将运维能力嵌入研发工作中。我们一直在谈DevOps，其实就是在谈开发和运维，这章里提到很多实际可行的方法，帮助开发和运维相亲相爱。

这里放了一张美式橄榄球的图，如何理解开发和运维的关系，实际上可以参考这张图中的内容。前面这一排叫做 line man，是一条线，后面这个人是非常重要的角色，也就是四分卫，是团队的大脑，开发和运维作为一个团队，他们会共享同一个目标，也就是赢球的目标，运维的存在就是保证开发有足够的时间去创造更大的价值，团队意识是将开发和运维集成在一起的先决条件，我们不是对立的，而是共同为组织企业目标服务的团队。

方法1: 打造服务平台，提高研发生产率

第一个方法是打造服务平台，提高研发生产效率。

在之前谷歌和 Etsy 的例子中也提到，在他们的公司中一直保有非常庞大的平台服务型团队，比如运维团队，他们怎么去对外提供这种服务能力，就是通过打造一个通用的服务平台，这也是越来越多的公司开始关注企业内部的 PaaS 平台、SaaS 平台或者 DevOps 平台这样一种平台型系统建设的原因。

建设这样一个平台的时候会有几点值得关注

第一是自动化和自助式的服务，如果平台只是一个工作流系统，当外部用户提交一个需求时，仍然需要后台团队内部的人员手动去处理，这样是远远达不到当初设计这个平台的目的和初衷的，我们希望达到的目标是当用户提交了一个需求，这个需求可以通过自动化和自助式的服务完成，而不是依赖后端服务平台提供方的手动支持。

第二是团队内部的平台开发也需要以一个产品的思维进行，通过产品化提供良好的服务品质和易用性，并不是说团队内部系统就可以不关注易用性，因为所有的用户在使用这样的产品的时候，他的体验他的生产效率就决定了整个企业的生产效率，如果系统难用，用户很容易找到替代品或者拒绝使用，这就造成了更大范围的资源浪费。

第三是超出内部用户预期，在原有企业内部，团队有一套自己的工作方式方法，你很难说一次性通过强制的方式让大家抛弃原有的方法而迁移到这样一个平台上，只能这个平台的功能，超出部分用户的预期，提供更好的功能，提高更好的实现，满足他们之前手动或者原有的方法不能满足的方法，这样才能吸引大家愿意去使用你的平台，最重要的是我们在认可平台的前提下，可以共同去改进内部交付平台。

每一个企业内部的工作流程，它的价值交付流都是不同的，一个平台的适用性取决于是否满足这个企业内部价值交付的整个流程和团队组织架构，这也是为什么一个通用的 DevOps 平台很难去适用于所有企业的原因，因为每个企业都有不同的关注点。底下有一句话说得很好，用户可以依赖于我们的工具，但是他不能依赖于工具背后的人。这也是自服务平台的一个核心理念，就是要提供自助式和自动化的服务能力。

平台服务团队的定位

对于平台服务团队的定位，越来越的企业开始组建工程效率团队或者敏捷改进团队，也越来越注重这样一些平台型工程效率提升团队的建设，对于这样一些团队包括之前大的运维团队，该如何去明确自己的定位，这里面给出了四点建议。

第一是打造自服务系统，提高研发团队的创新速度，提高生产力。这里面就提到了自服务，这个系统提供出去可以满足用户自己使用，而不只是一个流程系统，而需要我们手动支持。越早的提供自服务系统就越能释放平支撑团队或者工程效率改进团队手工工作的压低，而释放他们自己本身的创新能力，也提高团队生产率。

第二，当这样一种自服务系统，不管是内部自研的还是外部引进的，整个平台支持团队要提供相应的技术指导和工具迁移、工程教练类的服务，这些服务可以帮助研发团队和终端用户快速适应使用这样一些自服务系统，从而提高大家使用的效率，激发团队内部的最佳实践。因为往往在真正用户开始使用这样一种平台的时候，我们才会发现有很多潜在的需求是没有被满足的，而且团队内部的一些好的经验方法没有在系统中得到体现，这样一种内部的交流和用户之间的沟通可以通过工具支持和工程教练方法做到。

第三点，注重标准化建设，加快研发上手速度，专注核心价值创造，我们不希望这样一个系统非常复杂，需要专业培训，而是比较简单直接可以自解释的一种方式，任何一个团队决定用这个系统的时候他可以用非常简单的方式使用这个方法，前提是通过标准化建设。最后一点是分析团队现有工具链，当一个组织足够大的时候，总有一些团队内部会有一些自己好的实践和自己的工具，如何识别这样的工具，并认为它可以在内部大规模推广和推荐给其他团队使用，从而让整个组织受益，这是我们团队需要重点关注的方向。

方法2: 将运维工程师嵌入产品交付团队

第二种方法比较直接，把运维工程师直接嵌入产品交付团队。通过把运维工程师嵌入产品交付团队，打造产品交付团队的对外服务和运维的能力。同时产品目标是决定开发运维工作优先级的尺子，所有团队的目标是符合于产品目标的。

其次，运维不再是一个成本中心，它是整个自服务交付团队其中的一员，他也可以促进整个组织加大对平台部门或者说后端部门的成本投入和支持。将开发和运维结对是团队赋能的最佳途径，只有当大家一起肩并肩工作的时候，彼此之间的交流和培训可以快速提升团队内部人员的技能水平，建立T型人才梯队。

运维需要体现出自己的价值，通过转变谈对固有工作和思维方式，可以帮助大家知道之前很多工作方法是不满足可部署性、可靠性的，通过前端的介入可以间接影响产品架构的设计，可以间接影响业务决策。右边罗列了一些运维工程师的职责供大家参考。

方法3: 建立运维接口人制度

往往这样一个运维团队没有足够的人力把运维人员直接拆分，我们无法支持每一个团队都有一个独立的运维人员，这里提出运维接口人制度。

运维接口人首先需要去熟悉产品目标，而且他对整个内部的运维、自服务平台、自服务系统有非常良好的技能储备，可以直接对接运维的系统。

有一些比较新的需求过程的时候，他也可以快速协调二线支持人员，提供更加专业的支持。同时他也相当于是一个服务产品的接口人，他可以评估这个自服务系统，真正用起来到底是好还是有什么问题，可以帮助把这些问题收集并反馈到后端的运维平台内部，帮助优化自服务平台建设的需求优先级。

同时帮助协调资源需求和时间冲突，比如已经预知到团队在未来周上线非常大的系统，他就可以在第一时间和后端的一些集中式运维平台进行沟通，提前准备相应的资源提前做规划。

运维参与研发日常活动

在研发执行敏捷的过程中，实际上有一些非常好的工程实践，DevOps 倡导团队去共享价值共享目标，运维也需要参加研发的一些日常活动，其中一个非常典型的活动就是每日站会，主要目标在于团队内部共享信息，对齐目标，找到瓶颈点，寻求解决方案，站会时领导都会参加，也容易解决资源和优先级冲突协调的问题。

运维参与的好处在于他可以更加直观的理解研发活动，做好运维规划，提前准备资源，应对发布需求，并从运维视角给出关注点和建议，协助解决当前系统问题。比如研发遇到了一些瓶颈，比如运维发现可以通过运维的一些手段帮助提供一些日志的反馈，来快速定位问题，帮助整个组织内部的目标达到协同。

第二迭代回顾会议，这个是在每个 sprint 结束之后召开的总结类似的会议，会议目标在于总结成功和待改进的问题并在内部推广，团队碰撞新的想法，总结试验结果，同时把试验潜在的问题和改进点纳入待办事项。运维参与的好处，可以受益于团队学习，获取新的知识，同时他可以从运维视角展示很多实际产品运行中的数据，建立运维开发反馈环，分析问题和缺陷并且发现潜在问题。

第三个是构想可视化看板，看板的价值在于可视化价值流动，投入这种可视化同步工作进展，明确目标，识别潜在的约束点和任务依赖，通过约束在制品数量，加快业务价值的流转。

当运维和开发共享一个可视化看板时，可以快速跟踪价值交付全流程，说明价值交付是只有在运维完成线上部署并对用户提供真正服务的时候，才真正完成整个价值交付的过程，而不应该是在开发完成之后就认为这个需求已经结束。其次可以通过可视化看板去跟踪运维侧工作事项和进展，通过把运维和开发的目标对其，整体识别整个系统中的瓶颈点，并进行及时改进。

本章总结 - DevOps的融合

本章最后提出一个概念，DevOps 的融合，未来在 DevOps 理念不断深入过程中，开发和运维到底会产生什么样的交集和关系，如图所示，可能是部分的开发和部分的运维，是一个共同融合的状态。在之前 Google SRE 的书中就提出，所有的运维工程师和开发工程师都有非常强的开发背景，只不过运维方面会更加关注一些系统方面的知识，包括操作系统、网络、存储等方面知识的积累。

SRE 工作就是开发和运维有效的结合，SRE 相当于 DevOps 非常好的实践思路，一方面通过完成传统运维的工作，类似于发布、部署、监控，同时由于他们具备开发能力和全局视野，可以通过更加自动化的手段，更加高效的完成传统的工作，同时开发和运维通过目标的协同去共享业务价值交付的计划，从不同的角度对业务价值交付提供技术支持。

同时由于他们是这些自服务系统的开发者和使用者，可以在实际的使用过程中不断总结问题，不断优化和调整，可以让自服务平台更加有效，这也是 DevOps 最终所要达到的目标展示和 DevOps 自身的魅力所在。

由于时间限制，这次快速完成了第二部分的介绍，简单回顾一下，第二部分更多是关注承前启后的环节，当我们决定要去做 DevOps 的时候我们应该在什么地方开始 DevOps 转型，如何去识别业务价值流，如何去识别其中的指标。

当我们明确了要去改进的方向时，根据康威定律去组织一些团队架构，减少团队之间的耦合和依赖，来共享团队组织的目标，来帮助整个组织快速交付用户价值。最后通过运维和开发的融合，来帮助实现组织最终的目标改善产出。

原创：石雪峰　Certified DevOps Master，Certified Jenkins Engineer，DevOps 时代社区核心成员，全开源端到端部署流水线主创成员，DevOpsDays 大会金牌讲师。现任某大型互联网创业公司配置管理与工程效率总监，负责公司 DevOps 与持续交付体系与平台建设。曾任职于华为、尼康，从事持续交付推进及工具链平台建设工作，拥有多年持续交付落地实践经验。