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

粗略的看了一下，感觉是不错的分享，收藏了有空看，点个赞

喜欢文中的配图，是最近很火的吉卜力风格的吗

另外还有一个特别的技巧，如果在屏幕共享的时候，你甚至不想去问 chatGPT ，毕竟如果是一个愚蠢的问题，一般都会觉得挺尴尬的。这个时候，你可以快速的阐明你的意图，然后把验证任务打包分配出去，指派给会上在场的另外一个同学，这样就可以完美避开了这个尴尬局面

有一个运维大哥，当时发布的时候，先去抽烟放松了一下，然后上来操作的时候，就把版本发错了中心机房，直接 game over ，引发了故障。但是在故障 review 上还是谈笑风生，甚至可以说是挥斥方遒，各种分析系统的根因，熟练的安排各种 action ，丝毫不受影响。我当时觉得不管怎么说，这种心态还是值得学习的。

这两段太真实了...

业务系统功能回滚怎么做呢，看了蛮多博客都说要做功能回滚，但是一直没看到具体的操作案例

不是，我是最简单让 chatGPT Dall.E 3 绘图模型帮我生成的，只是要求是动漫风格。用的还是免费版的 chatGPT ，虽然有冷却时间（一次只能画 3 ，4 张吧），但是我很满意，毕竟单独写文字有点干巴巴的，有图片感觉视觉上都好看不少

写得挺好的
以我在字节当了几年牛马也就是那么三板斧
一是 出现问题先止血
二是 发布新版的时候要做到可观察 可监控 可灰度 可回滚

一般会分配置回滚和二进制回滚，具体得看你当前系统相关配置系统和发布系统是怎么设计的了，不过这些都是核心保命的东西，一般都是很傻瓜式的一键操作。

还有一个就是 做方案是不能只做需求方案 还得做应急方案 sop, 就是出现问题了 你又不在现场 有人能按照你的 sop 恢复

是的，sop 也是必做的，但是故障现场还是得具体问题具体分析，如果相关功能负责人不在，其余不熟悉的人无脑照着 sop 来恢复，我觉得很大概率会雪上加霜。
另外，就是故障发生的时候，相关人士有一口气在，就必须得上线，这是隐藏红线了，哈哈（🐶🐶保命，我并没有共情资本家，只是既然干了这行，就只能拥抱这样的规则

写的不错，运维过程中确实有很多案例非常有意思。我当年遇到过：地铁挖断光纤、机房停电、跨网通信不通、缓存泄漏、句柄泄漏、并发多异常退出。。。其中每一个拿出来都可以讲个几千字的原因分析和反思出来

感触很深，曾经遇到过修复版本的问题会引发更大的问题，不过当时先灰度了一下，避免了这个版本。

写的真不错👍
看我司的稳定性组就在做这些事情，故障止血、指挥、复盘，蛮专业的。
可惜我是前端，很少参与，有故障一般回滚即可。

写的很好啊，有很多点我也有类似的经历。

我补充一点关于定责和复盘这些非技术的事情。因为这些年我做过一线、负责人和老板，所以各个角度都有体验。定责复盘，实际上可以分为负责人（项目、组织经理）向老板汇报、向团队成员复盘两个部分，只是经常放在一起，而且以前者居多。

我的建议是负责人要勇于承担责任，团队成员的失误就是负责人的失误。即使承担责任压力很大，也切忌甩锅。（开发、测试和运维团队之间可以适当相互帮忙背锅，分担一下压力。）从老板的角度上说，损失已经发生了，也不会非要把直接责任人找出来开掉。老板也需要台阶下，不然后续还怎么继续展开工作。从权责对等的角度上讲，如果一个团队总是不粘锅，那它就不重要，所以是极有可能最先被优化掉的那个。

作为负责人，向团队成员做技术复盘的时候，更要注意对事不对人。本质上换个人并不能解决根本问题，能解决问题的只有排除人为失误的可能。那种出事临时工背锅的思路是不利于带团队的，人心散了。

写的太好了

学习了，前几个月出事故的时候手忙脚乱脑子空白，还是得多做些准备

不错不错 有大帝之姿

给 OP 点个赞，能沉下心来总结，写的太棒了

运维工作类似急诊、消防，年轻没经验干不了 ，年老没精力受不了

写的很好，感觉对我们这种刚工作几年的很有帮助

看完了，看的血压上来了。
真的受不了在休息的时候突然来个电话会议喊我排查问题，一点几把边界感都没有，就不能等到工作日再看问题？党的 XX 届全国代表大会都能推迟延期，什么勾八项目比党开会还重要？
该休息休息，什么故障都没有身体熬夜加班出了故障重要。不用焦虑，天还塌不了。

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

写得很好，感谢分享

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

写得太好了。收藏了。

好文，感谢楼主分享

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

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

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

6666

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

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

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

写得真好

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

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

多谢分享❤️