【QCon】精华内容上线92%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

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

  • 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:311701
用户头像
王强 技术是文明进步的力量

发布了 785 篇内容, 共 373.5 次阅读, 收获喜欢 1709 次。

关注

评论

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

HIFIVE音加加 × 火山引擎:正版曲库+智能视频创作SDK,短视频全链路需求一站式解决!

HIFIVE音加加

短视频 火山引擎 HIFIVE音加加 视频配乐 版权音乐

教你用JavaScript实现乘法游戏

小院里的霍大侠

JavaScript 前端开发 编程实战 实战案例 初学者

OpenMLDB 社区月报 | 2022年10月

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

子查询优化之 Semi-join 优化 | StoneDB 研发分享 #2

StoneDB

MySQL HTAP 数据库· StoneDB 12 月 PK 榜

react源码分析:babel如何解析jsx

flyzz177

React

新变化新营销 这些知识点你得Get!(文末有PPT福利首次放送)

字节跳动数据平台

大数据 营销 12 月 PK 榜

黄东旭:开发者的“技术无感化”时代,从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022

PingCAP

TiDB

数字化改变了什么?WeLink在实践中给出答案

路过的憨憨

让对外合作更高效,就用WeLink跨企业沟通

路过的憨憨

Ansible最佳实践之 AWX 启用facts缓存和模板问卷调查

山河已无恙

12月月更

互联网医疗领域月度观察——数字乡村建设加快,“互联网+医疗健康”带动乡村高质量发展

易观分析

数字化 互联网医疗

演讲实录 | OpenMLDB 整合自动特征工程

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

关于 Git 重写历史的一些笔记

山河已无恙

12月月更

react源码中的生命周期和事件系统

flyzz177

React

OpenMLDB Meetup No.7 回顾 | OpenMLDB+AutoX:整合自动特征工程,拥抱高效机器学习

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

专访 | 罗成:开源并非“只可远观”

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

Ansible最佳实践之 AWX 作业创建和启动

山河已无恙

12月月更

镕铭微电子加入龙蜥社区,推动开源 OS 在音视频产业的应用

OpenAnolis小助手

操作系统 芯片 数据存储 龙蜥社区 镕铭微电子

教育部公布2022年第一批产学合作协同育人项目,千锋教育57个项目成功立项

千锋IT教育

专访 | 徐鹏程:开源,就是酷

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

OpenMLDB 实时引擎性能测试报告

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

如何快速构建研发效能度量的指标体系?

Kyligence

数据分析 指标

Ansible最佳实践之Playbook高级循环任务如何操作

山河已无恙

12月月更

react源码中的协调与调度

flyzz177

React

创业者说丨云起无垠沈凯文:构建新一代开发安全基础设施 让Fuzzing技术为企业赋能

云起无垠

安全开发 开发安全 Fuzzing技术防护

初识华为云数据库GaussDB(for Cassandra

路过的憨憨

华为云数据库GaussDB(for Influx)揭秘:数据分级存储

路过的憨憨

Ansible之Ansible Tower使用User和Team管理访问权限的笔记

山河已无恙

12月月更

OpenMLDB v0.6 新版本运维功能增强

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

【Meetup 预告】OpenMLDB + MaxCompute:集成打通云上生态,高效构建 AI 应用

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

ChaosBlade Java 场景性能优化,那些你不知道的事

阿里巴巴中间件

阿里云 云原生 ChaosBlade

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