线上故障应急处理： 4 年多 on call 经验总结

[swananan]

https://jt26wzz.com/posts/0007-online-firefighting-real-world-lessions-from-4-years-on-call/

最近写了一篇回忆过去故障应急的博客，写的还是挺开心的，发现自己博客没有被收录在 VXNA 节点，就自己在这里发出来，交流交流。已经尽力隐藏了很多公司相关的细节，希望不要被熟人看见，有点羞耻，哈哈。

[0x663]

还好 OP 脱离了 ON CALL 的环境了。不然高压下必出问题。

[HENQIGUAI]

写得很好，感谢分享

[doublespout]

写的非常好，特别是青海湖团建故障，是因为没有发布，导致 fd 泄漏，也是离谱。

[yNV71aaf0Wn56q9G]

写得太好了。收藏了。

[kcojkcnw]

好文，感谢楼主分享

[nick1357]

做运维的，先收藏了，等上班再看[手动狗头]

[CodeWind]

做了快三年 oncall 了，要是早看到这篇文章就好了，动作和我们一摸一样，我们多了个对研发的要求，要求发版必须可观测，可灰度，可回滚，越看越觉得你该不会是我们公司的吧

[housex]

怎么觉得哥们像是我们公司团队出去的呢

[skyrim61]

6666

[egen]

> 但是这次变量，竟然是因为我们要去团建，那一周没有发布，导致线上服务长时间跑才暴露出来的资源泄漏。
看到这个忍不住了

[laminux29]

为了发博客，买了阿里云域名，还进行了备案....

话说在博客园开个专栏不香嘛？

[whusnoopy]

写得真好

也分享一个我经常给伙伴们说的狗血 OnCall 给大家图一乐：我们的客户 A 被他的客户 B 找过来说我们的数据有遗漏，并且给了截图说 B 看到的界面跟 A 看到的界面数据不一致，但我们的客服在系统后台看 A 的数据里是没有 B 说的那几条的，当时我们正在团建爬黄山，负责这个模块的同学回想起出发前确实有上线发布过新版本，当时整个人都不好了，虽然说那个发布理论上绝对影响不到这才对，到山上能落脚的地方，开手机 3G 热点（对的那时候还没 4G 但还好已经有 3G 了），笔记本电脑连上（我曾经在大厂遇到过只要出去团建必然会有 OnCall 的魔咒，所以爬山也背着笔记本），看了许久，后台数据的确没有，最后发现特么的 B 给的截图里，表示他有数据的这个圈好像不太圆，是不是 B 用 P 的图来跟 A 闹，把这个猜测告诉 A 让 A 去跟 B 对质，然后 B 承认了是自己 P 的图……

[snitfk]

学习学习，转给团队去看看。

[xiaowangge]

多谢分享❤️

[nananqujava]

@0x663 #21 我也 on call 了半年, 不是人干的, 还有压力怪一直催, 多方打电话, 甚至压力怪就看戏

[ytmsdy]

oncall 确实挺能锻炼人的，自觉不自觉的会强迫自己去熟悉系统，学习各种各样的知识。
不过这活最多也就干个一两年，干久了，容易神经衰弱。
有段时间 oncall ，搞得看到微信跳出消息都冷不丁紧张一下。

[swananan]

@0x663 确实，好久没 on call 了 ，现在恢复了好多，居然开始怀念过去的日子了（加大剂量

[swananan]

@laminux29 博客园不符合我的审美，哈哈

[qingh]

真正的实战总结，收藏了。

[AstroProfundis]

写得不错，一看就是真干过的老手了，相对偏研发视角
我第一份工作就是故障管理，楼主流程里面报故障和做复盘分锅的角色，一度怀疑楼主是熟人；特别是那个什么发错环境出故障的事情，我见过粘贴命令贴错了终端窗口搞出来的故障恍惚以为是同一件事情（

这些东西见多了之后很自然就能明白啥叫对生产环境保持敬畏（（