來源公眾號：木訥大叔愛運維
連結：https://mp.weixin.qq.com/s/NQ-13abASHSth2UtzI_I1Q
各位小夥伴，近期技術文感覺發的有點多，不知是否給大家在工作中解決實際問題帶來了一些靈感。為什麽這麽說呢？因為正是文章中涉及的細小知識點積少成多，讓我從零碎繁忙的運維工作中得到了一定程度的解放。相信認真讀過的小夥伴，一定會覺得工作中並非只有什麽高大上的技術才能解決痛點，恰恰相反，正是那些我們平時忽視的細節才是問題的要害。那麽只有切中要害，我們才能對癥下藥。
因此接下來一段時間，我可能會陸續分享運維過程中對一些問題的思考，希望給大家帶來一定的啟發。
本次分享的是運維管理與運維自動化的思考 。
一、運維的工作有哪些？
1.基礎設施，包括網路、伺服器、作業系統等工作；
2.環境管理，包括開發環境、測試環境、生產環境等；
3.部署，將套用或系統部署至不同環境；
4.監控，對基礎設施、套用或系統進行監控；
5.告警響應，對告警通知的響應及處理；
6.效能最佳化，對系統及相關元件效能進行最佳化；
7.系統高可用，對套用系統中的單點進行高可用升級；
8.SLA保障，保證業務系統的可用性，可根據SLA實作自動擴縮容；
以上工作是根據運維管理框架進行提取，包含但並不限於以上幾方面。
二、運維現狀
從「二八定律」來看，以上運維工作有80%可以透過繁瑣的手動處理進行處理，有20%需要根據不同因素來進行特定處理。
而80%的工作我們可以借助自動化進行處理，而剩下的20%可以借助監控的多維監控，對問題進行收集、分析進一步判斷處理。
三、運維管理
從運維現狀來看，我們優先需要解決的是自動化的問題，而自動化的前提是標準化/規範化，而好的自動化需要配合視覺化或web化，可以將我們80%或更多的工作進行最佳化。
因此目前我們總結的運維管理主要目標是標準化/規範化，自動化，視覺化/web化。
其中標準化可根據運維實際情況進行制定；而視覺化/web化，可以透過開源工具或web開發實作。
四、運維自動化
運維自動化可以實作的幾個主要方面：
1.伺服器上架自動化
新伺服器或虛擬機器從建立到交付到不同環境，需要進行一系列的客製，如cpu、記憶體、磁盤、ip地址、內核參數最佳化、時間同步、ssh加固、防火墻、各種客戶端安裝；當然這還不夠，若運維平台整合了cmdb、彈板機、zabbix等，伺服器上架還需要註冊到cmdb及彈板機、zabbix等管理工具；如還有其他工具也需要進行整合。
總之，伺服器上架自動化的最終目標是環境最佳化、安全可用、註冊到一切管理工具。
2.環境定義自動化
環境自訂分兩種情況：
（1）中小公司，測試環境包含所有的系統，即系統間是不隔離的，資料庫中包含各種系統對應的庫；
（2）大公司，每套系統需要單獨一套隔離的測試環境，各系統間不能互相存取；
對於環境定義的自動化比較適用於第二種情況，需要對需求部門快速建立資源。
總之環境定義自動化的主要原則無論是哪種情況，都要進行不同程度的隔離，減少環境連錯導致的問題。 排查環境問題是運維比較惡心的一個問題。
3.部署自動化
部署自動化的過程是不斷前進演化的， 大體分為：指令碼>批次ssh>自動化工具>容器 ，從每個過程來看部署自動化已經有批次操作>可用性>易用性>效率不斷轉變。部署自動化現在解決的不僅僅是部署本身了，還包括怎麽才能更快，更容易遮蔽底層的不同。
註意：此處聯想到【DevOps】思維導圖中關於自動化中的提高速度，即自動化初步完成，還需要進行速度方面的最佳化。
另部署自動化完成後，需要和監控進行聯動，即系統的可用性監控、效能監控等需要自動添加到監控系統。
4.監控自動化
從【系統監控體系】中我們知道監控物件分為從多個維度，每個維度可能用到的工具不一樣，即監控自動化可能需要對接不同的工具。如：
（1）自動添加可用性監控，如埠、url監控等
（2）自動添加日誌狀態監控，如status、error等
當然監控自動化不僅僅只針對監控，還要兼顧到故障恢復的自動化，即故障自愈。
5.版本釋出自動化
在伺服器規模不大的情況下，版本釋出要考慮摘節點、遮蔽告警等，需要和nginx、監控進行聯動。如：
（1）nginx實作平滑摘節點
（2）呼叫api實作監控項的禁用及啟動
五、運維自動化的幾個階段
站得高，看得遠。無論我們正在做哪個方面的自動化，從更高的層次了解運維自動化的各個階段，對我們更有益處：
1.操作自動化
這個層次的特征是把一系列的手工執行的操作，用指令碼或工具串聯，在一定程度上解決了運維手動執行的問題。但是不同的場景需要不斷調整指令碼或工具，反而增大了出錯機率。
2.場景自動化
這個層次的特征是工具會根據外部環境判斷如何執行，而這些判斷條件是運維事先定義好的。此層次的運維系統需要各類環境數據來作為判斷條件，同時還要能夠變化操作行為。
另，此層次的運維系統需要跟很多第三方系統對接（cmdb、網管系統）。
3.智慧化
此層次的運維系統具備數據核心（大數據儲存，所有營運中的數據都會按關聯關系集中儲存），具備根據數據自己分析和判斷、並自我決策和執行的能力。
在此層次，運維的主要工作是為系統增添分析策略、營運和維護此智慧運維系統，以及在系統執行的關鍵節點上介入做人工判斷。
六、怎樣做運維自動化
在我們思考怎麽做運維自動化之前，我們需要意識到「企業的架構不是設計出來的，是演變而來的」。因此我們可以借助這個作為指導思想。
1.先解決痛點
日常工作中，對常見問題進行分類和梳理，能做成工具的就工具化，能程式化操作的，就避免人為幹預。
至於是否基於cmdb，反而不太重要，特別是如果業務系統並沒有那麽大，伺服器的變動也沒那麽頻繁的話。
2.選擇正確的階段
運維自動化一般沿襲這樣的階段：手動支撐 => 線上標準規範化 => 運維工具化 => 平台自助化/自動化。選擇適合自己當前業務發展階段的運維自動化方式，不要一口吃成胖子。
另外，對於大中型運維自動化平台而言， CMDB和配置系統依然不可或缺。
CMDB即配置管理資料庫，一般用於統一管理IT數據、伺服器數據資產等。CMDB數據的準確性和權威性，關系到運維自動化是否走在正確的路上。
七、總結
1.運維自動化
在以上自動化過程中，在不同的自動化階段需要對接不同的第三方系統，因此可以看出一條統一的ESB（企業系統匯流排）來實作對系統的介面對接是多麽重要。但是也並不是沒有ESB就不好，不同階段解決的痛點不一樣，只有適合業務發展的階段的運維自動化才是最好的。
2.運維管理
文章開頭說運維管理主要目標是標準化/規範化，自動化，視覺化/web化，從切身體驗來看運維管理的目標也是隨著運維自動化階段的不同而變化的。
例如現在公司已經初步做到場景自動化及智慧化，雖然還不深入，在一定程度上我的運維工作也已經解放了80%左右，已經給我釋放了大部份時間，我也在想運維管理是否應該步入下一個階段：運維服務化？
理由：
（1）運維自動化的價值在於，將運維從繁瑣的、例行、容易發生人為事故的工作中脫離出來，做更有價值的業務運維和服務運維。
所以，從這個角度來看，運維自動化既不是起點，也不是終點。運維自動化不是萬能的，我們需要看清楚它的位置。
（2）運維的本質到底是服務，是服務於業務，因為運維是用技術解決業務問題，運維的價值要依托於業務才能體現。運維不是因為技術高深，或者管理了幾萬台伺服器而很牛逼，也不是能玩轉很多開源工具而很牛逼，這都不是運維的關鍵。對於運維來說，服務第一，技術第二。運維技術再牛，如果不能服務於業務，幫助業務取得成功，那價值也是有限的。
往期推薦
點亮，伺服器三年不宕機
