13518219792
| 导读 | 作为程序员，相信有一件事是大家最不想见到的。那就是，线上运行的系统出现了技术性故障。(特别还是周末你正在外面happy的时候：D) |
处理这类事情特别能体现一个人的综合能力。因为它会涉及到抗压能力、对外的沟通能力，以及排查问题所需的技术能力等等多个方面。如果你还没机会成为核心开发，其实很少会有这样充满压力的经历。因为在这个情况下处理事情其实是很慌的，毕竟所有使用系统的人以及他们的老板、你的上级、你的老板等等无数双眼睛都在盯着这件事情。
我还记得有一年双11，我作为“首席问题处理官”正在紧急处理服务器扛不住压力的问题，老板默默走到我身后问到“什么问题啊?什么时候好?”。你脑补一下这画面，想象一下看看。
只要你接下去还会继续从事程序员这个职业，我想这样的场景你总归会有机会遇到的。因为一个著名的定律——墨菲定律。墨菲定律：凡是可能出错的事就一定会出错。如果没有一个清晰的应对思路，那么一旦发生线上问题就会像热锅上的蚂蚁一样，急得团团转，像无头苍蝇一样到处乱撞(试)。
所以，我这次就想分享一些我多年作为“首席问题处理官”所总结下来的经验。这可是承载了我N多汗水和脑细胞的经验～
在日常的项目开发迭代过程中我们遇到一个bug，大家的处理过程几乎是一样的：定位bug -> 解决bug。可能少部分人在解决bug之后会有一个思考、复盘，看看是否有类似bug的地方，一并处理掉。
这个“定位 -> 解决 -> 复盘”的过程也同样适用于线上问题的处理。但是必然不仅仅如此。俗话说，解决一个问题最难的地方不是解决的过程，而是定位的过程。所以，针对线上问题我们等不起定位问题所花费的时间，因此要将「恢复」系统正常使用放在最首要的位置。所以，这个过程就变成了：“恢复 -> 定位 -> 解决 -> 复盘”。
这里多说一句，有一部分人的观点认为，将恢复系统作为首要目标，应当包括牺牲保留现场的动作，因为这个动作可能也需要耗费数分钟才行。我对这个观点持反对意见。理由是，解决问题的时长的确是一个很重要的指标，但是问题既然已经发生，如果由于没有保留现场导致后续没有排查到根源，导致下次该问题再次出现，到时候场面将会更加难看。所以我对这事的观点是，保留现场最重要。因此，这个过程又变成了：“保留现场 -> 恢复 -> 定位 -> 解决 -> 复盘”。
当然了，保留现场也不是说非得面面俱到，花很多时间。用最快的方式保留你当下所能想到的所有相关线索的地方即可。如果事后还是由于线索不足导致未能排查到根本原因，那只能说经验不足，考虑一下以后需要多保留哪些现场数据才行。好了，确定了这5个步骤，那么具体每个步骤可以做些什么呢?我来一个个说。
/01 保留现场/
