Close

更好的事件管理之路从这里开始

事件和问题管理角色不断变化

过去十年,事件管理发生了巨大变化。

ITIL 指南已经更新。IT 团队已开始与 DevOps 和 SecOps 分担责任。系统越来越复杂,导致事件管理解决方案也变得愈加复杂。许多公司陆续采用无指责事后分析新的绩效衡量方法

随着事件管理的不断变化和发展,问题管理(其近亲)以及两种实践之间的关系也在持续进步。

什么是问题?与事件有何不同?

根据 ITIL 的定义,问题是“一个或多个事件的原因或潜在原因”

事件是导致服务中断的单个计划外活动

换而言之,事件是那些通常让待命员工仓促行动以求尽快彻底解决的烦人经历。而问题则是这些破坏性事件的根本原因。

一个问题可能导致单个事件,也可能造成多个事件。一个事件可以追溯到单个问题,有时也可追溯到多个问题。

几个服务器机柜,其中之一翻倒并导致问题

例如,2016 年造成达美航空损失 1.5 亿美元的五小时服务中断是一个事件。导致该事件的问题是运营中心停电,而且(据推测)没有备份计划来应对这次停电。

同样,导致 Apple 损失约 2500 万美元的 12 小时 App Store 服务中断也是一个事件。其背后的问题是什么?一个 DNS 问题。

如果在科技界之外使用这些术语,那么着急去医生那里看偏头痛是一个事件。偏头痛的起因,即过敏、视力问题或疲劳等,就是问题

问题管理与事件管理

显而易见,问题和事件有千丝万缕的联系。一者是另一者的起因,团队必须兼顾这两者。

对于传统的 IT 团队,最新版 ITIL 指南要求团队同时管理问题和事件,但要分开来做。问题管理是侧重于预防事件或减轻其影响的实践。事件管理的重点则是实时处理事件。

ITIL 方法的优点是,它优先考虑问题管理和事件管理的核心目标。据推测,这些指南通过将两种实践分隔开并赋予同等的重要性,来试图避免 IT 团队经常遇到的一个问题:不断去为事件灭火,却不处理这些火灾的根本原因。

如果事件经理的主要目标是快速解决事件,而问题经理的主要目标是预防,那么组合这两个角色可能意味着降低其中一个目标(两者对组织都至关重要)的优先级,而偏向于另一个目标。

这种方法的缺点在于,分隔这两种实践(实际上它们彼此紧密联系)可能会造成知识缺口,并导致事件解决与根本原因分析之间出现沟通断裂,从而造成问题的根本原因。

DevOps 以及问题和事件管理角色的变化

像往常一样,协作性 DevOps 运动模糊了传统 IT 思维的界限,即:问题管理和事件管理不再被视为两种截然不同的实践,而是一个总体视图中彼此重叠的两半。

带有单独的问题和事件管理圆圈的 ITIL 示意图,以及带有问题和事件管理维恩图的 DevOps 示意图

促成这种转变不止是两种实践是同一事物的两面(预防解决事件)这个事实,还有 DevOps 方法。DevOps 方法一般会证实以下几点:

  • 一个事件通常有不止一个根本原因
  • 事后分析应该是无指责的,所有受事件影响的团队都要参与其中
  • 协作是持续改进的核心

问题管理和事件管理两者重叠也可能与整个行业向“谁构建,谁运行”方法转变有关。随着构建系统的团队负责解决这些系统中的事件,由同一团队负责进行事后分析、开展调查来找出事件的根本原因,并提出预防未来事件或减轻其影响的建议,也就合乎情理了。

衔接问题管理和事件管理的桥梁是无指责事后分析,一旦紧迫性降温,事件经理就会转向调查工作,并负担起问题管理和预防的任务。

模糊这两种实践之间界限的 DevOps 团队将面临一个关键挑战,确保问题管理(不太紧迫,但长期目标价值很高)不会因为事件管理的紧迫性而降低优先级。

但将事件管理与问题管理结合起来又谈何容易,我们的当务之急是找到并解决根本原因。了解事件管理解决方案——Jira Service Management 如何为团队提供协作的灵活性:记录背景信息、创建丰富的时间线,同时解决事件,由此帮助团队更好地管理问题。

后续内容
ChatOps