本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
階段 4:操作
您已建置彈性應用程式並對其進行測試。現在,每日現實正在保持執行狀態。但是在啟動時,您無法監看所有操作,也不應該嘗試。關鍵是保持對重要事項的提醒,而不會提供太多指標或讓團隊負擔過重。
從客戶的觀點開始。Amazon CloudWatch Synthetics Canary 充當自動化客戶。他們會持續測試重要的使用者旅程。讓他們登入、使用測試帳戶模擬購買,或存取金鑰功能,尤其是在繁忙的時段。這可協助您了解客戶體驗,並協助您在實際使用者之前發現問題。當 Canary 失敗時,您立即知道從客戶的角度來看,發生錯誤。
在此基礎上建置,並專注於監控支援基礎設施。哪些訊號告訴您有問題? Amazon CloudWatch 可協助您建置追蹤這些跡象的儀表板。不只是監控技術指標,還要將這些指標與業務影響相關聯。例如,高 CPU 用量很重要,但這可能會降低您使用 Canary 追蹤的客戶體驗。
做為實際的方法,請將您的監控映射至您的客戶旅程。如果您執行軟體即服務 (SaaS) 平台,您可能會關心 API 回應時間、身分驗證成功率和核心功能可用性。設定提醒,告知您這些指標何時偏離。不過,請選擇性。每個提醒都應要求採取動作。如果您的團隊因為「可能什麼都不做」而開始忽略提醒,表示您已設定太多或正在追蹤錯誤的指標。
透過您的團隊已使用的工具路由這些提醒。如果您的工程師住在特定的簡訊應用程式中,請在該處傳送提醒。目標是在不建立新程序的情況下快速感知。當警示觸發時,您的團隊應該確切知道它意味著什麼,以及如何處理它。
保持營運文件精簡且實用。在版本控制中存放具有程式碼的 Runbook,但請記住它們不是小說。當某件事休息時,您的團隊需要明確、可行的步驟。每個提醒都應連結到對應的 Runbook,而且每個 Runbook 應回答三個問題:
-
什麼會中斷?
-
它為什麼重要?
-
我該如何修正這個問題?
實作簡單的事件管理程序。您不需要複雜的架構,只需明確定義什麼構成事件,以及在情況升級時呼叫誰即可。保留事件日誌,因為它們可協助您改善應用程式的彈性。
關鍵在於尋找警示和額外負荷之間的甜甜點。使用 AWS 工具來自動化您可以執行的作業、專注於監控影響客戶的指標,並讓您的程序保持足夠光線,以隨著您的成長而演進。
下一章探討如何培養彈性思維,而不犧牲讓新創公司變得特別的速度和創新。在一天結束時,彈性與人們的彈性一樣多。