对话15年技术老兵：我是如何填平 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 融合敏捷、精益、自治团队、分布式决策等理念，企业应通过顶层设计、实践社区（CoP）、组织变革等方式建立与 DevOps 相匹配的组织与文化。我们通常说 DevOps 变革是“一把手”工程，很大程度上就是组织与文化的变革必须高层推动，否则 DevOps 也就只能停留在纯粹的工具、工程方法等皮毛上，难以走得远，给企业带来可观的价值。
其次，企业会面临工程方法方面的挑战。目前 DevOps 并没有一以贯之的标准或者知识体系，因此企业应体系化地理解敏捷与 DevOps，并形成一致认可的适合本企业的 DevOps 实施框架，这样才会更有效地提升能力。
在我们接触的很多软件企业中，他们并没有体系化的掌握 Scrum 方法，对 Backlog、EPIC/Feature/Story、Scrum 会议等都缺乏基本理解，因此，在进行敏捷项目管理时就遇到了很大的困难，更遑论 DevOps 整个体系了。华为云 DevCloud 推出的 HE2E 工作坊，基于 HE2E DevOps 实施框架与案例项目，以训战结合的方式，能够帮助企业更体系化地理解 DevOps。
最后企业将面临的问题是如何打造端到端的一站式 DevOps 工具平台。企业可以从 2+1（项目管理 + 源代码版本管理、持续交付流水线）能力来进行 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 理念与相关工具链。
标签：深坑,15,运维,平台,DevOps,王金伦,架构,企业 来源： https://blog.51cto.com/u_15127556/2717831