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

DevOps 建设似乎已经成为了企业共识，但是何时建设、如何建设仍然是企业关心和头疼的问题。企业的技术、人才、业务达到何种程度才适合建设 DevOps？建设过程中，从哪里先入手，又应该如何处理组织架构、原有技术栈与 DevOps 之间的矛盾？是否有 DevOps 建设的参考架构？建设完成之后，DevOps 的下一步该如何发展？...... 为了解答以上问题，我们采访了 15 年的技术老兵、现任华为云 DevCloud 首席解决方案架构师王金伦。

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，王金伦是这样理解的：“从本质上来讲，运维（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 实践成熟度的提升，持续地调整组织结构。”

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!