线上故障排除，如何填坑

每个开发在做项目的时候不可避免的会遇到各种各样的坑，有前人留下的，也有自己给自己挖的，有低级的，有严重的。在咱们遇到问题时 如何用最快速的方法解决掉，后面如何避免类似的问题，如何提早发现问题减少损失。

线上故障处理目标

跳坑

快速恢复线上服务，或紧急处理使线上的影响降到最低。

填坑

找到问题的原因，根本上解决问题。通常情况下，’填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，加大内存等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。

避坑

举一反三，以后避免再出现类似的问题，制定一些相关的规范

故障处理思路

• 故障发现
• 故障定位
• 故障排除
• 故障回溯

上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务，目的在于提高效率。

在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务器重启、服务器扩容等手段，确保对线上服务降到最低且可控。等到线上服务’撑’过去之后，我们再慢慢定位故障原因，根本上解决问题

下面对4个步骤说明下:

线上故障一般可以通过如下几种途径传递到开发/运维人员手中，按照从上到下的顺序，故障的严重程度依次变高。

1. 主动发现——可能是开发或者运维不经意间查看生产环境的error日志，或者例行检查监控项时，看到了一些异常的现象，进而发现了故障

2. 系统监控告警——通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是服务器出现了异常，但是业务还未受到大面积影响

3. 业务监控告警——如用户登录失败率增加，订单堆积量增大，则意味中系统的异常已经很严重，影响了业务处理；

4. 关联系统故障追溯——有可能是子系统已经有异常了，子系统依赖当前系统；

5. 生产事件上报——通常业务异常带来的影响传递到用户，再从用户传递到客服人员，再到技术人员手里，会存在一定时延，所以一旦有生产事件上报，这个时候严重性已经到了最高，技术人员的压力也会增大，因为会有领导的关注，产品经理的询问和催促，客户人员的焦虑带来的压力。

开发接收到反馈时，不要慌 不要慌 不要慌 。这个时候首先需要确认的是这是不是一次线上故障？还是只是个例生产问题？

一般来讲：’系统监控告警’和’业务监控告警’的情况下，大部分是线上故障；

‘主动发现’和‘生产事件上报’则可以根据上报事件个数或者问题复现的方式来评估是否是大规模线上故障，或者跟踪日志信息或者特定用户问题追溯来确定。

可以通过以下途径确定是否是线上故障：业务监控告警、上报事件个数、问题重现、服务器监控等。这些途径可以并行进行，灵活组合，有时候一个手段就能确定，有时候需要组合多个手段予以判定

故障定位

一旦确定是线上故障后，我们需要快速定位故障点，找到问题原因，以便对症下药，快速排除故障。
故障定位是一个不断‘收集信息--假设--验证--尝试’的循环过程，基本思路：拿到线上信息，产生怀疑点，拿到更详细的信息，进行推理验证，必要时刻，找到可行的验证措施，进行可控的尝试，或者在测试环境进行业务测试重现，性能测试重现。

可能存在的怀疑点有：

• 新版本发布有问题
• 潜在的程序bug被激发，比如在访问量暴增的情况下，并发bug被激发
• 业务量暴涨
• 遭遇攻击，如活动期间羊毛党刷积分等
• 上游服务调用异常，如依赖第三方接口挂掉了
• 服务器故障，如磁盘满，内存爆掉等
• 数据库故障

故障排除

这里需要特别指出一个特别的场景：无法定位故障的情况下如何迅速排除故障。
很多时候无法及时找到故障原因，必须直接进入故障排除，这时候的思路就在于：尽最大可能降低线上服务影响了。
可以采用的手段有如下几项:

• 服务降级——定位到某些服务有异常，但不清楚异常出现的原因，直接将这些服务降级，确保其他服务不受影响；
• 服务紧急扩容——无法定位到是哪些服务造成的，服务器资源彪升，扛不住压力时，紧急扩容服务器；比如恶意攻击、营销活动，秒杀等场景带来的突发情况；
• 回退版本——有新版本发布，但是不能迅速确定是否和新版本有关系，先做版本回退，确保线上服务回到上一个稳定版本。

还是那句话，故障排除的原则是：确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。

总结

线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于
快速 二字，在’跳坑’-‘填坑’之后，需要总结以便‘避坑’。
一切的流程或者手段都是为’快速’二字服务的，所以线上故障是最高优先级的任务，任何人需要第一时间予以响应；同时，尽早地反馈故障问题，尽早地集结各个角色，群策群力地进行排障值得提倡；
这个过程中，需要有一位有‘威望’的master坐镇，主持大局；在保证有序推进的情况下，尽可能地并行地收集信息，进行尝试。
必须要有一个’严肃’的形式让当事人及旁观者‘吃一堑长一智’，线上故障处理报告是必须的产出物。
为了更加高效的处理线上故障，需要有完善的基础设施支撑：监控/告警体系、日志trace体系。

完善的监控/告警体系

通过告警，能让我们迅速知道自己的服务出了问题，通过监控可以从时间维度进行对比分析，找到可疑点，进而定位故障。
监控通常分为：
1. 服务器监控——针对操作系统资源使用情况(比如cpu使用率、内容使用率、磁盘空间、io、network等)，容器健康程度（内存使用情况、线程数、GC情况等），application健康程度的（服务的可访问性等）;
2. 服务监控——包括吞吐量、时延等，这些指标至少包括：最大值、平均值，通过这些指标可以判断单个服务的变化情况和健康程度；
3. 业务监控——包括访问量、错误率等，一个业务场景往往会包含多个服务调用，因此通过业务监控，可以发现一些关联问题。
告警方面，需要根据实际情况和业务场景进行阈值设定，告警阈值的设定是一个动态调整的过程。
监控系统最基本的需要保证：按照时间序列进行统计、对比。

完善的日志trace体系

在线上故障处理过程中，日志尤其重要，通过日志能够定位到问题或者bug细节。在分布式架构的系统中，多实例的部署导致日志分散在多台机器上，靠人肉查看耗时费力，效率低下；另一方面，业务发展壮大后，业务系统越来越多，系统间依赖越来越多，各个业务系统的日志需要通过唯一的标识串联起来，否则会出现信息断层的问题，日志变得无用。所以完善的日志trace系统非常必要。
日志trace体系的几个关键点：
1. 有唯一的标识串联上下游系统日志
2. 能自动收集分布式应用日志
3. 日志收集时延不能超过10分钟（具体时间试实际情况而定，如果时延太长，日志没有多大意义）
4. 支持多种形式的查询/过滤/统计等
5. 可以看到时间序列上的变化趋势
推荐使用开源的日志架构：logstash+elasticsearch+kibana