營運卓越設計原則

營運卓越支柱的核心是 DevOps 做法， 可透過標準化的工作流程和小組凝聚力來確保工作負載品質。 此要素會定義 開發實務、可觀察性和發行管理的作業程式。 目標是將程序變異數、人為錯誤的機會和客戶中斷降到最低。 若要評估您的作業健康情況，請從下列問題開始進行：

• 您是否運用專業領域執行作業？
• 客戶使用的工作負載是否具有最大可預測性？
• 如何從經驗和收集到的資料中學習，以推動持續改善？

當沒有明確的擁有權或領導權時，工作負載作業可能會淪為混亂的做法。 在此類型的環境中，小組通常會訴諸以高度付出執行但產生低度結果的方法，這會導致使用者體驗不佳。 這些方法僅符合短期目標。 長期效益是透過 持續評估和戰略投資實現的。

設計原則提供作策略的指導方針，這些策略必須考慮 以因應根本原因，而不只是治療癥狀。 從建議的方法開始，然後觀察哪些有效、哪些無效，以識別需要改進的領域。 設定策略之後，請使用 卓越營運檢查清單繼續推動動作。

工作負載的作業需求與其業務需求一樣重要。 有效率的流程可確保工作負載在合規性限制內達成業務成果，無論是組織内還是外部合規性。 關鍵是找到有一致性的可重複性。

卓越營運支柱的目標是 做正確的事，以正確的方式做，並解決正確的問題作為一個團隊。

如果您達到這些目標，即使在變革期間，工作負載仍能可靠且可預測地執行。 無法滿足作業需求可能會導致部署失敗、用戶體驗不一致，以及可透過適當規劃和簡化執行而避免的成本。

採用 DevOps 文化

讓開發和營運小組能夠透過共同作業、共同責任和擁有權的心態合作，持續改善其系統設計和程式。

DevOps 是一個實踐社群，其中觀點和技能的多樣性推動著一項任務。 Teams 必須 培養共用知識的共同作業環境 ，而不是孤立的學習環境。 使用共用功能來努力克服資源限制。

良好的 DevOps 文化特性會在共同責任中茁壯成長。 開發和營運小組應將其目標和優先順序與客戶的期望保持一致，並牢記業務重點。 開發小組應該讓營運小組參與意見反應迴圈，讓改善能同樣地推動上游且其他小組能夠受益。 相反地，營運小組會負責藉由共用與工作負載相關的資源和意見反應，讓開發小組在業務成果中獲得成功。

同時，DevOps 做法 會將清楚的擁有權和責任線套用至每個小組。 無論應用程式執行的位置為何，工作負載小組都會負責該應用程式。

DevOps 會將作業工作最佳化，使其有效但不會造成負擔。 為了獲得 DevOps 的完整效益，文化特性應該透過技術最佳化流程，並讓組織中的人員能夠透過流程促進透明通訊。

方法	優點
使用可促進共同作業環境的常見系統和工具進行通訊和追蹤進度。	常見的工具和程式可啟用 透明通訊。 開發和營運小組都受益於各種環境的情境感知、常見的支援問題，以及整體挑戰和勝利。 小組已熟悉發生事件時現有的呈報路徑。 共用待辦項目會明確指出處理新功能或修正 Bug 等作業的優先順序。
在整個開發週期中建立 持續學習和實驗思維 。 支援跨小組共用知識，並維護檔以供重複使用。 進行無責任分析，及/或彙報發布後和事故後回顧。	透過 A/B 測試和開發概念證明等實驗機制，您可以鼓勵創新，同時降低成本。 透過共同作業分享知識，讓小組熟悉設計方法、工具和流程。 在項目之後進行回顧有助於 識別改進和 慶祝成功的領域。
採用經過實證的產業敏捷式做法 ，專注於動作優化。 尋找在作業中 「左移」的機會，無論是針對手動和自動化程序、部署和品質保證實務，還是提升可觀察性。	敏捷式開發實務會導致發行生命週期較短，這是商業價值指標。 偵測、解決及避免先前的問題，通常較不干擾程式。
設定所有開發和作業程序的標準，並定期檢閱和驗證。 這些程序包括例行工作、頻外程序、緊急演練和情況、工具選擇、監視程序、技能計劃，甚至是與專案關係人和客戶揭露的通訊。 對於您的決定要有意圖且清楚明確。	標準可增加作業的可預測性，並讓流程和做法可調整。 驗證標準是指出改進點的絕佳方式。 定期進行演習，為緊急和復原情況做好準備。 使用精確度執行並啟用治理， 以防止 導致風險的異常。
利用具有專業技能和豐富經驗的集中式作業小組。	針對作業和資源使用共用資源具有成本效益。 雖然您擁有工作負載，但集中式小組可協助您運用跨功能技能，例如事件管理、主動監視觀點，以及信任外包專業知識。

建立開發標準

藉由標準化開發做法、強制執行品質大門，以及透過系統性變更管理追蹤進度和成功，將生產力優化。

開發團隊負責在發行前，以最少的摩擦解決工作負載問題。 請留意開發人員的效率，並 針對快速轉換週期進行優化，從程式代碼撰寫到測試結果。 實作有效且大小正確的流程，以規劃和標準化技術活動，並推動團隊和專案關係人之間的共識。

方法	優點
描述工作負載功能 並擷取客戶收益。 衍生 架構的範圍和詳細的功能和非功能需求 。 建立大小估計模型 ，以報告涉及之工作的範圍和成本。	良好的規格可藉由支援更具生產力且簡化的開發週期， 來降低營運成本和失敗的機會 。 開發人員在開始撰寫程式代碼週期之前，先瞭解 技術設計、目標和完成準則 。 良好的文件有助於新小組成員的可重複 溝通 和 上線 。
使用 業界標準軟體開發方法， 針對工作負載和小組大小的需求進行適當調整。 維護所有角色之間共用的待辦專案。	採用已知的方法 會設定項目的節奏。 它透過為團隊成員提供明確的期望和責任來消除流程的模糊性。 藉由根據一般清單進行追蹤，即可使用標準做法 來精簡工作並排定優先順序 。 該專案將有更大機會按時交付。 標準方法有助於 風險管理。 透過細微的里程碑檢閱，開發人員可以在成為攪局者之前解決潛在問題。
針對所有程式代碼、腳本、部署範本、管線定義和相關文件使用統一的原始檔控制。 分支策略必須支持獨立且相互依存的功能、程序錯誤修正和緊急修補的順暢釋放。 使用整個組織的共享知識來建置分支策略和部署程式。	正確使用原始檔控制對於支援 並行變更 和版本控制至關重要。 維持可重複的工作流程來管理不同大小和風險的變更，並在過程中進行同儕審核，以及保留稽核記錄。
具有強調在開發生命週期早期進行測試的質量保證流程。 包含計劃性測試程式的所有成品，包括屬於功能發行或更新一部分的應用程式元件、基礎結構和數據平面作業。 當成品在環境中升級時，將其視為不可變的，每次通過品質把關都能更有信心。 在實用的情況下，自動化例行檢查。	品質保證可確保功能和非功能需求都得到滿足，從而對客戶產生積極的影響。 擁有測試計劃可確保品質和完整性，並考慮可能的失敗案例。 透過品質閘道，您可以強制執行最佳做法來降低風險。 不變性帶來信心，因為它可確保您測試的系統完全是您發行的內容。 除非符合品質準則，否則測試週期會有效率地封鎖進度。
使用 樣式指南和工具來推動一致性，以強制執行 慣例，並採用 一般工具鏈 來開發、測試和與專案關係人通訊。 開發人員的技術標準應該 需要實 作模式、API 設計、 記錄、例外狀況處理和其他程式。	程序代碼中的一致性可讓可讀性更容易維護。 它也會降低複雜性，並啟用程式代碼重複使用。 常見的工具和慣例也可協助小組將程序優化，而不需要解決一次性選擇。
一致且故意地堅持在撰寫程式碼時進行開發者文件的整理。	清除程式代碼檔可確保在需要重新瀏覽舊程式代碼或開發小組輪替時，可以輕鬆地了解邏輯和功能。
報告測量效率的進度和趨勢 。	錯誤、失敗更新、部署時間、意見反應迴圈和其他計量的趨勢已發佈，並推動改善。

透過可檢視性改善作業

取得系統可見性、獲得洞察力，並做出數據驅動的決策。

建構一個文化，透過監控工作負載並考慮 Azure Well-Architected Framework 的所有支柱，不斷改善品質。 藉由提供必要的數據、統計數據和趨勢，讓小組和專案關係人能夠跨許多面向做出短期和長期決策。 從您的數據中學習並推動改善。

基於可觀察性目的而建置的作業，是主動維護應用程式、品質和安全性保證、容量規劃和產品管理的關鍵。

監視的重要層面是 使用健康模型幫助您在問題成為事件並影響客戶體驗之前預測問題 。 有效率的監視可減少在事件管理上花費的響應迴圈。

方法	優點
使用自己的堆疊和流程建置監視系統。 將監視系統視為與其公用程序分離的工作負載維度。 堆疊必須涵蓋所有層級，包括基礎結構、應用程式健康情況，以及建置和發行程式。 擷取或取樣商務數據 的範圍不足，無法進行可觀察性實作。	將監視和工作負載堆疊分離，以 分隔功能需求和可觀察性需求 ，並讓獨立演進成為可能。 程序代碼中的變更不應影響監視，反之亦然。 由於可觀察性需求與功能需求不同，因此不會因為監視設定變更或中斷而中斷商務數據。
在每種數據來源類型的收集過程中建立一致性。 使用遙測業界標準、基礎結構計量集合和工具，在程式代碼中標準化檢測。	一致性可防止感知和測量的差異，因為類似資源之間的熟悉可 減少相互關聯和分析數據所花費的時間。 您有一個整體的觀點來預測問題。
從應用程式程式代碼發出遙測，以將執行流程的關鍵點相互關聯，並提供不同層級數據粒度的端對端檢視。	根據嚴重性層級排定動作的優先順序，並理解冗長內容的背景。 這項信息對於疑難解答而言非常重要。
擁有發出和收集數據的責任，即使數據接收是由多個小組共用，並由中央小組管理。	藉由將監視數據當地語系化至工作負載環境，小組可以存取記錄和計量來解決工作負載問題。
收集 足夠的數據 ，並保留 足夠的時間。 請考慮與記錄和儲存數據相關聯的成本取捨。	刻意數據收集可協助您將與收集更多數據相關的 財務和營運成本優化 。 將雜訊降到最低，避免在分析期間進行密集計算 ，並降低儲存不再需要之數據的成本。
區分不同的監視訊號：配置檔、記錄、計量和追蹤。 請針對正確的用途使用每個訊號。 優先考慮使用計量來啟動依賴數值測量的行動。 使用 配置檔在系統中取得較低層級的可見性，例如記憶體配置。 有限地使用記錄和追蹤，以提供流程和相依性的背景。	藉由將訊號用於正確的用途，您可以防止監視系統的實作效率不佳。 例如，針對動作使用記錄需要解析。 您可以使用計量更快達成相同的目標。
在儀錶板中匯總和可視化數據，以便展示針對觀眾的監控數據，同時考慮商業背景。 使用 案例儀錶板 來呈現數據，以推動專案關係人之間的認知。 針對事件回應等操作員活動，使用具有深入鑽研功能的操作儀錶板和工作簿。 經常重新整理儀錶板並提供細微的數據。	透過視覺效果，您可以分析趨勢、追蹤商務目標，以及管理事件。 專為客戶興趣量身定制的儀表板能使解讀更具相關性，並加速偵測和採取行動的時間。
使用標準化描述和嚴重性層級來通知責任角色，讓警示成為可採取動作。 提供從各種來源定序的資訊，並追蹤與商務目標的偏差。 僅針對需要動作的事件觸發警示。 爭取主動式和引發思考的警示，在降級狀態變成失敗之前發起行動。	警示會提醒組織所定義的重要事件。 良好的警示系統可識別動作和嚴重性，並提供足夠的數據來提升清晰度和目的。 操作員可以立即開始補救工作，而不會有任何延遲。

自動化以提高效率

以軟體自動化取代重複的手動工作 ，以更快的速度完成這些工作，以更高的一致性和精確度，並降低風險。

工作負載可能具有涉及小組成員進行乏味、重複且耗時的工作，而不需要人類智力的工作流程。 視頻率而定，您可能會花費相當長的時間進行這些工作，並在工作負載成長時投入更多時間。 此外，由於人為輸入，這些流程通常容易出錯。

透過自動化，您可以節省時間、精力和金錢，並避免錯誤。

方法	優點
以符合適當的複雜度層級、投入程度、頻率、精確度、時效性和生命週期的準則，評估所有工作流程。 根據該評估，自動化工作流程，並優先安排具有最高預期收益的工作流程。 拿掉備援工作流程 或增加價值，以證明人力投入。	您可以將團隊容量重新投入更高的價值工作，並提升生產力和一致性。 建置工作流程清查可確保您將正確的工作自動化。 拿掉備援工作可減少複雜度和錯誤。
當您評估是否 要建置自定義工具或購買軟體時，請明確說明您的決策。 將樓宇自動化保留於高度特化和高價值的工作中。	藉由購買現成的軟體並利用支援合約，您可以節省維護成本。 藉由開發軟體，您可以擁有更多控制權，並滿足您的團隊和工作負載中的獨特使用案例。 不過，會產生成本影響。 選擇工具可讓您的作業達到標準化水準。 透過訓練，您可以達到準備就緒的統一水平以利採用。
設計工作負載元件以支援 自動化功能。	避免系統設計中缺乏自動化的情況可促進重複性工作的反模式、減緩成長，並開始累積技術債務。
將所有 自動化視為工作負載的重要相依性 。 適應工作負載的預期成長。 您的自動化工具是工作負載不可或缺的一部分，而且它應該遵守五個 Well-Architected Framework 要素。	將您的自動化元件設計為能承受風險，例如安全性威脅。 透過套用的最佳做法，您可以避免實作蔓延。 如果此相依性保持運作且安全，工作負載會繼續以高階保證運作。
藉由探索超越工作負載的更多選項，實現大規模自動化。 藉由提供範本和架構來讓新項目上線，並提升現有設計和實作的重複使用，來偏好「設計一次，隨處執行」模型。	採用經過嘗試和測試的方法，並減少失敗的機會。

採用安全部署做法

使用可降低錯誤和非預期狀況效果的護欄，在部署中達到一致性。

建置自動化和模組化的工作負載供應鏈，以確保在所有環境中一致、可預測且可重複的部署。 儘早套用安全作法能確保生產環境的信心，並且如果問題影響到客戶時能夠迅速恢復。

所有變更，無論是程式代碼、組態或成品，都必須以相同層級的嚴格性進行部署。 測試、監視和版本控制是達成一致性的常見做法。

方法	優點
使用基礎結構即程序代碼 （IaC） 來定義所有基礎結構的預期狀態。 使用模組化和分層的方法，但避免不必要的抽象概念。 讓圖層符合生命週期需求，讓基礎層保持穩定。	IaC 可啟用部署自動化和一致性，並做為可用於追蹤的自我檔。 IaC 成品會融入您的軟體開發生命週期，從而啟用測試和品質審查流程。 IaC 也有助於偵測和減輕設定漂移。
偏好小型、累加式的更新，並且經常部署。	較小的更新可藉由減少並行錯誤數目來簡化驗證。 同時釋放多個瑕疵變更時，可能會大幅增加爆破半徑。
在所有環境中使用 自動化管線 來部署每個程式代碼和基礎結構變更。	一致的部署方法可減少錯誤和差異，讓部署可靠且可重複。 部署流程會自動記錄，而每次執行都會建立操作的記錄。
在整個開發生命週期中，於生產前和生產環境中嚴格測試更新。	早期測試能更早發現問題，允許逐步修正，並在更新準備好投入生產環境時減少問題。 擁有多個預備生產環境可進行各種類型的測試，提升對生產上成功發佈的信心。
使用部署模式推出新功能，以允許使用者漸進式曝光和漸進式採用。 測試回溯和向前相容性。	受控制的更新推出可降低瑕疵問題普遍發生的風險。 逐漸增加曝光有助於確保相容性和穩定性，並建立對發行的信心。
準備好補償措施，以便在生產環境中從錯誤部署或關鍵缺陷中恢復。 使用 測試支援的自動化 來推出修正程式。 針對緊急更新，需有相關人員事先核准的快速流程。	有風險降低計劃可降低潛在影響持續時間。 您可以快速部署緊急修正程式，例如安全性修補程式，讓使用者更快獲得安全版本。

後續步驟

建議您檢閱卓越營運檢查清單，以探索其他概念。

卓越營運檢查清單