如何針對性破解自動化運維落地的18個關鍵問題？

不久前，我做過一個關於企業自動化運維落地經驗及工具對比的分享和介紹，其中很多場景是我根據實踐經驗對一線網際網路公司和傳統行業的做法進行的對比闡述：如何將自動化運維形成一個整體？如何從方法論的角度去理解自動化運維、去建設自動化運維？該文引發很多讀者的感觸、思考。

本文通過整理運維愛好者們提出的一系列自動化運維落地的具體問題及討論結果，總結成文，供大家參考學習。

一、自動化運維平臺風險

問題1：自動化運維風險如何控制？

一是所有自動化功能模組的本質都是落到程式碼層面，那麼就需要對自動化運維功能的程式碼進行測試，適用於開發專案管理的流程；

二是對於一些刪除或者修改類的操作，需要考慮double check和回滾方案，對於不能回滾的操作不能做（這點其實和手工操作是沒有區別的）；

三是灰度策略，可以採用灰度的方式來驗證自動化操作結果和預期是否一致，如果一致則繼續進行，如果不一致則需要進行回滾；

四是監控配合，監控系統能夠及時發現有問題的操作並及時報警；

五是許可權管理，對於能夠操作自動化運維平臺的，需要有嚴格的許可權控制；

六是通過API對接的系統，需要有鑑權機制。

問題2：自動化運維平臺的安全和許可權如何控制？

個人認為應該注意以下幾個方面：

 ●  對於Web頁面操作的通過AD域加角色的方式進行許可權控制；
 ●  對於介面呼叫的情況需要有相應的許可權模組；
 ●  對於運維平臺自身，要防止平臺在未授權的情況下對生產資源進行刪除和修改操作；

 ●  定期對平臺進行安全掃描，掃描平臺自身的漏洞。

二、自動化運維平臺規劃

問題1：自動化運維的建設應該如何規劃？

這個問題沒有固定的答案，分幾步需要結合具體情況，最終的目的是要實現所有的端到端的交付。一般來說大體可以分為以下幾個階段：

 ●  解決目前最急切的痛點（這裡一般是指運維團隊自身最大的痛點或者擠壓已久的沒有解決的其他團隊提出的問題）；
 ●  收集IT部門其他組（開發和測試團隊）的自動化運維需求並內部排期解決；
 ●  在解決了前兩者點上的問題之後，將各個點串聯起來，消除點與點之間人肉工作；
 ●  在初步形成的自動化運維鏈條上查漏補缺，形成正向反饋鏈條。

問題2：自動化運維建設中，標準化的規範如何制定？

標準化需要結合公司的具體情況，一般而言有以下幾個方面需要進行標準化（供參考）：

 ●  伺服器Pod標準化，一個Pod放幾臺機器，如何連線；
 ●  物理機機型，計算密集型、記憶體型、IO密集型還是儲存型，需要將不同廠商的機型歸納為幾個標準機型；
 ●  作業系統標準化，包括作業系統版本、作業系統核心引數、碟符路徑等；
 ●  軟體安裝標準化，包括軟體版本、安裝路徑、日誌路徑、日誌切割、引數調優等；
 ●  軟體部署標準化，雙節點不能部署在同一臺物理機和同一個機櫃上，避免主機和機櫃級故障。

問題3：在實際的運維環境中，我們該如何制定一套完整的自動化運維管理方案，用來支撐自動化運維工作？

制定自動化運維方案，需要考慮以下幾個方面：

 ●  明確制定自動化運維方案的目的，這是制定自動化運維方案的指導思想；
 ●  明確自動化運維方案的服務物件角色；
 ●  明確不同的物件角色在自動化運維過程中的抓手分別是什麼；
 ●  明確自動化運維方案落地過程中需要注意的安全問題（例如許可權細化、呼叫鑑權、操作審計等）；
 ●  通過調研的方式進一步瞭解其他同事的運維需求；
 ●  在方案裡明確建設自動化運維平臺計劃分幾個階段，將需求分散在這幾個階段裡；
 ●  明確將自動化運維方案落地為自動化運維平臺時的具體方式（自研、外購還是基於外購進行二次開發）；
 ●  在自動化運維方案中明確平臺在使用過程中的正向反饋流程。

問題4：自動化運維的建設，需要分幾階段進行？應如何做規劃？

這個問題沒有固定的答案，分幾步需要結合具體情況，最終的目的是要實現所有端到端的交付。一般來說大體可以分為以下幾個階段：

 ●  解決目前最急切的痛點；
 ●  收集IT部門其他組（開發和測試團隊）的自動化運維需求；
 ●  在解決了前兩者點上的問題之後，將各個點串聯起來，消除點與點之間人肉工作；

 ●  在初步形成的自動化運維鏈條上查漏補缺。

三、CMDB資料採集問題

問題1：CMDB建設過程中，如何實現自動發現？

CMDB的自動發現一般基於以下幾種方式：

 ●  通過呼叫被採集方軟體的API介面獲取相關資訊，例如VMware、EMC儲存等；
 ●  通過某種協議（公有或者是私有協議），例如SNMP去獲取相關配置資訊；
 ●  通過在主機上執行命令，並對結果進行處理，例如抓取主機上中介軟體的資訊；
 ●  通過執行中介軟體的命令來獲取資訊。

自動化發現一般是通過以上幾種方式的組合來實現自動發現的目的。

問題2：自動化運維的建設中如何選擇CMDB自動收集資料？

這個問題有點大了，具體到資料收集這個點上而言，CMDB的資料要想收集全面，需要從兩個方面去考慮：一是CMDB採集工具自身的自動化採集能力，二是有些資料需要通過流程的方式來督促人工錄入，例如業務系統名稱、業務系統運維負責人、開發負責人、測試負責人這些資訊自動採集工具是採集不到的，需要人工維護。

如果需要建設CMDB系統，有三種思路：

 ●  完全自研，這就要求團隊的研發能力比較強，並且有人對ITIL的流程比較瞭解，自動採集實現較慢；
 ●  直接採購商業的CMDB產品，好處是快速上線、自動採集能力強，缺點是有些需求可能無法直接滿足，需要定製開發；
 ●  基於開源的產品做二次開發，例如基於IOP，但是自動發現能力還是要自己實現，優勢是有一個基本可用的框架。

問題3：如何同時保證CMDB資料的實時性與一致性？

 ●  實時性：保證CMDB資料的實時性需要依賴CMDB工具的自動化採集能力；

 ●  一致性：一致性需要流程控制和定期的資料審計操作，資料審計操作可以藉助CMDB平臺的能力來實現。

四、運維工具選型

問題1：自動化運維工具選擇時，應該對哪些因素進行考量？

在選擇自動化運維工具時筆者認為應該從以下幾個方面考量：

 ●  自動化運維工具的成熟度，即在業界的受眾面。這裡無論是對商用的還是開源的都可以從這個角度進行評估；
 ●  自動化運維工具的功能能否滿足運維需求；
 ●  如果是選擇開源的自動化運維工具還要考慮工具的技術棧和公司人員的技術棧是否匹配；
 ●  自動化運維工具在安全方面是否有良好的支援；
 ●  自動化運維工具在工作過程中對主機效能的影響，尤其還要測試在併發大的時候，對運維工具平臺自身服務端的壓力；
 ●  還要考慮選擇的自動化運維工具是否滿足公司後續技術棧的發展需要。

問題2：自動化運維建設中的運維工具的規劃和整合問題？

目前而言，大多數公司的確會存在這樣的問題。在我看來問題之所以會存在，最主要原因是在前期缺乏一個巨集觀的整體規劃，各個組織各自為政，沒有統籌管理。

那麼對於已經存在的現狀要如何處理呢？在我看來要做以下幾件事：

 ●  需要成立一個治理小組，成員包括各個存在系統的Owner，然後由一位領導擔任組長；
 ●  各個系統Owner闡述當初建設這個系統的背景以及該系統現在能解決什麼問題、還有什麼問題沒有解決；
 ●  依據第二步的討論結果進行合併工作，將能合併的系統進行合併，不能合併的但是功能有重疊的進行資料打通，統一進行輸出；
 ●  後續新建系統時需要由治理小組統一規劃，避免類似事情再發生。

問題3：自動化運維產品如何選擇？

自動化運維涉及的面非常廣，一般大家談到的包括資源的自助服務、監控、排程任務、應用釋出等。那麼在選擇產品的時候需要考慮以下幾點：

 ●  梳理清楚自身的痛點，即目前最需要解決的問題是什麼；
 ●  規劃：計劃在3年內做到什麼樣的效果；
 ●  所選自動化運維平臺的產品成熟度（同行業案例多少）；
 ●  自動化運維平臺的開發程度，能否進行二次開發或者是支援功能擴充；
 ●  平臺的技術框架是否是主流的技術框架；

 ●  通過試用來測試和本地實際情況的結合程度。

五、其他

問題1：AIOps和自動化運維是什麼關係？

AIOps是自動化運維的一部分，是這幾年隨著AI火爆後開始出現的領域，自動化涉及運維操作的方方面面，AIOps僅僅是將AI技術應用到現有的Ops平臺上，一般同時都會結合大資料技術一起使用。

問題2：是否可以結合當前的一些先進技術，如雲端計算、大資料等，使得自動化運維更加高效、智慧？

結合雲端計算能力，可以快速擴容自動化運維平臺的服務能力；結合大資料和人工智慧技術，可以使自動化運維平臺提供更強大的功能，就是現在很多人開始關注的AIOps。

風險需要人工來稽核，比如基於大資料和人工智慧技術對某種行為進行自動操作，那麼在剛開始使用這個技術的時候需要人工進行double check，並且對劃定優先順序和重要性級別。對於一個低優先順序和低重要級的可以自動處理。

問題3：在運維的關注點上，傳統企業與網際網路企業有哪些不同？

傳統行業與網際網路在運維環節的不同在以下幾個方面：

 ●  運維程式碼化：傳統行業的運維更多的還是停留在人工操作運維平臺的層面甚至是純人工操作，而網際網路更多的是通過程式碼來進行運維，避免人工操作，這也是為什麼網際網路公司對運維有要求開發能力的原因；
 ●  點化與線性化：傳統行業的運維分不同時間購進了很多運維平臺，而各個運維平臺之間是獨立的、離散的。而網際網路的運維平臺多是線性的，可以實現端到端的交付與串聯；
 ●  對人員要求不同：網際網路公司無論是哪個層面的運維都要求有一定的開發能力或者是一些原理的深入瞭解（程式碼層面），而傳統行業更多的是對操作層面的要求。

問題4：自動化運維平臺如何能更好的貼近業務？及時發現業務的已經發生的風險和將要發生的風險？

自動化運維要更好的貼近業務首先需要收集業務的自動化運維需求，通過平臺來滿足業務的自動化運維需求，這是第一步要做的工作。

其次需要對業務系統進行監控，在此基礎上，需要和業務溝通風險指標，將風險指標進行量化，並配置到自動化運維平臺的監控系統中，利用平臺的監控能力進行724小時監控，當出現指標達到報警閾值的時候，就通過簡訊、微信、郵件等方式進行告警。

最後，對於風險指標的配置可以通過大資料分析和AI的結合來逐步完善，形成一個適合每個業務系統的正向反饋鏈。

問題5：傳統的IT運維與自動化運維有什麼差別？

之所以會出現半自動化的運維，其實就是因為這些解決的都是點上的問題，都是把每個點的人工操作變成了指令碼化或者平臺化的自動動作，是離散的，本質上還是點而不是線，更不是面。真正的自動化運維是要達到端到端的自動化交付，是從開發到測試到運維全鏈路的自動化，去除人工操作。

舉一個例子，建立一個Redis中介軟體，半自動化的做法是：

 ●  在虛擬化平臺申請機器；
 ●  網路分配IP地址（人工）；
 ●  通過另外的指令碼對機器進行初始化（人工執行指令碼）；
 ●  通過安裝指令碼安裝Redis（人工安裝）；
 ●  郵件或者人工告知申請方。

自動化的做法是：提交建立Redis需求，自動化平臺做好所有的事情，然後呼叫郵件介面，通知申請者。

問題6：自動化運維自主研發的邊界如何界定？既可以做到自主可控，又可以全面發揮和提升員工的能力？

自主可控有兩種思路，一種是完全自研；另一種是基於一個採購的自動化運維平臺進行二次開發。

對於第一種情況，需要公司人員具備一定的開發能力，優勢在於可以並充分結合本地需求，缺點是對人員要求比較高並且平臺成型較慢；

對於第二種情況，需要採購一個平臺技術棧實現與本公司開發或者運維人員匹配的平臺，並且要求平臺方開放原始碼或者提供豐富的二次開發介面，優勢是可以快速滿足至少80%左右的需求，劣勢是需要理解已有的程式碼，靈活性不夠。

原文釋出時間為：2018-10-29

本文作者：王洋

本文來自雲棲社群合作伙伴“DBAplus社群”，瞭解相關資訊可以關注“DBAplus社群”。