线上服务应急与技术攻关方法论

海恩法则和墨菲定律

海恩法则指出：

每一块儿严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。

海恩法则强调两点：

（1）事故的发生是量的积累的结果；

（2）再好的技术，再完美的规章，在实际操做层面，也没法取代人自身的素质和责任心。

根据海恩法则，一块儿重大事故发生以后，咱们要在处理事故和解决问题的同事，还要及时的对同类问题的「事故征兆」和「事故苗头」进行排查并处理，以防止相似问题的再次发生，将问题在萌芽状态就将其解决掉，这能够做为互联网企业线上应急的指导思想。

墨菲定律指出：

若是有两种或者两种以上方式去作某件事情，而选择其中一种方式将致使灾难，则一定有人会作出这种选择。

默认定律强调一下几点：

（1）任何事情都没有表面看起来那么简单

（2）全部事情的发展都会比你预计的时间长

（3）会出错的事情总会出错

（4）若是你担忧某种状况会发生，那么它更有可能发生

墨菲定律其实是个心理学效应，若是你担忧某种状况会发生，那么它更发生的可能性很大，长此以往就必定会发生。

墨菲定律给到咱们技术人的警示：

对生产环境发生的任何怪异现象和问题都不要轻视，对其背后产生的缘由必定要彻查。

海恩法则给到咱们技术人的警示：

任何生产环境的严重故障，背后都有不少次小问题的积累，积累到必定量级以后会致使质变，进而发生更严重的故障。

因此，咱们须要对线上服务，产生的任何问题征兆，不论问题大小，都要刨根问底，对任何问题都要持怀疑态度，问问本身"为何会发生？发生的缘由是什么？如何排查和解决？怎么快速恢复服务？如何避免？"等等。不能由于问题的现象不明显而忽略。

线上应急的目标、原则、方法

一、应急目标

行动的方向在关键时间正确把握，在应急过程当中不能偏离目标。

生产环境发生故障，要快速优先想办法恢复服务，避免或减小因故障形成的损失，下降对用户的影响。

二、应急原则

对应应急原则总结以下：

（1）第一时间恢复系统而不是完全查找缘由解决问题，快速止损。

（2）有明显的资金损失时，要在第一时间升级，快速止损。该条用在金融领域尤其关键。

（3）当前应急负责人若短期内没法解决问题，必须升级处理。

（4）应急过程当中在不影响用户体验前提下，要保留部分现场和数据。便于恢复后定位分析问题缘由。

三、应急方法和流程

线上应急必须有组织、有计划的进行。

线上应急主要分为六个阶段：

应急要有整体目标：尽快恢复问题，消除影响。无论应急的那个阶段，首要问题都是优先恢复系统问题，恢复问题不要求立马定位问题，也不必定有完美的解决方案。

通常经过经验判断，启动线上的问题预处理方案等，达到快读恢复问题的目标。同时，要注意保留部分现场，便于过后定位解决并复盘问题。

一、发现问题

一般针对系统层面来讲的，问题的发现必定是借助于系统的告警、自动化监控等机制来实现的，不能由用户、业务方来告诉通知你的系统出现问题了，若是这样，你的系统出现问题已经持续了一段时间了。

监控层面，一般都是对系统层面、应用层面、资源层面进行监控。

对系统层面的监控包括：系统的CPU利用率、系统负载、内存是会用状况、网络IO负载、磁盘负载、I/O等待、交换区的使用、线程数及打开的文件句柄数等进行监控，一旦超出阈值，就及时告警。

对应用层面的监控包括对服务接口的响应时间、吞吐量、调用频次、接口成功率即接口的波动率进行监控。

对资源层面的监控包括对数据库、缓存和消息队列的监控。咱们一般会对数据库负载、慢SQL、链接数等进行监控；对缓存的链接数、占用内存、吞吐量、响应时间等进行监控；对消息队列的响应时间、吞吐量、负载、积压状况进行监控。

二、定位问题

首先要根据经验来分析 ，应急团队中有人对相应问题有经验，并肯定可以经过某种手段来进行恢复，则应第一时间快速恢复，同时保留现场，而后定位问题。

应急人员定位过程当中可能须要与业务负责人、技术负责人、技术人员、运营和运维一块儿，对产生问题的缘由进行快速分析。

须要考虑以下问题：

（1）问题系统最近是否进行了上线操做？

（2）依赖的基础平台和资源是否进行了上线或者升级？

（3）依赖的系统最近是否进行了上线？

（4）运营是否在系统里面作过运营变动？

（5）网络是否有波动，联系运维人员协助排查？

（6）最近的业务访问量是否正常，是否有异常流量？

（7）服务的适用房是否有促销活动？

三、解决问题

解决问题的阶段有时在应急处理中，有时在应急处理后。理想状况下，出现问题系统启动应急预案，每一个系统会对各类问题设计止损、兜底、降级开关等策略。所以，发生严重问题先使用启用这些预案来恢复问题，以后再定位和解决问题。

解决问题固然要以定位问题为基础，必须清楚的明确分析出问题的根本缘由，再提出解决问题的有效方案，切记没有明确缘由以前，不要使用各类可能方法来尝试修复问题，这样可能尚未解决当前问题，可能会引出了另一个问题。

四、消除影响

解决问题时，某个问题可能尚未被解决就已恢复，不管在那种状况下都须要消除问题产生的影响。

五、复盘问题

消除问题后，须要应急团队与相关方回顾事故产生的缘由、应急过程的合理性，对树立处理啊的问题提出整改措施，主要聚焦一下几个问题：

（1）相似的问题还有哪些没有想到？

（2）作了哪些事情，这个事故就不会发生了？

（3）作了哪些事情，这个事故即便发生了也不会产生损失？

（4）作了哪些事情，这个事故即便法神过来，也不会产生这么大的损失？

固然，回顾事故目的再也不犯相似的错误，而不是惩罚当事人。

六、避免措施

根据回顾问题提出的改进方案和避免措施，咱们必须以正式的项目管理方式进行统一管理，若是有项目经理的角色，则将避免措施和改进措施一并交给项目经理去跟进；若是没有，则请创建一个改进措施和避免措施的跟进方案和机制，不然，长此以往，问题就被忽略了。

技术攻关方法论

技术攻关流程图：

技术攻关的目标是解决问题。

从问题发生的环境和背景入手，优先考虑上述图中的提到的几个问题：

一、最近是否有变动、升级或上线操做？

优先考虑这一条，特别是上线完成后收到系统告警，用户反馈的相关问题及时关注，若是因上线致使出现的问题，要第一时间回滚处理，避免扩大影响。

同时，创建健全上线流程和上线评审机制，每次上线都须要有快速回滚方案。

二、以前是否有遇到过相似的问题？

根据历史经验判断系统是否曾出现过相同或相似的问题，若是有解决相似的问题经验，能够参考快速的应用历史经验解决问题。

要求每次故障后复盘并总结故障缘由，并给出问题解决方案，积累到经验库。

三、是否有相关领域的专家？

遇到了更深层次的问题，好比遭遇DDOS攻击、性能扛不住、网络故障、使用的中间件频繁告警等。相似问题先求助相关领域专家，他们积累了更加丰富的经验，或能更深刻了解缘由并快速解决问题。

以上流程仍然没法解决问题，就须要本身想办法作技术攻关了。

对于任何问题的分析，须要从如下几个方面入手来分析：

简称：5W

When：何时出现的问题？

What：什么出现了问题？

Who：谁在什么时间里发现了问题？问题影响了谁？

Where：哪里出现了问题？

Why：为何出现了问题？

根据以上的分析，帮助你理清思路，初步对系统作判断，而后从这个系统的日志、数据、工具，并结合代码定位分析问题缘由。

这里也就体现了系统中日志的重要性，好的日志能协助快速而准确的定位问题。

能够想办法「最小化复现」线上问题，最小化复现是问题产生时所依赖的组件最小化集合，容易搭建，减小了使用组件的范围，有助于迅速定位问题缘由。

若是能在一个可控的环境或者仿真环境上重现问题，或者经过远程调试的手段也能协助定位问题。

定位到问题缘由后，要给出解决方案。

评估解决方案对线上的影响，权衡利弊，选择最佳方案，并给出选择的缘由。

将问题解决方案报备给上级进行评审，评审经过后再实施。方案须要在开发环境和QA环境进行验证，不只仅要验证方案所解决的问题，同时，还要避免对现有功能有所影响，所以可能还须要进一步回归验证。

经过这样一系列技术攻关流程，能够保障技术攻关过程当中获得完整、正确且高效的问题解决之道。

参考：分布式服务架构、原理、设计与实战

欢迎关注个人公众号，扫二维码关注得到更多精彩文章，与你一同成长~