什么是事件管理？

事件管理流程的类型

不同种类的公司往往采用不同类型的事件管理流程。没有哪一个流程对所有公司均适用，因此您可能会看到不同的公司采用不同的做法。

许多团队依赖较为传统的 IT 式事件管理流程，例如 ITIL 认证中概述的那些。其他团队则倾向于采用更具现场可靠性工程师 (SRE) 或 DevOps 风格的事件管理流程。

IT 事件管理流程

事件管理流程可帮助 IT 团队调查、记录和解决服务中断或停机问题。ITIL 事件管理工作流的宗旨是减少停机，最大限度减轻事件对员工工作效率的影响。通过采用专为管理事件而设计的模板，您可以创建可重复的事件管理工作流，为团队记录、诊断和解决事件以及保留活动档案提供保障。

ITIL 框架的用户主要是在企业内部运行服务的 IT 团队。通常，团队会从 ITIL 提取自己所需的，这几乎涵盖 IT 团队可能面临的所有类型的事件、事务和流程，并将其余部分留给别人。如果团队需要专注于培养主动排除故障的文化，ITIL 就非常适用。规定的流程可帮助团队以一致方式跟踪事件和行动，从而改进报告和分析，进而带来更健康的服务和更成功的团队。

IT 事件管理流程中的步骤

识别事件并进行记录

事件可能来自任何来源，如员工、客户、供应商和监控系统等。无论源自何处，前两步都很简单：有人发现事件，接着有人记录事件。这些事件日志（即工作单）通常包括：

• 事件报告人员的姓名
• 事件报告的日期和时间
• 事件描述（什么出现了问题或无法正常运行）
• 为便于跟踪而分配给事件的唯一标识号

分类

为每个事件分配一个直观的逻辑类别（并按需分配子类别）。这有助于您分析数据的趋势和模式，而这是有效管理问题和防止未来发生事件的关键组成部分。

确定优先级

必须确定每一事件的优先级。首先评估事件对业务的影响、将会受到影响的人数、所有适用的 SLA，以及事件对财务、安全和合规性的潜在影响。将此事件与所有其他未决事件进行比较，以确定其相对优先级。

响应

• 初步诊断：理想情况下，一线支持团队可以从诊断到结案监督整个事件，但若他们做不到，则下一步是记录所有相关信息并上报给上一级团队。
• 上报：上一级团队将获取记录的数据并继续进行诊断流程，如果该级团队无法诊断事件，则上报给更上一级团队。
• 沟通：团队要定期与受影响的内部和外部利益相关者分享最新动态。
• 调查和诊断：这个过程一直持续到确定事件的性质为止。有时，团队会引入外部资源或其他部门成员来咨询和协助解决问题。
• 解决方案和恢复：在此步骤中，团队得出诊断结论并执行必要的步骤以解决事件。恢复仅指完全还原操作可能需要的时间，因为即使在确定了正确的解决方案后，某些修复程序（例如错误补丁等）也可能需要测试和部署。
• 关闭：如果事件升级，它最终会被传回服务台并被关闭。为了保持质量并确保流程顺利进行，只允许服务台员工关闭事件，并且事件负责人应与报告事件的人员进行核实，以确认解决方案令人满意且实际已可关闭此事件。

事件、问题和变更：有何区别？

IT 团队通常会遇到不同类型的问题，这些问题要作相应分类，以便应用适当的管理技术。

• 服务请求 – 客户要求获得某一事物的正式请求，例如，配备一台新笔记本电脑。
• 事件 – IT 服务发生意外中断或质量降低，例如，网站停机。
• 问题 – 问题是造成事件的根本原因，例如，服务器配置不当。您想要将这些掌握在手，从而避免发生全面的事件。
• 变更 – 您所采取的行动，可以是标准的、常规的或紧急的。标准变更设有既定程序。常规变更通常是值得留意的，必须要经过审批流程。紧急变更是立即付诸实施的，理想情况下，在经过测试后大范围推行。

DevOps 和 SRE 事件管理流程

采用 DevOps 或 SRE 方法管理事件时，构建服务的团队也负责运行服务，并在服务中断时予以修复。随着永远在线云服务、全局访问 Web 应用、微服务和软件即服务的增长，这种方法迅速得到普及。

生活和工作所依赖的软件越来越多地托管在与您共处一地的服务器上。它可能是部署在数据中心内的 Web 应用，供全球数千或数百万用户使用。对于负责运行这些服务的团队而言，敏捷性和速度至关重要。而且，任何停机都有可能影响成千上万的组织，而不是仅仅一个。

“谁构建，谁运行”方法的优势在于，它可提供敏捷团队所需的灵活性；然而，它也可能让人不能清晰界定谁在何时负责什么。DevOps 团队对不太结构化的开发流程可能更加得心应手，也更易获得成功。但是，最好是对事件管理的一组核心流程进行标准化，这样在事件白热化时不会有如何应对的疑问，而且能够对问题进行跟踪，并报告具体如何解决。

DevOps 事件管理团队的三个信念

• 轮流待命：DevOps 团队通常不专门安排待命的团队成员，而是轮流执行待命计划，所有成员分担可能在夜间被唤醒应对事件的工作。
• 负责建造的工程师最适合承担修复工作：“谁构建，谁运行”理念的中心思想是，最熟悉服务的人（构建者）是最有能力修复服务中断的人。
• 快速构建，但实施问责：当工程师知道自己和队友会在停机期间陷入困境，就会有更大动力来确保部署高质量的代码。

这种方法可确保快速响应，更快向需要了解如何构建可靠服务的团队提供反馈。

我们在 Atlassian 事件手册中概述了一种非常适合 DevOps 的事件管理方法。

事件管理工具

事件管理不只是使用工具而已，而是要恰当地糅合不同的工具、方法和人员。下方列出了几种高效管理事件的最常见工具类别：

• 事件跟踪：每一事件都应予以跟踪和记录，以便识别趋势并随时进行比较。
• 聊天室：实时文字沟通是以团队形式诊断和解决事件的一个关键。它还能为日后响应分析提供一组丰富的数据。
• 视频聊天：对于许多事件，视频聊天可为文字聊天提供补充，而团队视频聊天有助于讨论调查结果并制定响应策略。
• 警报系统：诸如 Opsgenie 之类的工具可与您的监控系统集成，并管理待命轮换和上报。
• 文档工具：诸如 Confluence 之类的工具可以记录事件状态文档和事后分析。
• Statuspage：通过 Statuspage 与内部利益相关者和客户沟通状态，这有助于让每个人都参与其中。