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

[swananan]

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

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

[Glauben]

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

[maxwellz]

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

[yzqn]

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

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

这两段太真实了...

[wuyiccc]

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

[swananan]

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

[kingcanfish]

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

[swananan]

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

[kingcanfish]

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

[swananan]

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

[opengps]

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

[celiachu207]

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

[jydeng]

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

[kuanat]

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

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

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

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

[ponng]

写的太好了

[lilyou]

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

[XuHuan1025]

不错不错 有大帝之姿

[z67nnciQnb7r8bLf]

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

[timeisweapon]

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

[gxy2825]

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

[0x663]

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

[0x663]

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

[HENQIGUAI]

写得很好，感谢分享

[doublespout]

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

[yxc]

写得太好了。收藏了。

[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]

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

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

[AstroProfundis]

@AstroProfundis 发现楼主果然是前司的，怪不得这套流程那么眼熟 hhhh 只不过估计和我没有同时在职（

[Higurashi]

@0x663 #20 表示我也很遭不住这种，除非给我够多东西，我心里还是不那么舒服

[retain]

好文, 值得看

[Int100]

写得真好，个人也有一段 on call 的经历，压力真的大，尤其是告警来的时候……

[speedmancs]

准备好详细的运维手册，sev2 15 分钟内搞不定立刻升级，开 bridge ，到处摇人，先 mitigate 然后再做 RCA.

[speedmancs]

rollback 是必须的，我们现在用 k8s, terraform 配置管理的 release ，做 release 时必须得带 rollback 选项，要不然不批。

[speedmancs]

我正在 oncall, 早上接到一个警报，一看 dashboard, 一堆超时, API 5xx
一看还是个很重要的客户，直接上 k8s 集群看, 一看两个起了 30 多天的 pod 某个资源 util 99%.....但是系统负荷不算太大。

不管了，直接一个一个重启 pod
五分钟后一切正常，警报消除，开始排查日志，到处找人分析原因。最后也没查出个所以然，只能写个 tracking ticket, 然后跟经理和组里通报一下。

[speedmancs]

oncall 实际上就是值班的，可能对出错的系统也不是很了解，关键是要在短时间内处理这些问题，找到对应的人，该升级就升级，该摇人就摇人，最怕那种闷声大发财，一声不吭在那哼哧哼哧分析研究 2 个小时。。。。

[speedmancs]

我们以前有个哥们，oncall 时漏了好多警报，还有有 backup oncall, 后来这家伙说自己手机坏了。。。。然后开了个批斗大会把他狠狠批判了一顿。

[lqw3030]

值得学习，点赞👍

[dreampython]

拜读 OP 的文章，其中“比如说周末拿出一张大白纸，什么都不看，在白纸上开始画自己业务系统的运作流程”对我帮助最大。
我是一个 SRE ，一直找不到萦绕在心头的不踏实的来由，现在知道是没有熟练掌握产品架构和数据流的原因。
已经拿着大白纸开始画数据流了。

[YOUXIAZ]

写的很好，受教了

[zhoudaiyu]

本人也是 SRE ，非常受用，感谢您！期待下一篇文章，分享一些通过回滚变量后仍不能解决故障的 case 。

[dustynight]

写的很棒，很多时候看着文字都能回想起自己的一些工作经历，抛砖引玉分享一下我的想法。
0. 最重要的一点，出了问题先恢复业务。不要想着当场 debug 发布修复，先把业务恢复了再说。有发版就回滚，改了配置就改回来，总之发生问题之前，对生产环境做了什么修改，赶紧改回来。
1. 冷静。很多时候问题跟因都不复杂，只是当时太着急了，没找到原因。时刻对自己说“天塌不下来”，我只是个小虾米，捅破天+1 +2 先背锅。
2. 每一次发布，都要做好回滚预案。新功能的开关，灰度等等。不要觉得就一行代码的变更加开关麻烦，出了事真能救命。
3. 系统留一些人工干预的口子，保留直接上手洗数据的能力。我碰到过一些问题，最终是动用了全组人，手工一点点调用 API ，把数据洗回来了。

[vizResh]

点赞+1

[unused]

遇到过客户不接受临时止血方案，要求先找根因

[HXM]

看完了，很棒的分享，顺便问下博客用的主题是什么？

[levelworm]

@speedmancs #47

大佬是腾讯还是阿里的？我们公司数据部门一直在 on-call ，所以有段时间想要转 ops ，不过后来觉得自己水平还是太差，数据这块我知道一些，换成 k8s 这些就完全不懂了。

[lesismal]

on call 最苦逼，兄弟注意身体

[Milesy]

处理流程写到点上了，看着很舒服，心态也确实很重要

[NCZkevin]

太真实了，在某大厂干了 3 年, 每两个月 oncall 的那周是我最痛苦的时刻

[Atma]

老板，收藏了

[SHIINASAMA]

OP 真的厉害，刚工作不久隐隐约约能感受到一点，但没有如此细致的总结👍

[AstroProfundis]

@speedmancs #48 非常同意，最怕就是闷着头查根因把自己绕进去了的。

收到报警或者故障通告不要怕，首先看是什么故障现象，不要去管根因，尽快想办法消弭掉这个现象恢复业务。当然很多时候恢复故障影响和根因排查是互相交织的甚至就是一回事，但第一时间目标一定是恢复而非搞明白 why

如果发现短时间搞不定就要果断升级摇人并且把“我现在搞不定”喊出来，越多人知道越好，这样才有更多资源来帮助处理，甚至说难听点这是一个潜在的可能有助于事后甩锅的操作

哪怕 oncall 的人只是接了个电话转头再打电话叫别人自己最终什么都没干也是有意义的，特别是对大公司来说故障影响时间缩短一秒都是实实在在的损失减少

另外就是实际处理故障的人很容易因为压力或者工作量而埋头处理问题一声不吭，这个时候需要有同组的人或者主管在旁边帮忙把进度同步出来告知其他相关人员，我们曾经一度是在一些部门把这个要求制度化了的：要求任何时候处理故障必须有人去协助沟通，然后处理人员只需要和这个负责沟通的人说话，剩下的信息同步之类的都不需要管，专心修问题

[catazshadow]

写的很好，有含金量

[Cola98]

@kingcanfish 但是这种会涉及到的甩锅问题吧

[swananan]

@HXM https://github.com/XXXMrG/archie-zola/tree/main 这个主题，非常符合我的个人审美

[kaede316]

功能开发的时候，就需要确保三个要素：可灰度、可监控、可回滚 点赞！

[MarlonFan]

写的真不错，手动点赞

[deity888]

很有含金量，学习了，手动点赞

[snow0]

@whusnoopy B p 图的用意是

[WashFreshFresh]

坚持了四年，佩服。我有一段一年左右的 on call 经历，那段时间微信消息提醒音和微信铃声一响我心都会凸一下。

[mjjyyds]

在美股里亏麻了的我，还在试图加仓 笑死了 哈哈哈哈哈

[whusnoopy]

@snow0 B 想钻空子薅 A 的羊毛，说他在 A 那有一个优惠资格，但实际是没有的

[vgtiger]

博客主题很好看呀，是自己撸的还是用的主题模板？想给我的博客抄一份😁

[swananan]

@vgtiger https://github.com/XXXMrG/archie-zola/tree/main 这个主题

[vgtiger]

@swananan #76 多谢😁

[noyidoit]

好文

[LiaoMatt]

好文

[wupher]

写的非常棒！

on call 反人性，出国旅游都要背上笔记本，希望能早日摆脱当前的地狱

[edisonwong]

有时候排查的问题最扯淡的莫过于，最后发现自己坚信的假设一直是错的...

[julio867]

收藏~👍

[lihuashan]

收藏，好文，我正在经历中

[moli15522]

博客写的很非常棒，如果博客有 RSS 就更好了，可以及时收到更新通知了

[dddd1919]

刚在 ruanyf 推荐看到，作为多年双修 feature & hotfix 感同身受

[11232as]

今天刚参加了一个公司估计要赔近千万级别的事故 review 就看到文章了，深有感触啊...

[v66ex]

非常同意 cloudflare 那段，我也很喜欢看 cloudflare 的故障报告，学习他们的排查思路，以及从他们的部分截图管中窥豹，了解 cf 这种体量的公司会用什么样的程序或者工具，他们是如何监控他们的业务，如何告警等等。说实话，其他大厂我真没看到有 cf 那么详细的故障报告，很多的故障发个公告就一笔带过了，但作为用户或者同行，还是很希望能看到他们在故障发生后做了什么来缓解故障。

[v66ex]

@levelworm 礼貌问下，on-call 和 ops 区别是什么，我理解不应该是 ops 的人去轮着值班 on-call 吗

[EchoGroot]

> 当故障止血手段和故障根因定位绑死在了一起，那就是一场灾难，这意味着我们需要在非常紧张的状态下，快速定位故障根因，然后才能知道如何止血故障，恢复产品正常运行。

现在看来经历过的某次事故中，我在未定位到根因的情况下，进行未起作用的尝试性止损操作，是正确的。
但是当时复盘会被业务方指了出来，记忆犹新，一直认为是我做错了。

[v66ex]

cf 的股票（ net ）我之前买过，可惜，60 买了 80 就卖了，然后后面涨到 100 多去，哭死。net 确实是我一直看好的公司，后悔没拿住，历年的生日周发布的振奋人心的产品，由于他们的庞大体量，流经他们的互联网流量，可以做很多有趣的产品。。。。

[swananan]

@moli15522 感谢，我会尽快支持一下 RSS ，我原来以为是已经支持了，囧

[swananan]

@EchoGroot 这里需要特别注意的一个点是，止损操作需要流程规范化，比如方案需要通过应急一号位同意，才能开始开始执行。
还是那句话，当时如果整个应急团队都没有异议，事后就不应该针对人去追责相关的止损操作。除非是对整个应急团队进行拷打，哈哈，那只能一起扛了。

[Hyxiao]

好像在阮一峰的周刊里面看到 op 的文章了

[huixia0010]

从阮一峰的周刊里看到你的这篇文章，阅读完，文末看到了 V 站，感谢你的分享，非常有趣。
能写这么多，肚子里是真的有经验的。抱拳。

[swananan]

@Hyxiao 是的，我去那里毛遂自荐了一下

[swananan]

@moli15522 试一下这个呢，https://jt26wzz.com/atom.xml 一直有的，只是没标明出来

[swananan]

rss 地址更新了下： https://jt26wzz.com/rss.xml

[weners]

好文，感谢楼主分享

[moli15522]

@swananan #96 404

[moli15522]

@swananan #96 https://jt26wzz.com/rss.xml ，已订阅