ITPub博客

首页 > 自动化运维 > DevOps > 行业洞察系列之《事件管理的 5 个阶段及其改进建议》

行业洞察系列之《事件管理的 5 个阶段及其改进建议》

原创 DevOps 作者:ruixiangyun 时间:2021-07-15 16:11:29 1 删除 编辑

006XMqchly1gshn6y9o7yj30gy0990th.jpg

高效的事件管理应该是所有企业业务系统的重要组成部分。为什么这么说?因为随着IT技术、工具和工作流程的日益复杂,以及彼此关联性的日益增加,业务系统越来越容易受到计划外停机的影响。停机可能在任何时候发生在任何系统上,对内部和外部业务运营都会造成潜在影响。停机事故的成本通常以每分钟数万(甚至数十万)美元计算。

由于会面临这样的潜在影响,企业正在加速优化事件响应流程,以确保事件能够得到最快最有效的管理。这意味着企业需要采取一种全面的事件应对方法,了解事件如何发展,如何不断提高系统弹性。从学术角度来看,一个典型的事件响应工作流程涉及多少阶段,就这个问题有不止一种观点。

虽然不同机构对此可能观点不一,但我们将重点关注以下五个阶段,以此代表事件的生命周期。

1. 准备阶段

2. 检测和告警阶段

3. 遏制阶段

4. 修复阶段

5. 分析阶段

忽视其中任何一个阶段,机构将会面临事件管理失败的风险,由此会导致不必要的延误及相关成本的产生。下面,我们会分别介绍每个阶段,并在实践方面提供建议,帮助团队更有效地管理事件。

006XMqchly1gshndgn2yhj30na0ejq5u.jpg

(一)准备阶段

 

即使是最有经验的IT专业人士也会说,准备阶段是事件管理中必不可少的部分,但准备工作却常常被忽视。在这一阶段,团队会探讨多种“假设”场景,然后定义应对这些场景的流程。

领先的机构对准备阶段非常重视,他们采取运动员进行运动训练的方式进行准备工作。目的是建立针对事件响应的肌肉记忆,以便更快做出反应。

“事件响应方法论一般都会强调准备工作的重要性——不仅要培养事件响应能力,帮助机构做好响应事件的准备,还要通过确保系统、网络和应用程序足够安全,预防事件发生。”

美国国家标准与技术研究院(National Institute of Standards and Technology, NIST)

改进 建议

 

•  时刻准备好应急包

事件响应者的“应急包”是一个关键信息存储库,团队利用应急包在最短的时间内做出响应。把这些材料集中到一处,团队获取信息就变得轻而易举,无需再去费时搜寻。根据机构的团队和系统结构,应急包中可能包括各种各样的东西:

• 事件响应计划

• 联系人列表

• 待命值班表

• 上报政策

• 会议工具链接

• 访问代码

• 政策文件

• 技术文件和运行手册


•  不要排斥运行手册

运行手册为团队成员提供重要指导,告诉他们在特定场景中应该采取什么措施。这对于采取轮班制和/或系统专员有可能无法即时响应的团队来说尤为重要。如果没有运行手册在手,不熟悉系统的响应者只能重复花费时间来确定需要采取哪些措施开启修复工作。一套维护良好的运行手册不仅使团队响应更快,同时还构建了一个集体知识库,有助于事件响应实践的持续改进。

•  接纳混乱,提高稳定性

“混沌工程”(Chaos Engineering)作为一个术语看起来像是一种矛盾说法。其实不然。这是一种通过故意导入故障来对系统进行实验的做法,目的是了解如何能够更稳健地构建系统。混世魔猴(Chaos Monkey,也可译作“捣乱猴子”)就是一个例子。混世魔猴最初是由网飞(Netflix)开发的一款测试工具,通过故意使制作系统脱机来测试网络弹性。虽然看似危险,但这种做法实际上可以帮助工程师不断对系统进行测试,确保系统的恢复力。最终,混世魔猴帮助网飞的团队建立了一种以系统弹性为核心的文化。由于大获成功,许多其他机构也纷纷效仿这种做法。

006XMqchly1gshner12uxj30lc0bn3zv.jpg

(二)检测和 告警 阶段

 

事件检测的重点不仅是要对事件的发生了如指掌,还要知道如何将情况通知给团队。虽然两个过程看起来不同,但事实上两者关系密切。挑战在于,虽然可用的IT监控工具增多了,团队检测异常和事件管理的能力也大大提高了,但监控工具也会造成“告警风暴”或误报,使响应过程变得复杂。

顶级IT团队会在监控过程上增加一层,确保告警得到妥当管理。这一层的作用是集中控制告警过程,同时提高告警处理的智能化水平。

“检测的目的是做出准确的响应……。这项工作主要要求明确识别和沟通角色、责任以及事件处理的初始方法。其中应包括确定由谁来识别事件并确定其严重性,以此作为在机构环境中有效处理事件的一种手段。”

马耳他信息技术局(Malta Information Technology Agency,MITA)

改进建议

•  跳出网络运维中心(N OC 思考

过去,网络运维中心(NOC)充当了大型IT系统的监控和告警中心。网络运维中心的工程师一般会负责对系统出现的事件进行分类和上报,这是一项挑战。事件管理工具可以显著改进这一过程。基于定义好的告警类型、团队值班表和上报政策,将告警交付工作流程自动化,可以避免可能的人为错误和/或延误。

•  合流 ,而 非增流

没有什么比受到来自多个监控工具告警的持续性狂轰乱炸更糟糕的事了。利用单个工具将告警流集中,这样团队能够更好地滤出干扰因素,迅速把注意力放在需要关注的事项上。

 

•  知识=力量

基础类型的告警会传达出错信息,但不总是告知出了什么问题。这样会导致不必要的延误,因为团队必须调查并确定造成问题的原因。将告警与触发原因的技术细节结合起来,可以使修复过程更快开始。

 

•  谁在守卫卫兵?

拉丁语中的这句话——“谁在守卫卫兵?”,指出了所有IT团队面临的一个普遍问题。因为他们使用的监控工具与这些工具要保护的系统一样,同样容易受到事件和停机的影响。如果没有办法确保监控工具的正常运行,系统很容易在不发送通知的情况下停机。全方位的告警流程确保系统和监测系统的工具都能得到持续的健康体检。

(三) 遏制 阶段

 

IT事件的分流过程类似于医疗领域中的分诊过程。第一步是确定事件的严重程度。接下来,需要遏制事件发展,防止情况恶化。在这一阶段采取的所有行动都应集中全力限制和防止任何进一步的损害发生。

 

“短期遏制不是为了长期解决问题,只是为了在事件恶化前限制事件的发展。”

理查德·贝特里奇,布鲁金斯学会


改进建议

 

•  止血

分诊医生知道,如果所有情况一出现就试图全部解决,则会深陷泥潭,这样有可能造成更大的伤害。他们的重点是采取短期行动,使病人状况足够稳定,再将他们转移至更紧急的护理。在技术领域,遏制行动的重点在于临时解决方案(隔离网络、回归构建、重启服务器等),这些解决方案至少可以限制事件的范围,或者更理想的是使系统重新上线。如果事件管理仅注重修复,不注重遏制,那么在找到永久性解决方案前,可能会使中断不必要地延长。

 

•  不要孤军奋战

IT团队中的英雄文化已经没落。单枪匹马的工程师挑灯夜战、周末无休地工作,就因为他们是唯一能使系统死灰复燃的人,这种情况已不再流行。

相反,团队就应以团队的方式工作。他们协作处理问题,因为他们知道知识共享可以使事件得到更快的解决。因此,电话会议、即时通讯工具和实时视频成为事件管理工具箱的基本要件。这些都能迅速将团队聚集在一起,使他们能够实时协作。即时通讯工具与事件管理工具的集成对于团队也很常见,这样事件就可以在单个平台上被触发、确认和解决。


•  要透明

数字时代使人们随时都能获得海量信息。在IT系统故障期间,这可能是一个优势,也可能是一个劣势。如果用户遭遇服务中断,故障通常会在短时间内传播开。为了在这方面保持领先,团队应该有一个事先准备好的事件沟通计划。目的是公开告知客户正在发生服务中断,以此跟客户建立信任,并向他们确认正在采取措施解决问题。像Twitter、StatusPage和用户论坛这样的工具是分享这一信息的好地方。重要的是,应该把该流程继续纳入到修复和分析阶段,进一步增加用户的信任,否则他们可能会放弃使用您的业务。

006XMqchly1gshnh478guj30kc0c6dhb.jpg

(四)修复阶段

 

与遏制密切相关的是修复。这一阶段是实施长期解决方案的地方,确保事件得到彻底和有效的解决。在遏制阶段,目标可能是使系统重新联机,而在修复阶段,目标转变为了解导致问题的原因以及如何纠正问题以防止未来发生类似事件。

 

“在全面恢复系统之前,应进行修复工作,确定问题根源。恢复的最后阶段不仅仅是将系统恢复到原来的状态,还要使系统变得更好、更安全。系统应该具有跟原先一样的操作能力,但也应能抵御最初导致事件的因素。”

                                                                                                                                    美国国土安全部


改进建议

 

•  Cynefin

决策制定框架Cynefin(发音为KUN-iv-en)提供了一种结构化的方式来处理问题,帮助事件响应者根据问题本身的性质决定最佳行动方案。根据事件的类型(简单、复杂、繁复、混乱),可以定义一个解决它的方法。

• 事故是否有已知的原因和解决方案?

• 是否需要让更多人参与帮助解决事件?

• 是否有时间调查问题以确定最佳响应,还是情况要求立即采取行动?

 

•  自动化程度高吗?

聊天工具事实上已经成为企业改善沟通和协作的工具。然而,聊天工具的发展也远远超出了仅让团队发送消息的功能。GitHub的软件开发团队在发布开源工具Hubot时引领了聊天工具的发展。Hubot允许用户直接从聊天环境触发行动和脚本。这允许团队通过创建自动化流程操作(启动服务器重启、部署代码片段等)程序来简化操作。

006XMqchly1gshni0zaazj30in0ab75a.jpg

(五)分析阶段

 

尘埃落定,系统恢复后,事件管理工作流程并未结束。这时候会开启事件管理生命周期中最重要的阶段之一——分析阶段。“事后”分析的目的是了解清楚事件发生的系统性原因以及所采取的应对措施。

从这里开始,领导团队的工作是从系统及为维护系统而定义的流程中寻找并确定改进的方案。通过评估这些信息,团队可以开发支持更高系统弹性和更快事件响应的新的工作流程。

 

“(事后分析)应以报告的形式撰写,详细回顾整个事件;这份报告应该能够回答在经验教训会上可能提出的“谁”、 “什么”、“哪儿”、“为什么”和“如何”等问题。 总体目标是从机构内部发生的事件中学习,改进团队的表现,并在发生类似事件时提供参考资料。”

      美国系统网络安全协会(SANS Institute)

改进建议

 

•  从失败中学习

绝大多数情况下,IT团队会说,他们只花时间回顾“重大中断”状况。虽然这是一个良好的开端,但这也往往忽略了可能会产生长久影响的小事件。可能并非所有事件都需要详细的事后报告,但对细节的简要回顾还是需要的。这样一来,对情况的认识有助于团体知识的提高和持续改进。

 

•  没有根本原因!

或者有?在分析一个事件时,很少有人能说出一个可以确定的“根本”原因。根据Cynefin模型,原因及必要的响应已知并可以重复的事件属于“简单”事件类型。但出现这类事件的情况极少。通常情况下,由于系统过于复杂且相互依赖,无法定义事件的单一根源。即便根本原因看似很明显(比如导致应用程序崩溃的输入错误),通常也有理由去了解哪些外部因素可能导致应用程序崩溃(或没有及时阻止程序崩溃)。

 

•  不要指责

每次事后分析的目地都应该是了解出了什么问题以及可以采取哪些措施来避免将来发生类似事件。 重要的是,这个过程不应该用来问责。 这是因为在乎“谁”而非“什么”的团队会使情绪妨碍到对事实真相的分析。

006XMqchly1gshnilxuffj30gm09b74n.jpg

总结

 

在现代IT环境中,唯一不变的是变化本身。这意味着系统将不断受到新的和不同的方式的压力。了解这一点的团队也明白,这不是系统是否会失灵的问题,而是何时会失灵的问题。采取措施为系统失灵做好准备应被视为持续成功的关键因素,并且应被嵌入工程团队的DNA。

本文译自Atlassian的“5 stages of incident management and how to improve them”


关于 睿象云

 

睿象云是一家全球领先的智能运维平台厂商,创始团队始终秉承 “让开发运维工作变得更加高效” 的使命,专注于为企业提供更加智能、全面的跨云监控和事件管理平台。

睿象云团队致力于运用便捷的集成方式,精准的智能算法,及完善的分派响应机制,为企业搭建灵活、统一的运维管理平台,实现云环境下所有 IT 指标和事件信息的汇聚、处理、分派以及智能分析。从而帮助业务运维团队更加快速的掌握业务健康状况,甄别运维问题,判定故障根因,建立知识图谱,最终全面提升企业的IT运维能力,降低运营成本和风险,创造更加优质的用户体验。

Cloud Alert是国内首个SaaS智能告警管理平台,能够帮助您快速接入监控工具的告警,集中到同一个平台统一管理,自动去重降噪,帮助运维从海量告警中识别重要告警,聚焦处理核心问题,更快解决告警,让业务更可靠。

想了解更多? 访问 aiops.com 即刻申请 21 天免费试用版,了解睿象云如何帮助您改进事件管理流程。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69948837/viewspace-2781509/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
睿象云始终秉承“让运维更加轻松高效”的经营理念,不断探索运维管理的奥秘,为企业发展提供源源不断的动力。

注册时间:2019-09-19

  • 博文量
    38
  • 访问量
    19642