實現自動化運維就是將復雜的事情簡單化、標準化、流程化，通過工具重復性、周期性的實現。例如應用系統維護自動化，巡檢自動化和故障處理自動化等。能夠自動解決用戶在 IT 管理中的日常運維問題，最終實現提升運維效率的目的。然后在應用這些自動化運維工具，如SaltStack、Ansible、Puppet等等的過程中肯定會遇到不少問題和難點，以下是部分典型問題匯總。

一、目前，市面上有很多自動化運維工具，例如SaltStack、Ansible、Puppet、Chef等。各個工具使用方式也不相同。在進行工具選型時，需要考慮哪些方面的因素？

1.各種運維工具只是用于幫助人員進行運維的，每種工具都有其使用的優勢領域，Puppet適用于軟件自動化配置和部署；SaltStack適用于基礎設施管理，在幾分鐘內可運行起來，很容易管理上萬臺服務器，速度夠快；Ansible適用于批量操作系統配置、批量程序的部署、批量運行命令等；運維人員不想維護過多的平臺，我們都希望學習過程盡可能簡單，使用的工具強大，二次開發的成本也低，從這幾方面講SaltStack是一個很好的選擇。

2.從語言考慮：

SaltStack、Ansible python開發的

Puppet、Chef  ruby開發的

從用戶覆蓋考慮：

Ansible 、SaltStack、Puppet、Chef

從學習成本考慮：

Ansible 、SaltStack、Puppet、Chef

開源社區支持程度考慮：

Ansible 、SaltStack、Puppet、Chef 都支持的很好：

大規模應用考慮：

SaltStack、Puppet、Chef 、Ansible

二、自動化運維工具有哪些方式實現故障的準確定位？

1.一個小小的故障出現必將引起數十個甚至上百的設備報警，那么現階段的自動化運維軟件能夠把故障定位精確到什么程度？還是僅僅能做到提示，真正的故障原因還需要運維人員自己去手動找？故障定位算法采用機器學習中的二叉決策樹的方式實現: 一方面希望將故障所產生的所有告警信息整合為一條信息，減少告警量；另一方面希望能夠智能定位出故障點，減少工程師排查問題的時間，并引入自動化處理。以網絡故障原因定位為例，實現上述目標需要三步: 第一步：將問題排障過程的經驗提煉成二叉決策樹；第二步：將告警信息按照時間分片算法進行分類分組；第三步：將分組的告警信息輸出給決策樹進行自動推理輸出推理結果。智能定位出故障點，盡可能減少人工參與，提高運維效率。

2.設備的全面健康檢查狀態對比 巡檢腳本的指標巡檢完善度 同比類比，和趨勢對比 準確定位目前需要專家分析 目前情況代碼的穩定程度和it基礎架構的穩定程度相對完善 出現問題，一般會實現故障轉移，給我們時間進行故障分析避免再次發生

三、如何才能避免自動化運維工具使用后帶來的風險？

1.自動化運維平臺運行時，對于大批量操作，如版本變更，批量發布等一定要經過測試后才能進行批量操作。風險就是不知道執行的是否成功，有了校驗也不知道校驗的是否完全和執行是否成功。一般有了執行腳本就會有校驗腳本。

所以以下幾點值得注意：

（1）制定比較通用的校驗架構，按腳本規范編寫腳本利于腳本的校驗；

（2）有一些像配置核查的功能也能夠幫助我們找出配置的不一致，這些校驗功能幫助我們查出風險；

（3）自己編寫一些腳本各數據的腳本做成定時任務執行，定時的反饋信息；

（4）還有就是一些報表，報表也可以校驗數據。不同的校驗方法針對不同校驗級別的數據和功能。

（5）還有限制一些風險的操作，例如：rm，像這些操作就要有審核機制或者其他管理方法。

（6）應對風險還有一種就是操作日志，可以通過操作日志進行方向操作能夠找回數據。

2.權限控制，關鍵命令記錄雙人授權，變更時間窗口限制 批量執行的數量 等等 最簡單的就是權限控制，和執行操作審批。

四、企業實現自動化運維的高效率需要哪些制度或措施提供保障？

1.運維制度的建立包括環境管理、資產管理、介質管理、設備管理、監控管理、網絡安全管理、系統安全管理、惡意代碼防范管理、密碼管理、變更管理、備份與恢復管理、安全事件處置，應急預案管理等制度。

（1） 運維管理制度是衡量運維工作的一把尺子，完善的管理制度能有效的提升運維工作效率，日常工作以管理制度為依據，按規定的要求和規定的流程操作既快速又準確；

（2） 全面的運維管理制度能在問題和故障還沒有出現沒有造成損失前就被及時的發現，從而問題得到有效的處理，業務連續性得到了保障；

（3）運維管理制度為運維工作提供了規范化的解決方案，使運維人員在處理問題時有章可循快速找到問題的根本原因，把問題對業務造成的損失降到最低；

（4）運維管理制度是為業務服務的，業務是不斷發展的，運維管理制度要跟得上業務的不斷發展實現管理制度的創新。

2.雙人審核，特權審批。能自動化操作的全部編寫自動化腳本 定義自動化流程，減少前端運維人員手工操作風險。提高效率的關鍵是解放運維人員，把運維人員變成腳本開發人員或者程序開發者。

五、自動化運維如何體現價值，為客戶帶來怎樣的收益？它的價值如何體現？

1.自動化運維平臺的建設能為客戶帶來很多收益，包括以下幾個方面：

（1）在沒有 建設運維 平臺之前，一個 新 業務上線，需要做很多操作， 例 如DNS變更、LVS變更、OS初始化、自動化測試、持續部署、持續反饋、監控、業務調用關系配置等等。現在新業務上線只需要簡單的配置，剩余的工作由平臺協調自動完成上線。

（2）通過建設自動化運維平臺實現了對業務流程的有效梳理，有效的了解現有的IT資源、運行狀況、可靠性與可用性，使企業從全局掌握IT資源和資產的詳細信息，為企業的決策提供了有力的支撐；

（3）通過建設自動化運維平臺提高了運維工作效率，以前有很多需要人工參與處理的故障和事件，現在絕大部分由運維平臺自動按預定的規則進行處理，在運維響應時間上有了很大的提升；

（4）通過建設自動化運維平臺發現潛在的問題，降低了故障率，運維人員再也不是以前的救火隊員了，一些潛在的問題在萌芽階段就被發現和處理了，避免了故障造成的業務中斷；

（5）通過建設自動化運維平臺有利于故障的快速恢復，通過對以往時間點配置的保存建立配置基準快照，然后根據出現故障前后的配置基準的比對快速的發現故障的線索和根源，及時找到故障處理辦法恢復系統運行。

2.配置的標準化比例將大幅提高 操作的規范化比原來會有質的提升。

六、如何在運維自動化軟件真正實現標準化，規范化？

1.標準化和規范化是自動化運維平臺建設的基礎和關鍵點：

（1）實施自動化前提需要標準規范與流程化。比如如果系統版本，主機名，IP不統一規范，則可能會導致saltstack部署執行，日志監控部署，應用部署等一系列問題。

（2）運維自動化需要規范標準化，當然運維自動化又促進規范標準化。運維自動化，標準化需要落實，不能空談，標準要深入人心，融入日常行為中 。

（3）由于業務增長迅速，系統（應用）環境需求天天都有很多 ， 運維自動化與標準化往往是由業務，IT環境驅動的，逐步優化完善出來的。

（4）標準與自動化需要持續性改進優化 ， 運維自動化不是一蹴而就，而是逐漸持續性優化改進（ITIL理念）和實施的。

2.真正實現標準化，規范化。在我看來全部是人員問題。規范化：從人員抓起，規范是給人制定的，不按照規范進行操作進行懲罰和相關操作。無違規操作的進行獎賞。標準化：確定標準基線，不標準的一概進行整改，按時完成。無法完成的進行相關懲罰，對標準化高的進行獎勵。

七、細化自動化運維，制定相關標準，才能引領高效運維之路？

1.企業需要自動化運維，但是需要什么樣的自動化運維？是基于基礎平臺方向，還是業務運維方向？應對自動化運維進行專業細化，并制定相關標準，才能吸引更多的傳統中大型企業開展自動化運維。目前，我國的自動化運維相關開發均采用SaltStack、Ansible、Puppet等開源產品，開源產品本身漏洞多、迭代更新快，這讓傳統大型企業自身的運維人員難以承受，這就需要涌現出幾個大型頭部自動化運維廠商出來拿出標準化的自動化運維產品來引領中國自動化運維發展。

2.制定相關的行業標準是自動化運維發展一個保障，標準化是自動化運維的基礎，想要實現標準化，從小處講首先識別各個運維對象，然后我們日常做的所有運維工作都應該是針對這些對象的運維。如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清楚對象，運維自然不得章法。例如擴容，首先確定是服務器的擴容，還是應用的擴容，還是其它對象的擴容。你會發現，對象不同，擴容這個場景所實施的動作是完全不一樣的。如果把服務器的擴容套用到應用的擴容上去，必然會導致流程錯亂。同時對于對象理解上的不一致，也會增加無謂的溝通成本，造成運維效率低下。這種情況下的自動化運維不但不能提升效率，還會越自動越混亂。

八、如何在已有平臺實現實現Ansible 的的集成設計？

1.在已有平臺實現ansible 的集成設計包括兩種方法：

（1）通過專門的Jenkins插件實現ansible 的集成 優點：Ansible腳本被SCM版本控制，有助于追蹤歷史記錄。Ansible腳本與項目捆綁，容易查找并進行二次開發。缺點：積累難以復用，很容易陷入各自為戰。運維工作交給研發，在DEVOPS推進前期阻力比較大。

（2）直接借助SSH實現ansible 的集成

優點：Jenkins和Ansible分開部署，各自發展，避免一鍋端。Ansible腳本集中管理，方便知識共享。

缺點：個性化比較麻煩，比如針對已有項目的適配。

2.已有平臺可以開發api接口 java 拼裝命令發送給 api接口，接口調用 cli或者 python的ansible 接口運行 cmd命令 執行 解析返回結果入庫 或者使用play'book 上層平臺直接生產 playbook 然后用cli接口調用 ansble playbook 執行解析返回結果入庫。ansible 返回結果可以自己定義，直接返回到數據庫中這個需要修改 ansibe的返回部分代碼網絡上有相應案例可以參考。

九、Ansible主機訪問目標主機的權限設置？

1.Ansible主機對所有目標主機都能夠免密登錄，這塊存在一定的安全風險。如何確保Ansible主機的安全性，如何加強Ansible主機對目標主機訪問的控制？

針對這個問題需要把握以下幾點：

Ansible使用原生openssh，而openssh是全球范圍內最嚴格審查的程序之一，具有輕量級

安全性高的特點。

在生產節點和非生產節點上啟動Ansible必須分兩批進行。

配置較低權限的運維專用帳號，不能通過密碼或ssh密鑰使用root登錄。

2.Ansible 自有一個簡單 acl 控制，輸入配置文件中的密碼才能向指定機器發布命令和執行playbook 但配置文件是明文的，可修改為加密方式需要修改下 ansible代碼。

十、自動化運維工具安全審計問題？

1.一般機構都有堡壘機（運維審計平臺）自動化運維繞過了審計，這方面是如何做的。像ansible 使用ssh 是如何與堡壘機對接的。還是單獨建立帳戶權限，或直接使用秘鑰認證。

Ansible可以通過堡壘機管理被管節點，例如有三類節點：

管理節點，admin.example.com，是執行ansible命令的服務器

被管理的節點，internal1.example.com, internal2.example.com

堡壘機，bastion.example.com

管理節點不能直連 internal1 & internal2，需要通過堡壘機建立連接。

管理節點連接堡壘機的方式如下：

ssh -i keyfile_bastion -p 12345user@bastion.example.com

從堡壘機連接internal節點的方式如下：

ssh -i keyfile_internal -p 23456 user@internal1.example.com

ssh -i keyfile_internal -p 23456 user@internal2.example.com

2.自動化運維工具集成 ansible,記錄所有操作內容和執行歷史日志。

十一、對于多套不同架構的基礎設施環境如何構建自動化運維平臺？

1.隨著公司多年的業務發展情況，已經形成了多套異構的基礎設施生產運營環境，主要涵蓋了：純物理機集群環境、基于 Esxi 主機的虛擬化集群環境、采用 OpenStack 高可用方案的私有云集群環境，當前也已經從最初的小型機+x86 主機+SAN的硬件基礎設施，替換成全 x86 主機的硬件基礎設施。但由于三套不同的環境下均有生產性系統要保證持續的運行，對于三套不同的環境各有不同的運維要求，對整體的 IT 運維帶來了很大的壓力。但由于評估將基礎設施環境全部替換為統一的基礎設施需要的周期比較長，所以想先初步將多套環境的運維盡量采用自動化的方式進行提升，以減輕運維工作的壓力。當前遇到的主要問題是，采用何種方案能夠比較簡便的實現對多套環境的統一自動運維，以及在后續進行環境遷移的時候，方便通過配置調整而實現自動化運維的靈活適應。

2.SaltStack提供三種運行方式，包括Local本地運行交付管理，Master/Minion方式，不需要客戶端Salt SSH方式，SaltStack提供方法來管理目標系統的狀態。通過高效的遠程執行引擎，任何配置可以被管理應用到遠程系統SaltStack。雖然它主要設計用于Linux平臺，SaltStack也可以管理其他操作系統，包括VMware vSphere環境。可以通過saltstack創建Openstack虛擬機，實現Saltstack對Openstack的管理。