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

上述途径传递过来的信息仅仅只是线上故障苗头，并非一定就发生了大规模的线上故障，所以首先需要确认的是这是不是一次线上故障？还是只是个例生产问题？是否和本系统有关系？一般来讲：‘系统监控告警’和‘业务监控告警’的情况下，大部分都和本系统有关，且可能是线上故障；而‘主动发现’和‘生产事件上报’则需要做甄别，可以根据上报事件个数或者问题复现的方式来评估是否是大规模线上故障，或者跟踪日志信息或者特定用户问题追溯来确定。至于‘关联系统故障追溯’的情况，首先不要慌，先从宏观上确定本系统服务正常，一般可以检查是否有服务器监控报警，是否有业务监控报警等来确定，如果上游或者下游提供了日志，可以通过日志进行追踪，从而确定本系统是否存在故障。
因此在得到一些线上故障苗头之后，可以通过以下途径确定是否是线上故障：业务监控告警、上报事件个数、问题重现、服务器监控等。这些途径可以并行进行，灵活组合，有时候一个手段就能确定，有时候需要组合多个手段予以判定。

文章插图

故障定位
一旦确定是线上故障后，我们需要快速定位故障点，找到问题原因，以便对症下药，快速排除故障。
故障定位是一个不断‘收集信息--假设--验证--尝试’的循环过程，基本思路：拿到线上信息，产生怀疑点，拿到更详细的信息，进行推理验证，必要时刻，找到可行的验证措施，进行可控的尝试，或者在测试环境进行业务测试重现，性能测试重现。
可能存在的怀疑点有：
1、新版本发布有问题
2、潜在的程序bug被激发，比如在访问量暴增的情况下，并发bug被激发
3、业务量暴涨
4、遭遇攻击，如活动期间羊毛党刷积分等
5、上游服务调用异常，如上游系统升级httpclient后，将长连接改为短连接
6、下游服务异常，下游服务宕机
7、网络问题
8、服务器故障，如磁盘满，内存爆掉等
9、应用故障
10、数据库故障
为此，可以通过如下几方面收集信息，以便支撑你的怀疑点：
1、最近新版本的发布情况
2、本服务的异常/error日志
3、本服务的调用量变化情况，是否存在暴涨？
4、本服务的吞吐量，是否出现下降？
5、本服务的时延，是否出现突然增大？
6、服务器TCP的链接情况，是否存在大量的CLOSE_WAIT？
7、服务器的cpu使用率，是否突然飙升？
8、服务器的disk，磁盘空间是否已经用完？
9、服务器的内存，内存是否爆掉？
10、数据库或者存储是否挂掉？
很多故障并不是由于单一原因造成的，而是多个条件同时满足时才出现的，所以，需要多收集信息，综合得到的信息，产生怀疑点，快速推理和验证，最后找到问题点，定位到故障。这个过程中可以集合大家的力量，并行去check各个点，并快速反馈信息。
由于组合情况众多，这里只将明显的故障定位场景列出，更多的需要总结归纳：
1、发布了最新版本，且故障最早出现时间在版本发布之后，很大程度上时由于新版本发布带来的问题，可能是bug，也可能是部署出现问题；
2、未发布新版本，业务访问量猛增，服务时延增大，吞吐量先上升后下降，到最后服务直接不可用，可能原因是：业务量暴涨/遭遇攻击/上游服务异常调用；
3、未发布新版本，部分服务失败，服务错误率增加，业务访问量增加，可能原因是业务访问量增大激发了潜在的并发bug，或者出现了io瓶颈等；
4、业务访问量并未增加，但是服务时延下降，吞吐量下降，服务错误率增加，且服务器TCP的CLOSE_WAIT增大，这时候需要怀疑下游依赖服务是否异常。
5、业务访问量并未增加，服务大范围不可用，日志中出现大量数据库错，很明显数据库可能出现问题，或者应用的数据库连接池出现问题。
不一而足，需要逐步积累。下图是对上面描述的总结。

文章插图

故障定位的初期，一般会先通过邮件+电话的方式进行沟通，如果几分钟之后事态变糟糕，且没有眉目，则需要紧急启动会议形式的联合排障，所有相关人员需要放下手头事情，集中到一个特定会议室进行联合排障。这样的好处也在于能够迅速共享信息，快速做出决策。联合排障人员通常会包括：开发、运维、测试、产品，主力应当是开发和运维，测试和产品需要帮忙快速确认一些东西，如复现问题，或者确认业务逻辑等。