前記：所謂幹一行愛一行，人生處處是《圍城》這是人性，但在改變那一刻之前，自應全心全意研究本行，全心投入，不計回報，用心在當下，寫到體系就像是前面所有博客的一個帽子，現在把他總結整理出來，希望對你有所啓迪。
自動化運維體系是一步步發展過來的，構造自動化運維體系的前提得先了解原始運維體系，原始運維體系好比是本，有了本才知道怎麼實現自動化、實現Aiops.......
首先，運維有其業務職能，全部職能梳理規範後形成章程、綱領和體系，互聯網最大的特點是“快”和“變”，但不代表沒有固定的體系，恰巧有的是應對"快"和"變"的體系，從事一線運維這些年，體會到千象背後是有恆道的，所謂萬變不離其宗，運維工作一切圍繞高SLA和低成本爲目標運轉，只是工具在圍繞運維體系變來變去而已，從開發的角度理解運維體系就像是算法，實現算法的語言和方式就像是工具，自動化就是工具的升級。
在前期，運維人員在和各部門無數的磨合、探索中慢慢形成了工作體系，也就是運維體系，此體系無形的規範了運維的工作，以及工作該怎麼幹，運維人員通過這個無形的綱領開展日常工作並保障業務的健康發展，這個階段可以說是制度爲王、制度規範，沒有系統的自動化運維平臺，有的只是零散的一些大小工具，各種事物基本靠人工、靠制度、靠約束，雖是原始階段，但也是運維最真實的樣子，忙碌而又忙碌，效率總跟不上需求，制度總跟不上執行，與開發的協作總難同一頻道，需要大量的運維人力。
再向後發展，爲了提高效率的同時解決與開發間的溝通協作問題，提出了DevOps，大家開始做自動化，這個自動化其本質是把運維體系落在一個到多個系統上，通過自動化系統來提高工作效率，同時用系統來實現制度，開發和運維都在一個系統上協作，遵守同樣的規則，協作上也高效多了，這個階段到了技術爲王、平臺規範，市場上出現了運維開發，出現了SRE，各種問題得到了有效的解決，當然解決的程度取決自動化系統做的優劣，這個就參差不齊了，但出現了這個發展方向。
再向後發展，出現了AiOps......
個人感覺，有兩個維度變化很明顯，越來越注重技術解決問題，人員需要越來越少，能用技術工具替代的崗位在慢慢被替代，隨着自動化平臺的成熟穩定，理論上理想的終極狀態可能只留"運維平臺+應用運維"，其他運維轉崗應用運維，應用運維轉崗技術運營。
那麼如果你恰好接到一個從零開始建設的運維工作，怎麼有序規劃、快速迭代到自動化運維體系呢？下面我們分兩步把他拆開看一看。
一、 規範工作，形成運維服務體系（制度爲王）
1、變更規範
- 上線變更：代碼上線、擴容；
- 配置變更：系統配置、應用配置；
- 網絡變更：網絡割接、設備更換；
- 其它變更：流量調度、服務切換、服務下線...
- 原則：a、制定變更審覈流程；
b、制定變更相關方通知（羣、郵件）；
c、制定變更回滾策略；
d、遵循測試、單機灰度、機房灰度、全量上線的規則；
e、下線變更要將服務器依賴處理乾淨，比如說掛着vip、有域名解析。
2、災備規範
- 服務災備：多機器、多機房；
- 數據災備：多備份、異地備份；
- 網絡災備：多線路、多設備；
- 原則：a、自動切換 > 手動切換；
b、無狀態 > 有狀態；
c、熱備 > 冷備；
d、多機房 > 單機房。
3、預案規範
- 線路切換：移動、電信、聯通、BGP等多線路切換；
- 機房切換：不同機房切換；
- 機器切換：不同機器切換、故障機器自動摘掉；
- 服務降級：無法切換時，如何降低標準繼續服務；
- 數據庫切換：主從切換、讀寫切換；
- 網絡切換：主備線路切換、鏈路切換；
- 原則：a、域名切換 > 更換IP；
b、自動摘掉 > 手動操作；
c、自動切換 > 手動切換；
d、考慮好雪崩事宜。
4、容量規範
- 系統容量：木桶原理計算系統的上、下行容量、用量、餘量；
- 模塊容量：模塊的上、下行容量、用量、餘量；
- 機房容量：分機房的容量、用量、餘量；
- 單機容量：壓測單機的容量，一般用於反向計算機房、模塊容量；
- 原則：a、制定模塊單機容量指標，並記錄文檔（比如QPS、連接數、在線用戶數等），
b、容量要考慮下行（讀）、上行（寫），考慮存儲增量；
c、計算當前模塊總容量，收集當前的用量，並對比容量計算餘量；
d、系統總容量可以根據木桶原理，找到短板模塊後，反向計算出來。
5、告警規範
- 基礎監控：CPU、內存、網絡、IO；
- 應用監控：進程、端口；
- 業務監控：日誌、業務埋點；
- 依賴監控：數據庫、依賴接口...
- 原則：a、核心監控收斂成告警，並對告警進行分級，備註告警影響；
b、核心監控形成可排查問題的DashBoard；
c、告警的價值在於實時發現故障，是事中和事後的。
6、巡檢規範
- 系統核心指標DashBoard；
- 分模塊核心指標DashBoard；
- 基礎資源核心指標DashBoard：服務器；
- 依賴資源核心指標DashBorad：依賴db、依賴接口；
- 自動化巡檢報告；
- 值班oncall安排；
- 原則：a、DashBoard核心在於收斂、捨得；
b、自動化巡檢的必要性在於異常偵測，預防故障，是事前的。
7、權限安全規範
- 開發、運維、臨時權限；
- 安全上符合安全審計標準。
8、故障管理規範
- 服務分級，確定各服務用戶角度的影響；
- 制定分級後各服務SLA，制定問題、故障分級標準；
- 制定故障通知、處理規範；
- 制定故障覆盤，改進措施按時保量完成的規範；
- 原則：a、擁抱故障，但同一故障解決後，不應重複出現。
9、文檔、工具規範
- 統一共享知識文檔；
- 統一共享各種腳本工具；
- 原則：a、理想的情況是“一站式運維平臺”，一個平臺涵蓋所有工具操作。
10、標準化規範：
- 主機名標準化；
- 應用軟件安裝結構標準化；
- 日誌存儲標準化；
- 日誌格式標準化；
- 域名使用標準化；
- 原則：a、主機名儘量能看出更多信息，比如服務、模塊、機房等；
b、日誌是排查問題的重要信息，一定要標準化，方便手工排查，更是爲了以後用工具處理打下基礎。
二、 技術實現制度，搭平臺，建設自動化運維體系（技術爲王）
有了第一階段的運維體系爲基礎，就可以考慮用平臺工具來實現零散的手工操作、制度規範，理想的情況是“一站式運維平臺”解決所有事情，平臺後端集成使用開源技術方案作爲支撐，對於用戶優雅而統一，目前開源項目中尚未找到很好的“一站式運維”產品，下面羅列一下常用的解決某類問題的技術方案。
1、監控告警方案
- Zabbix：https://www.zabbix.com
- OpenFlcon：https://github.com/open-falcon/falcon-plus
- Prometheus：https://prometheus.io
- Grafana：https://grafana.com
2、日誌分析方案
- ELKB：https://www.elastic.co
3、安全堡壘機方案
- JumpServer：http://www.jumpserver.org
4、持續集成部署CI/CD方案
- jenkins：https://jenkins.io
- GitLab：https://about.gitlab.com
5、容器技術方案
- Kubernetes：https://kubernetes.io
6、配管自動化方案
- Puppet：https://puppet.com
- Saltstack：https://www.saltstack.com
- Ansible：https://www.ansible.com
8、一些運管集成方案
- SaltShaker：https://github.com/yueyongyue/saltshaker_api
- 騰訊藍..鯨：https://github.com/Tencent/bk-cmdb
- OpsManage：https://github.com/welliamcao/OpsManage
......
從制度到技術的進化就是效率提升、成本降低的過程，也是培養用技術工程思想解決問題的過程，自動化做的越好，所需要的人力反而越少，解決各種問題的效率也越高，現在市場上解決單個點的方案如上羅列有很多，但從用戶的角度看就像“五行有了缺一個串”，做一個事兒打開一個系統實在太痛苦了，好一點的大廠做個單點登錄，解決了一系統一賬戶的問題，不過也是一堆系統，用戶體驗差。即便如此，爲了“一站式運維”的方向，很多企業都會量身開發一套個性化的運維管理系統，將資源、流程、事物、審覈、自動化.....儘量封裝到一個平臺上，提高運維操作效率，相信將來會更方便、智能。
至於最近熱炒的AiOps，更多的也是爲了提升效率、降低成本、降低操作出錯，讓運維更加智能化、無人化，作爲一線運維，從實際情況看，可能只適合部分場景，有些操作、判斷還是離不開人。
查看更多請到博主原創站：運維網咖社（www.net-add.com）