卓越營運設計原則

本文翻譯自：Microsoft 發布 Operational excellence design principles
原文連結：https://github.com/MicrosoftDocs/well-architected/blob/main/well-architected/operational-excellence/principles.md
翻譯日期：2024-12-27

「良好架構框架」(Well-Architected Framework) 其中一項原則(pillar)「卓越營運」(operational excellence)，其核心是透過標準化工作流程與團隊凝聚力，確保工作負載(workload)的品質，稱為DevOps 實踐。

卓越營運這個原則定義了開發實作、可監測性與發行版本管理的作業流程，目標是將流程差異、人為錯誤的機會和對客戶服務中斷降到最低。若要評估您的營運健康狀態，請從以下問題開始著手：

• 您是否依照技術領域的規範執行營運系統作業？

• 客戶使用工作負載時，是否對於工作負載最終產出效果擁有最大的可預期性？

• 您如何從經驗與收集到的資料中學習，以持續改善系統？

沒有明確的權責劃分或管理時，工作負載作業可能會演變成一團亂。在此狀況中， 團隊營運系統通常會事倍功半，導致使用者體驗不佳，而且處理問題的方式通常只能滿足短期目標，長期效益仍必須透過持續評估與策略性投資來實現。

設計原則的目的，是在營運策略上指引您考量如何應對根本原因，而不僅僅是緩解癥狀。從建議的方法開始，然後觀察哪些有效，哪些無效，找出需要改善的地方。制訂策略後，繼續使用卓越營運設計檢查清單來推動行動。

工作負載的營運要求與其業務要求一樣重要。高效率的流程可確保工作負載實現業務成果，並且符合組織內外部的合規性，而高效率流程的關鍵在於找到可重複性與一致性。卓越營運的目標是以正確的方式，做正確的事，並團隊合作解決正確的問題。

如果您實現卓越營運目標，即使遭遇任何變化，系統工作負載仍會以可靠與可預測的狀態運作。相反地，未能達成卓越營運要求，可能會導致部署失敗、使用者體驗不一致，以及成本增加等問題，這些問題原本都可以透過適當規劃與簡化運作而避免。

接納 DevOps 文化

目標：讓開發與營運團隊能夠透過共同協作、分擔權責的心態努力合作，以持續改善系統設計與流程。

DevOps 是一個實踐社群，透過多樣的觀點與技術來實現同一項使命。團隊必須營造一個共享知識的協作環境而非各自孤立學習。使用共享的機制，努力克服資源方面的限制。

良好的 DevOps 文化特性會在共同責任中萌芽茁壯。開發與營運團隊設定目標與優先順序時，應儘量貼近客戶期望，並牢記業務重點。開發團隊應該讓營運團隊有機會反應意見，以便推動上游任務改善，並使其他團隊一併受益。

相對地，營運團隊會負責藉由共享資源與反饋意見，使開發團隊在業務中獲得成功。 同時，DevOps 做法會明確劃分每個團隊的權責界線。無論應用程式在哪執行，工作負載團隊都該對其負責。

DevOps 改善營運任務，使其具有效率但不會過於繁重。為了充分發揮 DevOps 的優勢，DevOps 文化應該透過技術改善流程，並提供流程促使組織中的人員溝通透明化。

方法	效益
使用常見系統與工具推動協作環境，方便溝通與追蹤進度。	常見工具與流程可以實現溝通透明化。讓開發與營運團隊都能掌握各種環境的情況、常見的支援問題以及整體挑戰和成功。團隊應熟悉發生事件時的處理流程與步驟。共享待辦項目(backlog)，可以更容易釐清開發新功能或修復錯誤等作業的優先順序。
在整個開發週期中建立持續學習與實驗思維。 支援跨團隊知識共享，並維護文件供重複使用。進行對事不對人(不責難)的分析(blameless analysis)並在發布後或事件後回顧檢驗。	透過 A/B 測試與驗證概念等這類實驗機制，你可以鼓勵創新，同時節省成本。透過協作與共享知識，讓團隊精通設計方法、工具與流程。在專案結束後展開回顧，也有助於識別需要改善的面向。
採用經過實證的業界敏捷式做法，聚焦於行動最佳化。尋找在流程作業中「左移」(shift left)的機會，以取得手動和自動化流程、部署與品質控管做法，以及可監測性的機會。	敏捷式開發實務會縮短發布生命週期，這正是商業價值的指標。儘早偵測、解決並預防問題，通常比較不會干擾流程。
為所有開發與營運作業制訂標準流程，並定期加以審查與驗證。這些程序含日常任務、帶外流程(out-of-band processes)、緊急演練與緊急情況、工具選擇、監測程序、培訓計畫，甚至是對利害關係人的溝通與資訊揭露。做決策必須有意識且明確。	訂定標準能增加營運的可預期性，並使流程與實踐具可擴展性。驗證標準是找出改善點的好方法。透過定期演練為緊急情況與復原情況做好準備。精確執行並進行治理，以防止異常情況發生，導致風險。
善用具有專業技能與豐富經驗的集中式營運團隊。	對營運作業與資源有效使用而言，共享資源都具有成本效益。雖然您管理自己的工作負載，但集中式營運團隊可以協助您掌握跨職能技能，例如事件管理、主動監測視角以及可信任的外包專業。

建立開發標準

目標：透過標準化開發實作、執行品質控管以及透過系統化變更管理來追蹤進度與成果，改善生產效率。

開發團隊負責在發布之前、用最有效率的方式解決工作負載問題。請注意開發人員的效率，並改善從撰寫程式碼到測試結果的快速處理週期。實作有效且正確的流程，以規劃與標準化技術活動，並推動團隊與利害關係人之間達成共識。

方法	效益
記錄工作負載特性並維繫客戶利益。推論出架構的範圍，以及詳細的功能與非功能需求。建立規模估算模型以報告所涉及任務的範圍與成本。	良好的規範可以支援更高生產效率且簡化的開發週期，來降低營運成本與失敗的機會。開始程式碼撰寫週期之前，開發人員需了解技術設計、目標與完成標準。良好的文件有助於重複溝通與新團隊成員的入職教育訓練。
使用符合業界標準的軟體開發方法，根據您的工作負載與團隊規模需求適當調整。維護可供所有職務共用的待辦項目(backlog)。	採用眾所周知的方法，確立專案的節奏。透過提供團隊成員明確的期望與問責，去除流程的模糊性。透過追蹤共用的代辦事項清單，即可以使用標準方法來精簡任務並確定優先順序。讓專案將更有機會能按時交付。標準化的方法有助於風險管理。設定目標較小、期程較短的里程碑來加以審查，讓開發人員可以在潛在問題演變成重大問題之前加以因應。
對所有程式碼、指令碼、部署範本、流水線定義與相關文件使用統一的原始碼版控機制。分支策略(branching strategy)必須達到流暢發布更新的目的，含開發獨立功能或具耦合性的多個功能、錯誤修復與快速修復(hotfix)等類型的更新。利用整個組織的共享知識，來建立您的分支策略與部署流程。	正確使用原始碼版控機制，才能達到同步協作與版本控制。維護可重複的工作流程，以發布各種規模與不同風險的變更，在流程內進行同儕程式碼審查(peer review)，並保留稽核紀錄。
採用強調在開發生命週期早期進行測試的品質保證流程。要保留測試過程的所有部署產物(artifact)，例如作為功能發布或更新一部分的應用程式元件、基礎架構與資料層面的作業。在透過環境升級部署產物時，將部署產物視為不可變的(immutable)，以及在每次經過品質檢驗時，都能提升部署信心。在可行的情況下，自動進行例行檢查。	品質檢驗可確保功能與非功能需求都符合標準，這會對客戶產生正面的影響。制訂測試計畫可確保品質與完整性，並考量可能的故障情況。透過品管標準，您可以強制實施最佳做法來降低風險。不可變的部署產物確保系統在測試與發布階段的狀態是一致的，可以提升部署信心。除非滿足品質檢驗，否則測試環節會有效的阻擋進入後續流程。
使用格式指南與工具來推動一致性，以強制執行慣例，並採用常見工具鏈進行開發、測試與利害關係人的溝通。開發人員實作的技術標準應該含採用設計模式、API 設計、記錄、異常狀況處理與其他流程。	程式碼的一致性可提高可讀性並更容易維護。它也降低了複雜性，並能實現程式碼再利用。常見工具與慣例也可以幫助團隊改善流程，而不需解決一次性案例。
每當程式被撰寫出來，就持續維護程式碼品質與一致性。	架構清晰的程式碼可確保閱讀舊程式碼或開發團隊人員異動時，能輕鬆理解邏輯與功能。
報告進度與趨勢以衡量效率。	發布錯誤、更新失敗、部署時間、意見反饋與其他指標的趨勢報告，並推動改善。

透過可監測性改善營運

目標：深入了解系統的可監測性、洞察報告，並依據資料做出決策。

透過監測工作負載並考量 Azure Well-Architected Framework 的所有原則，建立不斷提高品質的文化。透過提供必要的資料、統計數據與趨勢，使團隊與利害關係人能在各方面做出短期與長期決策。從您的資料中學習並推動改善。

為可監測性而建置的作業，是主動維護應用程式、品質與安全保證、容量規劃與產品管理的關鍵。

監測的一個重要方面是使用健康狀態建模，幫助您在問題演變為事件並影響客戶體驗之前進行預測。有效的監測可減少事件管理花費的反應週期。

方法	效益
建構一套具有獨立堆疊與流程的監測系統。 將監測系統視為與其效用分離之工作負載的一個維度。堆疊必須覆蓋所有層，含基礎架構、應用程式健康狀態以及建置與發布流程。 擷取或採樣業務資料的範圍不足，無法進行可監測性的實作。	將監測與工作負載堆疊解耦，以分隔功能需求與可監測性需求，並讓獨立演進成為可能。程式碼中的變更不應影響監測，反之亦然。 由於可監測性需求與功能需求不同，因此不會因監測配置變更或中斷，而影響業務資料。
儘可能讓各種類型資料來源採用一致的收集流程。 透過使用遠端監測資料、基礎架構指標收集與工具的業界標準，將程式碼檢測標準化。	一致性可以防止感測與測量之間的差異，因為跨資料來源之間具有相似性，可以花費更少的時間來建立資料之間的關聯性與分析資料。讓您有一個整體的觀點來預測問題。
由應用程式碼發出遠端監測資料，建立關鍵的執行流程點之間的關聯性，並提供不同精細程度的端對端（end-to-end）監測數據。	根據嚴重性層級排定動作的優先順序，並了解內容的詳細資訊。此資訊對於故障排除至為關鍵。
即使資料接收器由多個團隊共用，並由中央團隊管理，團隊有發送與收集資料的責任。	藉由將監測資料在地化到工作負載環境，團隊可以存取紀錄與指標來因應工作負載問題。
收集足夠的資料並保留恰好夠長的時間。請考慮與日誌紀錄和儲存資料相關的成本取捨。	有意識地收集資料可協助您管控與收集資料相關的財務與營運成本。 將雜訊降到最低，避免在分析期間進行密集運算，並降低無用資料的儲存成本。
區分不同的監測訊號：設定檔、日誌紀錄、指標與追蹤。將每個訊號用於正確的目的。優先使用指標來觸發，對相關數值進行測量。 使用設定檔(profiles)在系統中取得較底層的可監測性，例如記憶體分配。 保留日誌與追蹤資料的使用，以提供流程與相依關係的脈絡資訊。	藉由將訊號用於正確的目的，您可以避免監測系統的實作效率不彰。 例如，使用操作日誌資料需要先經過剖析，但你可以使用指標測量更快達成相同的目標。
在儀表板中彙總並視覺化資料，以呈現適合受眾並符合業務脈絡的監測資料。 使用案例儀表板來顯示資料，以提高利害關係人的意識。 使用具有深入分析功能的操作儀表板與活頁簿進行事件應變等操作者活動。經常更新儀表板並提供精細資料。	透過視覺化，您可以分析趨勢、追蹤業務目標並管理事件。 針對客戶興趣量身打造的儀表板能解讀相關性，並加速偵測與採取行動的時間。
使用標準化的說明內容與嚴重性等級來通知負責的角色，讓警示成為可採取的動作。提供從各種來源整理的資訊，並追蹤與業務目標的差異。 僅針對需要採取措施的事件觸發警示。 採取主動式且引起注意的警示，在降級狀態變成故障之前採取行動。	警示能引起對團隊定義的重大事件的關注。 良好的警示系統可以識別出操作動作與嚴重性，並提供足夠的資料來釐清細節與效果。讓操作者可以立即展開修復，而不會延遲。

對部署具備信心

目標：以符合預期的方式，達到所需的部署狀態。

建置工作負載供應鏈，使您能在所有環境中跨工作負載的託管平台、應用程式、資料與配置資源，一致地達到所有環境中可預測性的目標。部署機制必須具備自動化、測試、監測與版本控制能力。它應該經過模組化，並準備好視需要執行，不應以整合型端對端流程 (monolithic end-to-end process) 形式呈現。供應鏈不一定是為了更快速的執行，而是為了在多次反覆迭代中實現一致性與自動記錄。

工作負載團隊對供應鏈負責，因為它與他們自己的工作負載有關。

方法	效益
使用基礎架構即程式碼(Infrastructure as Code, IaC) 定義供應鏈的可重複層面，而且是立即在正式環境使用。更推薦使用宣告式方法，而不是指令式方法。	宣告式 IaC 技術在設計時考量了自動化與可重複使用性。您可以將基礎架構部署從個人轉移到工具中，並實現一致的品質。從基礎架構的角度來看，較少的技術選擇可以移除工具之間的差異，並更容易偵測出組態設定漂移(drift)，維護也會更容易。如果您的架構設計選擇儘量貼近團隊現有的技能組合，團隊可以輕鬆採用這些工具。
讓團隊為選定的 IaC 技術做好準備。了解其擴充性模型、能力與限制。提升團隊專業度與善用組織內的共享知識。	技能提升可以提高生產效率，並透過共享學習創造協作環境。您可以透過培訓而不是招募新人來填補技術差距。
請遵循軟體建議進行 IaC 開發與維護。適度進行模組化。避免客製化或低價值抽象化。遵循分層方法來反映不同的生命週期。形成基礎層，其中下層保持不變，上層視需要變更。部署產物(artifact)，例如應用程式二進位檔、IaC 範本與參數，都是可能遭受攻擊的面向(attack surface)。應採取一些保險措施，例如秘密管理、存取控制以及其他與安全要素相關的原則。	部署產物(artifact)會經歷與程式碼相同等級的工程嚴謹度。透過同儕審查與測試來控管品質，讓您對部署充滿信心。分層方法使維護變得更加容易，並建立了明確的責任界線。為部署產物(artifact)加入安全控制，有助於在部署流程中強化系統。
開發適用於所有環境中使用的 通用部署清單(manifest)。使用此清單作為新建專案、增量工作負載更新或災害復原的預設機制。	去除維護多項資產的開銷。因為您可以部署已經過嘗試與測試的清單，而不是建立臨時環境，如果發生災害，復原將快速可靠。
努力實現透過 IaC 自動化部署、不可變且暫時性的基礎架構。	禁止組態設定漂移(drift)，確保部署等冪性 (idempotent)。這種基礎架構移除了重大的營運負擔，例如修補。它也有益於核心驗證情境，例如藍綠基礎架構部署。

備註：將入口網站的使用範圍限縮到僅用於非重複性質的調查任務。

自動化以提高效率

目標：以軟體自動化取代重複的手動任務，可以更快完成這些任務，具有更高的一致性與準確性，並降低風險。

工作負載可能具有工作流程，其中的流程涉及團隊成員執行其實不需要人類智慧，平凡、重複且耗時的任務。隨著工作負載的增加以及執行營運任務的頻率，您可能會花費大量時間在這些工作上，而且透過人力手動執行流程通常容易出錯。

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

方法	效益
對複雜性、工作量、頻率、準確性、及時性與生命週期等面向設定適當水準的標準，並用此標準評估所有工作流程。根據此評估自動化工作流程，並優先考慮具有最高預期回報的工作流程。移除冗餘工作流程或增加價值以證明人力的合理性。	您可以將團隊能力重新投入到更高價值的工作中，並提高生產力與一致性。建立工作流程清單可確保您能自動執行正確的任務。移除冗餘任務可以降低複雜性與出錯機會。
當您評估要開發客製化工具或購買軟體時，請明確說明你的決策。建議針對高度專業化與高價值的工作建立自動化流程。	透過購買現成的軟體並利用支援合約，您可以節省維護成本。開發客製化工具雖然會影響成本，但您可以擁有更多控制權，並能滿足團隊與工作負載特有的使用情境。工具選擇可為您的作業達到標準化水準。透過培訓，您可以達到統一的採用就緒水準。
設計您的工作負載元件以支援自動化功能。	避免系統設計中缺乏自動化，促進重複任務的反模式、減緩成長並開始累積技術負債。
將所有自動化視為工作負載的關鍵相依性。針對工作負載的預期成長進行因應調整。您的自動化工具是工作負載不可或缺的一環，它應該遵循 Well-Architected Framework 的五個原則。	設計您的自動化元件以抵禦安全威脅等風險。透過採取最佳做法，您可以避免實作無序擴張。為確保工作負載在高服務水準下運作，依賴的自動化元件要能維持工作負載的功能性與安全性。
藉由探索工作負載以外的選項實現大規模自動化。藉由提供範本與架構來啟動新專案，並提升現有設計與實作的重複使用，來支援「設計一次，到處執行」模式。	採用經過實測與驗證過的方法，並減少失敗的機率。

採用安全部署實踐

目標：在部署流程中設置防護機制，以儘量減少錯誤或意外情況的影響。

在開發週期中，經歷開發實作、測試以及修復錯誤過程，工作負載產出的檔案(work load artifacts)會有許多變更。

部署流程必須遵循標準作業流程。任何變更都必須以相同的嚴格程度進行部署。此原則同樣適用於程式碼、配置與所有相關跡證。關鍵是儘早採用安全做法，以便在正式環境中具有可預期性。即使客戶發現錯誤，您也應該能夠儘速推出復原變更。

方法	效益
將任何變更的部署過程標準化，並使用自動化部署流程，例如流水線(pipeline)。所有環境都必須使用流水線。對資產和版本進行分類，以便在各環境中易於追蹤和識別。	一致的部署方法可以減少流程錯誤與任何變動造成的問題，並讓您將精力集中在工作負載問題上。標準化可確保部署安全、可靠，並可重複地完成。分類能讓您輕鬆檢視先前的部署紀錄與發生的問題。您也許能使用這些資訊來加快還原 (rollback) 與向前復原 (roll-forward) 操作。
定期部署小型增量更新。	頻繁、經過充分測試的小更新能讓版本驗證變得更加容易。由於變動範圍較小，可以更快排除故障，並將對客戶的影響降至最低。
在整個開發生命週期中使用不同的機制，嚴格測試更新。	在開發的早期階段發現問題，並通過迭代修復與一致的部署流程，能讓準備好在正式環境更版時，問題的影響範圍最小。
盡責地逐步推出更新。使用部署模型，您可以控制逐步增加執行個體(instance)與客戶的數量，直到所有人已安全地採用更新。	設定測試計畫並測試每個更新版本，以便在正式環境營運的初期階段解決問題。避免推出影響整個客戶群的不當更新。測試更新是否向後與向前相容。
制訂緩解策略以從部署失敗中快速復原。此策略應涵蓋根據問題的嚴重性，做出還原(rollback)或向前復原(roll-forward)的決策。擁有明確定義的流程與自動化系統，可以透過使用標準部署流水線，快速推出修復程序。	減少潛在影響的持續時間。將系統復原到先前的工作版本，或向前復原到具有(經過徹底測試)修復的版本。
制訂退版降回(fallback)計畫，發生緊急情況時將系統重置為運作狀態，並從非預期故障中復原。僅在必要且獲得核准時才使用此策略。隨著時間的推移，努力改進計畫。	您可以快速追蹤高優先順序的修復，例如安全性修復。加速流水線可能不會執行標準作業流程的所有檢查，這樣可能產生影響較輕微的故障，但盡可能用最快的方式為客戶提供安全版本會更重要。

後續步驟

我們建議您查看卓越營運設計檢查清單以探索其他概念。

卓越營運設計檢查清單

此清單提供了一系列建議，可協助您打造卓越營運的文化。從 DevOps 方法開始，整合多個領域的專業知識。這種方法可建立嚴謹的設計與開發實務，可重複、可靠且安全的基礎架構與程式碼部署。

只有在人為介入有幫助的領域，才優先考慮人為介入，並在其他領域納入自動化。可監測性可藉由監測健康狀態事件來提供卓越營運，以及驗證目前的工作負載設計與實作，為未來的產品開發提供資訊。

如果不考量卓越營運並進行相關權衡取捨或採行相關建議，工作負載可能會面臨風險。請仔細考量以下檢查清單中的要點，以鞏固您對設計的信心。

檢查清單

	文件編碼	建議
☐	OE:01	確認工作負載團隊成員的專長，並將其整合到工作方法中，以按照規格設計、開發、部署與操作工作負載。團隊成員必須具備明確的決策與責任，重視持續改善與最佳化，並採用持續學習的對事不對人(不責難的)文化。
☐	OE:02	透過使用文件、檢查清單或自動化工具，將您視需要執行例行任務與緊急作業任務的方式正規化。透過採用領先業界的實踐與方法(例如左移方法)，努力實現團隊流程與可交付成果的一致性與可預期性。
☐	OE:03	將軟體構思與規劃流程正規化。參考既有的業界與組織標準。使用常見、按優先順序排列的待辦項目與足夠詳細的規格。根據結果，反饋到規劃流程並持續改善工作方式。
☐	OE:04	透過遵循經業界驗證的開發與測試做法，改善軟體開發與品質保證流程。為了明確指派角色，將跨元件的做法標準化，例如工具、原始碼控制、應用程式設計模式、文件與格式指南。
☐	OE:05	使用標準化基礎架構即程式碼(IaC)方法準備資源及其配置。如同其他程式碼，以一致的風格、適當的模組化與品質保證來設計 IaC。盡可能選擇聲明式方法。
☐	OE:06	建立一條工作負載供應鏈，透過可預期的自動化流水線達成期望的變更。流水線會測試並跨環境升級這些變更。改善供應鏈，使您的工作負載可靠、安全、符合成本效益且高效能。
☐	OE:07	設計與實作監測系統以驗證設計選擇，並為未來的設計與業務決策提供資訊。監測系統擷取並通知從工作負載的基礎架構與程式碼發出的遠端監測資訊、指標與紀錄。
☐	OE:08	制訂有效的緊急應變做法。確保您的工作負載在基礎架構與程式碼中發出有意義的健康狀態訊號。收集所產生的資料並利用這些資料產生警示並據以採取行動，透過儀表板與查詢監測數據啟動緊急應變措施。明確定義人員職責，例如值班輪調、事件管理、緊急資源存取與進行事後分析。
☐	OE:09	將所有不需要人類判斷和調整的工作進行自動化，這些工作通常是高度標準化的，且投資自動化具有效益。請盡可能選擇現成的自動化軟體，而非客製化開發。將所有自動化視為工作負載元件，並將Well-Architected Framework原則應用於其設計與實作。
☐	OE:10	預先設計與實施自動化作業，例如生命週期問題、啟動並應用治理與合規性防護機制。不要在事後嘗試調整自動化作業，選擇平台提供的自動化功能。
☐	OE:11	明確定義工作負載的安全部署實踐。強調小規模、增量、以品質為導向的發布方法。使用現代部署模式與漸進式揭露技術來控制風險。考量常規、緊急或快速修復等不同類型部署。
☐	OE:12	實作部署故障緩解策略，透過快速復原處理非預期的部署中問題。結合多種方法，例如還原 (rollback)、功能停用或使用部署模式的原生功能。

後續步驟

我們建議您查看卓越營運權衡取捨以探索其他概念。

註解：本文最後一行提及的「卓越營運權衡取捨」提供了一個外部連結，以進一步說明如何在工作負載架構和營運設計中進行取捨的原則與方法。若對此主題有更深入的需求，可以點擊連結查閱詳細內容。