在任何雲端平臺上設計任務關鍵性應用程式，需要深思熟慮的工程方法。 有一些相關複雜度：瞭解平臺的功能、選取正確的服務、正確設定、有效地運作它們，並與不斷演進的最佳做法和服務藍圖保持一致。
若要流覽此複雜性，請建立清楚且簡單的設計方法，以符合您的業務需求，特別是運行時間和復原。 當決策變得具有挑戰性，或者您發現自己陷入分析癱瘓時，請回到您的方法作為參考點。 這有助於驗證您的選擇、將設計保持專注，並確保與整體目標保持一致。
本文建議一種設計方法，該方法是基於從檢閱部署於 Azure 的許多關鍵任務應用程式中獲得的見解。
針對可靠性目標進行設計
任務關鍵性對每個人來說並不一樣。 架構會因工作負載的商務需求和可接受的停機時間而有所不同。 這些通常是由服務等級目標所定義，例如99.9% 與99.999% 可用性。 請考慮可用性目標不僅僅是指運行時間。 它們代表與狀況良好的應用程式狀態相對的一致服務。 作為起點，小組應該定義可接受的停機時間。 使用正常運行時間/停機時間計算器來確定可容忍的停機時間。
此設計方法可作為設定目標之後架構決策和取捨的起點。 隨著草稿目標架構的形狀和成本和複雜度變得更清楚，初始需求可能會透過替代解決方案重新審視、挑戰、調整或解決。
例如，雖然單一區域、多區域設定可能足以滿足許多關鍵工作負載的需求，但更高的可靠性需要更多的工程工作和複雜性。 除非有強烈的需求，否則請避免優先採用複雜的解決方案，例如主動-主動多重區域架構。
RTO （復原時間目標） 和 RPO （恢復點目標） 也是定義可靠性需求的關鍵。 例如，如果您的目標是在一分鐘內復原應用程式，備份型或主動-被動策略可能不夠快。
請參閱 定義可靠性目標的建議
努力實現端對端自動化
採用涵蓋部署和進行中管理活動的完整自動化策略。 此方法強調透過自動化優先原則的一致性、可重複性和復原能力。
自動化的典型區域是例行工作，例如修補、調整和監視，以減少手動工作和錯誤。 偏好範本進行組態和部署，以確保一致性和清楚明瞭，只有在範本無法可行時，才使用腳本。
請參閱 啟用自動化的建議
零停機時間部署的設計
零停機部署可確保使用者在變更期間不會發生任何中斷。
此方法需要嚴格的發行前版本測試，讓更新不會造成瑕疵、弱點或不穩定。 若要支援此功能，部署工具和程序必須具有高可用性且具有復原性。
一致性是關鍵。 所有環境都應該使用相同的成品和自動化程式，以消除任何手動錯誤的機會，並降低整體風險。 端對端自動化不只是慣用的，而是實現可靠、可重複且無中斷部署的必要條件。
請參閱 部署和測試的建議
快速失敗偵測和復原的設計
快速失敗偵測會從定義完善的健全狀況模型開始。 由於故障通常會在元件之間串聯，因此早期偵測和工作負載元件之間的明確相依性對於最小化爆炸半徑和加速復原是不可協商的。
根據實際使用者流量以及效能和可用性的商業標準，清楚識別出每個元件看起來何為健康及不健康。 這些定義應引導您監視的計量，並協助追蹤問題回到其根本原因。
請參閱 健康情況模型化的設計指南
使用 Azure 演進
將架構設計為模組化且具有彈性，因此無須進行重大變更，就能更輕鬆地採用新功能。 定期檢閱您的設計，以掌握 Azure 不斷演進的服務與功能。 排定 Azure 原生受控服務優先順序，以降低作業額外負荷和更佳的整合。 由於 Azure 經常更新，因此將您的架構與其藍圖一致，有助於確保您的應用程式保持優化且未來就緒。
如需有關新服務和功能的最新資訊，請參閱Evolve with Azure和Azure 更新。
後續步驟
開始您的設計旅程，先檢閱 Well-Architected Framework 的支柱如何應用於任務關鍵類型的工作負載。
設計區域是相互關聯的，因此一個區域中的變更可能會影響其他區域。 從業務最關鍵的領域開始，然後檢閱考慮和建議，以瞭解您的選擇如何跨架構建立取捨。