運維框架
下面我們從以下幾個問題入手來深入探討。
運維框架為什么要分層呢？
我認為有以下幾點：
運維是面向團隊而不是個人，分層能夠讓團隊中每個人找到自己的工作的重點、明確運維的管理思路與目標。
分層其實是將運維工作進行了邏輯上的拆解，形成了上下文。因此我們做的某些操作并不是孤立的，會牽扯到不同的層次，是可以有生命周期的。例如：服務(wù)器上架，就涉及到以下幾個層面：（1）基礎(chǔ)設(shè)施層：服務(wù)器、操作系統(tǒng)等（2）應(yīng)用層：基礎(chǔ)組件、中間件等（3）管理層：無人值守、cmdb、監(jiān)控等（4）展示層：zabbix、藍鯨等在沒有分層的情況下，我們就會孤立的重復(fù)操作，而忽略其實我們可以通過一套自動化流程徹底解決問題。
分層可以幫助我們更好的進行知識點梳理與盤點，對運維工作形成良性補充。
再說你就要說我吹NB了，但至少在我眼中是非常重要的，幫我理清了管理思路。
既然運維框架如此重要，那是如何生成的呢？
最終的運維框架其實并不是一蹴而就的，也是逐漸演化而來的，最初版如下：
最初版的運維框架粒度粗，但其核心要素為：
分為基礎(chǔ)設(shè)施、系統(tǒng)應(yīng)用、平臺服務(wù)幾個層次
基礎(chǔ)組件、業(yè)務(wù)組件、公共組件
開發(fā)技術(shù)棧分類
無論運維框架如何演進，以上要素都會以不同形式存在，因此我們在此階段需要好好梳理，為以后打好堅實的基礎(chǔ)。
此階段的缺點是系統(tǒng)應(yīng)用服務(wù)偏離了，關(guān)聯(lián)到業(yè)務(wù)上了，雖然運維是支撐業(yè)務(wù)的，但運維框架旨在梳理運維架構(gòu)，為運維提供架構(gòu)支撐。因此在后續(xù)單獨分離應(yīng)用層，從業(yè)務(wù)實現(xiàn)上分離出基礎(chǔ)服務(wù)、業(yè)務(wù)應(yīng)用、中間件三個共性特點。
運維規(guī)范
終于來到重點了，運維規(guī)范是如何生成的？
運維規(guī)范從來不是憑空捏造的，需要從碎片化的運維工作提取事實依據(jù)來生成
碎片化的運維工作存在于運維框架各個層面，因此運維規(guī)范按框架分層提取
明白以上兩點后，我們就可以按照運維框架中的各個層次來提取了。當然由于運維框架的不斷演進，因此運維規(guī)范是持續(xù)生成，不斷補充到運維工作中。
1.基礎(chǔ)設(shè)施服務(wù)
操作系統(tǒng)安裝規(guī)范
目錄管理規(guī)范
系統(tǒng)配置（初始化）規(guī)范
JDK安裝規(guī)范
網(wǎng)絡(luò)設(shè)備配置規(guī)范
等等
2.系統(tǒng)應(yīng)用規(guī)范
系統(tǒng)上線規(guī)范
進程管理規(guī)范
備份管理規(guī)范
hosts規(guī)范
等等
3.平臺服務(wù)規(guī)范
監(jiān)控管理規(guī)范
系統(tǒng)巡檢規(guī)范
日志收集規(guī)范
跳板機管理規(guī)范
CI/CD規(guī)范
等等
規(guī)范生成如圖：
規(guī)范最關(guān)鍵
當你有了規(guī)范后，是否應(yīng)用了一段時間就不再更新了呢？
如果發(fā)生這種情況，我覺得主要是以下幾個原因：
規(guī)范的總結(jié)成了工作的負擔；
規(guī)范的風(fēng)格不統(tǒng)一，團隊不同成員因格式五花八門，非?；靵y；
規(guī)范的文字太多，閱讀耗時，成了擺設(shè)；
另外，規(guī)范一定是可持續(xù)的，再結(jié)合以上問題，在最終生成規(guī)范時，運維團隊需要明確規(guī)范的目的，使規(guī)范輕裝上陣。
一、運維的工作有哪些？
1.基礎(chǔ)設(shè)施，包括網(wǎng)絡(luò)、服務(wù)器、操作系統(tǒng)等工作；2.環(huán)境管理，包括開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境等；3.部署，將應(yīng)用或系統(tǒng)部署至不同環(huán)境；4.監(jiān)控，對基礎(chǔ)設(shè)施、應(yīng)用或系統(tǒng)進行監(jiān)控；5.告警響應(yīng)，對告警通知的響應(yīng)及處理；6.性能優(yōu)化，對系統(tǒng)及相關(guān)組件如Nginx、Java、PHP、DB或網(wǎng)絡(luò)等的性能進行優(yōu)化；7.系統(tǒng)高可用，對應(yīng)用系統(tǒng)中的單點進行高可用升級；8.SLA保障，保證業(yè)務(wù)系統(tǒng)的可用性，可根據(jù)SLA實現(xiàn)自動擴縮容；以上工作是根據(jù)運維管理框架進行提取，包含但并不限于以上幾方面。
二、運維自動化
運維自動化可以實現(xiàn)的幾個主要方面：
1.服務(wù)器上架自動化新服務(wù)器或虛擬機從創(chuàng)建到交付到不同環(huán)境，需要進行一系列的定制，如cpu、內(nèi)存、磁盤、ip地址、內(nèi)核參數(shù)優(yōu)化、時間同步、ssh加固、防火墻、各種客戶端安裝；當然這還不夠，若運維平臺集成了cmdb、跳板機、zabbix等，服務(wù)器上架還需要注冊到cmdb及跳板機、zabbix等管理工具；如還有其他工具也需要進行集成?？傊?wù)器上架自動化的最終目標是環(huán)境優(yōu)化、安全可用、注冊到一切管理工具。
2.環(huán)境定義自動化環(huán)境自定義分兩種情況：（1）中小公司，測試環(huán)境包含所有的系統(tǒng)，即系統(tǒng)間是不隔離的，數(shù)據(jù)庫中包含各種系統(tǒng)對應(yīng)的庫；（2）大公司，每套系統(tǒng)需要單獨一套隔離的測試環(huán)境，各系統(tǒng)間不能互相訪問；
對于環(huán)境定義的自動化比較適用于第二種情況，需要對需求部門快速創(chuàng)建資源?？傊h(huán)境定義自動化的主要原則無論是哪種情況，都要進行不同程度的隔離，減少環(huán)境連錯導(dǎo)致的問題。排查環(huán)境問題是運維比較惡心的一個問題。
3.部署自動化部署自動化的過程是不斷進化的，大體分為：腳本＞批量＞自動化工具＞容器，從每個過程來看部署自動化已經(jīng)有批量操作＞可用性＞易用性＞效率不斷轉(zhuǎn)變。部署自動化現(xiàn)在解決的不僅僅是部署本身了，還包括怎么才能更快，更容易屏蔽底層的不同。
注意：此處聯(lián)想到《DevOps》思維導(dǎo)圖中關(guān)于自動化中的提高速度，即自動化初步完成，還需要進行速度方面的優(yōu)化。另部署自動化完成后，需要和監(jiān)控進行聯(lián)動，即系統(tǒng)的可用性監(jiān)控、性能監(jiān)控等需要自動添加到監(jiān)控系統(tǒng)。
4.監(jiān)控自動化從《系統(tǒng)監(jiān)控體系》中我們知道監(jiān)控對象分為從多個維度，每個維度可能用到的工具不一樣，即監(jiān)控自動化可能需要對接不同的工具。如：（1）自動添加可用性監(jiān)控，如端口、url監(jiān)控等（2）自動添加日志狀態(tài)監(jiān)控，如status、error等當然監(jiān)控自動化不僅僅只針對監(jiān)控，還要兼顧到故障恢復(fù)的自動化，即故障自愈。
5.版本發(fā)布自動化在服務(wù)器規(guī)模不大的情況下，版本發(fā)布要考慮摘節(jié)點、屏蔽告警等，需要和nginx、監(jiān)控進行聯(lián)動。如：（1）nginx實現(xiàn)平滑摘節(jié)點（2）調(diào)用api實現(xiàn)監(jiān)控項的禁用及啟動
五、運維自動化的幾個階段站得高，看得遠。無論我們正在做哪個方面的自動化，從更高的層次了解運維自動化的各個階段，對我們更有益處：1.操作自動化這個層次的特征是把一系列的手工執(zhí)行的操作，用腳本或工具串聯(lián)，在一定程度上解決了運維手動執(zhí)行的問題。但是不同的場景需要不斷調(diào)整腳本或工具，反而增大了出錯概率。
2.場景自動化這個層次的特征是工具會根據(jù)外部環(huán)境判斷如何運行，而這些判斷條件是運維事先定義好的。此層次的運維系統(tǒng)需要各類環(huán)境數(shù)據(jù)來作為判斷條件，同時還要能夠變化操作行為。另，此層次的運維系統(tǒng)需要跟很多第三方系統(tǒng)對接（cmdb、網(wǎng)管系統(tǒng)）。
3.智能化此層次的運維系統(tǒng)具備數(shù)據(jù)核心（大數(shù)據(jù)存儲，所有運營中的數(shù)據(jù)都會按關(guān)聯(lián)關(guān)系集中存儲），具備根據(jù)數(shù)據(jù)自己分析和判斷、并自我決策和執(zhí)行的能力。在此層次，運維的主要工作是為系統(tǒng)增添分析策略、運營和維護此智能運維系統(tǒng)，以及在系統(tǒng)執(zhí)行的關(guān)鍵節(jié)點上介入做人工判斷。
六、怎樣做運維自動化
在我們思考怎么做運維自動化之前，我們需要意識到“企業(yè)的架構(gòu)不是設(shè)計出來的，是演變而來的”。因此我們可以借助這個作為指導(dǎo)思想。
1.先解決痛點日常工作中，對常見問題進行分類和梳理，能做成工具的就工具化，能程序化操作的，就避免人為干預(yù)。至于是否基于cmdb，反而不太重要，特別是如果業(yè)務(wù)系統(tǒng)并沒有那么大，服務(wù)器的變動也沒那么頻繁的話。
2.選擇正確的階段運維自動化一般沿襲這樣的階段：手動支撐＝＞線上標準規(guī)范化＝＞運維工具化＝＞平臺自助化/自動化。選擇適合自己當前業(yè)務(wù)發(fā)展階段的運維自動化方式，不要一口吃成胖子。
另外，對于大中型運維自動化平臺而言，CMDB和配置系統(tǒng)依然不可或缺。CMDB即配置管理數(shù)據(jù)庫，一般用于統(tǒng)一管理IT數(shù)據(jù)、服務(wù)器數(shù)據(jù)資產(chǎn)等。CMDB數(shù)據(jù)的準確性和權(quán)威性，關(guān)系到運維自動化是否走在正確的路上。
七、總結(jié)1.運維自動化
在以上自動化過程中，在不同的自動化階段需要對接不同的第三方系統(tǒng)，因此可以看出一條統(tǒng)一的ESB（企業(yè)系統(tǒng)總線）來實現(xiàn)對系統(tǒng)的接口對接是多么重要。但是也并不是沒有ESB就不好，不同階段解決的痛點不一樣，只有適合業(yè)務(wù)發(fā)展的階段的運維自動化才是最好的。
2.運維管理文章開頭說運維管理主要目標是標準化/規(guī)范化，自動化，可視化/web化，從切身體驗來看運維管理的目標也是隨著運維自動化階段的不同而變化的。例如現(xiàn)在公司已經(jīng)初步做到場景自動化及智能化，雖然還不深入，在一定程度上我的運維工作也已經(jīng)解放了80%左右，已經(jīng)給我釋放了大部分時間，我也在想運維管理是否應(yīng)該步入下一個階段：運維服務(wù)化？
理由：（1）運維自動化的價值在于，將運維從繁瑣的、例行、容易發(fā)生人為事故的工作中脫離出來，做更有價值的業(yè)務(wù)運維和服務(wù)運維。所以，從這個角度來看，運維自動化既不是起點，也不是終點。運維自動化不是萬能的，我們需要看清楚它的位置。
（2）運維的本質(zhì)到底是服務(wù)，是服務(wù)于業(yè)務(wù)，因為運維是用技術(shù)解決業(yè)務(wù)問題，運維的價值要依托于業(yè)務(wù)才能體現(xiàn)。運維不是因為技術(shù)高深，或者管理了幾萬臺服務(wù)器而很牛逼，也不是能玩轉(zhuǎn)很多開源工具而很牛逼，這都不是運維的關(guān)鍵。對于運維來說，服務(wù)第一，技術(shù)第二。運維技術(shù)再牛，如果不能服務(wù)于業(yè)務(wù)，幫助業(yè)務(wù)取得成功，那價值也是有限的。
運維自動化之殤
運維自動化是我們的必經(jīng)之路，那么，一定就是解決所有問題的靈丹妙藥么？可能不盡然哦。潛在問題包括如下：
1）忽略權(quán)限和基線
運維自動化平臺通常由DevOps開發(fā)（例如Python+Shell），更多的是以實現(xiàn)功能為主，可能對賬號權(quán)限或服務(wù)器操作權(quán)限，未做特殊限制，這樣問題就來了，例如：
是否針對運維自動化平臺的服務(wù)器賬號做了特殊限制，使得這個賬號只能操作指定目錄，只能重啟Nginx、不能重啟PHP？
是否做了超限檢查？例如，對部分特殊請求如“rm-Rf”或超高數(shù)值調(diào)整做了二次過濾？
是否做了關(guān)鍵操作的雙保險？例如，數(shù)據(jù)庫合并類的危險操作，增加了一個檢查人審核機制？
另外，運維自動化發(fā)布平臺是否保存有程序基線，并有一鍵恢復(fù)功能？
大公司的業(yè)務(wù)系統(tǒng)，運行十多年，開發(fā)人員你來我往數(shù)以千計，而發(fā)布平臺每次僅更新部分代碼（類似縫縫補補）。這樣的后果是，可能根本沒有人有一套完整的業(yè)務(wù)系統(tǒng)代碼。
如果執(zhí)行任意系統(tǒng)命令+缺乏基線，兩者兼?zhèn)洌瑒偤糜钟腥擞|發(fā)了執(zhí)行操作，那么災(zāi)難性的后果就會突然來臨。
畢竟，對于歷史悠久的大型業(yè)務(wù)系統(tǒng)而言，老代碼往往沒人敢動，而且嚴重SOA化，從零重建的難度之大，也許需要幾十個小時。而又因為這種極端情況下，很難形成一個強一致性的版本，所以重建成功往往只是災(zāi)難的開始，之后就是開發(fā)、客服和DBA陷入長期的疲于奔命之中。
2）缺乏安全機制
運維自動化平臺一般由非專業(yè)開發(fā)人員實施，而且是給內(nèi)部人員使用，主觀上容易忽略代碼安全和系統(tǒng)安全。
“上帝節(jié)點”是安全災(zāi)難的起點。
之前沒有運維自動化，小米加步槍的時代，上千臺服務(wù)器相對獨立，還有各種堡壘機、動態(tài)令牌或私鑰登錄服務(wù)器等安全措施，想一個命令刪除大批量服務(wù)器的程序，還真不容易實現(xiàn)。
運維自動化平臺已然是“上帝節(jié)點”，天然的實現(xiàn)了連接到大批量服務(wù)器（甚至可能直接是root權(quán)限）。這樣，為廣大的黑客朋友帶來了無限想象空間。
有朋友可能會說，我放在公司內(nèi)網(wǎng)了非常安全。其實，現(xiàn)在黑客可以很容易的掃描到內(nèi)網(wǎng)所有域名，識別到疑似運維自動化平臺的域名，然后用常規(guī)或非常規(guī)手段入侵，然后就“一鍋端”了。例如：
你的運維自動化平臺是基于通用框架如Django么。一個常識是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。
3）忽略專業(yè)性
運維自動化越是充分的公司，隱藏的風(fēng)險就越大。
即使一個再優(yōu)秀的運維自動化平臺，也不能解決所有運維問題。所以，如果忽略了對人員專業(yè)能力的培養(yǎng)，那么在某些需要人工操作的場景（例如機房遷移這類重大調(diào)試），問題就會報復(fù)性的反彈和爆發(fā)。
一次專業(yè)的調(diào)試，體現(xiàn)在對調(diào)試時長和調(diào)試效果的掌控上。調(diào)試時長必須可接受、并可控。
例如一次跨機房遷移，停業(yè)務(wù)10小時甚至以上，是很難被接受的；停業(yè)務(wù)10分鐘以下，則是很令人愉快的。但這個的專業(yè)化要求很多，包括如充分的演練、更多的任務(wù)前置，保證只有必須的操作在調(diào)試期間進行。
可控性主要體現(xiàn)在調(diào)試節(jié)奏的把握，例如是否有快速可操作的回滾措施，保證如果預(yù)計調(diào)試不能如期完成，能提前預(yù)警并快速切回之前的系統(tǒng)狀態(tài)。
當有重大調(diào)試需求時，突然發(fā)現(xiàn)中級運維人員沒那么多了，初級運維人員缺少專業(yè)化鍛煉和練手機會，“手生”，主管不敢用之；高級運維人員都已“金盆洗手”多年，自己不敢上手。
4）自得和忽略人文關(guān)懷
運維自動化平臺上線后，運維人員可能會產(chǎn)生一種主觀的優(yōu)越感，并嚴重阻礙后續(xù)工作的開展。以前是開發(fā)追著運維打，運維往往疲于奔命，心力憔悴?，F(xiàn)在神器在手，容易“多年的媳婦熬成婆”。。。
其實運維自動化只是解決了運維部分工作效率的問題，遠沒有解決運維的全部問題，外部門對運維的不滿，可能濤聲依舊，例如經(jīng)常容易犯的“老板著個臉，說話直接不拐彎；需求老不及時完成，完不成也不說”等等。
運維自動化越是充分的公司，高層管理者（技術(shù)VP或CTO）可能產(chǎn)生一種錯覺，運維人員是否可以靠邊站了？甚至夸張些說，是否可以“卸磨殺驢”了？這種意識層的錯覺或者說自我心理暗示，會導(dǎo)致各種多米諾骨牌式的效應(yīng)。
如果高層忽略人為關(guān)懷，在某些極端情況下，運維自動化平臺的高權(quán)限人員，可能“有意”利用上述提及的平臺缺陷，進行極具破壞性的事情。。然后災(zāi)難性的后果，可能長時間難以補救。
結(jié)語
運維自動化的價值在于，將運維從繁瑣的、例行、容易發(fā)生人為事故的工作中脫離出來，做更有價值的業(yè)務(wù)運維和服務(wù)運維。
運維自動化，終歸只是一個高級工具而已。運維的價值最終是要體現(xiàn)在業(yè)務(wù)上的：
體現(xiàn)的方式就是運維服務(wù)化，所以運維自動化（智能化）最終都要為運維的服務(wù)化服務(wù)。所以如何構(gòu)建你的自動化系統(tǒng)最終要看你所支撐的業(yè)務(wù)需要什么樣的服務(wù)。
