KPI驱动的DevOps转型可行吗？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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