如何让 DevOps 发挥期望的效益

作者 | Prakash

译者 | 王强

策划 | 褚杏娟

如今几乎每个人都说自己在做 DevOps，但只有少数人获得了期望中的业务价值。这背后的原因在于，他们清楚地知道要让 DevOps 模式在组织中正确推行下去需要重点关注哪些地方，同时他们也知道业务价值是 DevOps 的终极目标，价值始于客户也终于客户。

DevOps 的正确应用需要关注四大要素：领导力、组织结构、DevOps 中的价值流图（VSM）和脉搏检查。这四个要素看似简单，但却最容易被忽视。只有组织真正做到时，DevOps 才会发挥出最大作用，为客户创造更多的业务价值。

领导力

领导力是目前在所有组织和行业中出现率最高的术语之一。这方面，给我启发最大的是领导力大师 John C Maxwell 的一句话：“一切事物都是成也领导力，败也领导力”。DevOps 也不例外，但 DevOps 是嘴上说的最多、行动做得最少的典型领域。

“人们在接受领导者的愿景之前，首先认可的是领导者本人。”——John Maxwell

组织成员在追随任何有价值的愿景或事业之前，首先会全力追随“有价值的领导者”。组织成员不会因为 DevOps “值得做”或是流行风尚就接受它，除非他们认可了推广这一愿景的领导者。因此，一个组织中的 DevOps 究竟会成功还是失败，完全取决于组织的领导者。

下面是所有“DevOps 领导者”必须关注的一些关键问题：

影响力——根据 John Maxwell 的说法，“领导力完全就是影响力”。DevOps 领导者必须有一定的影响力，才能在组织中发挥效力。
以人为本，而不是以特权为中心——没有人会因为拥有的特权或头衔自动成为受人尊敬的领导者。领导者需要以人为本，时刻重视自己的下属。人们并不在乎你有多博学多识，他们的感受是否被重视才是关键的。
创造 DevOps 文化——DevOps 是一种文化，整个组织都需要做 DevOps，这样才能成功。没有正确的心态和文化很难获得 DevOps 的全部收益，而创建正确的文化是领导者的责任。
耐心——这是领导者所有应具备的品质中最有意义的一项。DevOps 转型确实带来了很多不确定性，而领导者的品格就是在应对困难、展示耐心的过程中体现出来的。
富有远见——领导者不仅要推行企业愿景，他们本身就应该富有远见。领导者不仅能看到别人看不见的东西，而且还能比别人看到得更多。

组织结构

在大多数组织中，DevOps 团队的组织结构是什么样的？

职能结构可以说是今天众多组织中最常见的结构类型。这种结构的目的是将具备专业技能的员工按不同的功能分组，如 IT 交付、基础设施、运维、治理、DevOps 和测试等。每个部门 / 职能部门都由一个人领导，这些人再向一个交付单元的领导汇报，最后所有高层都向 CIO 汇报。

这种职能结构的优点是将员工按照技能知识和明确的角色、职责进行分工，缺点是每个职能部门都可能会变得过于孤立，往往会忽略组织的整体性。但这种孤岛式的结构并不适用于 DevOps。

DevOps 由部门主管负责，他 / 她需要向组织的其他成员推销或证明这项服务。DevOps 部门主管与其他部门主管之间存在着“推销方 - 接受方”的动态关系。在整个组织中推广 DevOps 是 DevOps 部门主管一个人的直接责任，并非所有部门主管有同样的 KPI 要求。

DevOps 团队和其他部门之间没有协作，因为他们已经形成了“孤岛”。这种结构中，其他支持团队（如基础设施、运维、工具链等团队）并不总是与 DevOps 团队共事。最重要的是，企业看不到 DevOps 的价值，DevOps 总是被视为额外的开销 / 成本。

为此，我提出五点建议：

DevOps Scrum 团队应该由 DevOps、工程、工具链、架构、基础设施、运维人员和必要的业务代表组成。
这种跨职能的设置应该是可复制的，并随着需求增长而增加更多 Scrum 团队。
组织中的最高领导层应该承担起推动 DevOps 的责任。DevOps 需要组织文化进行转变，因此应该自上而下地推动。推动 DevOps 应该是组织中 CIO 的 KPI。

DevOps 中的 VSM

价值流（Value Streams，即 VSM）是一种可视化工具，能够客观地衡量和跟踪对组织最重要的事物，以及会给客户带来实际价值的事物。

VSM 用于衡量业务价值在实现流程中所有活动的流动情况，它清晰地展现了端到端价值流中的瓶颈，并帮助组织确定需要关注和改进的领域。当我们衡量流程的一个子集（如开发人员完成一个“用户故事”所需的时间或将变更部署到生产环境所需的时间）时，可以针对性优化价值流的部分。