前記

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

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

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

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

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

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

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

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

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

一、定業(yè)務規(guī)范

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

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

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

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

1、變更規(guī)范

• 上線變更：代碼上線、回滾、擴縮容；
• 配置變更：系統(tǒng)配置、應用配置；
• 網絡變更：網絡割接、設備更換；
• 其它變更：流量調度、服務切換、服務下線…

原則：

1. 制定變更審核流程；
2. 制定變更相關方通知（群、郵件）；
3. 制定變更回滾策略；
4. 遵循測試、灰度、全量上線的規(guī)則；

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

2、容災規(guī)范

• 服務災備：多機器、多機房；
• 數據災備：多備份、異地備份；
• 網絡災備：多線路、多設備；

原則：

1. 自動切換 好于 手動切換；
2. 無狀態(tài) 好于 有狀態(tài)；
3. 熱備 好于 冷備；
4. 多機房 好于 單機房。

3、容量規(guī)范

• 系統(tǒng)容量：木桶原理計算系統(tǒng)的全鏈路容量、用量、余量；
• 模塊容量：模塊的容量、用量、余量；
• 機房容量：分機房的容量、用量、余量；
• 單機容量：用于反向計算機房、模塊容量；

原則：

1. 制定模塊單機容量指標（比如QPS、連接數、在線用戶數等）；
2. 容量要考慮下行（讀）、上行（寫），考慮存儲增量；
3. 計算當前模塊總容量，收集當前的用量，并對比容量計算余量；
4. 系統(tǒng)總容量可以根據木桶原理，找到短板模塊后，反向計算出來。

4、巡檢規(guī)范

• 用戶核心指標；
• 服務核心指標；
• 基礎資源指標：服務器；
• 依賴資源指標：依賴db、依賴接口；
• 自動化巡檢報告；
• 值班oncall安排；

原則：

1. DashBoard核心在于收斂、舍得；
2. 自動化巡檢的必要性在于異常偵測，預防故障。

5、告警規(guī)范

• 基礎監(jiān)控：CPU、內存、網絡、IO；
• 應用監(jiān)控：進程、端口；
• 業(yè)務監(jiān)控：日志、業(yè)務埋點；
• 依賴監(jiān)控：數據庫、依賴接口……

原則：

1. 核心監(jiān)控收斂成告警，并對告警進行分級，備注告警影響；
2. 核心監(jiān)控形成可排查問題的DashBoard；
3. 告警的價值在于實時發(fā)現故障。

6、預案規(guī)范

• 線路切換：移動、電信、聯(lián)通線路切換；
• 機房切換：不同機房切換；
• 機器切換：機器故障時進行摘除；
• 服務降級：無法切換時，降低標準繼續(xù)服務；
• 數據庫切換：主從切換、讀寫切換；
• 網絡切換：主備線路切換、鏈路切換；

原則：

1. 域名切換 好于 更換IP；
2. 自動摘除 好于 手動操作；
3. 自動切換 好于 手動切換；
4. 考慮好雪崩事宜。

7、故障管理規(guī)范

• 服務分級：確定各服務用戶角度的影響；
• 故障定級：制定故障定級標準；
• 制定故障通知、處理規(guī)范；
• 制定故障復盤，改進措施按時保量完成的規(guī)范；

原則：

擁抱故障，同類故障不能重復發(fā)生。

8、權限安全規(guī)范

• 開發(fā)、運維、臨時權限；
• 安全上符合安全審計標準。

9、文檔、工具規(guī)范

• 統(tǒng)一共享知識文檔；
• 統(tǒng)一共享各種腳本工具；

原則：

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

10、標準化規(guī)范：

• 主機名標準化；
• 日志存儲標準化；
• 日志格式標準化；
• 域名使用標準化；
• 軟件安裝目錄結構標準化；

原則：

1. 主機名盡量能看出更多信息，比如服務、模塊、機房等；
2. 日志是排查問題的重要信息，一定要標準化，方便手工排查，更是為了以后用工具處理打下基礎。

11、資源管理規(guī)范

• 服務器
• vip
• 域名
• 證書
• 代碼

原則：

1. 資源之間是有關系的，要建立有關系的資源管理。
2. 這里只列了一些常見的業(yè)務規(guī)范，還有很多規(guī)范是要在業(yè)務實際問題中去制定的，規(guī)范代表了運維的最佳實踐，在DevOps建設中非常重要。

二、建工作制度

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

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

• 上線審批制度
• 合規(guī)部署制度
• 日志清理制度
• 容量管理制度
• oncall管理制度
• 服務巡檢制度
• 故障管理制度
• 安全管理制度
• ……

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

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

三、搭 DevOps 系統(tǒng)

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

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

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

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

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

寫到這里，希望對從業(yè)的你有所啟迪。