前記

體系就像是一頂帽子，是對 DevOps 運維的一個深度總結，寫一下工作中的感悟，希望對你有所啟迪。

DevOps 體系是從原始運維一步步走過來的，原始運維好比是本，有了本進而想繼續提升效率、減少出錯、優化流程，就發展到了 DevOps，AIOps……

首先，運維的業務職能規范后形成章程、綱領，在互聯網快速發展的特點下，形成了一套應對”快”和”變”的體系，并不停的迭代升級，工作這些年，體會到千象背后是有恒道的，運維工作一直圍繞高 SLA 和低成本的業務目標運轉著，只是工具在圍繞著體系變來變去。從開發的角度理解，運維體系就像是算法，實現算法的語言就像是工具，DevOps 就是工具的升級。

工具的本質其實是一個基礎支撐，有了這個支撐，一系列目標的實現才更科學、高效，簡單示意如下。

原始階段，運維工程師與各部門無數的磨合、探索下，慢慢形成了最初的體系，其無形的規范著運維的工作和注意事項，工程師通過這個綱領開展日常工作并保障業務的健康發展，這個階段可以說是制度為王、制度規范，沒有系統的運維平臺，有的只是零散的一些大小工具，各種事物基本靠人工、靠制度、靠約束，雖是原始階段，但也是運維最真實的樣子，忙碌而又忙碌，效率總跟不上需求，制度總跟不上執行，與開發的協作總難同一頻道，需要大量的運維人力。

再向后發展，為了提高效率的同時解決與開發間的溝通協作問題，提出了 DevOps，大家開始做自動化、做 DevOps 文化，這個自動化其本質是把運維體系落在一個到多個系統上，通過自動化系統來提高工作效率，同時用系統來實現制度，開發和運維都在一個系統上協作，遵守同樣的規則，協作上也高效多了，這個階段到了技術為王、平臺規范，市場上出現了運維開發，出現了 SRE，各種問題得到了有效的解決，當然解決的程度取決 DevOps 系統做的優劣，這個就參差不齊了，但出現了這個發展方向。

再向后發展，行業領頭羊提出要進一步減少人工參與，用機器自動化替換人工自動化，進而出現了 AIOps。

細心觀察，從原始運維向 DevOps 的演進過程，就是越來越注重技術解決問題的過程，人員需要越來越少，能用技術替代的崗位慢慢被替代，隨著自動化平臺的成熟穩定，理論上理想的終極狀態可能只留”運維平臺+業務運維“，其他運維轉崗業務運維，業務運維轉崗技術運營。

那么我們如何思考設計一套 DevOps 運維服務體系呢？總結下來，一個最小的模型為定業務規范、建工作制度、搭 DevOps 系統，以此為最小單元循環往復、迭代升級。

一、定業務規范

先講個美國人與中國人種地的事兒，美國人建立農場，把種地標準化流程化后，引入工具，幾個人種幾百畝地收成高、成本低反而不累，中國人每個人幾畝地各自作業，收成低、成本高反而都很累。

做運維我感覺也是這個道理，想要批量化、高效率的作業就要規范化，制定各種標準形成規范，如果每個服務各自為戰，就會出現烏泱泱一群人確實忙的腳不離地兒，但就是不出活兒。

那么我們通過 DevOps 要批量管理哪些東西呢，集中一下大概就是資源、服務、規范三類，資源包括像服務器、網絡設備、負載均衡、證書、域名、代碼、容器等，服務包括像圍繞運維提供的服務監控告警、CI/CD、日志分析、服務預案、配置管理等，規范包括像流程、資源、服務的各種標準化等，簡單示意如下。

所以規范是整個 DevOps 體系建設里非常重要的一環，每個規范也對應了一些最佳實踐原則，整理了一些運維中的規范如下：

1、變更規范

上線變更：代碼上線、回滾、擴縮容；

配置變更：系統配置、應用配置；

網絡變更：網絡割接、設備更換；

其它變更：流量調度、服務切換、服務下線…

原則：

制定變更審核流程；

制定變更相關方通知（群、郵件）；

制定變更回滾策略；

遵循測試、灰度、全量上線的規則；

下線變更要將服務器依賴處理干凈，比如說掛著vip、有域名解析。

2、容災規范

服務災備：多機器、多機房；

數據災備：多備份、異地備份；

網絡災備：多線路、多設備；

原則：

自動切換 好于 手動切換；

無狀態 好于 有狀態；

熱備 好于 冷備；

多機房 好于 單機房。

3、容量規范

系統容量：木桶原理計算系統的全鏈路容量、用量、余量；

模塊容量：模塊的容量、用量、余量；

機房容量：分機房的容量、用量、余量；

單機容量：用于反向計算機房、模塊容量；

原則：

制定模塊單機容量指標（比如QPS、連接數、在線用戶數等）；

容量要考慮下行（讀）、上行（寫），考慮存儲增量；

計算當前模塊總容量，收集當前的用量，并對比容量計算余量；

系統總容量可以根據木桶原理，找到短板模塊后，反向計算出來。

4、巡檢規范

用戶核心指標；

服務核心指標；

基礎資源指標：服務器；

依賴資源指標：依賴db、依賴接口；

自動化巡檢報告；

值班oncall安排；

原則：

DashBoard核心在于收斂、舍得；

自動化巡檢的必要性在于異常偵測，預防故障。

5、告警規范

基礎監控：CPU、內存、網絡、IO；

應用監控：進程、端口；

業務監控：日志、業務埋點；

依賴監控：數據庫、依賴接口……

原則：

核心監控收斂成告警，并對告警進行分級，備注告警影響；

核心監控形成可排查問題的DashBoard；

告警的價值在于實時發現故障。

6、預案規范

線路切換：移動、電信、聯通線路切換；

機房切換：不同機房切換；

機器切換：機器故障時進行摘除；

服務降級：無法切換時，降低標準繼續服務；

數據庫切換：主從切換、讀寫切換；

網絡切換：主備線路切換、鏈路切換；

原則：

域名切換 好于 更換IP；

自動摘除 好于 手動操作；

自動切換 好于 手動切換；

考慮好雪崩事宜。

7、故障管理規范

服務分級：確定各服務用戶角度的影響；

故障定級：制定故障定級標準；

制定故障通知、處理規范；

制定故障復盤，改進措施按時保量完成的規范；

原則：

擁抱故障，同類故障不能重復發生。

8、權限安全規范

開發、運維、臨時權限；

安全上符合安全審計標準。

9、文檔、工具規范

統一共享知識文檔；

統一共享各種腳本工具；

原則：

理想的情況是“一站式運維平臺”，一個平臺涵蓋所有工具操作。

10、標準化規范：

主機名標準化；

日志存儲標準化；

日志格式標準化；

域名使用標準化；

軟件安裝目錄結構標準化；

原則：

主機名盡量能看出更多信息，比如服務、模塊、機房等；

日志是排查問題的重要信息，一定要標準化，方便手工排查，更是為了以后用工具處理打下基礎。

11、資源管理規范

服務器

vip

域名

證書

代碼

原則：

資源之間是有關系的，要建立有關系的資源管理。

這里只列了一些常見的業務規范，還有很多規范是要在業務實際問題中去制定的，規范代表了運維的最佳實踐，在DevOps建設中非常重要。

二、建工作制度

制度對應著工作的做事流程方法，會影響到文化，制度的建設情況，也反映了解決問題的層次，好的制度是應該能夠系統化、工具化、可執行、可量化的，這樣在后期才好用DevOps實現，把制度友好的落到運維平臺上。

制度的產生不應該是解決一個case，而是科學的解決一類問題，制度的執行如果僅靠人的自覺自律，是靠不住的，一定要盡可能落到技術上。

上線審批制度

合規部署制度

日志清理制度

容量管理制度

oncall管理制度

服務巡檢制度

故障管理制度

安全管理制度

……

工作中最不缺的是各種制度，如何建是有技巧的，也體現了一個運維的能力，這種能力堅持下去就會變為一種文化，例如考慮問題看到本質，解決問題解決根本。

另外，制度的建立要一定要本著長遠的眼光，科學的態度，DevOps的思想（工具思維）。

三、搭 DevOps 系統

搭系統就是把前面的內容用技術的手段信息化，用科學的工具實現零散的資源管理、規范制度、手工操作，最理想的目標是“一站式運維”，工程師不需要切換系統，一個平臺解決所有事情。

但要管的東西實在太多了，為了專業，市面上首先出現了解決單個點的優秀方案，比如說zabbix、Jenkins…。.但從用戶的角度看就像“五行有了缺一個串”，解決一個業務問題，需要打開N多個系統，來回跳轉，這種方式令人崩潰。好一點的大廠做個單點登陸，解決了賬號混亂的問題，不過依舊是一堆系統，用戶體驗差、操作效率低。

實際上，這些單點的解決方案非常重要，我們在思考設計DevOps的時候，想要做到高質量、低成本，必須用好這些方案像拼積木一樣做資源整合，把他們當作底層的輪子，站在巨人的肩膀上做系統，力爭在應用層做到“一站式”，工作細分到這個程度，指望一個系統解決所有底層問題是不現實的，用圖示意如下。

可以看到，整個工具體系分為了兩層，一層是底層的輪子層，這一層面向的是單個主題的解決，講究深度和系統的解決一類問題，上層是面向SRE的應用層，也可以說是業務層，業務層通過底層輪子封裝后管理了資源、規范制度、運維服務（運維提供的服務）這三類內容，所有的輪子通過一套賬號和權限體系打通。

我們要用好開源社區優秀的輪子，特別是小廠，沒有必要重復建設，要通過輪子的api接口做好應用層的流程封裝，通過應用層的集成，做到一站式操作，應用層作為和SRE的用戶接口，體現了一個 DevOps 的用戶體驗，輪子可以復雜，“一站式運維平臺”要做到盡可能簡單、優雅。

寫到這里，希望對從業的你有所啟迪。
責編AJX