Azure 上 SaaS 工作負載的事件管理
軟體即服務的獨立軟體供應商 （ISV） 解決方案必須為客戶操作解決方案。 這樣做需要組織設定和文化特性，以順利處理非預期的生產情況。 身為架構設計人員，您必須據以設計管理工具。
本文會引導您調整組織的文化特性、流程和工具，以支援生產 SaaS 解決方案的事件管理。
瞭解您作為服務提供者的責任
操作 SaaS 解決方案表示您是客戶的 24x7 IT 和營運部門。 您必須準備好正確的人員配置、文化、程式和工具。
設計考量
負責 24x7x365 支援。 操作 SaaS 解決方案時，您的組織必須隨時備妥事件回應。 此準備包含一律有小組成員可用，因為事件發生在上班時間以外。
即時網站支援 牽涉到即時監視和響應影響系統可用性、安全性、效能或部署的事件。 您或您的客戶可以偵測這些事件。 若要處理這類事件，您需要特定技能，包括分析並解決壓力下的問題的能力。
實時網站支援可能會有壓力，因此請務必支援您的小組成員。 如果小組對此責任不熟悉，請仔細規劃轉換。 解決有關事件期間待命職責、補償和管理無法使用的問題。
風險：技能與期望管理。 並非所有工程師都適合 24x7x365 支援角色。 轉換既有小組以支援 SaaS 解決方案時，請確定已設定適當的期望，並提供教育機會。建立現場文化。 請考慮如何管理支援案例和事件，以及呈報的發生方式。 目標是確保小組成員瞭解其責任，並具備處理事件所需的技能和工具。
初創公司和小型組織對於即時網站問題可能有輕量型方案。 工程師一開始可能會回應客戶支援案例，作為前線支援。 成熟的組織，或具有企業客戶的 SaaS 提供者，需要更結構化的支援和專用小組。
取捨：營運卓越和成本。 管理即時網站事件可能會因新功能或 Bug 修正而偏離開發時間。 如果開發速度是個問題，請考慮僱用專用的即時網站資源。
設計建議
| 建議 | 優點 |
|---|---|
| 介紹處理支援案例的前線小組。 對於複雜的案例，此小組會收集工程小組對其調查所需的資訊。 廠商可作為您的前線支援小組，並執行初始問題分析並解決簡單的問題。 |
您可以避免過度負擔工程小組，並承擔事件處理責任，並處理其一般職責的中斷。 |
| 投資待命函式，讓工程師處理複雜的案例、調查及採取行動。 可能的話，請輪替小組成員之間的待命責任，每個工程師一次接聽數天。 |
透過定義完善的責任和呈報路徑，您可以快速找出並解決問題，而不會中斷您的工程工作流程。 |
| 採購專為事件管理而特製的工具。 請確定所有回應者都可以存取及瞭解如何有效地使用這些工具。 選取可監視系統狀態、追蹤客戶回報問題、找出問題、呈報給待命工程師、管理沒有響應的工程師，以及在生產環境中進行變更的工具。 |
擁有正確的工具可協助您的待命小組快速識別並解決事件，同時維護安全性和操作控制。 |
| 改善監視、部署、更新和其他一般管理作業。 | 藉由投資作業成熟度，您可以降低即時網站問題的可能性。 如果確實發生問題，妥善定義的作業會縮短解決時間。 |
定義您的回應計劃
確認事件是不可避免的，並透過定義事件回應計劃來做好準備。 這種主動式方法可防止您在第一個事件期間設計回應策略。
提前規劃重大事件，這通常會影響客戶使用服務的能力。 當您管理事件發生時，此準備有助於將壓力和複雜性降至最低。
設計考量
定義呈報路徑。 請確定小組了解支援工作的呈報程式。 在許多 SaaS 解決方案中，客戶會連絡前線支援小組，然後與工程小組通訊。 請確定客戶知道要與誰互動，以及為什麼他們不應該略過這些程式。 此外，請確定您的工程小組知道何時以及如何向廠商尋求協助，包括Microsoft的支持小組。
定義嚴重性層級。 不同的事件對您和您的客戶很重要。 處理主要生產中斷的方式與處理次要 Bug 的方式不同。 根據客戶影響定義嚴重性層級，併為每個層級設定適當的期望和時程表。
文件資訊，您需要分級。 讓檔保持最新狀態對於有效的事件回應至關重要。 本檔包含系統的架構配置、元件層級詳細數據、擁有者和重要聯繫人。 不正確或過時的資訊可能會導致事件回應小組浪費寶貴的時間，找出系統作業、責任，以及事件的潛在影響。
規劃與客戶的有效溝通。 提供狀態更新是事件管理的關鍵。 狀態更新可協助您的客戶瞭解事件的本質，以及減少遇到類似問題之客戶的支援案例數量。
設計建議
| 建議 | 優點 |
|---|---|
| 提供明確的事件報告程式，例如向客戶開啟支援案例與前線支援小組。 | 您可以確保探索和回應事件的一致性，這可縮短解決時間，並防止資訊遺失或被忽略。 |
| 記錄架構配置、元件層級的詳細數據、隱私權或安全性分類、擁有者和重要聯繫人。 | 分級小組提供隨時可用的資訊，並可專注於調查和評估影響。 |
| 請確定您的事件回應小組可以存取必要的資產和系統，例如記錄。 他們也需要能夠透過安全且受控制的程式進行生產變更。 | 您可以藉由確保小組不會浪費時間，更快速地還原作業。 |
| 使用商業狀態頁面，而不是自行建置。 | 使用商業狀態頁面節省時間。 由另一個組織裝載的狀態頁面，在系統中斷期間，客戶仍可存取。 |
以有條不紊的方式管理事件
遵守定義的計劃對於避免在回應時間進行即興化至關重要。 這種方法有助於將管理這些情況的壓力和複雜度降至最低。
設計考量
指派事件嚴重性。 使用事件回應計劃來判斷事件嚴重性。 客戶在事件期間經常感到沮喪。 請務必了解他們看到的影響，以便您可以排定優先順序。 清楚傳達事件的嚴重性，讓客戶有實際的期望。
保持冷靜，清楚地思考。 事件可能是壓力和模棱兩可的，多個項目關係人要求注意。 有一個明確的程式，誰在事件中領先。 盡可能盡可能將事件分級，同時確認您可能必須處理不完善的資訊。 請嘗試繼續控制局勢。
組織領導者可協助保護正在積極調查或緩和事件的小組成員。
將狀態傳達給您的客戶。 更新狀態頁面以發佈足夠的資訊。 及時溝通並提供必要的資訊，例如預估的解決時間。 為客戶提供頻繁的更新，以維持其信任。
設計建議
| 建議 | 優點 |
|---|---|
| 在事件期間，優先於探索復原。 發生事件時，請快速設定還原作業的優先順序，以將客戶的中斷降到最低。 |
即使還不瞭解造成問題的原因，您也可以透過路由傳送受影響的元件或回復更新來復原。 |
| 在中斷期間提供及時、清楚且頻繁的更新。 | 您可以灌輸客戶信心，並減輕第一線支援小組的負擔。 |
| 在作用中事件期間指定通訊管理員。 此經理可能是單一人員，或者您可能會在事件之間輪替小組成員的責任。 | 藉由為工程小組提供一個語音，您可以集中交談，並減少對其他小組成員的干擾。 您也可以在混亂的事件期間防止衝突的資訊連絡客戶或項目關係人。 |
| 請確定您有Microsoft等廠商的任務關鍵性支持計劃。 | 如果發生中斷，您需要與平臺廠商的響應式通訊，例如Microsoft，以協助您判斷問題所在位置，以及縮短中斷持續時間。 |
進行事件後檢閱
從事件復原之後，請檢閱和分析從事件中學到的內容。 實作補救動作，包括技術變更、程序調整或更多訓練。
設計考量
從事件中學習。 中斷提供寶貴的學習機會。 在事件之後進行徹底檢閱，以找出課程並實作改進。 重大事件通常有多個原因。 評估解決方案的其他層級，例如作業程式，是否會在問題呈報之前防止或偵測到問題。 此外，在您的解決方案中尋找可能也面臨相同問題風險的類似模式。
與客戶通訊。 許多ISV提供事件後通訊，尤其是預期高品質更新的企業客戶。 透明並為客戶提供足夠的資訊，以瞭解問題和緩和步驟。 不過，若要維護安全性和完整性，請避免共用解決方案架構或元件的相關過多內部詳細數據。
設計建議
| 建議 | 優點 |
|---|---|
| 建立程式以執行內部事件後檢閱。 專注於找出造成問題的原因。 請考慮技術原因、您的程式可能對中斷造成影響的方式，以及您回應事件的方式。 |
內部事件後檢閱可協助您了解生產中斷情況，並將類似問題再次發生的風險降到最低。 |
| 制定結構化計劃，以解決任何需要補救的專案。 包括清楚的責任和時程表。 | 清楚的責任可協助您確保每個角色符合其功能期望、增強清晰性，並允許在所需的層級進行透明報告。 |
| 發佈面向客戶的事件後檢閱。 為客戶提供足夠的詳細數據，以了解問題和風險降低步驟，而不需要透露不必要的內部詳細數據或系統架構。 事件後通訊應該一律由人類撰寫和發佈。 技術和非技術項目關係人應檢閱通訊的正確性和清晰性。 |
這種方法可協助維護客戶的信心，並保證您從事件中學到並正在解決已識別的問題。 |
後續步驟
檢閱設計區域之後，請繼續進行評估工具來評估您的設計。