本文主要分享《分布式服务架构：原理、设计与实战》相关的线上应急的目标、原则和方法。之所以分享在于近来再次回顾了以往的线上应急案例，觉得其中的内容有很大的参考价值。
一、线上应急的目标是什么？
行动的方向在关键时刻一定要正确，在应急过程中不能偏离目标：
在生产环境发生故障时快速恢复服务、避免或减少故障造成的损失，避免或减少故障对客户的影响。
二、线上应急的原则包含哪些？
- 1.应第一时间恢复系统而不是彻底解决问题，快速止损。
- 2.有明显的资金损失时，要在第一时间升级，快速止损。
- 3.应急指挥要围绕目标，快速启动应急过程和快速决策止损方案。
- 4.当前应急责任人如果在短时间内不能解决问题，则必须进行升级处理。
- 5.应急过程中在不影响用户体验的前提下，要保留部分现场和数据。
三、线上应急的方法和流程有哪些？
线上应急一般分为6个阶段：发现问题、定位问题、解决问题、消除影响、回顾问题、避免措施。
1.发现问题
发现问题时通常通过自动化的监控和报警系统来实现。一般我们会对系统层面、应用层面和数据层面进行监控。
对系统层面的监控包括对系统的CPU利用率、系统负载、内存使用情况、网络I/O负载、磁盘负载、I/O等待、交换区的使用、线程数及打开的文件句柄数等进行监控，一旦超出阈值，就需要报警。
对应用层面的监控包括对服务接口的响应时间、吞吐量、调用频次、接口成功率及接口的波动率等进行监控。
对资源层的监控包括对数据库、缓存和消息队列的监控。我们通常会对数据库的负载、慢SQL、连接数等进行监控；对缓存的连接数、占用内存、吞吐量、响应时间等进行监控；以及对消息队列的响应时间、吞吐量、负载、积压情况等进行监控。
2.定位问题
定位问题时，首先要根据经验来分析，如果应急团队中有人对相应的问题有经验，并确定能够通过某种手段进行恢复，则应该第一时间恢复，同时保留现场，然后定位问题。
在应急人员定位过程中需要与业务负责人、技术负责人、核心技术开发人员、技术专家、架构师、运营和运维人员一起，对产生问题的原因进行快速分析。
在分析过程中要先考虑系统最近发生的变化，需要考虑如下问题:
- (1)问题系统最近是否进行了上线？
- (2)依赖的基础平台和资源是否进行了上线或者升级？
- (3)依赖的系统最近是否进行了上线？
- (4)运营是否在系统里面做过运营变更？
- (5)网络是否有波动？
- (6)最近的业务是否上量？
- (7)服务的使用方是否有促销活动(不仅仅可能是一些商业活动还可能是其它相关)？
3.解决问题
解决问题的阶段有时在应急处理中，有时在应急处理后。在理想情况下，每个系统会对各种严重情况设计止损和降级开关，因此在发生严重问题时先使用止损策略，在恢复问题后再定位和解决问题。
解决问题要以定位问题为基础，必须清晰地定位问题产生的根本原因，再提出解决问题的有效方案，切记在没有明确原因之前，不要使用各种可能的方法来尝试修复问题，这样可能还没有解决这个问题又引出另一个问题。
4.消除影响
在解决问题时，某个问题可能还没解决就已恢复，无论在哪种情况下都可能需要消除问题产生的影响。
- (1)技术人员在应急过程中对系统做的临时性改变，后证明是无效的，则要尝试恢复到原来的状态。
- (2)技术人员在应急过程中对系统进行的降级开关的操作，在事后需要恢复。
- (3)运营人员在应急过程中对系统做的特殊设置如某些流量路由的开关，需要恢复。
- (4)对使用方或者用户造成的问题，尽量采取补偿的策略进行恢复，在极端情况下需要一一核实。
- (5)对外由专门的客服团队整理话术统一对外宣布发生故障的原因并安抚用户，话术尽量贴近客观事实，并从用户的角度出发。
5.回顾问题
消除问题后，需要应急团队与相关方回顾事故产生的原因、应急过程的合理性，对梳理出来的问题提出整改措施，主要聚焦于如下几个问题:
- (1)类似的问题还有哪些没有想到？
- (2)做了哪些事情，这个事故就不会发生？
- (3)做了哪些事情，这个事故即使发生了，也不会产生损失？
- (4)做了哪些事情，这个事故即使发生了，也不会产生这么大的损失？
当然，回顾事故的目的是不再犯类似的错误，而不是单单惩罚当事人，就没有然后了。
6.避免措施
根据回顾问题时提出的改进方案和避免措施，我们必须以正式的项目管理方式进行统一管理。如果有项目经理的角色，则将避免措施和改进措施一并交给项目经理去跟进；如果没有，则请建立一个改进措施和避免措施的跟进方案和机制，否则，久而久之，问题就被忽略了。
四、我在实践中是如何应用上述目标、原则和方法的？
过往写的一些文章可供读者朋友们参考：
- 1.基于报告之复盘
- 2.Gateway Timeout 504问题复盘
- 3.ssh问题之复盘
- 4.数据库被删之反思
- 5.服务器安全策略之思考与实践
- 6.Linux设备上没有空间之复盘
- 7.项目依赖管理混乱问题之解决
- 8.分布式配置中心之思考
- 9.WebService安全机制的思考与实践
- 10.SQL优化之博客案例
回顾职业生涯，除以上文章列举的案例外，还有更多，例如以下三个：
- 1.在创业公司的时候，为什么Tomcat上的应用服务总是宕机(那个时候我没有弄清楚真正的原因是什么，采用一个临时的办法，写shell脚本，每分钟检测，如果宕机，立即重启，以此确保服务的正常运行)？
- 2.在教育Saas公司的时候，为什么MongoDB会导致整个系统崩塌(后面我们团队以此复盘以后，我明白了为什么以及后续将如何避免这样的问题，其实这已经不是一个小小的中间件问题，上升到整个业务流程的管理)？
- 3.在M2公司的时候，为什么报告不能实时生成反而将其改为定时生成(经过当初的多次试验，我弄清楚了为什么，这既有技术层面的实现原因，也有业务层面的数据处理问题)？
同样无论你的职责是研发工程师还是架构师、技术经理、项目经理之类的，都需要敬畏以下法则和定律:
- 1.海恩法则。
- 2.墨菲定律。
1.海恩法则
海恩法则的定义为:
每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆及1000起事故隐患。
该法则强调如下两点：
- (1)事故的发生是量的积累的结果。
- (2)再好的技术、再完美的规章，在实际操作层面也无法取代自身的素质和责任心。
2.墨菲定律
如果有两种或两种以上方式去做某件事情，而选择其中一种方式将导致灾难，则必定有人会做出这种选择。
墨菲定律强调以下四点:
- (1)任何事情都没有表面看起来那么简单。
- (2)所有事情的发展都会比你预计的时间长。
- (3)会出错的事总会出错。
- (4)如果你担心某种情况发生，那么它更有可能发生。
本文分享到此结束，希望能够对大家有所帮助！！！