在IT服务管理中，事件和问题并不是相互独立的。它们是同一个问题的不同层面--同一个硬币的两面。事件是问题对正常业务运营的直接影响。事件管理者面临的挑战是了解问题，采取行动减轻任何影响并尽快恢复服务。
问题是指问题的长期影响以及问题对维持正常的、未来的商业活动所带来的风险。问题管理者面临的挑战是调查问题的根本原因、相关的依赖关系和可能导致问题再次发生的环境因素。这种调查还能帮助他们确定，如果不解决根本原因，与问题相关的风险（影响和可能性）有多大，以及采取某种纠正措施（长期修复）与简单承认和接受风险的适当性。
为什么事件和问题管理在大多数组织中是分开的
如果事件和问题管理都是为了解决性能问题，那么为什么它们在标准的ITSM范式中是独立的功能？答案就在于这两种功能的优先级被认为是冲突的。事件管理的重点是眼前的影响，而不是未来可能发生的情况。你的公司需要事件管理者保持这种关注，以防止长期的业务中断和故障，从而对生产力或声誉造成重大损害。
问题管理，在大多数情况下，需要时间来彻底和正确地做，假设我们正在处理一个实际的原因不明的问题。你不希望问题管理者匆忙下结论而错过一个关键细节。
在事件和问题管理之间共享数据
尽管事件管理和问题管理在许多IT组织中是独立的职能，但他们必须分享信息和见解，以创建一个端到端的信息流。当问题发生时，事件管理者就在第一线。他们看到表现不佳的系统或应用程序正在发生什么。他们看到问题对业务的影响。当事件发生时，他们还能看到环境中的其他事件。这最后一点特别重要。一个变化、一个行动或其他一些与服务组件或依赖关系有关的事件会导致大多数事件（和问题）。
一旦服务恢复，这些因素往往很难（如果不是不可能）被识别。因此，事件管理者是问题管理功能的 "眼睛和耳朵"--收集有助于根本原因分析和问题诊断的宝贵信息。我们不应该把事件管理和问题管理看成是两种功能，而应该把它们看成是一个连续体。另外，如果认为事件管理者（尤其是重大事件管理者）不需要启动，有时甚至需要领导某种形式的根本原因分析，当现有的修复方案无效或者在不知道原因的情况下进行的风险太大，那是一种谬论。在实时事件中把这项任务交给问题管理部门，可能会延长中断时间，导致很多 "乒乓 "行为。
另一方面，问题经理是 "已知问题清单 "的维护者，事件经理依靠该清单来诊断问题并迅速确定潜在的短期修复措施。即使在问题经理确定了问题的根本原因和长期修复的步骤之后，也往往需要相当长的时间来实施纠正措施并完全解决该问题。在这期间，公司面临着问题复发和造成进一步业务中断的风险。问题管理者必须向事件管理者提供明确的指示，告诉他们在遇到问题复发时应该怎么做，以避免再次出现业务中断。如果在问题复发期间需要额外的数据收集，那么事件管理者也必须知道这一点，这样他们就可以在实施纠正措施之前收集所需的数据，因为纠正措施有可能破坏或歪曲问题管理所需的线索。
事件和问题管理者作为一个团队一起工作
实现高水平服务的公司知道事件和问题管理者，必须作为一个团队合作，作为端到端支持流程的一部分，以实现最大限度地减少业务中断及其影响的共同目标。
