營運卓越設計原則
營運卓越要素的核心是 DevOps 做法, 可透過標準化工作流程和小組的協調,確保工作負載品質。 此要素會定義 開發實務、可觀察性和發行管理的作業程式。 目標是將程式變異數、人為錯誤的機會和客戶中斷降到最低。 若要評估您的作業健康情況,請從下列問題開始:
- 您是否使用專業領域來執行作業?
- 客戶是否使用工作負載具有最大可預測性?
- 如何從體驗和收集的資料中學習,以推動持續改進?
當沒有清楚的擁有權或領導權時,工作負載作業可能會變成混亂的做法。 在此類型的環境中,小組通常會依賴以高精力執行的方法,並產生低結果,這會導致使用者體驗不佳。 這些方法只符合短期目標。 長期權益可透過 持續評估和策略性投資來實現。
設計原則提供操作策略的指導方針,這些策略必須考慮 以解決根本原因,而不只是處理徵兆。 從建議的方法開始,然後觀察哪些方法正常運作,以及哪些方法無法識別改進的領域。 設定策略之後,繼續使用 營運卓越檢查清單來推動動作。
工作負載的作業需求與其商務需求一樣重要。 有效率的程式可確保工作負載在合規性條件約束內達到業務成果,無論是組織或外部合規性。 索引鍵是尋找具有一致性的可重複性。
營運卓越要素的目標是 要執行正確的動作、以正確的方式執行,以及以小組身分解決正確的問題。
如果您符合這些目標,即使變更期間,工作負載仍能可靠地執行且可預測。 無法滿足作業需求可能會導致部署失敗、使用者體驗不一致,以及可能透過適當規劃和簡化執行而避免的成本。
採用 DevOps 文化
讓開發和營運小組能夠透過共同作業、共同責任和擁有權思維合作,持續改善其系統設計和程式。 |
---|
DevOps 是一個實務社群,其中觀點和技能的多樣性推動一項任務。 Teams 必須 培養共用知識的共同作業環境 ,而不是孤立的學習。 使用共用函式來努力克服資源限制。
良好的 DevOps 文化會因共同責任而成長。 開發和營運小組應將其目標和優先順序與客戶的期望保持一致,並牢記業務焦點。 開發小組應該在意見反應迴圈中牽涉到作業小組,因此改善會受到上游驅動,而其他小組則同樣受益。 相反地,營運小組負責藉由共用與工作負載相關的資源和意見反應,讓開發小組在業務成果中成功。
同時,DevOps 做法 會針對每個小組套用清楚的擁有權和責任。 無論應用程式執行的位置為何,工作負載小組都會負責該應用程式。
DevOps 會優化作業工作,使其有效但無法負擔。 為了獲得 DevOps 的完整權益,文化特性應該透過技術優化程式,並讓組織中的人員能夠提升透明通訊。
方法 | 優點 |
---|---|
使用可提升共同作業環境的常見系統和工具進行通訊和追蹤進度。 | 常見的工具和程式可啟用 透明通訊。 開發和營運小組都受益于各種環境的情況感知、常見的支援問題,以及整體挑戰和勝出。 如果發生事件,Teams 就已經熟悉現有的呈報路徑。 共用待辦專案會優先處理新功能或修正 Bug 等優先順序。 |
在整個開發週期中建置 持續學習和實驗思維 。 支援跨小組分享知識,並維護檔以供重複使用。 進行無責任分析,並評估發行後和/或事件後檢閱。 |
透過實驗機制,例如 A/B 測試和開發概念證明,您可以鼓勵創新,同時降低成本。 透過共同作業分享知識,讓小組熟悉設計方法、工具和程式。 在專案之後進行回顧有助於 識別改善領域 並慶祝成功。 |
採用經過實證的業界敏捷式做法 ,著重于動作優化。 尋找在作業中「 左移」 的機會,以進行手動和自動化程式、部署和品質保證做法,以及可觀察性。 |
敏捷式開發做法會導致發行生命週期較短,這是商業價值指標。 偵測、解決並避免先前的問題通常較不幹擾程式。 |
設定所有開發和作業程式的標準,並定期檢閱並加以驗證。 這些套裝程式括例行工作、頻外程式、緊急演練和情況、工具選擇、監視程式、技能計畫,甚至是與專案關係人與客戶洩漏的通訊。 刻意且明確地決定。 |
標準可新增作業的可預測性,並讓流程和做法可調整。 驗證標準是繪製改進點的絕佳方式。 執行一般演練,以備妥緊急和復原情況。 以精確度執行,並啟用治理以防止導致風險 的異常 。 |
利用具有特殊技術和廣度經驗的集中式作業小組。 | 針對作業和資源使用共用資源有一個成本效益。 雖然您擁有工作負載,但集中式小組可協助您使用跨功能技能,例如事件管理、主動式監視觀點,以及信任的外包專業知識。 |
建立開發標準
藉由標準化開發實務、強制執行品質閘道,以及透過系統化變更管理追蹤進度和成功,將生產力優化。 |
---|
開發小組負責在發行前解決工作負載問題,但有最少的摩擦。 請留意開發人員的效率,並 針對快速回合週期進行優化,從撰寫程式碼到測試結果。 實作有效且正確的程式,以規劃和標準化技術活動,並推動小組和專案關係人內的共識。
方法 | 優點 |
---|---|
記錄工作負載功能 並擷取客戶權益。 衍生 架構的範圍和非功能需求 。 建立調整大小估計模型 ,以報告涉及的工作範圍和成本。 |
良好的規格可藉由支援更具生產力且簡化的開發週期, 來降低營運成本和失敗的機會 。 開發人員在開始撰寫程式碼週期之前,先瞭解 技術設計、目標和完成準則 。 良好的檔可促進新小組成員的可重複 通訊 和 上線 。 |
使用 業界標準軟體發展方法,適當地針對 工作負載和小組大小的需求進行調整。 維護所有角色之間共用的待辦專案。 |
採用已知的方法 會設定專案的節奏。 它可藉由讓小組成員清楚預期和責任,來移除程式模棱兩可。 藉由追蹤一般清單, 即可使用標準做法來精簡工作並排定優先順序 。 專案將有機會及時傳遞。 標準方法可協助 風險管理。 透過細微的里程碑檢閱,開發人員可以在成為顯示者之前解決潛在問題。 |
針對所有程式碼、腳本、部署範本、管線定義和相關檔使用統一原始檔控制。 分支策略必須支援獨立和相依性功能、Bug 修正和 Hotfix 的無摩擦發行。 使用整個組織的共用知識來建置分支策略和部署程式。 |
正確使用原始檔控制對於支援 並行變更 和版本控制非常重要。 維護可重複的工作流程,以釋放各種大小和風險的變更、在程式中執行對等檢閱,以及保留稽核記錄。 |
具備 在 開發生命週期初期強調測試的品質保證程式。 包含計劃性測試程式的所有成品,包括屬於功能發行或更新一部分的應用程式元件、基礎結構和資料平面作業。 當成品透過環境升階時,將成品視為不可變,每次通過品質閘道時都會獲得信賴度。 在實際的情況下,自動化例行檢查。 |
品質保證可確保功能與非功能需求都符合信賴度,這會導致正面的客戶影響。 擁有測試計劃可確保品質和完整性,並考慮可能的失敗案例。 透過品質閘道,您可以強制執行最佳做法來降低風險。 不變性帶來信賴度,因為它可確保您測試的系統確實是您發行的內容。 除非符合品質準則,否則測試週期會有效率地封鎖進度。 |
使用 樣式指南和工具推動一致性,以強制執行 慣例,並採用 一般工具鏈 來開發、測試和與專案關係人通訊。 開發人員的技術標準應該 需要 實作模式、API 設計、 記錄、例外狀況處理和其他程式。 |
程式碼中的一致性可讓可讀性和更容易維護。 它也會降低複雜性,並啟用程式碼重複使用。 常見的工具和慣例也可協助小組優化程式,而不需要解決一次性選擇。 |
一致且刻意在撰寫程式碼的開發人員檔。 | 清楚的程式碼檔可確保在需要重新流覽舊程式碼或開發小組輪替時,可以輕鬆地瞭解邏輯和功能。 |
報告進度和趨勢 以測量效率。 | 錯誤、失敗更新、部署時間、意見反應迴圈和其他計量的趨勢已發佈,以及可推動改善。 |
使用可檢視性演進作業
深入瞭解系統、衍生深入解析,以及做出資料驅動決策。 |
---|
藉 由監視工作負載並 考慮 Azure Well-Architected Framework 的所有要素,建置持續改善品質的文化特性。 藉由提供必要的資料、統計資料和趨勢,讓小組和專案關係人能夠跨許多 Facet 進行短期和長期決策。 從您的資料中學習,並推動改善。
基於可觀察性目的所建置的作業,是主動維護應用程式、品質和安全性保證、容量規劃和產品管理的關鍵。
監視的重要層面是 使用健康情況模型來協助您在問題成為事件並影響客戶體驗之前先預期問題 。 有效率的監視可減少花費在事件管理上的回應迴圈。
方法 | 優點 |
---|---|
使用自己的堆疊和流程建置監視系統。 將監視系統視為與公用程式分離的工作負載維度。 堆疊必須涵蓋所有層級,包括基礎結構、應用程式健康情況,以及建置和發行程式。 擷取或取樣商務資料 不在可觀察性實作的範圍內。 |
將監視和工作負載堆疊分離,以 分隔功能需求和可檢視性需求 ,並讓獨立演進成為可能。 程式碼中的變更不應影響監視,反之亦然。 由於可檢視性需求與功能需求不同, 因此商務資料不會 因為監視設定變更或中斷而中斷。 |
針對每種資料來源類型,在收集程式中推動一致性。 使用遙測、基礎結構計量集合和工具的業界標準,將程式碼中的檢測標準化。 |
一致性可防止區分和測量的差異,因為相似資源之間的熟悉度 可減少相互關聯和分析資料所花費的時間。 您有整體的觀點可預期問題。 |
從應用程式程式碼發出遙測,以相互關聯執行流程的關鍵點,並在不同層級的資料細微性上提供端對端檢視。 | 根據嚴重性層級排定動作的優先順序,並瞭解其詳細資訊的內容。 這項資訊對於疑難排解而言非常重要。 |
擁有發出和收集資料的責任,即使資料接收是由多個小組共用,並由中央小組管理。 | 藉由將監視資料當地語系化至工作負載環境,小組可以存取記錄和計量來解決工作負載疑慮。 |
收集 足夠的資料 ,並保留足夠的 時間。 請考慮與記錄和儲存資料相關聯的成本取捨。 |
刻意資料收集可協助您優化與收集更多資料相關聯的 財務和營運成本 。 將雜訊降至最低,並在分析期間避免大量計算 ,並降低儲存不再需要的資料成本。 |
區分不同的監視訊號:設定檔、記錄、計量和追蹤。 請針對正確的用途使用每個訊號。 優先 使用計量來觸發 依賴數值測量的動作。 使用 設定檔取得系統較低層級的可見度,例如記憶體配置。 保留 記錄和追蹤的使用,以提供流程和 相依性的內容。 |
藉由針對正確的用途使用訊號,您可以防止監視系統的實作效率不佳。 例如,針對動作使用記錄需要剖析。 您可以使用計量更快達成相同的目標。 |
匯總和視覺化儀表板中的資料 ,以呈現符合物件的監視資料,並記住商務內容。 使用 案例儀表板 來呈現資料,以推動專案關係人之間的認知。 針對事件回應等操作員活動,使用操作儀表板和活頁簿與向下切入功能。 經常重新整理儀表板並提供細微的資料。 |
透過視覺效果,您可以分析趨勢、追蹤商務目標,以及管理事件。 專為客戶興趣量身打造的儀表板會進行相關解譯,並加速偵測和動作的時間。 |
使用標準化描述和嚴重性層級通知責任角色,讓警示成為可採取動作。 提供從各種來源定序的資訊,並追蹤與商務目標的偏差。 僅針對需要採取動作的事件觸發警示。 致力於主動 和思考警示,以在降級狀態變成失敗之前起始動作。 |
警示會注意組織所定義的重大事件。 良好的警示系統可識別動作和嚴重性,並提供足夠的資料來提升清楚度和目的。 操作員可以在補救時啟動,而不會延遲。 |
放心地部署
使用可預測性達到部署的預期狀態。 |
---|
建置工作負載供應鏈,可讓您在工作負載的裝載平臺、應用程式、資料和設定資源之間,一致地達到所有環境的可預測性目標。 部署機制必須能夠自動化、測試、監視和版本控制。 它應該模組化,並準備好視需要執行。 它不應該以整合型端對端進程來表示。 供應鏈不一定能加快執行速度,而是為了在多個反復專案上達到一致性和自我檔。
工作負載小組負責供應鏈,因為它與自己的工作負載相關。
方法 | 優點 |
---|---|
使用基礎結構即程式碼 (IaC) 來定義已準備好生產環境的供應鏈可重複層面。 偏好宣告式方法,而非命令式方法。 |
宣告式 IaC 技術的設計考慮自動化和重複使用性。 您可以將基礎結構部署從個人卸載成工具,並達到一致的品質。 從基礎結構的觀點來看,較少的技術選擇會移除工具的差異,並讓設定漂移更容易偵測。 維護也比較容易。 如果您將選擇與小組的現有技能集保持一致,小組可以輕鬆地採用。 |
準備小組以使用所選的 IaC 技術。 瞭解其擴充性模型、功能和限制。 利用小組內的特製化,並在組織內共用知識。 |
提升技能可提升生產力,並透過共用學習促進共同作業的環境。 您可以使用訓練來填滿差距,而不是雇用。 |
遵循 IaC 開發和維護的軟體建議。 在仲裁中模組化。 避免自訂或低值抽象概念。 請遵循分層方法來反映不同的生命週期。 形成基礎層,其中較低層會維持不變,且上方層會視需要變更。 部署成品,例如應用程式二進位檔、IaC 範本和參數,都是受攻擊面的一部分。 套用保證,例如秘密管理、存取控制,以及安全性要素的其他原則。 |
成品會體驗與應用程式程式碼相同的工程層級。 透過對等檢閱和測試進行品質控制可讓您確信部署。 分層方法可簡化維護,並建立界限,以建立清楚的責任線。 將安全性控制項新增至成品有助於在部署程式期間強化系統。 |
開發適用于所有環境的 通用部署 資訊清單。 使用該資訊清單作為綠地專案、累加式工作負載更新或災害復原的預設機制。 | 移除維護多個資產的額外負荷。 如果發生災害,復原將會快速且可靠,因為您可以部署已嘗試和測試的資訊清單,而不是建立現成的環境。 |
致力於透過 IaC 自動化部署的 不可變和暫時基礎結構 。 | 禁止設定漂移,並讓部署具有等冪性。 這種基礎結構可移除大量的作業負擔,例如修補。 它也受益于核心驗證案例,例如藍綠基礎結構部署。 |
注意
將入口網站使用量的範圍減少為僅非重複調查工作。
自動化以提升效率
以軟體自動化取代重複的手動工作 ,以更快速完成這些工作,並具有更大的一致性和精確度,並降低風險。 |
---|
工作負載的工作流程可能會有包含小組成員的工作流程,這些流程牽涉到執行不實際需要人為智慧、重複且耗時的工作。 視頻率而定,您可能會花費相當多的時間進行這些工作,並在工作負載成長時投入更多時間。 此外,這些程式通常因為人為輸入而容易出錯。
透過自動化,您可以節省時間、精力和金錢,並避免錯誤。
方法 | 優點 |
---|---|
根據正確層級複雜度、工作、頻率、精確度、時程表和生命週期的準則,評估所有工作流程。 根據該評估將工作流程自動化,並以最高預期傳回的工作流程為優先順序。 移除備援工作流程 或增加價值,以合理化人力。 |
您可以在較高的價值工作中重新建立小組容量,並提升生產力和一致性。 建置工作流程的清查可確保您將正確的工作自動化。 移除備援工作可降低複雜性和錯誤。 |
當您評估是否 要建置自訂工具或購買軟體時,請明確說明您的決策。 保留高度特製化和高價值工作的建置自動化。 |
藉由購買現成的軟體並利用支援合約,您可以節省維護成本。 藉由建置軟體,您可以擁有更多控制權,並符合小組和工作負載特有的使用案例。 不過,成本會受到影響。 選擇工具可為您的作業帶來標準化層級。 透過訓練,您可以達到採用的統一整備程度。 |
設計工作負載元件以支援 自動化功能。 | 避免在系統設計中缺少自動化的情況,提升重複工作的反模式、降低成長速度,並開始累積技術債務。 |
將所有 自動化視為工作負載的重要相依性 。 適應工作負載的預期成長。 您的自動化工具是工作負載不可或缺的一部分,它應該遵守五個 Well-Architected 架構要素。 |
設計自動化元件以承受風險,例如安全性威脅。 透過套用的最佳做法,您可以避免實作擴展。 如果此相依性保持正常且安全,工作負載將會繼續以高階保證運作。 |
藉由探索工作負載以外的選項,大規模自動化。 藉由提供範本和架構讓新專案上線,並提升現有設計和實作的重複使用,以偏好「設計一次、隨處執行」模型。 |
採用已嘗試和測試的方法,並減少失敗的機會。 |
採用安全部署做法
在部署程式中實作防護措施,以將錯誤或非預期狀況的影響降到最低。 |
---|
在開發週期期間,工作負載成品會在實作和測試及修正 Bug 時經歷許多變更。
部署程式必須遵循標準作業程式。 任何變更都必須使用相同的嚴格層級進行部署。 此原則同樣適用于程式碼、組態和所有相關成品。 關鍵在於儘快套用安全作法,以便您在生產環境中具有可預測性。 即使錯誤觸達客戶,您也應該能夠儘快推出復原變更。
方法 | 優點 |
---|---|
使用自動化部署程式標準化部署任何變更的程式,例如管線。 所有環境都必須使用管線。 分類每個環境的資產和版本,使其 易於 追蹤和識別。 |
一致的部署方法可減少 進程錯誤和差異所造成的問題,並可讓您專注于工作負載考慮。 標準化可確保部署以安全、可靠且可重複的方式完成。 分類可讓您輕鬆地檢視先前部署的記錄和發生的問題。 您可以使用該資訊來加速復原和向前復原作業。 |
定期部署 小型累加式更新 。 | 經常、經過妥善測試、小型更新,可 更輕鬆地驗證版本。 由於使用量較小,因此更快速地對 客戶造成最低影響 進行疑難排解。 |
在開發生命週期中使用不同機制嚴格測試更新。 | 攔截開發初期階段的問題 。 反復修正和一致的部署做法會導致在更新準備好進行生產環境時關閉問題。 |
逐漸推出更新,並盡責。 使用部署模型,讓您能夠 逐漸增加實例數目和客戶 ,直到所有更新都安全地採用為止。 |
以受控制的方式測試每個更新,以便在生產階段早期修正問題。 避免推出會影響整個客戶群的錯誤更新。 測試更新是否回溯和向前相容。 |
有風險降低策略,可快速 從部署失敗中復原。 策略應涵蓋根據問題重要性 來回複或向前 復原的決策。 具有 定義完善的流程和自動化系統 ,可使用標準部署管線快速推出修正程式。 |
減少潛在影響的持續時間。 將系統還原回先前的工作版本,或向前復原至已徹底測試修正的版本。 |
具有後援計畫,以在緊急狀況下將 系統重 設為工作狀態,並從非預期的失敗中復原。 只有在必要且經過核准時,才使用此策略。 努力改善一段時間的計畫。 |
您可以快速追蹤高優先順序修正,例如安全性補救。 加速管線可能沒有標準作業程式的所有檢查,但您會以最快的速度讓客戶進入安全版本,這比影響較低的錯誤還要高。 |
下一步
建議您檢閱營運卓越檢查清單,以探索其他概念。
意見反應
https://aka.ms/ContentUserFeedback。
即將推出:在 2024 年,我們將隨著內容的意見反應機制逐步淘汰 GitHub 問題,並以新的意見反應系統來取代。 如需詳細資訊,請參閱提交並檢視相關的意見反應