随笔：技术债务和公司治理

于是在重装时有了些闲暇的时间随便写点东西。恰逢《MIT科技评论》35岁以下科技创新35人放榜，看到一位高中同班同学，恭喜UCLA的李教授，获奖理由是针对前沿的生物学问题创新的开发了多种统计学方法。当年我们那班同学几乎全部选了基础学科，而我属于比较学渣那种，虽然也是读的数学，
但最后只能
旁门左道的玩着量化交易和
网络
。对于量化交易，前一两周的风险预测终于在这周释放了，上月末买入的认沽也开始产生收益了。

上周五long了一些下月300ETF的put…, 涨的让我怀疑算法，昨日中午都想平掉认输……最后忍了一下，相信算法…… 我们的风控指标继续冲高……年关或许没有那么好过了

ZartbotFin，公众号：zartbot年关将近，A股难过……

而对于网络，无论是网络安全还是网络性能，我们也在开发一些新的统计学方法，例如前面中毒的日志就是根据统计学获得的Reputation较差的主机访问日志并自动触发防护的，或者利用统计信息推测链路故障或者利用遥测数据优化网络路径等工作。

谈到
这个话题顺便列出最近在看的某院士的书，过段时间读完了再给大家分享一些读书笔记。

当然今天分享的一件事情是公司的技术债务产生和如何治理的问题。思科的商业模式来看，最为成功的我个人认为是大量的内部竞争，刚到思科的时候在一个很小的BU，做运营商信令网关这些东西的，没有一点大公司的存在感，因为作为BU是独立核算的，感觉那时候的思科就是一个大的销售和服务中前台，后台全是一堆小BU各自负责几个产品，而且当时总觉得是个小BU生意做不好就死要失业了，一直生存在危机中。这样的治理结构看上去乱糟糟的，但是我们经常开玩笑说思科给客户的东西一定是最好的，因为内部都有最聪明的人激烈竞争过。这样的治理结构也特别的适合当年常玩的Spin-off/Spin-in模式，MPLS几进几出的故事已经成为业界传奇了。

但是为什么一些大公司最终很难内生的出现一些颠覆世界的产品呢？思科在MPLS走后依然有大量的Spin-In项目，例如Innovation Everywhere Challenge，我也带领团队拿过全球总冠军并开始孵化项目，但是最终还是遇到了大量的问题，这些问题都不是技术上的，也不是资源上的问题，而是和公司治理相关的问题和一些理念上的问题，我有跨越全网的统计算法可以实现端到端的遥测分析，却没有足够的精力去拉通整个业务线条的人，特别是在SDN的浪潮下，各个BU已经整合成一系列大的中台了。

通常大型公司治理结构中对于分工有明确的细化，越界和越级的行为是被严厉排斥的。项目实施过程中每个团队的存在感都是需要精确的平衡的，因此软件架构上不可避免的会有冗余。技术债务通常就是在这种背景下产生的，同时随着时间的变化，项目组件通常会在因人员的流动不停的转手，以至于十多年过去了接手的人已经完全不懂很多最基本的原理了。

另外一个很根本的原因就是前文提到过的，架构的设计应该自顶而下，而员工的晋升和发展是自底而上的，这两个东西自然的产生了矛盾：

人的职业生涯发展，没有人一开始什么都懂就直接做架构师做顶层设计的。通常在设计协议时回溯自己走过的光辉历程并将自己的职业生涯和已有项目经验复用便成了最佳实践。这样的思维方式解决小规模的问题非常棒，毕竟可以很快速的通过类比理解需求和最小的工程代价实现。但是随着职级越做越高，其实这样的设计会变得越来越危险，因为您需要解决的问题规模越来越大，而自身的视野并没有同比例的扩大。

zartbot.Net，公众号：zartbot包处理的艺术(2)—如何设计协议

其实每个人的职级应该跟自己的视野相匹配，同时您在和不同的职级沟通时也需要从别人的职级去考虑，例如我在做Nimble架构的时候，给我们的SVP和产品线CTO谈的应该是未来5~10年的规划，网络的演进，跟VP和Fellow谈的是未来3~5年的产品线规划。而跟一些总监和资深总监谈的可能就是2~3年产品的解决方案，而到了一线二线的研发经理需要谈的就是某个产品需要什么功能以及功能间的组合。而任何错位的沟通都会带来不好的结果，而本质上是视野决定的。当一个VP还在细化的管理下面的研发进度时，或许也是另一种视野的错位。当年思科的Spin-In模式便是一个很好的方式，让一群员工能够利用公司中台的资源和已有的技术栈去尽情的发挥，因为只有这样的模式才能更替一些已有的组件，使得软件架构的设计是自顶而下的过程。

另一个问题是很多企业在开始搭大中台的结构，这一点上也会有一系列的问题产生。
当很多公共组件被中台吸收后，单个业务线条的死活已经无法威胁到中台的生死了，因此中台成了公司中大而不倒的部门，旱涝保收自然效率就会下降了。所以某个著名通信企业老总跟我说他已经整合好数通很多产品线的软件的时候，以及很多公司开始成立中央软件部的时候，我默默的表示这是一个巨大的风险。

如果PM团队不够强势，中台会越来越大，而产品也会越来越重，例如某个互联网大厂的IM软件便是如此，里面总要加一些社交的赛道。
而微信则依旧非常的干净，当然鹅厂也有自己的问题，例如鹅云至今没有SmartNIC，高性能网络团队搭建也没开始。
当然从本质上来看DPU/SmartNIC
这个问题其实就是一个数据密集型业务的处理
，
M
a
ny C
o
re
是必然选择，可能鹅厂因为技术栈全是C/Cpp因此对于Offload不太重视，大概率也是因为内部管理架构的原因。
但是
鹅云就不同了
，
留到下次
TAOPP（The Art Of Packet Processing)
–
第三节再说。