李佐輝
DBAplus社羣（dbaplus)
讀完需要
20
分鐘速讀僅需 5 分鐘
本文根據李佐輝老師在〖deeplus直播第221期〗線上分享演講內容整理而成。（文末有獲取本期PPT&回放的途徑，不要錯過）
李佐輝
浙江移動網管中心SRE首席架構師
浙江移動SRE團隊發起人、高級工程師，通信網絡工程師IT開發轉型推動者。
畢業於浙江大學信電系，12年通信網絡運維經驗，深入理解通信網絡IT需求。
一、背景：我們是網絡運維工程師
我們維護的設備：廠家定製，專有軟硬件的通信設備。
我們眼中的世界：路由、協議、網元、信令、局數據…
我們日常工作內容主要涉及以下三個方面：
但是，我們的人員素質較高，100%的工科背景，都具備基礎的編程技能，大部分人對運維開發轉型充滿興趣。
二、我們遇到了點小麻煩
隨着通信技術的發展，網絡運維的壓力和責任越來越大。
與知名互聯網公司對比，我們維手段較原始，大量工作處於人肉運維階段；對標先進互聯網公司，我們還有很長的路要走。
國企的人力成本存在紅線，人力資源不足。即運維的設備越來越多，但是人不見多。2014到2019年，語音核心網元增加了80%，但是運維人員僅增加12%。
雖然支撐系統平臺手段衆多，但日常維護中仍存在大量的手工冗餘操作。支撐平臺開發週期長、開放性差，是兩個較大的問題。
網絡設備正在向IT雲化演進，網絡運維人亟需轉變傳統思維，向IT化思維靠攏。
複雜的雲化架構有時發生故障根本無從查起，詭異的故障無法用科學解釋。
無法用科學解釋的時候，迷信就出現了。
三、浙江移動的SRE轉型之路
1、轉變思想
在轉型過程中，我們吸收了谷歌的SRE運維思想。SRE是Google對DevOps的實踐總結。
SRE的終極目標：保證業務連續性。
SRE把運維問題變成了軟件工程問題：
50%~60%軟件工程師；
其他具備85%~99%軟件技能，且具備一定程度其他IT技能的工程師。
SRE模型的優勢：
運維人數相對少；
開發團隊和運維團隊的衝突焦點消除；
SRE團隊和研發團隊之間的成員可以自由流動。
•SRE模型的問題：符合SRE的人才難招聘
SRE與DevOps的關係：SRE理念是DevOps的具體表現形式。DevOps和SRE是道，DevOps工具是術。
SRE做的是運維自動化，但自動化不是目的。
自動化有3種形式：
外部自動化：即通過外部的工具和腳本，實現運維自動化功能。
內部自動化：即將開發的腳本和工具部署在系統內部，實現自動化
服務強化：在系統設計和開發階段就考慮到運維手段，將運維自動化體系原生嵌入到系統中。
目前我們主要做外部自動化，冰箱內部自動化和服務強化邁進。
自動化後帶來的好處：
高度的一致性：無論新手還是專家，作出的判斷和操作完全一致
問題快速反應：發生故障快速反應
完成任務省時：完成報表取數、優化分析等任務省時省力
固化經驗：將運維人員的經驗和教訓固化到代碼中流傳下去
2、確立目標
SRE團隊的目標：提倡主動運維思維，以運維開發爲手段，依託SRE運維模式，提升運維人員ICT技能, 支撐各專業高效運維。
但是隻有當團隊目標與個人目標相一致時，團隊纔是可持續發展的。
讓我們來看看SRE運維開發轉型如何實現運維工程師們的個人目標：
3、建立良好的生態圈
1）建立組織架構
建立議事會負責制的半剛性組織架構制度：
議事會：負責組織架構設計、管理模式探索、人員IT轉型等。
技術支持團隊：負責技術演進、技術支持、人員技能培養、開發平臺搭建和維護等。
工作小組：聚焦應用開發、服務開發和平臺開放性探索。
2）建立OKR導向的正向激勵制度
除了行政架構的激勵外，還存在橫向的SRE OKR激勵。
3）探索人員分工
人員角色介紹：
Enbedded SRE：嵌入式SRE，活躍於運維團隊中，主要實現自身的自動化需求，有日常負責運維的設備，需要參與on-call值班。我們大部分成員均屬於此種類型。
Platform SRE：平臺開發型的SRE，主要對平臺負責，開發新平臺或對存量平臺進行開放性改造，以使其它SRE成員可以方便的在其上開發。無日常運維設備或on-call值班的要求。
Consulting SRE：顧問型SRE，技能較高的成員，平時負責爲SRE其它成員答疑解惑，解決問題，或是參與到其它成員的具體項目中進行開發指導或牽頭開發，項目進入正軌後即退出項目組。平時無運維設備或on-call值班的要求。
4）專注人員培養
技能培養：依託IT和CT能力培養體系，針對SRE人員、存量運維人員、新員工、協維人員制定不同的人員培養體系。
人員成長後評估：從5個方面，21個評分項對人員進行畫像，完成人員的培養後評估。
5）完善日常工作框架
建立SRE日常工作框架，確定技術規範，避免技術債務。
6）搭建開發支撐平臺
通過建平臺、解耦合兩部分工作來搭建SRE的開發支撐環境。
服務原子化，新增開發區，積木式開發，提升效率，降低開發難度。
平臺開放化，依託平臺進行功能增強，不需考慮底層和前端，大大降低難度。
四、階段工作成果
團隊經過2年多的建設已經初具成果，共培養SRE團隊成員97人，完成開發需求200餘個，具有如下的優勢：
需求實現快：基於開放解耦的平臺進行搭積木式二次開發，單個功能點開發平均僅需2個小時，需求到上線時間縮短551倍。
痛點切入準：運維專家轉型開發人員，網絡痛點了然於心。
人力大解放：機器換人，大量運維工作自動化，值班人員減少70%。
壓力大釋放：逐步接受與信任系統，具體的運維工作逐步轉交給自動化系統完成，釋放運維人員壓力。
>>>>
Q&A
Q1：請問如何說服領導組成sre團隊的？畢竟是垂直管理的企業。
A：轉型肯定是自上而下的，自下而上那叫革命，如果得不到領導的支持，那麼轉型肯定不會成功。隨着通信網絡技術的演進，語音、短信這類傳統業務的收入大幅下降，後續的技術和人員架構會怎麼樣，我們之前也是迷茫的，不知道路在何方，但是通信網絡IT化這個趨勢是明確的，這個就需要我們去轉型。
對於如何進行轉型，領導層面的考慮肯定比我們多，而且更深入。這時我們瞭解到了Google的SRE理念，覺得很符合我們的訴求，就跟領導一拍即合，把這個作爲我們轉型的方向了。
Q2：請問貴公司的自動運維是自研的嗎？用了哪些開源的技術或產品呢？
A：公司層面我不太好回答，但是在我們部門，大部分是的。我們使用了很多的開源技術和產品，比如Hadoop、Flink、Zabbix、Ansible、Jenkins等等。不過雖然使用了那麼多開源的軟件，但是我們還是非常注意開源軟件的引入安全的。
Q3：如何讓外購系統廠家幫忙解耦他們的系統？
A：之前外購系統都是一個一個獨立的煙囪，我們有新的需求提給廠家實現都很慢，廠家不懂業務，我們不懂開發，需求溝通存在較大的成本，而且開發出來的功能往往與我們需要的相差甚大。這種情況下我們與廠家存在比較大的矛盾，我們說他們開發慢，難溝通，開發出來的東西不好用；他們說我們需求奇怪，需求變更太頻繁，對完成時間點要求太高。
如果外購系統解耦之後呢，系統廠家只需要維護他們系統框架和開放出來的接口，一些業務功能由我們自己來開發實現，搭在他們的平臺上，這樣需求實現快，功能上可以完全滿足我們的需求，而我們又省去了平臺維護的工作，對平臺廠家來說又不會受到頻繁的需求變更單，也不需要去深入的瞭解我們的業務需求，對兩方來說都省事多了，完全是雙贏的局面。
我們把以上這些有利之處跟廠家說清楚，廠家都是比較願意接受的，後面我們就把需要開放解耦的地方敲定，作爲需求提給他們就可以了。
Q4：SRE日常工作裏面，提到的需求歸口管理，是指業務需求？
A：是的，對於我們來說，運維需要的功能就是我們的業務需求。
Q5：此外開發的開發規範，是約定到所有業務系統開發廠家的代碼開發規範，一套標準麼？還有API調用規範等，如何進行約束？因爲涉及廠家非常多，管控難度非常大。
A：開發規範是針對我們SRE的，並不是針對業務系統開發廠家的。這是爲了規範代碼格式和代碼行爲，形成良好的代碼風格，便於運維經驗固話在代碼中後的回溯。因爲都是基於SRE團隊的，也不存在廠家多管控難度大的問題了。
獲取本期PPT
請添加菲菲VX：dbafeifei
推薦閱讀
DevOps是微服務的祕方
DevOps落地成不成，關鍵不在持續集成？
阿里高工流生 | 雲原生時代的 DevOps 之道
新炬首架樑銘圖：從70萬字SRE神作提煉出7千字精華與君共勉
回看本期直播，請點擊閱讀原文↓