在無伺服器架構下，服務追蹤對於理解應用程式行為至關重要。透過儀表化與註解，我們可以收集追蹤資料，並利用 X-Ray 服務進行視覺化分析，找出效能瓶頸。同時，錯誤預算和容錯設計也是確保應用程式穩定性的關鍵。錯誤預算允許一定程度的錯誤發生，並引導工程團隊在穩定性和交付速度之間取得平衡。容錯設計則透過重試機制、死信佇列和事件儲存等方法，讓應用程式即使在部分服務故障時也能維持正常運作。此外，理解暫時性錯誤和永久性錯誤的差異，並針對不同錯誤型別採取相應的處理策略，才能有效提升系統的可靠性。最後，DynamoDB 的全球表和點時還原功能則提供資料層級的容錯能力，確保資料安全和服務的持續性。
啟用服務追蹤
要啟用服務追蹤，您需要關注兩個主要方面：儀表化和註解。儀表化是指組態微服務和管理服務以發出追蹤資料，而註解是指新增鍵值對以提供額外的上下文資訊。
儀表化
儀表化是指組態您的應用程式以發出追蹤資料。這可以透過組態資源和附加 IAM 政策到角色來實作。例如，要啟用 Step Functions 工作流程的追蹤，您需要在 CloudFormation 範本中包含以下組態：
{
"Type": "AWS::StepFunctions::StateMachine",
"Properties": {
"TracingConfiguration": {
"Enabled": true
}
}
}
您還需要附加一個 IAM 政策到角色，以允許發出追蹤資料。
註解
註解是指新增鍵值對以提供額外的上下文資訊。註解可以被索引，允許您根據註解資料過濾和分組追蹤資料。
使用 X-Ray 服務
X-Ray 服務是一種完全託管的服務，可以幫助您收集、分析和視覺化您的應用程式的追蹤資料。X-Ray 服務的使用是根據收集和檢索的追蹤數量來計費的。免費層包括 100,000 個追蹤和 1,000,000 次檢索。
如果您生成和分析的大量追蹤數量超出了免費層，您應該設定一個取樣率，以控制成本。X-Ray 服務使用您的取樣率來決定記錄請求的百分比。例如，您可能會考慮在啟動新服務時使用 100% 的取樣率，以捕捉盡可能多的資料。隨著您對服務行為有了更好的理解，您可以減少取樣率，以節省成本。
圖表翻譯：
graph LR
A[啟用服務追蹤] --> B[儀表化]
B --> C[增加註解]
C --> D[收集和分析追蹤資料]
D --> E[視覺化和最佳化]
以上圖表展示了啟用服務追蹤的流程，從儀表化和增加註解開始，然後收集和分析追蹤資料，最終視覺化和最佳化應用程式的效能。
服務無伺服器營運：錯誤預算和容錯設計
在無伺服器應用中，錯誤預算和容錯設計是兩個非常重要的概念。錯誤預算是指允許在特定時間內發生的錯誤數量，而容錯設計則是指設計系統以便在發生錯誤時仍能正常運作。
錯誤預算
錯誤預算是指允許在特定時間內發生的錯誤數量。例如，一個 API 端點可能有 5% 的錯誤預算，這意味著如果 API 端點傳回的 5xx 錯誤數量超過所有回應的 5%，則錯誤預算將被完全使用。
錯誤預算可以用來給工程團隊釋放 Bug 到生產環境的許可。正如我們在第 6 章和第 7 章中所看到的，穩定性和交付速度之間的平衡對於維持一個強大且有用的應用程式至關重要。工程師必須有能力安全地交付程式碼，而不會被減慢。
容錯設計
容錯設計是指設計系統以便在發生錯誤時仍能正常運作。這包括編寫清晰、可維護和可除錯的程式碼，仔細分離業務邏輯和 AWS 管理服務，保持 Lambda 函式和 Step Functions 工作流程簡單，並利用服務整合。
在無伺服器應用中，容錯設計非常重要，因為它可以幫助您從故障中還原。透過設計容錯系統，您可以確保您的應用程式即使在發生錯誤時也能正常運作。
兩種型別的故障
有兩種型別的故障：可預測的故障和不可預測的故障。可預測的故障是指那些可以預測和防止的故障，例如網路連線失敗或資料函式庫查詢失敗。不可預測的故障是指那些不能預測和防止的故障，例如硬體失敗或軟體 Bug。
內容解密：
上述內容介紹了無伺服器營運中的錯誤預算和容錯設計概念。錯誤預算是指允許在特定時間內發生的錯誤數量，而容錯設計則是指設計系統以便在發生錯誤時仍能正常運作。透過設定錯誤預算和設計容錯系統，您可以確保您的應用程式即使在發生錯誤時也能正常運作。
圖表翻譯：
graph LR
A[錯誤預算] --> B[容錯設計]
B --> C[系統設計]
C --> D[業務邏輯]
D --> E[AWS 管理服務]
E --> F[Lambda 函式]
F --> G[Step Functions 工作流程]
G --> H[服務整合]
H --> I[容錯系統]
I --> J[故障還原]
上述圖表展示了無伺服器營運中的錯誤預算、容錯設計和系統設計之間的關係。透過設定錯誤預算和設計容錯系統，您可以確保您的應用程式即使在發生錯誤時也能正常運作。
瞭解暫時性與永久性錯誤
在設計可靠的系統時，瞭解暫時性錯誤（Transient Faults）和永久性錯誤（Permanent Faults）是非常重要的。暫時性錯誤通常可以透過重試機制自動還原，例如第三方服務暫時停機或網路連線問題。另一方面，永久性錯誤則是指在重試機制失敗後仍然存在的錯誤，需要人工干預或自動重新處理。
自動重試機制
許多AWS管理服務和SDK函式庫提供了內建的機制來幫助應用程式從故障中還原。例如，AWS SDK允許組態最大重試次數和退避率。Step Functions和EventBridge也提供了類別似的功能。
死信佇列和事件儲存
為了處理永久性錯誤，死信佇列（Dead Letter Queue）可以用於儲存無法送達的事件，以便於後續的手動或自動重試。事件儲存（Event Archive）也可以用於儲存事件，以便於後續的重放。
DynamoDB的全球表和點時還原
DynamoDB提供了全球表（Global Tables）和點時還原（Point-in-Time Recovery）功能，可以用於還原表格資料在意外操作後的狀態。啟用刪除保護設定可以防止意外刪除表格。
從系統穩定性與業務連續性角度來看，建構具備容錯能力的無伺服器應用至關重要。本文深入探討了從服務追蹤的啟用、X-Ray 的運用，到錯誤預算及容錯設計的實踐，層層遞進地闡述如何提升系統的可靠性。分析了暫時性錯誤和永久性錯誤的區別，並提出了相應的處理策略，如自動重試機制、死信佇列以及 DynamoDB 的全球表和點時還原功能。然而，單純依靠工具和機制並不足以確保系統的萬無一失。技術團隊還需關注錯誤預算的設定與執行，並將容錯設計的理念融入系統架構的每個環節，才能真正構建出高韌性的無伺服器應用。展望未來，隨著無伺服器技術的持續發展，更精細化的錯誤處理和自動化還原機制將成為關注焦點，進一步提升系統的穩定性和可靠性。玄貓認為，主動預防和自動化處理錯誤，而非僅僅依賴事後補救，才是建構真正健壯的無伺服器應用的關鍵所在。
