入职半年,我提交代码的速度全组最快,加班时长全组最长。直到生产环境崩掉那天,我才发现自己完全不知道怎么开始排查。

Slack 消息以每秒十几条的速度往上刷,我的心跳比通知还快。而 senior 开发 Youssef 只是拉了下椅子,戴上耳机,像处理日常需求一样开始逐行看日志。

「快」是一种幻觉

「快」是一种幻觉

新人时期的我把「关闭工单速度」当成核心指标。早走的人被我默认划进「不够拼」的阵营,晚走的自己则有种隐秘的优越感。

Youssef 从不加班。每天六点准时消失,但第二天总能给出比熬夜方案更干净的实现。我当时把这归结为「他经验多」,没意识到这是两种完全不同的工作模式。

崩溃现场他花了 40 分钟定位问题,修复只改了 3 行。我在旁边看着,突然意识到自己过去半年写的「快速修复」里,有多少会在未来变成同样的生产事故。

senior 的「慢」藏在哪

后来我开始观察 Youssef 的日常节奏。他写代码前会花 15 分钟画流程图,不是给别人看,是给自己理清边界条件。代码审查时他逐行追问「如果这里返回空,下游怎么处理」,而我之前看到能跑就过。

最反差的是他处理阻塞的方式。遇到依赖方延迟,我会反复刷新 Slack 催进度,他直接写 mock 数据继续推进,同时给依赖方发一封不带情绪的时间线邮件。两件事并行,互不干扰。

这些习惯从不写在周报里,代码仓库也看不到痕迹。但它们决定了一个人能否在服务器崩溃时,把心率控制在正常范围。

我偷学的第一招

我偷学的第一招

现在遇到线上故障,我会先强制自己离开键盘 30 秒。倒水、站起来、或者只是盯着屏幕但不碰鼠标。这个停顿足够让肾上腺素回落,避免「赶紧改点什么」的冲动型操作。

Youssef 后来告诉我,他早期也经历过 panic 阶段,直到发现 80% 的故障恶化都来自「第一反应式修复」。坐得住不是性格,是训练出来的肌肉记忆。

上周我独立处理了一次缓存穿透问题,从发现到解决用了 52 分钟。团队群里有人夸「处理得稳」,我只回复了一个 。没人知道我在那 52 分钟里,把 Youssef 拉椅子的动作在心里重复了多少遍。

你现在遇到线上故障的第一反应是什么?是打开日志,还是先刷新监控面板看有没有人发现?