随笔：关键系统故障和软件债务久期

当然上半年还有某某交易所指数算错了，去年还有某某交易所大量报盘前置连不上, 手上也处理过大量的交易所故障，
其实这些故障都是架构上的问题，交易标的物多了导致的容量不够，处理不及时，代码已经用了十多二十年了，而关键业务重构动作又不能很大，所以日积月累成了大量的技术债务。

而我们对于技术债务的分析实际上还是定性的阶段，
正好最近
空闲时间准备FRM，各种债券期权估值的题目做的心
烦
，那就顺
手写几句吧
。
软件债务的形成在开发阶段，开发成本和运维成本的长期摊销构成的。另一方面是软件收益。但是软件债务一直没有很好的呈现在公司财务的资产负债表上，因此科技类企业的风险控制在整个管理领域是严重缺失的，而科技类企业财务造假也非常容易就是因为我们还没有完善的软件债务分析模型。相比之下固定资产折旧有一定的摊销年限，过了以后就可以报废了。而软件还有很大程度上需要复用，在复用和重构之间如何取舍，下面提供一些方法。
前几天我在和某司一个资深工程师聊天的时候谈到一个问题， 例如最简单的统计，求方差均值偏度峰度这些，或者各种分位点。统计函数包肯定有现成的开源软件，流计算引擎也有Flink这样的现成的框架，为什么还要重新造轮子呢？其实这里就是一个债务分析流程。



资金流的入方向的收益分析通常各个企业不同，但是Marketing都会做一些标准的估值模型和预测模型，财务报表上的现金流收入预测其实都好弄。接下来要谈的软件开发成本的债务摊销才是关键。


1. 研发阶段架构选择和债务估计
2018年开发某分布式流数据处理平台时，如果使用Flink在嵌入式平台需要对已有的硬件平台重构，加大内存加强CPU。同时Flink在那个时候不支持ARM使得大量的低端边缘路由器节点无法使用。AI模型推理的代码集成到Flink上需要大量的人月，公司投资成本不足以支撑这样的项目。对于这些，可以量化成每一笔开销的现金流，然后贴现到项目初期，贴现利率假设用固定利率就好。当然具体的人月工资开销和硬件开销涉及到公司的一些机密就不列举数据了。

而对比如果是采用Go来根据cloud Dataflow算法写一个流计算系统，而且网络遥测数据并不需要Exactly Once语义，部分数据丢弃也可以容忍的情况下，开发一套系统基本上1个人月的时间，Tensorflow有现成的Go的API，而Scikit Learn或者xgboost这样的决策树模型弄到Go上构建推理算子也很简单。统计上那些算法都有C的Code可以抄作业，但是这些统计算子引入CGO可能cross compile会增加复杂度，同时远期增加半个人月的长期维护成本，那么通过债务模型贴现后发现调用c的lib还不如直接抄Code改写成pure Go，而且软件尺寸会小很多，因为我只需要均值/方差/分位点的统计，并不需要为了这么小一点功能引入一个很大的库。


2. 软件维护阶段债务估计

新开始的时候选择架构比较容易，而在一个已经开发了长达数十年的平台上进行债务分析基本上是一笔糊涂帐了，同时你还要面临着开着飞机换引擎的代价。通常你面临的债务分为几个部分：
1.软件开发者的知识债务：
这是非常重要但是往往被忽视了的，很多人在一个公司工作了十多年，通常也算是某个领域的专家或者骨干了，但是很有可能他的知识体系结构和现代的软件开发框架已经脱节了，因此这样的专家在设计软件架构时会主观的选择复用已有的系统，或者在已有系统上小修小补构建。因为如果采用新的框架可能经验上与一些新人就没有差距了。而上层的经理决策层通常也盲目信任权威，因此Nokia当年那种“我们什么都没有做错，但是还是失败了”这样的事情出现的根本原因在此。
通常针对这类问题，管理层和HRBP应该有一定的激励机制，类似于债券中的息票率来缩短债务久期，当然人员的流动也是减小这类债务的另一种处理方式
。
2. 软件的维护债务：这个比较好衡量，就是根据bug数以及bug平均解决时间根据一个平均人月的开销作为现金流贴现就好了。
3.架构更替的风险债务：这个也是需要很好的计算的，当我们根据前两步确定债务现金流最大的模块后，特别是整体摊销到模块的现金流为负数的时候那么就需要考虑模块级的重构了，重构可能带来的潜在业务风险也是需要计算的，这样对于重构软件开发资源的投入有指导性的意义。通常人都是很懒的喜欢重构一些低挂果（好摘的桃子），反正又有工作量又有漂漂亮亮的晋升理由。相反踏踏实实冒着高风险修改关键业务的收益无法很好的衡量。

3. 软件债务久期久期和凸性是衡量债券风险的重要指标。同样利用久期的计算也可以很好的规划软件债务风险。软件债务久期越短相对风险越小，这样的考量下，并不是简单的降低软件开发cost可以平衡的，因为同时它考虑到了业务后续的风险和潜在故障的贴现，使得企业主有更好的债务衡量工具，是招一堆P6还是一个相对完善的阶梯级的研发团队。一堆新手虽然使得近期的软件开发成本下降了，但是会使得远期维护成本急剧上升，久期的计算便可以放大这样的问题使得管理层能够更好的意识到这样的风险。通过软件债务久期指标便可以获得比较科学的重构规划。