分布式服务架构[原理、设计与实践]学习笔记

地震是由不可抗力导致的，而事故与之不同，任何大的生产事故在发生之前都有迹可循，而且事故的发生并不是偶然的，我们应该善于从现象中总结规律，找到发现、止损和避免的方法

海恩法则

每一起严重事故的背后，必然有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利用率最高的线程，一般适用于服务器负载较高的场景，并需要快速定位负载过高的成因。

命令格式:

./show-busiest-java-threads -p 进程号 -c 显示条数
./show-busiest-java-threads -h

脚本源码:

#!/bin/bashPROG=`basename $0`
usage()