如何建立线上问题快速响应机制

1、概述

  线上问题通常是指大规模影响生产服务的问题或事件，通俗点说就是"踩雷"，线上问题处理的流程也可以看成是"踩坑"、“跳坑”、“填坑”、“避坑”，优先级从高到底依次排序；

  线上问题的处理，不仅是一项技术活，更是对技术人员/技术团队反应能力、决策能力、判定能力、组织能力的考验。面对突发的生产故障，需要快速定位问题，找到解决方案，快速实施解决方案并不是一件容易的事情。本文主要包括如下内容：线上故障处理的目标、思路、步骤、以及如何建立快速响应机制；

  本文仅依据平时经历的生产故障排查和处理，总结一些肤浅的方法论，以求共同讨论，共同提高，欢迎探讨。

2、目标

  2.1 “跳坑”：— —快速恢复线上服务，或者将线上问题的影响降到最低

  线上服务的可用性，直接影响着客户的利益，一旦线上服务无法使用，往往会给公司带来严重的经济损失和赔偿金，更严重的会给整个公司或团队带来恶劣的名声。所以出现线上问题的第一要务就是尽快恢复线上服务，及时不能快速恢复也要提供规避方案，想尽方法将影响降到最低；

  2.2 “填坑”：— —快速定位问题产生的根本原因，从根本上解决问题；

  在恢复线上服务，尽最大可能减少用户损失外，还需要彻查产生问题的根本原因；一般来说，跳坑和填坑二者是并行的，完成“填坑”意味着“跳坑”结束，但是跳坑也有一些非常规手法，如：重启服务，增加熔断机制（过载保护）/服务降级、请求阈值控制等；

  2.3 “避坑”：— —举一反三，以此及彼

   定位到根本问题并解决之后，最重要的还是举一反三，团队中的流程/规范/制度是否需要优化，模块之间最薄弱或最容易受到攻击的地方在哪，该问题在其他团队或系统中是否存在？通过这样的不断总结和批评，最终形成一份故障报告，总结问题出现原因和解决方案；

3、故障发现

   线上问题一般都是会有通过以下几种途径传递到研发团队，严重程度依次从低到高排列：

• 测试/运营/开发，通过一定方式方法，测试出了系统问题，如：评审设计有误，系统功能与需求不一致，或查看系统error日志时发现异常，进而发现了故障；

• 系统监控预警： 如cpu、内存、IO、线程数、系统流量等达到服务器异常指标，很有可能是系统出现问题，但此时往往业务还没有收到大面积影响；

• 关联系统报错：上游系统或者下游系统出现问题，如服务器直接宕机/网络波动，这时候服务影响面已经很广了，需要马上恢复服务；

• 生产环境问题上报：用户无法使用系统，并反馈给运营人员，然后运营人员再将问题转发给技术，这中间会存在很大的延时性，所以等到技术人员得知系统出问题时往往已经造成了不可挽回的影响；

      总的来说，上述的几种途径反映的仅仅是线上问题的故障苗头，具体是不是系统故障还是由于一些不可控因素导致的问题，还需要进一步定位和排查。一般来说，上面的"系统监控预警"发现的问题一般都是与本系统有很大的关系，另外其他途径还需要额外判断条件，如：用户反馈数量，故障持续时间长度等，所以当问题产生时还是需要多手段，多角度，灵活运用各个方法以检测是否本系统出现问题；

3、故障定位

   在确定是线上问题之后，我们应该快速定位故障点，以便对症下药，快速解决问题。故障定位就是一个"收集信息"—>“提出假设”—>“推理验证”—>“进一步定位问题”；当然，生产线上往往是不允许直接验证的，需要在测试环境进行业务场景/性能场景的验证；一般来说， BUG的快速定位，可以从以下几点方面初步考虑，

• 是否有新版本的发布；

• 版本发布后部署是否正常 ；

• 是否有BUG更新；

• 潜在的BUG被激发，如遭遇高并发场景，访问量激增；

• 系统受到攻击，如黑客、羊毛党的恶意请求等；

• 上/下游服务器异常，或者宕机；

• 网络波动；

• 服务器故障，如线程池用尽、CPU爆表、内存不足等；

• 第三方服务故障，如数据库连接有误，服务器IDC供应商故障；

  针对以上方向，可以从观察系统相关信息以便支撑自己的假设：

• 版本近段时间的发布情况；

• 版本部署后正常，如.jar包更新是否齐全，配置文件有无更新，服务器负载是否均衡等；

• 有无BUG更新导致其他系统问题的产生；

• 系统流量是否激增，接口调用频率是否异常；

• 用户请求是否符合正常操作流程，请求参数是否合法，CPU占有率是否突然飙升等；

• 系统响应时间是否延迟，吞吐量是否下降等，上下游服务器是否畅通等；

• 一定时间范围内时间是否存在波动；

• 手动请求服务器是否爆502错误，内存、线程是否正常等；

• 第三方服务是否出现连接等问题导致服务无法使用；

   很多问题的产生往往都是多个条件同时满足时才会出现，所以问题的定位工作往往会伴随着很大的挑战。在定位问题过程中，讲究“快”、“准”、“狠”，快速响应并准确定位到问题产生原因后，及时给出解决方案，避免应时间成本的不必要增加。

4、故障排除

   故障发现后，接下来的故障修复就不是什么非常困难的事了，另外这里主要说下实在无法定位故障原因的一些非常规手法；

• 服务降级：暂时Closed或Half-Open系统的某些服务，为其他服务腾出系统资源，等到服务逐渐平稳之后再将服务开启；
• 服务熔断：当系统达到一定的压力时，主动停止服务，等到系统资源恢复到正常水平时，自动开启服务；
• 紧急扩容：如：营销活动、秒杀、恶意攻击等场景造成系统资源占有率一路飙升，且又无法定位到问题，可以对服务器进行紧急扩容，如增加服务器数量、带宽数量、存储数量、计算能力等；但如果系统架构固定，则只能通过增加已有服务器的CPU数量、内存数量、硬盘内等，但是会存在相当大的扩展容限；
• 版本回退：有新版本发布时，无法快速定位问题时，可以进行系统版本回退，保持系统的稳定性；
• 注：以上方法都是有比较大的风险，一般情况下会比较少使用，容易给用户带来非常不好的体验；

4、故障回溯

   排除故障之后，需要进行线上问题的解决流程进行反思和总结，找出流程中不合理或繁杂的地方，从而及时更新生产故障解决流程，必要时可以发起紧急会议，故障参与人员一起开会讨论问题的产生原因，最终输出一份详尽的故障报告；另外追溯故障的目的不是为了追溯责任，更重要的是为了大家长记性，避免往后的研发中或其他团队跳进之前的坑里；

5、故障预警监控

  上面谈了线上问题的发现，定位、排除和追溯，但是问题的快速处理，需要很多基础设施的支持，它们都是线上问题处理最必须的条件。

• 服务器监控：监控服务器的的资源（如：cpu占有率、I/O、线程池、吞吐量、时延等），通过这些服务判断系统的状态而采取对应的应对措施；
• 业务监控：监控系统失败请求、错误率 、timeout请求等，若异常达到一定比例时系统应自动发送邮件通知相关人员，争取在用户反馈之前处理并修复问题；
• 系统运行日志：详尽完整的日志，排查定位线上问题产生原因，很大程度上取决于系统运行日志，通过日志和系统可以快速定位问题产生原因；
• 建立7*24小时运营反馈机制（慎用）：一般事件上报，都会有专门的通道提供给用户，但是往往因为工作时间等很多原因，导致出现很大的时延性，保持反馈渠道的畅通对于一些系统服务面积非常广泛，或者系统稳定性要求非常高的企业来说是非常有必要的，但是往往也会带来高额的企业成本；

6、总结

  以上，对系统故障的整个链路进行了讨论；总之，线上排障的第一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，还需要总结以便‘避坑’。另外在平时的系统中也要建立相对应的基础设施，如完整的系统监控机制，完善的日志trace体系，以及通畅的问题反馈渠道。