一、优先恢复业务

  1.   恢复业务优先是指，不管在任何情况下，也不管任何级别的故障，都要先做到恢复业务，当发生故障的时候，大家的第一反应是定位故障（定位到具体原因），再进行业务恢复，在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级！

二、及时升级

1、有明确的业务影响
2、非常重要的业务的严重以上的告警故障
3、处理时效明显超长
4、有高级别领导，监控中心或者客服已关注到了该故障
5、很明确超出了自己的能力范围

三、处理故障的常见方法

1、服务整体性能下降或异常，可以考虑重启服务；
2、故障对象提供服务异常，可考虑隔离；
3、应用做过变更，可以考虑是否需要回切变更；
4、资源不足，可以考虑应急扩容；
5、应用性能问题，可以考虑调整应用参数、日志参数；
6、数据库繁忙，可以考虑通过数据库快照分析，优化SQL；
7、应用功能设计有误，可以考虑紧急关闭功能菜单；
故障处理一般会分为三个阶段，故障前，故障中和故障后，故障前是指故障的定位分析（在发生故障前，由哪些人执行了哪些操作，有可能引起了这个故障），故障中是指故障处理过程，故障后是指故障总结；
重启：重启包括服务重启和服务器重启（os重启）两种，在发生故障中，任何中涉及到的环节，都可以重启来完成，重启的一般顺序是，故障对象>故障对象上游>故障对象下游，一般离故障对象越远，重启顺序越靠后。
隔离：隔离是指对故障的对象从集群中抽离的过程，目的是让故障对象不在提供服务
降级：降级是指为了防止产生更大的故障所采取的一种预案，一般而言，降级一定不是当下生产的给用户的最优状态，即使没有技术影响，也会或多或少带来一些业务的影响，比如自动配载出现问题的时候，采用人工配载的方式，虽然能达到一样的目的，但是影响工作效率；

四、故障复盘

4-1、故障复盘的概念

  1.  复盘源于围棋术语，复盘也称「复局」，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。这样可以有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞，是提高自己水平的好方法；「故障复盘」本身也是一致，就是对故障发生及处理过程重新「过」一遍，对这个过程的进行和思考进行回顾，反思和探究，实现稳定性及能力的提升。

4-2、故障复盘的目的

  1. 简单点说就是，故障进行定性、故障定责及总结本次故障带来的经验教训，为什么要对故障进行定性？可总结为以下几个方面：<br />A.通过故障定性，评估对业务带来的影响、损失及范围；<br />B.通过故障定性，我们可以更加有序、科学的投入不同程度的资源来解决不同级别的问题；<br />C.跳出本次故障本身，更抽象性的看待同级别、不同级别故障的共性或差异，可更加系统化的解决共性问题；<br />**首先，我们要明白故障复盘   不等于是追责或者是惩罚**<br />**要辩证地看待故障这件事 **复盘的目的是为了**从故障中学习**，找到我们技术和管理上的不足，然后**不断改进。**虽然我们都不愿意故障发生，但是从故障中学习，反而是提升团队和员工能力的最佳手段。<br />问题复盘的意义就在于找到问题的原因，然后加以改进，避免同样的问题反复出现，降低问题发生的概率和影响；<br />**有助于避免犯同样的错误，降低成本：**让出现过的故障处于「可控」又或「收敛」的状态，从出现的故障中可以提炼、固化一些流程，提升效率的同时，同样或同类也可以避免出现同样的故障；<br />**校准方向：**复盘有助于让自己始终保持在正确的方向，让我们所有的工作更有目的性，需要解决什么问题，改进措施需要达到什么效果，从而更明确/清楚工作目的，提高工作效率；<br />**看清故障背后的问题，找出故障背后真正的原因：**复盘过程中，可以让我们去总结以及分析导致故障的原因，对故障提出对应的改进措施，发现解决问题的新思路或者新方法，更加客观的认清业务当前稳定性的现状（实事求是），以便寻求最佳的解决办法；<br />一般人为性的失误操作都是要准备分享会议：目的是为了下次再次发生类似故障的时候，避免采坑，分享会议中，有些人肯定会觉得，我不用处理这一块的工作内容，所以这个事情一定不会在我身上发生的，但是“人常在河边走，难免会湿鞋”，且分享的目的不是说这次故障再次发生的时候，我们应该怎么做，而是要学会反思同类故障发生的时候，我们应该怎么做，才能较少恢复的时间/快速恢复业务；

五、故障复盘方法

故障复盘的内容涵盖以下四点：事实、分析、定责和改进4部分
4-1、讲清楚事实：事实是复盘的基础，如果连事实都无法陈述清楚，就无法深入分析、提出针对性的改进措施—-为了讲清楚事实，我们需要明确时间线，也就是我们故障报告中的时间回放（产生过程、处理过程），包含发现问题时间、响应问题时间、处理问题（处理过程中采取的各种关键措施的时间点），问题恢复的时间和问题影响的结果等信息===时间信息是非常关键的，因为可以反映出问题发现的速度，各种措施执行时间和团队响应效率指标等；

4-2、全面且深入地分析：首先要保证没有遗漏问题（确保故障影响的问题点有哪几项），其次需要针对每一个问题进行深入的分析，避免以后以其它的形式再次出现（不可为了填补本次故障的坑，然后在其它地方再挖一个坑）；
为了全面且深入的分析，我们要明确问题链，也就是问题的传导路径
问题链的路径逻辑分为2类：业务流程和项目流程
业务流程：指的是端到端的业务处理的过程，它的分析对象是故障各个关联的系统
项目流程：指的是端到端的项目开发的过程，分析的对象是各个阶段相关的人员，比如开发、测试、产品（开发的代码问题、测试用例不全，测试不到位、产品的业务流程设计不合理等）
我们一般先采用业务流程的逻辑将问题定位到单个系统，然后再针对单个系统采用项目流程的方式将问题定位到具体的人或者流程中的某个步骤；

首先，故障并非都是坏事，偶尔它是避免大故障发生的预警，谁或哪个团队对本次故障负主要责任及次要责任。做到边界清晰、权责对等；由本次故障带来了哪些经验教训，包括得失的体会，以及是否有规律性的东西值得思考；
4-3、得出有说服力的定责结论：根据深入分析后的结果，进行定责（分析的原因是明确定责的标准之一）；
如何得出有说服力的定责结论，首先，我们要明确责任链，也就是问题责任人之间的关系
需要结合以下几点进行定责：结合时间线中问题影响的结果、公司的故障定级标准、问题链的分析结果，最终决定由哪些团队或个人承担责任，分别承担多大的责任，接受什么样的处罚等；
之所以叫责任链，是因为一个问题的发生往往是整个流程上的多个环节的相关处理人有问题，才会导致最终的问题发生———-比如开发人员引入bug，测试人员遗漏了测试，产品人员未对开发的内容进行验收确认………
附加：故障定级的四大范围：A.故障是否影响业务系统的核心功能？B.故障发生到最终解决的时长；C.故障的影响面（全网用户/部分用户）D.发现途径：监控发现还是用户反馈？

4-4、制定可落实的改进措施：改进措施避免形式化，空喊口号，不可落实，分析不彻底（只针对单个故障提出对应的改进措施——如跨声的轻应用新旧版本不兼容的问题，只针对当前提出解决办法，改进措施不全面）
改进线：具体的改进措施、改进责任人、和时间节点
改进计划的思路来源于2个方面：时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方，较少恢复故障的时间，其次通过问题链找到具体需要解决的问题；

六、故障改进措施建议？

即对上面的分析、总结确定进行后续相关的改进、优化的落地措施。所以制定的动作及措施都需要符合以下建议：
S.即改进项：我们需要改进、优化的单项、指标是什么？
M.即验收标准：指定改验收标准是什么？
A.即改进项是否可以达到：避免出现一些假大空、无法落地的改进；
R.即要与其他改进具有一定的相关性：即尽可能避免出现孤立的改进；
T.即预期解决时间：这个时间建议最长不要过长（不要超过三个月），避免改进流于形式；
最后明确改进措施的相关负责人，跟进后续的改进项的状态，最终确认改进的结果与验收标准的贴合度，是复盘的最终目的及最好的指标

七、组织架构：

故障处理者：他们的职责就是尽快恢复业务
故障定位者：他们的职责是当故障处理者方法失效或者需要查找问题根因时，解决故障
信息传递者：他们的职责是对故障处理，故障定位传递有效信息，同时对外部传递故障进展信息
往往运维这三类人不会同时存在，比如在凌晨值班时，只需要故障处理者处理即可，恢复业务后，第二天由故障定位者去找根因及优化措施。