写点什么

一份处理宕机的应急响应入门指南

  • 2021-01-13
  • 本文字数:3070 字

    阅读完需:约 10 分钟

一份处理宕机的应急响应入门指南

本文最初发布于 byrayray.dev 网站,经原作者授权由 InfoQ 中文站翻译并分享。


在职业生涯中,我跟事故仿佛“结下不解之缘”。也许,这是命运使然,或者我喜欢看到事物是怎么出问题的。也许,罪魁祸首是我?不管出于何种原因,这种经历给我很大帮助,让我总结出一套应对事故的方法论。



从那时起,Matthieu 就时常鼓励我向更多人分享这些理念。于是我接受了他的建议,写下这篇文章。


如果你搜索过应急响应(Incident Response)这个概念,会发现有很多结果是关于应急角色(incident role)的。Atlassian 上有一些优秀的文档很好地解释了这些概念。


简单来说:


  • 应急角色可随着你响应团队的成长而帮助扩展应急规模。角色有助于分离职责,确保应急工作的各个方面都有专人值守。定义这些角色可以让每个人都清楚自己应该做的事情,以及对彼此应有的期望。

  • 有两个角色是你必须关注的:

  • 应急指挥官,是针对事故所采取措施的唯一联系人。他们不需要亲临一线采取行动,但是在重新启动服务器之前,请先与他们做好确认。这样就避免了某位好心办坏事的同事说出那句经典的“糟了,我不知道你正在将数据库还原到这个节点上”。

  • 联络角色。这个角色是必不可少的,也是缺少结构化应急响应流程时最容易被遗忘的角色。你当然不能重蹈覆辙,而是要尽早任命某人来管理联络事宜,并确保所有响应人都主动分担与他们的联络工作。永远不要要求人们同时做调试和联络工作,这样会分散他们的注意力,结果两件事情都会搞砸!

  • 文献中还定义了其他许多角色,但是只有当你的团队对每个角色的含义有深刻的了解时,这些角色才能派上用场。我认为,指挥官和联络人是至关重要的——在没有足够培训的前提下增加粒度会扰乱应急工作,并削弱你的响应能力。


如果你对想要使用的角色感到相当满意,并且你的团队在所有角色上都有良好的实践经验,那么你就迈出了高效响应的第一步。可是,现在有了各种角色,你的团队该如何解决问题呢?


第一,快速找到流血部位


首先,找出流血部位(what is bleeding)。如果你可以尽早确定应急响应的范围,就意味着你接下来的措施就更可能解决问题。


尝试:


  • 确定是哪些系统发生了故障,然后检查各个依赖项,判定问题是由上游组件还是下游组件引起的;

  • 一定要警惕假设。对于你从第三方获得的所有信息,一方面给予信任,另一方面请务必验证。记录你所做的验证工作,例如你运行的命令和运行的时间。错误的假设可能会让你的响应偏离正轨,因此请尽力避免它们。

  • 找到技术上的问题源头后,请考虑做一些影响分析。不要因为这部分工作而影响进度,但如果有人愿意,请让他们估计影响的范围——哪些人受影响,人数有多少。对影响的不正确理解可能会导致错误的决定,而清楚地了解受影响的对象可以帮助组织的其他部分(客户成功、客户支持等)做出适当的响应。


一旦团队理解了事故的性质,就可以开始止血(stop the bleeding)。换句话说,你的目标应该是尽快阻止当前的麻烦,并将清理工作推迟到压力更小的时间段再做。


第二,确定行动的优先级


为此,我们需要确定行动的优先次序,以尽可能取得最佳的成果。请注意“尽可能”这一短语:应该立即采取能够迅速实施的例行补救措施,就算你怀疑它只能解决部分问题也无所谓。


这些措施包括:


  • 回滚到一个确认没问题的版本,就算你觉得自己很快就能写好修复程序,也可以在回滚后压力较小的情况下再徐徐而图之。

  • 采取措施保护关键系统,就算牺牲其他一些不太关键的流程也可以。如果某个端点导致整个系统出现故障,请在这个端点恢复了关键服务后立刻 no-op 掉它。

  • 充分调动团队,并主动应用你认为风险较低的修补程序,就算你怀疑它可能无法解决全部问题也不怕:缩减不必要的队列、冻结部署、重新启动服务器。充分调动人力就可以快速做尝试,前提是其他响应者要继续分析问题的根源,同时假设简单的修补会无济于事。


这样你就应该大致了解自己的团队应该做什么事情了。现在的问题是,他们应该如何协作来执行这些任务呢?


第三,使用高效率工具、创建应急文档


鉴于沟通交流在应急响应工作中的重要性,你需要一款高效率工具来传递即时消息并记录操作日志。


可以使用 Slack(或其他有着相同功能的软件):


  • 在任何事故中,第一项操作就应该是创建一个消息频道。有很多工具(monzo/response、Netflix 的 Dispatch)可以为你自动创建它(还有很多其他东西),但就算你得自己手动完成这一步,也一定不能跳过它。为了准备好这个通道,多花费一分钟的停机时间也是值得的。

  • 我坚决反对私有应急响应频道。公司内部使用的公共通道可以提升信息访问的便捷性,从而加强你的响应能力。这样可以避免很多会让你头痛的协调(有一次,我见过两支彼此独立的应急团队在处理同一个事故,但他们之间根本不知道对方的存在……)

  • 每当你要执行破坏性操作(例如运行一条命令或重新启动某些资源)时,请向频道发送告知消息。这不仅可以让整个团队提高警觉性,而且为善后阶段编写事故日志提供了宝贵的记录。


即时消息非常适合用来传递带有时间戳且不应更改的信息。对于你希望随着应急工作的进展而调整的内容,请在你喜欢的协作编辑器中创建一个应急文档(Google 文档、Dropbox Paper、Notion 等):


  • 你的组织可以草拟一些包含所需结构的应急文档模板:也许你有报告职责,或者有特定的沟通流程?全都放在这里,这样只需点击一下即可从这些模板创建文档。

  • 特别是针对大规模事故的应急工作中,应急团队会有人员轮换,这时候这些文档可以充当人员进入应急团队的切入点。让管理通讯的人员来管理这些文档、维护一份重要事件的时间表,甚至在事故特别复杂时起草一份执行摘要。

  • 让你的技术团队将代码段或相关日志行贴到文档附录中,这样每个人都可以对齐同一份应急工作的中心视图。


聊天记录和应急文档结合在一起能成为强大的工具组合,可以帮助协调响应团队,同时为视察工作的投资者提供透明度。还有一点好处是,等到尘埃落定,可以很容易地将这些​​内容重塑成一份善后报告。


第四,注意人为因素


最后,也是最重要的是人为因素。人们在承受压力时会做出错误决定,而沉浸在应急工作中会让你完全忘记照顾自己。在这方面,你应该以身作则,并强硬地要求你的团队成员照顾好自己的身体状况。


这里要考虑的一些事情:


  • 减轻压力的一种有效方法是休息,远离屏幕,然后深呼吸。主动带领你的团队和你一起停下来,这样就会减少匆忙之间搞砸事情的潜在风险。

  • 一般来说,只要出现以下情况就暂停一下:

  • 有人呼你。不必太长;仅仅十秒的呼吸就能提醒你的身体一切尽在掌握,并降低肾上腺素水平。

  • 当生产故障停止时。警报平息并且情况看起来稳定后,请让整个团队休息一下。大多数事故都需要很多后续工作:在开始这些流程前,请让自己休息至少 15 分钟。

  • 跟踪过程中,在开始执行任何类型的流程之前,例如“X 群集的恢复”。让大家在开始做任务列表前先呼吸些新鲜空气,让每个人都能回点血,避免流程出错或超时。

  • 一定要对应急指挥官做好培训,让指挥官及时撤出精疲力尽的响应人员。一项重要的工作是在人们饥肠辘辘之前订好外卖。也许应急响应团队会大声抗议,说他们根本用不着吃饭,可是等外卖上桌了,你就会看到他们狼吞虎咽的样子了。


这份列表缺失的内容还有很多,但你可以把它当作一个入门包,也可以作为经验丰富的人员在制定应急响应流程中关键环节时的一个参考。


只要记住:深吸一口气、关照好同事、批判系统而非人员、不要着急。祝大家好运!


这篇文章中缺少对善后分析、事故发生前的准备工作,以及在安全性、数据完整性、可用性之间如何权衡的内容。如果你有兴趣听取我对这些观点的意见,请在 Twitter 上联系,我很高兴与你分享。


原文链接:


https://blog.lawrencejones.dev/incident-response/index.html

2021-01-13 11:312675
用户头像
王强 技术是文明进步的力量

发布了 885 篇内容, 共 507.1 次阅读, 收获喜欢 1787 次。

关注

评论

发布
暂无评论
发现更多内容

ImageKnife组件,让小白也能轻松搞定HarmonyOS图片开发

HarmonyOS开发者

HarmonyOS ArKUI 3.0

Tapdata Cloud 2.1.4 来啦:数据连接又上新,PolarDB MySQL、轻流开始接入,可自动标记不支持的字段类型

tapdata

SaaS 云数据库 Real Time DaaS polarDB DaaS

浅谈商业模式---《北大-真格创业课》笔记(30/100)

hackstoic

商业模式 创业公司

阿里云弹性计算对视觉计算的思考与实践

阿里云弹性计算

Metaverse 视觉计算

算法交易的最佳编程语言是什么?

非凸科技

rust 编程语言 交易系统 策略

博云首批通过欧拉技术测评,联合解决方案通过验证

BoCloud博云

新闻

全网最细的短网址系统设计与实战

星牛君

MySQL redis 布隆过滤器 Java EE

一文看懂博睿数据AIOps场景、算法和能力

博睿数据

新品发布 | OpenHarmony面向教育行业的发行版+大赛预告来了~

拓维信息

活动 操作系统 OpenHarmony OpenAtom OpenHarmony OpenHarmony 3.1 Release

基于云效AppStack实现环境管理 | 开箱即用

阿里云云效

阿里云 研发管理 研发 应用交付 环境管理

高级Java面试经验总结:多家大厂简历优化+面试题目+面经+薪酬等

Java架构追梦

Java 程序员 面试 后端开发

新思科技连续六年获评Gartner魔力象限领导者殊荣

InfoQ_434670063458

新思科技 应用安全 Gartner

PlatoFarm生态进展不断,通缩推动PLATO价值提升

小哈区块

【国产】ETL自动化调度运维管理平台 TASKCTL 8.0 分布式部署

敏捷调度TASKCTL

Docker DevOps 国产开源 大数据运维 TASKCTL

直播回顾:SIMD 指令集在 OpenJDK 中的现状与未来 | 龙蜥技术

OpenAnolis小助手

Java Openjdk simd arm 龙蜥社区

时序数据库 VS 工业实时数据库

CnosDB

IoT 时序数据库 开源社区 CnosDB infra

web前端培训Vue3 setup() 启动函数的原理

@零度

前端开发 Vue3

低代码之火,何以燎原?

BeeWorks

服务器与普通台式机的对比及发展趋势

Finovy Cloud

gpu 云服务器 GPU服务器 GPU算力

多商户商城系统如何对接电商收付通?

CRMEB

最佳实践 | 运维效率提升10倍的秘诀

星汉未来

DevOps 云原生 智能运维

观测云新增俄勒冈站点,布局全球可观测服务网络

观测云

PlatoFarm生态进展不断,通缩推动PLATO价值提升

西柚子

首版架构师全栈”成长笔记“一经发布就获得一致好评,我不允许你没看过

Java架构追梦

Java 程序员 java面试 后端开发

“数聚赋能”,让实时数据中台成为惠企、惠民政策服务应用的源头活水

tapdata

数据中台 数字政务 实时数据 智慧政务

不面试别看!字节跳动2022年Java架构师岗面试题(试行版)发布

Java架构追梦

Java 程序员 java面试 后端开发

「可视化案例Vol.3」数字孪生可视化园区,开启园区智慧管理新篇章

ThingJS数字孪生引擎

物联网 可视化 数字孪生

2022,「大厂云」还在找新着力点

ToB行业头条

看端点科技如何以行业实践探索企业数字化转型新路径

科技热闻

Android C++系列:vector最佳实践

轻口味

c++ android 4月月更

向着阳光的华为,淬火而行的哪吒

脑极体

一份处理宕机的应急响应入门指南_文化 & 方法_Lawrence Jones_InfoQ精选文章