企业实施DevOps的七大挑战_IT新闻

企业实施DevOps的七大挑战_IT新闻 发表时间:2017-10-13 11:35

点上方绿标即可收听朗读音频

双击文章内容从指定位置处朗读

  姚安峰

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

  什么是 DevOps?

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

  1. 一些企业的运维部门找我们说要搞 DevOps我请他们约开发部门的同事一起来沟通却得到类似于“不用管他们我们自己搞……”的回复再问那打算搞啥呢?答案可能是“我们想谈谈自动化运维……”
  2. 另一种认知是敏捷宣言提出了“业务和开发要紧密协作拥抱变化将变化视为提升价值的机会而非麻烦”那么 DevOps 则是将敏捷思想向运维延伸通过开发和运维的紧密协作让交付的最后一公里也能拥抱变化兼顾吞吐量和稳定性
  3. 进一步有些企业提出了自运维“No-Ops”理念让运维的职能融入产品交付团队由团队自主、自助地完成部署发布同时自己承担线上问题支持等工作完全让运维工作去中心化实现“Who build it, who run it”
  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 企业还没有跟上

  还有一个更重要的关键词必须强调“自助式”这是平台设计的前提我们在有些组织看到确实有类似的持续集成、持续交付平台然而对这个平台的使用就如同前面提到的集中式 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 全流程各领域帮助各行业客户采纳优秀且与企业环境相适应的管理和技术实践交付高价值、高质量产品提升创新能力推动持续改进主导翻译了著作《精益企业》

亲,眼睛太累了,关注exread(睿读吧)微信号,用耳朵“阅读”微信。

您可以将文章的链接或收藏的微信发送到睿读吧微信号中,我们会帮您转换成音频来听读,让您的眼睛休息一下吧!
查看来源 违规举报