事件回應的基礎
現今組織受益於雲端的可存取性、效率和便利性，但這些組織也會在進行涉及將其許多商務部分移往雲端服務的數位轉型時，遇到許多挑戰。
您在組織中可能會面對的一些常見挑戰包括：
- 服務中斷次數的增加
- 針對追蹤及回應事件沒有有效的方法 (所有工作都是臨機操作且反動的)
- 無法接受的解決時間
- 解決的時間無法獲得改善，甚至更加惡化
- 難以尋找資訊和狀態
- 重複發生相同的問題和錯誤
為了面對這些挑戰，您需要建置在穩固基礎上且經過妥善定義的事件回應計劃。
基礎和要件
基礎的目的在於支撐及鞏固其上方結構。 我們已分別在此學習路徑的不同課程模組簡介中，探討了可靠性工作是以監視作為其基礎建置而成，而事件回應則位於階層中監視基礎層級的正上方。
當然，事件回應也擁有自己的基礎。 良好的事件回應規劃有三大支柱：
- 名冊
- 角色
- 旋轉
在本單元中，您將會了解在設計事件回應策略時，每個支柱的意義，以及各自發揮作用的部分，其有助朝著實現可靠性的目標邁進。
名冊
良策固然重要，但若沒有將明之材仍毫無用武之地。 因此，最好的起點是判斷哪些人員該負責針對問題進行回應，以及在有需要時如何通知這些人員採取行動。
解決這項困難的最佳方式就是設計一份名冊。 名冊即為接受指派至待命小組的人員清單。 這個小組應由多名工程師組成。 這些小組成員需要具備知識和技能，以解決環境中、或在事件回應中進行定型時，可能發生的各種問題。
光是人名清單並不夠充足， 您還需要針對任何指定時間點上的待命人員、以及各自負責的工作來建置一套架構。 這便是角色的意義所在。
角色
角色能夠將原本雜亂無章或臨時回應整理得井然有序。 角色會定義每名人員在特定情況下要承擔的特定職責，以及各自在「命令鏈」中的位置，藉此達成其目的。角色可能會因組織或事件種類而有所不同，但下列角色應常駐於組織的事件回應小組中：
- 主要回應者：即為「負責人」，通常是趕往現場的第一人，也就是在事件發生時要呼叫的第一位待命工程師。
- 次要回應者：即為後備人員，在無法與主要回應者取得連絡、或其需要第二人支援時採取行動。
- 主題專家 (SME)：這些人員對於您作業的特定面向擁有更深入了解。 當主要與次要回應者必須將問題呈報給具有更多專業知識的人員時，主題專家就能夠提供協助。 主題專家不會隨時待命，僅在需要特殊技術時與其連絡。 對於各種不同的主題 (例如，資料庫、前端、網路基礎結構、Web 應用程式、網路安全性等) 您都應該保有一份主題專家的清單。
- 事件指揮官：在面臨會影響許多環節及/或需要不同小組與系統之間進行合作的大規模事件或服務中斷時，事件指揮官的角色舉足輕重。 事件指揮官必須在各種回應與補救活動的溝通和工作之間進行協調。 事件指揮官會留意事件「全貌」，密切關注事情的走向，以及人員是否各司其職。 事件指揮官能讓工程師專注於自己負責的補救工作上，確保不會介入或影響其他人的工作。
- 書記：書記角色是要盡可能地詳細記錄與事件有關的溝通。 小組通常會使用電話橋接、電話會議或視訊聊天來聯繫所有人，嘗試了解正在發生的事情，這確實有助於創造溝通空間。 不過，如果沒有人負責將對話寫下，其他人便難以深入了解工程師正在傳達的訊息或所正在執行作業。 因此，書記是指能夠協助詳細記錄以供日後檢閱的人員。 書記會擷取所有可能的資料，除了小組成員的工作，也會記錄人員所說的內容，甚至人員的感受與體驗。
- 溝通協調者：您可將此人員視為事件的「公用關係管理員」。 溝通協調者會與事件指揮官一起工作，並和其他未直接參與事件處理及復原的人共用相關資訊。 這些人可能包括客戶、銷售與行銷小組、客戶支援，以及組織內外部的任何其他利益關係人，這些人可能需要了解事件的狀況，以及回應與補救的進展。
旋轉
您現在已經有一份回應小組人員的名冊，也為其中所有人指派了適當的角色。 下一步 (最後一步) 便是建立一組輪替人員，也就是一份排程表，為每個人分配需要待命的班次。
您有許多方式可為人員排班。 排班可以是複雜且具策略性的流程。 您不應隨機指派輪班，而是思考如何讓排定的班次更有效率，並盡可能地不要讓小組成員感到不愉快。
排班的方法包含：
- 待命制：這是種讓小組成員連續 7 天進行待命的輪替方法。 這種方法可輕易地配置排班所涵蓋的範圍，但必須小心限制班次的時間。 超過三到四天的班次可能會危害到工程人員整體身心健康，進而降低整個系統的可靠性。
- 日班制：這種輪班模式可安排工程師僅在正常的工作時間內待命，並在下班時，將待命責任交接給另一位不同時區的同事。
這只是部分指派班次的範例。 重點在於以最適合回應小組人員的方式來排班。 自訂排班的方式有很多，在針對工程師需要更多彈性的週末時尤須注意。 發生非工作相關的衝突時，工程師應該要能夠輕鬆地將角色交接給其他人員。