任務關鍵性設計方法是由五個主要設計原則所支撐，這些原則可作為關鍵設計領域的後續設計決策指南針。 強烈建議您熟悉這些原則，以進一步瞭解其影響和與不遵循相關的取捨。
可靠性
| 設計原則 | 考慮事項 |
|---|---|
| 主動/主動設計 | 若要將可用性最大化並達成區域容錯，解決方案元件應盡可能使用主動/主動部署模型分散到多個可用性區域和 Azure 區域。 |
| 爆炸半徑減少和故障隔離 | 在 Azure 之類的高度分散式超大規模雲端環境中，無法避免失敗。 藉由預期從個別元件到整個 Azure 區域的失敗以及相互關聯的影響，可以以具有復原力的方式設計和開發解決方案。 |
| 觀察應用程式健康情況 | 在影響應用程式可靠性的問題可以減輕之前，必須先偵測並了解它們。 藉由監視與已知狀況良好狀態相關的應用程式作業，即可偵測甚至預測可靠性問題，以便快速補救動作。 |
| 磁碟驅動器自動化 | 應用程式停機的主要原因之一是人為錯誤，無論是部署測試不足的軟體或設定錯誤。 若要將人為錯誤的可能性和影響降到最低，請務必努力在雲端解決方案的所有層面進行自動化，以改善可靠性：自動化測試、部署和管理。 |
| 自我修復的設計 | 自我修復描述系統能夠依靠事先定義的補救協定，自動處理與解決方案內失敗模式相關的故障。 這是一個進階的概念，需要高度的系統成熟度，配合監視和自動化，而且從一開始就應該將其作為一個目標，以最大化可靠性。 |
| 避免複雜性 | 在設計解決方案和所有作業程式以提升可靠性和管理效率時，避免不必要的複雜性，將失敗的可能性降至最低。 |
效能效率
| 設計原則 | 考慮事項 |
|---|---|
| 向外延展的設計 | 擴展是一個概念，著重於系統透過橫向擴展回應需求的能力。 這表示當流量增加時，會平行新增更多資源單位，而不是增加現有資源的大小。 系統的能力，可以透過擴展單元來處理預期和非預期的流量增加，對於整體效能和可靠性至關重要，進一步降低單一資源失敗的影響。 |
| 超大規模運算的自動化 | 整個解決方案的調整作業應該完全自動化，以將流量非預期或預期增加的效能和可用性影響降到最低，確保瞭解規模調整作業所需的時間，並與應用程式健康情況的模型一致。 |
| 持續驗證和測試 | 自動化測試應在 CI/CD 程式中執行，以推動每個應用程式變更的持續驗證。 應包含針對具有同步處理混亂實驗之效能基準的負載測試，以驗證現有的閾值、目標和假設，以及協助快速識別復原和可用性的風險。 這類測試應在預備和測試環境內進行，但也可以選擇性地在開發環境中進行。 對正式環境執行測試子集也很有幫助，特別是搭配藍綠部署模型，在接收正式流量之前先驗證新的部署標籤。 |
| 使用受控計算服務減少額外負荷 | 使用受控計算服務和容器化架構，可藉由將基礎結構部署和維護轉移至受控服務提供者，大幅減少設計、作和調整應用程式的持續系統管理及作業額外負荷。 |
| 建立基準效能並識別瓶頸 | 使用來自每個系統元件的詳細遙測進行效能測試，可讓您識別系統中的瓶頸，包括需要調整與其他元件相關的元件，而且這項資訊應併入容量模型。 |
| 模型容量 | 容量模型可協助規劃資源層級以適應特定負載配置，並顯示系統元件之間的運行關係，從而支持系統整體的容量配置規劃。 |
卓越營運
| 設計原則 | 考慮事項 |
|---|---|
| 鬆散結合的元件 | 鬆散結合可讓您獨立且隨選測試、部署和更新應用程式的元件，同時將支援、服務、資源或核准的小組間相依性降到最低。 |
| 自動化建置和發行程式 | 完全自動化的建置和發行程式可減少摩擦，並提升部署更新的速度，在環境中帶來重複性和一致性。 自動化可縮短開發人員推送變更以取得程式碼品質、測試涵蓋範圍、復原能力、安全性和效能的見解，進而提升開發人員生產力的意見反應迴圈。 |
| 開發人員靈活度 | 持續整合與持續部署 （CI/CD） 自動化可讓您使用與相關聯功能分支系結生命週期的短期開發環境，以在工程週期內儘早促進開發人員靈活度並推動驗證，以將 Bug 的工程成本降至最低。 |
| 量化作業健康情況 | 所有元件和資源的完整診斷工具使得持續觀察記錄、度量和追蹤成為可能，同時也促進健康模型化，將應用程式的健康情況量化，以滿足可用性和效能需求。 |
| 演練復原和模擬失敗 | 商務持續性（BC）和災害復原（DR）規劃和練習演練是不可或缺的，而且應該經常進行，因為學習可以反覆改善計劃和程式，以在非計劃性停機時最大化復原能力。 |
| 接受持續作業改進 | 優先處理系統與用戶體驗的例行改進，使用健康情況模型透過意見反應機制來瞭解和測量營運效率，讓應用程式小組能夠以反覆的方式了解和解決差距。 |
安全性
| 設計原則 | 考慮事項 |
|---|---|
| 監視整個解決方案的安全性，並規劃事件回應 | 將安全性和稽核事件相互關聯，以建立應用程式健康情況的模型，並識別作用中威脅。 使用安全性資訊和事件管理 （SIEM） 工具來建立自動化和手動程式，以回應事件以進行追蹤。 |
| 針對潛在威脅建立模型和測試 | 請確定適當的資源強化，並建立程式來識別和減輕已知威脅，使用滲透測試來驗證威脅風險降低，以及靜態程式代碼分析和程式代碼掃描。 |
| 識別及保護端點 | 透過安全功能和裝置 (例如防火牆或 Web 應用程式防火牆)，監控和保護內部和外部端點的網路完整性。 使用業界標準方法來防範常見的攻擊媒介，例如 Distributed 拒絕Of-Service （DDoS） 攻擊，例如 SlowLoris。 |
| 防範程式代碼層級弱點 | 識別並減輕代碼層面的漏洞，例如跨網站腳本或 SQL 注入，並將安全修補納入代碼庫的所有部分的運行週期，包括相依性。 |
| 自動化並使用最低許可權 | 推動自動化，將人類互動的需求降到最低，並跨應用程式和控制平面實作最低許可權，以防止數據外泄和惡意動作專案案例。 |
| 分類和加密數據 | 根據風險分類數據，並在待用和傳輸中套用業界標準加密，確保密鑰和憑證安全地儲存並妥善管理。 |
成本優化
引入更高的可靠性會帶來明顯的成本權衡，這應該在工作負載需求的背景下仔細考慮。
將可靠性最大化可能會影響解決方案的整體財務成本。 例如，重複資源，以及跨區域資源分佈以達到高可用性，具有明確的成本影響。 為了避免成本過高，請勿過度設計或過度配置超出商務相關需求。
此外，與基本可靠性概念相關的工程實踐投資會增加成本，包括將基礎設施視為代碼、部署自動化和測試自動化。 這在時間和精力方面都付出了代價，可以投資到別處來提供新的應用程式功能和功能。
後續步驟
設計區域是相互關聯的，因此一個區域中的變更可能會影響其他區域。 從業務最關鍵的領域開始，然後檢閱考慮和建議，以瞭解您的選擇如何跨架構建立取捨。