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% 附有事後記錄。這並不太令人驚訝，因為並非所有事件都需要事後分析（有些公司在公司blog上寫了事後分析），但我們設想，隨著客戶開始期待此類後續行動，這個百分比將在2019年有所上升。

你是否計畫向客戶提供事後說明，或者至少說明為什麼會發生這種情況？每一次中斷都會使人們對服務失去信心。你需要解釋改進的地方，防止將來發生類似情況。

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

超群事件

有些時候，某些公司或行業更容易出現服務中斷。例如，雙十一，電商網站或應用程式的流量呈指數級增長。

對於 Amazon 來說，Prime Day（他們今年最大的銷售日）就是這一天 — 甚至可以與最瘋狂的黑色星期五和網路星期一的流量相媲美。

儘管這家零售巨頭的銷售額仍創下了歷史新高，但消費者在一個多小時內無法連接到amazon.com，這導致了很多客戶的不滿，估計收入損失高達1億美元。

壞消息：亞馬遜似乎因為 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問題，以確保從每個事件中採取措施進行改進。

本文來自公眾號Atlassian速递發布的：194年的停機時間：回顧2018年我們記錄的事件數據

如果您喜歡這篇文章，歡迎fallow我們的頻道！