class="topic_img" alt=""/>
姚安峰
DevOps 这个词在近年来可谓大火。从 2014 年底我开始给一些企业做持续交付/DevOps 相关的评估和咨询，似乎每个企业都表示想要推行 DevOps，或者说他们正在做 DevOps。这把火蔓延的速度远远超过当年敏捷在 IT 行业的传播。然而有些企业管理者对 DevOps 的认知让我们意识到，由于各种有意或无意的因素，这个概念不幸地成为了一个让人困惑的 buzz word……
什么是 DevOps？
这里我想列出四种我们在市场上、企业咨询以及社区交流过程中接触到的认知：
作为企业管理者，要在组织中引入 DevOps 并推动变革，首先要对 DevOps 的目标有清晰的认识，并明确 DevOps 在自己企业的上下文中意味着什么。我反对一些厂商将 DevOps 吹得太大，但这也绝不仅仅是运维单方面的目标。DevOps 运动本质上是关于开发（含测试）和运维的协作，在“为用户创造最大化价值”的一致目标下，让软件交付给用户并获得反馈的过程更加敏捷。至于要不要将开发运维一体化，则取决于具体产品的特征，在不同场景下可以有不同的协作模式。
DevOps 行业报告提出了两个顶层的用于衡量 IT 组织效能的指标：吞吐量和稳定性。在一些人看来，这两个目标就像鱼和熊掌不可兼得。追求交付吞吐量，就会带来更大的不稳定性和风险；而传统运维管理以稳定性为目标，就必然牺牲对变化的响应力。之所以会有这样的悲观认知，是因为仅仅站在当前的时空看待问题，而无法超越自己的能力局限。企业管理者需要理解，进行 DevOps 转型，就是要超越自己的能力局限，超出当前的时空看问题，通过组织设计、过程改进和工程技术的提升让组织能力上升到一个新的维度，我们完全可以做到同时提高 IT 交付的吞吐量和稳定性，而不是在两者之间取舍平衡。
然而，要突破自身的能力局限，这并非易事。下面谈到的实施 DevOps 过程中的七大挑战中的每一个都需要组织下决心投入，并耐心等待回报，没有足够的认知转变和卓越领导力难以实现。
挑战一：自动化测试投入不足，收益低
敏捷宣言自提出时，就已经将自动化测试作为敏捷、极限编程的核心实践来强调。然而这么多年过去了，在组织中真正有效进行自动化测试的并不多，各种问题都在影响着组织和团队对自动化测试的信心。
要想同时提升吞吐量和稳定性，以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。如果说在以往谈论敏捷开发的时候，自动化测试是对团队的较高要求，那么到了 DevOps 时代，这就是最基本的入门要求。毫不夸张的说，如果软件系统没有一套较完善的自动化测试体系，就请不要谈 DevOps 了。
最直接的问题是投入不足。很多管理者意识里是将自动化测试看做一项额外的、可有可无的任务。他们关注的是短期的项目管理目标，而不是长期的产品持续演进，往往只有进度压力不大的时候才投入人力来做一做，或者单独聘请一个团队来补充测试用例，然后离开，而不是作为开发团队交付软件产品的一部分。这样的模式很难产生一套长期有效的测试套件，反过来进一步削弱了管理者对其进行投入的信心。
另外常见的一些问题包括：
要解决以上问题，并产生一套有效的自动化测试套件是一个巨大挑战，需要管理者和团队转变质量意识；需要企业从项目化的管理转向产品化的管理，人们才能真正长远地去考虑对自动化测试的投资；需要影响业务人员在需求容量上的期望，为书写自动化测试提供时间。
挑战二：高度集中的 IT 基础设施服务
在传统模式下，像服务器申请、配置变更等 IT 服务是由高度集中的基础设施管理团队负责。产品交付团队需要向集中的 IT 服务团队提出申请；而该团队往往承接着来自很多交付团队的需求，于是只能将请求进行排队依次处理，并且主要依靠手动处理；结果是交付团队不得不长时间等待，才能得到所需资源。这个过程中的手动操作，使得经过一段时间后，基础设施的配置变成了一个黑洞，没人能够说得清各个服务器之间的状态差异，当问题出现时需要耗费很长时间来进行分析定位。我把这样的时代称之为 IT 基础设施服务的“农耕时代”。
IT 基础设施的管理要更加敏捷，提高变更吞吐量并同时提高稳定性，首先需要在基础设施的管理上实现这四个目标：
在此基础上，基础设施管理团队不再排队处理所有交付团队的请求，而是专注于提供一个基于标准化、脚本化、版本化和可视化方式管理基础设施的自助服务平台；组织授权给各产品交付团队利用平台的能力，以代码化的方式随时按需进行基础设施的准备和变更。缩短等待时间的同时，因为进入生产环境的基础设施变更已经以一致的方式在各个测试环境经过了验证，减少了人为手动操作可能引入的错误和遗漏，确保了各个环境的一致性；也让前期的自动化和手动测试更加可信，从而使得系统的稳定性也得到提高。这样一个模式我称之为 IT 基础设施服务的“云时代”。
对企业来说，从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。首先基础设施自助服务平台的建设需要投入；更重要的是，能够授权交付团队依赖自动化方式，而非人工来保障基础设施配置的质量，本身就需要管理者的思想转变。在我看来，一些管理者倾向于依靠人来控制，而不信赖经过反复验证的自动化过程，只有一个原因：人出了错可以追责和惩罚，而自动化过程出了错，不容易找到某个单一的人来担责，总不至于惩罚机器。
这里还有一个挑战不得不提，这种转变带来了传统运维模式下运维人员的技能要求转变，从以往手动的服务器操作，变成需要写 DSL、需要会编程。这必然影响到一群人的职业发展，这会给变革带来阻力；企业应当给这群人提供足够的培训，提供新的职业发展机会。
挑战三：部署与发布未分离
在产品交付团队追求频繁变更、提升交付吞吐量的时候，即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性，但由于周期短、频率高，要平衡投入产出的收益，在软件进入生产环境时，还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权，减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略，也就是没有将“部署”与“发布”分离。
“部署”和“发布”是两个不同的词，然而很多年里当提到将软件最后发布给用户使用时，两个词通常是混用的。为什么呢？以往，我们将软件发布给用户的手段很单一，就是将软件部署到生产环境跑起来，用户就可以用了，这两个词所代表的动作是同时完成的。
要让发布环节变得更加安全，就需要将这两个动作分离。“部署”即是让新的或修改的软件安装到目标环境上运行起来。这应当是一个技术决策，即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定，随时可以执行。这个动作过程中，技术团队重点关注的是：
而“发布”应当是一个业务决策，即允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放，经过一段时间的反馈信息收集，包括对系统稳定性和用户行为、喜好的观察，然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题，可以很快关闭新特性，或回退到旧的版本。在这个发布的过程中，交付团队和业务人员重点关注的是：
要实现这样的分离也是一个很大挑战。首先技术上，需要引入蓝绿部署、金丝雀发布，以及特性开关等手段；但要让每个团队都自己去建立这样一套机制成本太高，企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验；另一方面，这样的分离意味着重新定义了在软件部署发布过程中 IT 团队和业务人员的职责，需要 IT 和业务的紧密协作。
挑战四：缺少自助式的持续交付平台
DevOps 不仅仅是关于运维的自动化，同时也是关于开发、测试到运维各个职能围绕着每一次软件变更的紧密协作。在这个过程中，开发关心的是代码库、编译、构建；测试关心的是测试验证和测试环境；运维关心的是部署与发布控制、监控及支持等，各个环节的任务涉及到一系列工具构成的工具链。然而在对很多客户的调研中，我们发现普遍存在的现状是：
要在企业中实现 DevOps，有一定规模的 IT 企业非常需要给产品交付团队提供一个软件持续交付平台，让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成，包括所有自动化任务的配置和调度，支持信息可视化辐射，和內建一些必要的流程控制环节，例如操作权限和信息审计等。这样一个平台应纳入 IT 企业的战略性平台之一，其价值我认为有几点：
我们已经明显看到有不少互联网公司，比如阿里、腾讯在组织级提供类似这样的交付平台，然而更多 IT 企业还没有跟上。
还有一个更重要的关键词必须强调：“自助式”，这是平台设计的前提。我们在有些组织看到确实有类似的持续集成、持续交付平台。然而对这个平台的使用就如同前面提到的集中式 IT 基础设施服务一样，当交付团队需要为新的应用或服务建立一套新的自动化构建任务，或需要修改现有配置时，必须向平台的负责部门提出申请，由集中式的团队来帮助建立或修改配置。这些配置任务在集中式团队排队和等待，成为新的瓶颈。而产品交付团队自身始终不具备自动化能力，每次变更配置都不得不等待，导致需要的自动化任务跟不上架构的变化，任务失败后定位和解决问题很低效。最严重的是，团队的开发、测试人员根本不关心持续集成的执行和结果。这种模式下，平台其实远远发挥不了它应有的作用。
正确的做法是，平台团队只需要专注于提供自动化、自助式的持续交付平台，将产品交付团队当做自己的用户，听取使用反馈，持续演进；平台的设计必须要兼顾过程的标准化和流水线配置的灵活性；该团队不负责为各产品配置构建任务和流水线。这个配置工作应完全由各交付团队自己来完成，必须要具备“在需要修改配置时随时自己就可以修改”的能力。若没有该能力，组织就要提供培训和赋能。
挑战五：IT 架构耦合度高
上图左下方的这栋建筑，住着很多户。如果其中某一户对自己房子的布局和功能不满意，想要重新设计，这时一个房间的设计改动必然影响到其它住户，甚至可能危机整栋建筑。如果要想允许每一户人随时修改自己房子，不用太担心危及整个系统，缩短整个改动的周期，就需要像图中其它的小房子一样，彼此之间松耦合，靠简单、标准的道路来连接。
我们的 IT 系统也是一样，要实现 DevOps 的目标，更快地响应业务变化、提高交付吞吐量，每个子系统的粒度就要小，彼此之间松耦合，各自可以独立地进行测试和部署。很多企业多个系统因为耦合紧密不得不在同一时间点部署发布，为了确保每一次投产不出问题，需要投入大量人力来进行协调，投产部署过程要处理更大的复杂性，也更容易引入质量问题。
另一方面的影响是，若单一系统规模大、复杂性高、系统间耦合度高，就难以给予交付团队更大授权、实现开发团队自主运维。
DevOps 转型过程中的这一挑战在于，企业必须对现有 IT 系统进行解耦，将目前很多代码级依赖、数据库级依赖、或业务上的紧密依赖进行解耦，走向围绕业务领域边界建立的、靠轻量级服务和消息集成的服务化架构，要从设计上使得相互依赖的服务之间在升级时做到前向兼容，这是一个困难且耗时的过程；在这个过程中如果没有恰当的架构演进策略，缺少正确的方法引导，导致在服务拆分不合理，或缺少与之配套的服务治理能力，结果可能适得其反。这方面我们有过很多经验教训。ThoughtWorks 在实践 DevOps 的过程中，往往就伴随着大量的向微服务方向进行架构拆分和改造的工作，这一过程可能长达数年，逐步演进。但绝不能知难而退，投入必不可少。
挑战六：职能化组织中的开发运维部门墙
在多年以前，当传统企业的业务发展对数字化的依赖程度还不高，当管理者将 IT 系统的开发视为一种耗费人力但又价值并不高的非核心能力时，快速膨胀的软件研发队伍纷纷从原有的业务部门中拆分出来，成为了独立的部门或信息技术子公司；随着软件系统的复杂性越来越高，在专业化、流程化的考虑下，实现功能的开发、保障质量的测试和保障运行稳定的运维按职责和技能不同被拆分成了各自独立、相互制衡的部门。结果是各部门有了自己的目标，彼此不同甚至相互冲突，都着眼于各自内部优化；但很不幸地，在这个过程中企业的终极目标——最大化为用户/客户创造价值，这个必须要所有职能作为一个有机的整体运作才能实现的目标——却被弱化了。如下：
在这样的组织设计中，各部分在一致目标下的协作不足，而更加注重过程控制和相互制衡，要真正实现 DevOps 是不可能的。举几个例子：
在给一些企业评估其持续交付和 DevOps 能力时，普遍的情况是开发完成的工作进入生产环境要经过冗长的审批过程，审批基于一大堆文档；然而事实是（不要欺骗自己），那些并不了解产品细节和每一次变更细节的审批者，很少甚至从来没有在审批过程中发现过潜藏的问题，但这一过程却严重拉长了新版本上线获得用户反馈的周期；可以说，如果开发团队在提交文档时，某些文档忘了修改、还保持和上一次申请时一模一样，估计那些审批者也发现不了（或者根本就不会细看）；
另一个普遍的现实是前面提到过的，开发、测试和运维各自有一套工具来完成自己关心的任务，而这些工具相互割裂、重复建设，没有协作。不一致的工作方式和工具既降低了交付吞吐量，也给质量保障引入了更大风险。
让软件开发的最后一公里——运维环节变得更加敏捷和适应变化，开发和运维职能的紧密协作是 DevOps 运动的最核心思想。要达到该目标，企业如何为开发和运维建立一致的目标，通过协作而非制衡的方式来共同面对同时提升吞吐量和保障稳定性的挑战是企业实施 DevOps 最重要的命题！组织需要下面这样一种治理结构：
围绕着提供给用户的产品和服务，建立包括产品设计、开发、测试和运维在内的产品交付团队。这并不意味着组织一定要立即在汇报线的设置上做出改变，关键是如何设置目标和组织日常工作！除了各业务产品，同时集中的 IT 运维服务部门也应走向产品化，也就是从以往为各个业务产品提供运维支持，转向专注于为业务产品交付团队提供支撑其交付的平台，以及进行运维监控、运营分析的平台；可能也从用户支持统一体验的角度出发，给各业务产品提供面向最终用户统一的支持、服务热线和客户服务渠道。
这种转变对组织是很大的挑战，涉及到多年形成的治理结构的改变。首先需要各级管理者思想上的改变，从基于不信任前提的控制型、分化制衡型管理思想，转变为基于信任前提的服务型、协作型管理思想，这在 ThoughtWorks 提倡的适应性领导力中有深入探讨。这种转变从一开始，很难在组织大范围开展，建议的是先建立特区，再逐步试点扩大，最后实现突破；在转变的过程中必然会涉及到部门职责范围、绩效考评、人才能力模型等深层次的转变。这种转变需要组织管理者、转型推动者发挥领导力，展现出变革的魄力和执行力才能得以成功。
挑战七：缺少敏捷文化
前面谈到的强职能化组织结构也深刻地影响着一个组织的文化。在与曾经咨询过的一个客户探讨到如何进行 DevOps 转型时，开发和运维部门坐在一起探讨。大家就运维流程如何改变、自动化能力如何建设等都没有异议，然而自始至终无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？因为 DevOps 能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化审批和控制力，也认为不该为其承担责任。最终不了了之。
我认为，根本的问题出在文化，旧有的组织治理模式产生了各扫门前雪的官僚文化，没有责任共担，以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维，可能源自组织的绩效考评和激励制度。
现代关于“系统论”的研究已经在很多著作中强调，一个组织就是一个由人构成的复杂系统，组织中每一个人所能获得的信息是有限的（包括最高管理者也是），每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。如果系统发生失败，例如生产环境出现问题，这必然是由于系统各个部分相互作用（从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用）产生的结果，对其中任何局部进行惩罚无非是寻找替罪羊，有害而无益。这时候组织真正应该做的，是相信每一个人都已经做出了最大努力，将相关干系人拉到一起对问题的根因进行分析，找到能够有效避免类似问题再次出现的解决方案，并确保该方案得到实施，对其效果进行验证。
再举一个例子，Petrik 曾经在 DevOpsDays 上提到了一个 DevOps 的优秀实践：Chaos Monkey（混世魔猴）。这只自动化的猴子会每隔一段时间随机将生产环境服务器关闭，以此来测试生产环境的快速恢复能力，促使各团队提升系统的稳定性。我曾经和国内企业的开发、运维部门讨论过这个实践，有趣的是无论开发还是运维都跳出来反对该实践，认为无法落地。如果没有这只“猴子”，大家可以给领导讲自己的系统很稳定（只要没出问题）；然而这只“猴子”可能会随时暴露出自己的系统并不像自己所宣称的那样稳定，会降低自己在上级心目中的“有能力”印象，随之而来的可能就是问责、惩罚。这样的文化下，大家真正关心的是如何给领导“表现”，而不是在真正的系统稳定性上追求卓越。
真正能够实现 DevOps 的组织，我们认为需要具备下面这样一些文化：
总结
无论是组织治理结构、管理流程、工程技术能力还是文化特征，DevOps 运动都和精益产品开发、敏捷宣言所倡导的理念一致。我认为一个组织如果没有充分经历过敏捷文化的熏陶，也很难实现 DevOps 的目标，充其量在自动化工具和技术能力上有所提升，收益很有限。
因此我们不应当将 DevOps 作为一个孤立的运动去看待，更不能仅仅从工具角度去实施，而是应当将 DevOps 作为企业在数字化进程中为追求创新和快速市场响应、为提升组织适应力所进行的精益敏捷组织转型的一部分，这是一项系统工程。 尽管挑战重重，只要管理者首先从自身的管理思想出发做出改变，从组织小范围开始，将各种职能的人员聚拢到一起，设置共同的愿景和目标，打破束缚，给予足够授权，以紧密协作、责任共担的方式共同面对挑战，就能取得成功。然后再将小范围的经验在更大的范围逐步扩散，并适时地对企业深层次治理模式做出调整，就能够在整个企业范围内产生积极影响力，带来组织效能的巨大提升。
更多精彩商业洞见，请关注微信公众号：ThoughtWorks 商业洞见
姚安峰，ThoughtWorks 咨询师，08 年起开始致力于敏捷的践行和推广，理论与实践跨越敏捷、精益、持续交付和 DevOps 全流程各领域，帮助各行业客户采纳优秀且与企业环境相适应的管理和技术实践交付高价值、高质量产品，提升创新能力，推动持续改进。主导翻译了著作《精益企业》。
相关文章
