神聊《DevOps HandBook》 Part II：DevOps从何处入手

大熊

导言

本次分享是《DevOps Handbook》的第二部分，主要关注DevOps从哪里入手，这一章是承前启后的一章，主要解决的是我们要做什么的问题。第一章简单回溯了DevOps的发展历史以及核心的三步工作法，第二章后会深入每一步工作法并详细介绍里面的优秀实践。在第二章里主要关注的是企业如何去选择合适的价值流，并在价值流中进行分析改进。同时关注整个企业组织架构的建设，企业组织架构和管理制度是领导者发挥卓越领导力的基础。最后一部分会探讨Dev和Ops之间融合的实践方法。

今天分享分四个部分，第一部分会介绍如何选择合适的价值流，第二部分通过具体的方法理解并可视化价值流，第三部分主要关注组织架构，第四部分关注研发和运维能力整合的具体实践。

开启DeVOps转型之旅

相信小伙伴们或多或少对DevOps已经有一些基本的认识，并且也希望借由DevOps完成整个企业IT价值流交付链的建设。很多人在真正开始做DevOps之前总是会有一些问题，比如我们应该如何在什么地方开始DevOps的转型之旅，都有谁需要加入这场DevOps的变革，如何建立DevOps转型组织，如何确保成功。每当发现这些问题的时候我总会想到“纪念碑谷”这个游戏，我们在做DevOps转型的时候就好像我们是“纪念碑谷”里的主人公，目标相对比较明确，同时业界也会有一些非常优秀的公司，像亚马逊、谷歌、BAT、招行等，他们在DevOps过程中在各自的领域取得了非常瞩目的成功，我们想要达到这个目标，过程和路径实际上并不是十分清晰的，所以经常有人会问应该如何去做DevOps，但是他们从来没有提及我们为什么要做DevOps，DevOps要解决的是什么问题。在本次分享的第一部分，我们要在什么地方开始我们的DevOps转型之旅。

2.5 选择合适的价值流

在开始前简单分享一下价值流的概念，价值流也就是VSM（Value stream mapping），是本书中非常核心的一个概念。价值流图其实源于传统的一些制造行业，源于精益思想。价值流图是通过一种形象化的方式，把整个产品生产过程中包括从原料一直到产品交付用户这样一个过程，让它变得可视化。价值流图的主要目的是发现浪费和消除浪费，这也是精益思想中的一个核心理念。在价值流图中如果想要消除浪费，核心关注两个时间指标，VAT增值活动时间，NVAT不增值活动时间，通过把增值活动时间无限放大，不增值活动时间缩小，来达到整个交付效率的提升，减少整体的浪费。价值流图中还有两个核心状态，当前状态、未来状态，企业通过制定合理的未来状态，和当前状态去做对比，识别状态之间的差距。在这个过程中通过持续改进，典型的方法就是PDCA的流程，通过持续改进的方法，逐渐把我们从当前的状态演进成未来想要达到的预期状态。在做IT时，它不同于传统的制造行业，对于IT流中很多信息的可视化实际上是比较困难的，而且也不容易被量化，我们同样可以借鉴传统制造业的方法来帮助我们识别IT交付价值流中的各个阶段，并帮助我们发现其中的约束点和瓶颈点，通过持续改进，不断识别和改进问题。

为什么价值流的选择会是我们的第一步

为什么价值流的选择会是我们的第一步，上边的图片是阿波罗11号第一次登上月球的纪念照，实际上我们去做DevOps转型的时候，价值流的选择包含了很多深层次的概念，其中就代表DevOps转型的工作难度，你要在什么地方、在哪个业务开始DevOps。其次会影响哪些人和组织会被引入变革，在这个过程中我们会跟谁去打交道。还有合理利用有限的组织资源和机会。这个事情是需要深思熟虑的，主要的原因在于如果我们这个转型的第一步方向出了问题，不仅浪费了有限的企业资源，同时也打击了企业去变革的勇气和积极性。最终的结果是错失时间窗口和市场机遇，导致企业危机会不断放大。右下有一行小字，真实反映了这种情况，“尤其当我们的企业处于危机中的时候，我们可能很难有太多的机会不断去尝试”，我们的机会是有限的，所以第一步方向选正确是对我们未来的转型奠定一个非常坚实的基础。

Nordstrom DevOps转型案例

《DevOps Handbook》引用了Nordstrom的转型案例，Nordstrom是美国高档的百货商店，2015年时达到将近135亿美元的销售额。这个案例是2011年发生的案例，案例中提到了在DevOps转型之前，整个价值流的方式是Optimizing for Cost，去优化支出，优化费用。他们常见的做法是把很多的技术团队进行外包，每年排一部计划，通过瀑布式的方式去开发演进，每次会发布很多新的内容。最后一条是达到将近97%的计划达成率，这点其实是很有意思的，虽然通过这样一种技术外包和瀑布式开发模式，每次的计划达成率都非常高，但实际上这样的结果还是无法满足企业五年的战略规划，背后深层次原因在于当时整个在线电子商务的迅猛发展，对整个企业的发展带来非常大的挑战。我们保持以前这种按计划迭代式重管控的方式开发演进就很容易导致这样的一个结果，像诺基亚的CEO所说，我们可能并没有做错什么，但不知道为什么我们输了。这个并不是真实的消息，应该是网上有人杜撰出来的。正因为这样一种IT交付价值效率和企业发展预期之间的距离，Nordstrom开始了转型。转型的核心理念，从费用的优化转向对速度的优化，他们做了几件事情，建立了独立的团队，持续更进计划，按需发展，通过快速迭代不断满足用户需求，达到了以往四倍的交付速度。整个案例中主要有四点值得大家借鉴和参考，第一是专注，整个研发过程中，Nordstrom并没有一次铺开，把所有的业务都去做DevOps转型，而是挑选了一些特定领域去做实验和学习，这些领域实际上都是当时没有达到业绩指标的一些小的团队和业务方向。第二，通过转型，他们达到了初期的成功，并且证明了这样一种方式在组织内部是可以被复制的。第三，通过改进，帮助没有达到业务目标的部门去实现业务部门，以至于他们更愿意接受新的工作方法。第四是度量，通过可视化，减少前置时间，并不断迭代。在整个转型过程中，实际上他们面临的是一个非常尖锐的问题，因为业务的需求扩大了四倍，有人就提出我们的团队是不是也要相应扩大四倍，但是当时负责DevOps转型的IT负责人却选择了另外一条路，通过一些内建质量或者集中部署，不断提高生产IT效率，最终达到交付时间下降和事故率下降，最终完成了DevOps转型。在本次的分享中我们也会详细介绍每一个领域到底应该怎么样去做。

Greenfield vs Brownfield

首先需要解决的问题是，我们要在什么地方开始选择合适的价值流。比较普遍的情况下会有两种类型的系统，一种叫Greenfield，一种叫Brownfield，其实这个概念来源于建筑行业，Greenfield代表的是一个全新的项目或者这个项目处于一个初期阶段，采取了一些全新的设计和全新的团队，而且无需担心现有的代码流程组织的阻碍。Brownfield项目往往适用于一些新技术方法去尝试，Greenfield只在既存产品和服务，这样一些产品和服务已运行很多年，有沉重的技术债务，而且不能满足组织交付能力的需求。很多人会认为DevOps可能会更加适用于这些新项目，也就是Greenfield的项目，但事实上DevOps不仅对Greenfield项目，对于既存的项目同样是有效的。通过统计发现，超过半数的转型案例是来源于右边这种Brownfield的项目。背后深层次的原因在于，现有的产品和服务已经长期的提供线上服务并创造价值，客观体现了组织交付能力和需求的落差，当这样的一些现有系统实现转变，它所带来的客观利润实际上是非常可观的，而且在这些传统团队里，他们普遍认识到传统的方法是不足以支撑业务目标的，所以他们更有动力去迎接变化、拥抱变化，采用新的方法改进现有状态，以达到业务目标。当然，对于现有系统的改造会伴随很多阻碍和问题，比如它缺乏很多自动化测试和紧偶合的架构等，在本书的三步工作法中对这些具体的实践方法都有一个明确的定义。

SOR vs SOE

第二种系统类型是SOR和SOE，最早是由一家IT咨询公司提出了Bimodal的概念，Bimodal就是所谓的双模IT，其中SOR更倾向于类似于现有的ERP或HR、财务类似的一些系统，关注点在于业务的可靠性和稳定性，对于数据的正确性是至关重要的，而且这样的系统监管规格要求也比较高。导致这样的系统会关注性能，变化节奏慢，核心理念是Do it RIGHT。另外一个系统是SOE，这种类似于电子商务和移动应用，更关注业务的敏捷交付，关注用户价值导向、快速迭代以及如何更好的满足需求，荷银理念是Do it FAST。SOR和SOE在企业中往往是并行存在的，但是由于两种系统的显著差异，往往容易让大家区分对。但是在今年的DevOps状态报告中，明确提出了DevOps是可以弥合这两种方式的最佳方案。

DevOps弥合两种模式

通过今年的DevOps状态报告的数据显示，高效能组织同时可以取得高质量和高效率，对于SOR和SOE这两类系统，不应该割裂对待，因为对于一个系统来说，当系统耦合性较强的时候，它的变更频率适用于木板原理，短板往往成为整个系统的瓶颈点，在现有的系统中往往就是SOR。同时不管是SOR还是SOR，同样需要关注快速、安全和简单的变更。Greenfield的这种产品或者说SOE的产品，往往基于可靠的SOR，所以保证SOR和SOE的整体优化才是IT系统服务优化的一个最佳出路。SOR和SOE系统不应该割裂对待，现有系统和新系统同样也适用于DevOps转型。

选择合适的初始团队

当我们决定要在哪个系统领域开始我们的转型的时候，接下来要面对的就是如何去选择一个合适的初始团队。上边这个图非常有名，摩尔提出了一个跨越鸿沟的概念，在这个图中可以看到，第一象限、第二象限相当于更愿意拥抱变化的用户群体，后面是更加偏向于保守和跟随大流的企业，中间有一条鸿沟，在组织中开始进行DevOps转型的时候其实更加适用于这些创新性的团队，因为他们往往认同DevOps的理念和实践，往往有一些拥抱变化和更新现有流程的意愿，同时对风险承受能力和快速试错有一定认识。对于系统真正去尝试转型的时候，务必要注意的是避免在初始阶段全面铺开。即便有管理层的支持，但实际也是要循序渐进的过程。今年Facebook发表了一篇非常著名的文章，介绍了他们整个发布系统的演进过程，从主干开发分支发布到主干开发主干发布，这样一个发布系统，在一年内首先覆盖了50%的研发人员，同时对生产环境流量从0.1%到1%再到10%，逐步切换，完成了核心系统的过渡。避免多面铺开转型的任务，核心在于我们要识别收敛目标，要确保初期成功。同时初期成功可以在组织内复制，经验是值得总结的。

在组织中拓展DevOps

在DevOps转型落地的时候，初期的成功是非常重要的，如何去保证初期的转型是可以获得成功的，书中介绍了几种方式。第一，把大的改进事项细分，通过渐进的方式去改进。第二，加快改进速度。第三，及时发现错误，当我们在一个小的转型工作中发现我们的方向出现了问题，可以及时调整方向，及时调整优先级。其次，在整个迭代过程，基于不断的学习去调整后续转型的决策。初期的成功可以带给我们的是提升整个转型团队的信用，提升我们的影响力，扩展支持者。第一，寻找早期支持者，企业转型离不开真正的业务团队，如何找到那些合适的团队，找到具有创新意识的团队，并且这样的团队最好是在组织内部有影响力的团队，可以提升变革的可信度。第二，积累成功案例，通过影响更多的团队和价值流，印发从众的效应，可以帮助相对保守的团队看到这些初期的效果，以至于他们愿意接受这样的改进方式。第三，回避顽固保守者，保证这样的改进可以持续成功。

本章总结

总结一下，这一章核心理念要找到合适的价值流，如何找到合适的业务方向去开始DevOps转型。介绍了几种系统类型，也介绍了不同的团队类型。总结过程中引用了一个理论，这个理论是由管理大师彼得·德鲁克提出的，翻译过来是大鱼小池的效应，这个效应更多是认知方面的一些理论。举例来说，有一万块钱，如果跟一千块钱比，我可能是富翁，跟一百万去比，我可能是一个比较穷的人。当我们在跟不同人比较的时候，我们的心理落差不一样。回到DevOps转型过程中，通过大鱼小池的效应，可以帮助我们在有限范围内获得更多的资源，相当于在小的鱼缸里，这只鱼可以享受更多的水，水就是我们可以调动的资源。同时在这样一个小的团体内，我获得成功可能是至关重要的，有助于提高转型的信心和主动性。同时在小的范围内尝试转型，尝试一些新的技术、新的方法，不会影响整个组织，小范围的试错不会影响整个组织的效能。当我们在一个小池内逐渐成长为值得信任或者我们的实践理论方法得到验证之后，我们再去更大范围扩展，这样循序渐进的方式帮助DevOps转型可以获得有效的成功。

2.6 理解并可视化价值流

第二部分是理解并可视化价值流，第一章我们已经找到了改进的业务点、业务方向，接下来要做的是去识别整个价值创造过程中的所有环节。精益所倡导的方式是价值的流动，价值流动的前提是识别出整个价值交付流的各个阶段。实际上在很多复杂的项目中是需要多人去合作的，而且价值交付过程非常复杂，非常难对整个价值交付的全局有统观的意识。多团队协作导致组织上和地域上的隔离。举个简单例子，可能这个公司测试团队很忙，普遍的做法是采取增加测试人员的方式去缓解测试瓶颈。这样的改进结果会导致测试的人力成本逐渐上升，但效果却不好。这就是为什么如果我们只关注下游，而不关注上游，其实价值流动的根音并没有被我们发现，测试忙，可能他的原因整个软件质量并没有大家可测试的需求。如果我们在上游在开发团队引入类似持续集成或者自动化测试的方式，帮助整个质量的左移，这样可以有效缓解测试很忙的案例，避免头痛医头、脚痛医脚的现象，保证组织有一个全局的视野。这个过程中不仅要识别整个价值流交付的各个阶段，同时要识别这里面的主要角色。在书中提供了一些参考的角色，如下图所示。

召集价值流图分析WorkShop

在识别价值流的过程中有一个非常好的实践，召集价值流图分析Workshop，在这个Workshop里会召集价值流交付各个环节的主要人员，大家在一起协作去识别，并画出价值流交付的过程。往往复杂系统需要上百人的协作，细化所有的步骤也非常复杂，在这个过程中要掌握颗粒度，原则上希望参加Workshop的人员是有一定决策权的。识别出来的价值流主要包含5-15个左右的步骤，在这个过程中可以充分了解彼此的活动，格外需要关注两类问题，一类是存在大量等待的环节，比如线上什么环境的准备需要很长时间，或者开发需要很长时间才能得到用户反馈。另外是产生显著返工的环节，比如部署频繁失败或者测试率不通过，质量可能存在一些潜在的风险。核心理念在于无需面面俱到，而是聚焦影响快速流动和可靠产出的环节。在这样一个活动中很有可能是第一次跟一些经常通过电话微信沟通的人员见面，而且对于运维人员来说他有可能是第一次真实的去理解研发缺乏一些线上日志或者具体信息的沮丧，对开发来说他们也才发现，每每他们去标记一个完成之后，后端的测试和部署团队需要花多大努力才能交付到真正的用户价值。通过这样一种彼此的分享去了解彼此的工作，去寻求一些潜在的价值点，才是我们真正要去关注的核心内容。

可视化价值流图

通过这样一个Workshop，可以初步梳理出价值流图主要的阶段和核心的时间，在价值流图中重点关注的是三个要素，Lead time、Process time、准确率，前两个概念在上次分享时其实已经有说提到，Lead time是整个价值流交付完整的时间，也就是我们常说的前置时间，而Process time是真正去执行这个时间的具体时间。这样的对比就可以识别出一些潜在待改进的度量指标。如果我们要去改进的指标Lead time，这里面潜在的问题可能是我们有一些约束点和瓶颈点，导致很多工作处于等待的状态，无形中延长了Lead time的过程。如果这个指标更多关注于Process time，就说明在整个工作真正执行过程中可能存在很多手动或者低效的方式，导致价值在生产的过程中是低效的。如果我们关注的是准确率，这里面客观体现的是质量和信息不健全。通过识别潜在的改进点，通过不断迭代、循环，最终达到整个组织效率最佳的目标，这个循环是不断演进的过程。同时在这个过程中我们要重点关注的是约束理论，因为所有不在约束点去进行的改进，实际上都是一种伪改进，因为在价值流过程中，如果你在约束点之前进行改进，实际上约束点还是瓶颈。如果在约束点之后改进，价值交付同样没有得到很好的释放。所以在整个价值流过程中如何良好的识别约束点也是要重点关注的内容。

变革推进小组

当我们识别了要去改进的指标的时候，接下来就要去组件变革推进小组，可以说组织内唯一不变的事情就是组织变革，当组织开始发生危机的时候，组织的变化可能也就会停滞，相应速度开始变慢，信息也会开始脱节。在一个组织中或多或少都有一些现有的流程和实践，这些原有的流程和实践帮助组织从小到大，获得了很多业务上的成功。每一次组织变革或者DevOps变革，都意味着去颠覆和创新原有的团队职责，在这个过程中毫无疑问会产生一些DevOps转型和现有业务的冲突，如何解决这样一个冲突，最好的办法就是建立独立的变革改进小组。在这样一个小组中会有一些特殊的属性，比如说变革小组中的成员是需要全职加入DevOps转型改革的，而不是一个兼职的状态，另外倾向于全面能力的人员，第三倾向于资历较深、在组织内受到尊敬的角色，这样当我们的转型方案真正跟业务整合的时候，往往会通过一些良好的沟通达到更好的效果。当然这样一个转型工作小组最佳的方式是可以在同样一个办公区域去做面对面的沟通，可以优化组织内部沟通效率。目标只有一个，通过一个全新的流程或知识来达到变革转型的效果。

在张乐老师之前的分享过程中也提供过这样一个参考变革组织小组的组织架构。上边这个变革推进小组是ETC小组，会统领整个跨职能团队的组织变革，同时在下端会有一些平台型的组织提供技术支持和平台型的能力。

团队共享改进目标

在整个过程中，团队需要制定清晰改进目标，成立这样一个变革改进小组，要有一个非常清晰的目标，比如需要降低一些现有的预算，达到50%，比如说可以减少95%从代码变更到线上提交的过程。通过制定清晰和可度量的目标和时间点，可以帮助我们明确将要改进的工作，同时这样一些目标达成是可以为组织和用户带来显著价值的，一可以呼应之前提到的一些初期的胜利，一些初期的成功可以通过一些具体的价值来真正体现，同时这样的目标最好跟管理层和全体人员达成一直。建议是减少并行开展类似的工作，组织资源是有限的，如果同时开展此类工作，往往会导致组织陷入这样的改进困境之中。通过减少并行开始的改进工作，有点类似于限制WIP的理念，通过减少WIP，加速改进过程的落地实施。第二是采取周期迭代和增量式的方法推进改进，因为我们很难确定这样的变革之路到底是不是可靠有效的，所以通过快速迭代、增量的方式去推进改进，往往是成功的不二法则。同时在每一次迭代之后要及时进行回顾和反思，为下一次迭代做好准备。

控制初期改进范围

在改进初期，我们建议要控制初期改进的范围，控制改进范围可以帮助灵活应对优先级和计划变更，同时可以把一些小的改进最快速度的体现出来，加强反馈环建设，增强改进信心，激发更多投入，快速学习，持续迭代，最重要的是，投入了这么多资源去做改进，如果迟迟没有效果，项目有被砍掉的风险。右边提到变革领导力，在整个项目改进过程中，变革领导力能起到非常重要的作用，它可以提供个体的支持，同时鼓励改进，明确改进目标，对团队现状进行挑战，并提供一些可行的方案。企业中的变革领导力是在DevOps状态报告中特别体现的一点。

预留20%时间处理非功能性需求和技术债务

本书中特别提到技术债务处理，建议预留20%处理非功能性需求和技术债务，经常有一些笑话，为了保持改进空间，产品经理要求程序员减缓程序执行的速度，由于程序员在代码里加了一句话，sleep 20，通过这个方法拖慢了整个程序执行速度。这是一个笑话，实际上当我们面临很强的交付压力时，不排除真的有这样一些性能瓶颈风险，比如随意添加本地一些变量等，虽然也可以达到目标，实际上是对组织留下潜在的技术债务。技术债务的堆积会导致一个非常严重的后果，往往最需要改进的组织在改进上的时间投入是最少的，因为他们技术债务的堆积侵占了很多研发工程师的时间。之前跟一个研发工程师在沟通时，他们有点自嘲说，我们其实是一个解bug的工程师，但是我们认为整个研发才是企业价值流中真正增值的环节，研发工程师是不等于解bug工程师的，这里面的原因很有可能是来源于技术债务。通过上图中左下角这个图可以看到，左边是用户可见的功能需求，带来的正向反馈是需求和功能，负向反馈是缺陷，对于这样一些问题是可以去把握和修复的。右边往往是用户不可见的内容，包括一些架构上的内容，包括非功能性的需求，包括一些过程改进。如果我们不能很好的去处理这样一些非功能性的需求等用户不可见的内容，往往就会导致技术债务堆积，进而拖慢组织发展速度。

增加团队工作可视化

增加团队工作可是化，为什么要做可视化，最主要的原因在于可视化可以帮助组织内所有人了解当前的工作状态，同时确保信息是及时更新的，可视化出来的信息不是过时的，所有人看到的是最新的状态信息。同时调整指标来应对改进变化。下面有一句话，自从人类发明火和掌握火的使用之后，所有的文化进步都跟工具密切相关，可以看到整个发展过程其实就是一部工具的进化史。

使用工具来加速加速行为转变

通过工具来加速行为转变，很多时候体现在可视化环节里。第一是使用统一的作业平台，在组织发展过程中，经常开发和运维是使用不的问题追踪系统的，比如开发是使用Jira这样的系统，运维可能是使用一个自建的系统。通过不同的作业平台的共享，其实开发和运维可以共享他们的目标，也可以共享待办事项，这样做的价值在于整个组织的资源优化被统一协调、统一调配，研发和运维的工作也符合组织业务价值目标的需求。另外，使用相同的作业系统、相同的语言，很容易在同一个系统内进行看板展示，进行任务传递和内容更新、沟通。最后通过全局视角进行任务优先级排序和编排。右边是即时通讯软件和聊天室的系统，这里提到一个典型的工具slack，这个工具是一个SaaS工具，在国内可能由于网络原因不太适用，国内也有一些相应的工具。它核心的理念在于使用一个统一的交流通讯系统平台，可以快速帮助我们解决问题，同时培养组织互信文化，在这个平台里聚合了很多外部工具，可以通过这样一个聊天系统，可以快速触发编译，可以快速收集到外部的反馈，很多信息是聚合在同一个系统里的，不需要查看一些bug的时候跳到Jira系统或者查看一些编译构建状态挑战到Jenkins系统上，在一起化的工具平台内部，很多信息是聚合在一起的。通过这种方式，组织内很多知识或者案例可以积累起来，提供强大的知识搜索的功能，遇到问题，可以通过关键字检索，查找到之前的解决方案，帮助快速解决问题。这样的做法也有一些负面因素，比如频繁打断，所以在使用这样一种即时通讯软件或者内部沟通软件的时候，团队需要去明确一些规则。总体来说，其实我们很多的浪费是发生在协调、沟通和组织间信息传递的过程中，通过打破这样一些浪费的环节，可以提升组织运行效率。

本章总结

总结一下，本章核心理念在于持续改进，识别价值流的一些过程。下图是网上找的比较有意思的图，原文是西班牙语，通过图示可以看到很多非常有趣的点。比如在这个地方提到改进需要一步一步去做，同时改进需要有一个教练的环节，并通过PDCA环节识别出不太适合我们组织企业的改进，同时进行一些反思和回顾帮助我们改进会更加有效。总结起来，设定一个可预期的目标，通过小步迭代的方式去执行改进，纳入日常活动，在错误中学习，改进是每个人的工作，不应该局限于具体的某个团队，应该是一种文化，这也是丰田方法核心的价值所在。

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

第三部分，根据康威定律构建组织和架构。康威定律从诞生至今已经超过50年历史，随着微服务架构的兴起，我们可以频繁的听到康威定律这个概念。康威定律：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。怎么理解这句话，在每个企业发展之初，相信每个人都是十项全能的选手，一个工程师可能研发运维一把抓，所有的事情都在他自己的脑袋里，这样的背景下整个组织的沟通成本是比较低的，效率也比较高。随着企业规模扩大，为了提升效率，我们会把人员按照专业去细分，同时把知识进行积累，形成规模效应，结果就会形成一个一个的组织。组织的边界逐步明确，就会导致很多优化是在组织内部，无法形成组织建的有效合作和闭环，导致一些紧偶合和强依赖。以右上角这个图为例，三个团队，UI团队、中间层团队和DBA团队，这显然是一个按照职能划分的组织结构，这样三个团队设计出来的系统往往是右面所示，会分三层去设计系统架构。随着微服务理念的兴起，系统需要做拆分和紧偶，通过系统调用或者接口定义的方式完成自服务或者自运维，这就要求组织会根据这样一种变化去进行调整，调整的基础就是要建立自组织、自交付的团队，为这个团队提供完整的支持，包括一些平台服务的通用平台，达到的目标是自组织团队可以独立完成价值交付、独立运维，而不是受限与其他组织。当我们打破组织之间的沟通或减少不必要的协同时，整个组织的自运行的效率就会逐渐提升，也就是DevOps的一种理念，如何使用于微服务和SaaS平台等技术的推行，实际上跟康威定律是密不可分的。

Etsy Sprouter And Conway's Law

接下来分享一个案例，Etsy，这案例来源于Etsy，它也是在DevOps领域实践非常突出非常著名的一家公司。这个案例起源于2007年，核心系统是Sprouter，Sprouter是存储过程导流的一个系统。在2007年时，Etsy的系统架构是这样，开发团队在应用层会写一些PHP代码，然后DBA会在后端写存储过程，中间Sprouter起到的作用就是对应用层提供一个统一的数据库访问入口，同时会屏蔽很多数据库的时限。这样做的结果，我们应用发布很多新功能，实际上都会依赖于后端的DBA团队去夺相应的调整，这就带来了大量沟通协调，大致一些优先级的问题，同时会有很多排队等待的浪费，会伴随很多会议和长的交付时间。同时数据库团队也依赖于中间层这个Sprouter，本来是两个团队可以完成的工作，现在分成了三个团队，造成这样一个系统架构的根因是，当时Etsy团队的组织架构分成两块，一块是前端的PHP团队，另外一块是后端的DBA团队，本来这个Sprouter的存在是想调和两个团队之间的问题，但是反而造成了之间的强依赖和效率的下降。在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的优秀实践中可以良好的发展，但是这并不是决定性的因素，因为在组织的背后核心还是企业的人和文化，丰田的成功并不源于他是一个非常先进的组织，而是他的人员有一种能力和习惯，这种能力和习惯在于整个组织的成员会共享质量、共享可用性，安全目标是每一个人的职责，而不是单一团队的制作，很多工作是嵌入到团队日常的。后面我们也会借助研发和运维如何去建立互信，建立融合的机制，去展示我们如何达到功能导向团队去获得成功的方法。

什么样的组织是最好的

究竟什么样的组织才是最好的组织，这其实是一个非常大的难题，相信很多人都知道稻盛和夫，他从日航破产到扭亏为盈只经过了两年时间。我们观察日行在稻盛和夫改进的前后，组织结构并没有发生太明显的变化，但是依然可以达到组织目标，这就体现了组织结构背后的组织有效性才是真正影响组织交付的核心理念。

帮助团队快速成长

如何帮助团队快速成长，随着技术日新月异和快速发展，我们可以越来越多的发现在更多的组织中会倡导一专多能，工程师的技能会向上下游拓展，以至于越来越多的工程师会冠以自己全栈工程师的title，将来会有DevOps工程师的时候，全栈或者一专多能这样一种技能是DevOps工程师必备的技能。为什么会导致这样一个结果，有一些背后的原因。在原始也就是职能导向的企业中，他们更多的是培养专家，每一个专家会在自己的角色范围内去深耕技术，这样导致的结果就是组织内部存在很多移交和瓶颈，因为很多的技术专家实际上比较稀少，很多业务会依赖于他，所以在他那个点就会导致一些瓶颈，而且这样的瓶颈就会引发整个组织的浪费。之前也提到类似于T型的人才，所谓T型人才相当于通才，不仅在一个领域内有非常深入的理解，同时普遍在各个领域也有一些自己的认知和技能的储备，这样就保证当开发遇到一些运维问题的时候，他是可以有一些自己的判断能力的，而不是说把所有跟运维相关的问题都移交到运维团队，这样就避免了工作在多个团队中的快速流转。同时这种T型人才的储备也有助于我们面向市场这种小型的自服务自交付团队的建立。最终极的人才相当于是异型人才，异型人才在各个领域都有非常深的技能储备，如何才能达到团队快速成长的结构，实际上有一些方法，比如可以创造内部学习和交叉培训的机会，组织对团队的发展提供技术支持，提供一些轮岗培训和鼓励创新、自主学习等，帮助团队的程序员不再专注于某一个具体领域，而是扩展他们的技能认知，帮助组织可以更快速的交付用户价值。

高效组织的四点建议

本章最后对高效能组织提出四点建议。第一，产品和服务导向，而非心目导向。关注产品指标，比如用户价值、营收或用户留存等，当团队关心最终指标时，他们才会知道自己的改进到底是否真正有效，才能真正去迭代更有效的工作方式方法。第二，建立松耦合架构，鼓励团队自治。团队资质可以减少依赖，独立开发测试和部署，独立进行生产发布，通过清晰的接口定义和一些服务型平台，可以帮助团队快速完成原本由专业团队才能完成的事情，把很多技能落到交付团队内部，这样就可以帮助他们完成团队自治。第三，根据康威定律设计组织边界，大型团队往往会带来低效或者大公司病，导致技能浪费，很多流程在设计过程中往往会把老板引入流程审批过程，实际上老板是远离整个业务价值交付的，让他去做决策，除了背锅没有什么其他的意义，更多的是要把决策权放到一线团队，精简不必要协同和交流，精简不必要的审批。第四，保持小型团队，独立交付。在亚马逊有一个非常经典的例子，两个披萨的团队，在这背后体现了管理幅度的概念，一个人可以管理多少人，在传统的管理学中大概是6到7人左右，但实际上并没有这么简单，一个人到底可以管理多少人取决于很多因素，比如流程是否清晰，是否有标准化的流程，再比如团队的能力如何，主动性是否强，其实都会影响整个团队的规模，核心的理念在于团队如何去共享一个清晰的目标，所有人都知道我们在做的这个事情到底是为什么目标，要到达什么样的结果。同时把这样的结果跟整个企业的核心业务目标去做匹配，来帮助七达到最终的经营目标。其次，在这样一个小型团队中可以锻炼和培养团队内部领导力，帮助更多的自组织团队可以成立和良好的运行。

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

谈到团队自治，我能想到最有意思的就是这个变形金刚的图，体现了组织自治非常好的理念，每一个组织都可以独立作战，都有独立的方式方法和能力，他们可以独立作战的同时也可以结合到一起，去达到更强大的组织目标，这样就可以把整个组织从1到整体的结合，完美的结合，进而提出价值产出。核心，第一是职能组织形态，第二是产品和服务导向，第三是快速独立交付用户价值，第四是培养员工进行内部学习并成为T型人才甚至是异型人才。

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转型，如何去识别业务价值流，如何去识别其中的指标。当我们明确了要去改进的方向时，根据康威定律去组织一些团队架构，减少团队之间的耦合和依赖，来共享团队组织的目标，来帮助整个组织快速交付用户价值。最后通过运维和开发的融合，来帮助实现组织最终的目标改善产出。

下期预告

下一次会真正开始到DevOps三步工作法的第一步，这里做一个简单的预告，下周二时王磊老师会给大家带来《DevOps Handbook》三步工作法的第一步：流水线实践。这里我们都知道流水线是持续交付的核心实践，在《DevOps Handbook》中这一章应该是内容最充实最多的内容，会详细介绍持续交付流水线、自动化测试以及持续集成、发布和一些架构方面的内容，也期待下一次《DevOps Handbook》拆书帮的活动。