本文來自twt企業(yè)IT社區(qū)，作者/許中華。
背景
在云時代我們完全看不到任何物理設(shè)備，也不再關(guān)心硬件的穩(wěn)定性和可靠性，因為當(dāng)我們的硬件發(fā)生故障時，業(yè)務(wù)會第一時間切換到其他的節(jié)點(diǎn)，甚至切換到其他的數(shù)據(jù)中心，這樣我們的硬件維修完全可以等到方便的時候再進(jìn)行。運(yùn)維自動化是整個云運(yùn)維的核心。要面對成千上萬臺的服務(wù)器，產(chǎn)生的運(yùn)維已經(jīng)是人工方式不可能完成的任務(wù)，這就需要一整套高效自動化的運(yùn)維管理工具，來幫我們實(shí)現(xiàn)運(yùn)維的自動化。當(dāng)運(yùn)維的自動化程度越來越高的時候，我們會發(fā)現(xiàn)其實(shí)云運(yùn)維維護(hù)的是代碼，而傳統(tǒng)運(yùn)維維護(hù)的是硬件。最后，云運(yùn)維對我們維護(hù)能力的要求也越來越高，我們不但要掌握操作系統(tǒng)，還要不停學(xué)習(xí)各種云計算相關(guān)的知識和理論，還要掌握一些開源的工具，同時還要具備開發(fā)定制的能力，要不停的去開發(fā)定制自動化的運(yùn)維工具和腳本。
一、現(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進(jìn)行運(yùn)維？
傳統(tǒng)監(jiān)控系統(tǒng)主要是基于傳統(tǒng)的環(huán)境構(gòu)建。主要是針對基礎(chǔ)的硬件設(shè)備、業(yè)務(wù)系統(tǒng)的監(jiān)控，對于虛擬化環(huán)境的覆蓋是不足甚至可以說是零覆蓋的，特別是在虛擬化技術(shù)引入之后，每臺宿主機(jī)里面的眾多虛擬機(jī)怎么去運(yùn)維？眾多的容器、微服務(wù)、APP怎么運(yùn)維?如何監(jiān)控是云化后運(yùn)維監(jiān)控面臨的挑戰(zhàn)。
當(dāng)前主要面臨的問題：
1.虛擬機(jī)配置變化更快，數(shù)據(jù)不準(zhǔn)確，很難做到及時更新。
配置變化更頻繁，因此對其配置狀態(tài)的跟蹤更復(fù)雜，整個系統(tǒng)范圍內(nèi)的資產(chǎn)信息更難掌握，運(yùn)用老套的統(tǒng)計辦法不及時也不準(zhǔn)確，耗費(fèi)人力、物力。
2.容量性能評估難，難以有效分配資源。
虛擬機(jī)不同于物理機(jī)，一臺宿主機(jī)上的各個虛機(jī)之間的關(guān)系是即爭用又共享，虛擬機(jī)對于CPU、內(nèi)存不僅僅是占用、很大一部分是共享的關(guān)系。對此特殊的分配機(jī)制，傳統(tǒng)的系統(tǒng)級CPU、內(nèi)存的占用已失去絕對指導(dǎo)意義，并不能完全代表虛擬機(jī)是否存在瓶頸。同樣的道理，難以判斷物理服務(wù)器資源是否得到了充分利用、是否有必要優(yōu)化、虛擬機(jī)密度是否恰當(dāng)，從而導(dǎo)致多數(shù)組織內(nèi)部存在較廣泛的資源閑置情況。
3.管理缺乏標(biāo)準(zhǔn)和規(guī)范
虛擬化在整個IT系統(tǒng)構(gòu)建中占的位置越來越重要，但與操作系統(tǒng)相比，IT系統(tǒng)級的加固和檢査機(jī)制相對薄弱，成熟度及普及度都不高，存在系統(tǒng)缺陷、安全漏洞、管理不規(guī)范等薄弱環(huán)節(jié)，容易成為新的短板現(xiàn)象。
4.系統(tǒng)狀態(tài)邊界化模糊，難以準(zhǔn)確評估狀態(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)實(shí)現(xiàn)更高的工作負(fù)載密度。因此，在整個生產(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ù)棧以實(shí)現(xiàn)在生產(chǎn)中運(yùn)行容器變得充滿挑戰(zhàn)。容器的主要優(yōu)點(diǎn)之一就在于它們是可移植的——一個應(yīng)用程序，其所有的依賴關(guān)系可以捆綁到一個獨(dú)立于Linux內(nèi)核、平臺分布或部署模型的主機(jī)版本的單個容器中。因此利用容器使應(yīng)用程序跨不同基礎(chǔ)設(shè)施需要的不僅僅是一個用于運(yùn)輸代碼的標(biāo)準(zhǔn)化單元，它還需要基礎(chǔ)設(shè)施服務(wù)，包括：
運(yùn)行Docker容器的主機(jī)（CPU、內(nèi)存、存儲和網(wǎng)絡(luò)連接），包括在本地以及云上運(yùn)行的虛擬機(jī)或物理機(jī)器；協(xié)調(diào)好端口映射或軟件定義的網(wǎng)絡(luò)，使不同主機(jī)上的容器能夠相互通信；向Internet提供負(fù)載均衡器服務(wù)；DNS，通常用于實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)；集成的健康檢查，確保應(yīng)對請求的使用的都是健康的容器服務(wù)；某些事件觸發(fā)執(zhí)行操作時的應(yīng)對措施，例如在主機(jī)發(fā)生故障后重新啟動新容器，確?？捎玫恼Ｈ萜魇冀K維持一個固定的數(shù)量，或者創(chuàng)建新主機(jī)和容器以響應(yīng)增加的負(fù)載；通過現(xiàn)有容器創(chuàng)建新容器來擴(kuò)展服務(wù)；借助存儲快照和備份功能以備份狀態(tài)容器，從而進(jìn)行災(zāi)難恢復(fù)；
微服務(wù)是一系列職責(zé)單一、細(xì)粒度的服務(wù)，是將我們的業(yè)務(wù)進(jìn)行拆分為獨(dú)立的服務(wù)單元，伸縮性好，耦合度低，不同的微服務(wù)可以用不同的語言開發(fā)，每一個服務(wù)處理的單一的業(yè)務(wù)。微服務(wù)可以劃分為前端服務(wù)（也叫邊緣服務(wù)）和后端服務(wù)（也叫中間服務(wù)），前端服務(wù)是對后端服務(wù)做必要的聚合和剪裁后暴露給外部不同的設(shè)備（PC、Phone等），所有的服務(wù)啟動時都會到Eureka服務(wù)器進(jìn)行注冊，服務(wù)之間會有錯綜復(fù)雜的依賴關(guān)系。
二、云化架構(gòu)采取的應(yīng)對措施
計算和虛擬化環(huán)境缺乏有效深入的監(jiān)控措施，導(dǎo)致管理被動，無法及時發(fā)現(xiàn)問題，無法有效分析問題，安全管理上缺乏對虛擬化環(huán)境的管理規(guī)范、手段及工具，安全短板問題較明顯。
針對于以上幾大問題，在云化后的運(yùn)維，應(yīng)該注重以下領(lǐng)域：
1、容量管理
容量管理分為容量優(yōu)化和容量規(guī)劃。容量優(yōu)化關(guān)注優(yōu)化資源配置，提高現(xiàn)有資源利用率。發(fā)現(xiàn)并回收低效、未使用的資源，以便合理調(diào)整虛擬機(jī)大小、回收閑置資源，在不影響性能的情況下優(yōu)化整合率和虛擬設(shè)備密度。容量規(guī)劃關(guān)注容量不足和超額配置情況，以提前規(guī)劃資源擴(kuò)容，指導(dǎo)采購，并規(guī)避資源風(fēng)險。
（1）業(yè)務(wù)處理量：反映在對外接口部分，主要評估響應(yīng)時間要求內(nèi)的最大并發(fā)能力，由于對外接口可能提供的服務(wù)是多個，按實(shí)際場景分析最大和最小容量；典型的服務(wù)接入如WEB集群、Web service（集群）、socket等；服務(wù)接入后一般交后臺程序進(jìn)行處理，處理結(jié)果最終返回服務(wù)接入端，因此可以每個服務(wù)（交易）的響應(yīng)時間作為容量評估的一個參數(shù)，其反映的是后臺程序的處理能力，表現(xiàn)的是一段時間內(nèi)的服務(wù)通過量；處理量相關(guān)部分容量指標(biāo)：交易量、TPS，系統(tǒng)響應(yīng)時間、響應(yīng)率。
（2）業(yè)務(wù)承載量：承載能力相對靜態(tài)，表示該應(yīng)用系統(tǒng)能夠容納的數(shù)據(jù)量，在交易型系統(tǒng)中，存量數(shù)據(jù)多少會影響服務(wù)處理的效率，進(jìn)而影響處理能力，為了保障對外能力，存量數(shù)據(jù)必然有所限制，比如數(shù)據(jù)庫中存放的歷史交易信息一定不能是無限制的；大部分系統(tǒng)都有批處理，批處理大部分會讀寫文件或數(shù)據(jù)庫，作為整體處理能力的一部分，批處理也需要納入容量管理范圍，允許的批處理時間窗口內(nèi)，能夠處理的數(shù)據(jù)量就是容量管理的一部分指標(biāo)；承載量相關(guān)部分容量指標(biāo)：最大用戶數(shù)，數(shù)據(jù)保留周期，活動數(shù)量。
（3）業(yè)務(wù)容量指標(biāo)對應(yīng)的系統(tǒng)性能容量參數(shù)：無論業(yè)務(wù)承載量還是業(yè)務(wù)處理量，最終在系統(tǒng)上反映的，都是系統(tǒng)的軟硬件配置、參數(shù)等實(shí)際對應(yīng)值，從業(yè)務(wù)容量指標(biāo)到系統(tǒng)容量指標(biāo)的翻譯非常困難，與各應(yīng)用系統(tǒng)的復(fù)雜程度相關(guān)，主要的系統(tǒng)容量或性能指標(biāo)包括：
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ù)雜難控，資源的驚人浪費(fèi)和局部資源的緊張情況同時存在。如何判斷充分利用這些資源，配置合理的虛擬設(shè)備比例是新環(huán)境下的運(yùn)維能力的硬性要求。
3、配置及資產(chǎn)管理
運(yùn)用專業(yè)的監(jiān)控工具進(jìn)行批量全面化的信息采樣，收集虛擬化層面的所有信息（包含計算資源的信息、網(wǎng)絡(luò)信息以及存儲存儲）。
具體包含：部署的vSphere版本、模板數(shù)量、CPU與內(nèi)存使用情況、網(wǎng)卡數(shù)量、HBA卡數(shù)量、是否處于維護(hù)模式、是否打開了vMotion、啟動運(yùn)行時間、對應(yīng)的vSwitch收集各種網(wǎng)絡(luò)配置信息、Datastore的相關(guān)信息、VM配置信息、包括名稱、IP地址、CPU預(yù)留、內(nèi)存預(yù)留、內(nèi)存limit、內(nèi)存擴(kuò)展預(yù)留、總的CPU請求、是否安裝了VMware Tools等等。
4、安全及合規(guī)管理
在云計算環(huán)境中，有很多比較容易忽略的安全隱患，可能被惡意利用。而且云計算環(huán)境是一個高度動態(tài)的環(huán)境，一兩次的檢查工作并不能保證整個IT環(huán)境的持續(xù)合規(guī)，必須要高頻的掃描檢測才能減少安全風(fēng)險。常見的安全檢測策略：拒絕MAC被更改、確保密碼復(fù)雜度、配置宿主機(jī)防火墻、配置NTP服務(wù)、設(shè)施Shell超時策略、不容許安裝未簽名的VIB、關(guān)閉ESXi與互聯(lián)網(wǎng)的通信、補(bǔ)丁安裝升級、集中保存core dumps日志等。
5、存儲管理、對虛擬化主機(jī)、虛機(jī)、網(wǎng)絡(luò)和存儲計算資源的全面監(jiān)控
全面將各個廠家的存儲設(shè)備納入存儲監(jiān)控進(jìn)行統(tǒng)一管理，實(shí)時監(jiān)控存儲容量以及其他設(shè)備如光纖交換機(jī)的性能?？梢詫Mware虛擬機(jī)，虛擬機(jī)上安裝的不同操作系統(tǒng)，操作系統(tǒng)上運(yùn)行的各種應(yīng)用和業(yè)務(wù)系統(tǒng)進(jìn)行深度監(jiān)控，及時發(fā)現(xiàn)IT系統(tǒng)的運(yùn)行故障，降低企業(yè)在虛擬化和云計算過程中的風(fēng)險。
6、容器和微服務(wù)管理
組織需要一種更便捷的方法來編排容器，以及管理多容器、多主機(jī)應(yīng)用程序的底層基礎(chǔ)架構(gòu)服務(wù)。這對于具有微服務(wù)體系結(jié)構(gòu)的應(yīng)用程序尤為重要，例如，一個Web應(yīng)用程序，包括一個容器集群運(yùn)行Web服務(wù)器前端的多個實(shí)例的主機(jī)（故障轉(zhuǎn)移和負(fù)載均衡）以及多個后端服務(wù)，是各自運(yùn)行在不同的容器中的。搭建基于容器和微服務(wù)監(jiān)控平臺。
7、用戶體驗監(jiān)控
App性能監(jiān)控是將App運(yùn)行時產(chǎn)生的性能數(shù)據(jù)進(jìn)行獲取及處理和分析,通過平臺發(fā)現(xiàn)應(yīng)用對用戶影響最大的性能問題并通過云端對性能數(shù)據(jù)進(jìn)行存儲、分析,以郵件、微信方式推送。讓行業(yè)經(jīng)驗沉淀成為一個完整的閉環(huán),使應(yīng)用的性能可以得到持續(xù)的監(jiān)控與提升。APP性能監(jiān)控是模擬用戶真實(shí)操作場景對APP在實(shí)際運(yùn)行中的性能數(shù)據(jù)（響應(yīng)耗時，數(shù)據(jù)流量，CPU/內(nèi)存占用率等）進(jìn)行持續(xù)性監(jiān)控。
網(wǎng)站業(yè)務(wù)撥測是一種網(wǎng)絡(luò)鏈路質(zhì)量的測試手段。撥測，非常類似于爬蟲，更準(zhǔn)確地講，非常類似于黑客控制“肉雞”發(fā)起DDos攻擊。這里的“肉雞”，就是某個互聯(lián)網(wǎng)服務(wù)的客戶端，比如PC端、手機(jī)端。目的：探測各地區(qū)用戶到各個服務(wù)接入點(diǎn)的鏈路狀況，這樣，服務(wù)調(diào)度系統(tǒng)就可以根據(jù)探測結(jié)果為用戶提供最佳的接入點(diǎn)。
呼叫中心業(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)用、實(shí)例、服務(wù)性能指標(biāo)分析
根源分析
應(yīng)用拓?fù)浞治?/p>
應(yīng)用和服務(wù)依賴分析
慢服務(wù)檢測
性能優(yōu)化
9、統(tǒng)一日志管理和監(jiān)控
日志監(jiān)控可以采用大數(shù)據(jù)技術(shù)實(shí)現(xiàn)，大致可以分為兩大模塊：
離線數(shù)據(jù)處理：比如說電商、運(yùn)營商出現(xiàn)的大批量的日志，可以由flume、sqoop或者其他路徑，導(dǎo)入到HDFS中，然后經(jīng)過數(shù)據(jù)清洗，使用Hive進(jìn)行分析和處理，對于優(yōu)化服務(wù)器資源等有很好的作用；
實(shí)時數(shù)據(jù)處理：對于有些業(yè)務(wù)需要，可能第二天或者更晚的時候進(jìn)行分析無關(guān)緊要，但對于一些高頻的金融交易來說，實(shí)時性就太重要了。
主要模塊：日志收集模塊、日志處理模塊
主要工具：
Filebeat：Filebeat就是一個完美的替代者，它基于Go語言沒有任何依賴，配置文件簡單，格式明了，同時，filebeat比logstash更加輕量級，所以占用系統(tǒng)資源極少，非常適合安裝在生產(chǎn)機(jī)器。
kafka：消息緩沖隊列，大數(shù)據(jù)處理中常用的緩沖隊列，用于數(shù)據(jù)爆炸的時候，避免拖垮后續(xù)的處理邏輯，將消息先存放到隊列中，延遲一定的時間進(jìn)行處理。
Apache Flink：具有真正的流處理特性以及低延遲和高吞吐量流處理功能，非常適合CEP工作負(fù)載。
Spring boot：構(gòu)建數(shù)據(jù)配置服務(wù)，方便用戶配置自己的日志數(shù)據(jù)，比如郵件發(fā)給何人，短信發(fā)給何人，都可以自由指定。
zookeeper：數(shù)據(jù)配置中心，在本項目用途中，主要是用于配置數(shù)據(jù)的管理。
1：日志收集模塊
在日志收集模塊中，針對我們自身的業(yè)務(wù)，可以分為兩大部分：
Nginx日志和數(shù)據(jù)庫運(yùn)行日志：首先是Nginx，作為業(yè)內(nèi)比較強(qiáng)大的負(fù)責(zé)均衡工具，其性能比較優(yōu)良，我們在日常的服務(wù)中，也是使用該工具來進(jìn)行負(fù)載均衡的功能實(shí)現(xiàn)。對于Tomcat類型的服務(wù)，選擇使用log4j內(nèi)置的flume-appender方式來實(shí)現(xiàn)。對于收集到的日志，統(tǒng)一采用kafkaSink的方式，輸送到后續(xù)的kafka中，以備后續(xù)的處理。
2：日志處理模塊
對于收集到的日志的處理，我們采用的是Apache Flink工具，將其與kafka對接，對于收集到的每一條數(shù)據(jù)進(jìn)行處理。
10、大膽嘗試使用AIOPS
AIOPS可以實(shí)現(xiàn)歷史數(shù)據(jù)分析、毛刺檢測、指標(biāo)預(yù)測、異常判定。
通過海量數(shù)據(jù)源（性能指標(biāo)、日志、告警）、使用TensorFlow等成熟算法庫、輕量化計算可以實(shí)現(xiàn)告警準(zhǔn)確率提升到80%，告警覆蓋率提升到95%、告警配置人力下降60%，一句話：降本增效體質(zhì)。
AIOPS在深度上可以實(shí)現(xiàn)智能故障發(fā)現(xiàn)，更一步實(shí)現(xiàn)日志異常檢測、告警壓縮和關(guān)聯(lián)、告警根因分析以及容量預(yù)測；在廣度上讓AIOPS在更多運(yùn)維領(lǐng)域落地開花。
隨著云的普及，IT環(huán)境表現(xiàn)出三個特征：規(guī)模更大，產(chǎn)生的數(shù)據(jù)更多；動態(tài)，云的彈性決定了IT環(huán)境是不斷變化的；更復(fù)雜，從主機(jī)層面有物理機(jī)，虛擬機(jī)，云主機(jī)，容器等，從形態(tài)上有私有云、公有云、混合云等。越來越多的數(shù)據(jù)，復(fù)雜環(huán)境頻繁的警報，大量重復(fù)工作，要求提升自動化水平，AIOps是解決這些問題的利器，使用AIOps只是時間問題。
三、總結(jié)
云化環(huán)境運(yùn)維應(yīng)該以交易監(jiān)控和APM項目為抓手，以業(yè)務(wù)質(zhì)量和客戶體驗為核心，以可管控、可視化、可度量為目標(biāo)，從用戶體驗出發(fā)，建立端到端全鏈路監(jiān)控、告警+投訴預(yù)警+客服聯(lián)動形成完整閉環(huán)管理。在強(qiáng)化基礎(chǔ)設(shè)施監(jiān)控的基礎(chǔ)上，補(bǔ)充和完善應(yīng)用性能監(jiān)控和業(yè)務(wù)質(zhì)量監(jiān)控能力，保障業(yè)務(wù)的穩(wěn)定性和客戶感知。引入自動化手段，封裝標(biāo)準(zhǔn)模板，通過自動化配置打通CMDB、監(jiān)控、告警數(shù)據(jù)流，實(shí)現(xiàn)一鍵批量創(chuàng)建監(jiān)控、告警策略的功能，實(shí)現(xiàn)自動化提速；通過使用ETL工具如Kattle等開發(fā)抽取告警平臺歷史數(shù)據(jù)，最終裝載到大數(shù)據(jù)分析平臺中，進(jìn)行多維度的數(shù)據(jù)分析，實(shí)現(xiàn)數(shù)據(jù)化賦能；建立豐富、多樣、靈活的視圖與報表，提供直觀高效的巡檢、定位工具，結(jié)合智能化手段提升監(jiān)控預(yù)警能力，實(shí)現(xiàn)智能化增效。
從業(yè)界的發(fā)展歷程來看，技術(shù)的標(biāo)準(zhǔn)化是一個必然的演進(jìn)過程，運(yùn)維自動化其實(shí)就是標(biāo)準(zhǔn)化的一種體現(xiàn)。從入手SRE的第一步開始，應(yīng)該整理和梳理工作職責(zé)，把需要解決的問題都文檔成檢查清單。方便業(yè)務(wù)上的快速實(shí)施。緊接著就是可視化這些業(yè)務(wù)指標(biāo)和場景，幫助企業(yè)降低運(yùn)營成本，量化服務(wù)體系的目標(biāo)。
