建站
咨詢
售后
建站咨詢
新聞中心
DevOps 轉型是一件頗有挑戰(zhàn)性的工作。它并不是一個簡單的工具或者平臺的使用、運維能力提升。特別是在中大型組織中，它涉及到一系列的組織問題。
十年的谷城網站建設經驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。全網營銷推廣的優(yōu)勢是能夠根據用戶設備顯示端的尺寸不同，自動調整谷城建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“谷城網站設計”,“谷城網站推廣”以來，每個客戶項目都認真落實執(zhí)行。
而傳統(tǒng)的 DevOps 成熟度模型過于撕裂與分散，無法適用于大型組織。DevOps 廠商與云廠商的 DevOps 成熟度模型過于關注如何賣云基礎設施，無助于企業(yè)進行高效的協(xié)作。
為此，我決定在 Ledge 的基礎上，設計上開源的、面向大型組織的 DevOps 能力成熟度模型。它是基于我們所提煉的一系列研發(fā)效能模型，抽象而成的成熟度模型。
在設計與劃分時，我們考慮的維度有兩個：
- 規(guī)?；τ谥写笮徒M織而言， DevOps 模型在設計時，要關注于流程化/標準化、工具化/平臺化四個規(guī)?；蛩?。即選取合適的試點團隊，構建組織的 DevOps 能力，再進行規(guī)?；茝V。
- 組織協(xié)作性。在中大型組織內原先已經有一系列的 DevOps 相關的工具/平臺，如看板、流水線等。這些工具/平臺需要進行調整，以確保更好的協(xié)調性，從而更快的響應業(yè)務變化。
所以，在這個規(guī)?；?DevOps 設計與實施，我們總結出了 DevOps 的四大核心能力，又稱為四大基石。
DevOps Radar
其中，高效協(xié)同是四大基石中最重要的一部分，DevOps 的本質所在。
高效協(xié)同。協(xié)同指的是人與人之前的協(xié)同，即業(yè)務與技術、技術與技術、技術與測試、測試與運維等。在標準化上，我們關注于：協(xié)作設計，從流程上盡可能減少浪費;組織/團隊治理，優(yōu)化團隊與組織結構。在平臺上，我們關注于：需求管理，保障需求過程的概念完整性傳遞，如分析、拆分、協(xié)作;指標化改進;即將協(xié)同平臺作為度量指標的展示平臺，用于持續(xù)性的改進，諸如于技術技術債等。
持續(xù)交付。持續(xù)交付是指能夠按需快速、安全且可持續(xù)地發(fā)布各種類型的更改。在標準化上，我們關注于：服務化架構，即實現(xiàn)類似于微服務架構、服務導向架構的架構化方式，實現(xiàn)技術架構能快速響應業(yè)務變化;版本管理，即從源碼源頭開始對版本進行標準化，通過分支管理、語義化版本等方式實現(xiàn)。在工具上，我們關注于：靈活變更，即通過平臺管理變更與制品;持續(xù)部署，則是與變更相關關聯(lián)的持續(xù)集成與部署。
質量保障。質量保障是指為最終用戶提供高質量的軟件產品。在標準化上，我們關注于：測試策略，即結對質量左移設計測試生命周期，設計測試分層模型進行指標化引導 ;測試方式，定義自動化測試、手動測試的類型、時機、準出標準等。在平臺化上，我們關注于：測試管理，諸如于用例管理與設計、測試數(shù)據管理;質量安全，則是針對于代碼、環(huán)境等進行自動化質量與安全相關的掃描。
環(huán)境支撐。環(huán)境支撐是指用于支撐體系所需要的基礎設施與運維體系。在標準化上，我們關注于：配置管理，即將基礎設施代碼化后，進行相應的基線配置管理、應用配置等;資源管理，即對環(huán)境的管理，以及各環(huán)節(jié)所需要的資源和環(huán)境進行管理。在平臺上，我們關注于：部署管理，即對于發(fā)布環(huán)境的管理，以及諸如灰度發(fā)布等高級部署方式的管理;運維自動化，在運維上進行自動化的監(jiān)控和警告，并支持更好的彈性發(fā)布，諸如于高可用性等。
在規(guī)劃完 DevOps 子域之后，我們可以根據組織的規(guī)模，細分子域以及對應的詳細項。如在協(xié)作設計上，可以進一步地對過程協(xié)作與角色協(xié)作進行設計。如下圖所示：
大型組織 DevOps 模型
考慮到這是一個成熟度模型，所以我們還需要定義成熟度的級別。通常來說，一個成熟度模型應該是從 1~5，又或者是 0~4 四個級別。
對于規(guī)?；慕M織來說，我們只需要 4 個級別，即只存在 2~5 個級別。從流程標準化和平臺化，我們已經消滅級別 1 的存在，它們都是不合規(guī)的。與此同時，從標準化和平臺化的層面來看，事實上，我們也不存在級別 5，因為它們過于靈活和超前。
所以，它只需要三級模型：
Level 2，規(guī)范化。從原始需求的產生到需求的上線，全部遵循組織內定義的規(guī)模標準。需求協(xié)作的過程透明化，流程明確，流轉自動化;持續(xù)交付上，采用組織所定義的實踐，如語義化版本，制品來源與產出可信等;在質量上，采用依據組織定義的模型設計測試策略等;在環(huán)境上，平臺能支撐起規(guī)范化所需要的設計。
Level 3，平臺標準化與自動化。將規(guī)范化的內容，逐一在平臺上進行標準化，即定義多種技術實踐，只能從中二選一，或者三選一。四大基石，都通過這一系列標準來進行自動化。唯一值得商榷的一點是持續(xù)交付上，我們需要一個松耦合的架構，才能支撐起單個團隊的快速交付，諸如于微服務架構、插件化架構等。
Level 4，指標驅動與自動改進。建立一系列的度量模型，對于軟件開發(fā)過程進行全面的度量。與此同時，團隊與平臺根據這些定義的對系統(tǒng)和平臺進行優(yōu)化。如在環(huán)境支撐上，對于應用狀態(tài)的實時監(jiān)控，實現(xiàn)自動化彈性。
對于第 5 級來說，視不同的組織情況，略有不同。如我們所定義的是：
Level 5，云研發(fā)架構。構建基于云端開發(fā)時的基礎設施架構，諸如于云研發(fā)架構、Serverless、Typeflow、Darklang 等，實現(xiàn)基礎設施的自動化與架構的高度解耦。在質量上，對運行時監(jiān)控，實現(xiàn)自動化測試編寫，對代碼進行靜態(tài)分析，實現(xiàn)精益測試;在協(xié)同上，通過構建領域特定語言，實現(xiàn)需求生成代碼骨架;在環(huán)境上，自動實現(xiàn)灰度發(fā)布等特性。
本文轉載自微信公眾號「phodal」，可以通過以下二維碼關注。轉載本文請聯(lián)系phodal公眾號。
本文題目：中大型組織DevOps成熟度模型
文章來源：http://m.fisionsoft.com.cn/article/cddidjg.html
