事件回應的基礎

現今的組織受益於雲端的輔助功能、效率及便利性，但隨著其進行數位轉型，它們面臨許多挑戰，這些轉型牽涉到將部分業務移至雲端服務。

貴組織可能面臨的一些常見挑戰包括：

• 服務中斷次數增加
• 沒有有效的追蹤和回應事件的方法（一切都是臨機作和反動的）
• 無法接受的解決時間
• 解決問題所需的時間沒有改善，甚至越來越糟糕
• 信息與狀態難以找到
• 相同問題和錯誤的重複出現

若要應對這些挑戰，您需要一個定義完善的事件響應計劃，其建置基礎穩固。

基礎和支柱

基金會的目的是要堅持和保存其上方的結構。 我們已分別在此學習路徑的不同課程模組簡介中，探討了可靠性工作是以監視作為其基礎建置而成，而事件回應則位於階層中監視基礎層級的正上方。

事件回應也有基礎本身。 有三大要素支援良好的事件響應計劃：

• 名單
• 角色
• 輪替人員

在此單元中，您將瞭解每個要素是什麼，以及他們在設計事件回應策略時扮演哪些部分，以進一步引導您沿著可靠性目標前進的道路。

名單

有一個很好的計劃至關重要，但計劃是毫無用處的，沒有人員來執行它。 因此，最好的起點是決定誰預期要響應問題，以及如何讓他們知道何時需要他們的回應。

解決這項挑戰的最佳方式是設計名冊。 名冊是指派給待命小組的人員清單。 此小組應由多個工程師組成。 這些小組成員應具備知識和技能，以解決環境中可能發生的問題類型，以及事件回應的訓練。

不過，名稱清單還不夠。 您必須建立一個系統，以了解在任何特定時間點誰負責待命，以及每個人應該做什麼。 這就是角色發揮作用的地方。

角色

角色能為本來可能混亂的回應，或者充其量僅是臨機應變的回應，帶來秩序。 其方式是定義每個人在特定情況下要假設的特定函式，以及每個函式在「命令鏈結」中的位置。角色可能會因組織或甚至事件類型而有所不同，但下列角色通常應該屬於有組織的事件回應小組：

• 主要回應者：即為「負責人」，通常是趕往現場的第一人，也就是在事件發生時要呼叫的第一位待命工程師。
• 次要回應者：這是作為備份的人員，如果主要回應者無法應對，或需要第二雙眼睛，則可以介入支援。
• 主題專家（SME）：這些是深入瞭解您作業特定面向的人員。 如果主要和次要回應者需要向具有更多專業知識的人呈報問題，他們就在那裡。 它們並非隨時待命，但需要其特殊技能時可以使用。 您應該維護各種主題中的中小企業清單（例如資料庫、前端、網路基礎結構、Web 應用程式、網路安全性等等）。
• 事件指揮官：這是影響許多不同元件和/或需要跨許多不同小組和系統協調的大型事件或中斷中的重要角色。 事件指揮官將是協調大部分對話及回應和補救措施活動的人。 事件指揮官密切關注「大局」：他們持續關注發生了什麼事，以及誰在做什麼。 事件指揮官非常擅長確保工程師保持專注，並進行其自身的補救工作，並且避免互相干擾或撤銷彼此的工作。
• Scribe：抄寫員的職責是盡可能詳細地記錄與事件相關的對話。 小組通常會使用電話橋接、電話會議或視訊聊天來聯繫所有人，嘗試了解正在發生的事情，這確實有助於創造溝通空間。 然而，若不將其內容轉錄下來，我們就很難理清並詳細了解工程師們所說和所做的事情。 因此，書記是指能夠協助詳細記錄以供日後檢閱的人員。 抄寫員會擷取所有可能的數據，不僅記錄團隊成員在做什麼，還記錄他們所說的話，甚至他們的感受或經歷。
• 溝通協調員：將此人視為事件的「公關經理」。 通訊協調員會與事件指揮官合作，與未參與積極處理和復原事件的人員分享事件的相關信息。 這可能包括客戶、銷售和行銷團隊、客戶支援，以及組織內外的任何其他利害關係人，這些利害關係人需要了解發生的情況，以及回應及補救措施的進展狀況。

輪替人員

現在您已擁有回應小組人員的名冊，並已指派適當的角色。 下一步和最後一個步驟是建立排班表，這是一個指派每位人員值班班次的排程。

分班的方式有很多不同。 班次排程可以是複雜的策略性程式。 不應隨機指派班次;您應該將一些想法納入排程，使其盡可能有效，並盡可能讓小組成員愉快。

排班的方法包含：

• 24 x 7：這是小組成員連續數天的輪替。 這是配置班次涵蓋範圍的簡單方式，但您必須小心限制持續時間。 班次輪換時間超過三到四天，可能會損害工程人員的整體健康情況，因而降低整個系統的可靠性。
• 日班制：這種輪班模式可安排工程師僅在正常的工作時間內待命，並在下班時，將待命責任交接給另一位不同時區的同事。

這些只是可指派班次方式的幾個範例。 重點是以最適合回應小組個人的方式劃分班次。 當工程師需要更多彈性時，有許多方式可以自定義班次，尤其是週末。 當發生非工作相關衝突時，工程師應該能夠輕鬆地將角色交給某人。