DevFinOps：度量什么最重要？

作者｜Dominic Wellington

译者｜盖磊

IT实施中面临的一个最大问题，就是如何制定IT成本计划。对整个IT项目做出估算，一直以来都是个难以很好解决的问题。本文作者提出了一种称为“DevFinOps”的方法，通过对重要度量的收集，将财务因素也考虑到IT开发运营结构中。进而作者扩展了该方法，进一步考虑了人力资源成本和运维情况。

最近似乎有不少“Dev-XXX-Ops”术语得以创立。尽管如此，在我看来，其中还应该再添加一个，即DevFinOps。（译者注：其中“Fin”是“Finance”的缩写。）

应在Dev与Ops之间添加什么?

在IT实施中，一个最大问题就是如何制定IT成本计划。如果不加以控制，IT会不断扩充，直至花完所有的预算。这意味着，我们将会深陷业务的连续循环和冗余中，重造更多复杂的轮子，做出非理性与购买决策，不胜枚举。

事实上，对IT项目做整体成本估算的做法已成为一个笑柄。大多数IT项目因超出预算而声名狼藉。

有一个“#NoEstimates”运动，提倡对于软件开发项目而言，完全不可能做出一个合理的估算。该运动的理念基本合理，具体内容为：

我们可以采用增量的方式完成各部分工作，尽快地形成所需的可交付产品。一旦采取了这种方式，就无需对故事（story）或项目做任何估算了。

对此，我们只能在Twitter看到一个简要的解释，大概意思是说因为并没有对整个项目做估算，因此根本也不会有其它任何估算。这并非我们的出发点。该做法只是去除了可能存在错误的整体估算，并没有给出对其中更细分部分工作的预算。对细枝末节的工作做预算时，需要更为精准的预算。

我们应该如何做？

或许，我们需要将财务问题也直接考虑到IT开发运营结构中。参考DevSecOps或DevNetOps等DevOps扩展的命名方法，我们将此做法称为“DevFinOps”。

这并非一个飞跃。毕竟，我们已将成本整合到SLA计算、估算工具的TCO以及拟议购买的ROI等方面。然而，这些通常是在事后才做的计算，甚至可能会为了适合一些外部假设而做出调整。

就此，我提议正确地将财务信息应用于IT元数据和流程中，以做出更好的决策。

我提出的方法建立在IT资产管理（ITAM）数据的基础之上，进而扩展了这些数据的使用范围。但是，该方法并非是做ITAM。虽然ITAM 数据库中已经记录了特定设备或硬件的购买价格和当前摊余成本，但是因为当前支持的业务功能不同，这些数据在各个时刻所体现出的实际价值可能会有所差异。

如果一台服务器是闲置的，那么扣除硬件本身的价值、后端支持（楼层空间、网络、冷却等），或许还包括相关的软件许可费用之后，它就没有其它任何特别的价值了。但是如果将该服务器配置成支持主要业务关键型应用程序的基础架构的组成部分，那么它将为企业带来更高的价值。

对系统采取不同的行动，会产生不同的潜在影响。我们应该将此类系统操作视为应从有限预算中扣除的费用。实时修补关键业务服务器，无疑是一项代价高昂的操作。因此，不要轻易采取此类操作。操作的成本也应从业务预算中扣除。

这种计算方法具有明显的优点。即便是在IT部门之外，我们也可借助它，轻松地交流各种提议行动方案的不同影响，并在云和本地部署方式间，或是在不同类型的云服务之间做出决策。但是，决策过程可能是一个充斥着冲突的过程。技术选择和定价模型往往是难以做出比较的。此外，过程中还包括了其它一些成本，例如合规性（当然，还包括欧盟的《一般数据保护条例》）、供应商风险等。对不同的因素做量化和规范化，可使我们更易于预先比较各种选项，并在事后计算所得到的收益。

该方法是否可行？

我们看到，Google已经做了类似的事情（例如站点可靠性工程（SRE）计划），并提出了“误差预算”（error budget）的概念：

业务或产品必须对已完成的事项确立一个应达成的可用性目标。剔除可用性目标，就是我们所说的错误预算。如果应达成目标是 99.99％可用，那么这意味着还有 0.01％的不可用，即我们允许有 0.01％的无效率。这就是一个预算。只要不超支，我们可以将预算用在任何设想的事项上。

如何使编程项目更具可比性，而且估算更为可靠？各种方法由来已久，并且杂乱不堪。通常，人们只是根据古老的“管理三段论”，简单地统计代码的行数。“我们需要测量一些东西，并且测量值易于采集。那么让我们去测量它吧！”。当然，还有讲解软件工程和相关管理相关课程的《人月神话》。

幸运的是，已有一些方法可以计算代码的复杂性，进而计算对成本的潜在影响，例如“霍尔斯特德容量方法”（Halstead volume）。该方法是一种对代码复杂度的测量方法，它使用不同操作符的数量、不同操作量的数量以及这两者的总量去描述代码的复杂度。该方法虽然并不能保证在任何情况下都是完全准确的，但它所给出的结果对于做比较而言是完全够用的。进而，我们可以对要变更的代码和要应用的补丁计算相对的霍尔斯特德容量，进而估计变更的风险。

人力成本应如何考虑？

如果一并考虑人力资源成本，那么我们需要采集更多的指标。其中的一些问题，一直以来都是历史难题。例如，如何区分紧急事件和重要事件，如何确定每个事件的优先级，等等。如果我们将薪酬数据（包括加班）与变更联系起来，那么一旦我们在某个问题上浪费了足够多的时间，就容易做出决定了。最合算的解决方案是完全从头开始。

收集所有此类信息，这听起来好像有很多工作要做。但事实上，这些数据业已存在，只是没有关联在一起。当企业想要推出一个新服务时，通常会在决策前做相当严密的计算。企业期望能获得（或保留）一定数量的客户，因此要提前制定出这些客户的平均整体价值、盈亏平衡点及其它一些标准。

顺便说一句，这也是我们应该与有信誉和有经验的供应商合作的一个原因。一个好供应商的销售团队将有助于挖掘这些信息，但即使是在最积极的销售过程中，也不会完全泄漏具体的部署情况。在企业内部具有更多的信息，如果只有在正确的地点和适当的时间才能得到有用的信息，那么这些信息就非常有用。

从长远来看，这意味着业务案例和投资回报的计算，最终将会是具体且实际的，而不只是在电子表格里编编公式。对此，我推荐一本很棒的小书，名为《如何用统计数字说谎》（How to Lie with Statistics，该书提供免费的PDF 下载，见参考资料）。这本书读起来十分有趣，你会发现书中介绍的事项完全是无处不在的。

如果你想最大限度地追逐潮流，那么可以考虑使用区块链验证技术，只是我个人有些担心交易成本（包括热成本）将会令人望而却步。好消息是，这里介绍的DevFinOps方法也可用于解决这个问题……

所有一切是为了什么？

该方法的底线是，目标应能计算当前IT成本的规模，并能给出变更会产生何种影响（至少在合理的范围内），而且关键在于，能实时地做到这一点。

该目标就是敏捷成本估算，也是我选择创造“DevFinOps"一词的原因之一。我们今天做成本估算的方式是非常“瀑布式”的，大型团队已在电子表格上争论不休。这一过程是如此痛苦和昂贵（就个人时间和中断时间而言），因此只适用于最大变更。

该过程并未与敏捷的快速发布周期很好地保持一致，这也正是“#NoEstimates”运动的出发点。但是，如果实时地收集和处理全部的成本数据，并让这些数据可以通过简单的API调用，我们就可以对所提议的变更计算两端的成本（即代码本身的复杂性），进而对变更中包含软件缺陷的概率做出估计，并估计部署将会对基础设施产生的影响。然后，我们可以将这一成本与团队当前的 SRE 误差预算做比较，确定是否可以自动地实施变更，或是否需要将变更作为例外注销掉。

结果看起来很像在ITIL（IT基础架构库）中提出的“标准更改”这一概念，但是不存在ITIL的中心化与SRE的去中心化之间的固有冲突。关键在于，如何为标准变更的实际内容确定一个可以普遍接受的标准。否则，我们就需要ITIL变更经理去提前做出决定。

在运维中的情况如何？

我们也不要忘记运维（Ops）。上面介绍的适用成本估算方法，可使Ops对报警做出正确的的优先级排序，并对影响做出准确的估计。即便是在技术上具有同等重要度的两个中断，可能也会对业务造成完全不同的影响。当前在做调和（reconciliation）中，主要依靠的是部落（tribe）知识，以及一些时常是不准确的甚至过时的制度。如果能有一个中央共享存储库，用于存储所部署系统价值的描述数据，那么我们就能更准确地估算这些影响。

参考资料：

https://blog.forecast.it/blog/66-of-enterprise-software-projects-have-cost-overruns

http://www.horace.org/blog/wp-content/uploads/2012/05/How-to-Lie-With-Statistics-1954-Huff.pdf

https://www.moogsoft.com/resources/aiops/guide/gartner-2017-aiops-market-guide/

活动推荐

随着 AI、Big Data、Cloud 的逐渐成熟，FAAS、CAAS 等技术的兴起，以及被运维业务的多样化和复杂化，很多传统的运维技术和解决方案已经不能满足当前运维所需，AIOps智能运维、大数据运维、ChatOps、SRE、Chaos Engineering、微服务与容器运维等新技术和方向应运而生，它们一方面把最前沿的技术结合到运维中来，一方面在人员角色、领域范围、文化等方面又有了很多扩展，让传统运维有了翻天覆地的变化。