前記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、變更規(guī)范

上線變更：代碼上線、回滾、擴(kuò)縮容；

配置變更：系統(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)備：多機(jī)器、多機(jī)房；

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

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

原則：

自動(dòng)切換 好于 手動(dòng)切換；

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

熱備 好于 冷備；

多機(jī)房 好于 單機(jī)房。

3、容量規(guī)范

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

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

機(jī)房容量：分機(jī)房的容量、用量、余量；

單機(jī)容量：用于反向計(jì)算機(jī)房、模塊容量；

原則：

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

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

計(jì)算當(dāng)前模塊總?cè)萘浚占?dāng)前的用量，并對比容量計(jì)算余量；

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

4、巡檢規(guī)范

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

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

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

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

自動(dòng)化巡檢報(bào)告；

值班oncall安排；

原則：

DashBoard核心在于收斂、舍得；

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

5、告警規(guī)范

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

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

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

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

原則：

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

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

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

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

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

機(jī)房切換：不同機(jī)房切換；

機(jī)器切換：機(jī)器故障時(shí)進(jìn)行摘除；

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

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

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

原則：

域名切換 好于 更換IP；

自動(dòng)摘除 好于 手動(dòng)操作；

自動(dòng)切換 好于 手動(dòng)切換；

考慮好雪崩事宜。

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

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

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

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

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

原則：

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

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

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

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

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

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

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

原則：

理想的情況是“一站式運(yùn)維平臺(tái)”，一個(gè)平臺(tái)涵蓋所有工具操作。

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

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

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

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

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

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

原則：

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

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

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

服務(wù)器

vip

域名

證書

代碼

原則：

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

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

二、建工作制度

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

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

上線審批制度

合規(guī)部署制度

日志清理制度

容量管理制度

oncall管理制度

服務(wù)巡檢制度

故障管理制度

安全管理制度

……

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

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

三、搭 DevOps 系統(tǒng)

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

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

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

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

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

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