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