如何打造好運維組織架構？

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

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

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

應該怎么理解呢？

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

從價值呈現的角度看運維

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

運維基礎平臺體系建設

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

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

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

持續交付體系建設

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

穩定性體系建設

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

技術運營體系建設

技術運營體系也是偏運作機制方面的建設，最主要的事情就是確保我們制定的標準、指標、規則和流程能夠有效落地。這里面有些可以通過技術平臺來實現，有些就需要管理流程，有些還需要執行人的溝通協作這些軟技能。
最終通過這樣一個規劃，我把團隊以虛擬形式重新規劃了不同職責，分別負責基礎平臺體系、分布式中間件服務化體系、持續交付體系和穩定性體系，基本就是上述的前四件事情。

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

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

運維協作模式的改變

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

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

下面來分享下我們目前正在嘗試的一些調整。
我們運維所在的平臺技術部門，包括了分布式中間件、虛擬化技術、穩定性工具平臺以及大數據幾個子部門。當我們發起并推進上述工作時，就需要與這些團隊聯合協作，朝著某個目標共同執行。下面我們來看看細分的情況。

運維基礎平臺建設

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

分布式中間件服務化建設

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

持續交付體系建設

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

穩定性體系建設

這里會涉及一些鏈路埋點、限流降級、以及開關預案等一些技術方案需求，通常會有這樣一個專門的穩定性工具團隊，對外輸出一些穩定性保障能力，比如一些穩定性通用SDK的開發，后臺日志采集分析以及數據計算等等，這些事情會對技術能力的要求比較高，需要具備較強開發能力的人來做。所以，運維在這里發揮的作用一個是上述提到的場景化實現能力，再一個就是穩定性能力的落地，或者說是運營能力。穩定性工具提供的多是能力和支持，最終要在業務層面真正執行，就需要運維和業務開發共同來執行。比如一個應用上線，是否具備關鍵接口的限流降級能力，是否具備熔斷能力，是否滿足上線的性能及容量要求，這個工作是需要運維深入每個業務，根據不同的業務場景和實現情況，一個個具體落地才行。所以，整體上對運維技術運營能力的要求就會非常高。

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

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

運維的組織架構

上面是我們從團隊需求和運維價值呈現層面成立的虛擬組織，從實際的人員管理以及技能維度來劃分的話，我們和其它互聯網公司的運維團隊差別不大，基本會分為如下幾個崗位：

基礎運維，包括IDC運維、硬件運維、系統運維以及網絡運維；
應用運維，主要是業務和基礎服務層面的穩定性保障和容量規劃等工作；
數據運維，包括數據庫、緩存以及大數據的運維；
運維開發，主要是提供效率和穩定性層面的工具開發。

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

而前面所說的從價值呈現層面進行的虛擬團隊劃分，則是將上述幾個實體團隊技能上的橫向拉通，讓他們重新組織，形成技能上的互補，從而發揮出更大的團隊能力。

實體組織架構，相當于一個人的骨骼框架，但是價值呈現層面的虛擬組織，就更像是一個人的靈魂，體現著這個人的精神面貌和獨特價值。

這個過程中，必然會對運維的技能模型有更新、更高的要求。

總結

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

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

所以這對技術管理者要求會比較高，應該如何不斷地去匹配和契合這個最佳價值點，同時如何統籌調度好團隊中不同類型的技術資源并形成合力，是非常重要的。

你的團隊在實際過程中遇到過哪些問題，你有怎樣的經驗和觀點，歡迎你留言與我一起討論。

運維體現的應該是整體技術架構的運維能力，而不是運維的運維能力。視角不轉變，就走不出運維困局。

后面幾篇文章，談談我對運維組織架構和能力建設的思考，實踐和建議。

精選提問

感覺運維工作對軟件開發的跨界能力要求較高，既要懂得基礎的應用模型，又要了解應用間的服務架構模型，同時還要掌握架構內的數據模型，對于大規模的服務器管理同時還需要設計規劃網絡模型，每一項都不僅僅是了解就可以勝任的，想要做好運維工作，想走捷徑是不容易的。

應該說沒有任何捷徑可以走。

我是一個公司快速發展，從運維打雜王立刻成為了運維團隊管理者， 人員也在擴張，自身從外部學習培訓，也在踐行運維工具化 Web化。自己開發了運維發布平臺 運維服務平臺 對照老師所講還是在解決運維的運維能力。再cto眼里感覺還是很混亂 工具零散 沒有形成體系 沒有形成項目。我大概也能理解cto希望的是老師所講的站在全局的角度去規劃 。 但在全局 我好像只是知道要cmdb 要持續發布要穩定性 似乎還是一層表面 真正落地實施計劃 有點內力不足。

你要考慮，是誰的cmdb ？誰的持續發布？誰的穩定性？找到這個主體，也就串起來了。
我前面的文章都涉及過這些內容，你可以再看看。

我們運維團隊主管，就是面向領導運維，領導說有問題，那就大力配合，而且一定會出成果。領導不提問題，不改進任何問題。出現問題，反正在領導那里能甩鍋。在這種環境下，實現不到老師講的知識？。我該怎么做？

體制上的問題只能體制上改進，這個是根本。
所以如果你覺的成長有限，或者受限太嚴重，可以做出其它選擇了。

總結

以上是生活随笔為你收集整理的如何打造好运维组织架构？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。