194 年的停机时间：回顾 2018 年我们记录的事件数据

【知识点：ITSM 服务管理平台包含事件管理、问题管理、变更管理、服务级别管理。事件管理的目标是在不影响业务的情况下，尽可能快速的恢复服务，从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类，确定事件的优先级和建立事件的升级机制。】

我们 2018 年停机报告中强调了公司如何能在停机期间频繁高效地与用户保持沟通，提供服务。

Statuspage 的客户在 2018 年记录了超过 194 年的公共事件，这比 2017 年的 104 年增长了 87%。

开放式的事件沟通方式对公司及其客户越来越重要。这一点得到了一些大牌公司的肯定和强调，他们 18 年都设立了公共 Statuspage，如 Github、LinkedIn 和 Yelp。更多地关注事件沟通，也就更多地关注事件管理。公司花费更多的时间和资源为停机做准备，正如我们从客户那里了解到的，他们如何为高流量日做准备。

我们深入研究了 2018 年的数据，以便更好地了解客户在今年停工期间的沟通时间和方式。这些数据包含所有报告的事件，从服务中的小故障点到大规模停机，再加上定期维护记录的任何计划停机时间。

数字代表什么意思

当然，从 2017 年到 2018 年，记录的事件小时数的大幅增加，部分原因是 Statuspage 用户总数的增加，但我们也认为这反映了依赖 SaaS 产品的公司越来越倾向于云优先的心态。公司围绕着事件展开沟通，客户已经开始期望有这种透明度。

作为一家软件公司， 你需要 Statuspage，让客户知道为什么 FordPass 有“技术上故障”。保持沉默只会让客户感受更糟。

Kyle Campos（@kCampos）2018 年 7 月 14 日

除了今年记录的事件数量大幅增长之外，我们还发现每个事件的平均更新数量几乎翻了一番。每个事件平均更新 4.4 次，我们认为公司开始优先考虑与客户进行频繁、透明的沟通。

我们还惊讶地发现，近一半的客户（确切地说是 45%）采用了某些页面自动化集成提醒或监控工具。虽然我们一直主张在事件通信过程中有人的元素，但设置某种级别的自动化绝对可以在最重要的时候节省时间。许多客户采用这种混合的手动/自动方法来节省时间，而不会冒着客户体验不佳的风险。

虽然记录的事件和发布的更新在不断增加，但是事后回顾和记录非常少 — 2018 年在 Statuspage 记录的事件中只有 3% 附有事后记录。这并不太令人惊讶，因为并非所有事件都需要事后分析（有些公司在公司博客上写了事后分析），但我们设想，随着客户开始期待此类后续行动，这个百分比将在 2019 年有所上升。

你是否计划向客户提供事后说明，或者至少说明为什么会发生这种情况？每一次中断都会使人们对服务失去信心。你需要解释改进的地方，防止将来发生类似情况。

马特·彼得曼（@mattpeerman）2018 年 12 月 1 日

超群事件

有些时候，某些公司或行业更容易出现服务中断。例如，双十一，电子商务公司的网站或应用程序流量呈指数级增长。对于 Amazon 来说，Prime Day（他们今年最大的销售日）就是这一天 — 甚至可以与最疯狂的黑色星期五和网络星期一的流量相媲美。尽管这家零售巨头的销售额仍创下了历史新高，但消费者在一个多小时内无法连接到 amazon.com，这导致了很多客户的不满，估计收入损失高达 1 亿美元。最重要的是 Twitter 上大量可爱的狗狗图片，展示着错误页面：

坏消息：亚马逊似乎因为 Prime Day 销售的需求而崩溃。好消息：亚马逊的错误页面令人赞叹。

赛斯菲德（@sfiegerman）2018 年 7 月 16 日

HugOps 2019

尽管今年可能会有更多的停机时间，但也有更多的爱和欣赏（#HugOps）展现给那些在停机时敞开心扉的公司 — 事实上，有超过 7000 条关于 HugOps 的推特和转推。我们开始向那些在推特上转发过我们数字 HugOps 海报的人发送实际的 HugOps 海报，今年已经发送了 70 多张。这意味着 1% 的 HugOps 推特用户现在自豪地在他们的办公室里展示了一张 HugOps 海报。

Atlassian 事件管理的最新进展

虽然事件沟通是事件管理的重要组成部分，但它只是更大难题的一部分。在 Atlassian，我们在事件管理工具和实践方面的投资翻了一番。看看我们在做什么：

Opsgenie 的自动化操作：事件响应者通常对警报采取可预测的重复操作。这些操作包括收集有关特定系统的更多信息、运行网络诊断、增加云资源或重新启动服务。自动化操作使您能够通过第三方平台运行自动化脚本和剧本。Opsgenie 现在提供了两种自动化集成方法的支持：AWS 系统管理器和通用的 REST 端点。团队可以与这些平台集成，直接从 Opsgenie 控制台或移动应用程序触发自动化任务。这节省了响应者的时间，减少了他们在事件响应期间需要使用的应用程序的数量，并且可以对 MTTR 产生积极影响。了解更多信息。

事后分析 Jira Ops：事件管理过程中最重要的部分之一就是事后分析。在这里，事件响应团队可以学习、改进和收集试图解决事件的时间和投资的所有回报。不幸的是，事后分享过程往往被忽视，因为它太费时和难以管理。JiraOps 事后分析的一个关键时间节省程序是事件时间线，它按时间顺序收集事件中的所有关键事件。团队可以分析发生的事情，确定根本原因，并直接从事后创建 Jira 问题，以确保从每个事件中采取措施进行改进。