歡迎大家一起學習交流

運維是一個綜合多學科（網絡、系統、開發、安全、應用架構、存儲等）的綜合性技術崗位，從最初的網絡管理（網絡管理）到今天的系統運維工程師，網絡運維工程師、安全運維工程師、運維開發工程師等，可見運維的分工還在細化，對綜合技能的要求越來越高可見，未來運維的發展趨勢是高、精、尖，高即高，精即精通，銳即尖端，即運維工作場所必須站在一定的技術高度必須能夠控制趨勢。

一、運維崗位的發展與趨勢

根據不同運維領域和技術方面的三個方面，以及分工流程，了解2019年運維崗位的發展趨勢。

1、由字段定義

1）、基礎設施運維：IDC/網絡運維、服務器/存儲設備運維

2）、系統運維：系統中間件運維、云測算平臺運維

3）、數據運維：數據庫運維、大數據技術平臺運維

4）、應用運維：應用軟件系統

5）、云平臺運維：公有云平臺運維

6）、容器運維：基于容器服務的運維

2、按技術方面分

1）、安全運維

2）、性能運維

3）、數據運維

4）、一體化運維

3、由進程定義

1），構建/持續集成，發布

2），安裝部署，升級，遷移，合并，擴展

3），配置，初始化，配置更改

4），備份，傳輸，恢復

5）、日志、監控、警報

6），診斷故障排除，優化

二、系統運維技能圖

系統運維是運維的基礎。新的一年，對基本運維技能的要求也越來越高。打好系統運維基礎，可以深入學習身邊的各種運維技巧。

右圖列出了系統運維必備的技能：

三、Web運維技能圖

Web運維是運維崗位中崗位最多的，薪資也比較高，但是需要掌握的知識點很多。新技能要掌握，老的運維技能不能丟。 Web運維需要掌握的各種必備技能。

四、大數據運維技能圖

大數據從2017年開始逐漸走進生活的各個角落，2018年逐漸落地，2019年大數據依舊火熱。再加上國家對大數據產業的扶持，大數據產業進入了新時代。每年的工作需求肯定會更強，所以掌握大數據運維的技能是運維的最前沿。

五、容器運維技能圖

容器的形成是 IT 行業的一場革命。從 2015 年到 2016 年，業界普遍感受到容器技術的爆發。短短一年多時間，容器技術在中國大陸完成了零星的概念。為烽火燎原之大功。

如今，容器技術在國外大部分企業的落地已經成為共識，國外生態也呈現出企業產品、開源社區、公有云齊頭并進的良好局面。為此，2019年也是容器繼續快速落地的一年。右圖列出了大數據運維必須掌握的各種基本技能。

六、數據為王的時代

高層建筑從地面開始，高層建筑的穩定性取決于地基是否牢固。運維數據是這座高層建筑運維的基礎。運維數據大致分為四個方面：CMDB、日志、生產DB、知識庫。

只有數據的維護和管理才重要，尤其是日志數據。對于運維來說，通過日志可以更準確、更全面地了解系統或設備的運行情況，并可以查看和恢復問題的原因。整個過程。通過日志服務器運維，還可以提前預知系統中可能出現的問題或故障，比如系統安全日志。如果網絡攻擊會在系統安全日志中體現出來。

下面簡單介紹一下運維收集的日志數據的組成部分和用途。

1、系統日志

系統日志主要是指操作系統的日志，主要是/var/log下的各種日志信息。包含系統運行日志、系統安全日志、定時任務日志等。系統日志是運維管理安全模塊中審計的重要依據。通常，默認的操作系統日志不能滿足要求，需要更改系統的參數，例如給命令添加時間戳和IP，以及長時間保留歷史記錄。另外對日志文件進行處理，不允許用戶執行空命令，只能追加。

2、應用日志

應用日志主要記錄應用服務的健康運行和業務運行的具體日志。應用監控的運行狀態反映了應用服務的健康狀況。如果某個應用占用了CPU，或者顯存太低，或者出現波動，可以通過分析應用日志和業務運行日志來推斷。業務操作日志可以為業務審計提供主要依據。有些系統喜歡把業務操作日志放到數據庫里，這也是需要注意的。但是，無論在哪里，需求都是不可或缺的，為后續的業務審計和問題回顧提供了依據。

3、數據庫日志

數據庫日志主要報告數據庫的運行狀態。通過對數據庫的日志進行監控和管理，可以及時了解數據庫的運行情況，及時解決問題。可以將數據庫日志與數據庫系統自帶的數據庫系統結合起來，比如系統視圖v$、MySQL等也作為數據庫日志的一部分進行管理和監控，我們已經及時知道數據庫的監控狀態，以防可能出現的問題。

4、設備日志

設備日志通常是一個容易忽略的地方，但它往往可以反映設備的運行情況。交換機故障、防火墻故障等設備故障都可能導致大規模的系統和服務故障。因此，必須收集、分析和監控設備日志，以進行預警。常用的設備日志包括交換機日志、防火墻日志、網絡安全設備日志。

日志這么多，運維必須通過各種手段完成日志采集、過濾分析、可視化展示。那么如何實現這個功能，有很多技巧，比如ELK集成套件(,,)可以很方便的實現日志數據的實時采集、分析傳輸、圖形化展示。

此外，還有一個附屬于 Beats 的日志收集工具。 Beats 目前包括四種工具：

（收集網絡流量數據）

（收集系統、進程和文件系統級別的 CPU 和視頻內存使用情況等數據）

（收集文件數據）

（收集風暴日志數據）

如您所見，Beats 涵蓋了收集日志數據的所有方面。

如何以這種方式使用ELK？根據日志量的不同，對應的ELK架構也不同。請參閱以下常見架構：

該框架主要收集各個節點上的相關日志和數據，經過分析過濾后發送到遠程服務器存儲。然后將數據壓縮并存儲在分片中，并提供多種API供用戶查詢和操作。用戶可以通過Web直觀地查詢日志，并根據需要生成數據報表。

這個框架的優點是構建簡單，使用方便。缺點是對系統資源的消耗比較大，運行時占用CPU和顯存資源。此外，由于沒有消息隊列緩存，因此可能存在數據丟失的風險。建議初學者或數據量較小的環境使用此框架。

這就引出了第二個框架：

這種架構的主要特點是引入了消息隊列機制。每個節點上的Agent（第一級，主要用于傳輸數據）首先將數據傳輸到消息隊列（常見的Kafka、Redis等），然后，（第二級主要用于拉取消息隊列數據，過濾和分析數據）并將低級數據傳遞給存儲。最后，通過將日志和數據呈現給用戶。由于引入了Kafka（或Redis）緩存機制，雖然遠端因故障停止運行，但不會因為數據已經存儲而丟失數據。

這些架構適用于集群大、數據量一般的應用環境，但是由于需要分析處理大量數據，以及存儲和索引大量數據，負載會比較重解決方案是將它們配置為集群模式以分擔負載。

這種架構的優點是引入了消息隊列機制來平衡網絡傳輸，從而增加了網絡阻塞的可能性，尤其是數據丟失，但是仍然存在占用系統資源過多的問題。服務器運維，可能會出現性能困境。

最后還有第三個框架：

這個框架是在其中的第二個框架的基礎上改進的，主要是將后端收集數據的Agent替換為消息隊列的Kafka集群，然后通過集群模式進行改進。該架構適用于集群小、數據量大的業務場景。通過替換后端Agent來收集日志，有效減少業務系統資源的消耗。同時消息隊列采用Kafka集群架構，有效保證了采集數據的安全性和穩定性，前端和集群采用集群方式構建，提升了效率、擴展性和吞吐量ELK 系統作為一個整體。

七、運用大數據思維進行運維監控

大數據分析從運維人員的日志分析開始，逐步發展到各種業務的分析。人們發現這種數據蘊含著巨大的價值。通過對互聯網上研究對象的實時檢測和跟蹤所形成的海量行為數據，挖掘分析，闡明規律，提出研究推論和對策。這就是大數據的用途。

同樣，通過大數據分析，我們可以得到各種指標，比如：

1、業務層面，如團購業務每秒訪問量、每秒檢查團購券數量、每分鐘支付、創建訂單等。

2、在應用層面，每個應用的錯誤數、調用進程、平均訪問時長、最大時長、95行等

3、系統資源層面：如cpu、內存、swap、磁盤、負載、主進程生存等

4、網絡層面：如丟包、ping生存、流量、tcp連接等

而這種指標正是運維非常需要的。這種通過大數據分析的指標可以解決以下問題：

系統健康監測

找出問題的癥結

系統問題的診斷和調整

跟蹤安全相關問題

如何運用大數據思維進行運維？大數據架構的一個思路就是提供一個運維平臺方便地解決這類問題，而不是讓大數據平臺解決出現的問題。

一個基本的大數據運維框架如下：

對于運維的監控，借助大數據思維，需要分三步走：

獲取所需數據

過濾異常數據并設置報警閾值

通過第三方監控平臺發出警報

所有系統中最可靠的是日志輸出。系統是否正常，發生了什么，我們習慣在出現問題的時候查看日志，或者寫一個腳本定期分析。現在這種東西可以集成到現有的平臺中，我們唯一要做的就是定義解析日志的邏輯。

好了，這就是明天給大家介紹的新時代核心運維技能。抓住機遇，開始新的學習！有問題可以一起學習交流。