在 站点可靠性工程师（SRE）的世界里，故障不仅是一种选择，而且是预期的。 系统、Web 应用程序、服务器、设备等都容易出现性能问题和某个时刻的意外中断。 这是一个不可避免的事实。 这些意外的故障可能导致巨大的收入损失，客户信任，并且取决于行业，也许是罚款。 幸运的是，SRE 事件管理是用于限制意外问题造成的中断的核心实践之一。 在另一篇文章中，我们讨论了 混沌工程 以及 SRE 团队如何主动寻找和测试故障，以防止最坏的情况发生。 但是，众所周知，问题可能会从裂缝中溜走。 目标是防止这些事件成为大规模的级联故障。 SRE 和 DevOps 团队可以使用这些事件来更好地构建并改进其系统和服务。
什么是事件？
在我们深入探讨这个话题之前，首先我们必须讨论事件是什么。 需要立即采取行动的事情与以后可以调查的事情之间的界限在哪里？ 如果每个问题都被归类为紧急问题，没有人会得到任何解决方案。 在IT（信息技术）的背景下，事件只是扰乱正常操作或服务质量的事件或问题。 它不会导致失败，但如果不加以选中，可能会对您的服务和运营造成更大的影响。 它们通常发生在凌晨2点，当你幸福地睡着了，被手机响的声音吵醒。 我们当然是在开玩笑，但你知道，如果一大早就发生了一些事情，那就糟糕了。 在凌晨2：00.m，没有什么好事发生，特别是当我们谈论IT行业时。
什么是事件管理？
现在我们已经讨论了什么是事件，事件管理是团队解决这些事件并使系统和服务恢复正常运营的过程。 我们还应该注意，事件管理只是称为IT服务管理（ITSM）的更大概念的一个元素。 ITSM 定义了团队如何设计、创建和交付其服务。 它不仅仅是IT支持。 ITSM 是 IT 服务生命周期背后的策略、流程和结构。 ITSM是信息技术基础设施库（ITIL）的实践之一。
ITIL为构建ITSM解决方案提供了框架和指南。 您可能已经熟悉其他框架，如业务流程框架 （eTOM）、信息和相关技术控制目标 （COBIT）、FitSM、ISO/IEC 20000 和 Microsoft 运营框架 （MOF）。
IT 服务管理 （ITSM） 框架
如果我们退后一步，只关注ITSM框架中的元素，那么还有其他六个组件与事件管理一起构成了ITSM”轮子”。 虽然我们不会详细介绍这些内容，但重要的是要了解所有这些部分如何与事件管理结合在一起。
服务目录
IT 服务目录通常是组织创建的数据库或资源，用于向用户提供有关其运营服务和产品的信息。 这些服务目录提供有关当前和计划服务的有用信息，以及定价、采购流程、联系人和其他可交付结果。
服务台
可以将服务台视为服务提供商与用户（如内部员工、利益干系人或客户）之间的联系点。 它是用户获得帮助和服务的中心”中心”。 根据ITIL的定义，服务台可以采取事件解决或服务请求的形式，但无论如何，服务台的主要目标是提供快速高效的服务。
问题管理
当我们谈论事件管理时，SRE团队可能能够快速解决事件，但潜在的问题可能仍然存在并持续一段时间。 问题管理是永久修复事件根本原因的过程，可提高长期性能和未来服务部署。
变更管理
任何类型的更改，无论我们谈论的是新服务部署还是个人更改，总存在风险因素。 变更管理是确定变更将如何影响服务部署和/或考虑对业务本身的影响的过程。 变更管理有时也与发布管理分组。
资产管理
您无法虚拟化所有内容…还。 软件服务仍然需要物理设备和硬件才能运行。 组织需要跟踪、管理和不断更新这些设备，以确保其服务能够平稳运行。 资产管理也称为 IT 资产管理或 ITAM。
知识、政策和程序管理
知识管理的目标是在组织内收集、审查和共享信息方面减少冗余。 这有助于提高效率，并确保信息一致、最新且可用。
事件管理生命周期：流程和步骤
组织对事件的响应，无论是关于停机、安全漏洞还是网络攻击，甚至是长时间的延迟和重复的错误，对于业务的持续成功以及客户或最终用户的信任都至关重要。 SRE 必须管理复杂的分布式系统。 虽然这些系统的好处是它们更可靠、可扩展和容错，但这也使它们变得非常复杂，这可能导致更长的修复时间，因为问题更难检测和查明。 最好的 SRE 事件管理团队坚持严格的事件管理和补救流程。 虽然实际步骤和流程可能因组织而异，但大多数组织都遵循相同的基本路径。 让我们看一下 SRE 事件管理过程和步骤。
1. 事件识别
您无法修复您不知道的问题。 事件识别从某种形式的监视或警报机制开始。 我们在另一篇文章中讨论了 监视分布式系统 ，以及它与 SRE 团队的关系。 了解错误、停机时间或应用程序延迟发生的时间和地点是限制对用户和客户的影响的关键因素。 但是，在某些情况下，事件将通过支持票证，电话甚至社交媒体来了解，当问题公开发布给所有人看时，这绝不是好消息。
2. 事件记录
无论检测方法如何，一旦确定了事件，就应该记录下来。 事件日志记录有多种用途。 它确保已提交正式记录，以便以后查看事件趋势。 如果相同或类似的事件反复出现，则可能表明需要解决的更复杂的问题。 记录事件时，还会包含相关信息，如时间戳、事件描述和发现问题的人员。 信息越详细越好。
3. 事件分类
接下来是根据严重性、紧迫性或受影响的功能区域等因素对事件进行分类。 与记录事件一样，提供的更多信息有助于以后确定要分配给事件响应的正确团队或个人。
4. 事件优先级
根据事件的分类方式，下一步是设置优先级。 同样，其中一些步骤同时发生，因此在某些情况下，它们可能同时执行。 组织通常使用低、中或高的简单比例，但是，某些事件可能会根据受影响的情况自动归入特定类别。 例如，如果事件与中断有关，则会自动将其置于高优先级。
5. 事件响应、解决和关闭
最后一步是最终响应并解决事件以结束。 这最后一步与其说是一门科学，不如说是一种艺术形式。 这里没有简单的按钮。 它可能需要几个周期，并尝试确认事件最终得到解决。 每次尝试都可以带来更多信息和关于事件可能发生的原因的其他理论。 这也可以导致识别可能存在弱点的进一步机会。 处理完事件后，就可以关闭请求并响应报告事件的原始用户了。
死后分析
在事件响应之后，通常最好完整地查看事件的详细信息。 这称为事后事件。 确定哪些事件需要事后分析通常由团队或组织决定，但是，原因保持不变。 事后分析有助于确定可以改进的领域，识别性能盲点，并完善您的事件响应流程。 事后分析应总结事件的各个方面，并包括以下要素：
- 事件的高级别摘要和时间表。
- 事件的根本原因分析和来源。
- 为解决事件而采取的措施以及哪些措施有效或无效。
- 将来的事件预防以及发现的其他信息。
事后分析是 SRE文化的核心规则之一。 事实上，他们称之为无可指摘的死后分析。 这个概念背后的想法是，团队中的每个人都以最好的意图行事，没有人应该为这一事件负责。 重点是确定发生这种情况的原因以及如何提高系统性能。 错误是这个行业自然而然的一部分，所以重点不是责怪个人，而是创建一个更强大、更有弹性的系统，这样问题就不会再发生。
结论：SRE 事件管理 – 概述、技术和工具
SRE 事件管理对于保持系统、应用程序、站点和服务正常运行至关重要。 秒很重要，尤其是在用户体验方面。 在大型分布式系统中，最小的问题可能会导致级联问题。 当问题发生时，主动设置正确的警报和通知可能是区别，并确保对用户的影响有限。 有关Dotcom-Monitor平台如何与这些事件管理工具集成 的更多信息，请访问我们的 知识库。
免费试用 Dotcom-Monitor 并访问平台内的所有解决方案、集成和功能。
