如今几乎每个人都说自己在做 DevOps,但只有少数人获得了期望中的业务价值。这背后的原因在于,他们清楚地知道要让 DevOps 模式在组织中正确推行下去需要重点关注哪些地方,同时他们也知道业务价值是 DevOps 的终极目标,价值始于客户也终于客户。
DevOps 的正确应用需要关注四大要素:领导力、组织结构、DevOps 中的价值流图(VSM)和脉搏检查。这四个要素看似简单,但却最容易被忽视。只有组织真正做到时,DevOps 才会发挥出最大作用,为客户创造更多的业务价值。
领导力是目前在所有组织和行业中出现率最高的术语之一。这方面,给我启发最大的是领导力大师 John C Maxwell 的一句话:“一切事物都是成也领导力,败也领导力”。DevOps 也不例外,但 DevOps 是嘴上说的最多、行动做得最少的典型领域。
“人们在接受领导者的愿景之前,首先认可的是领导者本人。”——John Maxwell
组织成员在追随任何有价值的愿景或事业之前,首先会全力追随“有价值的领导者”。组织成员不会因为 DevOps “值得做”或是流行风尚就接受它,除非他们认可了推广这一愿景的领导者。因此,一个组织中的 DevOps 究竟会成功还是失败,完全取决于组织的领导者。
下面是所有“DevOps 领导者”必须关注的一些关键问题:
在大多数组织中,DevOps 团队的组织结构是什么样的?
职能结构可以说是今天众多组织中最常见的结构类型。这种结构的目的是将具备专业技能的员工按不同的功能分组,如 IT 交付、基础设施、运维、治理、DevOps 和测试等。每个部门/职能部门都由一个人领导,这些人再向一个交付单元的领导汇报,最后所有高层都向 CIO 汇报。
这种职能结构的优点是将员工按照技能知识和明确的角色、职责进行分工,缺点是每个职能部门都可能会变得过于孤立,往往会忽略组织的整体性。但这种孤岛式的结构并不适用于 DevOps。
DevOps 由部门主管负责,他/她需要向组织的其他成员推销或证明这项服务。DevOps 部门主管与其他部门主管之间存在着“推销方-接受方”的动态关系。在整个组织中推广 DevOps 是 DevOps 部门主管一个人的直接责任,并非所有部门主管有同样的 KPI 要求。
DevOps 团队和其他部门之间没有协作,因为他们已经形成了“孤岛”。这种结构中,其他支持团队(如基础设施、运维、工具链等团队)并不总是与 DevOps 团队共事。最重要的是,企业看不到 DevOps 的价值,DevOps 总是被视为额外的开销/成本。
为此,我提出五点建议:
价值流(Value Streams,即 VSM)是一种可视化工具,能够客观地衡量和跟踪对组织最重要的事物,以及会给客户带来实际价值的事物。
VSM 用于衡量业务价值在实现流程中所有活动的流动情况,它清晰地展现了端到端价值流中的瓶颈,并帮助组织确定需要关注和改进的领域。当我们衡量流程的一个子集(如开发人员完成一个“用户故事”所需的时间或将变更部署到生产环境所需的时间)时,可以针对性优化价值流的部分。
资料来源:cloudbees.com
价值流图可以通过下面的步骤来完成:
以下是 DevOps 中 VSM 的好处:
今天,人们非常关注使用 DevOps 价值流管理平台来推动组织中 DevOps 的转型。这有助于为利益相关者提供更大的可见性,并帮助后者做出正确的技术投资决策,还可以在集成交付过程中形成实时报告并产生更多分析结果,进而促进价值流的持续改进。
组织要在一些关键领域做检查,包括:
总之,对许多组织来说,DevOps 的旅程可能不是一帆风顺的。然而,如果专注正确的领域、聘请优秀的行业专家,肯定会获得更多收益。请记得,为组织实现“DevOps”是领导者的责任。
原文链接:
https://www.headwaygrp.com/post/devops-why-organizations-struggle
领取专属 10元无门槛券
私享最新 技术干货