KPI驱动的DevOps转型可行吗？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相关阅读：

另辟蹊径，传统银行供应商系统持续交付之路

从急诊室故事联想到系统运维

关于作者

---

刘华（Kenneth）

• 就职于世界500强银行，负责基金服务业务软件开发与交付
  

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书

小说体敏捷/DevOps转型教科书

和实战经验分享

购书指南

—

纸质书、电子书在京东、当当、亚马逊、微信读书等渠道已全面上架，搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。

有声书已登录喜马拉雅、微信读书，适合路上听书的你。

关注公众号看其他原创作品

觉得好看，点个“在看”或转发给朋友们，欢迎你留言。