運維前線：一線運維專家的運維方法、技巧與實踐1.8 運維自動化依賴的團隊模型

<b>1.8　運維自動化依賴的團隊模型</b>

<b></b>

下面将從能力模型、驅動模型和技能模型三個角度來闡述運維團隊和個人的能力要求，最後給出一個參考的組織結構。

1.8.1　團隊的能力模型

具體的團隊能力模型示意圖如圖1-15所示。

圖1-15　團隊能力模型

對于我帶過的應用運維團隊，我都會從如上三個方面對組員提出運維能力要求。

1）業務運維。因為對這塊能力的要求越來越低，是以其在我們的考核體系中所占的比重也越來越低。日常的變更、擴容、故障定位、運維規劃對人的能力要求都非常低，這些工作都能模式化且平台化，進而減少了對人的倚重。

2）運維研發。我希望每一個應用運維人員都有運維研發的能力，但這在現實中是不可能的。對于應用運維團隊和運維部門來說，運維研發的配備必不可少。在應用運維團隊的内部，可以讓有研發能力的人迅速承擔面向業務運維平台的建設，或者參與到部門的運維系統建設中，可以抽出50%的時間參與研發。運維研發能力是能夠讓團隊價值迅速達成的有效保證，沒有研發能力的運維不能成為一個好運維。

3）技術研究。運維是一個技術團隊，需要通過技術來展現價值，當找到好的技術時就要想着如何将技術應用到業務上，為使用者帶來價值，比如說提升使用者體驗，減少成本等。

這個時候就會産生一個問題，應用運維團隊内的人也會運維研發，同時又有專職的運維研發團隊，那麼他們的職責分工如何解決，在工作上是否會存在重複建設？我的回答是這樣的：

首先，可以把運維研發初期定位在公共服務平台的研發上，比如說dns、lvs、配置管理、監控系統、cmdb、資料分析平台等。

其次，運維研發還需要制定相應的運維研發規範，代碼規範、ui規範、測試規範等，讓所有參與運維研發的人統一遵守，包括應用運維研發的組員。

最後來說一下應用運維小組内的研發能力該如何發揮的問題。其實在很多運維團隊中，運維都是跟随業務的，一則可以讓應用運維研發人員開發面向業務的運維系統，因為他們最了解該業務的需求，能夠實作自己想要的；另外一種更好的操作方式，是讓應用運維小組内的研發人員抽出50%的時間參與到以運維研發牽頭成立的虛拟研發小組中。一則可以進一步提高應用運維的研發水準；另外還可以提高運維研發對業務運維的了解，同時還能提高帶隊作戰的能力。

那麼，運維研發和應用運維的比例應該設定成多少比較合适？我個人認為3:1比較合适，大家也可以自檢一下，自己的運維團隊到底設定了多少運維研發人員？另外想要檢測運維研發配備是否足夠，可以周期性地看看運維團隊取得的進步，特别是效率和品質等次元。

一個高性能的運維團隊一定是以應用運維和運維研發為核心建構的！

1.8.2　團隊的驅動模型

具體的團隊驅動模型如圖1-16所示。

圖1-16　團隊驅動模型

團隊的驅動力不同，帶來結果的就會完全不同。為什麼很多運維人員都說自己很辛苦？這時你可以思考一下到底是什麼在引導着你進行運維工作？傳統的維護，往往都集中在第一階段和第二階段，而進入到高階運維體系之後，我們需要迅速切換到價值驅動和使用者驅動的次元上來。有了使用者驅動和價值驅動，對運維的效率和品質就都會有更高的要求，對于外部驅動我們必須走自動化和平台這條道路。建議大家在平時的工作中加入品質、效率、成本等一些kpi要求，不要隻局限于自己所做的事情，而是要關注自己所做的事情對産品和使用者的影響。

1.8.3　團隊的技能模型

bat（百度、阿裡、騰訊）很早就實施了職業通道體系，在運維側細分了多個能力通道，比如說網絡運維、業務運維、運維研發、dba等。對于運維人員的成長也有明确的要求和衡量體系，在此我就不詳細介紹了。

1.8.4　參考的運維團隊組織結構

我們不一定要按照這個結構明确設定運維小組，但是運維的職能差不多就是這樣。我還有另外一個建議，最好将公共服務研發團隊和運維團隊放在一個組織結構下，這樣将會有利于公共化服務的推廣，而公共化服務對運維效率的影響是最大的，如圖1-17所示。

圖1-17　運維團隊組織結構

至此，自動化平台的深度解碼已經完成。本章從多個層面帶領大家了解運維自動化，其實還是希望能給大家帶來一點借鑒意義。大膽地往前走吧，一切都有可能，唯獨那些實作不了的，都是我們人的問題，無它。