在 站点可靠性工程师（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 事件管理过程和步骤。
事件识别
您无法修复您不知道的问题。 事件识别从某种形式的监视或警报机制开始。 我们在另一篇文章中讨论了 监视分布式系统 ，以及它与 SRE 团队的关系。 了解错误、停机时间或应用程序延迟发生的时间和地点是限制对用户和客户的影响的关键因素。 但是，在某些情况下，事件将通过支持票证，电话甚至社交媒体来了解，当问题公开发布给所有人看时，这绝不是好消息。
事件日志记录
无论检测方法如何，一旦确定了事件，就应该记录下来。 事件日志记录有多种用途。 它确保已提交正式记录，以便以后查看事件趋势。 如果相同或类似的事件反复出现，则可能表明需要解决的更复杂的问题。 记录事件时，还会包含相关信息，如时间戳、事件描述和发现问题的人员。 信息越详细越好。
事件分类
接下来是根据严重性、紧迫性或受影响的功能区域等因素对事件进行分类。 与记录事件一样，提供的更多信息有助于以后确定要分配给事件响应的正确团队或个人。
事件优先级
根据事件的分类方式，下一步是设置优先级。 同样，其中一些步骤同时发生，因此在某些情况下，它们可能同时执行。 组织通常使用低、中或高的简单比例，但是，某些事件可能会根据受影响的情况自动归入特定类别。 例如，如果事件与中断有关，则会自动将其置于高优先级。
事件响应、解决和关闭
最后一步是最终响应并解决事件以结束。 这最后一步与其说是一门科学，不如说是一种艺术形式。 这里没有简单的按钮。 它可能需要几个周期，并尝试确认事件最终得到解决。 每次尝试都可以带来更多信息和关于事件可能发生的原因的其他理论。 这也可以导致识别可能存在弱点的进一步机会。 处理完事件后，就可以关闭请求并响应报告事件的原始用户了。
死后分析
在事件响应之后，通常最好完整地查看事件的详细信息。 这称为事后事件。 确定哪些事件需要事后分析通常由团队或组织决定，但是，原因保持不变。 事后分析有助于确定可以改进的领域，识别性能盲点，并完善您的事件响应流程。 事后分析应总结事件的各个方面，并包括以下要素：
- 事件的高级别摘要和时间表。
- 事件的根本原因分析和来源。
- 为解决事件而采取的措施以及哪些措施有效或无效。
- 将来的事件预防以及发现的其他信息。
事后分析是 SRE文化的核心规则之一。 事实上，他们称之为无可指摘的死后分析。 这个概念背后的想法是，团队中的每个人都以最好的意图行事，没有人应该为这一事件负责。 重点是确定发生这种情况的原因以及如何提高系统性能。 错误是这个行业自然而然的一部分，所以重点不是责怪个人，而是创建一个更强大、更有弹性的系统，这样问题就不会再发生。
SRE事件管理：工具和服务
如今，SRE 似乎可以无限制地访问和访问各种工具、平台和服务，以帮助自动化和管理其工作负载。 其中一些工具我们已经在另一篇文章中介绍过，但我们将专门讨论SRE事件管理工具。
事件，警报和通信工具
事件管理、通信和警报工具可能是 SRE 团队使用的一些最重要的工具。 您的团队越早意识到这一点，事件就越快得到解决。 这些工具应与监视策略一起使用。 Dotcom-Monitor 平台与这些工具（以及更多工具）集成，提供了一种无缝的方式，将团队可能已经使用的工具与您的监视和可观察性目标相结合。
PagerDuty
PagerDuty 可以根据组织的特定监视要求帮助识别和触发警报。 通过自动化事件识别阶段，团队可以减少手动监督的数量和开始事件管理流程所需的时间。 正确的团队会立即收到通知，这意味着事件响应可以尽快发生。
维克托·奥普斯
VictorOps，现在是Splunk On-Call，是一个事件自动化平台，可帮助减少解决事件所需的时间，为SRE和DevOps团队提供一种有效管理其事件响应流程的方法。 Splunk On-Call还可以帮助简化待命计划和事件升级策略。
Slack
虽然不是真正的事件响应工具，但沟通是事件响应过程中的一个重要因素。 作为市场上最知名和最受欢迎的聊天应用程序之一，Slack为SRE团队提供了将所有通信整合到一个仪表板中的功能。 Slack非常适合公司间通信，还可以自动执行响应和事件，甚至可以连接到其他系统和服务。
微软团队
如果你的组织使用 Office 365，那么你可能已经了解 Microsoft 团队。 与Slack一样，微软是一个实时通信应用程序，提供在线消息传递，视频聊天和文档共享等功能。
OpsGenie
OpsGenie 是另一种事件响应解决方案，它使团队能够通过组和筛选机制设置和配置自动警报。 此外，SRE 还可以管理随叫随到的路由规则和特定的升级策略。 OpsGenie 还提供报告和分析等功能，以便团队可以查看和跟踪事件响应指标和效率。
结论：SRE 事件管理 – 概述、技术和工具
SRE 事件管理对于保持系统、应用程序、站点和服务正常运行至关重要。 秒很重要，尤其是在用户体验方面。 在大型分布式系统中，最小的问题可能会导致级联问题。 当问题发生时，主动设置正确的警报和通知可能是区别，并确保对用户的影响有限。 有关Dotcom-Monitor平台如何与这些事件管理工具集成 的更多信息，请访问我们的 知识库。
免费试用Dotcom-Monitor 30天，并可以访问平台中的所有解决方案，集成和功能。
