如何让 DevOps 发挥期望的效益
- 2022-03-21 16:14:47
- Prakash 王强
- 转贴:
- 微信公众号
- 983
DevOps 的正确应用需要关注四大要素:领导力、组织结构、DevOps 中的价值流图(VSM)和脉搏检查。这四个要素看似简单,但却最容易被忽视。只有组织真正做到时,DevOps 才会发挥出最大作用,为客户创造更多的业务价值。
一、领导力
领导力是目前在所有组织和行业中出现率最高的术语之一。这方面,给我启发最大的是领导力大师 John C Maxwell 的一句话:“一切事物都是成也领导力,败也领导力”。DevOps 也不例外,但 DevOps 是嘴上说的最多、行动做得最少的典型领域。
“人们在接受领导者的愿景之前,首先认可的是领导者本人。”——John Maxwell
- 影响力——根据 John Maxwell 的说法,“领导力完全就是影响力”。DevOps 领导者必须有一定的影响力,才能在组织中发挥效力。
- 以人为本,而不是以特权为中心——没有人会因为拥有的特权或头衔自动成为受人尊敬的领导者。领导者需要以人为本,时刻重视自己的下属。人们并不在乎你有多博学多识,他们的感受是否被重视才是关键的。
- 创造 DevOps 文化——DevOps 是一种文化,整个组织都需要做 DevOps,这样才能成功。没有正确的心态和文化很难获得 DevOps 的全部收益,而创建正确的文化是领导者的责任。
- 耐心——这是领导者所有应具备的品质中最有意义的一项。DevOps 转型确实带来了很多不确定性,而领导者的品格就是在应对困难、展示耐心的过程中体现出来的。
- 富有远见——领导者不仅要推行企业愿景,他们本身就应该富有远见。领导者不仅能看到别人看不见的东西,而且还能比别人看到得更多。
在大多数组织中,DevOps 团队的组织结构是什么样的?
职能结构可以说是今天众多组织中最常见的结构类型。这种结构的目的是将具备专业技能的员工按不同的功能分组,如 IT 交付、基础设施、运维、治理、DevOps 和测试等。每个部门 / 职能部门都由一个人领导,这些人再向一个交付单元的领导汇报,最后所有高层都向 CIO 汇报。这种职能结构的优点是将员工按照技能知识和明确的角色、职责进行分工,缺点是每个职能部门都可能会变得过于孤立,往往会忽略组织的整体性。但这种孤岛式的结构并不适用于 DevOps。
DevOps 团队和其他部门之间没有协作,因为他们已经形成了“孤岛”。这种结构中,其他支持团队(如基础设施、运维、工具链等团队)并不总是与 DevOps 团队共事。最重要的是,企业看不到 DevOps 的价值,DevOps 总是被视为额外的开销 / 成本。为此,我提出以下建议:
- 像其他 Scrum 团队一样,DevOps 团队应该是组织中的一个渗透性团队。为 DevOps 创建一个跨职能团队是非常重要的。
- 为 DevOps 任命一名产品负责人,他应该能直接接触到组织领导,影响 DevOps 的路线图。
- DevOps Scrum 团队应该由 DevOps、工程、工具链、架构、基础设施、运维人员和必要的业务代表组成。
- 这种跨职能的设置应该是可复制的,并随着需求增长而增加更多 Scrum 团队。
- 组织中的最高领导层应该承担起推动 DevOps 的责任。DevOps 需要组织文化进行转变,因此应该自上而下地推动。推动 DevOps 应该是组织中 CIO 的 KPI。
三、DevOps 中的 VSM
价值流(Value Streams,即 VSM)是一种可视化工具,能够客观地衡量和跟踪对组织最重要的事物,以及会给客户带来实际价值的事物。VSM 用于衡量业务价值在实现流程中所有活动的流动情况,它清晰地展现了端到端价值流中的瓶颈,并帮助组织确定需要关注和改进的领域。当我们衡量流程的一个子集(如开发人员完成一个“用户故事”所需的时间或将变更部署到生产环境所需的时间)时,可以针对性优化价值流的部分。价值流图可以通过下面的步骤来完成:
- 绘制出你的现有 DevOps 流程图;
- 指出存在浪费的位置;
- 绘制你的 DevOps 流目标图景;
- 与相关各方沟通交流所需做出的变更。
- 帮助企业理解 DevOps 的价值;
- 有助于识别瓶颈和痛点;
- 在整个 SDLC 中创造可视性和可追溯性;
- 清楚地强调浪费的部分;
- 展示可以改进和自动化的地方所在;
- 助力反馈循环;
- 通过数据和可视化手段清楚地展示背景和流程。
四、对关键领域进行检查
组织要在一些关键领域做检查,包括:
- 组织成员都是如何看待 DevOps 的?
- 谁真正在倡导 DevOps?
- 谁在阻挠 DevOps?
- 谁是组织中以“稳定第一”的名义拖累 DevOps 推广工作的“恐龙”?
- 为什么某些部门对你的 DevOps 实践不感兴趣,并不想采用?
- 你的 DevOps 工具是否用过头了?
- 对 DevOps 的早期采用者有哪些激励措施?
- 你的领导层在让行业专家帮助你的组织方面有多开放?
- 尽管有很多工具,但衡量指标的工作看起来是一项艰巨的任务吗?
- 你有多长的时间与业务伙伴举办一次“展示和讲述”活动来展示 DevOps 的好处?
联系我们
联系人: | 田老师 |
---|---|
电话: | +86 135 5227 9573 |
Email: | clientservice@hardenx.cn |
地址: | 北京市朝阳区福码大厦B座17层1705 |
加微领1G资料