任務關鍵性工作負載的設計原則
任務關鍵性設計方法是由五個主要設計原則所支援，這些原則可作為跨重要設計領域的後續設計決策指南針。 強烈建議您熟悉這些原則，以進一步瞭解其影響與不符合規範相關聯的取捨。
重要
本文是 Azure Well-Architected 任務關鍵性工作負載 系列的一部分。 如果您不熟悉此系列，建議您從 什麼是任務關鍵性工作負載開始？
這些任務關鍵性設計原則會產生並擴充 Azure Well-Architected 架構的品質要素：可靠性、 安全性、 成本優化、 營運卓越和 效能效率。
可靠性
最大可靠性 - 最可靠解決方案的基本原理，確保正確瞭解取捨。
| 設計原則 | 考量事項 |
|---|---|
| 主動/主動設計 | 若要將可用性最大化並達到區域容錯，解決方案元件應該盡可能分散到多個可用性區域和 Azure 區域，並盡可能使用主動/主動部署模型。 |
| 擷取半徑縮小和錯誤隔離 | 無法避免在高度分散的多租使用者雲端環境中發生失敗，例如 Azure。 藉由預期失敗和相互關聯的影響，從個別元件到整個 Azure 區域，即可以復原的方式設計及開發解決方案。 |
| 觀察應用程式健康狀態 | 在影響應用程式可靠性的問題可以減輕之前，必須先偵測並瞭解它們。 藉由監視相對於已知狀況良好狀態的應用程式作業，即可偵測或甚至預測可靠性問題，以快速補救動作。 |
| 推動自動化 | 應用程式停機的其中一個主要原因是人為錯誤，無論是因為部署測試不足的軟體或設定錯誤。 若要將人為錯誤的可能性和影響降到最低，請務必努力在雲端解決方案的所有層面進行自動化，以改善可靠性;自動化測試、部署和管理。 |
| 針對自我修復設計 | 自我修復描述系統透過連線到解決方案內失敗模式的預先定義補救通訊協定自動處理失敗的能力。 這是一種進階概念，需要具有監視和自動化的高階系統成熟度，但應該是從頭開始到最大化可靠性的目標。 |
| 複雜性避免 | 在設計解決方案和所有作業程式以提升可靠性和管理效率時避免不必要的複雜度，將失敗的可能性降到最低。 |
效能效率
永續性效能和延展性 - 設計跨端對端解決方案的延展性，而不會有效能瓶頸。
| 設計原則 | 考量事項 |
|---|---|
| 針對向外擴充設計 | 向外延展是一個概念，著重于系統透過水準成長回應需求的能力。 這表示隨著流量成長，會平行新增更多資源單位，而不是增加現有資源的大小。 透過縮放單位處理預期和非預期流量的系統能力，對於整體效能和可靠性而言非常重要，方法是進一步減少單一資源失敗的影響。 |
| 超大規模資料庫的自動化 | 整個解決方案中的調整作業應該完全自動化，以將非預期或預期流量的效能和可用性影響降到最低，確保瞭解調整作業所需的時間，並符合應用程式健康情況的模型。 |
| 持續驗證和測試 | 自動化測試應在 CI/CD 程式中執行，以推動每個應用程式變更的持續驗證。 針對具有同步式混亂實驗的效能基準進行負載測試，應該包含以驗證現有的臨界值、目標和假設，以及協助快速識別復原和可用性的風險。 這類測試應在預備和測試環境中進行，但也可以選擇性地在開發環境中進行。 對生產環境執行測試子集也很有説明，特別是與藍色/綠色部署模型搭配使用，以在接收生產流量之前驗證新的部署戳記。 |
| 使用受控計算服務減少額外負荷 | 使用受控計算服務和容器化架構可大幅減少設計、操作和調整應用程式的持續管理與操作額外負荷，方法是將基礎結構部署和維護轉移至受控服務提供者。 |
| 基準效能並識別瓶頸 | 使用來自每個系統元件的詳細遙測進行效能測試，可識別系統中的瓶頸，包括需要調整與其他元件相關的元件，而且這項資訊應該併入容量模型中。 |
| 模型容量 | 容量模型可針對指定的負載設定檔規劃資源規模層級，並另外公開系統元件彼此之間的關聯性，因此啟用全系統的容量配置規劃。 |
卓越營運
依設計進行作業 - 設計為持續執行強固且具判斷性的作業管理。
| 設計原則 | 考量事項 |
|---|---|
| 鬆散結合的元件 | 鬆散結合可讓您獨立且隨選測試、部署和更新應用程式的元件，同時將支援、服務、資源或核准的小組間相依性降至最低。 |
| 自動化建置和發行程式 | 完全自動化的建置和發行程式可減少衝突，並增加部署更新的速度，使環境具有可重複性和一致性。 自動化可縮短開發人員推送變更的意見反應迴圈，以取得程式碼品質、測試涵蓋範圍、復原、安全性和效能的深入解析，進而提升開發人員生產力。 |
| 開發人員靈活度 | 持續整合和持續部署 (CI/CD) 自動化可讓短期開發環境與相關聯功能分支的生命週期搭配使用，以在工程週期內儘快提升開發人員靈活度並推動驗證，以將 Bug 的工程成本降到最低。 |
| 量化作業健康情況 | 所有元件和資源的完整診斷檢測可讓您持續觀察記錄、計量和追蹤，但也有助於健康情況模型化，將內容中的應用程式健康情況量化為可用性和效能需求。 |
| 排練復原和練習失敗 | 商務持續性 (BC) 和災害復原 (DR) 規劃和練習演練很重要，因此應該經常進行，因為學習可以反復改善計畫與程式，以在非計劃性停機時最大化復原能力。 |
| 採用持續作業改進 | 使用健康情況模型，透過意見反應機制來優先改善系統和使用者體驗的例行性改善，讓應用程式小組以反復的方式瞭解和解決差距。 |
安全性
一律安全 - 設計端對端安全性，以維護應用程式穩定性並確保可用性。
| 設計原則 | 考量事項 |
|---|---|
| 監視整個解決方案的安全性，並規劃事件回應 | 將安全性和稽核事件相互關聯，以建立應用程式健康情況的模型，並識別作用中的威脅。 使用安全性資訊和事件管理建立自動化和手動程式， (SIEM) 工具來追蹤事件。 |
| 針對潛在威脅建立模型和測試 | 確定適當的資源強化和建立程式，以識別及減輕已知威脅，使用滲透測試來驗證威脅防護，以及靜態程式碼分析和程式碼掃描。 |
| 識別及保護端點 | 透過安全性功能和設備，監視及保護內部和外部端點的網路完整性，例如防火牆或 Web 應用程式防火牆。 使用業界標準方法來防範常見的攻擊媒介，例如分散式阻斷服務 (DDoS) 攻擊，例如 SlowLoris。 |
| 防範程式碼層級弱點 | 識別並減輕程式碼層級弱點，例如跨網站腳本或 SQL 插入，並將安全性修補納入程式碼基底的所有部分的作業生命週期，包括相依性。 |
| 自動化並使用最低權限 | 推動自動化，以將人為互動的需求降到最低，並跨應用程式和控制平面實作最低許可權，以防止資料外泄和惡意執行者案例。 |
| 分類和加密資料 | 根據風險分類資料，並套用待用和傳輸中的業界標準加密，確保金鑰和憑證會安全地儲存並正確管理。 |
成本最佳化
在工作負載需求的內容中，有明顯的成本取捨與引進更高的可靠性相關，這應該仔細考慮。
將可靠性最大化可能會影響解決方案的整體財務成本。 例如，資源重複以及跨區域的資源分佈，以達到高可用性，具有明確的成本影響。 若要避免過度成本，請不要過度工程師或過度布建，而超出相關的業務需求。
此外，在基本可靠性概念中新增了與工程投資相關聯的成本，例如採用基礎結構即程式碼、部署自動化和混亂工程。 這在時間和精力方面都會有成本，可以投資到其他位置來提供新的應用程式功能和功能。
雲端原生設計
Azure 原生受控服務 - Azure 原生受控服務 會優先處理，因為其系統管理與作業額外負荷較低，以及與應用程式堆疊上一致的組態和檢測緊密整合。
藍圖對齊 - 納入即將推出的全新和改良 Azure 服務功能，因為它們成為正式運作 (GA) ，以保持接近 Azure 的前置邊緣。
採用預覽功能並減輕已知差距 - 雖然正式推出 (GA) 服務會優先支援，但 Azure 服務預覽會主動探索快速整合，為 Azure 產品群組提供技術和可採取動作的意見反應，以解決差距。
Azure 登陸區域對齊 - 可在 Azure 登陸區域內 部署，並符合 Azure 登陸區域設計方法，但也可在登陸區域外部的裸機環境中完整運作且可部署。
後續步驟
檢閱與任務關鍵性工作負載相關聯的跨領域考慮。