標準化：運維過程中最基礎、最重要、最容易被忽視的環節

作者丨趙成

今天我專門來講講標準化這個工作。可以說這項工作是運維過程中最基礎、最重要的，但也是最容易被忽視的一個環節。

我做過多次公開演講，每次講到這個環節，通常會有單獨的一頁 PPT，就放四個字，字型大小加大加粗，重複三遍，這四個字就是「標準先行」，然後演講過程中會大聲說出「標準先行，標準先行，標準先行」，重要的事情說三遍，目的就是想反覆強調這件事情的重要程度，一定不要忽視。

我們運維工作的開展常常不知從何下手，或者上來就沖著工具和自動化去了，卻始終不得章法，工具做了一堆，效率卻並沒有提升。其實絕大多數情況下，問題和原因就是標準化這個基礎工作沒做紮實。

首先，讓我們來看看為什麼標準化這個事情如此重要。

為什麼要做標準化？

標準化的過程實際上就是對運維對象的識別和建模過程。形成統一的對象模型後，各方在統一的認識下展開有效協作，然後針對不同的運維對象，再抽取出它們所對應的運維場景，接下來才是運維場景的自動化實現。

這有點像我們學的面向對象編程的思想，其實我們就是需要遵循這樣一個思路，我們面對的就是一個個實體和邏輯運維對象。

在標準化的過程中，先識別出各個運維對象，然後我們日常做的所有運維工作，都應該是針對這些對象的運維。如果運維操作脫離了對象，那就沒有任何意義。同樣，沒有理清楚對象，運維自然不得章法。

比如我們說擴容，那就要先確定這裡到底是伺服器的擴容，還是應用的擴容，還是其它對象的擴容。你會發現，對象不同，擴容這個場景所實施的動作是完全不一樣的。如果把伺服器的擴容套用到應用的擴容上去，必然會導致流程錯亂。同時對於對象理解上的不一致，也會徒增無謂的溝通成本，造成效率低下。自然地，這種情況下的運維自動化不但不能提升效率，還會越自動越混亂。

這就是為什麼我每次都會連續強調三遍「標準先行」的原因。雖然這個事情比較枯燥和繁瑣，但是於紛繁複雜中抽象出標準規範的東西，是我們後續一系列自動化和穩定性保障的基礎。萬丈高樓平地起，所以請你一定不要忽略這個工作。

好，總結一下標準化的套路：

第一步，識別對象；

第二步，識別對象屬性；

第三步，識別對象關係；

第四步，識別對象場景。

接下來我們就按照上面這個思路，一起來分析從基礎設施層面和應用層面應該識別出哪些運維對象。

基礎設施層面的標準化

基礎設施層面的運維對象應該不難識別，因為都是一個個物理存在的實體，我們可以進行如下分析。

第一步，識別實體對象，主要有伺服器、網路、IDC、機櫃、存儲、配件等。

第二步，識別對象的屬性，比如伺服器就會有 SN 序列號、IP 地址、廠商、硬體配置（如 CPU、內存、硬碟、網卡、PCIE、BIOS）、維保信息等；網路設備如交換機也會有廠商、型號、帶寬等信息。

第三步，識別對象之間的關聯關係，比如伺服器所在的機櫃，虛擬機所在的宿主機、機櫃所在 IDC 等簡單關係；複雜一點就會有核心交換機、匯聚交換機、接入交換機以及機櫃和伺服器之間的級聯關係等，這些相對複雜一些，也就是我們常說的網路拓撲關係。

把以上信息梳理清楚，通過 ER 建模工具進行數據建模，再將以上的信息固化到 DB 中，一個資源層面的信息管理平台就基本成型了。

以伺服器為例簡單展示一下，我們的視角就是下面這樣的：

但是，信息固化不是目的，也沒有價值，只有信息動態流轉起來才有價值。接下來我們需要做的事情，就是識別出針對運維對象所實施的日常運維操作有哪些，也就是識別出運維場景是什麼。

第四步，還是以伺服器為例，我們針對伺服器的日常操作有採購、入庫、安裝、配置、上線、下線、維修等等。另外，可能還會有可視化和查詢的場景，如拓撲關係的可視化和動態展示，交換機與伺服器之間的級聯關係、狀態（正常 or 故障）的展示等，這樣可以很直觀地關注到資源節點的狀態。

完成了這些工作，接下來才是對上述運維場景的自動化開發。所以你看，在真正執行去做工具和自動化平台之前，其實是需要先做好大量的基礎準備工作的。我要再次強調這一點，一定不能忽視。

應用層面的標準化

下面我們再一起看一個邏輯上的對象，就是我們前面經常提到的運維的核心：應用。對這個邏輯對象的建模會相對複雜一些，不過我們依然可以按照上面的套路來。

本篇節選自「趙成運維體系管理課」 付費專欄文章，請移步極客時間趙成專欄查看完整文章並歡迎你留言並與作者一起參與討論。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！