企业实施DevOps转型面临的七大挑战——思特沃克姚安峰

企业实施DevOps转型面临的七大挑战——思特沃克姚安峰DevOps这个词在近年来可谓大火。从2014年底笔者开始给一些企业做持续交付/DevOps相关的评估和咨询，似乎每个企业都表示想要推行DevOps，或者说他们正在做DevOps。这把火蔓延的速度远远超过当年敏捷在IT行业的传播。然而有些企业管理者对DevOps的认知让我们意识到，由于各种有意或无意的因素，这个概念不幸地成为了一个让人困惑的buzzword……什么是DevOps？这里笔者想列出四种我们在市场上、企业咨询以及社区交流过程中接触到的认知：1、一些企业的运维部门找我们，说要搞DevOps。帮他们约开发部门的同事一起来沟通，却得到类似于“不用管他们，我们自己搞……”的回复。再问那打算搞啥呢？答案可能是“我们想谈谈自动化运维……”。2、另一种认知是，敏捷宣言提出了“业务和开发要紧密协作，拥抱变化，将变化视为提升价值的机会而非麻烦。”那么DevOps则是将敏捷思想向运维延伸，通过开发和运维的紧密协作，让交付的最后一公里也能拥抱变化，兼顾吞吐量和稳定性。3、进一步，有些企业提出了自运维“No-Ops”理念，让运维的职能融入产品交付团队，由团队自主、自助地完成部署发布，同时自己承担线上问题支持等工作，完全让运维工作去中心化，实现“Whobuildit,whorunit”。4、我们还看到，一些咨询或解决方案厂商的宣传将DevOps刻画成了一个全新的、从设计、需求到发布运维端到端的研发体系，似乎有了DevOps这把榔头，软件研发的各种问题都解决了。有了DevOps，苦逼的程序员们就迎来解放了...作为企业管理者，要在组织中引入DevOps并推动变革，首先要对DevOps的目标有清晰的认识，并明确DevOps在自己企业的上下文中意味着什么。笔者个人还是比较反对一些厂商将DevOps吹得太大，但这也绝不仅仅是运维单方面的目标。DevOps运动本质上是关于开发（含测试）和运维的协作，在“为用户创造最大化价值”的一致目标下，让软件交付给用户并获得反馈的过程更加敏捷。至于要不要将开发运维一体化，则取决于具体产品的特征，在不同场景下可以有不同的协作模式。DevOps行业报告提出了两个顶层的用于衡量IT组织效能的指标：吞吐量和稳定性。在一些人看来，这两个目标就像鱼和熊掌不可兼得。追求交付吞吐量，就会带来更大的不稳定性和风险；而传统运维管理以稳定性为目标，就必然牺牲对变化的响应力。之所以会有这样的悲观认知，是因为仅仅站在当前的时空看待问题，而无法超越自己的能力局限。企业管理者需要理解，进行DevOps转型，就是要超越自己的能力局限，超出当前的时空看问题，通过组织设计、过程改进和工程技术的提升让组织能力上升到一个新的维度，我们完全可以做到同时提高IT交付的吞吐量和稳定性，而不是在两者之间取舍平衡。然而，要突破自身的能力局限，这并非易事。下面谈到的实施DevOps过程中的七大挑战中的每一个都需要组织下决心投入，并耐心等待回报，没有足够的认知转变和卓越领导力难以实现。挑战一：自动化测试投入不足，收益低敏捷宣言自提出时，就已经将自动化测试作为敏捷、极限编程的核心实践来强调。然而这么多年过去了，在组织中真正有效进行自动化测试的并不多，各种问题都在影响着组织和团队对自动化测试的信心。要想同时提升吞吐量和稳定性，以自动化替代手工方式快速、频繁的对软件质量进行验证是首要的手段。如果说在以往谈论敏捷开发的时候，自动化测试是对团队的较高要求，那么到了DevOps时代，这就是最基本的入门要求。毫不夸张的说，如果软件系统没有一套较完善的自动化测试体系，就请不要谈DevOps了。最直接的问题是投入不足。很多管理者意识里是将自动化测试看做一项额外的、可有可无的任务。他们关注的是短期的项目管理目标，而不是长期的产品持续演进，往往只有进度压力不大的时候才投入人力来做一做，或者单独聘请一个团队来补充测试用例，然后离开，而不是作为开发团队交付软件产品的一部分。这样的模式很难产生一套长期有效的测试套件，反过来进一步削弱了管理者对其进行投入的信心。另外常见的一些问题包括：1、缺乏对自动化测试策略的正确认知，过多集中在界面上做测试，缺少单元测试和API测试。界面功能测试案例的开发和维护成本高，执行速度慢；想想上千个案例全部执行完可能需要跑上半天、一天，然后有几十个案例因为环境或网络问题而执行失败，却不是因为代码问题。结果是我们看到不少团队从来没有一次将所有案例全量执行过，只能每次手动挑选一部分案例来跑。2、缺乏一套独立的自动化测试环境，而是和手动测试共用一套环境。这种做法一方面会导致自动化测试和手动测试在资源和测试数据上相互影响，使得测试不稳定；另一方面自动化测试过多依赖外部集成环境，缺少必要的依赖隔离，使得测试案例执行不稳定、执行效率低。3、自动化测试、手动测试和生产等各环境不一致，使得自动化测试的结果不够可信。4、由测试人员或单独的团队来写自动化测试，而不是让开发人员写。这首先导致开发人员在设计和编码时很少考虑为了更高效稳定的自动化测试进行优化，加大了测试开发的难度；其次测试人员必须等到开发基本编码完成了才能开始写测试案例，并且需要请开发人员讲解API或界面元素的设计，这是一个低效的过程，浪费时间。5、没有将自动化测试纳入持续交付流水线自动化地频繁执行。我们看到不少团队是在完成手动测试后、上线之前选择性地执行自动化测试案例来进行回归；这样的用法没有最大化其价值，对质量的反馈速度太慢。要解决以上问题，并产生一套有效的自动化测试套件是一个巨大挑战，需要管理者和团队转变质量意识；需要企业从项目化的管理转向产品化的管理，人们才能真正长远地去考虑对自动化测试的投资；需要影响业务人员在需求容量上的期望，为书写自动化测试提供时间。挑战二：高度集中的IT基础设施服务在传统模式下，像服务器申请、配置变更等IT服务是由高度集中的基础设施管理团队负责。产品交付团队需要向集中的IT服务团队提出申请；而该团队往往承接着来自很多交付团队的需求，于是只能将请求进行排队依次处理，并且主要依靠手动处理；结果是交付团队不得不长时间等待，才能得到所需资源。这个过程中的手动操作，使得经过一段时间后，基础设施的配置变成了一个黑洞，没人能够说得清各个服务器之间的状态差异，当问题出现时需要耗费很长时间来进行分析定位。笔者把这样的时代称之为IT基础设施服务的“农耕时代”。IT基础设施的管理要更加敏捷，提高变更吞吐量并同时提高稳定性，首先需要在基础设施的管理上实现这四个目标：1、标准化2、脚本化3、版本化4、可视化在此基础上，基础设施管理团队不再排队处理所有交付团队的请求，而是专注于提供一个基于标准化、脚本化、版本化和可视化方式管理基础设施的自助服务平台；组织授权给各产品交付团队利用平台的能力，以代码化的方式随时按需进行基础设施的准备和变更。缩短等待时间的同时，因为进入生产环境的基础设施变更已经以一致的方式在各个测试环境经过了验证，减少了人为手动操作可能引入的错误和遗漏，确保了各个环境的一致性；也让前期的自动化和手动测试更加可信，从而使得系统的稳定性也得到提高。这样一个模式笔者称之为IT基础设施服务的“云时代”。对企业来说，从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。首先基础设施自助服务平台的建设需要投入；更重要的是，能够授权交付团队依赖自动化方式，而非人工来保障基础设施配置的质量，本身就需要管理者的思想转变。在笔者看来，一些管理者倾向于依靠人来控制，而不信赖经过反复验证的自动化过程，只有一个原因：人出了错可以追责和惩罚，而自动化过程出了错，不容易找到某个单一的人来担责，总不至于惩罚机器。这里还有一个挑战不得不提，这种转变带来了传统运维模式下运维人员的技能要求转变，从以往手动的服务器操作，变成需要写DSL、需要会编程。这必然影响到一群人的职业发展，这会给变革带来阻力；企业应当给这群人提供足够的培训，提供新的职业发展机会。挑战三：部署与发布未分离在产品交付团队追求频繁变更、提升交付吞吐量的时候，即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性，但由于周期短、频率高，要平衡投入产出的收益，在软件进入生产环境时，还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权，减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略，也就是没有将“部署”与“发布”分离。“部署”和“发布”是两个不同的词，然而很多年里当提到将软件最后发布给用户使用时，两个词通常是混用的。为什么呢？以往，我们将软件发布给用户的手段很单一，就是将软件部署到生产环境跑起来，用户就可以用了，这两个词所代表的动作是同时完成的。要让发布环节变得更加安全，就需要将这两个动作分离。“部署”即是让新的或修改的软件安装到目标环境上运行起来。这应当是一个技术决策，即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定，随时可以执行。这个动作过程中，技术团队重点关注的是：部署过程自动化版本更新过程对用户无感知能够快速回滚。而“发布”应当是一个业务决策，即允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放，经过一段时间的反馈信息收集，包括对系统稳定性和用户行为、喜好的观察，然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题，可以很快关闭新特性，或回退到旧的版本。在这个发布的过程中，交付团队和业务人员重点关注的是：系统稳定性用户实验反馈要实现这样的分离也是一个很大挑战。首先技术上，需要引入蓝绿部署、金丝雀发布，以及特性开关等手段；但要让每个团队都自己去建立这样一套机制成本太高，企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验；另一方面，这样的分离意味着重新定义了在软件部署发布过程中IT团队和业务人员的职责，需要IT和业务的紧密协作。挑战四：缺少自助式的持续交付平台DevOps不仅仅是关于运维的自动化，同时也是关于开发、测试到运维各个职能围绕着每一次软件变更的紧密协作。在这个过程中，开发关心的是代码库、编译、构建；测试关心的是测试验证和测试环境；运维关心的是部署与发布控制、监控及支持等，各个环节的任务涉及到一系列工具构成的工具链。然而在对很多客户的调研中，我们发现普遍存在的现状是：1、开发、测试和运维各自有自己的一套工具来完成自己关心的任务，而这些工具既不相同，也不相互关联；软件包在不同工具之间的转移更多依靠人工来完成；2、由于工具上的割裂，每个人并不清楚同一个变更在其它角色哪里到底发生了什么，也不关心；3、由于从获取代码、编译、扫描、构建、测试、部署、发布到获得反馈的整个过程中涉及到很多工具的运用，很难有哪个团队能够靠自身力量在每一个环节都做得成熟。要在企业中实现DevOps，有一定规模的IT企业非常需要给产品交付团队提供一个软件持续交付平台，让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成，包括所有自动化任务的配置和调度，支持信息可视化辐射，和內建一些必要的流程控制环节，例如操作权限和信息审计等。这样一个平台应纳入IT企业的战略性平台之一，其价值笔者认为有几点：1、作为一个杠杆，在规模化的组织中撬动各个交付团队的持续交付/DevOps工程技术能力，将其快速拉到一个基线，大大降低各团队自己实施的成本；2、通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作；3、每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更；而经过了完整验证的变更可以随时部署出去；4、在组织级能够将一些必不可少的控制环节內建到自动化过程中，比如质量保障过程、过程度量、权限控制及过程审计信息等，从而弱化很多传统依靠人为检查的管理流程，实现精益敏捷的轻流程目标。我们已经明显看到有不少互联网公司，比如阿里、腾讯在组织级提供类似这样的交付平台，然而更多IT企业还没有跟上