企业实施DevOps的七大挑战从2014年底开始，我一直在为一些公司做持续交付/DevOps相关的评估和咨询。好像每个公司都想做DevOps，或者说他们都在做DevOps。这场火的蔓延速度远超当年敏捷在IT行业的蔓延速度。然而，一些业务管理者对DevOps的认知让我们意识到，由于种种有意或无意的因素，这个概念不幸成为了一个令人困惑的流行语……什么是DevOps？这里我想罗列一下我们在市场、业务咨询、社区交流中遇到的四个：一些公司的运维部门找到我们，说要搞DevOps。我让他们请开发部的同事来跟他们交流，得到的回复是类似“别管他们，我们自己来……”。然后问你要做什么？答案可能是“我们想谈谈自动化运维……”。另一种认知是敏捷宣言提出“业务和开发应该紧密合作，拥抱变化，把变化看作是增加价值的机会而不是麻烦”。那么DevOps将敏捷思维延伸到运维，通过开发和运维的紧密配合，让交付的最后一公里拥抱变化，兼顾吞吐量和稳定性。更进一步，一些公司提出了自运维“No-Ops”的概念，将运维的职能整合到产品交付团队中，团队可以独立自主完成部署发布，并在同时自己承担线上问题支持，完全让运维工作去中心化，实现“谁建，谁跑”。我们也看到一些咨询或解决方案厂商的宣传将DevOps描绘成一个全新的从设计、需求到发布运维的端到端的研发体系。似乎有了DevOps这一锤，软件研发中的各种问题都迎刃而解了。有了DevOps，辛勤工作的程序员将得到解放……作为企业管理者，要在组织中引入DevOps，推动变革，首先必须对DevOps的目标有清晰的认识，清楚地了解DevOps在组织中的作用贵公司在的背景下意味着什么。我反对一些厂商过分吹嘘DevOps，但这不仅仅是运维的单方面目标。DevOps运动本质上是关于开发（包括测试）和运维的协作。在“为用户创造最大价值”的一贯目标下，将软件交付给用户并获得反馈的过程更加敏捷。至于开发运维是否一体化，要看具体产品的特点，不同的场景可以采用不同的协作模式。DevOps行业报告提出了两个衡量IT组织绩效的顶级指标：吞吐量和稳定性。对某些人来说，这两个目标就像是两全其美。追求交付吞吐量会带来更大的不稳定性和风险；而传统的运维管理以稳定为目标，必然会牺牲对变化的响应能力。之所以会有如此悲观的认知，是因为我们只从当下的时空来看问题，而无法超越自身能力的局限。业务管理者需要明白，DevOps转型是要超越自身能力的局限，超越当下的时空，通过组织设计、流程改进、工程技术，将组织能力提升到一个新的维度。我们可以做到同时提高IT交付的吞吐量和稳定性，而不是在两者之间选择一个平衡点。不过，想要突破自身能力的限制，并不是一件容易的事情。下面讨论的实施DevOps的七个主要挑战中的每一个都需要组织承诺、承诺并耐心等待回报。没有足够的认知转变和出色的领导力，这是很难实现的。挑战一：自动化测试投入不足，回报低自敏捷宣言提出以来，自动化测试一直被强调为敏捷和极限编程的核心实践。然而，这么多年过去了，真正有效实施自动化测试的组织并不多，各种问题正在影响组织和团队对自动化测试的信心。要同时提高吞吐量和稳定性，用自动化代替人工方法是快速、频繁地验证软件质量的主要手段。如果说过去谈敏捷开发时自动化测试是对团队更高的要求，那么在DevOps时代，这是最基本的入门要求。毫不夸张的说，如果软件系统没有比较完善的自动化测试体系，请不要谈DevOps。最紧迫的问题是投资不足。许多管理人员有意识地将自动化测试视为一项额外的、可有可无的任务。他们专注于短期项目管理目标，而不是长期的产品持续发展。他们往往只在进度压力不大的时候才投入人力去做，或者单独聘请一个团队补充测试用例然后离开，而不是作为交付软件产品的开发团队的一部分。这样的模型很难产生长期有效的测试套件，进而进一步削弱管理者对其投资的信心。其他一些常见的问题包括：缺乏对自动化测试策略的正确理解，过于关注接口测试，缺乏单元测试和API测试。接口功能测试用例开发维护成本高，执行速度慢；认为可能需要半天或者一天的时间把几千个case全部跑完，然后几十个case因为环境或者网络问题执行失败，而不是因为代码问题。结果，我们看到很多团队从来没有一次性执行过所有的案例，每次只能手动选择一部分案例来运行。它没有独立的自动化测试环境，而是与人工测试共用一个环境。一方面，这种做法会导致自动化测试和手工测试在资源和测试数据上相互影响，导致测试不稳定；另一方面，自动化测试过于依赖外部集成环境，缺乏必要的依赖隔离，导致测试用例执行不稳定，执行效率低。自动化测试、手动测试和生产环境之间的不一致导致自动化测试的结果不可靠。自动化测试由测试人员或独立团队编写，而不是由开发人员编写。这首先导致开发人员在设计和编码时很少考虑优化更高效、更稳定的自动化测试，增加了测试开发的难度；其次，测试人员必须等到开发的基本编码完成后，才能开始编写测试用例，而且还需要请开发人员解释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能力有限，构建需要一个过程，开发团队不敢承诺承担全部责任；而运维团队也认为不应该因为弱化了审批和管控而被追究责任。最后什么也没发生。在我看来，根本问题出在文化上。旧的组织治理模式产生了一种扫门的官僚文化，没有责任分担，出现问题要问责的文化。这种文化可能源于惯性的功能性思维，也可能源于组织的绩效考核和激励制度。现代“系统论”研究在很多著作中都强调，组织是由人组成的复杂系统，组织中每个人所能获得的信息是有限的（包括高层管理者）。个人或团队只能根据有限的经验和有限的信息做出决策和行动。如果系统出现故障，比如生产环境出现问题，那一定是系统各个部分相互作用的结果（从idea提出到软件生产的各个环节之间的相互作用，以及系统与其他系统之间的相互作用）系统）。惩罚无非是找替罪羊，害多于利。这个时候，组织真正应该做的是相信每个人都已经尽了最大的努力，将相关利益相关者聚集在一起，分析问题的根本原因，找到能够有效防止类似问题再次发生的解决方案。并确保方案得到实施，效果得到验证。再举个例子，Petrik曾经在DevOpsDays上提到过一个DevOps的优秀实践：ChaosMonkey。这只自动化猴子会定时随机关闭生产环境服务器，以测试生产环境的快速恢复能力，并提示各团队提高系统的稳定性。我和国内企业的开发和运维部门讨论过这种做法。有意思的是，无论是开发还是运维，都跳出来反对这种做法，认为无法实施。没有这个“猴子”，每个人都可以告诉领导，他们的系统是稳定的（只要不出问题）；然而，这只“猴子”随时可能暴露出他们的系统并不像它声称的那样稳定，降低自己在上级心目中的“能干”印象可能会导致问责和惩罚。在这样的文化中，大家真正关心的是如何“表演”领导者，而不是在真正的系统稳定中追求卓越。我们认为，真正能够实现DevOps的组织，需要具备以下文化：宣言。我认为，如果一个组织没有充分体验到敏捷文化的影响，是很难实现DevOps的目标的。充其量只是提高自动化工具和技术能力，收益非常有限。因此，我们不应该把DevOps看成是一个孤立的运动，更不能从工具的角度去实施，而应该把DevOps看成是企业在数字化过程中追求创新、快速响应市场、提升组织适应能力的追求。Lean-Agile组织转型的一部分，它是一个系统工程。虽然挑战很多，但只要管理者首先从自身的管理思想上做出改变，从小组织做起，把各个职能部门的人聚集在一起，设定共同的愿景和目标，打破束缚，给予足够的授权，紧密合作通过以协作、分担责任的方式共同面对挑战，可以取得成功。然后逐步将小范围内的经验推广到更大范围内，对企业的深层次治理模式进行适时调整，可以对整个企业产生积极的影响，带来组织效能的巨大提升。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
