漫談運維服務體系的建設和發展——從制度到技術

前記:所謂幹一行愛一行,人生處處是《圍城》這是人性,但在改變那一刻之前,自應全心全意研究本行,全心投入,不計回報,用心在當下,寫到體系就像是前面所有博客的一個帽子,現在把他總結整理出來,希望對你有所啓迪。

任何崗位都有其業務職能,全部職能梳理後形成章程、綱領和體系,運維亦然,互聯網最大的特點是“快”和“變”,但不代表沒有固定的體系,恰巧有的是應對"快"和"變"的體系,從事一線運維這些年,邊幹邊體會,千象背後是有恆道的,所謂萬變不離其宗,運維工作一切圍繞高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 

     ......

後附:文章導航

一、運維體系、技術雜談

    1、透過大型門戶平臺保障詮釋"應用運維架構"方法論

    2、老司機告訴你應用運維如何系統高效的接手一個新業務?

    3、運維中業務數據的認識和應用——“數據之美”

    4、微服務架構下業務單機QPS跑不上去應從哪些角度分析

    5、應用運維角度分析大型互聯網應用架構設計與優化的“4要素”

二、Linux自動化運維知識棧

 - Linux基礎

      1、回眸總結linux的啓動過程

      2、linux基礎學習筆記(一)——個人用心總結

      3、linux管道結合grep使用小知識一則(隨記)

      4、4核服務器cpu使用率10%負載飆到23.5故障排查

      5、linux下PXE無人值守環境自動安裝腳本

      6、mysql互主自動化配置腳本

      7、shell腳本——linux主機監控

 - 監控告警

      1、業務層面如何快速擁有自己的網絡監控?

      2、論TCP狀態監控在異常檢測、業務告警中的重要性    

      3、輕量級流式日誌計算分析plog+(zabbix+grafana)

      4、zabbix_sender主動上傳k/v監控nginx日誌狀態碼

      5、基於etcd+confd對監控prometheus的服務註冊發現

 - 日誌分析

      1、玩兒透圍繞ELK體系大型日誌分析集羣方案設計.搭建.調優.管理

      2、運維數據分析平臺建設的幾個段位——架構演進

      3、深入淺出剖析Elasticsearch的工作原理

      4、grafana加es數據源想實現關聯選擇鑽取的效果麼?

      5、正則表達式與grok正則解析梳理記錄

      6、logstash結合filebeat進行多套日誌的分離清洗

      7、filebeat6.2.4多套日誌採集併入不同kafka小記

      8、kafka與zookeeper管理之kafka-manager踩坑小記

      9、logstash中timestamp的轉換及json日誌的解析

      10、elk日誌收集之rsyslog軟連接監控文件深度坑

      11、ELK之ES2.4.1雙實例平滑升級調優至5.2.1踩坑並supervisor管理記

      12、巧用rsyslog收集多套日誌並做單套日誌的過濾分離

 - 容器技術

      1、步步爲營實踐總結kubernetes1.8.2安裝配置部署

      2、kubernetes1.8.2安裝配置calico2.6.6(附4種網絡模式性能數據)

      3、基於etcd+confd通過nginx對docker服務註冊發現詳解

三、網絡TCP/IP/HTTP協議

      1、wireshark優化顯示對響應頭髮送順序可能的誤導

      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...報錯

      6、應對防火牆使用nginx快速搭建http協議代理   

      7、nginx配置特定404返回默認圖並自定義狀態碼標記

      8、php-fpm多實例提升系統吞吐量和服務器資源利用率

      9、nginx多條件if判斷後rewrite,減輕後端php工作壓力(隨筆)

      10、Nginx/tengine裏的那些timeout時間

      11、老nginx集羣向tengine的升級改造,性能提升數倍

五、CDN架構及cache節點性能優化

 - CDN業務結構

      1、深入淺出剖析內容分發網絡CDN業務架構

      2、CDN的cache節點(http)結構及工作原理總結

      3、在互聯網你的請求是如何被引導、劫持的?

      4、說說爲什麼要有CNAME

      5、shell腳本——爬取域名一級頁面元素並判斷其可緩存性

 - Cache緩存節點

      1、Nginx/tengine做cache時緩存機制—存不存、存多久、用不用方法論

      2、透過ATS緩存配置看如何判斷HTTP資源是否可緩性

      3、ATS巧玩兒緩存策略增加動態服務吞吐量

      4、調整ATS日誌處理機制及相關腳本

查看更多請到博主原創站:運維網咖社(www.net-add.com)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章