成本分摊中的“分摊环”问题

导言：经济下行的背景下，企业越来越重视内部“降本增效”，成本分摊也是FinOps中比较热门的问题。本文选取了笔者在实现成本分摊功能过程中遇到的一个较为有趣的“分摊环”问题，并给出了两种解决思路“破环法”、“去环法”，最后介绍了工程实践中实际遇到的情形和解决思路。

成本分摊中的“分摊环”问题

成本分摊

经济下行的背景下，企业越来越重视内部“降本增效”，往往需要核算各项业务消耗的成本，对比业务营收，为企业业务扩张收缩提供决策依据。然而企业中的成本并不纯粹以业务为核算单元，也存在很多中后台的公共成本，它们既可能是企业运营本身就需要消耗的成本，也可能直接或间接的为企业业务提供服务所产生的成本。那些中后台部门往往都是成本部门，占据企业成本消耗的大头，他们也不希望只为企业反映消耗成本的一面，而是希望能够表达自己对业务的贡献。单纯的成本核算，并不能真实的反映企业业务实际占用的成本，还需要将中后台的成本，按其为各项业务的贡献占比，分摊到各个业务上，那么企业业务扩张收缩，相应的中后台成本的增减也提供预测估计。这就是本文所谓的“成本分摊”。

笔者在工作中负责计量企业各应用系统的各项成本，例如机房成本、网络成本、服务器成本、设施租用成本、软件成本等，并通过应用对各业务的用量占比，把信息技术部门的建设成本分摊到企业的各个部门，让决策者清楚的看到“钱从哪来，花到哪去”。

“分摊环”问题

在实现这一能力的过程中，笔者遇到一个分摊链路成环的问题。如下图所示，应用A/B/C/D各自回产生相应的成本，其中，A的成本有一部分要分给B，B的成本有一部分要分给C，C的成本有一部分要分给D，D的成本有一部分要分给A，这样形成了一个分摊环路。而部门P1/P2的成本均来自C成本的部分，那么最终部门P1/P2应该承担应用A/B/C/D的多少成本呢（包括成本金额和成本路径）？

笔者初看这个问题时，感觉有些复杂。因为整个分摊链路中不止一个环，环与环之间的关系又包含相切、相交的情形，导致问题的复杂度骤然提升。但实际上这些情形可以统一归类为多环重叠的情形，只要设计的算法可以适应重叠问题，那么就不需要分情形讨论。

两种“分摊环”问题的解决思路

对于分摊链路，我们期望的是成本在链路上可以一直向前走不回头，因此这里笔者分享两种两种处理环路的思路：破环法和去环法。

“破环法”

这个是笔者首先想到的方法，将环路按一定规则从某一段链路上破开，让环路不再成环。这个方法有点繁琐，但计算耗时稳定、可以记录环路路径。

“破环法”当观点认为，环路也是一个重要的路径，其基本思路有两点：

1. 最简单的情形是“来回分摊”的情形，分摊环问题可解。
2. 所有的环路都可以经过变换，达到“来回分摊”的情形。

首先考虑“来回分摊”的情形，这是一个简单的无穷级数问题。
其次，考虑“环路变换”，当变换到来回分摊情形时，按上述计算公式进行破环。实际上，在环上可以从任意一处位置进行破环，最终计算破环后的分摊比率没有差别。

因此，“破环法”的算法方案：

1. 记录节点间全局的分摊比率。
2. 从全局分摊链路图的任意一点出发，一直向前走，存储分摊路径和分摊比率，一旦在路径上遇到环路，就依公式破环，将破环后的比率更新到全局分摊比率。
3. 遍历分摊链路图的所有节点，有环破环，最终得到全局无环的分摊链路图和分摊比率。

“去环法”

这个是笔者的一位同事想出来的改进方法，将环路按一定规则直接从链路上去掉，让链路不再有环。该方法理解和实现上要更为简单，可优化空间更多。该同事不仅基本功扎实，并且头脑清晰聪慧，其思路确实值得称赞。

“去环法”的观点认为：环路无用。有环分摊都可以等效为无环分摊，如下图所示：


因此，“去环法”的算法方案：

1. 依次从全局分摊链路图的每一个点出发，计算每个点有效的分摊路径和分摊比率。
2. 计算分摊路径和分摊比率时，父节点递归收集子节点的直连节点（包括分摊路径和分摊比率），如果遇到环路，则去掉环路的比率，其他有效比率等比例扩张到1。
3. 如果自身节点已经是末端节点或者自身节点曾经出现在路径上，退出递归。

两个方案的对比

通过演算，无论是破环法还是去环法，计算结果都是相等的。

“破环法”本身其实是深度优先遍历，每条链路都尽力向前计算，所有路径都会被保留，并且破环是全局有效的，一个环在图中只要破一次即可，无论全局分摊链路图有多少环，其耗时都是线性增长的。缺点是实现上有些复杂，如果想混入其他业务逻辑，很难维护。

“去环法”本身其实是广度优先遍历，每个节点都假定下游节点已经完成去环处理，自身在进行去环。因为环路无用，因此去环法最终结果不会暴露有关环路的路径，并且去环是局部生效的，每个节点都要完整的跑完全局分摊链路图，并进行去环。实现上去环法有明显简单的优势，缺点是当环路增多时，其耗时增长非常快。

在实践中，笔者最先采用的是“破环法”，涉及800+个应用，每次计算耗时1小时左右。但成本分摊不是计费支付，对结果有一定的误差容忍。在可以容忍一定的误差的前提下，提前抛弃链路基本上可以避免“去环法”耗时增长的问题。最终笔者采用的是“去环法”。

工程实践中的问题

Loop or Mesh?

工程实践中，环路才是普遍情况。应用往往不是“我为你，你为他，他又为我”的单向环路，而是“我为大家，大家为我”的Mesh链路。这种情况在中台应用特别明显，一个中台应用往往使用其他中台应用，其他中台应用也会应用到这个中台应用的功能。一旦某个前台应用使用了中台的功能，那么这个前台应用的分摊链路数量会立刻急剧增长。

误差容忍

而在大中台大行其道的环境下，环路数量非常多，严重影响计算效率和结果规模，并且经过多次分叉后，相当多的路径其实占比非常非常小。考虑到成本分摊并不是计费支付，它的主要功能是为企业的业务成本提供参考数值，并且本身按应用用量的方式计算成本也不见得就完全精确。因此，在工程实践中，我们容许一定的误差。也就是当一条分摊路径的分摊比率小于误差容许比率(实践中我们取的是1‰)，那么这条路径就可以认为是个可忽略的路径。并且通过调节误差容许比率，也可以调整最终误差成本在总成本的占比，从而得到一个较为满意成本分摊路径。在误差容忍下，“破环法”必须要先计算出全局链路图，才能进行误差容忍优化，而此时“去环法”的优势则特别明显，可以十几秒内跑完所有结果。

总结

成本分摊更多涉及的是业务规则的问题，包括如何计量成本，如何计算用量，每家企业都有不同的要求，没有统一的规范。因此本文没有介绍成本分摊的整体方案，而是选取了实践过程中一个较为有趣的问题，给大家提供一定思路。
成本分摊在信息技术领域的应用是FinOps中比较热门的问题，笔者所在企业已经实现每月XXXX万规模的成本分摊。在笔者和厂商和同业交流中，多数企业都处在尝试阶段，涉及全面的、大规模的成本分摊案例较少，因此笔者将自身从业经历与大家分享，希望对大家将来的技术问题解决有一定帮助。