前記:所謂幹一行愛一行,人生處處是《圍城》這是人性,但在改變那一刻之前,自應全心全意研究本行,全心投入,不計回報,用心在當下,寫到體系就像是前面所有博客的一個帽子,現在把他總結整理出來,希望對你有所啓迪。
任何崗位都有其業務職能,全部職能梳理後形成章程、綱領和體系,運維亦然,互聯網最大的特點是“快”和“變”,但不代表沒有固定的體系,恰巧有的是應對"快"和"變"的體系,從事一線運維這些年,邊幹邊體會,千象背後是有恆道的,所謂萬變不離其宗,運維工作一切圍繞高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
- Salttack: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
......
後附:文章導航
一、運維體系、技術雜談
5、應用運維角度分析大型互聯網應用架構設計與優化的“4要素”
二、Linux自動化運維知識棧
- Linux基礎
- 監控告警
3、輕量級流式日誌計算分析plog+(zabbix+grafana)
4、zabbix_sender主動上傳k/v監控nginx日誌狀態碼
5、基於etcd+confd對監控prometheus的服務註冊發現
- 日誌分析
1、玩兒透圍繞ELK體系大型日誌分析集羣方案設計.搭建.調優.管理
6、logstash結合filebeat進行多套日誌的分離清洗
7、filebeat6.2.4多套日誌採集併入不同kafka小記
8、kafka與zookeeper管理之kafka-manager踩坑小記
9、logstash中timestamp的轉換及json日誌的解析
11、ELK之ES2.4.1雙實例平滑升級調優至5.2.1踩坑並supervisor管理記
- 容器技術
1、步步爲營實踐總結kubernetes1.8.2安裝配置部署
2、kubernetes1.8.2安裝配置calico2.6.6(附4種網絡模式性能數據)
3、基於etcd+confd通過nginx對docker服務註冊發現詳解
三、網絡TCP/IP/HTTP協議
2、弄清TIME_WAIT徹底解決TCP:time wait bucket table overflow
3、大併發下TCP內存消耗優化小記(86萬併發業務正常服務)
四、WebService架構及性能優化
1、記一次HttpDns業務調優——fastcgi-cache容量提升5倍
2、WebService之nginx+(php-fpm)結構模型剖析及優化
3、詳解nginx的原生被動健康檢查機制&災備使用(含測試)
4、小記解決nginx500錯誤之could not allocate node in cache keys zone "cache_one"
5、tengine2.0.1升級到2.2.2徹底消滅SSL_shutdown() failed...報錯
9、nginx多條件if判斷後rewrite,減輕後端php工作壓力(隨筆)
11、老nginx集羣向tengine的升級改造,性能提升數倍
五、CDN架構及cache節點性能優化
- CDN業務結構
- Cache緩存節點
1、Nginx/tengine做cache時緩存機制—存不存、存多久、用不用方法論
查看更多請到博主原創站:運維網咖社(www.net-add.com)