《带团队，不轻易放弃每一个战友》分享了我职场第一位经理yuz，教导我“遇到问题不仅要思考，也要及时提问，暴露问题”，并“在我遇到困难的时候，指导我，帮我解决问题”的故事。
今天，分享我职场第二位经理fengxq，手把手指导我的故事。
fengxq(doubhor)是当时百度hi后端团队，对业务和系统最熟悉的架构师，他晋升经理之后，让我负责cs(chat-server)模块，这完全在我意料之外，我当时，只是一个加入团队不到2年的新人。
“额，有点怕搞不定。” “怕啥，不是有我在么，出了问题，我扛着。”
系统接手之初，doubhor会和我讲解cs的上下游模块，系统框架，核心业务流程，异步流转状态机，历史坑...等等等等。 画外音: 百度hi团队有个好习惯，代码必有owner，冤有头债有主，coding要留名。所以，搜doubhor，或者“add by sk”能够找到我们曾经埋的坑，或者填的坑。
没过多长的时间，我就能照着sample code写新接口，实现新功能了。
写功能不难，真正考验技术功底的，是排查不能稳定复现的线上问题。 画外音：排查性能问题，也非常考验功底。
这次，老板Robin反馈，发送的一条聊天消息，接收方“疑似”没有收到。 画外音：兄弟姐妹们，你用“重启下试试”来搪塞过上下游么？
我初步grep了日志，有发送消息的日志，但要怎么确定接收方是否收到呢？由于初次排查类似的问题，有点蒙圈。
“排查的怎么样？” “没啥思路，从cs日志看，应该发送成功了。”
doubhor凑过来，开始画一条消息发送的流程：
“ts是与用户建立连接的模块，
cs是消息处理模块，
rt(router)是消息转发模块。”
“你这是步骤3的日志，能说明消息成功投递给rt了，并不能代表接收方收到。”
接着，doubhor拿出Excel，一步一步确认日志：
1.ts收到消息，日志有
2.cs收到消息，日志有
3.cs投递消息，日志有
4.rt中转消息，日志有
5.ts中转消息，接收方收到了
6.ts收到ACK，日志有
7.cs收到ACK，日志有
8.cs投递ACK，日志有
9.rt中转ACK，咦，你看这个地方，rt在中转ACK的时候，发现发送方在线状态置为“离线”了，所以ACK中转失败了，这样发送方会“以为接收方没有收到。”
“你看你看，这期间ts，cs，rt果然有发送方断开，设置离线的请求日志，这下就说得通了，因为断开没有收到ACK。”
这不是doubhor第一次手把手指导我，但这一次，我的印象最为深刻。doubhor是一个极其细心，极其耐心，思路清晰的leader，有了这一次讲解，im系统中消息投递的流程，我相信自己永远也不会忘记。 ...
多年以后，在我做一线leader的时候，我会尽量手把手将自己的功力传授给小伙伴。我在做二线leader的时候，我会尽量把自己的设计，管理，业务经验传授给leader，并要求，所有leader必须言传身教，手把手指导员工，让他们变成更牛逼的人。
“怕啥，不是有我在么，出了问题，我扛着”，有一个这样的leader，会觉得无比的温暖。多年以后，心里仍是满满的感激。
我是幸运的，你呢？
相关文章： 《带团队，不要轻易放弃任何一个队友》
