啪的一下，线上就出故障了，很快啊

阅读本文大概需要 6.66 分钟。

大家好，我是小贺。

---

前言

又到周末了，大家心情是不是很愉快啊，小贺也是，临近周末，都没心思干活写代码了，这不，一不小心就出事故了。

啪的一下，线上就出故障了，很快啊，表明佯装镇定其实内心慌得一批啊，紧急处理问题，提测上线，拿手机验证观察了一阵确认没有问题之后，才背起书包安心的下班。出了写字楼，那冷风呼呼地吹在脸上，不知道有多酸爽了。。

好了，下面就来回顾一下事情的经过吧。希望各位吃瓜的小伙伴能引以为戒。

1、事件回顾  

下午 16 点左右，正在工位上摸鱼的我，正想着周末要干点什么的时候，微信有人给我发消息，我点开消息一看，原来是产品小姐姐给我反馈了一个问题，说是线上刚发现的故障，还没等我回复，随机又把我拉进了一个群，群名赫然写着：APP 快速问题讨论。。

纳尼，线上故障？快速问题讨论？看到这几个字，突然有一种隐隐的预感：难不成我写的代码又出啥幺蛾子啦？

没事没事，小贺倒吸一口凉气，觉得应该不是什么大问题，正好有点口渴，随即起身去茶水间接了一杯水，喝完水回到工位上之后，点开群把消息瞅了一眼，哦，原来是有同事反馈线上 APP 打开使用有个问题。

简单来说，就是用户点击结果页跳转的链接 URL 不对，打开同一个网页，原来小贺所在的后端组会给客户端下发的是 A 链接，现在却变成了 B 链接， 然而 B 链接识别有点问题，导致部分地域的用户打开不了。。。

2、问题定位  

线上的问题，难道是？？？

不对啊，这个功能前不久刚上线的啊，也经过测试验证过了，线上代码也运行了一段时间了啊，怎么之前没有发现问题呢？

在动手修复代码之前，小贺带着疑问屁颠屁颠去找产品小姐姐问个究竟，和产品小姐姐当面沟通了一下，沟通的结果是，这个现象对应的某个功能在之前的需求里是按要求要实现的，但是现在是没有实现的，所以产生线上故障了，需要立马修复！

此时，回到工位上的我，表面上波澜不惊，其实心里已经慌的一批，因为这次的问题不是功能出了问题，而是功能没有实现。。。

立马登录服务器，敲击着各种命令，查看着日志，把最新的代码同步到本地，review 代码，进一步确认问题的根源，就是当初这个需求对应的链接修改规则没有实现，导致线上的版本没有实现这个功能，所以出现了开头的现象。

我立马找到当初的需求文档，把对应的需求点仔细，从头到尾的看了一遍，在我确认需求文档里面确实没有提到这个功能之后，一瞬间，我瞬间背后一凉。短时间内要实现功能？看群里反馈很紧急的样子，今晚我能修复的完么？意识到了问题的严重性的我，居然有点不知所措了。

3、讨论解决方案  

这个时候，测试同学也来到了我的工位，询问一下具体情况，到底是怎么一回事，我和他们解释了一下产生的现象和原因，测试的那边同学还是有经验，立马就有人反应说，如果来不及上线新的代码的话，是否可以把代码回滚到某一个版本。

然后开发的还是继续修复，这样留给修复的时间也充足些，当时大家想了一下，觉得这样不行，因为在这一版需求之后线上代码已经更新了好几回了，回滚不现实，于是这个方案被否决了。

后来又讨论说，能不能在配置平台的地方进行紧急干预，限制一下用户的版本，让某一个版本的用户不下发对应的数据，和产品讨论了一下，发现这个临时方案也不行，因为不是低版本的用户不下发数据，而是下发数据本身是不对的，其它用户也会受到影响，于是，这个方案也被否决了。

最终，讨论完了，结论就是，还是要改代码，嗯，啥都不说了，赶紧修复吧。

4、问题解决  

这个时候，我的 leader 也在知道了这件事情，把我叫了过去，虽然我和我的 leader 的工位很近，但往 leader 的位置上走向的时候，心里也是忐忑不安的，早已经做好了被批评的准备。

没想到，我把事情的来龙去脉给 leader 复述了一遍之后， leader 看上去波澜不惊，非常平静的样子，一点也没有责怪我的意思，反而是耐心的倾听我的想法。一边 review 我的代码，一边问我打算怎么做。

我简单快速的说了一下我的思路（当时情况紧急，根本来不及我多思考，我下意识的想到了一个最笨的方法）， leader 听了我的思路，想了一会，在听取了我的想法之后给我指出了解决问题的另外一个思路，指着我的代码，对我说，其实不需要改太多的逻辑，你看看，因为这xxx 所以xxx ，你这样改是不是比较快。

我想了想，觉得 leader 说的有点道理，比我想的那个实现方案要好，我说我先实现一下，验证一下是否可行。

然后就回工位，投入到紧急修复代码模式，这时距离产品提出问题不到半个小时。

紧接着，18 点左右紧急修复代码完并自测完毕之后，准备提测；

21 点测试完紧急上线；

22 点上线完成；

上线完成之后，配合测试同学盯了一圈监控指标发现没有异常，我才终于舒了一口气。。。

5、事后反思  

需求文档里没有提到的功能，后续可能也是需要实现，这个有可能是产品没有注意写进去，更大的可能是开发的同学需要及时和产品确认，确认清楚清楚，在投入开发，防止出现小贺今天的这种情况。

每一次的功能实现最好能有一个记录，本次实现解决了什么问题，修改了什么地方，以后出了问题能及时去回溯，方便定位问题。出了问题，立马修复，思考最优的解决方案，如果时间紧急，就应该考虑最快的最安全的解决方案。

像之前爆出的互联网大厂阿里云服务器出故障，那影响面就广了，如果服务器是广告平台之类的出了故障，对应的可是实打实的利润的流失啊。

通过这次事情，大家也看到了，后端研发在做前端或者app的研发人看来很高大上，但其实不然，几乎每天要处理各种线上问题，为前端为app做协议兼容，设计方案评审，代码 review，和产品扯需求，深夜升级服务等等。

这里呢，经过这次事故，小贺也是有所感悟，遇到突发事件还是要镇定，理性的解决问题，只有想清楚了问题的根源，加上对业务本身的熟悉，你才能游刃有余的处理问题，因为线上问题不容得你有充足的时间去修复，必须紧急定位修复。

PS：如果大家在阅读的过程中，有什么建议和看法，非常欢迎在下方留言，每个留言我都会认真看的