上周去客户现场救火，所以接触我们的销售和技术支持的一些同学。岗位性质不一样，一番交流倒是碰撞出思维的火花，所以记录一些 idea。

支持大客户的时候，对接的同事报怨：遇到问题不知道该找谁，解决问题效率低下，往往需要拉一圈人，从一开始拉个 3 4 个人的小群，然后再拉人再拉人，最后拉成了十几个甚至几十个人的大群。

是不是传话的人太多，干活的人太少呢? 也不尽然，其实一方面是路由的层级太深了，另一方面是深度和广度的天然约束。这里先总结几种模式。

1. 流程规范模式。如果按当下贵司的标准流程，应该是 oncall 走工单的，在收到 oncall 之后，首先会有 L1/L2 层的技术支持的同学先尝试解决，如果解决不了，才会路由到 L3 也就是研发这一层的介入。研发这边每个 team 会出人排班，轮流 oncall。好处是产研被打断得比较少，只有 oncall 当期值班的同学确定会被打断，其它人还是可以安心处理手头的工作。但是对于响应优先级，除非是 P0 P1 紧急任务，其它工单的响应性都会降低，因为 oncall 的人力就那么多，而问题的输入过多之后，就会处理不过来。前线的同学也不能立刻知道会是谁，会隔多久，会来处理这个问题。
2. leader传话模式。早期我们在没有比较完善的 oncall 制度之前，会更类似于混乱的 leader 传话的模式。比如说，前线的同事并不知道这个问题找谁，但是能知道这是哪个模块的问题，那么直接去找相应的 team leader。其实 team leader 自己日常是要处理许多事情的，他需要拦下各种杂事尽量减少组员被打断。如果能简单处理掉可以选择自己处理，如果不能的情况下，还是会穿透到具体的某个研发。但是这个阶段很混乱，很多时候问题会直接打穿到研发，站在前线 support 同学的角度，假设我我去找一个 leader，他本人直接解决不了我的问题，那他还是要帮我安排到某个研发，那我为啥不自己直接找那个研发？
3. 项目模式。如果订单足够大，其实我们是可以专门投一部分人 focus 在这个项目上面来的。这一种 support 形式其实是对于单个项目的效率局部最优的，所以其实在商务侧，他们最期望的就是自己的单子，有这种形式的支持。期望支持的人是一个 T 型的人才，T型人才有能力 handle 各个模块的广度问题，又有能力处理特定具体模块内深度的问题，这种场景下是最好不过了，一个这样的人的支持，在这种场景下可以释放出一个团队的战斗力。

比如说他们提到，"当发现 XX 被拉进群里来支持的时候，就觉得好有安全感"。而这种所谓的 "安全感" 就是对个人能力的一种肯定，能帮忙解决事情，而不是传话。我也举例说，"比如 YY，他能处理的问题就很多"。我说的 YY 这个同事之前是研发出身，后面转岗去了技术支持的团队，所以相对来说技能点更丰富全面。 这里也有一些影响因素，比如说已经工作了好些年的同事，其处理问题的经验和能力跟新人就不一样。oncall 的流程规范下，会遇到这样的不确定性，比如说工单被 schedule 到具体某个同事，而那个同事是刚转到那个 team 不算太久的新人，其实他也处理不了，那他还得继续往其它同事传。

好啦，关键点来了...我们不可能指望每个人都是 XX，每个人都是 YY 这种，战斗力很强的。我们也不能指望平均花 4-5 年的培养周期，才能出培养一个 T 型的人。

一个人的精力是很有限的，这是一个制约 T 型人才的重要因素，对于这一点我感受很深刻。

我加入公司的时间很早，随着产品最初的版本一路过来，整体架构都足够熟习。随着组织架构的调整我是经历过多个团队，覆盖许多的模块。所以在我去 oncall 的时候，我自认为是能够 handle 特别广的问题的。但是我发现，如果广度够的时候，深度就不够了。曾经我写代码也很猛，我写过 ddl 的代码，我写过事务的代码，可以说在 repo 中的各个模块，都曾留下过我的痕迹。但是，一旦我三个月不碰那一块的代码之后，查该模块有一定深度的 bug 的时候，就感觉很吃力了。

所以我们讨论的点又落到的知识的传承上面。

最深入理解某一小块代码具体实现的，肯定是还在写代码的，三个月以内触碰过那块代码的人。模块的划分越来越细，越来越细，最后变成了很多颗螺丝钉，也就是所谓"专家"，focus 在这么很窄的一个模块上面。

这是一个适应环境演变的特化的过程。比如果一个段子说，从阿里出来的大厨，到了外面小厂，人们以为他肯定是无所不能啦，结果他说，只负责在萝卜上面雕花。买菜不管，洗菜不管，下厨更是不会...当模块和层级无穷分裂，最终就是这样的形态。

当我们一个核心的"专家"离职，他所负责的那一块可能就没人能顶替他。知识是在他大脑里面传承的。可能有人问，为什么没有文档？不，我们有文档，有很多的文档，零散的知识库。有这些"文档"并不代表有这些"知识"，就好比书架上面有那么多书，它们都进入到你的脑子里面了么？

存储信息最高效的实现，是在某位专家的大脑里面。你问他什么，他会直接给你答案。这种检索过程最高效。就拿最近 oncall 中的问题来举例，客户问一个 prepare plan cache 为什么不生效的问题，我是研发，我可以跟代码去分析那块代码，只要是熟习那块代码并且给一定的时间，总能分析出来为什么。但是如果我们直接让写那块代码的同事来看，他几乎很快就能得到答案：哦，是代码中这里的判断条件，导致 range 查询请求转化为 point get 的时候，这个场景 prepare plan cache 使用不上。再比如说一个 ddl 卡住的问题，我知道 ddl 的执行流程，状态变更，知道怎么样获取到 ddl 元信息的状态，然后去找相应的源代码，而换成另一个同事来看，她直接得出答案了:这是 6.5.x 里面的一个已知问题，现象是 xxx，已在更高哪个版本中解决! 看，甚至并没有计算过程，直接出结果的，高效吧？这就是专家的威力。就像高考做题一样，有很多题目连答案都直接进缓存了，不涉及计算过程。

但是人脑的存储容量是非常有限的，考纲越大，就需要越多的专家只记忆其中一门科目的细节的过程。知识就像一片叶子上面的脉络一样，越是偏上层的原理性的东西，越是容易掌握。而偏下层细节方面的，越是难以用缓存在大脑的方式来处理。你问一个螺丝钉，他对他自己代码的那一个细节最清楚。你问一个中层的 team leader，他能够知道这个模块的整体情况和工作原理，但是对于代码中的某一些细节，他是不如螺丝钉的。而你再问他的 leader，那他抓的方向可能就不涉及代码了，他在思考整体的架构，系统的演变方向等等等。你抓首席架构师去处理一个具体 oncall 问题查查 bug 试试，这是没法处理的呀!至于 cto 已经去 branding 去了，刷脸增加 awareness。他要告诉大家的是，这个领域遇到的挑战是什么，新出现的发展方向是什么，要跟客户讲清楚自己家产品的先进性是什么。

注意到没有，知识是有分类的。如果还是按 T 型人才来讲，研发的特性是专，而 L1 L2 support 的特性是广。问一个模块的研发，另一个模块的问题，可能他掌握得还不如 L1 L2，因为后者可能正好在这个客户里面遇到，而到另一个客户里面，其结果是缓存着的不涉及到运算过程。

一个同学 oncall 累积的经验越多，他越是能见多识广地知道某个问题是什么原因引起的。这份经验的传承并没有那么自然，所以其实我们也有整理 knowledge base，oracle 的 knowledge base 甚至是包装成产品来卖的。对于这块的反馈上面，有部分同事表示好用。我还是持中立观点，它只是提供了一个资料检查的地方，知识并不是带智能的。而且在维护上面，我们需要付出整理成结构化的知识的代价，只有结构化的知识是易于被检索的。

继续从 knowledge base 的事情往下讲，我突然冒出了个 idea – AI。

前面说过，T型人才是很难的。知识的高效检索受限于介值–专家的大脑中，其容量十分有限。当知识以其它形式组织，比如说 knowledge base，它就仅仅是一份数据而已，检索并不高效。我们最有效的得到答案的方式是，问专家。

当这个链路变得很长之后，问题传达到专家那一层，需要的传话太多，影响效率。如果有可能突破这样有限制，达到更高的效率，人类是做不到的。只有另一种可能就是 AI。AI 是有学习能力的，给它投喂 knowledge base 从而得到一个可以回答问题的机器人，比花 4-5 年去培养一个可以处理 oncall 问题的T型人才，其实训练效率要高得多。

我能想到的 idea，其它人也能想到。于是我去搜了一下，结果发现公司内已经有同事在做这样的方向了。只不过当前机器人的能力，还达不到人工智能，大概处于人工智障的阶段。AI，这是突破极限的方法，"人们总是高估短期而低估长期科技能力"，到底未来会怎么样，等未来去验证了。