早在2014年,Gartner估计在$ 5,600个停机时间的一分钟的平均成本。这个被广泛引用的数字加起来超过了每小时30万美元,而这只是平均水平;2019年,在关键的“真相时刻”,比如黑色星期五的电子商务网站或重大体育赛事期间的流媒体视频服务,对大型组织的影响可能会大得多。

这个范围内的数字强调了对任何影响站点可用性或性能的事件进行快速有效响应的重要性。

什么是“事件”?

基本上,事故发生在任何时间,服务不存在或已通过正式的服务水平协议(SLA)定义通常对道路不执行。事件可以通过多种因素引起:网络中断。应用程序错误。硬件故障。而且,越来越多,在当今复杂的,多层次的基础设施,配置错误。

事件管理(IM)指帮助检测、识别、故障排除和解决此类事件的集体流程。受到IT基础设施库(ITIL)的强烈影响在20世纪80年代英国政府的推动下,IM经过多年的发展,已经包括了许多框架和方法es。然而,他们都有一个共同的目标:为利益相关者提供他们所需要的工具,使行为不当的影响客户的系统尽快启动和运行起来,同时使这些系统更加健壮和可靠。

不过,尽管有很长的历史,IM仍然笼罩在神话和通过禁止公司为迅速而有效,因为他们可以,也许更重要的是,解决从学习如何减少事故的发生事故的误解步履蹒跚。

这就是为什么我们要求事故管理的专家在New Relic的,并围绕产业确定共同IM神话和错误,并分享最佳事件管理最佳实践自己的见解。

误解1:速度就是一切

也被称为“只要能解决就能解决”的神话。快速解决问题显然很重要,特别是对于直接接触客户的系统。但这并不是唯一需要担心的事情。以速度的名义实现一个坏的或不完整的修复,或者一个临时的修复,或者一个破坏下游其他东西的修复,可能是危险的。

来自Kepner-Tregoe的Christoph Goldenstern。

“很多口头上的承诺都是为了满足IM的质量和客户满意度,但当你看到许多衡量IM成功的指标时,它们实际上主要关注的是效率:问题解决的速度有多快,”他说Christoph Goldenstern创新和卓越服务副总裁Kepner-Tregoe,培训和咨询公司,专门从事IM。

相反,企业应该关注最终结果的有效性和速度。“我们最终会给客户提供长期的解决方案吗?””Goldenstern问道。“我们是否在防止同样的事情再次发生?”这些都是应该问的问题。”

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

Kepner-Tregoe鼓励客户使用的一个度量标准是对手头问题的一个好的陈述所花费的时间。戈登斯特恩说:“我们从研究中知道,问题陈述的质量是降低解决时间和提高客户满意度的直接原因。”“培训你的员工,让他们尽快写出清晰、简洁、准确的问题陈述,这比简单地解决问题更有帮助。”

不要错过:如何运行的对抗性比赛日

误解2:一旦你扑灭了大火,你就完蛋了

令人高兴的是,这个神话正在慢慢地被根除。如今,在解决事件后进行某种形式的事后分析或内部回顾是相当标准的。关键是要主动地从事件中学习,以使您的系统更加健壮和稳定,并避免将来发生类似的事件。这里的相关短语是,主动学习“。

来自xMatters的Adam Serediuk。

“鼓励采取预防措施,而不是仅仅以反应方式解决事件,这真的很重要,”他说亚当Serediuk的运营总监xMattersDevOps事故管理工具的制造商。如果你不要求你的事件生命周期在事后分析完成和它的发现被接受或拒绝之前结束,“你实际上是在说,‘我们对防止未来的事件真的不感兴趣,’”Serediuk说。他补充说,两者之间是有区别的反应回应。你可以反应比如,把你的一些摇滚明星扔到某个事件上,然后马上修复它。“但这个过程不能轻易重复,”他指出,“也不能扩大规模。”

重要的是要把IM看作是一个端到端的过程响应是可度量的、迭代的、可重复的和可伸缩的,同意吗Branimir Valentic克罗地亚ITIL和iso20000专家Advisera.com,一家国际ITSM咨询公司。他表示:“即时通讯的意义不仅在于解决问题,还在于更深层次地学习。”

一个风险是,随着时间的推移,事后分析可能变成一种死记硬背的练习——只是一个让疲惫不堪的工程师去检查的盒子。“在这种简单的模型中,事后分析变成了繁忙的工作,”他警告说贝丝长,高级软件工程师和技术产品经理New Relic的。从事件中学习是非常有价值的,但也充满挑战,她说,“需要你不断地调整和适应弄清楚如何有效地学习。”

不要错过:如何及为何举办“无可指责的回顾”

误解3:只报告客户抱怨的主要问题,避免让它看起来很糟糕

另一种流行的神话故事,说你不应该过于交际有关的事件。如果您报告每一个事件,推理去,它可以看起来好像它的失败。这是更好地保持你的头下来,并承认和交流只有严重事件客户已经注意到并报告。

无论如何,这只是理论上的,但这是个糟糕的想法。客户——以及内部利益相关者——希望感到您是诚实和透明的,并且他们可以信任您能够检测并承认可能影响他们的事件。隐瞒一些小事——即使是小事——也会破坏这种信任。

纽Relic的Beth Long。

Long说,当事情发生变化时,你不应该把它看作是你的it组织的污点。“你

运行复杂系统,”她说。”当然事情会变糟的。发生意外只是游戏的一部分。关键是你怎么做。”

“我在New Relic很喜欢的一点是,”Long补充道,“我们在内部和客户之间都积极主动地进行沟通,这就消除了‘哦不,除非是一笔大交易,否则你不能告诉任何人’的误解。”他说,很多公司对分享任何信息都很偏执,除非他们基本上是被迫的,但这是错误的。是透明的。”

不要错过:在呼叫和事故响应:教训成功后,New Relic的路

误解4:只有影响客户的事件才重要

一个相关的说法是,只有事件是影响外部客户是相关的。事实上,一些机构甚至定义事件仅作为“客户影响的破坏。”但相信神话会降低你的整体IM有效性。同样,这个想法是,IM应该是一个学习的经验和你应该采取基于这样的学习积极行动。

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

比如说你的内部售票系统坏了,或者你的内部wiki系统崩溃了。什么类型的监督或缺乏控制导致了这种情况的发生?在像这样相对较小的内部情况下,“你可以在更小的压力下学习,也许可以避免以后的生产事故,”Serediuk说。在较低的压力下,你可以更有目的性地集中注意力为什么您遇到了一个特殊的问题,以及如何防止它再次出现。

不要错过:推动运营意识有了事故数据

误区5:系统总是会提醒您,当他们在痛苦

运营人员倾向于监控他们认为重要的事情。但它们并不总是正确的。当这种情况发生时,系统可能陷入麻烦,而你的团队可能幸灾乐祸地一无所知。从历史上看,ops团队关注的是磁盘利用率、CPU使用率和网络吞吐量等指标。但真正的问题是,服务是否健康?”Serediuk说。

这可以归结为宏观和微观监测的区别。在微监视中,您关注的是单个组件,如CPU、内存和磁盘。通过宏监视,您可以看到更大的图景,即它如何影响系统用户。

“这就是服务级别目标(SLOs)和服务级别指示器(SLIs)发挥作用的地方,”Serediuk说。“你是根据用户体验来判断的。例如,如果您每秒的web请求量突然降为零,那么您就知道有问题了。如果您只是进行微监视,比如监视内存利用率,那么您可能会错过它。“通过观察重要的度量标准——用户是否在使用我的系统,”他指出,“我捕捉到了一些我可能没有注意到的东西。”

不要错过:六步战斗警报疲劳为现代复杂系统设置SLOs和sli的最佳实践

误解6:你可以通过你的平均分辨率(MTTR)来判断你的IM进程的工作情况

该MTTR正是它说:均值(平均)花费的时间来解决的事件。但问题盛产根据此指标作为晴雨表IM成功。对于初学者来说,所有的事件都是不一样的。操作简单,易于解决的事件不应该用相同的度量作为更复杂的判断。

兰迪·斯坦伯格,《并发》。

“企业范围内的电子邮件服务宕机,与只有少数用户的应用程序(可能每隔一个月就会出现一次容易解决的故障)相比,你会怎么做?””问兰迪·斯坦伯格他是IT亚博直播平台咨询公司的解决方案架构师并发性。“事件五花八门,不能很好地反映你做得有多好。”

此外,测量MTTR本身是一门艺术,而不是科学。例如,时钟何时开始滴答作响?当应用程序开始变慢的时候?你什么时候收到第一个警报?当客户注意到?“复杂系统的边界是如此多变,这是一个很难持续捕获的指标,”New Relic的Long指出。她补充说,如果你的即时通讯响应时间很短,以至于你想把它缩短到一个“正常”的数字,那么MTTR就很有用。“否则,它可能会非常具有误导性。”

不要错过:减少MTTR的方法正确

误解7:我们越来越擅长即时通讯,因为我们更快更早地发现问题

由于增加的疗效和自动监测和报警像New Relic的工具粒度,企业在检测的事件越来越远好于以前可能。但是,这并不意味着我们在事件管理渐入佳境。检测事件是只有一半的方程。解决这是另一半。

来自Everbridge的Vincent Geffray。

“有趣的是,如果你纵观整个过程,我们并没有变得更好的反应事件一般,”声称文森特Geffray公司产品营销高级总监Everbridge,一个关键的事件管理公司。为什么?因为所有的收益,我们在这个过程中,检测事件越早,在该过程的第二阶段,其中包括寻找合适的人解决问题浪费了第一阶段获得。“这可能需要几分钟的时间来检测问题,然后一小时只是为了得到合适的人表,开始找出一个解决方案,”他说。

补救的办法?花时间来研究在事件响应过程中的步骤,朝向使他们更高效的眼睛。这就是最大的收获还没有实现。

Geffray说,“在现实生活中发生的事情,”在一个工具像New Relic已经确定应用程序的问题,就是创建一个机票票务系统,然后你必须找到正确的人,让他们在一起,给他们他们需要的信息,这样他们就可以开始调查。“在大多数情况下,不会是一个人。他指出:“研究表明,大多数IT事件至少需要五个人来解决。”“你可以想象,关键任务应用程序的数量越多,组织规模越大,分布越广,需要的时间就越多。”

不要错过: F针对事件响应工作流的ive步骤,具有Jira软件和New Relic集成

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

考虑到IT行业朝着无可指责的文化的(压倒性的积极)运动,这是一个需要消除的重要神话。

从好的方面来说,一种无可指责的文化可以消除对即时通讯的恐惧:当人们知道自己不会因为犯错而被解雇时,他们更有可能坦诚和透明。但这并不意味着不问责制”,长说。“犯错误没有惩罚,并不意味着你不应该指出谁犯了哪些错误,从而从中吸取教训。”

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

不要错过:如何及为何举办“无可指责的回顾”

误解9:你需要一个专门的即时通讯团队

一些公司选择有一个独立的、专门的事件管理团队,而另一些公司更喜欢通过常规的IT工程工作来轮换人员,事实上,有很多原因可以解释为什么您希望在您的IT组织中分布IM技能。

“如果你看看DevOps方法,工程师在整个公司可以应对任何事件在任何角色,很强大,”说,他指出,尽管New Relic的New Relic的应急力量(削弱)准备介入事件指挥官安全性事件和“很困难,”日常事件,分布在整个组织的反应。

朗解释说,授权任何一个拥有必要信息的工程师在事故中做出艰难的决定是至关重要的。“你不能在事情如火如荼的时候坐等某人接电话。你需要赋予应对危机的人权力,让他们能够做出艰难的决定,并且要知道,只要他们具备了这样的能力,就去行动,打电话,尽自己最大的努力。”

当然,所有这些都需要密集的、深入的、持续的训练,以及可重复的、迭代的过程。你想要最好的资源在适当的地方解决最大的事件,这需要适当的组织和良好的过程。他是新Relic的工程副总裁马太福音的已经放样的位置,每一个工程师,谁是随叫随到应该有足够的训练和足够的经验,做好电话。“如果他们让这种情况发生横着走了一个电话,我们就会有自己的背,”烈焰红唇说。

不要错过:介绍新Relic应急部队

fredric@newrelic.com”

弗雷德里克·保罗(Freditor)是《新Relic》的主编。他是一位屡获殊荣的作家、编辑和内容策略家,曾在ReadWrite、AllBusiness.com、InformationWeek、CNET、Electronic Entertainment、PC World和PC|Computing担任高级编辑职位。他的文章发表在《麻省理工技术评论》、《Omni》、《康德纳斯旅行者》和《新闻周刊》等杂志上。查看贴子

以书面New Relic的博客人气?亚搏体育登入网给我们发个广告!