如何打造運維組織架構?

前面幾周，我們介紹了Netfix為什麼沒有運維崗位、應用運維标準化、基礎服務标準化以及從應用生命周期的角度如何進行運維建設等内容。這一周我們就來聊聊在組織架構和運維 轉型方面的話題。

Netfix給我們的啟示 專欄的第一篇我們就介紹了Netfix的雲平台組織架構，你應該可以發現，Netfix其實已經給我們提供了一個非常好的思路和方向，就是在提供基礎服務能力的同時，提供對應的自助化 運維能力。也就是說，開發人員可以在這樣一個平台上完成自己想要做的任何運維操作，而不再依賴運維的人。

我們最應該學習和借鑒的，也恰恰是我們絕大多數團隊都會忽略的，就是要做好運維和整個技術架構體系的融合，一定不要割裂兩者。同時，還要注意不僅僅是促進組織架構層面的融合，最重 要的是要促進職能協作上的融合。

應該怎麼了解呢?

我先撇開組織架構，大緻說一下我的思路。開篇詞中我提到，運維能力的展現，一定是整體技術架構能力的展現。是以，要想做好運維就一定要跳出運維這個框框，從全局的角度來看 運維，要考慮如何打造和展現出整個技術架構的運維能力，而不是運維的運維能力。這一點是根本，一定要注意。如果我們仍然片面地從運維的角度看運維，片面地從運維的角度規劃運維， 是無法走出運維低價值的困局的。

從價值呈現的角度看運維

當我改變了這個認知後，我的出發點就回歸到了效率、穩定和成本這三個對于研發團隊來說最重要的目标上來。從運維的角度來說，能夠與這三個點契合的事情，我總結了以下五個。

1. 運維基礎平台體系建設

這塊主要包括我們前面提到的标準化體系以及CMDB、應用配置管理、DNS域名管理、資源管理等偏向運維自身體系的建設。這一部分是運維的基礎和核心，我們前面講到的标準化以 及應用體系建設都屬于這個範疇。

2. 分布式中間件的服務化建設

在整個技術架構體系中，分布式中間件基礎服務這一塊起到了支撐作用。這一部分的标準化和服務化非常關鍵，特别是基于開源産品的二次開發或自研的中間件産品，更需要有對應的标準化和服務化建設。這也是我們無意識地割裂運維與技術架構行為的最典型部分，這裡容易出現的問題，我們前面講過，你可以回去再複習一下。

3. 持續傳遞體系建設

持續傳遞體系是拉通運維和業務開發的關鍵紐帶，是提升整個研發團隊效率的關鍵部分。這個部分是整個軟體或應用的生命周期的管理體系，包括從應用建立、研發階段的持續內建，上線 階段的持續部署釋出，再到線上運作階段的各類資源服務擴容縮容等。開發和運維的沖突往往比較容易在這個過程中爆發出來，但是這個體系建設依賴上面兩部分的基礎，是以要整 體去看。

4. 穩定性體系建設

軟體系統線上的穩定性保障，包括如何快速發現線上問題、如何快速定位問題、如何快速從故障中恢複業務、如何有效評估系統容量等等。這裡面還會有一些運作機制的建設，比如 如何對故障應急響應、如何對故障進行有效管理、如何對故障複盤、如何加強日常演練等等。同樣，這個環節的事情也要依賴前兩個基礎體系的建設。

5. 技術營運體系建設

技術營運體系也是偏運作機制方面的建設，最主要的事情就是確定我們制定的标準、名額、規則和流程能夠有效落地。這裡面有些可以通過技術平台來實作，有些就需要管理流程，有些還需要執行人的溝通協作這些軟技能。

最終通過這樣一個規劃，我把團隊以虛拟形式重新規劃了不同職責，分别負責基礎平台體系、分布式中間件服務化體系、持續傳遞體系和穩定性體系，基本就是上述的前四件事情。

對于最後一個技術營運體系，這一點作為共性要求提出。我要求團隊每個成員都要具備技術營運意識。具體來說，就是要能夠有制定輸出标準的意識和能力，能夠有規範流程制定的能力，同時能夠将标準和流程固化到工具平台中，最後能夠確定承載了标準和規範的平台落地，也就是平台必須可用，确實能給運維團隊或開發團隊帶來效率和穩定性方面的提升。

這些對個人的要求還是比較高的，要有一定的規劃、設計和落地能力，能具備一整套能力的人還是少數，目前這塊還是靠團隊協作來執行。

運維協作模式的改變 上面的這幾件事情，并不是由運維團隊内部封閉來做。還是我們反複強調的那個思路，要站在怎麼能夠打造和發揮出整個技術架構體系運維能力的視角，而不僅僅是發揮運維團隊的運維能 力。是以這些事情的執行可以了解為是由運維團隊發起，與周邊技術團隊協作配合來完成的。

是以這些事情都需要跨團隊協作。一方面運維團隊要主動出擊，去溝通，去推進;另一方面，必須能得到上級主管甚至是更高層技術上司的支援，是以這裡要求技術管理者必須要有這 個意識，促進這樣的組織協作方式變革，如果技術管理者意識不到或者支援不到位的話，運維在後續的推進工作中将會遇到非常大的阻力。

下面來分享下我們目前正在嘗試的一些調整。

我們運維所在的平台技術部門，包括了分布式中間件、虛拟化技術、穩定性工具平台以及大資料幾個子部門。當我們發起并推進上述工作時，就需要與這些團隊聯合協作，朝着某個目标共同執行。下面我們來看看細分的情況。

1. 運維基礎平台建設

這塊大多數的工作會由運維來完成，因為這是運維的基礎，也屬于整個技術架構比較關鍵的基礎平台之一，這一點我們在講應用和叢集服務管理時已經介紹過。

2. 分布式中間件服務化建設

這個部分我們就需要分布式中間件團隊的配合。我們可以一起制定各種使用标準、規範和流程;中間件團隊負責提供運維服務能力的接口;運維團隊根據使用者使用的場景進行場景化需求分析，并最終實作場景，同時負責标準和自助化工具平台的推廣和落地。

3. 持續傳遞體系建設

這一部分也會涉及多個團隊的協作。在資源使用上，我們前期會用到KVM，那麼如何快速傳遞KVM資源，就需要與虛拟化技術團隊協作。現在我們在嘗試容器方案，涉及到鏡像制 作、網絡配置以及對象存儲這些底層技術，一樣會與虛拟化團隊配合，在資源傳遞效率和使用率上都有很大提升。同時，還會與中間件團隊協作，因為在應用釋出和擴容縮容過程 中，就會涉及服務上下線，這就要與服務化架構配合，服務化架構提供底層運維服務能力，而運維要做的就是通過中間件運維能力的封裝整合，進而實作使用者使用的場景化需求。

4. 穩定性體系建設

這裡會涉及一些鍊路埋點、限流降級、以及開關預案等一些技術方案需求，通常會有這樣一個專門的穩定性工具團隊，對外輸出一些穩定性保障能力，比如一些穩定性通用SDK的開 發，背景日志采集分析以及資料計算等等，這些事情會對技術能力的要求比較高，需要具備較強開發能力的人來做。是以，運維在這裡發揮的作用一個是上述提到的場景化實作能 力，再一個就是穩定性能力的落地，或者說是營運能力。

穩定性工具提供的多是能力和支援，最終要在業務層面真正執行，就需要運維和業務開發共同來執行。比如一個應用上線， 是否具備關鍵接口的限流降級能力，是否具備熔斷能力，是否滿足上線的性能及容量要求，這個工作是需要運維深入每個業務，根據不同的業務場景和實作情況，一個個具體落地才 行。是以，整體上對運維技術營運能力的要求就會非常高。

運維在這個過程中要發揮的最關鍵作用就是通過使用者使用場景的分析，将各項基礎服務封裝并友好地提供出來，并確定最終的落地。方式上，或者是通過工具平台的技術方式，比如分布式中 間件基礎服務;或者是通過技術營運能力，比如穩定性能力在業務層面的落地。

運維在這個過程中，就好像串起一串珍珠的繩子，将整個平台技術的不同部門，甚至是開發團隊給串聯起來，朝着發揮出整體技術架構運維能力的方向演進。

運維的組織架構

上面是我們從團隊需求和運維價值呈現層面成立的虛拟組織，從實際的人員管理以及技能次元來劃分的話，我們和其它網際網路公司的運維團隊差别不大，基本會分為如下幾個崗位:基礎運維，包括IDC運維、硬體運維、系統運維以及網絡運維; 應用運維，主要是業務和基礎服務層面的穩定性保障和容量規劃等工作; 資料運維，包括資料庫、緩存以及大資料的運維; 運維開發，主要是提供效率和穩定性層面的工具開發。

這個實體的組織架構，相當于是從技能層面的垂直劃分。基礎運維更擅長硬體和作業系統層面的運維;應用運維可能更擅長業務穩定性保障、疑難問題攻關以及技術營運等;資料運 維就不用多說了，DBA本身就是專業性極高的一個崗位;運維開發則是支援上述幾個崗位日常運維需求的，是否能将人力投入轉換成工具平台支援，就看這個團隊的能力。

而前面所說的從價值呈現層面進行的虛拟團隊劃分，則是将上述幾個實體團隊技能上的橫向拉通，讓他們重新組織，形成技能上的互補，進而發揮出更大的團隊能力。 實體組織架構，相當于一個人的骨骼架構，但是價值呈現層面的虛拟組織，就更像是一個人的靈魂，展現着這個人的精神面貌和獨特價值。 這個過程中，必然會對運維的技能模型有更新、更高的要求。

總結

今天我為你介紹了我們正在實踐的一些運維組織架構方面的内容。後來當我翻閱《SRE:Google運維解密》這本書時，發現如果按照書中的章節目錄進行分類的話，基本上都可以與 前面我介紹的部分對應起來，這也更加堅定了我們要按照這套組織模式運作下去的信心。

同時，我們也要明白，業界沒有一勞永逸的組織架構，也沒有放之四海而皆準的組織架構标準，更沒有萬能的可以解決任何問題的組織架構設計，這裡的關鍵是我們如何能夠發揮出團隊整體的 能力和價值，而這一點又需要我們不斷地與自己所在團隊和業務特點去比對和契合，這是一個不斷變化的過程，也是需要持續調整的過程。