前記

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

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

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

工具的本質(zhì)其實是一個基礎(chǔ)支撐，有了這個支撐，一系列目標(biāo)的實現(xiàn)才更科學(xué)、高效，簡單示意如下。

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

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

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

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

那么我們?nèi)绾嗡伎荚O(shè)計一套 DevOps 運維服務(wù)體系呢？總結(jié)下來，一個最小的模型為定業(yè)務(wù)規(guī)范、建工作制度、搭 DevOps 系統(tǒng)，以此為最小單元循環(huán)往復(fù)、迭代升級。

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

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

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

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

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

1、變更規(guī)范

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

配置變更：系統(tǒng)配置、應(yīng)用配置；

網(wǎng)絡(luò)變更：網(wǎng)絡(luò)割接、設(shè)備更換；

其它變更：流量調(diào)度、服務(wù)切換、服務(wù)下線…

原則：

制定變更審核流程；

制定變更相關(guān)方通知（群、郵件）；

制定變更回滾策略；

遵循測試、灰度、全量上線的規(guī)則；

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

2、容災(zāi)規(guī)范

服務(wù)災(zāi)備：多機器、多機房；

數(shù)據(jù)災(zāi)備：多備份、異地備份；

網(wǎng)絡(luò)災(zāi)備：多線路、多設(shè)備；

原則：

自動切換 好于 手動切換；

無狀態(tài) 好于 有狀態(tài)；

熱備 好于 冷備；

多機房 好于 單機房。

3、容量規(guī)范

系統(tǒng)容量：木桶原理計算系統(tǒng)的全鏈路容量、用量、余量；

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

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

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

原則：

制定模塊單機容量指標(biāo)（比如QPS、連接數(shù)、在線用戶數(shù)等）；

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

計算當(dāng)前模塊總?cè)萘?，收集?dāng)前的用量，并對比容量計算余量；

系統(tǒng)總?cè)萘靠梢愿鶕?jù)木桶原理，找到短板模塊后，反向計算出來。

4、巡檢規(guī)范

用戶核心指標(biāo)；

服務(wù)核心指標(biāo)；

基礎(chǔ)資源指標(biāo)：服務(wù)器；

依賴資源指標(biāo)：依賴db、依賴接口；

自動化巡檢報告；

值班oncall安排；

原則：

DashBoard核心在于收斂、舍得；

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

5、告警規(guī)范

基礎(chǔ)監(jiān)控：CPU、內(nèi)存、網(wǎng)絡(luò)、IO；

應(yīng)用監(jiān)控：進程、端口；

業(yè)務(wù)監(jiān)控：日志、業(yè)務(wù)埋點；

依賴監(jiān)控：數(shù)據(jù)庫、依賴接口……

原則：

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

核心監(jiān)控形成可排查問題的DashBoard；

告警的價值在于實時發(fā)現(xiàn)故障。

6、預(yù)案規(guī)范

線路切換：移動、電信、聯(lián)通線路切換；

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

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

服務(wù)降級：無法切換時，降低標(biāo)準(zhǔn)繼續(xù)服務(wù)；

數(shù)據(jù)庫切換：主從切換、讀寫切換；

網(wǎng)絡(luò)切換：主備線路切換、鏈路切換；

原則：

域名切換 好于 更換IP；

自動摘除 好于 手動操作；

自動切換 好于 手動切換；

考慮好雪崩事宜。

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

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

故障定級：制定故障定級標(biāo)準(zhǔn)；

制定故障通知、處理規(guī)范；

制定故障復(fù)盤，改進措施按時保量完成的規(guī)范；

原則：

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

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

開發(fā)、運維、臨時權(quán)限；

安全上符合安全審計標(biāo)準(zhǔn)。

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

統(tǒng)一共享知識文檔；

統(tǒng)一共享各種腳本工具；

原則：

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

10、標(biāo)準(zhǔn)化規(guī)范：

主機名標(biāo)準(zhǔn)化；

日志存儲標(biāo)準(zhǔn)化；

日志格式標(biāo)準(zhǔn)化；

域名使用標(biāo)準(zhǔn)化；

軟件安裝目錄結(jié)構(gòu)標(biāo)準(zhǔn)化；

原則：

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

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

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

服務(wù)器

vip

域名

證書

代碼

原則：

資源之間是有關(guān)系的，要建立有關(guān)系的資源管理。

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

二、建工作制度

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

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

上線審批制度

合規(guī)部署制度

日志清理制度

容量管理制度

oncall管理制度

服務(wù)巡檢制度

故障管理制度

安全管理制度

……

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

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

三、搭 DevOps 系統(tǒng)

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

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

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

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

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

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