一次线上紧急事故的处理复盘
版权声明：
本公众号发布的所有文章，未特殊署名，均属于原创，版权归本公众号所有。
转载请参阅公众号的：《转载授权》。
一、前言
之前有个周末，公司的 App 产品，导致线上的所有版本，都无法从服务器获取数据，最终排查出来的原因是因为 DNS 服务商将域名解析到一个错误的 IP 上了，所以请求就不会到达公司的服务器，而这个错误纠正的时间，可能长达 72小时（因为 DNS 缓存的缘故）。
本文就如何处理这样一个线上的紧急 Bug ，做一个复盘总结。
二、处理线上问题
线上的紧急事故，是一件非常可怕并且伤害无可估量的事情，它不知道什么时候会发生，是一种黑天鹅般的事件。
那么，我们在突发这样的事情之后，如何能有效的解决呢？
2.1 收到反馈要重视
所有的事件，最开始都是有苗头的，发生之后，你总是可以在之前的一些小事情上，找到蛛丝马迹。而在问题爆发之前，一般也会在一些什么用户反馈群、微信公众号后台等一些反馈的渠道，接到用户的反馈。
对于这些反馈，要重视起来，一个愿意来反馈问题的用户，背后可能是十个二十个或者更多的碰到问题的用户。
而如何从这些反馈中，区分问题的紧急级别，也是一个非常重要的技能。
2.2 快速定位事故原因
碰到紧急事故，最先知道或者最先通知的，一般都是产品经理或者技术负责人。而他们需要做的，就是协调相关的人员，快速的定位出事故的原因。
通常分一下几个步骤：
定位问题的原因
确定影响的范围
找到解决的办法
办法生效的时间
这几步都非常的重要，既然已经是线上的紧急事故了，就需要紧急的处理，这个时候如果定位错了问题，就可能导致非常严重的二次伤害。
例如，你找到了问题的原因和解决方案，但是它生效的时间，最长有 72 小时。但是如果你定位错误，就会导致在这 72 小时内的反馈，你可能就会安慰用户说已经解决，需要多久多久才可以生效，但是过了这个时间段，你发现问题并没有得到解决。而又需要重新反复的再次定位问题，耽误了问题解决的最优时间。
2.3 解决问题，尽快上线
定位到问题的所在，就需要确定如何快速的让这个问题得到解决。
就现在的环境来说，如果是服务端的数据的问题，通常定位好问题，让服务端快速修改即可解决。
而对于客户端的问题而言，如果之前有过热修复的积累，可以先判断是否能通过热修复技术来解决问题，如果不行，就只能尽快修复并且发版了。
2.4 安抚用户
在定位到问题之后，在程序员修复问题的同时，运营人员应该第一时间发出公告，安抚用户的情绪，重视各个渠道的用户反馈，一有类似情况的反馈，尽快对用户表达歉意，并且告知已经在处理，需要用户耐心等待。
一般来说，安抚用户的动作，无法就是通过一些方法，告知用户现在有问题，相关人员正在紧急修复，让用户耐心等待。而这个告知的发布，一般的渠道有：
官方微博
应用关联微信公众号
应用推送。
群公告等。
总结起来就是通过一切可以利用的渠道，告知用户现有的情况，以达到安抚用户的目的。
举个前两年的例子，小米运动 App ，有一次升级之后出现闪退，根本无法进入 App ，这个时候它们紧急处理了这个问题，并且给用户发送了一条推送，告知用户需要卸载 App 重新安装，即可正常使用。
2.5 事故之后，如期复盘
定期复盘是一个非常好的习惯，不管是对个人还是对公司。
而发生这些紧急的事故之后，也需要在事故解决之后，进行复盘，总结一下在这个事故之中，有什么做的不好的地方，有什么可以做的更好的地方。
例如，在解决方案选定之后，毕竟还需要人去实施，那在这个实时的过程中，有没有什么可以改进效率的空间。又或者，客户端开发能否在 App 内预埋功能，让下次出现类似事故的时候，切换一个配置就得到解决。
复盘是为了之后更好的规避和应对这种突发事故，可能大部分情况下，我们的准备都是白费的，但是一旦出现事故，这些准备就可以让我们更从容。
三、结语
这次事故，整个团队迅速行动，快速的解决了问题，没有造成太大的损失，这也是比较欣慰的地方。
愿各位同行不要出现线上事故。
推荐阅读：