DevOps这个效能管理体系，这2年在互联网圈里越来越火，其实，这里边涵盖的各个实践，不都是全新的事物，但把它们总结成一个体系，却是近年来的成果，那么，如何认知DevOps全貌及本质，小编本着自我学习的态度，以专辑系列形式，持续整合最新业界动态及案例，方便查阅与运用，感兴趣的朋友，大家根据情况实践起来吧。
那么，在做DevOps实施过程中，有哪些挑战，看看行业内的经验及总结：
注：内容摘取于网络，如有不妥请联系删除。
认知误区
DevOps就是自动化运维，运维部门独立就能搞定。
DevOps是敏捷实践的扩展，通过开发和运维协作，兼顾吞吐量和稳定性。
将运维职能分解到产品产品研发团队，谁开发谁编译谁部署谁发布谁监控。
DevOps实现端到端研发体系，能解决各种问题。
DevOps，其实是为了实现价值最大化为出发点，开发测试运维相互协作实将这个过程更敏捷。没有统一的标准，各个公司各个业务会有不同的实现策略
2018年DevOps动态报告用于衡量IT组织效能的2个指标：吞吐量和稳定性。但在实施过程中，普遍认为两个指标是无法完美兼顾和平衡，往往是相对立的；其实，这个理解是不对的，只能说实现完美兼顾是有很大的挑战与突破，需要组织有足够的认知、下决心转变、配套的卓越领导力才可能实现，下面详细分7大维度具体分析；
自动化测试认知不足与投入产出比未被认可
自动化测试，是敏捷经典实践，是解决手工效能，加快质量验证效率&效果，同时提升吞吐量和稳定性首要前提，但行业内真正有效实现自动化测试的案例不多，组织对自动化测试在产品持续演进中的价值未被认可或认知不足。一般在保障工作任务及进度压力不大的时候会投入人力来做，不会作为产品交付实施过程中的必备环节。另外，即使有时间和充足的支持，也很难做到长期有效与可持续扩充。
要做到自动化测试的普及与应用，需要管理者和团队质量意识转变，长远的考虑自动化测试的投入价值、并且还要留出相应的实现时间于产品实现过程中。
普遍情况举例：
界面测试普遍，单元测试和API测试涉猎较少。
功能测试case,开发和维护成本高，执行速度慢；受环境、网络问题影响，失败率高，往往不是代码本身的问题。全量case全部执行的不多，往往手动挑选部分案case。
自动化测试缺乏独立环境：一般与手动测试共用一套。
两者在环境资源、测试数据上相互影响导致测试不稳定。
自动化测试过多依赖外部集成环境，缺少必要的依赖隔离，使得测试案例执行不稳定、执行效率低。
测试环境不一致，导致测试结果偏差大，可靠性差。
开发人员参与度不足，加大了测试开发自动化测试case的难度。
测试必须等到开发基本编码完成了才能开始写测试case。
测试需要找开发讲解API或界面设计元素，低效且浪费时间。
没有将自动化测试纳入持续交付流水线，自动化地频繁执行。
一般，完成手动测试后上线之前，筛选执行部分自动化测试case回归，这样的用法没有发挥最大价值且质量反馈速度太慢。
IT基础设施服务高度集中
基础设施，如服务器申请、配置变更等IT服务，一般由独立的团队负责管理，各产品交付团队的资源申请&需求被排队和积压的情况多见，另外，手动配置管理不当，会出现各个服务器之间的状态差异不清晰不透明等问题，增加了问题分析定位的诊断时间。
如何将IT基础设施服务环节更敏捷起来，提高变更吞吐量并同时提高稳定性，需要在以下5个方向上努力：
标准化
可视化
版本化
脚本化
自助化
从这种基础设施管理集中式控制向去中心化授权的转变也是一个巨大挑战。
1.基础设施自助服务平台的建设需要投入。
2.交付团队依赖自动化方式而非人工，来保障基础设施配置的质量这种机制需要授权。
3.在依靠人来控制和自动化管理之间取舍，阻碍因素：人出了错好追责和惩罚，而自动化过程出了错很难找到到某个单一的人或者环节来担责。
4.传统运维模式下运维人员的技能要求转变，从以往手动的服务器操作，变成需要写DSL、需要会编程。会影响运维人员的职业发展，企业应当给这群人提供足够的培训，提供新的职业发展机会。
部署与发布未分离
在产品交付团队追求频繁变更、提升交付吞吐量的时候，即便进行了严格的同行评审、通过了完善的自动化测试、确保了基础设施环境的一致性，但由于周期短、频率高，要平衡投入产出的收益，在软件进入生产环境时，还是有风险存在。因此一些管理者无论如何不敢在部署发布流程上进行放权，减少审批控制。这种不安全感是来自传统的发布过程缺少一种安全性策略，也就是没有将“部署”与“发布”分离。
“部署”：让新的、修改的软件安装到目标环境上运行起来。这应当是一个技术决策，即是否执行这个动作应当完全由技术团队依靠对变更进行的同行评审和测试来决定，随时可以执行。这个动作过程中，技术团队重点关注的是：
部署过程自动化
版本更新过程对用户无感知
能够快速回滚。
“发布”：应当是一个业务决策，允许业务和产品人员来控制新特性对用户的可见性。首先对受控的小范围用户开放，经过一段时间的反馈信息收集，包括对系统稳定性和用户行为、喜好的观察，然后决定是否将其开放给更大范围的用户。如果系统存在质量或设计问题，可以很快关闭新特性，或回退到旧的版本。在这个发布的过程中，交付团队和业务人员重点关注的是：
系统稳定性
用户实验反馈
要实现这样的分离也是一个很大挑战。
1.引入蓝绿部署、金丝雀发布、特性开关等手段；
2.每个团队都自己去建立这样一套机制成本太高，企业需要从平台战略的角度提供这样一种便捷的能力来实现灵活可配置的在线受控实验；
3.这样的分离意味着重新定义了在软件部署发布过程中，IT团队和业务人员的职责，需要IT和业务的紧密协作。
缺少自助式的持续交付平台
DevOps是关于开发、测试、运维各个职能围绕着每一次软件变更的紧密协作。开发关心的是代码库、编译、构建；测试关心的是测试验证和测试环境；运维关心的是部署与发布控制、监控及支持等，各个环节的任务涉及到一系列工具构成的工具链。
行业普遍现状：
开发、测试、运维各自有自己的一套工具来完成自己关心的任务，这些工具既不相同也不相互关联；软件包在不同工具之间的转移更多依靠人工来完成；
由于工具上的割裂，每个人并不清楚同一个变更在其它角色哪里到底发生了什么，也不关心；
由于从获取代码、编译、扫描、构建、测试、部署、发布到获得反馈的整个过程中涉及到很多工具的运用，很难有哪个团队能够靠自身力量在每一个环节都做得成熟。
要在企业中实现DevOps，有一定规模的IT企业非常需要给产品交付团队提供一个软件持续交付平台，让软件从代码提交构建到交付给用户的整个过程得以在这个平台上完成，包括所有自动化任务的配置和调度，支持信息可视化辐射，和內建一些必要的流程控制环节，例如操作权限和信息审计等。这样一个平台应纳入IT企业的战略性平台之一。
价值点：
作为一个杠杆，在规模化的组织中撬动各个交付团队的持续交付/DevOps工程技术能力，将其快速拉到一个基线，大大降低各团队自己实施的成本。
通过统一的部署流水线将从代码提交到交付给用户的整个过程高度可视化出来，信息透明；让开发、测试和运维以高度一致的方式工作在同一个流水线上，真正建立起协作。
每一次的软件变更在这个完整的流水线中得到充分的验证，尽早发现有缺陷的变更；而经过了完整验证的变更可以随时部署出去。
在组织级能够将一些必不可少的控制环节內建到自动化过程中，比如质量保障过程、过程度量、权限控制及过程审计信息等，从而弱化很多传统依靠人为检查的管理流程，实现精益敏捷的轻流程目标。
“自助式”，这是平台设计的前提。有些公司确实有类似的持续集成、持续交付平台。然而对这个平台的使用却仍集中式的进行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作为企业在数字化进程中为追求创新和快速市场响应、为提升组织适应力所进行的精益敏捷组织转型的一部分，这是一项系统工程。 尽管挑战重重，只要管理者首先从自身的管理思想出发做出改变，从组织小范围开始，将各种职能的人员聚拢到一起，设置共同的愿景和目标，打破束缚，给予足够授权，以紧密协作、责任共担的方式共同面对挑战，就能取得成功。然后再将小范围的经验在更大的范围逐步扩散，并适时地对企业深层次治理模式做出调整，就能够在整个企业范围内产生积极影响力，带来组织效能的巨大提升。
