要的是确切结果，不要忽悠我
前段时间，乔帮主（乔梁，《持续交付2.0》的作者）在持续交付2.0的群里发出这一句话：
业务老大问：“原来100工程师做的一个产品，用半年时间做 devops 改进。半年之后会得到什么确切的结果？”
以上是原话。
乔帮主在群发这话的意思是：如果你的业务老大问这样的问题，你该如何回答？
请注意，业务老大要的是确切结果，不要拿“虚”的东西来忽悠人。
请读者朋友思考一会。 。
。
。 客官不要急，请再思考一会鸭。 。
。
面对老大这样的提问，技术人可能觉得好笑，接着可能装作一本正经回答老大：
- 如果DevOps改进半年后，会使单元测试覆盖率提高到 80%。
- 如果DevOps改进半年后，会使A系统的部署耗时缩短到 1 分钟。
这回答真的很“确切”，但是，还是没有办法说服业务老大。注意，业务老大是不懂技术的。老大听到你的回答，估计一头雾水：什么是单元测试覆盖率？提高到 80% 后，对我的业务 KPI 又有什么关系？
别笑，这在 IT 行业里是常态。很多时候是不懂技术的老大，却又领导着一批技术人员。
面对这样的“常态”，作为技术人员，我们有必要，也有责任让不懂技术的业务老大理解 IT 行业里必要的“常识”。
回到业务老大的问题，如果你仔细思考，还真不好回答。比如，单元测试覆盖率提高到 80% 后，对我的业务 KPI 又有什么关系？能让我的业务 KPI 提高 80% 吗？
老翟的做法
当笔者看到这个问题，第一感觉就是：我们必须找到 DevOps 改进措施和业务老大关心的 KPI 之间的关系。换句话说，就是如果在100名工程师做一个产品的团队的情况下，进行 DevOps 改进半年后，会给我的业务 KPI 带来什么确切的结果？
笔者认为业务老大的问题，可以拆分成两个小问题：
- 有效性问题：如何证明 DevOps 改进是对业务 KPI 提升是有效的？
- 进度问题：怎么评估 DevOps 改进对业务 KPI 提升了多少？
如何证明 DevOps 改进是对业务 KPI 提升是有效的？
这就是我说的：我们必须找到 DevOps 改进措施和业务 KPI 之间的关系。
“DevOps 改进措施和业务 KPI 之间的关系”指的是什么？这需要针对不同的业务场景进行举例说明。
另外，面对类似这种“改进”类型的问题，我们首先，要了解当前情况。否则就是隔山估大猪——瞎猜。所以，当别人给你信誓旦旦说改进了多少时，你需要提问：你知道当前业务 KPI 是多少吗。这样就可以判断他是不是瞎猜了。
接下来，我们就拿秒杀业务系统来举例，找到 DevOps 改进措施和业务 KPI 之间的关系。
笔者从网上找到了秒杀系统的 KPI：
((带有秒杀商品的购物车成功支付金额 + 秒杀单品成功支付金额) - 秒杀商品成本价) / (带有秒杀商品的购物车支付金额 + 秒杀单品支付金额)
从公式来看，就是利润率。为了提高这个利润率，单位时间内我们必须：
- 提高带有秒杀商品的成功支付率。
- 降低秒杀商品的成本价。
关于第1点。很明显，我们 DevOps 改进措施必须能提高“带有秒杀商品的成功支付率”指标。
关于第2点。秒杀的成本价。笔者认为可能包括：商品本身进货价、物流费用、IT 方面的硬件成本等。
拿 IT 硬件方面的成本来举例。比如秒杀的 1 个小时，在没有 DevOps 改进前，我们的带宽需要从5MB提升到20MB，机器数量从3台增加到12台等。但是，这样的技术决定是根据经验猜的。秒杀活动过于火爆的话，如果机器不够，增加机器不及时，影响了用户支付，会严重影响业务KPI。秒杀活动无人理睬时，带宽和机器都浪费了。
所以，DevOps 改进后，就能实现动态伸缩，机器和带宽都可以根据实际情况增减。这时，IT 成本指标就降低了。
实现动态伸缩，需要实现应用的自动化部署。接着，要实现自动化部署，又要提高单元测试覆盖率以保证软件的正确性……就这样从业务层到技术层，慢慢推导，证明给业务老大：看，从逻辑上，DevOps 的改进对业务 KPI 的提升是有效的。
进度问题：怎么评估 DevOps 改进对业务 KPI 提升了多少？
关于进度问题，第一件事情，要做的就是了解当前的业务 KPI 值，并进行监控。这里并不是一开始就要建一个完整的全面的监控系统。
第二件事情：根据 DevOps 改进措施和业务 KPI 之间的关系，还有当前的业务 KPI 的情况，计算改进措施对业务 KPI 的提升值。
关键问题来了，怎么计算？
笔者认为可以这样做。
- 找到当前业务 KPI 受技术影响的点，并提问，如果改进（优化）掉了这些影响点，业务 KPI 会提高多少？注意，需要从全局考虑这些点的优先级。并不是要一次性改进所有的点，也不是必须要改进。通过这一步，我们可以得到理想状态下，业务 KPI 能提高到什么程度。
- 评估到底需要哪些改进措施，并找到这些改进措施的限制点。通过这步，我们可以有目的的安排工作去改进。
- 了解当前团队的能力，就可以评估半年后的确切结果了。
第2步要做得好，我们必须了解整个团队（甚至整个公司）的协作方式，包括代码管理、发布模式；了解团队的自动化程度；了解各方的利益关系，包括测试、开发和运维等。
小记
以上的例子是笔者臆造的。思考过程才是关键。从这个过程，你可以看出，其实提高业务 KPI 的方式，其实很多很多。而使用 DevOps 方法，只是具体实现中的一种。我们不应该使用“DevOps”这个框，把自己的思维限制了。
还有一点需要提一下。在跟业务老大讨论 DevOps 改进时，我们需要区分当前业务中，软件是处于成本中心（比如HR系统），还是处于利润中心（比如淘宝网）。
处于成本中心的情况，我们重点放在帮助业务节约成本。比如你可以说自动化程度越高，需要招的人越少。
处于利润中心的情况，我们重点放在帮助业务提高盈利能力。比如你可以说发布越多，正确性越高，盈利越强。
最后，整篇文章一个很大的漏洞，不知道读者有没有注意到。从头到尾，笔者都没有谈“DevOps改进”是什么。因为整个行业对 DevOps 的定义本身，没有共识，所以，讨论“DevOps 改进”的定义，笔者觉得明智。不过，笔者十分赞同乔帮主说的：可以将 DevOps 理解为一场运动。
附录
- 年度回顾：百度乔梁谈持续交付与 DevOps: https://www.infoq.cn/article/2012/02/baidu-salon-review-qiaoliang
- 时间、商品、价格、数量，四个要素做好一场“秒杀”:http://www.woshipm.com/operate/584869.html
Last modified on 2019-12-31