共用方式為

營運卓越設計原則

  • 發行項

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

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

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

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

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

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

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

採用 DevOps 文化特性

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

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

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

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

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

方法 優點
使用可促進共同作業環境的常見系統和工具進行通訊和追蹤進度。 常見的工具和程式可啟用 透明通訊。 開發和營運小組都受益於各種環境的情境感知、常見的支援問題，以及整體挑戰和勝利。

小組已熟悉發生事件時現有的呈報路徑。

共用待辦項目會明確指出處理新功能或修正 Bug 等作業的優先順序。
在整個開發週期中建立 持續學習和實驗思維 。

支援跨小組共用 知識，並維護檔以供重複使用。

進行無可指責的分析，並彙報發行后和/或事件后檢閱。		 透過 A/B 測試和開發概念證明等實驗機制，您可以鼓勵創新，同時降低成本。

透過共同作業分享知識，讓小組熟悉設計方法、工具和流程。

在項目之後進行回顧有助於 識別改進 和慶祝成功的領域。
採用經過實證的產業敏捷式做法 ，專注於動作優化。

尋找 在作業中「左移」 的機會，以取得手動和自動化程式、部署和品質保證做法，以及可觀察性的機會。		 敏捷式開發實務會導致發行生命週期較短，這是商業價值指標。

偵測、解決及避免先前的問題，通常較不干擾程式。
設定所有開發和作業程序的標準，並定期檢閱和驗證。

這些程序包括例行工作、頻外程序、緊急演練和情況、工具選擇、監視程序、技能計劃，甚至是與專案關係人和客戶揭露的通訊。

刻意明確決定。		 標準可增加作業的可預測性，並讓流程和做法可調整。 驗證標準是指出改進點的絕佳方式。

定期進行演習，為緊急和復原情況做好準備。

使用精確度執行並啟用治理，以防止 導致風險的異常 。
利用具有特殊技能和廣度經驗的集中式作業小組。 針對作業和資源使用共用資源具有成本效益。

雖然您擁有工作負載，但集中式小組可協助您運用跨功能技能，例如事件管理、主動監視觀點，以及信任外包專業知識。

建立開發標準

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

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

方法 優點
記錄工作負載功能 並擷取客戶權益。

衍生 架構的範圍和詳細的功能和非功能需求 。

建立大小估計模型 ，以報告涉及之工作的範圍和成本。		 良好的規格可 藉由支援更具生產力且簡化的開發週期，來降低營運成本和失敗 的機會。

開發人員在開始撰寫程式代碼週期之前， 先瞭解技術設計、目標和完成準則 。

良好的文件有助於新小組成員的可 重複溝通 和 上線 。
使用業界標準軟體開發方法，針對工作負載和小組大小的需求進行適當調整。

維護所有角色之間共用的待辦專案。		 採用已知的方法 會設定項目的節奏。 它藉由讓小組成員清楚的期望和責任來消除程式模棱兩可。

藉由根據一般清單進行追蹤， 即可使用標準做法來精簡工作並排定優先順序 。 該專案將有更好的機會按時交付。

標準方法有助於 風險管理。 透過細微的里程碑檢閱，開發人員可以在成為顯示者之前解決潛在問題。
針對所有程式代碼、腳本、部署範本、管線定義和相關文件使用統一的原始檔控制 。

分支策略必須支持獨立且相互依存的功能、Bug 修正和 Hotfix 的無摩擦釋放。

使用整個組織的共享知識來建置分支策略和部署程式。		 正確使用原始檔控制對於支援 並行變更 和版本控制至關重要。

維護可重複的工作流程，以釋放各種大小和風險的變更、在程式中進行對等檢閱，以及保留稽核線索。
具有 在開發生命週期早期強調測試的質量保證 程式。

包含計劃性測試程式的所有成品，包括屬於功能發行或更新一部分的應用程式元件、基礎結構和數據平面作業。

在透過環境提升成品時，將成品視為不可變的，每次通過品質網關時都會獲得信心。

在實用的情況下，自動化例行檢查。		 品質保證可確保功能和非功能性需求都符合信心，這會導致對客戶產生正面的影響。

擁有測試計劃可確保品質和完整性，並考慮可能的失敗案例。

透過品質閘道，您可以強制執行最佳做法來降低風險。

不變性帶來信心，因為它可確保您測試的系統完全是您發行的內容。

除非符合品質準則，否則測試週期會有效率地封鎖進度。
使用 樣式指南和工具來推動一致性，以強制執行 慣例，並採用一般 工具鏈 來開發、測試和與專案關係人通訊。

開發人員的技術標準應該 需要實 作模式、API 設計、記錄、 例外狀況處理和其他程式。		 程序代碼中的一致性可讓可讀性更容易維護。 它也會降低複雜性，並啟用程式代碼重複使用。

常見的工具和慣例也可協助小組將程序優化，而不需要解決一次性選擇。
一致且刻意地堅持撰寫程式代碼的開發人員檔。 清除程式代碼檔可確保在需要重新瀏覽舊程式代碼或開發小組輪替時，可以輕鬆地了解邏輯和功能。
報告測量效率的進度和趨勢 。 錯誤、失敗更新、部署時間、意見反應迴圈和其他計量的趨勢已發佈，並推動改善。

具有可觀察性的演進作業

目標圖示 深入了解系統、衍生深入解析，並做出數據驅動決策。

建置一種文化特性，藉由監視工作負載並納入 Azure 架構架構的所有要素，來持續改善品質。 藉由提供必要的數據、統計數據和趨勢，讓小組和專案關係人能夠跨許多面向做出短期和長期決策。 從您的數據中學習並推動改善。

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

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

方法 優點
使用自己的堆疊和流程建置監視系統。

將監視系統視為與其公用程序分離的工作負載維度。 堆疊必須涵蓋所有層級，包括基礎結構、應用程式健康情況，以及建置和發行程式。

擷取或取樣商務數據 的範圍不足，無法進行可觀察性實作。		 將監視和工作負載堆疊分離，以 分隔功能需求和可觀察性需求 ，並讓獨立演進成為可能。 程序代碼中的變更不應影響監視，反之亦然。

由於可觀察性需求與功能需求不同，因此不會因為監視設定變更或中斷而中斷商務數據。
為每種數據源類型推動收集程式中的一致性。

使用遙測業界標準、基礎結構計量集合和工具，在程式代碼中標準化檢測。		 一致性可防止感知和測量的差異，因為類似資源 之間的熟悉可減少相互關聯和分析數據所花費的時間。 您有一個整體的觀點來預測問題。

從應用程式程式代碼發出遙測 ，以將執行流程的關鍵點相互關聯，並提供不同層級數據粒度的端對端檢視。 根據嚴重性層級排定動作的優先順序，並了解內容的詳細資訊。 這項信息對於疑難解答而言非常重要。
擁有發出和收集數據的責任，即使數據接收是由多個小組共用，並由中央小組管理。 藉由將監視數據當地語系化至工作負載環境，小組可以存取記錄和計量來解決工作負載問題。
收集 足夠的數據 ，並保留足夠的 時間。

請考慮與記錄和儲存數據相關聯的成本取捨。		 刻意數據收集可協助您 將與收集更多數據相關的財務和營運成本 優化。

將雜訊降到最低，避免在分析期間進行密集計算 ，並降低儲存不再需要之數據的成本。
區分不同的監視訊號：配置檔、記錄、計量和追蹤。 請針對正確的用途使用每個訊號。

優先使用計量來觸發依賴數值測量的動作。

使用 配置檔在系統中取得較低層級的可見性，例如記憶體配置。

保留記錄和追蹤的使用，以提供流程和相依性的內容。		 藉由將訊號用於正確的用途，您可以防止監視系統的實作效率不佳。

例如，針對動作使用記錄需要剖析。 您可以使用計量更快達成相同的目標。
匯總和可視化 儀錶板中的數據，以呈現符合物件需求並記住商務內容的監視數據。

使用 案例儀錶板 來呈現數據，以推動專案關係人之間的認知。

針對事件回應等操作員活動，使用操作儀錶板和活頁簿 與向下切入功能。 經常重新整理儀錶板並提供細微的數據。		 透過視覺效果，您可以分析趨勢、追蹤商務目標，以及管理事件。

針對客戶興趣量身打造的儀錶板會進行相關解譯，並加速偵測和動作的時間。
使用標準化描述和嚴重性層級來通知責任角色，讓警示成為可 採取動作。 提供從各種來源定序的資訊，並追蹤與商務目標的偏差。

僅針對需要動作的事件觸發警示。

爭取主動 式和挑釁性警示，在降級狀態變成失敗之前起始動作。		 警示會留意組織所定義的重大事件。

良好的警示系統可識別動作和嚴重性，並提供足夠的數據來提升清晰度和目的。 操作員可以在補救時啟動，而不會延遲。

安心部署

目標圖示 使用可預測性達到所需的部署狀態。

建置工作負載供應鏈，可讓您在工作負載的裝載平臺、應用程式、數據和設定資源之間，一致地達到所有環境中可預測性的目標。 部署機制必須能夠自動化、測試、監視和版本控制。 它應該模組化，並準備好視需要執行。 它不應該以整合型端對端程式表示。 供應鏈不一定是為了更快速的執行，而是為了在多個反覆項目上達成一致性和自我檔。

工作負載小組負責供應鏈，因為它與自己的工作負載有關。

方法 優點
使用基礎結構即程式代碼 （IaC） 來定義已準備好生產之供應鏈的可重複層面。

偏好宣告式方法，而不是命令式方法。		 宣告式 IaC 技術的設計考慮自動化和重複使用性。 您可以將基礎結構部署從個人卸除成工具，並達到一致的品質。

從基礎結構的觀點來看，擁有較少的技術選擇會移除工具的變異數，並讓設定漂移易於偵測。 維護也會比較容易。 如果您將選擇與小組的現有技能集一致，小組可以輕鬆地採用。
準備小組以使用所選的 IaC 技術。 瞭解其擴充性模型、功能和限制。

利用小組內的特製化，並在組織內共用知識。		 提高技能可提高生產力，並透過共用學習來培養共同作業的環境。

您可以使用訓練來填補空白，而不是招聘。
請遵循 IaC 開發和維護的軟體建議 。

在仲裁中模組化。 避免自定義或低值抽象概念。

請遵循分層方法來反映不同的生命週期。 形成基礎層，其中較低層會保持不變，而上層會視需要變更。

部署成品，例如應用程式二進位檔、IaC 範本和參數，都是受攻擊面的一部分。 套用保證，例如秘密管理、訪問控制和其他安全性要素的原則。		 成品體驗與應用程式程序代碼相同的工程嚴謹程度。 透過對等檢閱和測試的品質控制可讓您有信心進行部署。

分層方法可讓維護更容易，並建立界限，以建立明確的責任線。

將安全性控制新增至成品有助於在部署程式期間強化系統。
開發適用於所有環境的通用部署指令清單。 使用該指令清單作為綠地專案、累加式工作負載更新或災害復原的默認機制。 拿掉維護多個資產的額外負荷。

如果發生災害，復原將會快速且可靠，因為您可以部署已嘗試和測試的指令清單，而不是建立即興的環境。
努力尋找 透過 IaC 自動化部署的不可變和暫時基礎結構 。 禁止設定漂移，並讓部署等冪。

這種基礎結構可消除重大作業負擔，例如修補。 它也有利於核心驗證案例，例如藍綠基礎結構部署。

注意

將入口網站使用量的範圍減少為僅重複的調查工作。

自動化以提高效率

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

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

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

方法 優點
根據正確層級複雜度、投入時間、頻率、精確度、時程表和生命週期的準則，評估所有工作流程 。

根據該評估將工作流程 自動化，並以最高的預期傳回來排定工作流程的優先順序。

拿掉備援工作流程 或增加價值，以證明人力投入。		 您可以將團隊容量重新投入更高的價值工作，並提升生產力和一致性。

建置工作流程清查可確保您將正確的工作自動化。 拿掉備援工作可減少複雜度和錯誤。
當您評估是否 要建置自定義工具或購買軟體時，請明確說明您的決策。

保留高特製化和高價值工作的建置自動化。		 藉由購買現成的軟體並利用支援合約，您可以節省維護成本。

藉由建置軟體，您可以擁有更多控制權，並迎合小組和工作負載特有的使用案例。 不過，會產生成本影響。

選擇工具可讓您的作業達到標準化水準。 透過訓練，您可以達到採用的統一整備程度。
設計工作負載元件以支援 自動化功能。 避免系統設計中缺乏自動化的情況，促進重複工作的反模式、減緩增長，並開始累積技術債務。
將所有自動化視為工作負載的重要相依性。 適應工作負載的預期成長。

您的自動化工具是工作負載不可或缺的一部分，它應該遵守五個架構完善的架構要素。		 設計您的自動化元件以承受風險，例如安全性威脅。 透過套用的最佳做法，您可以避免實作蔓延。

如果此相依性保持運作且安全，工作負載會繼續以高階保證運作。
藉由探索工作負載以外的選項，大規模 自動化。

藉由提供範本和架構來讓新項目上線，並提升現有設計和實作的重複使用，來偏好「設計一次，隨處執行」 模型。		 採用經過嘗試和測試的方法，並減少失敗的機會。

採用安全部署做法

目標圖示 在部署程式中實作護欄，以將錯誤或非預期狀況的影響降到最低。

在開發周期期間，工作負載成品會在實作和測試及修正 Bug 時經歷許多變更。

部署程式必須遵循標準作業程式。 任何變更都必須以相同層級的嚴謹進行部署。 此原則同樣適用於程式代碼、組態和所有相關成品。 關鍵是儘早套用安全做法，以便您在生產環境中具有可預測性。 即使錯誤到達客戶，您也應該能夠儘快推出復原變更。

方法 優點
使用自動化部署程式，例如管線，標準化部署任何變更的程式。

所有環境都必須使用管線。

分類每個環境的資產和版本，使其 易於 追蹤和識別。		 一致的部署方法可減少 因進程錯誤和差異所造成的問題，並可讓您將精力集中在工作負載考慮上。

標準化可確保部署能安全地、可靠地完成，並具有重複性。

分類可讓您輕鬆地檢視先前部署的記錄和已發生的問題。 您可以使用該資訊來加速復原和向前復原作業。
定期部署 小型增量更新 。 經常、經過測試且測試良好的小型更新，可 更輕鬆地驗證版本。

因使用量較小而加快對客戶的影響，以更快進行疑難解答。
在整個開發生命週期中使用不同機制 來嚴格測試更新。 在開發初期 攔截問題。 反覆修正和一致的部署做法會在更新準備好進行生產環境時，導致問題逐漸減少。
逐步推出更新，並盡職盡責。

使用部署模型，讓您能夠逐步 增加實例和客戶 的數目，直到所有實例都安全地採用更新為止。		 以受控制的方式測試每個更新，以便在生產初期修正問題。 避免推出會影響整個客戶群的錯誤更新。

測試更新是否回溯和向前相容。
有風險降低策略，可快速 從部署失敗中復原。

該策略應涵蓋根據問題關鍵性進行回復或向前復原的決策。

擁有 定義完善的流程和自動化系統 ，可使用標準部署管線快速推出修正程式。		 降低潛在影響的持續時間。

將系統還原回先前的工作版本，或向前復原至已徹底測試修正的版本。
有後援計劃 ，在發生緊急狀況時將系統 重設為工作狀態，並從非預期的失敗中復原。 只有在必要且經過核准時，才使用此策略。

努力改善一段時間的計劃。		 您可以快速追蹤高優先順序修正，例如安全性補救。

加速管線可能沒有標準作業程式的所有檢查，但您會以最快的方式讓客戶進入安全版本，這超過影響較低的錯誤。

下一步

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

卓越營運檢查清單