企业实施DevOps的七大挑战

2017-10-11 本文已影响588人 ThoughtWorks

DevOps这个词在近年来可谓大火。从2014年底我开始给一些企业做持续交付/DevOps相关的评估和咨询，似乎每个企业都表示想要推行DevOps，或者说他们正在做DevOps。这把火蔓延的速度远远超过当年敏捷在IT行业的传播。然而有些企业管理者对DevOps的认知让我们意识到，由于各种有意或无意的因素，这个概念不幸地成为了一个让人困惑的buzz word……

什么是DevOps？

这里我想列出四种我们在市场上、企业咨询以及社区交流过程中接触到的认知：

一些企业的运维部门找我们，说要搞DevOps。我请他们约开发部门的同事一起来沟通，却得到类似于“不用管他们，我们自己搞……”的回复。再问那打算搞啥呢？答案可能是“我们想谈谈自动化运维……”。
另一种认知是，敏捷宣言提出了“业务和开发要紧密协作，拥抱变化，将变化视为提升价值的机会而非麻烦。”那么DevOps则是将敏捷思想向运维延伸，通过开发和运维的紧密协作，让交付的最后一公里也能拥抱变化，兼顾吞吐量和稳定性。
进一步，有些企业提出了自运维“No-Ops”理念，让运维的职能融入产品交付团队，由团队自主、自助地完成部署发布，同时自己承担线上问题支持等工作，完全让运维工作去中心化，实现“Who build it, who run it”。
我们还看到，一些咨询或解决方案厂商的宣传将DevOps刻画成了一个全新的、从设计、需求到发布运维端到端的研发体系，似乎有了DevOps这把榔头，软件研发的各种问题都解决了。有了DevOps，苦逼的程序员们就迎来解放了...

作为企业管理者，要在组织中引入DevOps并推动变革，首先要对DevOps的目标有清晰的认识，并明确DevOps在自己企业的上下文中意味着什么。我反对一些厂商将DevOps吹得太大，但这也绝不仅仅是运维单方面的目标。DevOps运动本质上是关于开发（含测试）和运维的协作，在“为用户创造最大化价值”的一致目标下，让软件交付给用户并获得反馈的过程更加敏捷。至于要不要将开发运维一体化，则取决于具体产品的特征，在不同场景下可以有不同的协作模式。

缺乏一套独立的自动化测试环境，而是和手动测试共用一套环境。这种做法一方面会导致自动化测试和手动测试在资源和测试数据上相互影响，使得测试不稳定；另一方面自动化测试过多依赖外部集成环境，缺少必要的依赖隔离，使得测试案例执行不稳定、执行效率低。

自动化测试、手动测试和生产等各环境不一致，使得自动化测试的结果不够可信。

由测试人员或单独的团队来写自动化测试，而不是让开发人员写。这首先导致开发人员在设计和编码时很少考虑为了更高效稳定的自动化测试进行优化，加大了测试开发的难度；其次测试人员必须等到开发基本编码完成了才能开始写测试案例，并且需要请开发人员讲解API或界面元素的设计，这是一个低效的过程，浪费时间。

没有将自动化测试纳入持续交付流水线自动化地频繁执行。我们看到不少团队是在完成手动测试后、上线之前选择性地执行自动化测试案例来进行回归；这样的用法没有最大化其价值，对质量的反馈速度太慢。

要解决以上问题，并产生一套有效的自动化测试套件是一个巨大挑战，需要管理者和团队转变质量意识；需要企业从项目化的管理转向产品化的管理，人们才能真正长远地去考虑对自动化测试的投资；需要影响业务人员在需求容量上的期望，为书写自动化测试提供时间。

挑战二：高度集中的IT基础设施服务

在传统模式下，像服务器申请、配置变更等IT服务是由高度集中的基础设施管理团队负责。产品交付团队需要向集中的IT服务团队提出申请；而该团队往往承接着来自很多交付团队的需求，于是只能将请求进行排队依次处理，并且主要依靠手动处理；结果是交付团队不得不长时间等待，才能得到所需资源。这个过程中的手动操作，使得经过一段时间后，基础设施的配置变成了一个黑洞，没人能够说得清各个服务器之间的状态差异，当问题出现时需要耗费很长时间来进行分析定位。我把这样的时代称之为IT基础设施服务的“农耕时代”。

IT基础设施的管理要更加敏捷，提高变更吞吐量并同时提高稳定性，首先需要在基础设施的管理上实现这四个目标：

标准化
脚本化
版本化
可视化

在此基础上，基础设施管理团队不再排队处理所有交付团队的请求，而是专注于提供一个基于标准化、脚本化、版本化和可视化方式管理基础设施的自助服务平台；组织授权给各产品交付团队利用平台的能力，以代码化的方式随时按需进行基础设施的准备和变更。缩短等待时间的同时，因为进入生产环境的基础设施变更已经以一致的方式在各个测试环境经过了验证，减少了人为手动操作可能引入的错误和遗漏，确保了各个环境的一致性；也让前期的自动化和手动测试更加可信，从而使得系统的稳定性也得到提高。这样一个模式我称之为IT基础设施服务的“云时代”。

对企业来说，从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。首先基础设施自助服务平台的建设需要投入；更重要的是，能够授权交付团队依赖自动化方式，而非人工来保障基础设施配置的质量，本身就需要管理者的思想转变。在我看来，一些管理者倾向于依靠人来控制，而不信赖经过反复验证的自动化过程，只有一个原因：人出了错可以追责和惩罚，而自动化过程出了错，不容易找到某个单一的人来担责，总不至于惩罚机器。

这里还有一个挑战不得不提，这种转变带来了传统运维模式下运维人员的技能要求转变，从以往手动的服务器操作，变成需要写DSL、需要会编程。这必然影响到一群人的职业发展，这会给变革带来阻力；企业应当给这群人提供足够的培训，提供新的职业发展机会。

挑战三：部署与发布未分离

在产品交付团队追求频繁变更、提升交付吞吐量的时候，即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性，但由于周期短、频率高，要平衡投入产出的收益，在软件进入生产环境时，还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权，减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略，也就是没有将“部署”与“发布”分离。

“部署”和“发布”是两个不同的词，然而很多年里当提到将软件最后发布给用户使用时，两个词通常是混用的。为什么呢？以往，我们将软件发布给用户的手段很单一，就是将软件部署到生产环境跑起来，用户就可以用了，这两个词所代表的动作是同时完成的。

要让发布环节变得更加安全，就需要将这两个动作分离。“部署”即是让新的或修改的软件安装到目标环境上运行起来。这应当是一个技术决策，即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定，随时可以执行。这个动作过程中，技术团队重点关注的是：

部署过程自动化
版本更新过程对用户无感知
能够快速回滚。

而“发布”应当是一个业务决策，即允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放，经过一段时间的反馈信息收集，包括对系统稳定性和用户行为、喜好的观察，然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题，可以很快关闭新特性，或回退到旧的版本。在这个发布的过程中，交付团队和业务人员重点关注的是：

系统稳定性
用户实验反馈

要实现这样的分离也是一个很大挑战。首先技术上，需要引入蓝绿部署、金丝雀发布，以及特性开关等手段；但要让每个团队都自己去建立这样一套机制成本太高，企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验；另一方面，这样的分离意味着重新定义了在软件部署发布过程中IT团队和业务人员的职责，需要IT和业务的紧密协作。

挑战四：缺少自助式的持续交付平台

DevOps不仅仅是关于运维的自动化，同时也是关于开发、测试到运维各个职能围绕着每一次软件变更的紧密协作。在这个过程中，开发关心的是代码库、编译、构建；测试关心的是测试验证和测试环境；运维关心的是部署与发布控制、监控及支持等，各个环节的任务涉及到一系列工具构成的工具链。然而在对很多客户的调研中，我们发现普遍存在的现状是：

开发、测试和运维各自有自己的一套工具来完成自己关心的任务，而这些工具既不相同，也不相互关联；软件包在不同工具之间的转移更多依靠人工来完成；
由于工具上的割裂，每个人并不清楚同一个变更在其它角色哪里到底发生了什么，也不关心；
由于从获取代码、编译、扫描、构建、测试、部署、发布到获得反馈的整个过程中涉及到很多工具的运用，很难有哪个团队能够靠自身力量在每一个环节都做得成熟。

要在企业中实现DevOps，有一定规模的IT企业非常需要给产品交付团队提供一个软件持续交付平台，让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成，包括所有自动化任务的配置和调度，支持信息可视化辐射，和內建一些必要的流程控制环节，例如操作权限和信息审计等。这样一个平台应纳入IT企业的战略性平台之一，其价值我认为有几点：

作为一个杠杆，在规模化的组织中撬动各个交付团队的持续交付/DevOps工程技术能力，将其快速拉到一个基线，大大降低各团队自己实施的成本；
通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作；
每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更；而经过了完整验证的变更可以随时部署出去；
在组织级能够将一些必不可少的控制环节內建到自动化过程中，比如质量保障过程、过程度量、权限控制及过程审计信息等，从而弱化很多传统依靠人为检查的管理流程，实现精益敏捷的轻流程目标。

我们已经明显看到有不少互联网公司，比如阿里、腾讯在组织级提供类似这样的交付平台，然而更多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作为企业在数字化进程中为追求创新和快速市场响应、为提升组织适应力所进行的精益敏捷组织转型的一部分，这是一项系统工程。
尽管挑战重重，只要管理者首先从自身的管理思想出发做出改变，从组织小范围开始，将各种职能的人员聚拢到一起，设置共同的愿景和目标，打破束缚，给予足够授权，以紧密协作、责任共担的方式共同面对挑战，就能取得成功。然后再将小范围的经验在更大的范围逐步扩散，并适时地对企业深层次治理模式做出调整，就能够在整个企业范围内产生积极影响力，带来组织效能的巨大提升。