地震是由不可抗力导致的，而事故与之不同，任何大的生产事故在发生之前都有迹可循，而且事故的发生并不是偶然的，我们应该善于从现象中总结规律，找到发现、止损和避免的方法
海恩法则
每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆及1000起事故隐患。
- 事故的发生是量的积累的结果。
- 再好的技术、再完美的规章，在实际操作层面也无法取代人自身的素质和责任心。
根据海恩法则，一起重大事故发生后，我们在处理事故和解决问题的同时，还要及时对同类问题的"事故征兆"和"事故苗头"进行排查处理，以防止类似问题重复发生，把问题解决在萌芽状态，这完全可以作为互联网企业线上应急的指导思想。在线上应急的过程中，不但要定位和解决问题，还要发现问题的根源，并找到发生事故之前的各种征兆，对征兆进行排查和分析，并做响应的报警处理。
墨菲定律
如果有两种或两种以上方式去做某件事情，而选择其中一种方式将导致灾难，则必定有人会做出这种选择。
- 任何事情都没有表面看起来那么简单。
- 所有事情的发展都会比你预计的时间长。
- 会出错的事情总会出错。
- 如果你担心某种情况发生，那么它更有可能发生。
墨菲定律实际上是个心理学效应，如果你担心某种情况会发生，那么它更有可能发生，久而久之就一定会发生。这警示我们，在互联网公司里，对环境发生的任何怪异现象和问题都不要轻易忽视，对于其背后的原因一定要彻查。 同样，海恩法则也强调任何严重事故的背后都是多次小问题的积累，积累到一定的量级后会导致质变，严重的问题就会浮出水面。
对于任何现象都要秉承着"为什么发生？发生了怎么应对？怎么恢复？怎么避免？ "的原则，对问题要彻查，不能因为问题的现象不明显而忽略。
6.2. 线上应急的目标、原则和方法
6.2.1. 应急目标
在生产环境发生故障时快速恢复服务，避免或减少故障造成的损失，避免或减少故障对客户的影响，
6.2.2 应急原则
- 恢复系统，快速止损，而不是彻底解决问题。
- 有明显的资金损失时，升级问题快速止损。
- 不影响用户体验的前提下，保留部分现场和数据。
6.2.3 线上应急的额方法和流程
有条不紊地进行，遇事胆大心细,该做决策的时候要毫不犹豫，该升级的时候要果断。
线上应急一般分为6个阶段:发现问题、定位问题、解决问题、消除影响、回顾问题、避免措施。
在应急过程中要记住，应急只有一个总体目标:尽快恢复问题，消除影响。
定位问题
- 问题系统最近是否进行了上线？
- 依赖的基础平台和资源是否进行了上线或者升级？
- 依赖的系统最近是否进行了上线？
- 运营是否在系统里面做过运营变更？
- 网络是否有波动？
- 最近的业务量是否增加？
- 服务的使用方是否有促销活动？
回顾问题
- 类似的问题还有哪些没有想到？
- 做了哪些事情，这个事故就不会发生？
- 做了哪些事情，这个事故即使发生了，也不会产生损失？
- 做了哪些事情，这个事故即使发生了，也不会造成这么大的损失？
6.3 技术攻关的方法论
技术攻关的目标是解决问题，因此首先要从问题发生的环境和背景入手，首先考虑下面几个问题。
最近是否有变更、升级和上线？(回滚)
之前是否遇到过类似的情况？(使用历史经验)
是否有相关领域的专家？例如:安全、性能、数据库、大数据和业务等领域的专家(开启专家模式)【最小化复现→找到原因→提出解决方案→验证解决方案→线上实施】。
对于任何问题，我们必须收集发生这些问题的现象，考虑如下问题。When:什么时候出的问题？
What:什么出了问题？
Who:谁在什么时间里发现了问题？问题影响了谁？
Where:哪里出现了问题？哪里又没出现问题？
Why:为什么出现了问题？
6.5高效的服务化治理脚本
6.5.1 show-busiest-java-threads
此命令是用来查找java进程内CPU利用率最高的线程，一般适用于服务器负载较高的场景，并需要快速定位负载过高的成因。
命令格式:
sh
./show-busiest-java-threads -p 进程号 -c 显示条数
./show-busiest-java-threads -h脚本源码:
sh
#!/bin/bash
PROG=`basename $0`
usage()