事件反应流言被终结!

编者按:这是对最初于2019年4月发表的一篇文章的更新。

对于许多DevOps、站点可靠性工程(site reliability engineering, SRE)和运营团队来说，在潜在的问题演变成事故之前发现它们仍然需要花费大量的时间。团队通常都是被动地工作，处理突发事件，但却从来没有时间执行流程，以便在问题导致中断之前识别问题。

团队响应事件所花的每一分钟都将对他们的服务水平目标(SLOs)、公司声誉和团队的底线产生负面影响。

早在2014年，高德纳公司就估计每分钟停机时间的平均成本为5600美元;在2020年，对大型组织的影响在批判“真理的时刻”可能会很大。实际上，这种简单的统计数据强调了快速有效地响应影响您网站的可用性或表现的事件的重要性。

是什么让“事件？”

基本上，当服务不可用或没有按照定义的方式执行时(通常是通过正式的服务级别协议(SLA))，就会发生事件。事故可能由多种因素引起:网络中断、应用程序错误、硬件故障，以及在当今复杂和多层的基础设施中越来越多的配置错误。

事件响应指的是有助于检测，识别，故障排除和解决此类事件的集体进程。受IT基础设施图书馆的强烈影响（ITIL）到20世纪80年代，英国政府对事件的反应已经发展到包括许多框架和方法。然而，它们都有一个共同的目标:为涉众提供他们所需的工具，使行为不正常的系统尽快启动并重新运行，同时也使这些系统更加健壮和可靠。

但是，尽管历史悠久，事件应对仍然被掩盖在神话中，并被误解所束缚，这些误解阻碍了公司尽可能快速有效地解决事件——也许更重要的是，学习如何减少事件的发生。

这就是为什么我们询问了New Relic和业界的事件响应专家，以确定常见的事件响应误区和错误，并分享他们对最佳事件响应的最佳实践的见解。

流言1:速度就是一切

也称为“任何修复的是 - 一个良好修复”的神话。快速解决问题显然很重要，特别是对于直接触及客户的系统。但这不是唯一担心的事情。糟糕或不完整的修复或临时修复或在下游中断别的东西的修复可能是危险的，以便以速度的名义实施。

“很多口头上说的都是对事件响应的质量和客户满意度的需求，但当你看大量衡量事件响应成功的指标时，你会发现，它们实际上主要关注的是效率:问题解决的速度有多快。Christoph Goldenstern该公司负责创新和卓越服务的副总裁Kepner-Tregoe，专门从事事件响应的培训和咨询公司。

相反，企业应该专注于最终结果的有效性以及速度。“我们最终会长期推荐客户解决方案吗？”Goldenstern问道。“我们是否阻止了同样的事情再次发生？那些是要问的问题。“

他补充说，专注于“滞后指标”，即回顾过去衡量某件事是如何完成的，并不是非常有效。相反，他表示，企业应该专注于改善能够带来更好和更持久结果的行为，并围绕这些行为制定指标。

Kepner-Tregoe鼓励客户使用的一个度量标准是，获得手头问题的一个良好陈述所需的时间。Goldenstern说:“从我们的研究中我们知道，问题陈述的质量是降低解决问题时间和提高客户满意度的直接驱动因素。”“培训你的员工，让他们尽可能快地写出清晰、简洁、准确的问题陈述，这比简单地解决问题要好。”

误解2:一旦你扑灭了火，你就完了

幸运的是，这个神话正在慢慢被根除。如今，在解决一个事件后进行某种事后分析或内部回顾是相当标准的做法。关键是要主动地从事件中吸取教训，使您的系统更加健壮和稳定，并避免将来发生类似的事件。与此相关的短语是:主动学习。”

“激励预防措施是非常重要的，而不是仅仅在被动的模式下解决事件，”他说亚当Serediuk是，业务总监XMatters.该公司是DevOps事件管理工具的制造商。Serediuk说，如果你没有规定，在事后分析完成、调查结果被接受或拒绝之前，你的事件生命周期不会结束，“你实际上是在说，‘我们真的对防止未来的事件不感兴趣。’”他补充道，这两者是有区别的反应和回应。你可以反应比如，你可以向它扔一些摇滚明星，然后马上修复它。“但这一过程不能轻易重复，”他指出，“而且无法扩大规模。”

重要的是，要将事件响应视为端到端流程，其中响应测量，迭代，可重复和可扩展，同意Branimir Valentic是克罗地亚ITIL和ISO 20000的专家Advisera.com该公司是一家国际ITSM咨询公司。他说:“事件响应的重点不只是解决问题，而是要深入得多，从中学习。”

一个风险是，随着时间的推移，事后分析可能变成一种死记硬背的练习——只是一个让厌倦了的工程师检查的框框。不要让事后分析成为一项繁忙的工作。从事件中学习是非常有价值的，但也是具有挑战性的，需要你不断调整和适应，找出有效学习的方法。

误解3:只报告客户抱怨的主要问题，以免让事情看起来很糟糕

另一个普遍的神话认为，你不应该过于沟通你的事件。如果您报告每个事件，推理都可以看起来好像它失败了。最好让您的头脑保持下来并只承认并只沟通客户注意到并报告的严重事件。

无论如何，这是理论，但这是一个非常糟糕的想法。客户 - 内部利益相关者 - 希望觉得您是诚实和透明的，并且他们可以信任您检测和承认可能影响它们的事件。隐藏事件 - 甚至次要的事件 - 可以摧毁这种信任。

当事情发生故障时，您不应该将其视为对it组织不利的污点。发生意外只是比赛的一部分。关键是你怎么做。

主动与公司内部和客户沟通。许多公司对分享任何信息都很偏执，除非他们是被迫的，但这是错误的。是透明的。

Myth＃4：只有客户影响事件

一个相关的误区是，只有影响外部客户的事件才是相关的。事实上，一些组织甚至将事件单独定义为“影响客户的中断”。但是相信这个错误的想法会降低你对事件的整体反应效率。再次强调，事件反应应该是一种学习经验，你应该在学习的基础上采取主动的行动。

“我们可以从内部失误和内部事件中学到很多东西。它们甚至可能是你最好的学习经历之一，因为这是一个磨练你的反应过程、在没有压力的情况下学习的机会。”xMatters的Serediuk说。“当事情陷入困境时，很难灌输真正的组织变革。”

假设你的内部票务系统瘫痪了，或者你的内部wiki崩溃了。是什么样的监督或缺乏控制导致了这种情况的发生?Serediuk说，在像这样相对较小的内部情况下，“你可以在压力较小的情况下学习，或许还可以避免以后的生产事故。”压力越小，你可能就能更有目的性地集中注意力为什么你有一个特殊的问题，以及如何防止它再次出现。

误解5:当身体感到疼痛时，系统总是会提醒你

运营人员倾向于监控他们认为重要的东西。但他们并不总是对的。当这种情况发生时，系统可能会出现问题，而您的团队可能会幸灾乐祸地一无所知。过去，ops团队关注磁盘利用率、CPU利用率和网络吞吐量等指标。“但真正的问题是，服务健康吗?”Serediuk说。

这归结为宏观和微观监控之间的区别。在微监控中，您关注的是单个组件，如CPU、内存和磁盘。使用宏监视，您将看到更大的图景，即它如何影响系统用户。

“这就是服务水平目标(slo)和服务水平指标(slo)发挥作用的地方，”Serediuk说。“你要根据用户体验来判断事情。例如，如果您的每秒web请求突然减少到零，您就知道有问题了。如果您仅仅是在进行微监视，比如监视内存使用情况，那么您可能会错过它。“通过观察重要的指标——用户是否参与到我的系统中，”他说，“我发现了一些我之前可能没有注意到的东西。”

神话#6:你可以通过你的平均分辨率时间(MTTR)来判断你的IM进程的工作情况

MTTR就是它所说的:解决一个事件所需的平均时间。但是，如果把这个指标作为事件响应成功的晴雨表，问题就会很多。首先，并非所有事件都是一样的。简单、容易解决的事件不应该用与更复杂的事件相同的标准来判断。

“如何使用只有少数用户的应用程序进行比较，这是一个只有少数用户的应用程序，这可能遭受一个容易解决的事件，每隔一个月内容易于解决？”问兰迪·斯坦伯格他是IT亚博直播平台咨询公司的解决方案架构师并发性。“事件如此多样化，这不是你在做的好的晴雨表。”

此外，测量MTTR本身就是艺术，而不是科学。例如，时钟何时开始滴答？它是在应用程序开始放慢速度的时候吗？当你得到第一个警报时？当客户通知时？复杂系统的界限是如此流体，这是一致捕获的难度等。如果您的事件响应时间如此糟糕，MTTR可能很有用，即您试图将其降至可接受的数字;否则，它可能是非常误导的。

Myth＃7：我们在IM越来越好，因为我们正在更快地检测到问题

由于新的遗物等自动化监测和警报工具的效果和粒度增加，企业在检测到事件中的效果越来越好。但这并不意味着我们在事件的反应时越来越好。检测事件仅是等式的一半。解决这是另一半。

“有趣的是，如果你看整个过程，我们在总体上对事件的反应并没有变得更好，”声称文森特Geffray公司产品营销高级总监珠桥该公司是一家关键事件管理公司。为什么?因为我们在流程的第一阶段(更早地检测事件)获得的所有收获都在流程的第二阶段(包括寻找合适的人员来解决问题)中浪费了。他表示:“发现一个问题可能需要几分钟，而让合适的人坐到桌前开始制定解决方案可能需要一个小时。”

解决问题吗?人工智能和机器学习可以帮助评估与事件相关的历史数据，并根据之前的事件提出可能的应对措施。此外，花点时间研究事件响应过程中的步骤，着眼于提高它们的效率。这是尚未取得最大进展的领域。

“在现实生活中发生了什么，geffray说：”在新的遗物等工具已经确定了应用程序的工具之后，是在票务系统中创建的票证，然后您必须找到合适的人，让它们一起，并给他们所需的信息，以便他们开始调查。“在大多数情况下，它不会成为一个人。“研究表明，大多数IT事件需要至少五个人来解决，”他指出。“尽可能想象，关键任务应用程序的数量越高，越来越越来越多的组织，所需的时间就越多。”

误解8:“无可指责的文化”意味着对事件没有责任

这是消除IT行业的（绝大多数积极的）对无可指责文化的重要神话。

从好的方面来看，一种无可指责的文化消除了对事件反应方程式的恐惧:当人们知道他们不会因为犯一个错误而被解雇时，他们更有可能变得坦诚和透明。但这并不意味着不能问责制。你仍然应该找出犯了哪些错误，是谁犯的，以便从中吸取教训。

问责和指责之间有很大的区别。指责通常会误解复杂系统的本质，在这种情况下，一个特定的错误更有可能是一个触发事件，引发潜在失败的多米诺骨牌效应。一种无可指责的文化实际上能够实现真正的问责制，因为个人和团队感到足够安全，可以公开错误，这样组织就可以改善整个系统。

神话＃9：你需要一个专门的我的团队

虽然一些公司选择有一个独立的、专门的事件响应团队，但另一些公司更喜欢通过定期的IT工程工作轮换人员，实际上，有许多原因可以说明为什么您希望在整个IT组织中分发事件响应技能。

在DevOps方法中，任何工程师都应该能够以任何角色响应任何事件。对日常事件的反应应该分散到整个组织。

授权任何拥有必要信息的工程师在事故中做出艰难的决定是至关重要的。授权给那些做出回应的人，让他们能够做出艰难的决定，并知道他们可以尽自己最大的努力做出决定。

当然，所有这些都需要高强度的、深入的和持续的培训，以及可重复的、迭代的过程。您希望拥有最好的资源来处理最大的事件，这需要适当的组织和良好的流程。每一个随叫随到的工程师都应该受过足够的培训，有足够的经验来做好电话工作，而且他们也应该在电话出错时得到支持。

退房用AIOps加速事件响应了解更多关于New Relic应用智能如何帮助你改善你的事件反应过程和打破这些神话。