针对高速团队的事件管理
创建更好的事件时间线（及其重要性）
随着技术变得错综复杂，事件管理也变得复杂。而随着事件管理变得千头万绪，文档和沟通也变得复杂起来。
因此，越来越多公司开始采用事件时间线。这是一种集中式事件动态订阅源，旨在让团队在事件发生期间保持在同一页面上，也能为同样这些团队提供一份记录，供他们在事件后用来确定根本原因并改进未来表现。
什么是事件时间线？
事件时间线是事件的完整实时记录。它通常包括手动输入项（聊天）、页面整合记录、警报和确认，以及自动系统更新（例如，提示有人更改了事件严重性级别或将其标记为已解决的通知）。它也常与聊天或 Slack 频道同步。
时间线的宗旨是使团队保持在同一页面上，让团队新成员快速上手，并简化事件事后分析过程。Atlassian 事件管理解决方案 Jira Service Management 通过可定制的平台构建强大的时间线，利用时间线全面反映的事件解决和上下文信息来跟踪工作。借助集中式警报、灵活自动化、集成聊天工具和协作工作空间等功能，在团队无缝协作解决事件时，会自动记录事件时间线。
“给我一份过去（比如）三天内所有变更的清单。没有准确的时间线，我们将无法确定因果关系，最终可能会再次发生中断。”
— 摘自《凤凰项目》，
Gene Kim、Kevin Behr、George Spafford
事件时间线的价值
一个实时视图
团队或利益相关者之间缺乏沟通，是导致事件失控的最快方式之一。事件时间线可以缓解这种风险，它能在单一视图中实时向每个人提供相同的信息。也就是说，从处理事件的开发人员到负责向用户发布动态的沟通团队，再到高层的利益相关者，每个人都可掌握最新的消息，无需复杂的传声筒游戏，或多个断续的电子邮件对话、电话通话和聊天。
单一实时视图还可为利益相关者带来便利，不仅能更轻松地识别事件的核心问题，还可确定互连系统中的风险和潜在问题。让多个团队访问时间线，就能更轻松地在互连系统中找到潜在问题、原因或风险。
更可靠的事件事后分析
在 Atlassian，事件事后分析是我们事件和问题管理流程中一个不可或缺的部分。它能将团队召集到一起，弄清楚发生了什么、原因是什么，以及可以做些什么来防止未来再次发生。要深入探究这些问题，详细记录事件期间发生的一切会有所帮助，不论是警报、利益相关者更新，还是最终解决办法。
对于许多公司来说，事件时间线可以充当这种详细记录。它不仅是用来实时协同处理事件的工具，也是展示何时发生什么以及（有时）原因为何的单一视图，这些信息可在事后分析审查阶段为团队节省许多小时的时间。
更深入地挖掘 KPI
事件时间线通常可以帮助团队深入探究单个事件，但其用处不止于此。它还可以与类似事件的时间线结合使用，帮助团队发现模式并利用重要 KPI 诊断更大的问题。
如果事件的解决时间超过平均时长，故障点在哪里？与其他类似事件相比如何？流程的哪些部分需要更仔细地审视？是不是存在一种模式，导致我们在流程、技术或团队设置方面遇到更大的问题？警报是不是按需发出？还是，我们需要重新审查警报阈值？待命值班表是否足以覆盖事件？我们团队的结构是否恰当？
时间线可以充当一个审查数据点，或者在 SLA 和 SLO 问题调查中充当众多数据点之一。
事件时间线与 ChatOps
事件时间线通常由 Jira Service Management 等事件管理系统提供并在这些系统中使用，以便集中所有事件信息。
ChatOps 对于事件管理有着同样的目标。唯一区别是，ChatOps 通常不将时间线放在事件管理系统中，而是把它们集成中到 Slack 之类的聊天程序中，这类程序与 Opsgenie 等事件管理平台和任何其他相关来源同步并从中提取信息。
ChatOps 的好处，即团队访问相同的信息、实时对话和更新、减少上下文切换、告别传声筒游戏以及内置用于事后分析的记录等，与事件时间线所承诺的并无二致。核心区别仅在于信息的位置和数量。对于大多数事件团队，ChatOps 源中通常有大量噪音围绕着重要信息。将丰富细节提取到事件时间线，同时保留聊天记录以备日后参考，这会很有帮助。
要了解详细了解 ChatOps 对于团队解决事件的益处以及 Jira Service Management 的事件管理功能，请点击以下按钮。