轉載自： http://www.itbcn.cn/?p=250
維是一個融合多學科(網絡、系統、開發、安全、應用架構、存儲等)的綜合性技術崗位，從最初的網絡管理（網管）發展到現在的系統運維工程師、網絡運維工程師、安全運維工程師、運維開發工程師等，可以看出，運維的分工一直在細化，並且對綜合技能要求越來越高，可以看出，未來運維的發展趨勢是高、精、尖，高表示高度，精表示精通，尖表示尖端，也就是運維職場一定要站在一定的技術高度，在多個技術領域中，要精通某項技能，同時對尖端前沿技術一定要能掌控趨勢。
一、運維職位的發展和趨勢
根據不同的運維領域和技術面以及分工流程三個方面來了解下2019年運維職位的發展趨勢。
1、按領域來劃分
1）、基礎設施運維：IDC/網絡運維、服務器/存儲設備運維
2）、系統運維：系統中間件運維、雲計算平臺運維
3）、數據運維：數據庫運維、大數據技術平臺運維
4）、應用運維：應用軟件系統
5）、雲平臺運維：公有云平臺運維
6）、容器運維：基於容器服務的運維
2、按技術切面來分
1）、安全運維
2）、性能運維
3）、數據運維
4）、集成運維
3、按流程來劃分
1）、構建/持續集成、發佈
2）、安裝部署、升級、遷移、合併、擴展
3）、配置、初始化、配置變更
4）、備份、傳輸、恢復
5）、日誌、監控、預警
6）、診斷排查、優化
二、系統運維技能圖譜
系統運維是運維的基礎，新的一年中，對基礎運維技能要求也在提高，打好系統運維基礎，才能深入學習後面的各種運維技能。
下圖列出了系統運維要掌握的必備技能：
640?wx_fmt=png
三、web運維技能圖譜
web運維是運維崗位中崗位最多的一個，薪資也相對較高，但需要掌握的知識點也比較多，新的技能要掌握，老的運維技能也不能丟，下圖列出了web運維要掌握的各種必備技能。
640?wx_fmt=png
四、大數據運維技能圖譜
大數據從2017年開始逐漸走到生活的各個角落，2018年在逐漸落地，而在2019年，大數據依然火熱，加上國家對大數據產業的扶持，大數據產業在新的一年崗位需求一定會更加大，因此掌握大數據運維技能，就走在了運維的前沿，下圖列出了大數據運維要掌握的各種必備技能。
640?wx_fmt=png
五、容器運維技能圖譜
容器的產生，是一次IT行業的革命，2015 年到 2016 年，是業界普遍認爲的容器技術爆發的一年，短短一年多時間裏，容器技術在中國大陸完成了從零星概念到烽火燎原的壯舉。
時至今日，容器技術在國內大多數企業中落地已成爲一種共識，而國內的生態系統，也呈現出了企業產品、開源社區和公有云齊頭並進的良好局面。因此，2019年也是容器繼續快速落地的一年，下圖列出了大數據運維要掌握的各種必備技能。
640?wx_fmt=png
六、數據爲王的時代
萬丈高樓平地起，高樓穩不穩取決於地基是否紮實。運維數據便是運維管理這座高樓的地基。運維數據大致分爲CMDB、日誌、生產DB、知識庫四個方面。
CMDB中文是配置管理數據庫，存儲與管理企業IT架構中設備的各種配置信息，主要是IT資產管理信息。
日誌數據保護了企業服務器上運行的各種系統產生的應用日誌，系統日誌、設備日誌、數據庫日誌等數據，這部分數據是企業數據的核心。
DB數據主要是所有IT系統的數據庫信息，包括運維管理系統本身的數據庫，數據庫包含生產數據庫、測試數據庫、開發數據庫三種類型。
知識庫主要存儲日常開發、測試、運維管理中發生的事件、問題以及一些經典問題的解決和常用的解決方案，主要起到運維管理輔助的功能。對數據的維護和管理只管重要，特別是日誌數據，對運維來說，通過日誌可以比較準確全面地知道系統或是設備的運行情況，可以返查問題產生的原因，還原問題發生的整個過程。通過日誌也可以提前預測系統可能要發生的問題或是故障，如系統安全日誌，如果網絡攻 擊會在系統安全日誌中有一定的體現。
下面簡單介紹下，運維重點收集的日誌數據有哪些部分以及用途。
1、系統日誌
系統日誌主要指的是操作系統的日誌，主要在/var/log下的各種日誌信息。包含系統操作日誌、系統安全日誌、定時任務日誌等。系統日誌是運維管理安全模塊中審計的重要依據。一般默認的操作系統日誌不能滿足要求，需要對系統的參數進行修改，如爲history命令加上時間戳、IP，並且長久保留歷史等功能。並且對日誌文件進行處理，不允許用戶進行清空命令，只能追加。
2、應用日誌
應用日誌主要記錄應用服務的健康運行情況以及業務操作的具體日誌兩部分。應用監控運行情況反應應用服務的健康狀態，如果應用佔用CPU或是內存過高或是忽高忽低不定，都可以通過分析應用日誌結合業務操作日誌得出結論。業務操作日誌可以爲業務審計提供主要依據。有一些系統喜歡把業務操作日誌寫到數據庫中，這個也是需要注意的。不過不管在哪個地方，要求是不可缺少的，它爲以後業務審計和問題返查提供依據。
3、數據庫日誌
數據庫日誌主要反饋數據庫的運行情況。通過監控和管理數據庫的日誌，及時瞭解數據庫的運行情況，遇到問題及時解決等。可以通過數據庫日誌結合數據庫系統自帶的數據庫如Oracle的系統視圖v$開頭，MySQL的performance_schema等。雖然數據庫的一些信息不是存在日誌中而是在數據庫裏面，但是也可以作爲數據庫日誌的一部分進行管理和監控，已便我們及時知道數據庫的監控狀況，從而預防可能出現的問題。
4、設備日誌
設備日誌一般是一個比較容易忽略的地方，但設備日誌往往可以反映設備的運行情況。交換機故障，防火牆故障等設備故障都可能引起大面積的系統和服務故障。所以設備日誌一定要收集，分析和監控預警。常用的設備日誌有交換機日誌、防火牆日誌、網絡安全設備日誌等。
這麼多的日誌，運維要通過各種手段完成日誌的收集、過濾分析、可視化展示，那麼如何實現這些功能呢，方法很多，例如ELK集成套件（Elasticsearch , Logstash, Kibana）就可以輕鬆實現日誌數據的實時收集、分析傳輸以及圖形化展示。
Elasticsearch是個開源分佈式搜索引擎，提供蒐集、分析、存儲數據三大功能。它的特點有：分佈式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多數據源，自動搜索負載等。
Logstash主要是用來日誌的蒐集、分析、過濾日誌的工具，支持大量的數據獲取方式。一般工作方式爲c/s架構，client端安裝在需要收集日誌的主機上，server端負責將收到的各節點日誌進行過濾、修改等操作在一併發往elasticsearch上去。
Kibana 也是一個開源和免費的工具，Kibana可以爲 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 界面，可以幫助彙總、分析和搜索重要數據日誌。另外，還有Filebeat可以替換Logstash作爲日誌收集工具，Filebeat隸屬於Beats。目前Beats包含四種工具：
Packetbeat（蒐集網絡流量數據）
Topbeat（蒐集系統、進程和文件系統級別的 CPU 和內存使用情況等數據）
Filebeat（蒐集文件數據）
Winlogbeat（蒐集Windows事件日誌數據）可以看到，Beats涵蓋了所有收集日誌數據的各個方面。
那麼要如何使用ELK呢，根據日誌量的不同，對應的ELK架構也不盡相同，看下面幾個常見架構：
640?wx_fmt=png
此架構主要是將Logstash部署在各個節點上搜集相關日誌、數據，並經過分析、過濾後發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch再將數據以分片的形式壓縮存儲，並提供多種API供用戶查詢、操作。用戶可以通過Kibana Web直觀的對日誌進行查詢，並根據需求生成數據報表。
此架構的優點是搭建簡單，易於上手。缺點是Logstash消耗系統資源比較大，運行時佔用CPU和內存資源較高。另外，由於沒有消息隊列緩存，可能存在數據丟失的風險。此架構建議供初學者或數據量小的環境使用。
由此衍生出來了第二種架構：
640?wx_fmt=png
此架構主要特點是引入了消息隊列機制，位於各個節點上的Logstash Agent（一級Logstash，主要用來傳輸數據）先將數據傳遞給消息隊列（常見的有Kafka、Redis等），接着，Logstash server（二級Logstash，主要用來拉取消息隊列數據，過濾並分析數據）將格式化的數據傳遞給Elasticsearch進行存儲。最後，由Kibana將日誌和數據呈現給用戶。由於引入了Kafka（或者Redis）緩存機制，即使遠端Logstash server因故障停止運行，數據也不會丟失，因爲數據已經被存儲下來了。
這種架構適合於較大集羣、數據量一般的應用環境，但由於二級Logstash要分析處理大量數據，同時Elasticsearch也要存儲和索引大量數據，因此它們的負荷會比較重，解決的方法是將它們配置爲集羣模式，以分擔負載。
此架構的優點在於引入了消息隊列機制，均衡了網絡傳輸，從而降低了網絡閉塞尤其是丟失數據的可能性，但依然存在Logstash佔用系統資源過多的問題，在海量數據應用場景下，可能會出現性能瓶頸。
最後，還有第三種架構：
640?wx_fmt=png
這個架構是在上面第二個架構基礎上改進而來的，主要是將前端收集數據的Logstash Agent換成了filebeat，消息隊列使用了kafka集羣，然後將Logstash和Elasticsearch都通過集羣模式進行構建，此架構適合大型集羣、海量數據的業務場景，它通過將前端Logstash Agent替換成filebeat，有效降低了收集日誌對業務系統資源的消耗。同時，消息隊列使用kafka集羣架構，有效保障了收集數據的安全性和穩定性，而後端Logstash和Elasticsearch均採用集羣模式搭建，從整體上提高了ELK系統的高效性、擴展性和吞吐量。
七、用大數據思維做運維監控
大數據分析最早就來源於運維人的日誌分析，到逐漸發展對各種業務的分析，人們發現這些數據蘊涵着非常大的價值，通過實時監測、跟蹤研究對象在互聯網上產生的海量行爲數據，進行挖掘分析，揭示出規律性的東西，提出研究結論和對策。這就是大數據的用途。
同樣，通過大數據分析，我們可以得到各種指標，例如：
1、在業務層面，如團購業務每秒訪問數，團購券每秒驗券數，每分鐘支付、創建訂單等。
2、在應用層面，每個應用的錯誤數，調用過程，訪問的平均耗時，最大耗時，95線等
3、在系統資源層面：如cpu、內存、swap、磁盤、load、主進程存活等
4、在網絡層面： 如丟包、ping存活、流量、tcp連接數等
而這些指標，剛好是運維特別需要的東西。通過大數據分析出的這些指標，可以解決如下方面的問題：
系統健康狀況監控
查找故障根源
系統瓶頸診斷和調優
追蹤安全相關問題那麼如何用大數據思維做運維呢，大數據架構上的一個思維就是：提供一個平臺讓運維方便解決這些問題， 而不是，讓大數據平臺去解決出現的問題。
基本的一個大數據運維架構是這樣的：
640?wx_fmt=png
對於運維的監控，利用大數據思維，需要分三步走：
獲取需要的數據
過濾出異常數據並設置告警閥值
通過第三方監控平臺進行告警所有系統最可靠的就是日誌輸出，系統是不是正常，發生了什麼情況，我們以前是出了問題去查日誌，或者自己寫個腳本定時去分析。現在這些事情都可以整合到一個已有的平臺上，我們唯一要做的就是定義分析日誌的的邏輯。