针对高速团队的事件管理
事件和问题管理角色不断变化
过去十年，事件管理发生了巨大变化。
ITIL 指南已经更新。IT 团队已开始与 DevOps 和 SecOps 分担责任。系统越来越复杂，导致事件管理解决方案也变得愈加复杂。许多公司陆续采用无指责事后分析和新的绩效衡量方法。
随着事件管理的不断变化和发展，问题管理（其近亲）以及两种实践之间的关系也在持续进步。
什么是问题？与事件有何不同？
根据 ITIL 的定义，问题是“一个或多个事件的原因或潜在原因”。
而事件是导致服务中断的单个计划外活动。
换而言之，事件是那些通常让待命员工仓促行动以求尽快彻底解决的烦人经历。而问题则是这些破坏性事件的根本原因。
一个问题可能导致单个事件，也可能造成多个事件。一个事件可以追溯到单个问题，有时也可追溯到多个问题。
例如，2016 年造成达美航空损失 1.5 亿美元的五小时服务中断是一个事件。导致该事件的问题是运营中心停电，而且（据推测）没有备份计划来应对这次停电。
同样，导致 Apple 损失约 2500 万美元的 12 小时 App Store 服务中断也是一个事件。其背后的问题是什么？一个 DNS 问题。
如果在科技界之外使用这些术语，那么着急去医生那里看偏头痛是一个事件。偏头痛的起因，即过敏、视力问题或疲劳等，就是问题。
问题管理与事件管理
显而易见，问题和事件有千丝万缕的联系。一者是另一者的起因，团队必须兼顾这两者。
对于传统的 IT 团队，最新版 ITIL 指南要求团队同时管理问题和事件，但要分开来做。问题管理是侧重于预防事件或减轻其影响的实践。事件管理的重点则是实时处理事件。
ITIL 方法的优点是，它优先考虑问题管理和事件管理的核心目标。据推测，这些指南通过将两种实践分隔开并赋予同等的重要性，来试图避免 IT 团队经常遇到的一个问题：不断去为事件灭火，却不处理这些火灾的根本原因。
如果事件经理的主要目标是快速解决事件，而问题经理的主要目标是预防，那么组合这两个角色可能意味着降低其中一个目标（两者对组织都至关重要）的优先级，而偏向于另一个目标。
这种方法的缺点在于，分隔这两种实践（实际上它们彼此紧密联系）可能会造成知识缺口，并导致事件解决与根本原因分析之间出现沟通断裂，从而造成问题的根本原因。
DevOps 以及问题和事件管理角色的变化
像往常一样，协作性 DevOps 运动模糊了传统 IT 思维的界限，即：问题管理和事件管理不再被视为两种截然不同的实践，而是一个总体视图中彼此重叠的两半。
促成这种转变不止是两种实践是同一事物的两面（预防和解决事件）这个事实，还有 DevOps 方法。DevOps 方法一般会证实以下几点：
- 一个事件通常有不止一个根本原因
- 事后分析应该是无指责的，所有受事件影响的团队都要参与其中
- 协作是持续改进的核心
问题管理和事件管理两者重叠也可能与整个行业向“谁构建，谁运行”方法转变有关。随着构建系统的团队负责解决这些系统中的事件，由同一团队负责进行事后分析、开展调查来找出事件的根本原因，并提出预防未来事件或减轻其影响的建议，也就合乎情理了。
衔接问题管理和事件管理的桥梁是无指责事后分析，一旦紧迫性降温，事件经理就会转向调查工作，并负担起问题管理和预防的任务。
模糊这两种实践之间界限的 DevOps 团队将面临一个关键挑战，确保问题管理（不太紧迫，但长期目标价值很高）不会因为事件管理的紧迫性而降低优先级。
但将事件管理与问题管理结合起来又谈何容易，我们的当务之急是找到并解决根本原因。了解事件管理解决方案——Jira Service Management 如何为团队提供协作的灵活性：记录背景信息、创建丰富的时间线，同时解决事件，由此帮助团队更好地管理问题。