一 概述
尽管我们可以通过稳定性体系建设，来避免出现生产系统故障。但是仍然无法彻底避免一点风险都不会产生，当稳定性风险产生后，怎么快速协调组织，缩短故障时长，科学的流程就非常重要了。
好在我们现在就开始思考的话，我们还有充足的时间去设计各个环节，并让参与的同学充分的锻炼，从而做到训练有素，为故障恢复争取宝贵的时间。
二 结构化问题解决
对于问题解决有很多结构化解决方法，尤其是各种专业的咨询公司，这些流程值得我们借鉴。结合软件系统的生产环境故障来描述的话，一个典型的结构化问题解决步骤如下：
-
问题定义：清晰的描述问题现象、影响，其中影响要尽量量化。例如xx时xx分开始，xx服务异常，成功率从99%下跌到90%。
-
临时解决：基于预案的临时解决方案和实施结果，包括符合条件的预案执行，或者应用发布过程中出现的异常后立即回滚。
-
分析问题原因：结合已知因素，找到问题的根本原因。
-
制定解决方案。
-
实施解决方案。
-
标准化解决方案：将解决方案标准化，举一反三，避免同类问题继续发生。
生产环境中，出现突发异常时候，我们第一优先的是考虑怎么快速恢复服务，因此本文中重点介绍上面流程中前面2个步骤。
另外，问题解决里，沟通是贯穿在整个流程里的。需要在各个环节都做好充分的沟通。
三 关键角色
突发异常的情况都各有不同，很难有一个完全统一而且颗粒度很细的标准流程，但是可以提前约定好几个关键角色，定义角色的作用和关键动作，来提升协作效率。
主要包括这些角色：
-
指挥员：负责组织和协调故障快速恢复、故障群里通报相关进展。
-
通讯员：负责收集、记录关键信息，并在故障群等渠道跟相关团队沟通。
-
快恢负责人：根据故障现象、监控大盘，决策并执行预案。
-
问题诊断负责人：定位故障根本原因，当快恢不起作用的话，该角色至关重要。
以下是各个角色的详细描述。
1 指挥员
指挥员的选择
-
第一接警人：默认第一个收到告警、投诉反馈的技术人员作为指挥员。第一接警人判断是否能够指挥，或者是否有自己熟悉且充分演练的预案可用，如果可以则立即恢复服务，否则联系专职指挥员接手。在专职指挥员接手之前，第一接警人就是默认的指挥员。
-
专职指挥员：团队 Leader 和稳定性负责人是大多数风险的最佳指挥员，当应急团队建立联系后，指挥员可以交由 TL 或团队内的稳定性负责人。
-
各级TL：当故障时长和等级持续上升后，根据实际情况会上升，由更高层级 TL 接掌指挥员角色，以协调更多资源加入。
指挥员关键动作
-
确认问题：确定该次突发事件的现象、影响。
-
确定角色：确定参与该次事件处理的关键角色，包括通讯员、快恢负责人、问题诊断负责人。
-
向上沟通：让组织中关键角色知晓该问题，这样在需要时候，可以更快的调动更多人员和资源参与进来。
-
协调：协助快恢负责人和问题诊断负责人解决问题，在信息、领域专家等资源上给予支援。
对指挥员的要求
-
启动：确定人员，并通过视频会议、故障群等方式建立起应急小组。
-
前期：紧盯快恢负责人进展，优先落地快恢，而不是分析根本原因。当快恢不生效后，也要继续探索可能的快恢手段，例如回滚近期的变更等操作。过往的故障时长没有满足1-5-10的案例中，大多数情况下都是指挥员在分析问题根本原因，错失了快恢的最佳时机。
-
中期：尝试大量手段都无法恢复服务的话，重心逐渐转移到问题诊断负责人这里，找到根本原因。通常进入到这个阶段故障还没恢复的话，就是大故障了，1-5-10基本上是无法达标的。
-
后期：组织团队继续观察，确认不会问题再复现。组织善后和复盘等工作。
2 通讯员
如果故障不能在第一时间通过预案恢复的话，通讯员将会是仅次于指挥员的角色。高效组织信息收集、整理，会让整个应急小组更快速度找到解方案。
通讯员选择
-
专职通讯员：在团队内有一定稳定性认知，然后通常又不是快恢负责人和问题诊断负责人第一人选的那个同学。
-
其他不参与问题诊断和快恢的团队成员。
通讯员关键动作
-
持续确认问题和通报：随着时间推移，问题的现象、影响面也在动态变化，需要定期通报（故障群、电话会议等渠道），前期要做到5分钟换一次通报，随着时间推移，后期可以改成15分钟、30分钟等间隔。
-
信息收集：按照标准模版，为该问题建立一个统一的文档，把文档链接放到群公告、故障群中。并持续将收集的关键信息更新进去。方便后续加入到应急小组的同学快速了解上下文。
-
收集舆情：这一点跟信息收集有重叠，之所以特别强调出来，是因为该环节通常容易被忽略，技术同学容易陷入在技术指标中，对于舆情缺乏关注。
-
对外发声：联系客服负责人，与客服团队合作，安抚客户。
对通讯员关键要求
-
前期要快：快速收集关键信息，黄金10分钟内要做到每分钟有信息更新，并持续通报。
-
通报及时：好的信息通报是告知下次通报时间，例如xx问题yy正在处理中，目前情况是zzz，xx分钟后将进行下一次通报。如果有可靠和及时的通报，关注该问题的人只需持续留意信息通报即可，避免非专业的插手影响应急小组快速反应。
-
联系外部支援：涉及到外部依赖方的时候，例如OSS、MySQL等，通过指挥员、应用Owner等渠道知晓外部接口人的时候，及时组织外部接口人加入到应急小组中来，并向对方通报问题上下文。
3 快恢负责人
我们的期望是所有的风险都能够通过快恢来解决，如果不能的话，也是第一时间探讨其他可行的快恢方案（比如回滚等操作）。
快恢负责人选择
-
应用Owner/核心骨干。
-
执行过该应用预案的团队成员：我们鼓励团队之间交叉执行预案，当应用Owner联系不上的时候，其他同学也可以通过预案来协助问题恢复。
快恢负责人关键动作
-
执行快恢预案：根据问题现象，找到预案大盘，根据大盘上监控指标指引去执行相应的预案。
-
制定其他候选恢复方案：当已知快恢预案不生效时候，分析可能的变更等因素，通过回滚等方法尝试恢复。必要时候，让指挥员协调更多人进来支持。
快恢负责人关键要求
-
以恢复服务为第一优先级，问题根因分析请交给问题诊断负责人。
-
既定预案不能快恢，也要继续探索其他可能的恢复手段。
4 问题诊断负责人
通常我们不希望这个人出现在故障1-5-10的恢复环节，但是当快恢失效并且短时间内缺乏有效手段恢复服务的话，最后只能靠问题诊断负责人来找到根本原因，并制定解决方案。
问题诊断负责人选择
-
应用Owner/骨干：了解相关代码的人最适合去做问题诊断。
-
领域专家：比如网络问题，可以从集团找到该领域专家协助参与进来。
问题诊断人关键要求
-
根据收集的信息，找到问题根本原因。
-
向指挥员、通讯员提出要求，把外部支援邀请加入到应急小组中。
四 最后
故障应急响应是维持系统高可用的最后一个机会，这个环节的不专业表现，对于稳定来说是最后彻底的失守。因此，跟预案演练一样，故障应急也需要重点锻炼。一些可以锻炼的机会包括：
-
真实的故障场景。
-
红蓝对抗演习：与SRE联动，通过突袭方式，模拟一次故障。
-
常规报警升级：TL或者稳定性负责人随机抽取一个短信告警，人为将其升级为故障，进入故障应急响应流程。
标签：负责人,预案,通报,流程,指挥员,问题,故障,应急 来源： https://www.cnblogs.com/276815076/p/14785581.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。