DevOps 建设似乎已经成为了企业共识，但是何时建设、如何建设仍然是企业关心和头疼的问题。企业的技术、人才、业务达到何种程度才适合建设DevOps？建设过程中，从哪里先入手，又应该如何处理组织架构、原有技术栈与DevOps之间的矛盾？是否有DevOps建设的参考架构？建设完成之后，DevOps的下一步该如何发展？…为了解答以上问题，我们采访了 15 年的技术老兵、现任华为云 DevCloud 首席解决方案架构师王金伦。他将在QCon全球软件大会（上海站）2019 分享题为《DevOps转型中工程效率提升》的话题。

DevOps，是Development和Operations的组合词，是指一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。据中国信通院（CAICT）发布的《中国DevOps现状调查报告（2019年）》显示：“超半数企业使用DevOps的敏捷工程实践管理开发项目，近6成企业选择编码规范、单元测试和持续集成。”这说明，DevOps已经成为企业软件研发的主流，被众多企业所采用。

虽然企业都期望能够通过DevOps获得更多的价值，并有意愿积极尝试，但是DevOps的成功实践仍然是个难题。据《中国DevOps现状调查报告（2019年）》的调查结果显示：“实际能够真正成功实施DevOps的企业仅有31.65%，另外，还有接近四成（41.13%）的企业居然不清楚自己是否成功实施DevOps。”

这个结果虽然在意料之外，但也在情理之中，毕竟DevOps实践之路，成功的方法很多，但是失败的方式更多。本文将聚焦 DevOps 建设过程中的矛盾、难点，让大家的DevOps建设之路更加顺畅。

DevOps中的矛盾与冲突

任何新事物的出现和推行，必定时刻伴随着矛盾与冲突，DevOps也不例外。DevOps甫一出现，很多人就开始担心：“传统运维将被DevOps干掉？”没错，DevOps的第一个矛盾冲突很快就显现了，那就是传统运维和DevOps之间的矛盾，有人认为这两者之间是水火不相容，那实际情况是如何呢？

针对传统运维和DevOps，王金伦是这样理解的：“从本质上来讲，运维（Operations）是综合运用人员、流程与工具平台等对IT基础设施和应用系统进行管理，将平台与系统服务的价值按照一定的SLA持续地提供给内部或者外部客户。随着企业业务目标、IT基础设施、应用系统、运维理念、运维方法、运维工具平台的不断发展，运维会在不同的阶段或者从不同角度呈现一定的发展特征。”

“传统运维和自动化运维可以简单理解为业界在不同阶段或者从不同角度为运维打上的特征标签，它们各自具备不同的特征，例如传统运维通常具有被动、规范化低、自动化低等特征；自动化运维通常具有主动、规范化程度高、自动化程度高等特征。”

企业实施DevOps的合适节点

在很多人的印象中DevOps是一种先进的方法框架，使用DevOps能够给企业带来无限的好处，但事实是我们看到很多企业的DevOps实践并不成功，也有很多开发者抱怨DevOps就是个“累赘”。之所以会出现这种情况，绝大部分的原因都是企业根本没有做好实践DevOps的准备。那么，想要建设DevOps的企业应该具备哪些特质呢？

“理论上来讲，无论是大型企业还是中小型企业，无论是敏态还是稳态业务系统均可以采用DevOps相关的方法与实践。”王金伦表示，“企业在开展DevOps转型或者变革时，建议从业务敏捷性要求高的产品（例如企业面向终端用户提供的基于互联网的业务）入手，可以更加充分地体现DevOps的能力。当然DevOps的有效落地离不开人员技能、流程以及工具链平台的支撑，同时又与系统架构（例如微服务架构等）、系统依赖基础设施（例如云计算等）息息相关。因此企业应该在DevOps方法、微服务架构、云原生架构、云计算、自动化测试、持续集成、持续交付、灰度发布等技术上进行储备。当然企业最好不要希望运动式一夜之间完成这些储备，而应该参考DevOps实施框架，在软件交付的过程中逐渐进行技术储备，自然而然地落地DevOps方法与实践。”

DevOps实践与企业组织架构

在企业DevOps的建设过程中，组织架构的调整和员工职责的变动是始终存在的，尤其是Dev和Ops相关角色之间的变动。 DevOps Topologies曾经提出了9种有效的DevOps团队结构：

模型1：Dev与Ops无缝协作，适用于具有强技术领导力的组织。

模型2：完全共担Ops职责，适用于拥有单一的主要web产品或者服务的组织。

模型3：Ops即IaaS（平台），适用于拥有几个不同的产品或服务、一个传统的Ops部门或者应用全部运行在公有云上的组织。

模型4：DevOps作为外部服务，适用于运维经验不足的小型组织。

模型5：设定有效期的DevOps组，是模型1的前身。

模型6：DevOps布道师组，适用于Dev与Ops有疏远趋势的组织。

模型7：SRE组（Google模型），适应于用于高水平的工程师和成熟度的企业。

模型8：容器驱动协作，适应于容器可以很好地发挥作用的组织。

模型9：Dev和DBA协作，适应于拥有多个应用链接一个或者多个大型、中央式数据库的组织。

以上9个只是比较常见的DevOps团队的组织架构，但世界上没有完美的DevOps组织结构，王金伦建议：“组织结构的调整应该从组织的产品组合、技术领导力、团队人员技能水平、运作成本等角度进行综合考虑。建议企业尽可能围绕价值流建立跨功能自治团队，实现价值的持续交付，并随着DevOps实践成熟度的提升，持续地调整组织结构。”

当企业向DevOps转型时，企业中各部门人员的工作内容是否会跟随着发生变化呢？王金伦表示：“企业实践DevOps，并不会使得业务、需求、开发、架构、开发、测试、部署、运维等人员的核心工作内容发生太大的变化，不过工作方式可能会有所变化，例如业务人员应该有敏捷的思维，而不再是恪守传统的业务方法；运维人员应该更好地与开发人员协作，将运维需求纳入到产品待办事项中等等。”

DevOps与云平台

无论是基于云平台还是IDC，又或者是OpenShift，都可以搭建出的一套完整的DevOps环境，所以DevOps与云平台之间并不是充分必要的关系，双方互有联系，又彼此独立。那么，企业如何判断是否要在云平台中部署实践DevOps呢？

王金伦表示：“企业运维平台的部署方式（On Premises或Public Cloud）取决于企业的业务系统的部署方式（私有云、混合云或公有云）。在业务系统全部部署在公有云的情况下，运维平台建议部署在公有云上。在业务系统运行在私有云或者混合云场景下，运维平台的部署方式建议采用On Premises方式。”

如果本来是On Premises部署的运维平台现在想要上云，那么主要需要考虑数据安全性、运维通道速度等问题。上云之后，对于企业的组织架构与员工来讲，变化较小，不过需要熟悉公有云厂商的运维产品特性能力等。

DevOps的完整路径及技术选型

虽然每家企业都有各自的实际情况，无法照搬其它人的DevOps实践，但是我们可以有一个较为标准、完整的DevOps参考架构。

在王金伦看来，一个完整的理想的DevOps平台应该能够满足业务、需求、架构、开发、测试、部署、运维等角色在其上自主的完成相关工作，“DevOps平台应该提供项目管理、原型设计、源代码版本管理、代码质量分析、持续交付流水线、编译构建、测试管理、UI自动化测试、接口测试、性能测试、移动App测试、部署、发布、运维、Web IDE、文档管理、Wiki百科、开源镜像站等功能特性。”

从理论及实践上来讲，使用业界开源工具（例如Redmine、GitLab、Jenkins等）打造基本可用的DevOps平台，并不是一件特别困难的事情。但是想要做好DevOps平台的技术选型并不是一件易事，因为据XebiaLabs统计，DevOps 相关工具有15类，120种之多，种类繁多的同时，企业还要考虑可靠性、可用性、性能、安全、集成、持续升级、异构技术栈等问题。

王金伦以持续交付流水线、代码质量和移动App为例，详细介绍了如何做技术选型。

对于DevOps平台来讲，持续交付流水线是最为关键核心的。目前Gitlab、Jenkins、阿里云效、华为云 DevCloud都可以提供相关特性。对于流水线来讲，主要能力在于可视化任务编排能力（分层、并行/串行、人工介入、门禁等）、大规模并行调度能力等。如果企业使用开源软件，特别要关注对于大规模并行调度的支持能力。
对于软件交付来讲，开发者非常关注代码质量。现在不少企业使用SonarQube、Findbugs、Checkstyle、Infer等工具进行代码质量的检查，但是他们都不得不面临不同工具之间的相似规则如何归一、多个工具的检查结果如何统一等挑战。同时应用人工智能AI进行代码质量分析以及自动修复已经成为一种趋势，开源工具是否能够及时跟进以及跟进的质量如何，也是企业需要关注的。
移动 App 基本上成为各个企业对外服务系统的标配。如何兼容不同类型的移动终端，成为开发者极为头疼的问题。虽然移动终端提供了模拟器或者仿真器，但是真机兼容性测试仍然是不可或缺的一环。对于此种场景下，自建移动App测试平台并采购型号众多的移动终端几乎对于所有企业来讲都是很大的成本负担，企业可以考虑相关厂商提供的移动App兼容性测试服务。

DevOps实践的注意点

企业DevOps平台建设说起来容易，做起来难！王金伦认为在实践DevOps的过程中，企业应该特别关注以下三点：

首先，需要注意的就是组织架构、文化与行为等与DevOps契合度方面的问题。DevOps融合敏捷、精益、自治团队、分布式决策等理念，企业应通过顶层设计、实践社区（CoP）、组织变革等方式建立与DevOps相匹配的组织与文化。我们通常说DevOps变革是“一把手”工程，很大程度上就是组织与文化的变革必须高层推动，否则DevOps也就只能停留在纯粹的工具、工程方法等皮毛上，难以走得远，给企业带来可观的价值。

其次，企业会面临工程方法方面的挑战。目前DevOps并没有一以贯之的标准或者知识体系，因此企业应体系化地理解敏捷与DevOps，并形成一致认可的适合本企业的DevOps实施框架，这样才会更有效地提升能力。
在我们接触的很多软件企业中，他们并没有体系化的掌握Scrum方法，对Backlog、EPIC/Feature/Story、Scrum会议等都缺乏基本理解，因此，在进行敏捷项目管理时就遇到了很大的困难，更遑论DevOps整个体系了。华为云DevCloud推出的HE2E工作坊，基于HE2E DevOps实施框架与案例项目，以训战结合的方式，能够帮助企业更体系化地理解DevOps。
最后企业将面临的问题是如何打造端到端的一站式DevOps工具平台。企业可以从2+1（项目管理+源代码版本管理、持续交付流水线）能力来进行DevOps平台的打造。我们建议企业尽可能使用业界主流商业平台，在这些平台确实无法满足自己的核心需求的时候，再寻求自行搭建这条艰难的路。

AIOps是DevOps的下一步吗？

DevOps诞生于2009年项目经理兼敏捷实践者Patrick Debois主持的比利时会议，目前已有众多的企业在实践应用，借助DevOps，自动化程度得到提高，测试变得更加容易，部署速度更快。而智能化运维（AIOps）是在自动化的基础上，突出强调将人工智能等技术运用到运维的相关环节（例如根因分析、预测、故障恢复等），进一步提升运维的效率和效能。

那么AIOps会是DevOps的下一步吗？对此，王金伦认为：“从理论以及业界实际上来讲，AI将成为Ops或者DevOps能力提升的重要技术途径。因此，AIOps是将AI与DevOps中的Ops相结合，希望利用AI能力来解决Ops方面的一些难题。AIOps或者智能化运维应该是运维的一个重要演进方向，未来，企业级端到端的AIOps解决方案会成为一个重要趋势。”

目前AIOps主要应用的场景包括异常检测、预测分析、优化分析、根因分析、智能自动运维等。任何事情都是机遇与挑战并存，同样，AIOps也面临着很多挑战，王金伦认为其中最大的挑战是大规模的有质量的数据、经过训练的有效的模型、失败的成本等问题。

除此之外，运维领域还出现了很多其它新技术，它们可以帮助提升运维效率与效能。例如利用机器学习、大数据分析等技术提升根因分析、故障预测、自动修复等运维能力；通过Service Mesh、微服务等技术对运维平台架构进行重构，为DevOps环节提供反馈服务能力等；采用混沌工程等方法，一方面检验生产系统的突发事件应对能力，另一方面也可以检验运维平台应对过程提供的价值等等。

嘉宾介绍：

王金伦，于 2003 年清华大学计算机系毕业，拥有 15 年软件架构设计及开发管理经验，具有 PMP、ITIL、COBIT 等认证，具有 EXIN DevOps Professional、SAFe 认证授权培训资格。先后在明华证、中国移动等公司负责总架构师工作，主导过互联网基金交易平台、基金投资交易管理系统、中国移动漫游清算系统、测试云平台等大型平台系统的架构设计与研发工作。现任华为云 DevCloud 首席解决方案架构师，主要从事研发方法咨询、DevOps 解决方案、安全架构与方案、微服务架构等工作，熟悉业界主流的云计算与大数据平台，精通 DevOps 理念与相关工具链。

在即将到来的QCon上海2019中，王金伦老师将带你全方位理解云原生背景下 DevOps 转型的经验与实践，与自身转型相对照，找到共鸣点，提升转型的信心与效率，敬请关注。

创作场景

对话 15 年技术老兵：我是如何填平 DevOps 的深坑？