運維管理兜兜轉轉十幾余載，大家的運維管理再也不是小米加×××、人工費力拉線扛服務器的傳統時代，如你所知，這些年大家張口閉口談的都是運維自動化如何如何。一千個讀者就有一千個哈姆雷特，一千個運維就有一千種運維自動化想法或構建思路，小生不才，今日鬥膽來聊聊我眼中“運維自動化”的那些事兒！如有不妥，還請大家給出相應的意見......

運維自動化到底幹個啥？

據度娘之意，IT運維自動化是將日常IT運維中大量的重復性工作，小到簡單的日常檢查、配置變更和軟件安裝，大到整個變更流程的組織調度等，由過去的手工執行轉為自動化操作，從而減少乃至消除運維中的延遲，實現"零延時"的IT運維。其本質是運維方式的轉變，由手動逐漸演變為自動化操作！那運維自動化應該包含哪幾個層面？鑒於IT運維五個維度”效率、穩定、安全、體驗、成本”範疇，運維自動化統籌起來就有監控自動化、服務流程自動化、運維操作自動化......

IT監控自動化

監控自動化是運維自動化的起點之一，利用監控自動化平臺對各類IT資源（包括服務器、數據庫、中間件、存儲備份、網絡、安全、機房、業務應用、操作系統、虛擬化等）進行實時監控，再做故障根源告警歸並處理，以解決特殊情況下告警泛濫的問題，例如機房斷網造成的批量服務器報警。當然，監控自動化的範疇很廣，除了監控告警響應，系統各個服務如Nginx、Java、PHP、DB或網絡等的性能優化、資產關系的梳理以及業務系統的實時健康評估監測也是應該包含在裏面。

服務流程自動化

監控自動化發現了問題就應該接入相應的流程進行處理，這時候故障事件自動觸發問題處理跟蹤流程，並在自動化工單式流程的指引下通知到相關責任人，並利用知識庫自動化完成整個故障處理協調過程。

運維操作自動化

這個層面的自動化運維工具，主要是把運維一系列的手工執行繁瑣的工作，按照日常正確的維護流程分步編寫成腳本，然後由自動化運維工具按流程編排成作業自動化執行。簡單來說，就是把多個Shell、python、PowerShell、Bat等腳本串在一起執行實現某個特定的操作目的，以此來替代一些日常需要批量或者大量重復性的操作，比如變更、部署、配置下發等操作！

以前，傳統的運維方式是由監控系統監控，根據閾值設置產生告警，走工單方式人工處理。現在，使用自動化運維平臺，可以讓產生的告警和知識關聯，自動化處理故障。也就是說，IT運維自動化工具是監控自動化和流程自動化工具的完善和補充，三者結合相得益彰！

總體來說，運維自動化不是寫寫腳本，再用開源軟件東拼西湊就完了，這只能叫輔助運維，不叫自動化。據我所知，真正的自動化應該是讓運維平臺工具幫你’監測——發現——處理——解決問題”，集”自我修復、自我維護”為一體，各模塊之間盡量低耦合、可擴展、可插拔，最終實現運維智能化；也應該是真正能幫企業降低IT運成本，使運維管理可視化、可測量、可對比，進而真正將運維人員從繁瑣的、例行、容易發生人為事故的工作中脫離出來，做更有價值的運維工作。

運維自動化怎麽做？

很多運維人員在籌建IT運維自動化架構體系時，妄圖一口吃個大胖子，謀求一個完整的系統來自動化完成所有的運維工作，殊不知自動化是一個循序漸進持續發展的過程。我覺得在思考如何做運維自動化之前應該認識到幾個根本的原則問題：

標準必備

正所謂無規矩不成方圓，實施自動化前提需要標準規範與流程化。這包括資源標準化、OS的基礎配置標準化、基礎軟件（如Tomcat、JVM）配置標準化、應用配置標準化、流程規範標準化......比如，如Ngnix/JAVA/PHP/MySQL這些常見服務的應用初始化流程、部署更新流程等，可以提前固化下來，做到了標準化，消除了各種差異，才能為後續的自動化開發鋪平前進的道路。

與此同時，隨著ISO20000、ITIL v3.0的持續推廣，它們已成為實際的某種標準，尤其是ISO20000的認證要求，也是企業的普遍需求，而ITIL v3.0包含了對IT運維從戰略、設計到轉換、運營、改進的服務全生命周期的管理，也為企業的服務流程管理自動化提供了更多思路！

實用為先

大家常說，“公司的系統架構不是設計，而是演變而來的。”一般而言，企業要做運維自動化都不是一蹴而就，也不太可能一次性建好，都是分階段來做以解決自身實際問題：首先應該明確自身處於“手動支撐 —— 線上標準規範化——運維工具化——平臺自動化”的哪個階段，然後先找準現階段的痛點，對癥下藥。

說到實用，不得不提到——CMDB。關於“CMDB是不是運維自動化的基石“，不少運維還在疑惑，到底要不要建立CMDB呢? CMDB即配置管理數據庫，一般用於統一管理IT數據、服務器數據資產等。它不僅是硬件和資源的信息記錄，更重要是要建立起應用與資源之間的對應關系，並以此為基礎，配套著應用配置管理、監控、發布、穩定性等系統的建設，才能最終形成體系化的運維平臺，否則只是碎片化的運維模式。當然，這裏只是讓CMDB只提供最基礎的資源信息和應用資源的關聯關系，不期望把基礎的CMDB做得過重，不然後期會不堪重負！

安全為重

運維安全是企業安全保障的基石，不同於Web安全、移動安全、業務安全，隨著自動化運維管理體系的不斷融合與統一，運維安全環節任何一個代碼、一次部署出現問題往往會比較嚴重，很多時候說”牽一發而動全身“都不為過。此外，運維自動化平臺關聯的資源越來越多且復雜，甚至都涉及到了root權限，為廣大黑客朋友創造更多空間，所以加強自身安全防禦勢在必行。最基本的是加強權限和基線控制，是否針對運維自動化平臺的服務器賬號做了特殊限制？是否做了超限檢查？是否做了關鍵操作的雙保險？是否做了作業執行腳本、數據傳輸的加密控制？通通都得考慮，而堡壘機、安全審計、防火墻控制等措施更是不在話下了。

運維自動化安全建設牽扯面廣，這裏就不一一贅述了。還得提醒一點，在運維自動化操作層面，如何緩解自動化操作條件的變化而引發的巨大運維壓力，也應該認真考慮。

淺談運維自動化的那些事兒