IT 事件管理、响应和预防的未来

倒退五年，询问负责事件管理的 IT 团队。得到的答案几乎都会是“我们”。

现在问同样的问题，您可能不仅会听到 IT，还会听到 DevOps、SecOps 和架构团队。许多组织正在慢慢转向“谁构建，谁运行”的概念。

这种方法的明显好处是，它通过将责任转移到最熟悉代码的员工身上，减轻了 IT 团队的压力并加快了响应时间。这样可以最大限度地减少停机时间并提高团队工作效率。它还激励优秀的代码。（如果您曾在凌晨 3 点被吵醒来解决错误，那么下次代码上线时，您很可能会再三检查代码，以保持凌晨 3 点不会再被电话吵醒。）

这种方法的挑战是组织仍然需要一定的集中化。领导层需要查阅报告和文档。业务利益相关者需要掌握最新消息。他们希望查看事件指标，如平均解决时间和平均确认时间。他们希望事件更新、事件事后分析报告和补救工作全都一目了然。

对于许多正在转向去中心化并且表现尚可的公司来说，应对这一挑战的答案是运用促进去中心化和团队自主的技术，以保持事件解决的灵活性，同时仍然将信息集中到一处以使业务部门掌握最新动态。

与任何其他可能扰乱工作流程并产生不可预见的后果的重大变化一样，许多组织正在初步采取去中心化措施是有道理的。

他们首先要确定一个在文化上适合此类变革的团队，该团队正在管理低风险应用或产品。然后，他们将该团队特定应用或产品的事件管理移交给该团队。他们对该团队进行培训，实施待命时间表，并跟踪他们在一段时间内的进度，然后提出以下问题：

• 他们是否缩短了恢复时间？
• 他们遇到了哪些文化障碍？
• IT 团队需要安装哪些工具？
• 他们需要什么流程来沟通？
• 该团队会提供更好的系统更新吗？
• 事件数量下降了吗？
• 如果我们决定将这种去中心化推广到其他团队，那么我们可以从最初的测试中得到什么？

这些测试用例为决定是否在整个公司实施“谁构建，谁支持”框架奠定了基础，如果是的话，如何有效地在团队中推广该框架。

这种去中心化的举措还需要转向跨团队协作。如果 DevOps 参与事件管理，则 DevOps 需要在 IT 事件管理流程会议上占有一席之地。如果 IT 部门仍在帮助指导事件管理实践，他们需要参与其他团队的事后分析审查。

每个团队都将自己的优势带到事件管理上。IT 团队擅长制定实践和文档并遵循指导方针。DevOps 团队擅长变更和学习。SecOps 可以提供安全性。

为了促进团队之间的更多协作，做得好的公司公开共享信息，培养团队之间的同理心，摆脱跨团队的责备，在事件发生时通过聊天来保持团队的联系，并优先考虑每个人都能参与事件审查。

在 ITIL 指导方针中，通常将事件管理视为与事件预防不同的实践。两者都是 ITSM 难题的重要组成部分，但它们并不经常同时发生。

这种方法的问题在于它使事件管理处于被动状态。待命员工的任务是解决问题，一旦问题解决，他们就会转向下一个问题。他们的唯一目标是恢复——让系统恢复正常运行。

但只有恢复还不够。随着时间的推移，越来越多的 IT 团队开始意识到并接受这一点，将预防纳入事件管理流程，并使用平均解决时间（而不是平均恢复时间）等指标来判断绩效。

这种方法通常被称为问题管理，其目标是使流程更紧密地联系在一起，以确保团队不仅是解决完一个问题后立即转向下一个问题，而且还要做出响应、恢复并从事件中吸取经验教训，将这些经验教训应用于他们目前管理的以及更大的产品和服务系统。

许多企业 IT 组织将有专门的问题管理实践。他们通常将其视为单独团队的单独流程。在 Atlassian，我们主张更进一步，使用混合方法，让 IT 运营和开发人员团队将问题管理实践纳入自己的事件实践。这样可以更好地了解整个事件，并确保不会在事件发生后很长时间才进行事件分析。

因为，从长远来看，预防事件比快速响应事件更有价值。

这种在事件管理方面向跨团队协作的转变固有的挑战之一是，部分团队在流程和文档方面比其他团队更为宽松。

这是 IT 部门可以提供监督和显著价值的地方之一，即使其他团队负责管理自己的产品也是如此。因为没人愿意在凌晨 3 点处理重大事件，而且还没有一个可靠的计划。

在将团队纳入事件管理流程时，IT 部门可以帮助他们回答决定该计划的核心问题。例如：

• 您的事件响应是什么？
• 您要遵循的价值观是什么？
• 如果发生事件，您会如何响应？
• 您所支持的关键系统所需的信息在哪里？如果存在于多个系统中，如何将这些信息整合在一起，以便待命专家可以轻松访问这些信息？
• 您的流程和文档是否可以协作并由团队审核？

这种向去中心化、协作以及事件和问题管理相结合的转变，所需要的不仅仅是重新分配职责和安排 IT 专业人员参加 DevOps 事后分析。这里成功的关键不在于技术，甚至不在于流程。而在于打造一种支持这些变更的内部文化。

这是太多公司试图跳过的部分，也是成功过渡的基础。那么，支持去中心化、协作、面向未来事件管理的文化是什么样子的呢？

在 Atlassian，我们认为核心组件包括：