如何從零思考設計你的 DevOps 運維服務體系？
前記
體系就像是一頂帽子，是對 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 的用戶體驗，輪子可以復雜，“一站式運維平臺”要做到盡可能簡單、優雅。
寫到這里，希望對從業的你有所啟迪。
