運維思考：運維管理與運維自動化 ｜ 8月更文挑戰

各位小夥伴，近期技術文感受發的有點多，不知是否給你們在工做中解決實際問題帶來了一些靈感。爲何這麼說呢？由於正是文章中涉及的細小知識點聚沙成塔，讓我從零碎繁忙的運維工做中獲得了必定程度的解放。相信認真讀過的小夥伴，必定會以爲工做中並不是只有什麼高大上的技術才能解決痛點，偏偏相反，正是那些咱們平時忽視的細節纔是問題的要害。那麼只有切中要害，咱們才能對症下藥。

所以接下來一段時間，我可能會陸續分享運維過程當中對一些問題的思考，但願給你們帶來必定的啓發。

本次分享的是運維管理與運維自動化的思考。

1、運維的工做有哪些？

1.基礎設施，包括網絡、服務器、操做系統等工做；
2.環境管理，包括開發環境、測試環境、生產環境等；
3.部署，將應用或系統部署至不一樣環境；
4.監控，對基礎設施、應用或系統進行監控；
5.告警響應，對告警通知的響應及處理；
6.性能優化，對系統及相關組件性能進行優化；
7.系統高可用，對應用系統中的單點進行高可用升級；
8.SLA保障，保證業務系統的可用性，可根據SLA實現自動擴縮容；

以上工做是根據運維管理框架進行提取，包含但並不限於以上幾方面。

2、運維現狀

從「二八定律」來看，以上運維工做有80%能夠經過繁瑣的手動處理進行處理，有20%須要根據不一樣因素來進行特定處理。

而80%的工做咱們能夠藉助自動化進行處理，而剩下的20%能夠藉助監控的多維監控，對問題進行收集、分析進一步判斷處理。

3、運維管理

從運維現狀來看，咱們優先須要解決的是自動化的問題，而自動化的前提是標準化/規範化，而好的自動化須要配合可視化或web化，能夠將咱們80%或更多的工做進行優化。

所以目前咱們總結的運維管理主要目標是標準化/規範化，自動化，可視化/web化。

其中標準化可根據運維實際狀況進行制定；而可視化/web化，能夠經過開源工具或web開發實現。

4、運維自動化

運維自動化能夠實現的幾個主要方面：

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實現監控項的禁用及啓動

5、運維自動化的幾個階段

站得高，看得遠。不管咱們正在作哪一個方面的自動化，從更高的層次瞭解運維自動化的各個階段，對咱們更有益處：

1.操做自動化

這個層次的特徵是把一系列的手工執行的操做，用腳本或工具串聯，在必定程度上解決了運維手動執行的問題。可是不一樣的場景須要不斷調整腳本或工具，反而增大了出錯機率。

2.場景自動化

這個層次的特徵是工具會根據外部環境判斷如何運行，而這些判斷條件是運維事先定義好的。此層次的運維繫統須要各種環境數據來做爲判斷條件，同時還要可以變化操做行爲。
另，此層次的運維繫統須要跟不少第三方系統對接（cmdb、網管系統）。

3.智能化

此層次的運維繫統具有數據核心（大數據存儲，全部運營中的數據都會按關聯關係集中存儲），具有根據數據本身分析和判斷、並自我決策和執行的能力。
在此層次，運維的主要工做是爲系統增添分析策略、運營和維護此智能運維繫統，以及在系統執行的關鍵節點上介入作人工判斷。

6、怎樣作運維自動化

在咱們思考怎麼作運維自動化以前，咱們須要意識到「企業的架構不是設計出來的，是演變而來的」。所以咱們能夠藉助這個做爲指導思想。

1.先解決痛點

平常工做中，對常見問題進行分類和梳理，能作成工具的就工具化，能程序化操做的，就避免人爲干預。
至因而否基於cmdb，反而不過重要，特別是若是業務系統並無那麼大，服務器的變更也沒那麼頻繁的話。

2.選擇正確的階段

運維自動化通常沿襲這樣的階段：手動支撐 => 線上標準規範化 => 運維工具化 => 平臺自助化/自動化。選擇適合本身當前業務發展階段的運維自動化方式，不要一口吃成胖子。

另外，對於大中型運維自動化平臺而言， CMDB和配置系統依然不可或缺。
CMDB即配置管理數據庫，通常用於統一管理IT數據、服務器數據資產等。CMDB數據的準確性和權威性，關係到運維自動化是否走在正確的路上。

7、總結

1.運維自動化

在以上自動化過程當中，在不一樣的自動化階段須要對接不一樣的第三方系統，所以能夠看出一條統一的ESB（企業系統總線）來實現對系統的接口對接是多麼重要。可是也並非沒有ESB就很差，不一樣階段解決的痛點不同，只有適合業務發展的階段的運維自動化纔是最好的。

2.運維管理

文章開頭說運維管理主要目標是標準化/規範化，自動化，可視化/web化，從切身體驗來看運維管理的目標也是隨着運維自動化階段的不一樣而變化的。

例如如今公司已經初步作到場景自動化及智能化，雖然還不深刻，在必定程度上個人運維工做也已經解放了80%左右，已經給我釋放了大部分時間，我也在想運維管理是否應該步入下一個階段：運維服務化？

理由：

• 運維自動化的價值在於，將運維從繁瑣的、例行、容易發生人爲事故的工做中脫離出來，作更有價值的業務運維和服務運維。

  因此，從這個角度來看，運維自動化既不是起點，也不是終點。運維自動化不是萬能的，咱們須要看清楚它的位置。

• 運維的本質究竟是服務，是服務於業務，由於運維是用技術解決業務問題，運維的價值要依託於業務才能體現。運維不是由於技術高深，或者管理了幾萬臺服務器而很牛逼，也不是能玩轉不少開源工具而很牛逼，這都不是運維的關鍵。對於運維來講，服務第一，技術第二。運維技術再牛，若是不能服務於業務，幫助業務取得成功，那價值也是有限的。