共計 4703 個字符，預計需要花費 12 分鐘才能閱讀完成。
如何針對性破解 Linux 自動化運維落地的 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% 左右的需求，劣勢是需要理解已有的代碼，靈活性不夠。
以上關于企業自動化運維落地的 18 個問題的解答，希望對各位朋友有所幫助~
關于如何針對性破解 Linux 自動化運維落地的 18 個關鍵問題問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
