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

簡述

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

我自己也不斷在想是否應該将這些分享出來，因為都是自己在工作過程中的個人了解，都是野路子。但換個角度，運維的工作并不是簡單的修修補補，而是給業務賦能，讓自己實作價值的，是以接下來的文章更多的是進行落地。

運維架構

運維思索：運維管理與運維自動化一文中我們從運維工作中提取了運維架構（紅色代表缺失），由基礎設施層、資料層、應用層、管理層、展示層組成，生成了我們最終的運維體系。

下面我們從以下幾個問題入手來深入探讨。

1.運維架構為什麼要分層呢？

我認為有以下幾點：

• 運維是面向團隊而不是個人，分層能夠讓團隊中每個人找到自己的工作的重點、明确運維的管理思路與目标。

• 分層其實是将運維工作進行了邏輯上的拆解，形成了上下文。是以我們做的某些操作并不是孤立的，會牽扯到不同的層次，是可以有生命周期的。

  例如：伺服器上架，就涉及到以下幾個層面：

  （1）基礎設施層：伺服器、作業系統等

  （2）應用層：基礎元件、中間件等

  （3）管理層：無人值守、cmdb、監控等

  （4）展示層：zabbix、藍鲸等

  在沒有分層的情況下，我們就會孤立的重複操作，而忽略其實我們可以通過一套自動化流程徹底解決問題。

• 分層可以幫助我們更好的進行知識點梳理與盤點，對運維工作形成良性補充。
• 再說你就要說我吹NB了，但至少在我眼中是非常重要的，幫我裡清了管理思路。

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

最終的運維架構其實并不是一蹴而就的，也是逐漸演化而來的，最初版如下：

最初版的運維架構粒度粗，但其核心要素為：

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

無論運維架構如何演進，以上要素都會以不同形式存在，是以我們在此階段需要好好梳理，為以後打好堅實的基礎。

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

運維規範

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

• 運維規範從來不是憑空捏造的，需要從碎片化的運維工作提取事實依據來生成
• 碎片化的運維工作存在于運維架構各個層面，是以運維規範按架構分層提取

明白以上兩點後，我們就可以按照運維架構中的各個層次來提取了。當然由于運維架構的不斷演進，是以運維規範是持續生成，不斷補充到運維工作中。

1.基礎設施服務

• 作業系統安裝規範
• 目錄管理規範
• 系統配置（初始化）規範
• JDK安裝規範
• 網絡裝置配置規範
• 等等

2.系統應用規範

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

3.平台服務規範

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

規範生成如圖：

規範最關鍵

當你有了規範後，是否應用了一段時間就不再更新了呢？

如果發生這種情況，我覺得主要是以下幾個原因：

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

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

為解決這個問題，我給規範本身也定制了一個規範：

總結

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

最後，我的“野路子”就是這麼來的，希望對大家有所啟發，不喜勿噴！