针对高速团队的事件管理
像 IT 运营专家一样完成事件管理流程
作者：Atlassian 服务运营经理 Nick Wright
首先，我想说：一线支持人员是每个企业的无名英雄。
每个企业
我坚信技术支持应该被视为服务行业，客户应该能够给提供优质服务的支持人员额外奖励。如果可以的话，我很乐意微笑着为每一位快速解决我的问题的王牌支持人员提供额外奖励。
我离题了，正在阅读这篇文章的您，可能是负责管理或服务于帮助台团队。您可能现在也是感觉焦头烂额。真的很紧急，感觉非常糟糕。因此，我们采取一些措施来控制您的 IT 事件管理流程。
在深入探讨事件管理之前，让我们先对一些常用术语达成一致。
ITSM 和事件管理
如果您在 IT 部门工作，您可能熟悉 ITIL、ITSM、事件和问题。但为了让所有人都保持同步，以下提供了一些 Atlassian 的简略定义：
ITIL（IT 基础架构库）是 ITSM 的一套最佳实践（可以将其视为小技巧）。
ITSM（IT 服务管理）是一种创建、支持和管理 IT 服务的常用方法。ITSM 的核心理念便是相信 IT 应该作为服务进行交付。事件管理是 ITSM 的其中一种核心实践。
事件是指任何中断或降低服务质量（或具有此类威胁）的计划外事件。业务应用出现故障是一个事件。运行缓慢但尚未死机的 Web 服务器也是事件。它运行缓慢，并影响工作效率。更糟糕的是，它会导致更大的风险，即彻底瘫痪。
问题是背后根本原因尚不清楚的一个或多个事件。上述事件提到了网络迟缓以及业务应用宕机，此时，路由器配置错误可能是这两个现象背后的根本问题。
事件管理作为 ITSM 实践的重要性
那么，为什么要进行事件管理？为什么这还是 ITSM 的一部分？
答案是影响。研究表明，系统每停机一小时，重大事件平均使公司损失 10 万至 30 万美元不等。
明确定义事件管理流程有助于显著降低这些成本。明确定义流程的优势包括：
- 更快速地解决事件
- 降低组织的成本或收入损失
- 在事件发生期间改善内外部沟通
- 持续学习和改进
事件管理工作流
我将使用 ITIL 框架来引导您完成正确工作单处理的高级概述，但大多数其他流行的框架通过略有不同的术语阐明了大致相似的概念。
事件管理的关键在于，要有一个良好的流程并坚持下去。
我知道，即便如此，这也会令人望而生畏。但好消息是，您可以通过其他数以千计的 IT 服务团队的经验来学习。
忙碌的成长型 IT 组织最常犯的一个错误就是浪费时间做无用功，并从头开始创建流程。（而不借鉴最佳实践）或构建自己开发的工具来处理工作单。
识别事件并进行记录
事件可能源自四面八方。如果网络中心位置不当且屋顶漏水，员工可以打电话给您报告此事件，或者您也可以通过吊顶板掉下来砸到您腿上来得知此事件。（这并不是我们的经验之谈......*呵呵*）
无论源自何处，前两个步骤都很简单：有人发现事件，然后另有人记录事件。
如果您收到已通过服务台记录的事件，则表明已完成前两个步骤。如果您接到电话，或者事件是通过电子邮件、短信或快递报告的，则服务台团队就应负责在服务台中妥善地记录该事件。
这些事件日志（即工作单）通常包括：
- 事件报告人员的姓名
- 事件报告的日期和时间
- 事件描述（什么出现了问题或无法正常运行）
- 为便于跟踪而分配给事件的唯一标识号
对事件进行分类
接下来的两个步骤（分类和优先级）既关键又经常被忽视。他们还将我合作过的更“理智”的服务台与...好吧，没那么多。
首先，您必须为每个事件分配一个直观的逻辑类别（并按需分配子类别）。如果不这样做，您之后就无法分析数据，也无法摸索趋势和模式，而这些措施正是有效管理问题和预防未来事件的关键组成部分。
所以基本上，别忘了。此外，还应确保选择可让您轻松自定义事件类别的 IT 服务台解决方案。
优先处理您的事件
第二，必须确定每个事件的优先级。
要确定事件的优先级，首先要评估其对业务的影响。考虑将受到影响的人数，以及事件对财务、安全和法规遵从性的潜在影响，以确定事件造成的痛苦程度以及解决方案对业务的紧迫程度。
在此情况下，最佳做法是在事件发生之前定义严重性和优先级，从而使事件经理能够更轻松地快速评估优先级。
什么时候对优先级有疑问？选择优先级较高的级别。宁可小心谨慎，也不要轻举妄动，以免一些严重的事情钻了空子。
设置这些优先级后，则应按优先级顺序处理所有未决事件。大多数组织都会围绕每个优先级制定明确的服务协议，这样客户就清楚要多快才能得到响应和解决方案。我强烈推荐这种做法。
响应
事件响应是一个相当宽泛的术语，因此我们将其进一步分解为在您确定事件、对其进行分类和按优先级排序后最有可能执行的步骤。
初始诊断
我们可以将此视为医院针对新患者的分诊功能。服务台员工正在围绕可能出现的问题进行快速假设，这样他们就可以着手解决问题，或者遵循适当的程序并整合合适的资源来解决问题。
在此步骤中，知识库和诊断手册也是非常有用的工具。
如果一级服务台支持人员能够根据其初步诊断以及现有知识和工具解决事件，则该事件便可解决。否则，就需要上报。
事件上报
上报听起来像个坏词，但事实并非如此。
您的一线支持团队应能在不上报的情况下解决大量最常见的事件。但对于那些他们无法解决的事件，其目标就是收集和记录正确的信息，以帮助二级和三级（技术水平更高的）支持人员快速上手，这样他们就能迅速解决事件。
调查和诊断
ITIL 将此称为其自身的单个步骤。但实际上，它贯穿于整个事件生命周期。
从某种程度上说，一线支持人员在收集信息时便已在进行调查，甚至可能成功地诊断并解决事件，而无需进行任何上报。
在此情况下，您便可直接跳过接下来的几个步骤：解决和恢复以及关闭事件。
否则，在您上报给二级和三级支持人员或引入外部资源或其他部门成员以进行咨询和协助解决事件的每个步骤中，您都需要调查和诊断。
解决和恢复
最终，理想情况下，在既定的服务级别协议 (SLA) 范围内，您将得出诊断结论，并执行必要的步骤以解决事件。恢复仅指完全还原操作可能需要的时间，因为即使在确定了正确的解决方案后，某些修复程序（例如错误补丁等）也可能需要测试和部署。
事件关闭
然后，事件会被传回服务台（如果事件被上报）并关闭。为了保持质量并确保流程顺利进行，只允许服务台员工关闭事件，并且事件负责人应与报告事件的人员进行核实，以确认解决方案令人满意且实际已可关闭此事件。
结论：不要跳过步骤
这个流程可能看似过分正式，尤其是如果您只有几个服务台分析师时。但是，无论您的团队结构如何，事件生命周期都一样。
假设您只有一名服务台分析师，因此没有三级支持。但是，超出您的服务台分析师知识范畴的事件必须上报给某人，要么是您的总工程师或者外部顾问，甚至是您自己，对吧？
瞧！您确实有二级或三级支持——您自己或您的工程师。
我想表达什么？尽管 ITIL 看起来完全是关于语义的，但不要陷入其中。寻找简单的方法来调整组织层次结构和流程工作流程，以适应上文概述的简单 IT 服务管理框架。
这样，您将提供更好的客户服务，并为业务带来更多价值。（而且，您也不会再有焦头烂额的感觉，这是另一个好处！）
最后，还有几个注意点：
- 记录每个事件。给事件一个唯一的数字。并在中央帮助台系统中捕获重要细节（如日期、时间和描述）。
- 如果您有大量的内部或外部受众需要向其传达事件更新，请考虑使用事件沟通的状态页面。
- 为每个事件分配一个类别（并根据需要分配子类别）。
- 为每个事件指定一个优先级别，为每个优先级指定一个 SLA。
- 明确界定事件响应人员的角色，例如事件指挥官、重大事件经理、沟通主管。
- 只要有可能，请为您的一线支持团队提供知识库文章和事件诊断脚本，以帮助他们快速解决事件。
- 确保服务台始终保持对事件进度、路由和状态的控制。
- 而且不要仅仅捕获事件数据。还要进行分析！寻找可以减少事件量和降低风险的趋势、模式和潜在的深层次问题。
关于作者
Nick Wright
Atlassian 服务运营经理
我和我的团队确保 Atlassian 的云应用和基础架构表现一流，我很乐意分享我们在快速扩展的同时如何做到这一点。我是新西兰人，虽然存在语言障碍，但我可以说一点英语。工作之外，我要么骑自行车、玩游戏，要么和妻女一起出去玩。