運維思索：運維規範如何生成？

這是我參與8月更文挑戰的第4天。

簡述

前面的文章老說「運維管理」、「運維自動化」，可能你們都聽煩了，大道理誰都會說，能不能來點乾貨，把這些「大白話」落地？

我本身也不斷在想是否應該將這些分享出來，由於都是本身在工做過程當中的我的理解，都是野路子。但換個角度，運維的工做並非簡單的修修補補，而是給業務賦能，讓本身實現價值的，所以接下來的文章更多的是進行落地。

運維框架

《運維思考：運維管理與運維自動化》一文中咱們從運維工做中提取了運維框架（紅色表明缺失），由基礎設施層、數據層、應用層、管理層、展現層組成，生成了咱們最終的運維體系。

下面咱們從如下幾個問題入手來深刻探討。

1.運維框架爲何要分層呢？ 我認爲有如下幾點：

• 運維是面向團隊而不是我的，分層可以讓團隊中每一個人找到本身的工做的重點、明確運維的管理思路與目標。
• 分層實際上是將運維工做進行了邏輯上的拆解，造成了上下文。所以咱們作的某些操做並非孤立的，會牽扯到不一樣的層次，是能夠有生命週期的。

例如：服務器上架，就涉及到如下幾個層面： （1）基礎設施層：服務器、操做系統等 （2）應用層：基礎組件、中間件等 （3）管理層：無人值守、cmdb、監控等 （4）展現層：zabbix、藍鯨等 在沒有分層的狀況下，咱們就會孤立的重複操做，而忽略其實咱們能夠經過一套自動化流程完全解決問題。

• 分層能夠幫助咱們更好的進行知識點梳理與盤點，對運維工做造成良性補充。
• 再說你就要說我吹NB了，但至少在我眼中是很是重要的，幫我裏清了管理思路。

2.既然運維框架如此重要，那是如何生成的呢？

最終的運維框架其實並非一蹴而就的，也是逐漸演化而來的，最第一版以下：

最第一版的運維框架粒度粗，但其核心要素爲：

• 分爲基礎設施、系統應用、平臺服務按個層次
• 基礎組件、業務組件、公共組件
• 開發技術棧分類

不管運維框架如何演進，以上要素都會以不一樣形式存在，所以咱們在此階段須要好好梳理，爲之後打好堅實的基礎。

此階段的缺點是系統應用服務偏離了，關聯到業務上了，雖然運維是支撐業務的，但運維框架旨在梳理運維架構，爲運維提供架構支撐。所以在後續單獨分離應用層，從業務實現上分離出基礎服務、業務應用、中間件三個共性特色。

運維規範

終於來到重點了，運維規範是如何生成的？

• 運維規範歷來不是憑空捏造的，須要從碎片化的運維工做提取事實依據來生成
• 碎片化的運維工做存在於運維框架各個層面，所以運維規範按框架分層提取

明白以上兩點後，咱們就能夠按照運維框架中的各個層次來提取了。固然因爲運維框架的不斷演進，所以運維規範是持續生成，不斷補充到運維工做中。

1.基礎設施服務

• 操做系統安裝規範
• 目錄管理規範
• 系統配置（初始化）規範
• JDK安裝規範
• 網絡設備配置規範
• 等等

2.系統應用規範

• 系統上線規範
• 進程管理規範
• 備份管理規範
• hosts規範
• 等等

3.平臺服務規範

• 監控管理規範
• 系統巡檢規範
• 日誌收集規範
• 跳板機管理規範
• CI/CD規範
• 等等

規範生成如圖：

規範最關鍵

當你有了規範後，是否應用了一段時間就再也不更新了呢？ 若是發生這種狀況，我以爲主要是如下幾個緣由：

1. 規範的總結成了工做的負擔；
2. 規範的風格不統一，團隊不一樣成員因格式五花八門，很是混亂；
3. 規範的文字太多，閱讀耗時，成了擺設；

另外，規範必定是可持續的，再結合以上問題，在最終生成規範時，運維團隊須要明確規範的目的，使規範輕裝上陣。

爲解決這個問題，我給規範自己也定製了一個規範：

總結

運維規範只是自動化的前提，有了規範只是完成了萬里長征的第一步，接下來咱們只須要嚴格按規範去執行、不斷的進行優化，剩下的都是水到渠成的事兒了。

最後，個人「野路子」就是這麼來的，但願對你們有所啓發，不喜勿噴！