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