扫码阅读
手机扫码阅读

KPI驱动的DevOps转型可行吗?

246 2024-04-10

为了推动整个组织实现DevOps,公司高层制定了一些“简单粗暴”的KPI—— 今年的发布数量要比去年翻倍,故障数量要比去年减半。这些KPI成了所有IT系统负责人的共同目标。

乍一看,这样的目标很不合理。

单纯增加发布数量,其实是可以作弊的,把一个发布硬生生地拆成几个发布便可(也确实有团队在这么干!)。

而且,这样做,对业务真的有意义吗?到头来,还不是IT自己在自嗨,业务痛点并没有减少?

然而,只要我们端正对这些目标的态度,结果则大不一样。

如果我们狭隘地追求数字,应付考核,当然不会得到好的结果。

但如果我们把它当成驱动力,不断审视自己的团队和系统还有哪些方面可以改进,则会有很多意外收获。

作为其中一个IT系统负责人,我也要接受这些目标的要求。但通过围绕着这些目标对自己系统的持续改进,我们获得了以下成果:

  1. 实现了某些变更类型的在工作日的自动化发布,从而使发布数量比去年同期增长了192%,差不多是过去的3倍,远远抛离要求的目标。具体措施可参阅《另辟蹊径,传统银行供应商系统持续交付之路

  2. 改进工单排序流程,把时间精力用在刀刃上。具体措施可参阅《从急诊室故事联想到系统运维

  3. 每周故障分析会议,持续跟进故障长期解决方案的交付,分析故障和请求类型,建立知识库减少重复故障和请求。

  4. 加强监控,包括系统指标监控和业务流量增长,感知系统健康情况,防范于未然,也能减少人工登陆服务器的次数和工单数量。

  5. 标准化运维流程,把具体的标准运维流程写成分步文档,并提供审批申请模板,便于每个运维人员严格按照规范执行,减少出错和降低风险。

  6. 在合规的情况下,标准化发布后系统检查清单,为发布质量提供最基本的保障。

我们也一直强调,每个系统的情况都很不一样,有些是新建的,有些是遗留的,有些是自主开发的,有些是依赖供应商的,“家家有本难念的经”。

所以不应该把不同团队进行横比。这些目标,更重要的是驱动每个团队对自己进行持续改进,所以对自己的纵比更有意义

以我们公司的实践,KPI驱动的DevOps转型是可行的,但是这需要管理层对KPI背后的目的有明确的阐释,各团队也要对KPI有正确的理解,视之为工具,而不是考核,才能避免异化,达到持续改进的目的。

原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247484279&idx=1&sn=17d6ff1243d08b89a988999d264d5da3&chksm=e9e268f3de95e1e5422b35837e9728b240c6fbbd654a82de3a75ede2efa7215eff60d1fe3191#rd