我自己也不斷在想是否應該將這些分享出來，因為都是自己在工作過程中的個人理解，都是野路子。但換個角度，運維的工作並不是簡單的修修補補，而是給業務賦能，讓自己實現價值的，因此接下來的文章更多的是進行落地。
運維思索：運維管理與運維自動化一文中我們從運維工作中提取了運維框架（紅色代表缺失），由基礎設施層、資料層、應用層、管理層、展示層組成，生成了我們最終的運維體系。
1.運維框架為什麼要分層呢？
我認為有以下幾點：
2.既然運維框架如此重要，那是如何生成的呢？
最終的運維框架其實並不是一蹴而就的，也是逐漸演化而來的，最初版如下：
無論運維框架如何演進，以上要素都會以不同形式存在，因此我們在此階段需要好好梳理，為以後打好堅實的基礎。
此階段的缺點是系統應用服務偏離了，關聯到業務上了，雖然運維是支撐業務的，但運維框架旨在梳理運維架構，為運維提供架構支撐。因此在後續單獨分離應用層，從業務實現上分離出基礎服務、業務應用、中介軟體三個共性特點。
終於來到重點了，運維規範是如何生成的？
明白以上兩點後，我們就可以按照運維框架中的各個層次來提取了。當然由於運維框架的不斷演進，因此運維規範是持續生成，不斷補充到運維工作中。
1.基礎設施服務
2.系統應用規範
3.平台服務規範
規範生成如圖：
當你有了規範後，是否應用了一段時間就不再更新了呢？
如果發生這種情況，我覺得主要是以下幾個原因：
規範的總結成了工作的負擔；
規範的風格不統一，團隊不同成員因格式五花八門，非常混亂；
規範的文字太多，閱讀耗時，成了擺設；
另外，規範一定是可持續的，再結合以上問題，在最終生成規範時，運維團隊需要明確規範的目的，使規範輕裝上陣。
為解決這個問題，我給規範本身也定製了乙個規範：
運維規範只是自動化的前提，有了規範只是完成了萬里長征的第一步，接下來我們只需要嚴格按規範去執行、不斷的進行優化，剩下的都是水到渠成的事兒了。
最後，我的「野路子」就是這麼來的，希望對大家有所啟發，不喜勿噴！
IT運維服務規範
本部分規定了it運維服務支撐系統的應用需求，包括it運維服務模型與模式 it運維服務管理體系 以及it運維服務和管理能力評估與提公升途徑。本部分適用於企業理解智控國際it運維服務管理體系，指導智控國際為客戶提供it運維服務和it運維服務支撐系統。一 總則 2 二 參考標準 2 三 術語 定義和縮略語...
運維（1）什麼是運維
運維，這裡指網際網路運維，通常屬於技術部門，與研發 測試 系統管理同為網際網路產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。乙個網際網路產品的生成一般經歷的過程是 產品經理 需求分析 研發部門開發 測試部門測試 運維部門部署發布以及長期的執行維護。對於初創公司，運維部...
初級運維個人運維筆記
實時抓取並顯示當前系統中tcp 80埠的網路資料資訊，請寫出完整操作命令 tcpdump nn tcp port 80 如何重置mysql root密碼？一 在已知mysql資料庫的root使用者密碼的情況下，修改密碼的方法 1 在shell環境下，使用mysqladmin命令設定 mysqladm...