线上故障应急处理：4 年多 on call 经验总结
故障处理黄金法则
我的第一份工作是在 CDN 做基础设施研发，考虑到公司产品体量，那些年其实故障还是蛮多的😁，所以也算是久病成良医，当时在故障处理中，积累了一些经验教训，我这里再总结回顾一下。
故障止血是最高优先级
处理故障最重要的一条原则，就是明确故障止血是最高优先级。可能大家会困惑，这不是在说废话，我想更具体解释一下，故障应急时，故障发生的根因不是重点，重点是我们如何将产品功能恢复。 比如说，故障应急就像是医院的急救中心，患者大出血被送了过来，医生需要做的事情是先给患者止血，而不是考虑患者是因为什么原因导致了大出血。因为患者生命垂危，被刀砍伤，还是被车撞伤，其实并不重要，医生需要做的事情是先帮患者止血，让患者活下来，再去考虑其他问题。
这个教训，是我在第一次处理线上故障时候总结出来的，当时我在参加第一年团队内部绩效 Review 会，结果我负责的核心模块功能就正好出现了问题，导致大客户受到影响。记得当时会议室里面大家都在花式秀自己的 KPI 成果，突然一个运维大哥闯进会议室，说都别 TM review 绩效了，大客户报障了，赶快给我查问题。在这之前，我都因为刚毕业不久，面对线上故障处理，还都是属于跟在大哥后面摇旗呐喊的路人甲。这次是我自己写的核心功能出现了问题，所以在处理故障的时候，是会议室里所有人都在看着我排障，对我个人而言，是我自己真正意义上的第一次处理故障，而且还是处理自己功能模块引发的故障，可以说是 debuff 叠满了。还好这次故障相对比较容易排查，通过线上实时的错误日志，很快可以定位出来，是在新版本变更过程中，版本和配置不匹配导致的功能故障。我当时发现是这个原因之后，站起来大喊一声，不是功能有 Bug，是运维把版本配置发错了，就整个人放松了下来。
我当时老板发现我已经放松了，就立刻提醒我说，排障还没有结束，让我快速确认受影响的节点范围，以及确认快速止血恢复方案。我这才反应过来，确认根因，或者确认责任在谁，这在快速故障应急中毫无意义。快速止血恢复功能，让客户业务不再遭受损失才是重中之重。所以，在后续的故障处理中，我一直牢记，故障止血恢复永远是最高优先级，因为业务永远是第一位。
止血的最快手段是找到触发故障的变量
所以，我们达成了共识，故障处理的第一优先级是故障止血，但是怎么确定止血方案，又是一件头疼的事情。毕竟故障总是发生在研发毫无防备的时候，被紧急拉会，一群人面面相觑，搞清楚情况都很困难。商务还时不时进来添乱，不断的给研发上强度，故障恢复了吗，你们在干什么吃的，客户已经急的不行了，你们拿出点动作出来（像极了我在玩守望先锋竞技模式时候的路人队友）。我有过一任大老板平时还特别跟我们强调过，他喜欢在故障处理会议时候暗中观察，看看哪些研发是不合格的，嗯 😈，真是非常感谢这个善意的提醒，这让我一定能在故障处理的时候发挥出百分之两百的实力，证明我是一个合格的研发。
所以这么一看快速故障止血又成为了奢望。但是在非常多的故障复盘之后，我们又达成了一个共识，故障一定是某个变化引发的，而系统产品的变动更是引发故障的重灾区，找到触发故障的变量，可以让我们在短时间就制定出相对合理的故障止血方案。再者，变量不是故障根因，绝大部分情况下变量是可以非常容易找出来的。举个经典的例子，一次版本变更，甚至是一次配置改动，都是引发故障的变量。所以我们当时产品内部特别做了一个变更监控中心，可以按照各种维度展示系统事件变化情况，可以具体细节到一次域名配置的变更，一次机房的上下线。这样的话，当一个客户出现故障时候，我们可以快速的把该客户最近的所有系统事件给拉出来进行分析，猜测最可能导致故障出现的诱因，然后再针对性进行故障止血。
当然这个方案并不完美，总是有一些奇奇怪怪的变量，让人防不胜防。我又想到一次亲身经历的故障，当时团建的时候，我们团队跑去了青海自驾游玩，一路上非常开心，我记得我们当时还特意许了愿，希望团建的时候，故障不要发生。当然，都说了故障总是发生在猝不及防的时候，所以果然在团建路上故障发生了。当时我还是一个刚毕业的萌新，是一起团建的另外两个大哥负责处理的故障。第二天早上，其中一个大哥跟我说他们一晚上没有睡觉，凌晨 4 点才结束了电话会议，然后双眼盯着天花板，睡不着，直到天亮。故障倒是很简单，只是文件描述符的泄漏罢了。根因的话，是两个大哥分别写了不同的 bug，最后都导致了文件描述符的泄漏，哈哈，感觉挺有缘的。但是这次变量，竟然是因为我们要去团建，那一周没有发布，导致线上服务长时间跑才暴露出来的资源泄漏。所以用抓变量的方式来快速处理故障，并不是灵丹妙药。最后，我们一致决定以后再有团建的时候，哪怕没有发布，也要做一次象征性的发布。
另外，如果是客户侧发生的变化引发了故障，通过变量来快速确认止血手段的方式也不会那么有效。这种情况一般来说相对少，但是责任还不一定是客户那边的，比如说客户突然启用了某项功能，而我们并没有很好的支持，引发了故障。但是用户侧的变化，也是可以在故障初期，通过前线商务快速沟通，获取到的，所以也是可以用来帮助快速定位故障。
最后，当通过变量确认故障止血手段的方式不再有效，同时故障也很难一眼看穿是什么原因导致。换句话说，当故障止血手段和故障根因定位绑死在了一起，那就是一场灾难，这意味着我们需要在非常紧张的状态下，快速定位故障根因，然后才能知道如何止血故障，恢复产品正常运行。所以，有时候，当大家看到有些大型故障要处理几个小时甚至一天的，希望能多一点同情心，要知道真的没人想花这么长时间来处理故障！
止血方案执行需要谨慎和高效
哪怕我们有了相对确定的止血方案，但是止血方案的执行从来不是一件容易的事情，这里会出现的问题一般有两种。
第一种是雪上加霜，本来是想止血故障的，结果止血方案有瑕疵，或者执行有问题，把故障给进一步恶化了。我最近刚上的救生员培训课程，很明确说过中国法律规定，如果紧急救助失败，主动站出来的救生员是没有责任的。但是，在故障处理中，我相信公司可没那么好说话，毕竟大家都是拿着工资的专业人员，并不算见义勇为，需要对自己的行为负责。而且我遇到的几次大故障，都是因为故障止血引发系统血崩，导致故障影响范围进一步扩大。我印象中，有一次故障是一个非常经典的例子，当时只是在版本发布的时候，发现新功能不符合预期，处于稳健的考虑，决定回滚版本。但是新功能影响了系统版本回滚的稳定性，在进行全网回滚的时候，系统直接趴窝了。这里面有两处值得思考的地方，一处是新的功能必须要做到可回滚没有问题，这是设计新功能时候必须要考虑的，另外一处是止血方案也需要灰度，虽然这里版本回滚并没有被当做真正的故障处理，但是全网回滚确实是有点简单粗暴了，敬畏生产环境，这意味着灰度需要时时刻刻牢记于心。
还有一种，是止血方案不容易执行的。又是我之前经历过的一次故障，组里一个大兄弟大周末在给头部客户做质量调优，使用的相当于是动态脚本，跑在我们的服务端，这里大家可以理解是传统的服务端脚本热更新。但是点背的地方在于，这个脚本热更新框架有一个 bug，动态脚本更新完之后，导致进程死循环了。嗯，为什么 eBPF 严格限制指令执行数量，我从这次故障中也有了更深刻的领悟，动态脚本的执行安全性永远是第一位。这个故障，因为是全网推送的脚本，意味着我们线上当时有相当比例的进程是陷入了死循环状态，严重影响了产品服务，客户所有的请求，只要被内核分配在了死循环进程，就会永远得不到响应，真是绝了。电话会议被光速拉起来，考虑到我们线上服务都是 NGINX，NGINX 的 master 只能保证 worker 进程 crash 的时候，把 worker 进程重新拉起来，但是对于陷入死循环的 worker 进程，master 就只能干瞪眼了。于是我们当时的止血方案，就是把所有死循环进程都杀掉，让 master 重新拉起来，就完事了。这里，可能有人会说，为什么不使用 NGINX upgrade 进行全网版本更新，但是要注意的是，upgrade 没有办法处理死循环的 worker 进程（NGINX 是通过信号来控制 worker 进程的），而对于内核而言，死循环的 worker 进程还是可以接收新的网络请求，所以杀死所有死循环进程是我们当时快速恢复线上服务的最优解。
好了，谁来告诉我，怎么在短时间内，从那么多集群中，找到所有死循环的进程，并且把他们杀掉。于是，运维在手忙脚乱的现场编写和调试脚本，然后小范围灰度验证，再开始在所有受影响的节点执行脚本。所有在线的研发，都必须人工上机器，手动查找和杀死已经陷入死循环的进程。原来，止血方案哪怕定下来，也不是那么容易执行，谁又能想到线上能出现这种情况呢，你让我预演和提前思考系统的黑天鹅，我是不敢想线上居然会出现这种情况，想一想都觉得天塌了。所以，提高止血方案的执行效率，也是故障应急的重中之重。
故障应急处理中高效沟通
毕竟故障发生的情况五花八门，让人摸不着头脑，也许你在电影院或者在外边玩耍，突然被莫名其妙的拉进了电话会议里面。到底是系统内部指标监控报警的故障，还是外部客户的报障，故障的影响范围是什么样，根本摸不着头脑。电话会议里面还有各种各样的压力怪，不断给着已经快窒息的你持续上着强度。所以，怎么能在电话会议中有效沟通，快速故障应急，恢复线上服务呢？
还是那句话，久病成良医，我们依然总结了一些开会沟通应急方法，我觉得还是蛮有用的。考虑到故障应急就像打仗，既然是打仗，那就意味着最好只有一个声音来统筹全局，而不是乱糟糟的一团。所以当故障电话会议被拉起的时候，产品的负责人就会自动成为故障应急一号位。哈哈，我虽然一直在响应故障处理，但是还没有成为应急一号位的经历，但我需要明白应急一号位的工作职责，才能更好的和应急一号位打配合。而应急一号位要做的事情，就是按照之前介绍的黄金规则，统筹资源，确保大家往着正确的目标努力。更细节一些，应急一号位需要快速阐明和总结故障发生背景和情况进展，并且不断拉入相关对应的研发，及时同步情况，缩小故障排查范围，快速和研发确认止血方案和风险，进行合理的故障恢复。同时还要和商务前线不断沟通客户那边的情况，进行处理和反馈。
作为研发，特别是负责了系统中核心组件的研发，需要快速判断当前组件的运行情况，并且判断和故障的关联程度，及时反馈给故障应急一号位。同时我觉得，在故障应急中，负责排障的研发有两个需要特别注意的地方。
第一点是排查思路需要尽可能清晰的同步给在会的相关研发。比方说，我认为这些组件可能存在问题，我即将开始去排查了，并且会尽快反馈排查结果。这么做的好处很简单，排障过程中，时间特别宝贵，大家需要合理分工，并且互相认可排查思路，才能尽快缩小排查范围。
第二点是研发要敢于下判断，并且要说清楚自己的判断依据，这样才能达到大家集思广益，快速止血线上的效果。我觉得判断错了不是特别可怕，因为你同时也提供了判断依据，相关同事也会及时 review 你的判断，问题只会越来越清晰。当评估完止血方案和对应风险之后，故障也会被高效化解掉。
如何提高故障应急的处理能力
故障应急就如同破案一般，再思考一下福尔摩斯破案时候依赖哪些核心能力，高效的信息获取能力，缜密的逻辑推理，不受外界干扰的心态，所以答案就显而易见了。
打磨基本功
毫无疑问，高效的信息获取能力，可以帮助我们快速缩小问题排查范围，快速处理故障。但是这里需要技术硬实力来做支撑，毕竟对相关技术领域的理解越深入，越能获取别人获取不到的细节。哪怕在现如今 AI 流行的现在，也是如此，AI 只是发挥研发人员能力的杠杆，毕竟 AI 能发挥多大作用，还是取决于研发人员自己的硬实力。但是冰冻三尺非一日之寒，除了努力积累技术领域相关技能以外，我们还可以打磨哪些地方来提升故障应急的处理能力呢？
提升业务熟悉程度
首先什么算是业务熟悉程度，对于当前系统运行流程了然于胸，对自己负责组件的技术架构和各种细节也非常清晰。绝大部分功能，都可以很清晰说出当时功能的需求背景，设计方案，可能哪些地方有坑，后续可能的迭代规划是什么。如果别人问起这些问题，我们的答案是需要看代码和文档确认一下，那么要记住故障处理的时候，没有那么多时间去慢慢看文档和代码实现。
另外，系统运转的情况，有哪些核心日志，有哪些大盘，大盘的数据源分别来自于什么地方，这些细节也需要推敲清楚，毕竟故障通常是某个大盘数据崩坏了，如果都不知道大盘数据的生成来源，那快速应急排障也是天方夜谭。同理可知，如果是错误日志报警，也是需要对错误日志的产生原因有较为清晰的理解，甚至对错误日志的出现频率最好也能判断系统是否运行的符合预期。
有一个简单易行的办法，可以快速提升自己对业务或者技术细节的熟悉程度。比如说周末拿出一张大白纸，什么都不看，在白纸上开始画自己业务系统的运作流程，尽可能详尽的画出自己理解的每一处细节，这时候肯定觉得平时难以入眼的代码和文档变得魅力十足。因为在一开始练习的过程中，肯定充满了不确定，有很强的欲望再去看一看代码和文档，来补充自己不确定的细节。最后，这个办法也可以应用在深入学习核心组件的代码上，数据结构是核心组件的骨架，那运行流程就是核心组件的血液，我们可以通过在白纸上回忆填充，来不断增加对项目代码的理解程度，我当初学习 NGINX 的时候，就是不断的在白纸上一次次尝试自己画出 NGINX 的核心数据结构和各种场景的运行流程，其实还是蛮开心的，不过我现在好像遗忘了好多。这个技巧的原理，是强迫自己站在设计者和实现者的角度去思考问题，这样才能更深入的理解本质。
工具脚本沉淀
正所谓人在江湖身不由己，很多时候在故障排查的时候，你不得不分享你的电脑屏幕，如果这个时候，你需要在线上环境快速的分析一些数据，这个时候一般都恨自己平时没有好好看一看 AWK 之类文本处理工具的使用文档，或者某些工具的使用频率有点低，自己遗忘了。又或者，自己需要一个临时工具脚本来验证某个猜想。林林总总的这些烦心事，如果你选择了现场网上搜索，会极大拖慢你排查的效率，如果你还是屏幕分享状态，更是火上浇油。
我为了应对这样的场景，我会不断的总结我在故障排查的时候，可能会需要哪些工具，尽可能的文档化相关低频但是可能有用的工具，为什么不是高频，当然是因为高频的操作早就铭记于心了，我当初甚至是在我的 snippets 工具里面记录了大量 AWK 脚本模板，只是为了在处理故障的时候，让大家觉得我还是比较专业的，产生一个幻觉，也许这个故障能快速处理完。
现在有 chatGPT，这个问题就好很多了，任何非常低频的工具使用方法，chatGPT 都会对答如流。但是我仍然觉得有一些细节，值得我们去做的更好。比如说，很多底层工具是需要再针对特定系统业务二次包装，才能用的更得心应手，我们不能指望每次出问题都去问 chatGPT，提前把日常排查流程工具化，非常重要。另外还有一个特别的技巧，如果在屏幕共享的时候，你甚至不想去问 chatGPT，毕竟如果是一个愚蠢的问题，一般在场的所有人都会觉得挺尴尬的😰。这个时候，你可以快速的阐明你的意图，然后把验证任务打包分配出去，指派给会上在场的另外一个同学，这样就可以完美避开了这个尴尬局面。举个例子，嘿 xx，麻烦帮我把当前线上 Coredump 文件里面，请求中 top 10 的域名给整理出来，当然，事后我们要再把这个 gdb 脚本给工具给脚本化沉淀下来，毕竟我可没有屏幕共享当众现写脚本代码的特殊爱好。
排查流程沉淀
这个流程更像是一次复盘 review，只不过这是针对个人的复盘 review。我们需要回忆在故障排查的过程中，有哪些环境感觉不够流畅，有哪些细节我们不是特别有把握。我们需要把这些地方都梳理出来，去一一理清楚。这些细节，在真正的故障 review 会上是很容易被忽视掉的，只有自己在故障排查的过程中，才能深刻感受到自己对哪里细节还把握的不到位。每一次个人复盘，都能让自己在下一次排查中，更得心应手。说的更实在一些，每次个人 review，至少让自己比上一次故障处理的时候要强一些。
功能开发需要未雨绸缪
我们在功能开发的时候，就需要确保三个要素：可灰度、可监控、可回滚。这也是我们研发做功能和架构迭代的红线，必须遵守，不能妥协，不然真出了故障，肯定会在故障 review 会上被挑战的很惨。
学习优秀的故障复盘案例
在 Cloudflare 的技术博客里面，有非常多故障案例的细节分享。能够学习优秀公司的故障复盘细节，我觉得是非常难得机会。原因很简单，并不是每一家公司都会非常坦诚的展示出重大故障的技术细节。毕竟，在很多重大故障的背后，往往是相对低级的错误。而很多公司，很容易从商业的角度做出一些抉择，怕影响客户对自己的信任，从而对故障的原因轻描淡写的一笔带过。而 Cloudflare 会选择展示故障的细节，100% 的透明度，我觉得这是非常牛逼公司才能做到的事情🫡🫡🫡。这么一想，虽然已经是 2025 年，并且特朗普还在疯狂搞事情，但是我觉得我是不是能买一些这家公司的股票长期持有😁（在美股里亏麻了的我，还在试图加仓）。
另外在阅读 Cloudflare 的故障博客时，也是很有趣的体验。有时候看到他们在故障里面犯的一些错，我脑海里总能想到我们也犯了类似的错误，并且也引发了故障。大家都是人，都会犯一些同样的错误，有种同命相怜的感觉。同时，也会好奇他们是怎么处理这些错误，并且确保不再发生的。林林总总，这些博客常读常新，总是能触发一些新的感慨。最后，附录一个博客链接，是我读过的第一份 Cloudflare 故障复盘博客，印象特别深，大家感兴趣可以看一看。
https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/
心态调整
想象这样一个场景：你自诩为对这块领域是组内最熟悉的人，或者之一，但是在故障处理的过程中，死活没有思路，这时候其他人却轻松的给出了关键操作，极大的推进了故障处理的进度。想到这个，是不是有点畏首畏尾，感觉日子相当艰难。就好像故障应急是一场随时可能出现的考试，我们可能永远觉得自己没有发挥好，拿不到自己心目中的满分。
我以前也很惶恐过这样的问题，但是我明白了一个道理，就是故障应急并不是一场真正的考试，考试更多的是为了筛选和区分考试者，而故障应急的核心目的是让产品恢复运行，减少公司和客户的损失。所以故障应急并不是排他性的，只要我们坚持着上面的原则，高效的同步的排查思路和结果，努力的给出自己的判断，其实这些问题并不重要。没人会去当一个事后诸葛亮，来说一些没用的话，比如当初怎么不这么排查或者这么去止损，因为大家都在故障现场，并且都高效沟通着排查思路，哪怕有疏漏，这也是团队的决定，不应该指责个人。
一开始接触故障处理的时候，看着身边的大哥们镇定自若的处理故障，想到如果是自己，那该怎么办，越想越慌，十成本事最多发挥个八成就不错了。后面处理故障多了，赶鸭子上架，发现也没有那么难（毕竟我们有前面总结的黄金法则和个人提升方案），甚至开始化被动为主动，把故障应急当成个人展示的舞台，多少能秀点东西出来。但还有一种蛋疼的情况，就是大概率是自己的功能引发了故障，这种就像自己给自己扫墓，故障排查过程中脑壳痛，心里还忐忑不安，感觉就像天塌了。不过，我们也还是需要保持积极的心态，毕竟处理问题才是第一要务，锅背了无所谓，至少经验教训要学到。实在不行，我们还有一条祖训：代码和人只需要一个能跑就好了。
故障复盘
核心目标和注意事项
故障复盘的核心目标是什么，很简单，确保故障永远永远不会再发生。那么围绕这个目标，在复盘过程中，我们有一些需要特别注意的地方。
首先，确认故障已经被正确处理完毕了，因为可能我们在一开始处理故障的时候，采用了简单粗暴的止血方案，正如我们黄金法则第一条里面说的那样，先恢复业务，不计代价。然后再用更稳定的方式，去修正系统运行的问题。
接着，我们需要复盘梳理故障处理的时间线。比如说，故障什么时候发生，多久故障报警发现，什么时候有人开始介入处理故障，在处理故障的过程中，进行了哪些操作，有哪些操作是有效的，哪些操作是无效的，影响是什么。更重要的是，这些事件发生的时间点最好精确到秒。这个复盘的过程无疑是痛苦的，因为会发生很多灵魂拷问，比如说为什么这么久才开始报警这个故障，为什么止血操作拖了那么久才确认，为什么有那么多无效操作。痛苦自然就会让人成长和反思，进行查漏补缺。
最后就是梳理故障的根因原因，然后制定相关的 action 了。关于故障根本原因的话，其实顺着顺着时间线多问几个为什么，其实就已经非常清晰了。反而是故障的 action 制定需要特别注意，正常来说，action 需要指派到人，设置好合适的 deadline。但是我个人理解，这里还是有不少值得注意的地方。
- 不要相信人，用规则和制度来确保系统运行的下限。是的，不要以一个人是否靠谱，又或是否专业，来衡量这件事情会不会发生，而是通过制定合理的 action 来规避这样的问题，这是所谓的对事不对人。
- 举一反三，要有全局思维。很简单的举个例子，比如因为 dns 相关问题导致的故障，那么就不能只局限于发生故障的地方，而是要把生产系统中所有涉及 dns 功能的情况都梳理一遍，确保类似问题不再发生。
- 除了指派给人和设定合理的期限，action 的执行质量还有什么办法可以保证。我觉得一方面 action 实现就要像做功能需求迭代一样严谨，另外一方面定期的故障演练，对相关 action 的及时测试也是不可或缺的。
- 如果 action 还没做完，故障又发生了，怎么办？是的，我之前真的遇到过，真的是一场噩梦。所以，我们在制定 action 的时候，也需要思考到这一点，需要有一些临时方案，来确保真空期的时候，也能保证系统不会再次翻车。
聊聊故障定责
参加故障 review 会，就像参加一场葬礼，如果是自己引发的故障，那就是参加自己的葬礼。话说，我那些年参加了几十场葬礼了😂。虽然有很多公司会强调故障不问责到个人，但是权利和义务是对等的，既然拿了工资干了活，那故障的后果也是需要个人来承担的。当然，这里的担责只是影响个人或者团队的绩效，如果要求研发赔钱之类的，我建议光速提桶开溜,这种公司只存在我的想象中，不敢相信现实中能存在这样的公司（可能缅北那边有这样的公司？）。还有很多时候，故障会严重到一线研发承担不起，需要自己这条线上的老板们背责（对此，我心里话是，那还不如自己个人背锅，来的痛快呢）。另外，我相信是存在一些公司可以做到 Blame Free，但是无论如何，对于责任心强的人来说，承认和面对自己的错误，依然是一场修行。
所以，大部分人在自己的故障 review 会上，基本上是非常痛苦的状态，我可以感同身受，因为我也或多或少引发过几次，虽然出于一些运气，没有被当做故障来处理，但是对我个人还是造成了比较大的打击。
在这里，我没什么特别好的建议，我感觉我能总结的都在前文已经提及了，尽量保证好心态，毕竟公司是花了真金白银给我们上了一课，总结、学习和成长，确保问题不再发生，才是永恒的主题。实在不行，我们还有。在这里，我又想起好久之前，有一个运维大哥，当时发布的时候，先去抽烟放松了一下，然后上来操作的时候，就把版本发错了中心机房，直接 game over，引发了故障。但是在故障 review 上还是谈笑风生，甚至可以说是挥斥方遒，各种分析当前系统的缺陷，熟练的安排各种 action，丝毫不受影响。给当时的我带来了一点小震撼，但是不管怎么说，这种心态还是值得我们学习的。杀手锏，提桶跑路
尾声
那些年 on call 虽然帮助了我在工作中成长，但是也给我身心带来了不可磨灭的创伤😂，我至今一看到电话响起，都会有点紧张，在想自己工作电脑是不是在身边，是不是系统哪里又出问题了。突然想到，有一次团建，我和我老板合住一间房，早上突然公司会议电话响了起来，我和他对视了好几秒，表情非常凝重，然后缓缓的接起了电话，结果是团建路上别的小伙伴拉的电话会，讨论早饭吃什么。事后，我严肃的抗议和谴责了这一行为，吃个早饭都要拉电话会议，真的会死人的😠。
很多时候，故障应急的时候，都发生在我猝不及防的时候，有印象比较深的几次。有一次是我在成都玩的时候，从武侯祠开始应急处理问题，一直处理到九眼桥（是的，机智的我在旅游路上都带着电脑）。还有一次是圣诞节晚上，刚准备带着老婆出门去吃大餐，然后被拉进了电话会议里面，在这些时候，我老婆基本上都是气鼓鼓的坐在我旁边看我处理问题，问着和会议里商务一模一样的问题，究竟啥时候能处理结束。
就这样，过去很多故障应急的场景，在我写这篇文章的时候，就跟电影一样，又在我脑海里面重新回放了一遍，有快乐高光的时刻，也有痛苦消沉的时候。想到这，我甚至还有点怀念过去那段日子，可能我现在还在怀念的原因，是我现在已经很久没 on call 了吧。哈，确实是好日子过久了，都开始胡思乱想了。
尾声 2.0
这篇博客写完之后，有点神清气爽，没忍住，开了个帖子，发到了 V2EX 论坛里面，想分享交流一下。发现回复还挺多的（心中窃喜），蛮多人共鸣的，并且也有好多人也分享了各自的经验和感悟。果然，只要是干这行的，都没少吃这方面的苦。话说，我的博客目前还是个静态博客，还不支持评论，所以，我就把帖子链接也放在下面，方便讨论。也许，后面我博客也要支持下评论功能，因为还是蛮期待一些有价值的评论能够出现在自己的博客页面里。本来想着只是写写细分技术领域相关的博客，没想过会有多少评论。果然还是总结类的博客，看得人多。我 QUIC 协议栈相关的系列博客写的比这篇吹水博客累多了，却很少有人找我讨论😂。
https://www.v2ex.com/t/1126452
还有，其实这篇博客里面分享的故障，只是我经历过线上真实故障中的九牛一毛。之前有好多经历过的严重故障，背后的情况真的一比吊糟，完全经不起推敲和拷问，并且能够非常充分的支撑这篇博客里面的观点。但是，这个江湖很小，我怕图一时之快乱写一通之后，会非常危险。万一哪天还有江湖再见的那一天，希望不要有，场面肯定会非常尴尬。现在已经有个别前同事找上门，问这个是不是我写的了，希望我现在文章中举例的那几个哥们，不要看到这篇博客，特别是那个挥斥方遒的运维大哥，我其实没啥别的意思，只是觉得你在故障 review 的时候特别帅。