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

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

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

2.從語言考慮：

SaltStack、Ansible python開發(fā)的

Puppet、Chef  ruby開發(fā)的

從用戶覆蓋考慮：

Ansible 、SaltStack、Puppet、Chef

從學習成本考慮：

Ansible 、SaltStack、Puppet、Chef

開源社區(qū)支持程度考慮：

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

大規(guī)模應用考慮：

SaltStack、Puppet、Chef 、Ansible

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

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

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

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

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

所以以下幾點值得注意：

（1）制定比較通用的校驗架構(gòu)，按腳本規(guī)范編寫腳本利于腳本的校驗；

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

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

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

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

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

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

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

1.運維制度的建立包括環(huán)境管理、資產(chǎn)管理、介質(zhì)管理、設備管理、監(jiān)控管理、網(wǎng)絡安全管理、系統(tǒng)安全管理、惡意代碼防范管理、密碼管理、變更管理、備份與恢復管理、安全事件處置，應急預案管理等制度。

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

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

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

（4）運維管理制度是為業(yè)務服務的，業(yè)務是不斷發(fā)展的，運維管理制度要跟得上業(yè)務的不斷發(fā)展實現(xiàn)管理制度的創(chuàng)新。

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

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

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

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

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

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

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

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

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

六、如何在運維自動化軟件真正實現(xiàn)標準化，規(guī)范化？

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

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

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

（3）由于業(yè)務增長迅速，系統(tǒng)（應用）環(huán)境需求天天都有很多 ， 運維自動化與標準化往往是由業(yè)務，IT環(huán)境驅(qū)動的，逐步優(yōu)化完善出來的。

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

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

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

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

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

八、如何在已有平臺實現(xiàn)實現(xiàn)Ansible 的的集成設計？

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

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

（2）直接借助SSH實現(xiàn)ansible 的集成

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

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

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

九、Ansible主機訪問目標主機的權(quán)限設置？

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

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

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

安全性高的特點。

在生產(chǎn)節(jié)點和非生產(chǎn)節(jié)點上啟動Ansible必須分兩批進行。

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

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

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

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

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

管理節(jié)點，admin.example.com，是執(zhí)行ansible命令的服務器

被管理的節(jié)點，internal1.example.com, internal2.example.com

堡壘機，bastion.example.com

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

管理節(jié)點連接堡壘機的方式如下：

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

從堡壘機連接internal節(jié)點的方式如下：

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

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

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

十一、對于多套不同架構(gòu)的基礎設施環(huán)境如何構(gòu)建自動化運維平臺？

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

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