2021年08月27日
在云時代我們完全看不到任何物理設備，也不再關心硬件的穩定性和可靠性，因為當我們的硬件發生故障時，業務會第一時間切換到其他的節點，甚至切換到其他的數據中心，這樣我們的硬件維修完全可以等到方便的時候再進行。運維自動化是整個云運維的核心。要面對成千上萬臺的服務器，產生的運維已經是人工方式不可能完成的任務，這就需要一整套高效自動化的運維管理工具，來幫我們實現運維的自動化。當運維的自動化程度越來越高的時候，我們會發現其實云運維維護的是代碼，而傳統運維維護的是硬件。最后，云運維對我們維護能力的要求也越來越高，我們不但要掌握操作系統，還要不停學習各種云計算相關的知識和理論，還要掌握一些開源的工具，同時還要具備開發定制的能力，要不停的去開發定制自動化的運維工具和腳本。
傳統的IT架構使用了這么多年，所有的監控設備以及網絡架構都是基于此打造，那么在傳統架構虛擬化、云化后的今天，如何針對虛擬化、云計算的環境如IAAS、PAAS進行運維？
傳統監控系統主要是基于傳統的環境構建。主要是針對基礎的硬件設備、業務系統的監控，對于虛擬化環境的覆蓋是不足甚至可以說是零覆蓋的，特別是在虛擬化技術引入之后，每臺宿主機里面的眾多虛擬機怎么去運維？眾多的容器 、微服務 、APP怎么運維 ?如何監控是云化后運維監控面臨的挑戰。
當前主要面臨的問題：
1.虛擬機配置變化更快，數據不準確，很難做到及時更新。
配置變化更頻繁，因此對其配置狀態的跟蹤更復雜，整個系統范圍內的資產信息更難掌握，運用老套的統計辦法不及時也不準確，耗費人力、物力。
2.容量性能評估難，難以有效分配資源。
虛擬機不同于物理機，一臺宿主機上的各個虛機之間的關系是即爭用又共享，虛擬機對于CPU、內存不僅僅是占用、很大一部分是共享的關系。對此特殊的分配機制，傳統的系統級CPU、內存的占用已失去絕對指導意義，并不能完全代表虛擬機是否存在瓶頸。同樣的道理，難以判斷物理服務器資源是否得到了充分利用、是否有必要優化、虛擬機密度是否恰當，從而導致多數組織內部存在較廣泛的資源閑置情況。
3.管理缺乏標準和規范
虛擬化在整個IT系統構建中占的位置越來越重要，但與操作系統相比，IT系統級的加固和檢査機制相對薄弱，成熟度及普及度都不高，存在系統缺陷、安全漏洞、管理不規范等薄弱環節，容易成為新的短板現象。
4.系統狀態邊界化模糊，難以準確評估狀態。
云計算環境涉及IT基礎硬件、操作系統以及業務系統等，傳統的設備邊界不再那么清晰，承載的VM對資源既共享又競爭，所以系統處于不斷地動態調整中，故障域的耦合更加緊密，針對問題根源的判斷更加困難。
5.容器
由于不需要為每個容器加載操作系統和內核，因此與傳統的虛擬化環境相比，容器化環境能夠在給定數量的基礎架構內實現更高的工作負載密度。因此，在整個生產環境中創建、監視和銷毀的組件需求總量呈指數級增長，從而顯著增加了基于容器的管理環境的復雜性。Docker的生態系統復雜多變。在過去幾年中，第三方工具和服務大量出現，幫助開發人員在開發過程中部署、配置和管理他們的容器化工作流程。基于開源技術，這些工具和服務的變化之快以及新文檔的數量之多，使構建穩定的技術棧以實現在生產中運行容器變得充滿挑戰。容器的主要優點之一就在于它們是可移植的——一個應用程序，其所有的依賴關系可以捆綁到一個獨立于Linux內核、平臺分布或部署模型的主機版本的單個容器中。因此利用容器使應用程序跨不同基礎設施需要的不僅僅是一個用于運輸代碼的標準化單元，它還需要基礎設施服務，包括：
運行Docker容器的主機（CPU、內存、存儲和網絡連接），包括在本地以及云上運行的虛擬機 或物理機器；協調好端口映射或軟件定義的網絡，使不同主機上的容器能夠相互通信；向Internet提供負載均衡器服務；DNS，通常用于實現服務發現；集成的健康檢查，確保應對請求的使用的都是健康的容器服務；某些事件觸發執行操作時的應對措施，例如在主機發生故障后重新啟動新容器，確保可用的正常容器始終維持一個固定的數量，或者創建新主機和容器以響應增加的負載；通過現有容器創建新容器來擴展服務；借助存儲快照和備份功能以備份狀態容器，從而進行災難恢復；
微服務是一系列職責單一、細粒度的服務，是將我們的業務進行拆分為獨立的服務單元，伸縮性好，耦合度低，不同的微服務可以用不同的語言開發，每一個服務處理的單一的業務。微服務可以劃分為前端服務（也叫邊緣服務）和后端服務（也叫中間服務），前端服務是對后端服務做必要的聚合和剪裁后暴露給外部不同的設備（PC、Phone等），所有的服務啟動時都會到Eureka服務器進行注冊，服務之間會有錯綜復雜的依賴關系。
計算和虛擬化環境缺乏有效深入的監控措施，導致管理被動，無法及時發現問題，無法有效分析問題，安全管理上缺乏對虛擬化環境的管理規范、手段及工具，安全短板問題較明顯。
針對于以上幾大問題，在云化后的運維，應該注重以下領域：
容量管理分為容量優化和容量規劃。容量優化關注優化資源配置，提高現有資源利用率。發現并回收低效、未使用的資源，以便合理調整虛擬機大小、回收閑置資源，在不影響性能的情況下優化整合率和虛擬設備密度。容量規劃關注容量不足和超額配置情況，以提前規劃資源擴容，指導采購，并規避資源風險。
（1） 業務處理量：反映在對外接口部分，主要評估響應時間要求內的最大并發能力， 由于對外接口可能提供的服務是多個，按實際場景分析最大和最小容量；典型的服務接入 如WEB 集群、 Web service（集群）、 socket 等；服務接入后一般交后臺程序進行處理，處 理結果最終返回服務接入端，因此可以每個服務（交易）的響應時間作為容量評估的一個 參數，其反映的是后臺程序的處理能力，表現的是一段時間內的服務通過量；處理量相關部分容量指標：交易量、TPS，系統響應時間、響應率。
（2） 業務承載量：承載能力相對靜態，表示該應用系統能夠容納的數據量，在交易 型系統中，存量數據多少會影響服務處理的效率，進而影響處理能力，為了保障對外能力， 存量數據必然有所限制，比如數據庫中存放的歷史交易信息一定不能是無限制的；大部分 系統都有批處理，批處理大部分會讀寫文件或數據庫，作為整體處理能力的一部分，批處 理也需要納入容量管理范圍，允許的批處理時間窗口內，能夠處理的數據量就是容量管理 的一部分指標；承載量相關部分容量指標：最大用戶數，數據保留周期，活動數量。
（3）業務容量指標對應的系統性能容量參數：無論業務承載量還是業務處理量，最終在系統上反映的，都是系統的軟硬件配置、參數等實際對應值，從業務容量指標到系統容量指標的翻譯非常困難，與各應用系統的復雜程度相關，主要的系統容量或性能指標包括：
A、網絡性能及容量：帶寬、網速；
B、網絡設備：端口數、背板帶寬等；
C、服務器：網卡、光纖卡、 CPU、內存、磁盤；
D、存儲：IO、容量；
E、數據庫：最大連接數、表空間；
F 、文件系統：空間、類型；
G、應用服務器（WAS、Weblogic）：連接池數量、 JVM 大小、端口連接數；
H、 Web 服務器：端口數
I、消息中間件（MQ）：隊列深度
J、應用程序：處理速度
K、批處理：作業的窗口
由于云計算環境的資源共享和動態配置特性，云計算環境下的資源管理變得更加復雜難控，資源的驚人浪費和局部資源的緊張情況同時存在。如何判斷充分利用這些資源，配置合理的虛擬設備比例是新環境下的運維能力的硬性要求。
運用專業的監控工具進行批量全面化的信息采樣，收集虛擬化層面的所有信息（包含計算資源的信息、網絡信息以及存儲存儲）。
具體包含：部署的 vSphere 版本、模板數量、 CPU 與內存使用情況、網卡數量、 HBA 卡數量、是否處于維護模式、是否打開了 vMotion 、啟動運行時間、對應的 vSwitch 收集各種網絡配置信息、 Datastore 的相關信息、 VM 配置信息、包括名稱、 IP 地址、 CPU 預留、內存預留、內存 limit 、內存擴展預留、總的 CPU 請求、是否安裝了 VMware Tools 等等。
在云計算環境中，有很多比較容易忽略的安全隱患，可能被惡意利用。而且云計算環境是一個高度動態的環境，一兩次的檢查工作并不能保證整個 IT 環境的持續合規，必須要高頻的掃描檢測才能減少安全風險。常見的安全檢測策略：拒絕 MAC 被更改、確保密碼復雜度、配置宿主機防火墻、配置 NTP 服務、設施 Shell 超時策略、不容許安裝未簽名的 VIB 、關閉 ESXi 與互聯網的通信、補丁安裝升級、集中保存 core dumps 日志等。
全面將各個廠家的存儲設備納入存儲監控進行統一管理，實時監控存儲容量以及其他設備如光纖交換機的性能。可以對VMware虛擬機，虛擬機上安裝的不同操作系統，操作系統上運行的各種應用和業務系統進行深度監控，及時發現IT系統的運行故障，降低企業在虛擬化和云計算過程中的風險。
組織需要一種更便捷的方法來編排容器，以及管理多容器、多主機應用程序的底層基礎架構服務。這對于具有微服務體系結構的應用程序尤為重要，例如，一個Web應用程序，包括一個容器集群運行Web服務器前端的多個實例的主機（故障轉移和負載均衡）以及多個后端服務，是各自運行在不同的容器中的。搭建基于容器和微服務監控平臺。
App 性能監控是將 App運行時產生的性能數據進行獲取及處理和分析, 通過平臺發現應用對用戶影響最大的性能問題并通過云端對性能數據進行存儲、分析, 以郵件、微信方式推送。讓行業經驗沉淀成為一個完整的閉環, 使應用的性能可以得到持續的監控與提升。APP性能監控是模擬用戶真實操作場景對APP在實際運行中的性能數據（響應耗時，數據流量，CPU/內存占用率等）進行持續性監控。
網站業務撥測是一種網絡鏈路質量的測試手段。撥測，非常類似于爬蟲，更準確地講，非常類似于黑客控制“肉雞”發起DDos攻擊。這里的“肉雞”，就是某個互聯網服務的客戶端，比如PC端、手機端。目的：探測各地區用戶到各個服務接入點的鏈路狀況，這樣，服務調度系統就可以根據探測結果為用戶提供最佳的接入點。
呼叫中心業務撥測，模擬用戶的業務操作過程，獲得完成業務的操作過程性能數據和操作結果數據。
全稱 Application Performance Management ， 提供分布式追蹤功能。
被用于追蹤、監控和診斷分布式系統，特別是使用微服務架構，云原生或容積技術。提供以下主要功能：
分布式追蹤和上下文傳輸
應用、實例、服務性能指標分析
根源分析
應用拓撲分析