本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 階段 4：操作
<a name="stage-4"></a>

您已建置彈性應用程式並對其進行測試。現在，每日現實正在保持執行狀態。但是在啟動時，您無法監看所有操作，也不應該嘗試。關鍵是保持對重要事項的提醒，而不會提供太多指標或讓團隊負擔過重。

從客戶的觀點開始。[Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) Canary 充當自動化客戶。他們會持續測試重要的使用者旅程。讓他們登入、使用測試帳戶模擬購買，或存取金鑰功能，尤其是在繁忙的時段。這可協助您了解客戶體驗，並協助您在實際使用者之前發現問題。當 Canary 失敗時，您立即知道從客戶的角度來看，發生錯誤。

在此基礎上建置，並專注於監控支援基礎設施。哪些訊號告訴您有問題？ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 可協助您建置追蹤這些跡象的儀表板。不只是監控技術指標，還要將這些指標與業務影響相關聯。例如，高 CPU 用量很重要，但這可能會降低您使用 Canary 追蹤的客戶體驗。

做為實際的方法，請將您的監控映射至您的客戶旅程。如果您執行軟體即服務 (SaaS) 平台，您可能會關心 API 回應時間、身分驗證成功率和核心功能可用性。設定提醒，告知您這些指標何時偏離。不過，請選擇性。每個提醒都應要求採取動作。如果您的團隊因為「可能什麼都不做」而開始忽略提醒，表示您已設定太多或正在追蹤錯誤的指標。

透過您的團隊已使用的工具路由這些提醒。如果您的工程師住在特定的簡訊應用程式中，請在該處傳送提醒。目標是在不建立新程序的情況下快速感知。當警示觸發時，您的團隊應該確切知道它意味著什麼，以及如何處理它。

保持營運文件精簡且實用。在版本控制中存放具有程式碼的 Runbook，但請記住它們不是小說。當某件事休息時，您的團隊需要明確、可行的步驟。每個提醒都應連結到對應的 Runbook，而且每個 Runbook 應回答三個問題：
+ 什麼會中斷？
+ 它為什麼重要？
+ 我該如何修正這個問題？

實作簡單的事件管理程序。您不需要複雜的架構，只需明確定義什麼構成事件，以及在情況升級時呼叫誰即可。保留事件日誌，因為它們可協助您改善應用程式的彈性。

關鍵在於尋找警示和額外負荷之間的甜甜點。使用 AWS 工具來自動化您可以執行的作業、專注於監控影響客戶的指標，並讓您的程序保持足夠光線，以隨著您的成長而演進。

下一章探討如何培養彈性思維，而不犧牲讓新創公司變得特別的速度和創新。在一天結束時，彈性與人們的彈性一樣多。