稳定性之故障应急处理流程

2024-08-26 17:08

本文主要是介绍稳定性之故障应急处理流程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一 概述

尽管我们可以通过稳定性体系建设,来避免出现生产系统故障。但是仍然无法彻底避免一点风险都不会产生,当稳定性风险产生后,怎么快速协调组织,缩短故障时长,科学的流程就非常重要了。

好在我们现在就开始思考的话,我们还有充足的时间去设计各个环节,并让参与的同学充分的锻炼,从而做到训练有素,为故障恢复争取宝贵的时间。

二 结构化问题解决

对于问题解决有很多结构化解决方法,尤其是各种专业的咨询公司,这些流程值得我们借鉴。结合软件系统的生产环境故障来描述的话,一个典型的结构化问题解决步骤如下:

  • 问题定义:清晰的描述问题现象、影响,其中影响要尽量量化。例如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或者稳定性负责人随机抽取一个短信告警,人为将其升级为故障,进入故障应急响应流程。

这篇关于稳定性之故障应急处理流程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1109165

相关文章

Security OAuth2 单点登录流程

单点登录(英语:Single sign-on,缩写为 SSO),又译为单一签入,一种对于许多相互关连,但是又是各自独立的软件系统,提供访问控制的属性。当拥有这项属性时,当用户登录时,就可以获取所有系统的访问权限,不用对每个单一系统都逐一登录。这项功能通常是以轻型目录访问协议(LDAP)来实现,在服务器上会将用户信息存储到LDAP数据库中。相同的,单一注销(single sign-off)就是指

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

无人叉车3d激光slam多房间建图定位异常处理方案-墙体画线地图切分方案

墙体画线地图切分方案 针对问题:墙体两侧特征混淆误匹配,导致建图和定位偏差,表现为过门跳变、外月台走歪等 ·解决思路:预期的根治方案IGICP需要较长时间完成上线,先使用切分地图的工程化方案,即墙体两侧切分为不同地图,在某一侧只使用该侧地图进行定位 方案思路 切分原理:切分地图基于关键帧位置,而非点云。 理论基础:光照是直线的,一帧点云必定只能照射到墙的一侧,无法同时照到两侧实践考虑:关

【生成模型系列(初级)】嵌入(Embedding)方程——自然语言处理的数学灵魂【通俗理解】

【通俗理解】嵌入(Embedding)方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节:嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”,它将文本中的单词或短语转换成计算机能够理解的数学形式,即向量。 正如翻译机将一种语言

Thymeleaf:生成静态文件及异常处理java.lang.NoClassDefFoundError: ognl/PropertyAccessor

我们需要引入包: <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-thymeleaf</artifactId></dependency><dependency><groupId>org.springframework</groupId><artifactId>sp

kubelet组件的启动流程源码分析

概述 摘要: 本文将总结kubelet的作用以及原理,在有一定基础认识的前提下,通过阅读kubelet源码,对kubelet组件的启动流程进行分析。 正文 kubelet的作用 这里对kubelet的作用做一个简单总结。 节点管理 节点的注册 节点状态更新 容器管理(pod生命周期管理) 监听apiserver的容器事件 容器的创建、删除(CRI) 容器的网络的创建与删除

jenkins 插件执行shell命令时,提示“Command not found”处理方法

首先提示找不到“Command not found,可能我们第一反应是查看目标机器是否已支持该命令,不过如果相信能找到这里来的朋友估计遇到的跟我一样,其实目标机器是没有问题的通过一些远程工具执行shell命令是可以执行。奇怪的就是通过jenkinsSSH插件无法执行,经一番折腾各种搜索发现是jenkins没有加载/etc/profile导致。 【解决办法】: 需要在jenkins调用shell脚

火语言RPA流程组件介绍--浏览网页

🚩【组件功能】:浏览器打开指定网址或本地html文件 配置预览 配置说明 网址URL 支持T或# 默认FLOW输入项 输入需要打开的网址URL 超时时间 支持T或# 打开网页超时时间 执行后后等待时间(ms) 支持T或# 当前组件执行完成后继续等待的时间 UserAgent 支持T或# User Agent中文名为用户代理,简称 UA,它是一个特殊字符串头,使得服务器

明明的随机数处理问题分析与解决方案

明明的随机数处理问题分析与解决方案 引言问题描述解决方案数据结构设计具体步骤伪代码C语言实现详细解释读取输入去重操作排序操作输出结果复杂度分析 引言 明明生成了N个1到500之间的随机整数,我们需要对这些整数进行处理,删去重复的数字,然后进行排序并输出结果。本文将详细讲解如何通过算法、数据结构以及C语言来解决这个问题。我们将会使用数组和哈希表来实现去重操作,再利用排序算法对结果

8. 自然语言处理中的深度学习:从词向量到BERT

引言 深度学习在自然语言处理(NLP)领域的应用极大地推动了语言理解和生成技术的发展。通过从词向量到预训练模型(如BERT)的演进,NLP技术在机器翻译、情感分析、问答系统等任务中取得了显著成果。本篇博文将探讨深度学习在NLP中的核心技术,包括词向量、序列模型(如RNN、LSTM),以及BERT等预训练模型的崛起及其实际应用。 1. 词向量的生成与应用 词向量(Word Embedding)