傳統(tǒng)的IT架構(gòu)使用了這么多年，所有的監(jiān)控設(shè)備以及網(wǎng)絡(luò)架構(gòu)都是基于此打造，那么在傳統(tǒng)架構(gòu)虛擬化、云化后的今天，如何針對虛擬化、云計算的環(huán)境如IaaS、PaaS進行運維?應(yīng)該注重哪些領(lǐng)域?本文提出了非常清晰的思路，可供參考。

背景

[[320337]]

在云時代我們完全看不到任何物理設(shè)備，也不再關(guān)心硬件的穩(wěn)定性和可靠性，因為當我們的硬件發(fā)生故障時，業(yè)務(wù)會第一時間切換到其他的節(jié)點，甚至切換到其他的數(shù)據(jù)中心，這樣我們的硬件維修完全可以等到方便的時候再進行。運維自動化是整個云運維的核心。要面對成千上萬臺的服務(wù)器，產(chǎn)生的運維已經(jīng)是人工方式不可能完成的任務(wù)，這就需要一整套高效自動化的運維管理工具，來幫我們實現(xiàn)運維的自動化。當運維的自動化程度越來越高的時候，我們會發(fā)現(xiàn)其實云運維維護的是代碼，而傳統(tǒng)運維維護的是硬件。最后，云運維對我們維護能力的要求也越來越高，我們不但要掌握操作系統(tǒng)，還要不停學(xué)習(xí)各種云計算相關(guān)的知識和理論，還要掌握一些開源的工具，同時還要具備開發(fā)定制的能力，要不停的去開發(fā)定制自動化的運維工具和腳本。

一、現(xiàn)狀和面臨的挑戰(zhàn)

傳統(tǒng)的IT架構(gòu)使用了這么多年，所有的監(jiān)控設(shè)備以及網(wǎng)絡(luò)架構(gòu)都是基于此打造，那么在傳統(tǒng)架構(gòu)虛擬化、云化后的今天，如何針對虛擬化、云計算的環(huán)境如IAAS、PAAS進行運維?

傳統(tǒng)監(jiān)控系統(tǒng)主要是基于傳統(tǒng)的環(huán)境構(gòu)建。主要是針對基礎(chǔ)的硬件設(shè)備、業(yè)務(wù)系統(tǒng)的監(jiān)控，對于虛擬化環(huán)境的覆蓋是不足甚至可以說是零覆蓋的，特別是在虛擬化技術(shù)引入之后，每臺宿主機里面的眾多虛擬機怎么去運維?眾多的容器 、微服務(wù) 、APP怎么運維 ?如何監(jiān)控是云化后運維監(jiān)控面臨的挑戰(zhàn)。

當前主要面臨的問題：

1.虛擬機配置變化更快，數(shù)據(jù)不準確，很難做到及時更新。

配置變化更頻繁，因此對其配置狀態(tài)的跟蹤更復(fù)雜，整個系統(tǒng)范圍內(nèi)的資產(chǎn)信息更難掌握，運用老套的統(tǒng)計辦法不及時也不準確，耗費人力、物力。

2.容量性能評估難，難以有效分配資源。

虛擬機不同于物理機，一臺宿主機上的各個虛機之間的關(guān)系是即爭用又共享，虛擬機對于CPU、內(nèi)存不僅僅是占用、很大一部分是共享的關(guān)系。對此特殊的分配機制，傳統(tǒng)的系統(tǒng)級CPU、內(nèi)存的占用已失去絕對指導(dǎo)意義，并不能完全代表虛擬機是否存在瓶頸。同樣的道理，難以判斷物理服務(wù)器資源是否得到了充分利用、是否有必要優(yōu)化、虛擬機密度是否恰當，從而導(dǎo)致多數(shù)組織內(nèi)部存在較廣泛的資源閑置情況。

3.管理缺乏標準和規(guī)范

虛擬化在整個IT系統(tǒng)構(gòu)建中占的位置越來越重要，但與操作系統(tǒng)相比，IT系統(tǒng)級的加固和檢査機制相對薄弱，成熟度及普及度都不高，存在系統(tǒng)缺陷、安全漏洞、管理不規(guī)范等薄弱環(huán)節(jié)，容易成為新的短板現(xiàn)象。

4.系統(tǒng)狀態(tài)邊界化模糊，難以準確評估狀態(tài)。

云計算環(huán)境涉及IT基礎(chǔ)硬件、操作系統(tǒng)以及業(yè)務(wù)系統(tǒng)等，傳統(tǒng)的設(shè)備邊界不再那么清晰，承載的VM對資源既共享又競爭，所以系統(tǒng)處于不斷地動態(tài)調(diào)整中，故障域的耦合更加緊密，針對問題根源的判斷更加困難。

5.容器

由于不需要為每個容器加載操作系統(tǒng)和內(nèi)核，因此與傳統(tǒng)的虛擬化環(huán)境相比，容器化環(huán)境能夠在給定數(shù)量的基礎(chǔ)架構(gòu)內(nèi)實現(xiàn)更高的工作負載密度。因此，在整個生產(chǎn)環(huán)境中創(chuàng)建、監(jiān)視和銷毀的組件需求總量呈指數(shù)級增長，從而顯著增加了基于容器的管理環(huán)境的復(fù)雜性。Docker的生態(tài)系統(tǒng)復(fù)雜多變。在過去幾年中，第三方工具和服務(wù)大量出現(xiàn)，幫助開發(fā)人員在開發(fā)過程中部署、配置和管理他們的容器化工作流程。基于開源技術(shù)，這些工具和服務(wù)的變化之快以及新文檔的數(shù)量之多，使構(gòu)建穩(wěn)定的技術(shù)棧以實現(xiàn)在生產(chǎn)中運行容器變得充滿挑戰(zhàn)。容器的主要優(yōu)點之一就在于它們是可移植的——一個應(yīng)用程序，其所有的依賴關(guān)系可以捆綁到一個獨立于Linux內(nèi)核、平臺分布或部署模型的主機版本的單個容器中。因此利用容器使應(yīng)用程序跨不同基礎(chǔ)設(shè)施需要的不僅僅是一個用于運輸代碼的標準化單元，它還需要基礎(chǔ)設(shè)施服務(wù)，包括：

• 運行Docker容器的主機(CPU、內(nèi)存、存儲和網(wǎng)絡(luò)連接)，包括在本地以及云上運行的虛擬機 或物理機器;協(xié)調(diào)好端口映射或軟件定義的網(wǎng)絡(luò)，使不同主機上的容器能夠相互通信;向Internet提供負載均衡器服務(wù);DNS，通常用于實現(xiàn)服務(wù)發(fā)現(xiàn);集成的健康檢查，確保應(yīng)對請求的使用的都是健康的容器服務(wù);某些事件觸發(fā)執(zhí)行操作時的應(yīng)對措施，例如在主機發(fā)生故障后重新啟動新容器，確保可用的正常容器始終維持一個固定的數(shù)量，或者創(chuàng)建新主機和容器以響應(yīng)增加的負載;通過現(xiàn)有容器創(chuàng)建新容器來擴展服務(wù);借助存儲快照和備份功能以備份狀態(tài)容器，從而進行災(zāi)難恢復(fù);
• 微服務(wù)是一系列職責單一、細粒度的服務(wù)，是將我們的業(yè)務(wù)進行拆分為獨立的服務(wù)單元，伸縮性好，耦合度低，不同的微服務(wù)可以用不同的語言開發(fā)，每一個服務(wù)處理的單一的業(yè)務(wù)。微服務(wù)可以劃分為前端服務(wù)(也叫邊緣服務(wù))和后端服務(wù)(也叫中間服務(wù))，前端服務(wù)是對后端服務(wù)做必要的聚合和剪裁后暴露給外部不同的設(shè)備(PC、Phone等)，所有的服務(wù)啟動時都會到Eureka服務(wù)器進行注冊，服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系。

二、云化架構(gòu)采取的應(yīng)對措施

計算和虛擬化環(huán)境缺乏有效深入的監(jiān)控措施，導(dǎo)致管理被動，無法及時發(fā)現(xiàn)問題，無法有效分析問題，安全管理上缺乏對虛擬化環(huán)境的管理規(guī)范、手段及工具，安全短板問題較明顯。

針對于以上幾大問題，在云化后的運維，應(yīng)該注重以下領(lǐng)域：

1、容量管理

容量管理分為容量優(yōu)化和容量規(guī)劃。容量優(yōu)化關(guān)注優(yōu)化資源配置，提高現(xiàn)有資源利用率。發(fā)現(xiàn)并回收低效、未使用的資源，以便合理調(diào)整虛擬機大小、回收閑置資源，在不影響性能的情況下優(yōu)化整合率和虛擬設(shè)備密度。容量規(guī)劃關(guān)注容量不足和超額配置情況，以提前規(guī)劃資源擴容，指導(dǎo)采購，并規(guī)避資源風(fēng)險。

(1) 業(yè)務(wù)處理量：反映在對外接口部分，主要評估響應(yīng)時間要求內(nèi)的最大并發(fā)能力， 由于對外接口可能提供的服務(wù)是多個，按實際場景分析最大和最小容量;典型的服務(wù)接入 如WEB 集群、 Web service(集群)、 socket 等;服務(wù)接入后一般交后臺程序進行處理，處 理結(jié)果最終返回服務(wù)接入端，因此可以每個服務(wù)(交易)的響應(yīng)時間作為容量評估的一個 參數(shù)，其反映的是后臺程序的處理能力，表現(xiàn)的是一段時間內(nèi)的服務(wù)通過量;處理量相關(guān)部分容量指標：交易量、TPS，系統(tǒng)響應(yīng)時間、響應(yīng)率。

(2) 業(yè)務(wù)承載量：承載能力相對靜態(tài)，表示該應(yīng)用系統(tǒng)能夠容納的數(shù)據(jù)量，在交易 型系統(tǒng)中，存量數(shù)據(jù)多少會影響服務(wù)處理的效率，進而影響處理能力，為了保障對外能力， 存量數(shù)據(jù)必然有所限制，比如數(shù)據(jù)庫中存放的歷史交易信息一定不能是無限制的;大部分 系統(tǒng)都有批處理，批處理大部分會讀寫文件或數(shù)據(jù)庫，作為整體處理能力的一部分，批處 理也需要納入容量管理范圍，允許的批處理時間窗口內(nèi)，能夠處理的數(shù)據(jù)量就是容量管理 的一部分指標;承載量相關(guān)部分容量指標：最大用戶數(shù)，數(shù)據(jù)保留周期，活動數(shù)量。

(3)業(yè)務(wù)容量指標對應(yīng)的系統(tǒng)性能容量參數(shù)：無論業(yè)務(wù)承載量還是業(yè)務(wù)處理量，最終在系統(tǒng)上反映的，都是系統(tǒng)的軟硬件配置、參數(shù)等實際對應(yīng)值，從業(yè)務(wù)容量指標到系統(tǒng)容量指標的翻譯非常困難，與各應(yīng)用系統(tǒng)的復(fù)雜程度相關(guān)，主要的系統(tǒng)容量或性能指標包括：

A、網(wǎng)絡(luò)性能及容量：帶寬、網(wǎng)速;

B、網(wǎng)絡(luò)設(shè)備：端口數(shù)、背板帶寬等;

C、服務(wù)器：網(wǎng)卡、光纖卡、 CPU、內(nèi)存、磁盤;

D、存儲：IO、容量;

E、數(shù)據(jù)庫：最大連接數(shù)、表空間;

F 、文件系統(tǒng)：空間、類型;

G、應(yīng)用服務(wù)器(WAS、Weblogic)：連接池數(shù)量、 JVM 大小、端口連接數(shù);

H、 Web 服務(wù)器：端口數(shù)

I、消息中間件(MQ)：隊列深度

J、應(yīng)用程序：處理速度

K、批處理：作業(yè)的窗口

2、閑置資源回收、調(diào)整虛擬比

由于云計算環(huán)境的資源共享和動態(tài)配置特性，云計算環(huán)境下的資源管理變得更加復(fù)雜難控，資源的驚人浪費和局部資源的緊張情況同時存在。如何判斷充分利用這些資源，配置合理的虛擬設(shè)備比例是新環(huán)境下的運維能力的硬性要求。

3、配置及資產(chǎn)管理

運用專業(yè)的監(jiān)控工具進行批量全面化的信息采樣，收集虛擬化層面的所有信息(包含計算資源的信息、網(wǎng)絡(luò)信息以及存儲存儲)。

具體包含：部署的 vSphere 版本、模板數(shù)量、 CPU 與內(nèi)存使用情況、網(wǎng)卡數(shù)量、 HBA 卡數(shù)量、是否處于維護模式、是否打開了 vMotion 、啟動運行時間、對應(yīng)的 vSwitch 收集各種網(wǎng)絡(luò)配置信息、 Datastore 的相關(guān)信息、 VM 配置信息、包括名稱、 IP 地址、 CPU 預(yù)留、內(nèi)存預(yù)留、內(nèi)存 limit 、內(nèi)存擴展預(yù)留、總的 CPU 請求、是否安裝了 VMware Tools 等等。

4、安全及合規(guī)管理

在云計算環(huán)境中，有很多比較容易忽略的安全隱患，可能被惡意利用。而且云計算環(huán)境是一個高度動態(tài)的環(huán)境，一兩次的檢查工作并不能保證整個 IT 環(huán)境的持續(xù)合規(guī)，必須要高頻的掃描檢測才能減少安全風(fēng)險。常見的安全檢測策略：拒絕 MAC 被更改、確保密碼復(fù)雜度、配置宿主機防火墻、配置 NTP 服務(wù)、設(shè)施 Shell 超時策略、不容許安裝未簽名的 VIB 、關(guān)閉 ESXi 與互聯(lián)網(wǎng)的通信、補丁安裝升級、集中保存 core dumps 日志等。

5、存儲管理、對虛擬化主機、虛機、網(wǎng)絡(luò)和存儲計算資源的全面監(jiān)控

全面將各個廠家的存儲設(shè)備納入存儲監(jiān)控進行統(tǒng)一管理，實時監(jiān)控存儲容量以及其他設(shè)備如光纖交換機的性能。可以對VMware虛擬機，虛擬機上安裝的不同操作系統(tǒng)，操作系統(tǒng)上運行的各種應(yīng)用和業(yè)務(wù)系統(tǒng)進行深度監(jiān)控，及時發(fā)現(xiàn)IT系統(tǒng)的運行故障，降低企業(yè)在虛擬化和云計算過程中的風(fēng)險。

6、容器和微服務(wù)管理

組織需要一種更便捷的方法來編排容器，以及管理多容器、多主機應(yīng)用程序的底層基礎(chǔ)架構(gòu)服務(wù)。這對于具有微服務(wù)體系結(jié)構(gòu)的應(yīng)用程序尤為重要，例如，一個Web應(yīng)用程序，包括一個容器集群運行Web服務(wù)器前端的多個實例的主機(故障轉(zhuǎn)移和負載均衡)以及多個后端服務(wù)，是各自運行在不同的容器中的。搭建基于容器和微服務(wù)監(jiān)控平臺。

7、用戶體驗監(jiān)控

App 性能監(jiān)控是將 App運行時產(chǎn)生的性能數(shù)據(jù)進行獲取及處理和分析, 通過平臺發(fā)現(xiàn)應(yīng)用對用戶影響最大的性能問題并通過云端對性能數(shù)據(jù)進行存儲、分析, 以郵件、微信方式推送。讓行業(yè)經(jīng)驗沉淀成為一個完整的閉環(huán), 使應(yīng)用的性能可以得到持續(xù)的監(jiān)控與提升。APP性能監(jiān)控是模擬用戶真實操作場景對APP在實際運行中的性能數(shù)據(jù)(響應(yīng)耗時，數(shù)據(jù)流量，CPU/內(nèi)存占用率等)進行持續(xù)性監(jiān)控。

網(wǎng)站業(yè)務(wù)撥測是一種網(wǎng)絡(luò)鏈路質(zhì)量的測試手段。撥測，非常類似于爬蟲，更準確地講，非常類似于黑客控制“肉雞”發(fā)起DDos攻擊。這里的“肉雞”，就是某個互聯(lián)網(wǎng)服務(wù)的客戶端，比如PC端、手機端。目的：探測各地區(qū)用戶到各個服務(wù)接入點的鏈路狀況，這樣，服務(wù)調(diào)度系統(tǒng)就可以根據(jù)探測結(jié)果為用戶提供最佳的接入點。

呼叫中心業(yè)務(wù)撥測，模擬用戶的業(yè)務(wù)操作過程，獲得完成業(yè)務(wù)的操作過程性能數(shù)據(jù)和操作結(jié)果數(shù)據(jù)。

8、APM監(jiān)控

全稱 Application Performance Management ， 提供分布式追蹤功能。

被用于追蹤、監(jiān)控和診斷分布式系統(tǒng)，特別是使用微服務(wù)架構(gòu)，云原生或容積技術(shù)。提供以下主要功能：

• 分布式追蹤和上下文傳輸
• 應(yīng)用、實例、服務(wù)性能指標分析
• 根源分析
• 應(yīng)用拓撲分析
• 應(yīng)用和服務(wù)依賴分析
• 慢服務(wù)檢測
• 性能優(yōu)化

9、統(tǒng)一日志管理和監(jiān)控

日志監(jiān)控可以采用大數(shù)據(jù)技術(shù)實現(xiàn)，大致可以分為兩大模塊：

離線數(shù)據(jù)處理：比如說電商、運營商出現(xiàn)的大批量的日志，可以由flume、sqoop或者其他路徑，導(dǎo)入到HDFS中，然后經(jīng)過數(shù)據(jù)清洗，使用Hive進行分析和處理，對于優(yōu)化服務(wù)器資源等有很好的作用;

實時數(shù)據(jù)處理：對于有些業(yè)務(wù)需要，可能第二天或者更晚的時候進行分析無關(guān)緊要，但對于一些高頻的金融交易來說，實時性就太重要了。

主要模塊：日志收集模塊、日志處理模塊

主要工具：

Filebeat：Filebeat就是一個完美的替代者，它基于Go語言沒有任何依賴，配置文件簡單，格式明了，同時，filebeat比logstash更加輕量級，所以占用系統(tǒng)資源極少，非常適合安裝在生產(chǎn)機器 。

kafka：消息緩沖隊列，大數(shù)據(jù)處理中常用的緩沖隊列，用于數(shù)據(jù)爆炸的時候，避免拖垮后續(xù)的處理邏輯，將消息先存放到隊列中，延遲一定的時間進行處理。

Apache Flink：具有真正的流處理特性以及低延遲和高吞吐量流處理功能，非常適合CEP工作負載。

Spring boot：構(gòu)建數(shù)據(jù)配置服務(wù)，方便用戶配置自己的日志數(shù)據(jù)，比如郵件發(fā)給何人，短信發(fā)給何人，都可以自由指定。

zookeeper：數(shù)據(jù)配置中心，在本項目用途中，主要是用于配置數(shù)據(jù)的管理。

1：日志收集模塊

在日志收集模塊中，針對我們自身的業(yè)務(wù)，可以分為兩大部分：

Nginx日志和數(shù)據(jù)庫運行日志：首先是Nginx，作為業(yè)內(nèi)比較強大的負責均衡工具，其性能比較優(yōu)良，我們在日常的服務(wù)中，也是使用該工具來進行負載均衡的功能實現(xiàn)。對于Tomcat類型的服務(wù)，選擇使用log4j內(nèi)置的flume-appender方式來實現(xiàn)。對于收集到的日志，統(tǒng)一采用kafkaSink的方式，輸送到后續(xù)的kafka中，以備后續(xù)的處理。

2：日志處理模塊

對于收集到的日志的處理，我們采用的是Apache Flink工具，將其與kafka對接，對于收集到的每一條數(shù)據(jù)進行處理。

10、大膽嘗試使用AIOPS

AIOPS可以實現(xiàn)歷史數(shù)據(jù)分析 、 毛刺檢測 、 指標預(yù)測 、 異常判定 。

通過海量數(shù)據(jù)源 (性能指標、日志、告警)、使用TensorFlow等成熟算法庫、輕量化計算可以實現(xiàn)告警準確率提升到80%，告警覆蓋率提升到95%、告警配置人力下降60%，一句話：降本增效體質(zhì)。

AIOPS在深度上可以實現(xiàn)智能故障發(fā)現(xiàn)，更一步實現(xiàn)日志異常檢測、告警壓縮和關(guān)聯(lián)、告警根因分析以及容量預(yù)測;在廣度上讓AIOPS在更多運維領(lǐng)域落地開花。

隨著云的普及，IT環(huán)境表現(xiàn)出三個特征：規(guī)模更大，產(chǎn)生的數(shù)據(jù)更多 ;動態(tài)，云的彈性決定了IT環(huán)境是不斷變化的 ;更復(fù)雜，從主機層面有物理機，虛擬機，云主機，容器等，從形態(tài)上有私有云、公有云、混合云等。越來越多的數(shù)據(jù)，復(fù)雜環(huán)境頻繁的警報，大量重復(fù)工作，要求提升自動化水平，AIOps是解決這些問題的利器，使用AIOps只是時間問題。

三、總結(jié)

云化環(huán)境運維應(yīng)該以交易監(jiān)控和APM項目為抓手，以業(yè)務(wù)質(zhì)量和客戶體驗為核心，以可管控、可視化、可度量為目標，從用戶體驗出發(fā)，建立端到端全鏈路監(jiān)控、告警+投訴預(yù)警+客服聯(lián)動形成完整閉環(huán)管理。在強化基礎(chǔ)設(shè)施監(jiān)控的基礎(chǔ)上，補充和完善應(yīng)用性能監(jiān)控和業(yè)務(wù)質(zhì)量監(jiān)控能力，保障業(yè)務(wù)的穩(wěn)定性和客戶感知。引入自動化手段，封裝標準模板，通過自動化配置打通CMDB、監(jiān)控、告警數(shù)據(jù)流，實現(xiàn)一鍵批量創(chuàng)建監(jiān)控、告警策略的功能，實現(xiàn)自動化提速;通過使用ETL工具如Kattle等開發(fā)抽取告警平臺歷史數(shù)據(jù)，最終裝載到大數(shù)據(jù)分析平臺中，進行多維度的數(shù)據(jù)分析，實現(xiàn)數(shù)據(jù)化賦能;建立豐富、多樣、靈活的視圖與報表，提供直觀高效的巡檢、定位工具，結(jié)合智能化手段提升監(jiān)控預(yù)警能力，實現(xiàn)智能化增效。

從業(yè)界的發(fā)展歷程來看，技術(shù)的標準化是一個必然的演進過程，運維自動化其實就是標準化的一種體現(xiàn)。從入手SRE的第一步開始，應(yīng)該整理和梳理工作職責，把需要解決的問題都文檔成檢查清單。方便業(yè)務(wù)上的快速實施。緊接著就是可視化這些業(yè)務(wù)指標和場景，幫助企業(yè)降低運營成本，量化服務(wù)體系的目標。