★ FEATURED ARTICLE 工作里有一半时间在修 bug 和处理线上问题简历上一行都没有。这是大多数工程师简历的现状。原因有两种。一种是觉得修 bug 不算成果成果得是「做了什么功能」另一种是觉得写出来像在自曝「我们系统出过这么多事」。两种想法都不对但也确实不是所有修 bug 经历都值得写。先判断值不值得写三个标准满足两个就值得写一、定位过程有技术含量。看一眼日志改一行代码这不值得写用堆快照、火焰图、抓包、慢查询日志一层层缩小范围最后找到一个不显然的根因这值得写。区别在于前者任何人都能做后者需要方法。二、影响面在线上核心链路。个人开发环境的问题不写测试环境的问题一般也不写。线上、涉及资金或核心业务流程、有明确影响范围多少单、多少用户、多长时间的写。三、有沉淀。修完之后加了监控、写了排查工具、推动了规范、同类问题归零。有这一条一次救火就变成了一项能力。三条都不满足的比如「修复了若干前端样式问题」合并到日常工作一句带过就行。事故记录和能力描述的分界线同一件事两种写法2024 年 3 月订单服务因内存泄漏宕机 2 小时事后修复订单服务每隔 3 到 4 天出现一次 Full GC 风暴后 OOM重启后恢复。 用 jmap 导出两个时间点的堆快照对比定位到线程池复用场景下 ThreadLocal 未清理导致 MDC 上下文持续累积 先以定时重启止损48 小时内上线修复并在网关入口统一清理同类问题增加堆内存增长率告警此后未复发第一种是事故记录它回答的是「发生了什么」视角是当事人读的人得到的信息只有「这个系统出过事」。第二种是能力描述它回答的是「怎么找到的、怎么止损的、之后怎么不再发生」视角是排查者。读的人得到的信息是这个人会用工具、会区分止损和根治、会做长期措施。分界线就在这里写现象和结果是事故记录写方法和措施是能力描述。现象和结果只是背景方法和措施才是主体。追问会落在哪写了这类经历面试官的问题通常集中在四处为什么用这个工具。为什么是堆快照对比而不是直接看 GC 日志为什么抓包而不是加日志。这问的是你对工具适用范围的理解。为什么排除了其他假设。内存泄漏有很多可能原因你是怎么一步步排除掉连接池、缓存、大对象这些的。这问的是排查方法是不是系统性的。止损和根治的时间差怎么决定的。为什么先定时重启而不是直接回滚48 小时的修复窗口是怎么定的。这问的是你的工程判断。复盘是谁写的。如果复盘文档是你写的追问会转向长期措施如果是别人写的对方会想确认你在其中的实际角色。四个问题都能答这一条经历就撑住了。它比多数功能开发经历更有分量因为排查过程没法靠背诵准备。几类不值得写的自己写的 bug 自己修定位过程也没什么含量。这种写出来对方只会想「为什么会有这个 bug」。没找到根因靠重启或者加机器扛过去的。写了会被问根因答「没找到」不如不写。全是「配合排查」。别人定位你改代码或者别人改代码你验证这类不要单列。把故障时长和影响写得很大以显得重要。「导致全站不可用 4 小时」接下来的问题会是 SLA 和责任划分这不是你想聊的方向。影响范围写准即可不用放大。责任问题怎么处理简历上不用写这个 bug 是谁写的也不用写是不是你的锅。面试官问「根因是什么」问的是技术根因不是责任归属。如果确实是自己的问题面试里被问到坦然说然后把重点放在从中建立的措施上。回避会显得心虚纠结会显得情绪化都不如直接说。多次同类救火合并写处理过五次不同的慢查询问题不要列五条。合成一条建立慢 SQL 排查流程接入 pt-query-digest 定期分析输出 Top 10 慢查询周报 半年内处理索引缺失、隐式类型转换、深分页等问题 20 余处慢查询数量从日均 400 降至 30 以下这样写把「救火」变成了「建流程」层次高了一级也更容易撑住追问。写完自查每条故障类经历找一下有没有工具名、有没有止损和根治两个动作、有没有长期措施。三样缺两样的要么补要么并入日常工作一行带过。最后没处理过线上问题的工程师等于没上过真实的战场。把排查方法和长期措施写出来故障经历就是简历上最难被质疑的部分。
阅读完成 · 觉得有帮助？
