如何快速处理线上故障( 三 ) _线上故障

从上面可以看到，故障定位过程中，追求‘快速’二字，为此多项事情是并行去做的。为了避免出现群龙无首的慌乱局面，需要有一个主心骨坐镇，把握排障的方向并最终做出决策，这个人是master，需要冷静沉着，且要能调度尽可能多的资源，所以技术leader或者运维leader会比较合适。这个类似于分布式系统的设计思路。
另外，在故障定位过程中，获得的线上一线信息需要通过某种形式记录下来，邮件往来是一种比较好的方式，在完成通信和信息共享的基础上，也无形中保留了现场。其他的信息包括：error log，dump文件，服务器各个指标的状态值等等。
故障排除
一旦定位到故障原因，对症下药地排除故障就不是什么难事了，具体的措施可以参考下图中的总结：

文章插图

这里需要特别指出一个特别的场景：无法定位故障的情况下如何迅速排除故障。
很多时候无法及时找到故障原因，必须直接进入故障排除，这时候的思路就在于：尽最大可能降低线上服务影响了。可以采用的手段有如下几项:
1、服务降级——定位到某些服务有异常，但不清楚异常出现的原因，直接将这些服务降级，确保其他服务不受影响；
2、服务紧急扩容——无法定位到是哪些服务造成的，服务器资源彪升，扛不住压力时，紧急扩容服务器；比如恶意攻击、营销活动，秒杀等场景带来的突发情况；
3、回退版本——有新版本发布，但是不能迅速确定是否和新版本有关系，先做版本回退，确保线上服务回到上一个稳定版本。
还是那句话，故障排除的原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
故障回溯
故障回溯的目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。在‘跳坑’--‘填坑’之后，我们需要通过故障回溯的过程达到‘避坑’的效果，即要保证自己能‘避坑’，也保证团队/公司能够避开类似的坑。
故障回溯的过程，因人因团队而异，最重要的是要有严肃的‘形式’和最终的产出物。之所以提到严肃的‘形式’，是因为线上故障无小事，一定要让大家牢记在心。
至于如何达到‘严肃’，可以参考如下形式：
1、可以和kpi挂钩。慎用，可能会伤害到技术人员的心，造成‘懒政’现象——“多干多出事，少干少出事”出现；
2、可以实施追责制度。同上；
3、还可以进行邮件或者会议形式的讨论，广而告之。
总之，故障回溯的最终的目标不是为了追责，更重要的是让大家长记性，避免后续再次踩坑，而且线上故障报告的产出物一定要有，一方面是经验的积累，便于分享，另一方面也让当事人撸清楚事件过程，吃一堑长一智。
可以参考的一个流程如下：

文章插图

线上故障处理的‘后勤保障’
前面谈了线上故障处理的目标、思路和步骤，回过头来看下，要快速准确地定位和排除线上故障，需要很多基础设施支撑，它们是线上故障处理的‘后勤保障’ 。结合上面的内容归纳总结如下：
完善的监控/告警体系
通过告警，能让我们迅速知道自己的服务出了问题，通过监控可以从时间维度进行对比分析，找到可疑点，进而定位故障。
监控通常分为：
1、服务器监控——针对操作系统资源使用情况(比如cpu使用率、内容使用率、磁盘空间、io、network等)，容器健康程度（内存使用情况、线程数、GC情况等），Application健康程度的（服务的可访问性等）;
2、服务监控——包括吞吐量、时延等，这些指标至少包括：最大值、平均值，通过这些指标可以判断单个服务的变化情况和健康程度；
3、业务监控——包括访问量、错误率等，一个业务场景往往会包含多个服务调用，因此通过业务监控，可以发现一些关联问题。
告警方面，需要根据实际情况和业务场景进行阈值设定，告警阈值的设定是一个动态调整的过程。
监控系统最基本的需要保证：按照时间序列进行统计、对比。
完善的日志trace体系