前記

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

DevOps 體系是從原始運(yùn)維一步步走過(guò)來(lái)的，原始運(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)對(duì)”快”和”變”的體系，并不停的迭代升級(jí)，工作這些年，體會(huì)到千象背后是有恒道的，運(yùn)維工作一直圍繞高 SLA 和低成本的業(yè)務(wù)目標(biāo)運(yùn)轉(zhuǎn)著，只是工具在圍繞著體系變來(lái)變?nèi)ァ拈_(kāi)發(fā)的角度理解，運(yùn)維體系就像是算法，實(shí)現(xiàn)算法的語(yǔ)言就像是工具，DevOps 就是工具的升級(jí)。

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

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

再向后發(fā)展，為了提高效率的同時(shí)解決與開(kāi)發(fā)間的溝通協(xié)作問(wèn)題，提出了 DevOps，大家開(kāi)始做自動(dòng)化、做 DevOps 文化，這個(gè)自動(dòng)化其本質(zhì)是把運(yùn)維體系落在一個(gè)到多個(gè)系統(tǒng)上，通過(guò)自動(dòng)化系統(tǒng)來(lái)提高工作效率，同時(shí)用系統(tǒng)來(lái)實(shí)現(xiàn)制度，開(kāi)發(fā)和運(yùn)維都在一個(gè)系統(tǒng)上協(xié)作，遵守同樣的規(guī)則，協(xié)作上也高效多了，這個(gè)階段到了技術(shù)為王、平臺(tái)規(guī)范，市場(chǎng)上出現(xiàn)了運(yùn)維開(kāi)發(fā)，出現(xiàn)了 SRE，各種問(wèn)題得到了有效的解決，當(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)過(guò)程，就是越來(lái)越注重技術(shù)解決問(wèn)題的過(guò)程，人員需要越來(lái)越少，能用技術(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)營(yíng)。

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

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

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

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

那么我們通過(guò) 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)化等，簡(jiǎn)單示意如下。

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

1、變更規(guī)范

• 上線變更：代碼上線、回滾、擴(kuò)縮容；
• 配置變更：系統(tǒng)配置、應(yīng)用配置；
• 網(wǎng)絡(luò)變更：網(wǎng)絡(luò)割接、設(shè)備更換；
• 其它變更：流量調(diào)度、服務(wù)切換、服務(wù)下線…

原則：

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

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

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

• 服務(wù)災(zāi)備：多機(jī)器、多機(jī)房；
• 數(shù)據(jù)災(zāi)備：多備份、異地備份；
• 網(wǎng)絡(luò)災(zāi)備：多線路、多設(shè)備；

原則：

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

3、容量規(guī)范

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

原則：

1. 制定模塊單機(jī)容量指標(biāo)（比如QPS、連接數(shù)、在線用戶數(shù)等）；
2. 容量要考慮下行（讀）、上行（寫），考慮存儲(chǔ)增量；
3. 計(jì)算當(dāng)前模塊總?cè)萘浚占?dāng)前的用量，并對(duì)比容量計(jì)算余量；
4. 系統(tǒng)總?cè)萘靠梢愿鶕?jù)木桶原理，找到短板模塊后，反向計(jì)算出來(lái)。

4、巡檢規(guī)范

• 用戶核心指標(biāo)；
• 服務(wù)核心指標(biāo)；
• 基礎(chǔ)資源指標(biāo)：服務(wù)器；
• 依賴資源指標(biāo)：依賴db、依賴接口；
• 自動(dòng)化巡檢報(bào)告；
• 值班oncall安排；

原則：

1. DashBoard核心在于收斂、舍得；
2. 自動(dòng)化巡檢的必要性在于異常偵測(cè)，預(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ù)庫(kù)、依賴接口……

原則：

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

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

• 線路切換：移動(dòng)、電信、聯(lián)通線路切換；
• 機(jī)房切換：不同機(jī)房切換；
• 機(jī)器切換：機(jī)器故障時(shí)進(jìn)行摘除；
• 服務(wù)降級(jí)：無(wú)法切換時(shí)，降低標(biāo)準(zhǔn)繼續(xù)服務(wù)；
• 數(shù)據(jù)庫(kù)切換：主從切換、讀寫切換；
• 網(wǎng)絡(luò)切換：主備線路切換、鏈路切換；

原則：

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

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

• 服務(wù)分級(jí)：確定各服務(wù)用戶角度的影響；
• 故障定級(jí)：制定故障定級(jí)標(biāo)準(zhǔn)；
• 制定故障通知、處理規(guī)范；
• 制定故障復(fù)盤，改進(jìn)措施按時(shí)保量完成的規(guī)范；

原則：

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

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

• 開(kāi)發(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)化；

原則：

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

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

• 服務(wù)器
• vip
• 域名
• 證書
• 代碼

原則：

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

二、建工作制度

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

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

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

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

另外，制度的建立要一定要本著長(zhǎng)遠(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)秀方案，比如說(shuō)zabbix、Jenkins…..但從用戶的角度看就像“五行有了缺一個(gè)串”，解決一個(gè)業(yè)務(wù)問(wèn)題，需要打開(kāi)N多個(gè)系統(tǒng)，來(lái)回跳轉(zhuǎn)，這種方式令人崩潰。好一點(diǎn)的大廠做個(gè)單點(diǎn)登陸，解決了賬號(hào)混亂的問(wèn)題，不過(guò)依舊是一堆系統(tǒng)，用戶體驗(yàn)差、操作效率低。

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

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

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

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