丢耳机和故障排查有啥关系？
目录
上周把耳机搞丢了。
找耳机的过程，跟线上故障排查简直一模一样。
告警阶段
周一早上到公司，习惯性摸口袋拿耳机——耳机不在。这就是告警。
但告警得太晚了。耳机是上周五丢的，整整晚了两天才发现。要是耳机能发个"我离开耳朵超过 5 分钟"的告警，也不至于等到周一才发现。
快速止损
先快速找找：书包、口袋、办公桌抽屉。都没有。
无法定位根因，先快速止损——临时买了个便宜有线耳机顶着。就像线上服务挂了，先重启进程让业务跑起来，再慢慢查问题。
二分定位
开始梳理时间线：
周五上班 → 会议室 → 地下室 → 商铺吃饭 → 接驳车 → 地铁 → 打车 → 回家
周五开会时耳机还在耳朵上，这是最后一个已知正常状态。
回家后确认不在，这是第一个已知异常状态。
开始二分：
第一轮排查
- 问司机：没落在车上
- 翻监控：回家路上已经没有耳机了
范围缩小到：吃饭 → 接驳车 → 地铁
第二轮排查
翻吃饭时的照片——耳机还在裤子里。这是关键日志！
去问商铺老板，也说没看到耳机。
范围缩小到：接驳车 → 地铁
第三轮排查
- 让行政帮忙找会议室：没有
- 问接驳车司机：没有
最终定位：地铁
提交失物招领，等待结果。
复盘与 SOP
这次排查效率其实挺高，但缺少一个 SOP：
- 告警前置：贵重物品应该设置分离提醒
- 日志规范：养成随时拍照记录的习惯
- 排查模板：时间线梳理 → 二分定位 → 关键节点确认
- 应急预案：备用耳机应该常备
一点感悟
找耳机和查故障，本质上都是在信息不完整的情况下，通过有限线索快速定位问题。生活处处是技术，技术处处是人生。
唯一不同的是——耳机丢了可以买新的，线上故障造成的损失可没法重来。
Update：地铁失物招领处回复没找到。看来这次故障需要重新设计架构了。
彩蛋
这篇文章其实是用 Claude Code 写的。下面是我当时随手记的排查过程，原汁原味：
找耳机的过程，其实就是排障的过程。
耳机丢失 -> 告警。--> 没有及时发现
快速找找，可能的地方，书包。没有。
无法及时定位根因，先快速止损。（临时买个有线耳机）
二分快速定位问题时间点。
时间线梳理：周五上班->会议室->地下室->商铺吃饭->接驳车->地铁->打车->回家。
周五开了会，周五还在
看监控，回家的时候已经不在了
打司机的电话，没落在车上
吃饭的时候拍了照（多打日志的重要性），发现还在 ->缩短到 吃饭->接驳车->地铁
去餐厅问 -> 没有 -> 缩短到 接驳车->地铁
寻求帮助：让行政帮忙找了会议室、接驳车 -> 没有 -> 缩短到 地铁 这一个地方
提交地铁失物招领
少了：SOP的制定
从一堆零散的记录到一篇完整的文章，这就是 AI 工具的魔力——帮你把碎片化的思考整理成体系化的表达。
彩蛋的彩蛋
本文除了代码块以外的内容，全是 AI 写的——包括上面那段彩蛋。