前段时间，朋友圈被《我是技术总监，你干嘛总问我技术细节》刷屏了，微信群里也有不少讨论。
就我所看到的情况，各种意见都有：
- 有人认为“技术人不能丢掉技术”。
- 也有人认为“工作做到上面都是考验人性”。
- 还有人认为“工种不同，技术细节不清楚很正常”。
借这个机会，我想谈谈自己的经历。十多年前，我曾经去 BAT 中的一家面试过(到现在也是我唯一一次 BAT 的面试经历)。
当时刚毕业几年，写代码解决一般问题任务已经“得心应手”了，各方面知识也懂一点，会搭 MySQL 的 Master-Slave，会用 Memcache，HTTP 协议也基本熟悉……
在那个许多公司还在为 100 万 PV 就头疼的年代，这样的水准在技术上算比较领先了。所以我以为，这次面试应当是十拿九稳。
结果大大出乎我的意料，可以说是“惨败”。我熟悉的领域一个也没有谈起，我解决的问题一个也没有问到，却问了一大堆“技术细节”问题。比如一个 Int 变量要占几个字节，字符串的查找，替换怎样最快……
在学校里，我最熟悉的 Java，C 和 C++ 的课程只是囫囵吞枣，这类知识早就忘记了，做题比较多的也是离散数学、数值计算等等，工作了之后一直做 Java，根本不会深入到这样的细节。
所以，面试结果用“惨败”来形容，是一点不夸张的。
当时我觉得很委屈，对已经工作的人，为什么要考这些细节的书本知识?而且是日常开发根本用不到的书本知识?难道不应当重视实际经验吗?
等再工作几年我逐渐发现，这些原本不是“细节的书本知识”。如果你要解决的问题稍微有点挑战性，没有现成工具可以利用，只能靠自己思考和分析，或者借鉴其他现成工具的原理，就离不开这些看不起的“细节知识”。
比如，后来(一直到如今也是)我经常说：“好的程序员不会凡事都靠实地测试，而是会预先计算”，就必须用到这些细节的知识。
拿如今最热门的“高并发”应用来说，单个节点每秒处理多少个请求，每个请求包含哪些数据，每部分数据的大小是多少，机器的带宽是多少，网卡的吞吐率可以达到多少……
能把所有这些数据综合起来，心里就大概有了把握，而且这种理性结算的结果，远远比“写个程序去压测”要靠谱得多。
所幸我在这次面试失败之后几年就领悟到这个问题，于是又花时间(那时候 996 还很少见)把数据结构、算法、网络、系统结构等等基础知识全部梳理了一遍。如今回想起来，当时的这轮梳理确实值得，自己后来受益匪浅。
行业内有句话说：搞技术的不玩虚的，就服实打实的解决问题的本事。我认为这句话是成立的。
在我走上技术负责人的岗位后，也解决过不少技术上的疑难杂症，尤其是我“本职”领域之外的问题。
比如困扰大家很久的接口概率性失败的现象，最后诊断出是证书问题;又比如 HTTP 能通 SSH 不能通的问题，最后发现是 TCP 的 TIME_STAMP 配置问题;再比如面对不稳定的遗留系统，迅速拿出方案隔离不稳定部分，为技术改造赢得时间……
能解决这些麻烦的问题，自然能赢得各团队伙伴的信任，不过我并非这些领域的专家，只是多亏了之前对基础知识和技术细节的掌握，再加上学习和分析而已。
在很长的时间里，我一度非常相信“技术负责人就是要懂细节”，否则内心也很慌张。对细节的把握，让我感到踏实、放心。
同时，我也热衷于在面试中考察候选人对细节的了解，如果不了解细节，这个人就很浮躁。
换句话说，优秀的技术人员应当像把篦子，一路梳理过去，各种细节了如指掌，所有的问题原形毕露，这样工作才称职，自己才放心。
然而，随着面临问题的复杂，职位的升高，我发现自己日益焦虑，因为这是“不可能的任务”：
- 技术细节太多了，想要对每个细节都了如指掌只会让人疲惫不堪。
- 技术人员也太多了，想要在每个人那里都保持权威也会让人高度紧张。
到最后我发现，这已经不是一个用不用功、专不专心的问题，因为精力有限，要照顾的方面又太多，所以无论你多么用功，多么专心，都会感到力有不逮、左支右绌的局面。
看来，篦子这种模型有点问题——篦子当然好，但通常都不长，一手能够拿住，如果要覆盖很宽的面，就非常吃力。
那么，该怎么办呢?如果自己找不到出路，我尝试去观察其他人是怎么做的。观察一段时间之后，我还真有很大收获。
最大的收获是，我发现没有人可以了解所有的细节。如果光看媒体，似乎很多“大佬”无所不知、无所不晓。
但仔细分析就发现，“大佬”往往只有在自己熟悉或者有充分准备的领域可以谈得很深，遇到自己不熟悉的领域，他们要么不发声，要么说错了但会有公关团队去掩盖。
不可否认，一些企业里的高级管理人员或者创业者仍然保持了早期的工作作风，或者大概是为了保持“权威的存在感”，喜欢抓细节，喜欢就细节问题发表自己的看法。
在面试中，也有一些面试官喜欢过分追究细节，不断拿特别细特别专门的问题来考验候选人，营造自己的优势。
但仔细观察往往发现，这些人看起来无所不知，但如果是在他们不熟悉的领域，这样做多半没有好处。
“抓细节”往往导致本末倒置，“随时就细节问题发表看法”往往容易适得其反，“用细节问题让候选人难堪”可能错过有潜力的候选人，这一切，都抬高了企业的运营成本。
我经常说，IT 行业可以从其他领域借鉴经验，对技术细节的把握也是如此。以我对其他领域的了解，许多成功的技术领导者，其实并不关心细节，至少不会在细节上花太多的精力。
比如上世纪“太空竞赛”中，美国载人航天工程推进部分的总工程师冯·布劳恩，他最关心的是火箭分几级最合适，登月计划到底采用哪个方案更好，是地球轨道交会还是月球轨道交会。
至于火箭制造的各种细节，其实他没有精力去操心，也轮不到他操心(参考《系统问题应当如何排查?看看 NASA 著名的“10 厘米发射”吧》)。
再比如我军的高级将领里，真正会打枪、枪打得好的没有几个，但这并不妨碍他们叱咤风云、攻城掠地。
更典型的例子如 1955 年授衔上将的张爱萍将军，在后来主抓“两弹一星”工程，指挥我国第一颗洲际导弹发射时，丝毫没有技术背景的他却赢得了大批专业技术人才的信任和怀念。
这其实是普遍现象。上世纪中情局的若干高科技工程中，主管 Parangosky 并不是理工科出身，但这不妨碍他受到大家的一致尊重，被公认为“奇迹创造者”(参考《K-129，CIA“偷天换日”的工程奇迹【二】》)。
所有这些例子充分说明，不管是否技术出身的技术领导者，都不必过分强调“技术”，不必强求事无巨细全部掌握。相反，强求“面面俱到”反而显得荒谬。
我曾经写文章介绍过我国著名的理论物理学家束星北教授(参考《看，这就是束星北先生》)。
在十年动乱中遭受迫害。有一次，他被要求爬上电线杆去接电线，这种任务实在为难一把年纪的束星北，结果管制他的人反而说起了风凉话：还什么搞物理的大学教授呢，连个电线都不会接……
看看正反两方面的例子，我感到有点惭愧，因为我自己许多做法就是反面典型。
比如希望掌握所有细节，不但消耗了自己的精力，也没有给其他人放手工作的信任感;再比如拿细节去要求候选人和其他同事，有时候甚至到了“刁难”的程度，其实并不利于客观判断他们的水平和贡献。
所以在观察、比较、思索了很久之后，我的结论是：技术领导者的精力是有限的，他们的能力模型既不应当是“博而不精”的宽泛，也不应当是“深而不广”的专注，甚至业界流行的“T 型人才”也不准确。
对技术领导者来说，最合适的能力模型应当是钉耙型。
说到“钉耙”，许多人第一个想到的大概是猪八戒的九齿钉耙，我们就拿九齿钉耙为例。
钉耙很宽，扫出去可以覆盖一个面;同时钉耙又有许多齿，可以在某些具体的点上深入。
不过无论如何，太上老君只有那么多神镔铁可以用来打造九齿钉耙，在资源有限的情况下就得具体分析，考虑钉耙到底有多宽，有几个齿，每个齿应该有多深。
技术领导者可以动用的全部精力，就是打造钉耙可以用到的全部原料。每一名技术领导者都要思考，这些精力该如何分配，是照顾更宽广的面，还是照顾更深入的点?照顾哪些点?照顾到多深……
身为技术领导者，重要的不是你永远在每个点上都扎到很深，而是应当具备“无论哪个点上出现问题，需要你的时候都能深入扎进去”的能力。
换句话说，重要的是能及时识别和发现问题，及时了解问题，及时给出靠谱的解决方案。
哪怕当时答不上来，但是能通过询问、学习、分析能迅速定位和解决问题，就是合格的技术领导者。
而且与一次成型的钉耙不同，技术领导者必须时常“吊着一股劲”，那就是根据具体情况识别出最重要的问题，据此调整自己的精力分配和能力组成：
- 如果运维弱一点，就要在运维这个点上扎深一点。
- 如果前端弱一点，就得在前端这个点上扎深一点。
- 如果暂时各团队状况都还不错，那就把覆盖面铺更广一点，多为未来做规划……
从这个角度，也就可以理解为什么许多人说领导的关键就在于“找到合适的人，放到合适的位置上”，只有这样，领导者的钉耙才可以铺得很宽，不必在具体的细节上耗费太多。
但是，如何找到合适的人，如何放到合适的位置，这恰恰是需要有足够的细节知识才能作出可靠判断的。
总之一句话，各公司的情况不同，同样公司在不同阶段的情况也不同，合格的技术领导者一定需要具备“柔性”素质，能融入百般场景，解决万千问题。
这也解释了为什么许多非技术出身的领导者，也可以做好技术团队的管理。
原因大多是他们眼光精准、视野开阔、思维严密，并且对未来有充分的预见，时常能识别出当前最重要、最要紧的问题，投入资源去解决，确保一切处在有序、可控的状态。
当然，还少不了对技术人员的尊重，对技术规律的敬畏。
在此之外，技术出身的技术领导者还有额外的优势。他们对基础知识的掌握，对细节的了解，让他们即便面对陌生领域，也能够迅速搭起“从已知到未知”的桥梁，迅速得到“内行人”的视角，迅速和大家找到共同语言。
非技术出身的领导者在这方面就要吃力许多，所以也只有少数极高明的人能做得好。
认同这一点，许多问题也豁然开朗了。身为技术领导者，最重要的是保持对技术的敬畏，以及不排斥谈细节的意愿，所以虚浮的作风是万万要不得的。但同时，也不必苛求自己时刻了解所有细节。
在工作中，我们可以经常询问自己：
- 当前我是不是在解决最要紧的问题?
- 这个问题的背景我是否充分认识了?
- 对于解决方案我是否有足够的了解和把握?
- 我目前没有具体关心的那些问题，是不是有靠谱的团队在用靠谱的方式解决?
如果这些问题的回答都是肯定的，那么即便有一些技术细节不了解也是相当正常的，大可放心继续工作。
如果有一个问题的回答不是肯定的，那么工作就还没有做到位，这时候即便你掌握了各种技术细节，大概也不算称职。
对自己是如此，对其他人也是如此。至少在我看来，在招聘技术负责人时，没有必要过分纠结技术细节，而应当侧重考察对方的技术素养，所以重要的不是对细节了解多少，而是工作习惯有多细致。
具体来说，技术细节的问题，大概可以分为三类：
第一类，是候选人自称做过，也着重投入过精力的领域。合格的候选人，对这些细节是应当完整掌握的，并且其掌握应当能互相支撑印证，构成完整的技术决策网，不能有“想当然”的环节。
如果这个领域的细节答不出来，或者经不住追问，那多半是很有问题的。
比如候选人说自己做过服务治理，那么能谈的不应当只是和流行的 PPT 一样，大而化之地列举服务治理的好处，几个主要组成部分。
还应当清楚服务注册流程、服务生命周期定义、异常(尤其是安全)情况处理、扩缩容规范和限制等细节信息。
如果谈不出来，“做过服务治理”的经历就应当打个折扣。
第二类，是候选人没有专门做过，但是不管解决哪个领域的问题都需要具备的基础细节不可缺少。
比如“一个 Int 类型变量占几个字节”的问题就是如此，系统要做复杂一点，在分析和设计的时候，这些知识是不能空缺的。
候选人还应当了解其它的基础细节，比如光在真空中的传输速度是 30 万公里/秒，而在光纤中的传输速度是 20 万公里/秒。
这样分析技术问题时才有根据，比如北京到上海的直线距离大概是 1200 公里，所以单程理论传输时间大约要 10ms，则 Ping 值在 25-30ms 左右是正常的，没有更多优化空间优化。
但南京到上海的距离只有不到 300 公里，如果 Ping 值也在 30ms，则网络上估计还有些问题。
这样的细节知识，就是前端、后端、运维都可以用上的(此处数据经过老高(高春辉)确认)。
第三类，是候选人没有专门做过，但也不那么基础的细节。这类细节如果答不上来，其实并不是很要紧。
很难想象做社交的技术人员能懂得音视频处理的细节，做金融的技术人员能懂得游戏开发的细节。只要职位上升到一定的高度，都不可能在技术细节上面面俱到。
就像上文说的，只要候选人有足够的技术素质，在宽度上能覆盖这些领域，能找到靠谱的人、评估出靠谱的方案，或者在深度上能保持(经过一段时间的学习了解)介入能力，这些问题多半都是可以解决的。
所以我的最终答案就是，“能力上不求全责备，意愿上不推三阻四”。
如果面试遇到细节问题，最真诚的答案大概是这样：“我是技术总监，我可以把几个重要领域的细节全部谈清楚，但其他领域的细节我未必知道。不过我通常能判断一个不那么熟悉领域的方案是否靠谱，如果再多给我一点时间，我相信自己能答上来”。
