談談我理解的運維體系

• 2019 年 11 月 20 日
• 筆記

我寫這個文章的動機，還是因為在會後很多人問我，「一個全局的運維體系應該是什麼樣的？」。這篇文章就給大家一個初步的回答。

• 價值體系（value）

我在任何場合都在強調運維價值／IT價值和用戶價值之間的關係，在精益運維的分享中，我推導過，用戶價值可以通過IT價值相互轉換的。這種轉換的能力，大家現在都可以直接感受得到，根本原因是IT形態發生的變化。之前IT中的「I」是information，這個IT作用傳遞通過很多線下的渠道去接觸，這個資訊系統是一個內部的管理系統，稱之為MIS（管理資訊系統）。現在IT中的「I」是Internet，是互聯網，互聯網本身就是客戶渠道，已經把用戶和內部的IT緊密的結合在一起了。

運維的價值是什麼？品質、成本、效率、安全！這些價值觀的理解和落地有多深有多遠，就是你對用戶價值的理解有多深又多遠。

有些人說你一直在倡導面向用戶的價值交付，好虛啊。說實話，開始我也覺得很虛，即使你的工作中參與了一些實際的價值創造，依然還是覺得很虛。比如我們做用戶頁面的體驗優化，這個是產品經理技術化理解不了的，他們關注的是業務運營措施對用戶指標的影響。其實技術同樣是有影響的，老外又來數據證明了，比如網頁打開速度。來自以下的統計數據：

• 網頁速度載入超過3秒，會損失超過57%的用戶，57%的用戶在3秒後還沒有載入完，就會離開，除非原因是她的電腦問題或網速問題。
• PV會減少11%，用戶滿意度降低16%，對話減少7%。
• 亞馬遜網站每延長1秒的載入時間，一年就會減少16億美元的銷售額。

在騰訊的工作經歷，嚴格把網頁打開速度作為和一個核心的業務品質考核指標，對應的直接是用戶體驗。

我倒是建議大家找一本客戶關係管理的書，看看在客戶關係管理的每一個階段，如何把客戶創造價值給提煉出來的，虛可以變成實！

用戶價值內嵌IT價值！

• 技術體系（technology）

技術體系，這個是對應Dev技術架構的體系，是和研發建立一致性架構標準和服務化平台標準，在避免架構失控的同時，建立一致的架構可運維性。

這個地方的難點是很多企業缺少公共架構組，或者說有些企業有公共架構組，而他不負責實現和落地，空談架構了。我提出的解決辦法是：架構組要背上應用技術架構服務化的指標，無論是自上而下的PaaS平台化也好，還是自底向上的組件服務化也好。注意，我講到的名詞是應用技術架構服務化，這個是要求架構組把產生的技術架構能力一定要應用到業務技術架構中去，空談架構是最容易的了。

那Dev技術架構體系和我運維有什麼關係呢？他決定了你維護成本的大與小，維護品質的高與低，維護效率的快與慢！否則，你只盯著運維平台，認為都是平台的事情。

技術標準有了，業務的碎片便沒有了！

• 平台體系（platform）

運維的平台體系，這個我在外面講得很多了。我從平台的業務目標也論證過，他應該是什麼樣子的；我從平台的功能架構上也拆解過（到三級）講過運維平台應該是長成什麼樣子的。

不過說實話，對於很多人來說，看到三級功能架構容易被淹沒，很理解。所以我的建議重點，你就從cmdb＋持續交付開始好了，另外在IaaS層在增加幾個組件服務化，比如說DNS／F5／作業系統安裝等等。總的平台抽象就是自動化體系和數據化體系。自動化體系以持續交付為核心，數據化體系以智慧監控和運營分析為核心。

平台不是工具！

• 標準體系（standard）

運維的標準很重要，並且很難建立統一的一套標準來適應所有的企業，越往應用端靠近，越難統一，但可以抽象統一。

在越靠近運維側的基礎設施的標準制定上，運維完全可以自主控制，像硬體機型的標準化。但偏嚮應用的標準化上，需要有技術手段控制和效果呈現。技術手段的控制不僅僅是運維平台上，如應用的持續交付平台管理，還有技術體系中，如能力SDK化／組件服務化等等。技術手段的效果呈現，這個是偏向一種數據能力。我們都一直在討論日誌如何標準化的問題，其實是可以建立一些技術的標準的，把日誌分成幾大類，webserver日誌／用戶端日誌／應用端日誌／介面級日誌等等。在定義日誌標準的同時，提供sdk化的能力，最終把數據採集回來呈現的效果要平台中看到，在通過數據去驅動決策／驅動優化，如此便是閉環了。

那天在現場也有同學提問這個問題，關於標準執行難的問題，其實原因有兩方面，一個方面是標準的制定有問題，可能有標準定的不對，或者是標準制定沒有考慮業務需求；另外一個方面標準缺少有效的技術手段控制。

標準的層次決定了控制力！

• 過程體系（process）

我的過程體系不是流程體系，流程體系是其中的一部分，他還有規範和制度的要求，目標及其roadmap的設定等等。過程體系包括為了達到某種目標，我們設定的執行路徑是什麼。這個路徑有兩個部分，一部分是基於產品的執行路徑；另外一個是不基於產品的執行路徑。

在數據化運維裡面，這個體現很明顯。在和大家針對我們的EasyOps產品溝通過程中，我一直說我們的運營分析平台提供的產品，如果不加入運維制度和規範的要求，那就是一個無用功能。另外標準化的落地推廣，如果是有平台來承載，他也需要一個過程。這就是我理解的基於產品的執行路徑。

不基於產品的執行路徑，大到你的運維目標設定和分解下來的roadmap，比如說運維平台體系的構建；小到你的運維流程，比如說事件流程、資源池管理流程等等。這個地方會沉澱一些制度和規範要求出來的，安全的規範／事件的規範／配置管理的規範／發布的規範／環境管理的規範等等。大家不要害怕規範，規範沉澱－》平台落地－》規範改進，這個是目的哈。

運維過程不是運維流程！

以上就是對一些提問者的回答，如果有欠缺的部分，請您補充並後台留言。