闲谈KPI的久期

人世间很多事情是相通的, 因为真理就在那里。只是有些时候因为政治、文化、世俗或者信仰的需求而故意的去颠倒，让人产生了幻象罢了。例如当年的SDN、或者SDWAN，现在几乎所有类似的产品都遇到了控制器容量的问题，久分必合，而久合必分，这就是背后的逻辑，您需要去把这些因为市场或者营销带来的是非颠倒回来，那么自然就看透澈了。

谈到这个话题的起因是最近几日有好几个团队问到几年前渣做的一个项目，似乎也印证了这个道理, 从最底层的逻辑和客户的视角驱动产生的项目更加容易获得更长的生命周期，只是这样的KPI兑现的时间具有较大的不确定性，然后调侃自己KPI总是要等到三四年后才能在线上遇到问题然后才能落地兑现。有个同事丢下一句你应该做一个短期的KPI，然后再做一个KPI到期后的新的KPI，似乎有点期货移仓的味道… 然后紧接着一位金融的小伙伴冷冷的丢下一句：“典型的久期不匹配…”

恰逢最近某司Q2业绩生猛，干饭人也要迎来其中考试了，今天整理完前半个财年干的活交给老板，然后就来瞎扯一下KPI的金融属性和如何通过KPI实现绕监管和上杠杆，以及如何完成KDS(KPI Default Swap),以及 这些衍生品..纯属于胡扯，别真去用了3.25来抽我啊~

KPI的结构化分层

KPI的分层和次贷危机期间的那些结构化产品非常类似,无论是3.75或者是和债券那样评级为A都属于Senior Tranche，而3.25或者如同C级的债券则是Equity Tranche，中间的属于Mezzanine Tranche，而被优化和违约都是一样的给社会输送xx…但是从一个更大的团体来看，例如一个带有若干个团队的总监级领导，如何保证自己不被优化则涉及到了类似于CDO的结构化产品了，也就是前面所说的 了,当然这样逐级的KPI也就产生了一系列衍生的杠杆，当然也就直接导致了OKR的诞生,使得从管理层目标逐级向下的过程中不增加杠杆。

KPI的期限错配

针对一个管理者的视角来看，KPI本身又有更多的借贷属性，对上的KPI会非常自然的去把项目周期拉长，考评周期延长。而对下似乎又特别想把每个KPI压缩的更短。所以从这个视角上来看一个经理更像是一家金融机构，自然风险就在错配的流动性上了，对下的短期的KPI完成后的兑付出现问题的最直白的说法就是：“老板又txx画饼了…”，最后自然会导致流动性丧失，也就是员工离职带来的影响。最后只能承认”我TM真是TMX脑子有问题了“，然而说这句话的嘴哥还真的是KPI期限管理的王者，而华为本身也因为不是上市公司所以在KPI的构成结构上可以做到很好的期限配置，一些长期的耗时十年的项目得以通过并执行。

KPI的期限管理

现在的很多互联网企业面临市场竞争的压力下，内卷的越来越厉害，自然KPI的期限也越来越短，以至于执行的KPI和公司的愿景之间出现了巨大的鸿沟。期限管理的最难的一点是对上画饼，因为很多东西超越时代若干年是很难被固化的思维所接受的。例如当年大家都在搞集中式SDN控制器的时候，渣在公司推分布式智能的方案很难得到认同，即便是聪明的老大们认同了，执行的过程中也遇到了相当大的阻力，直到大家最近一两年面对控制器的性能瓶颈了才会逐渐的想起来要一些功能准备落地。

从这个问题上来看，也学会了不少KPI期限管理的道理。此处渣又要自黑了。

例如目标可能是最终实现分布式智能，但是复盘当时(2018年)的情况，Flink存在一些性能问题、ARM不兼容、嵌入式不可用、流式AI推理功能没有(当时做的时候Alink也刚在阿里内部起步),因此重构了一套，看上去逻辑没错吧？但是在整个公司内部推一套外面没人用的框架自然而然会遇到很多阻力。

那么如果按照KPI期限管理的理论换一种做法呢？先定一个短期目标把控制器内部分I/O密集和计算密集的业务做成微服务的方式，然后再推向网元侧，然后先顺应Flink的潮流获得公司内部更广泛的支持者，而不是简单的去反复解释why not flink，以这样的视角构建一个结构化的KPI，有短有长也有期限错配，把长KPI拆解分步执行，同时也能应对一些阻力。

所以很多人看到我搞NetDAM顺便评价了一下SRD/eRDMA就在那里拿着一些只言片语去议论，这也是一个没有考虑到KPI期限配置的误解。从短期KPI来看，或者更长远点的中期KPI来看，一个操作系统内核需要Bypass Network Stack是SRD、eRDMA存在的根本原因，而其内部的实现上都符合了现在到未来若干年的应用需求，从架构上来看，这两家的架构师做的都非常的不错。

只是渣看得更远一些，看到了未来400Gbps的主机网络使得DMA本身会存在问题，某种意义上来看NetDAM是一个“最终幻想”，因为渣在做预研所以满脑子都是在推演未来5年以后的通信场景，因为一个新产品从接受到落地通常需要两三年然后再培育客户两年正好赶上市场刚需而增长，所以你们才会看到Nimble这些自动驾驶网络过了四五年才逐渐的准备落地，而Ruta这样的项目等到大家逐渐接受也需要未来两三年的努力，NetDAM估计要到应用I/O密集度使得公有云200Gbps都成为瓶颈了才会逐渐的落地，当然这件事情会不会因为SMPC这样的东西加速不得而知。其实渣自己也很纠结，短期的KPI在哪？毕竟这是可以经济扶贫的最现实的诉求。当然把前几年的预研落地就可以了呀~~ 所以从这种角度来看，实现了一个Rolling的KPI自然而然的就会走上一个良性发展的正轨~

另一个问题是在内卷的过程中如何构建一个合理的KPI结构使得兄弟团队也有3.75的机会，这就是更需要考验一个管理者的艺术了， 很多时候并不需要把所有的credit抓到自己手上，抓最关键的就好。其实我们小时候都被长辈们教会了如何学会分享，而成年了似乎忘了,总是多了几分教会徒弟饿死师傅的忧虑。。。而渣这种就喜欢技术扶贫，一方面是整个行业落后太多了,特别是网络的团队由于过去十多年一直远离业务和寡头垄断导致有很多可以做的事情. 而另一方面就是手上有完全期限错配的KPI,不怕别人短期上杠杆:)

KDS(KPI违约互换)

从企业管理的角度来看，如何激励员工似乎KPI或者OKR的手段都是无效的，过去两年在关注金融机构风险管理的同时也一直在考虑技术型公司特别是科创企业的风险管理如何实施的问题。大型公司和上市公司很容易因为财务上的需要做出大量短期的决策，特别是那种需要牺牲短期市场利益。而很多公司的compensation plan又是事后激励机制，对于高风险长期项目的初期激励和投入接近于零，从这种角度来看某司当年的Spin-in的处理方式来处理长期性战略性的创新业务就显得非常重要了，而这种财务上的孵化本质上是一个KPI Default Swap(KDS)的过程，当然衍生品嘛赢了就会带来巨大的收益，自然也会导致一些不和谐的声音，就不多去评价了。只是更多的从管理上考虑，一个团队如何激励3.75去做更冒险但更长期能落地的事情，同时能够让中间的3.5去执行那些短期而关键的业务，这是需要考虑的。当然各个公司都有自己的研究院想去模仿当年贝尔实验室的成功，而其考评机制上又出现了问题，最根本的还是对于KPI的违约管理上的问题,明晰的KDS为KPI的违约提供了足够的期限管理机制，也为一些高风险的项目提供了保障机制，这是在整个过程拉远KPI和公司远景挂钩的最简单的对冲机制。

例如一个最简单的机制就是，当主机网络到了400Gbps以后，伴随着NUMA双路节点而构建的双400Gbps服务器，RDMA本身成为了问题，而主内存带宽完全不够响应，这个过程中的生态迁移该如何考虑，对于nvidia(mellanox)而言便是一个两难的境地，放弃RDMA自己苦心经营了那么多年的生态丧失，新的生态又要与其它同行共享，刮骨疗伤的事情并不是一般人有胆量做的，而nokia当年死守塞班就是一个反面的例子。

KPI和愿景

正如本文开头所说，你要明白那些被市场策略和生态颠倒的真相,或者更朴素的说法是马斯克常常谈的第一性原理，例如从长远来看，假设一个云数据中心可以给客户调度一万个核，如果不考虑现有的操作系统、编译链接执行和数据传输这一系列问题，从整个系统能耗最小的角度出发，一个数据进入后应该放在哪，如何同其它数据以最低能耗交互，这便是真正的“以数据为中心”的处理方式，而整个工程也是实现E级超算或者更高级超算所必备的关键技术。

那么长期的KPI其实就很清楚了，这件事情谁做成了真的就构建了下一代公有云的壁垒，但是短期和中期的KPI如何匹配，是采用Barbell的KPI期限，还是Bullet的KPI结构，你看这一点上有何债券的久期联系上了，一个公司的经营现金流决定了KPI的久期，那么如何在barbell和bullet之间取舍本质上是一个凸性的问题，而这种凸性又和市场的宏观经济状况相匹配，也和公司的体量相匹配。

细化来看，为了解决这个问题，操作系统要改、编译连接执行要改，都是非常大问题。操作系统该不该改？我们辩证的来看操作系统的时间片调度和保护机制是它一开始的目的，是因为有多人要共享一个处理器而诞生的技术，而现在云数据中心微服务及云原生架构本身加上大量的用户态的协程机制使得操作系统的调度器似乎成为鸡肋，通常还必须要在启动时加上isocpus去禁用调度获得更高的实时性，另一方面内存管理最终也变成了用户态malloc hugepage后自己玩，操作系统最多做点TLB的隔离操作，文件系统在云原生的环境下对象存储和Persistent memory的诞生使得它又如同鸡肋，最后的内核网络似乎早就被大家bypass了。所以你会看到exokernel、unikernel、libos这样的东西出现，更进一步如果这些赘肉打掉后，虚拟化本身是否还存在？以数据为中心的计算架构的操作系统是否还存在于每台服务器上？所以你会看到Serverless这样的东西出来。

与此同时有一些已有的流计算系统或者类似于K8S这样的系统已经有了调度器的雏形，但是另一个问题是从程序语言上来看，如何动态拆分计算任务？Java类的相对简单因为有相应的Class文件拆分，而传统的编译链接的程序如何面临多指令集(X86/ARM/RISC-V)的场景也是一个值得挑战的话题，而新兴的WebAssembly(WASM)在边缘计算中逐渐商用，如何混合调度边缘和终端资源？

那么接下来的一个话题是，编程语言是否需要升级？60年代的微分方程计算成就了Fortran，70~80年代的操作系统成就了C，90年代开始的互联网成就了Java. 而应对多核调度而诞生的golang似乎也逐渐发展起来了，另一方面保障内存安全的Rust也在迅猛发展。还有就是值得关注的Scala，例如Spark、Flink的应用，也有Chisel、SpinalHDL。函数式编程是否真的会在这场以数据为中心的变革中闪亮登上主流计算引擎的舞台？

这一系列的问题本身并不是某一颗XPU能实现的，而它又必须要实现，为了人类心智的荣耀~