从执行到负责：接住一个模块意味着什么
GreenTerminal
3 min read
接住一个模块，本质是从"做对事"切换到"对结果负责"。很多工程师在晋升或轮岗时被交托一块代码，第一反应是把它跑起来、改好 bug，但这只是执行的延续。真正的接住，意味着线上出问题时，第一个被叫醒的是你，而没人再替你兜底。
执行者和负责人的视角差
执行者问的是"这个功能怎么实现"。负责人问的是"这个功能下线了谁会受影响、恢复要多久"。同样是处理一个接口超时，执行者去加超时重试，负责人会先确认这个接口挂掉会不会引发资损、有没有降级开关、监控是否覆盖到了真实用户路径。
我见过一种典型情况：某人接手模块后把单元测试覆盖率从 30% 补到 80%，但线上还是出了一次事故。复盘发现，缺的不是测试，而是对依赖方调用链的理解——他根本不知道上游会在大促时把 QPS 翻五三倍打过来。负责不是把既有的事做得更漂亮，而是把没人管的部分纳入视野。
接住模块的三个动作
第一，画清边界。花半天把模块的上下游依赖、数据流向、触发条件写下来，哪怕只是给自己看的一页笔记。边界不清，你永远在替别人擦屁股，也永远说不清"这不是我的锅"到底是否成立。
第二，建立可观测性。至少确认三件事：关键路径有没有日志、有没有告警、出问题时能不能在一分钟内定位到是模块内部还是外部依赖。经验上，新接手模块的头两周就该把告警配齐，而不是等第一次事故来教。
第三，准备失败预案。给模块想一个最坏的失败场景，写清楚"如果 X 崩了，先做 Y 止血，再查 Z"。这个文档不必复杂，但要在你不在场时别人也能照着做。
反例：负责不等于不放手
一种常见误读是把"负责"等同于"所有事我来做"。结果负责人成了单点瓶颈，休假时系统无人敢动，团队也培养不出第二个人。判断标准很简单：如果模块出事只能你一个人解决，那不是接住了，是绑架了。
健康的负责包含授权和交接能力。你能把背景讲给同事听，让他独立处理一次线上问题，才是真正稳定地接住了模块。
边界：哪些不该你接
不是所有交到你手上的都该全盘接收。如果模块没有文档、没有监控、前任已离职且无人能讲清逻辑，盲目"接住"会让你背上一个定时炸弹。经验上，接手前先确认三件事：有没有回滚手段、有没有 owner 愿意在过渡期答疑、出问题有没有升级路径。三项缺两项以上，先谈条件再谈接手，这不丢人。
你接住没接住的检验
不用问主管，问自己三个问题：
- 模块凌晨三点挂了，除了你还有谁知道先查哪里？
- 你能说清楚这个模块最危险的一个假设是什么吗？
- 如果下周调你去别的项目，模块的正常运行会受影响吗？
三个都答得上来，才算接住。答不上来，你只是暂时在写它的代码。
1 view
0 likes
0 comments