《騰訊SNG梁定安：顯微鏡下的運維自動化》要點：
本文介紹了騰訊SNG梁定安：顯微鏡下的運維自動化，希望對您有用。如果有疑問，可以聯系我們。

本文來自騰訊社交多媒體業務負責人@梁定安(大梁)在APMCon2016·聽云的同名主題演講,解讀了在億級在線用戶和十萬級服務器的海量運維壓力挑戰下,如何把繁雜的運維工作變成自動化.

今天我跟大家交流的是實實在在的怎么樣做運維自動化這個主題.

可能之前大家也聽過我介紹織云平臺怎么做,我最近想一個事情,像騰訊這種體量(QQ月活量是8.3億,8.3億的DAU)及海量運維壓力下,構建出的自動化運維平臺如果真的放在一些中小企業,是沒有太多的用武之地.

那么怎么辦?

我一直在想怎么樣能夠讓大家沒白來這次的分享,所以我特意把我之前對整個運維自動化分享的內容重新提煉總結,通俗點的說就是更接地氣,我節選了我們這么多年做運維自動化里面最重要的一些功能模塊.

所以今天不會給大家介紹一個很龐大的系統,我會專門去講自動化里最核心的環節(CMDB分層、技術架構及后續落地辦法等等),說不定大家做了這些核心環節,就能提升到很高效的水平.

一、運維自動化的能與不能

今天的分享主要有三部分,前兩部分會重點跟大家講一下,我們做運維自動化之前,應該具備什么樣的理念.無論是運維還是開發這兩個角色,其實都需要去遵循這樣一些俗稱的標準化,我們的規范是什么?基于這樣的一些規范,我們怎么把我們的自動化落地.

自動化不是萬能的,并不是所有的場景都適用.運維自動化也是一樣,在騰訊體量很小的時候,我們就一直琢磨著要怎么樣高效運維.

因為騰訊的社交產品是樹狀結構,小的一些應用特別多.只有核心的幾個像QQ相冊、QQ空間、QQ音樂體量特別大,其他都是很碎片的小應用,如果這些小應用雜亂無章的生長,怎么規范化它?在它發展的時候我們的運維效率又能跟上.

去年6月份,騰訊整個集團的物理機剛剛突破50萬,我們運維團隊的人增幅遠沒有服務器增長的快.

我們先來看一下自動化想解決什么樣的問題?

上面這些挺有意思的話節選于我們團隊內部：比如文檔即過期,我們做運維的,老板整天希望我們寫一些所謂的運維文檔,這個文檔寫出來的時候其實就意味著它已經過期了.

還有一些資深同事離職,經驗也就消失了,這些都希望在自動化里解決.還有邏輯的解耦、微服務,寫死IP,或者有必要的切換等,這些肯定是在做運維自動化的時候不希望去觸的雷區,還包括包括人為同時的失誤、架構的失控等等.

我們怎么樣提出標準化規范?讓我們的研發團隊、運維團隊更高效合作,避免出現誤區?

做自動化不是為了炫酷,不能為了自動化而自動化,20%的工作消耗了我們80%的精力,我們只要集中精力把那20%的工作做好基本上就可以達到很好的狀態了,就可以釋放精力去做大數據、做智能化運維,而不是說什么場景都要追求到完完全全的極致.

我們團隊內部,大家都會經常說一句話,任何事情做到80分,我們投入半年就夠了.但是要把另外20分做完,可能要投入的時間遠大于那80分,所以這時候,我也是希望大家在回去規劃自己的運維自動化場景的時候,能夠著重思考這一點,哪個優先去做.

我們給我們的運維自動化下了一個定義,做任何事情之前,首先清楚我們的目標：在大規模運維場景下,將重復度高的工作,基于監控數據智能決策觸發,實現無人參與的自動操作的運維能力,稱之為運維自動化.

這里很重要的是無人參與,目前我們的平臺是可以做到無人職守擴和縮,今天就跟大家介紹怎么實現的.

再次回到業務場景,在騰訊的社交業務場景下,海量、敏捷、復雜高可用上面都有一些具體的描述,這也是在中國這么大的用戶群體下所有社交產品的一個普遍表現形態.

二、DEV與OPS：求同存異

在這樣一個海量的業務壓力下,我們怎么樣跟我們的開發人員、運維人員去共同定制我們能夠落地實現的標準化運維方案?

在2008年、2009年的時候,我們當時提D/O分離,但我一直覺得D/O分離有點自己坑自己的味道,你開發好程序給我你就不用干了,我含著淚都要把這個干好.

一個架構很差的程序,我們沒有辦法把它維護得很高效.

在騰訊社交這個產品線,我們現在功能模塊有5000多個,底下對應的微服務得上好幾萬個,這種情況是沒有辦法維護一些架構很差程序代碼的.

在當時2010年的時候,DevOps的概念還沒有提出,我們已經意識到這個問題,所以當時就已經開發了織云這個平臺,當它真正的跟DevOps這個理念對齊的時候是不謀而合的.

只有合作才能走得更快,才能在激烈的互聯網紅海競爭下取得勝利,怎么去做?

我們把開發和運維有可能打交道的地方分成四大塊：首先是架構.

運維很關注架構,不然沒辦法評估它的質量好壞跟架構有沒有直接的關系.運維希望開發遵守我們的規范.

之前我跟一些傳統行業的同行也有過交流,他們寫了很多規范開發不能做,這些都是流于形式,沒有辦法實實在在的去要求.

為此,我們帶著這樣的問題,一起來看一下騰訊是怎么實踐的.

我們推崇的統一架構、運維規范,怎么作用到開發人員的身上?然后基于這樣的統一的規范,如何能夠去打造運維的工具系統,讓它實現自動化?

基本上所有的互聯網業務架構,我們都是可以用上圖來簡單概括,分為客戶端,用戶用的終端、PC,中間是運營商,然后三層架構：接入層、邏輯層、數據層.

騰訊整個社交,大概是分成這個樣子,針對同樣的架構,我們就開始提出管理理念：框架化、組件化、無狀態、分布式.

我們的框架化是怎么落地的?

在騰訊社交這邊,我們的業務開發整個技術棧,基本上都是用C為我們的主要開發語言,不是用Java,所以說沒有辦法基于Java無痛注入的方案做APM,我們必須對開發的技術習慣設計更適合我們的框架.

為此,我們針對Socket通信把CS架構的服務端,按照公共的功能專門用來通訊、收發包,些能力變成一個框架.業務開發只需要專注寫它的業務邏輯,實現我們的框架.

在騰訊基本上我們有支持同步的開發框架、支持異步的開發框架,還有Web服務的一些應用,都是有通用的框架來支持的.

再講就是組件化,這里也有一個實例.假設我們現在要上一個網站,必須要有一個Web Server,不同的開發團隊會有不同的選擇,有人說Apache性能好,有人說NGINX比Apache強,有人說我用IIS,有人說那三個都是垃圾,我自己寫的是最好的.

很不幸,這個事情如果在2009年之前在騰訊確實是這樣子的,百花齊放,這就導致我們沒有辦法維護.對運維來說,100個不同的Web Server我就要選擇100次.

為什么我們不能要求一致?我們站在組件化的高度及要求下,同一種應用場景只能選一個,這次才能針對這種組件化去做到極致.

說完我們的一些框架化、組件化的舉例,通過提出了這樣一些要求,我們運維團隊讓我們每一個業務開發,開發出來的架構都基本上長成上面的樣子了.還有一些組件TGW、L5這些東西沒有介紹到,大家可以在搜索引擎上查到之前的分享.

今天我特別希望把這個理念跟大家完整闡述一遍.當我們的業務架構的層級都長成這個樣子的時候,我們無論是對它做自動化運維也好,做監控也好,都很方便.

剛剛上一個老師提到一點我覺得很有啟發,一款應用我們應該怎么樣去度量它?指標是怎么樣子的?

騰訊內部是直播年.騰訊自己也在做直播,我們社交的直播光是APP估計兩個數手不完,各種開發團隊都在做直播,不同的直播怎么度量?

所以這時候,運維團隊就占了很重要的決定性的作用.我出來說直播的質量、體系就應該這么看,我就給你定好了這種指標.

我覺得有很多事情,不是說技術好或不好,而是看誰來做更合適.這時候運維作為一個公共的支撐的團隊,它更有這種權利或者說它更應該去規范這樣的東西,讓我們對同質的業務場景可度量.

前面兩個部分,把我們的理念講完了.我們要怎么樣去落地?細節是什么樣子的?下面有一個全局的圖.

在我們社交運維團隊,我們主要的運維產品有四大塊：一個是織云,主要負責運維自動化方向,還有一個天網,還有我們的報表體系,專門用來做我們可度量的.最后還有一個手機運維MSNG,這里面包含了很多子的系統,今天主要是講織云里面的一小部分.

三、運維自動化的技術細節

今天著重介紹織云,并且是織云最核心的功能點.有了標準化以后要做很多事情,才可以很輕松的實現運維工作的自動化.

光是在運維自動化里面,大家都說標準化、運維規范,那究竟是什么?今天特別想跟大家一起打開這個黑匣子,看一下騰訊運維的標準化是怎樣的?

我們把業務架構又切分成不同的層,其實就是剛剛那個圖的另外一種表現形式.五層,不同的層級,我們要做的標準化針對的對象不同的.

就像我們的設備層什么是標準?統一的機型、計算型的、內存型的、SSD,你是用關系型數據庫,要用什么機型,要用大硬盤的,你是做Web Server的,內存標配一個就可以了.

特別是在虛擬化的今天,如果任由一個業務隨意去選擇它的機型,對于我們來說就是多了一種對象.在騰訊這么大的體量下我們沒有辦法容忍隨隨便便給我多增加一個運維對象.

所以我標紅了幾個字,就是要減少運維對象.像其他的業務層,你是IM型的應用,架構分布必須要三地、三活,QQ調度方案跟Q Zone的調度方案必須是一樣的.所以我們做的一切的一切都是要減少運維對象.

減少完運維對象怎么去執行?在開發前,把整個產品的生命周期分成這么幾塊,在開發前、上線前、上線中、運營中,不同階段,考慮的點不一樣.

開發前,知道業務形態長成什么樣,可能用到什么樣的組件、什么樣的框架,這個時候基本上杜絕了寫死IP的念頭,或者對本地存儲特別敏感的情況.

其實我只是寫出來,在真正運維工作中并沒有說每次上線一個產品我們都去評審,時間也耗不起.

當我們形成了這樣一個開發和運維合作的文化之后,開發團隊自己就會遵守了,并且在不同的階段,我們提出了不同的要求.每個要求都會對應了我們運維的一個工具系統,去支撐它,就是說我們的標準化可以落地了.

再來看基于我們互聯網業務的架構層分層的特征,針對不同層次的對象去建設對應維護對象的系統,這些系統所產生的數據都把它結構化落地到我們的配置管理CMDB里面,這個CMDB就在整個運維自動化的過程中扮演了一個很核心的地位.

CMDB層是什么東西?

我們開發和運維先天性就有一些思考模式的不同.我們在CMDB中提出了一個概念,就是模塊概念.為什么要有模塊這個概念?可能開發人員看到他自己寫的一套代碼,這套代碼對他來說部署在一個地方和部署在三個地方都是一套代碼.

但是對于騰訊來說,我們所有核心服務都是三地三中心,對于用戶來說,天津的用戶量跟深圳的用戶量不一樣,北方的用戶跟南方的用戶量不同,容量不同,準備的設備數量就不同,提前規劃的機房也不一樣.

這時候我們就提出了一個概念,就是模塊.這個模塊必須要按照運維的命名規則去定義它,存我們固定資產的信息,硬件配置、軟件配置、運營設置,還有資源配置、流程配置、測試用例等.

存這些東西有什么用?

如果CMDB一下子就能看到我們整個QQ的某一個功能,分布在天津、上海、深圳的容量分布圖,或者說記錄了這個模塊的測試用例.那么,我們在做自動化的時候,我把它部署完就可以自動調它的測試用例,自動測試然后上線.實現這個目的,都是為了自動化做鋪墊.

1、織云的運維思想

前面我們一直講思想講理念,前面兩個部分介紹了標準化,以及標準化怎么變成我們的配置化,變成配置化之后最后一步就是實現自動化.

實現自動化的過程,技術上看似很簡單,無非就是把一堆結構化的數據通過配置,通過一些自動化的手段或者寫批量的腳本,全部傳上機器把它還原就可以了.

現在業界比較流行Docker,Docker的口號是BUILD、SHIP、RUN(構建、傳輸、傳上生產環境執行起來),但是事實上有沒有這么理想化?

上圖是我們在騰訊每一個發布要做的事情.事實上我框起來的這些內容Docker并沒有幫我們解決的,編入業務權限怎么申請,這個可能很有騰訊特色.

大家都知道,騰訊很多業務都是生長在QQ這樣一個關系鏈體系下的,并不是所有的業務都有權限去拉QQ關系鏈的.訪問QQ關系鏈必須要經過一個授權,這個是鏡像部署解決不了的問題.但是我們織云平臺必須要解決這樣的事情.

此外還有一些Docker解決不了測試的問題,比如有人說我直接在測試環境測好打成一個鏡像,這可以.

但是,我們QQ有些大集群上千臺機器,每發一次都重啟一次嗎?這也不現實.測試怎么解決?灰度怎么解決?最后怎么上線?Docker也沒有解決上線的問題.我們網站型的應用,最后還是要加到域外解析,加到DNS.怎么辦?

為了解決它,所以我們內部整理了一個最適合騰訊社交的流程,如下圖.

我們把整個自動部署的過程抽象成六大步,但其實分解開來是有23步,我們為了兼容帶著業務特色的部署發布,帶著我們運維要求的一些部署發布,還必須要有一個測試的環節,必須要有灰度的環節,最終完成上線.

我們把我們的自動化的流程抽象成23步放在我們的資源平臺,但是資源平臺究竟起到一個什么樣的作用?或者說它的特別之處在哪里?我們是用了七大點把它總結出來,如下圖.

首先它是要能傳承的,所有的運維經驗都是一種配置項資源存在CMBD里面,并且需要提出了很多標準,這些標準落地在我們管理不同對象的運維系統里面,最終是協作的.

這么多個特征組成整個織云的技術架構,我今天都不講了,因為我覺得不需要這么多復雜的東西.

2、運維自動化的核心組件

接下來想跟大家深入一點的去交流自動化運維最核心的CMDB、流程系統,把我們的一個一個的工具通過我們的傳輸通道能串起來.

只要你實現了這些,你的運維效率就提高很多,不需要完全自動化,不需要無人職守.為什么要無人職守?本來就500臺機器,10個人,每個人50臺機器是很容易.

上圖是我們最重要的CMDB的技術架構,歸根結底就是一個關系型的數據庫.

我們要存哪些配置項來設計表的結構,并且可以提供接口化,讓我們的工具系統可以調度.

如果要做部署包的系統,首先要知道操作的對象是誰?這個對象的模塊名是誰?我剛才提到很重要一點,我們統一了開發和運維的語言,操作這個模塊每次部署需要裝哪些包?發哪些配置?近期都存在我們的CMDB數據庫里面,拉出來調我們的流程系統,調我們的傳輸工具,把這些資源推到我們的生產環境.

推完之后,要啟動流程系統、啟動步驟、測試步驟、灰度步驟、上線步驟,一步一步串起來.這就是為什么說自動化運維很重要的一個核心就取決于我們有什么樣的一些料可以做這道菜.

接下來是流程系統,現在業界沒有一些特別適用的開源方案,但是我們還是在做流程系統,今年又在做一版新的,希望做得更強壯.

假設我們寫了100個腳本,只是一個大的腳本,把這100個腳本串起來就是我們流程系統.

它可以通過一定的數據觸發執行,什么時候這個流程跑什么樣的工具都是有一些決策的,或者說當某個工具失敗了,究竟是重試還是跑分支流程,還是說終止告警,這就是我們的流程系統.

我們之前提供了一些函數頭,里面的工具寫好自己的邏輯,能夠通過一些公共輸入輸出的函數方法,讓這個工具本身處理完的輸入輸出能夠被流程理解,能夠傳給下一個工具.

主要核心就是做了這樣一個事情,架構做成什么樣子不重要,所以今天我畫的是原理,并不是架構.如果大家想看流程系統的架構,可以搜一下我以前分享過的運維自動化的PPT,里面有那個架構.

最后是傳輸通道,怎么樣讓流程串起來?

最終要操作生產環境的時候要怎么樣做?在騰訊我們用一個C/S的架構來實現我們叫做命令通道的東西,可以傳文件,可以執行命令.

大家寫一個C/S,自己配一個協議,傳一堆文件,它能解析指令、執行,找到對應的文件執行完,這個就是我們的傳輸通道最基礎的一些功能.

但是傳輸功能是不是僅僅這么簡單就足夠了?

基于安全性考慮,我們還需要去關注我們的源IP權限,防止被黑客攻擊變成肉機之后,隨意發起批量操作,有損大廠名譽.

其次是用戶身份的健全,QQ的運維不可能操作QQ音樂的設備,當然如果兼崗是可以的.我們會對執行的命令做一些解析,防止高危操作,防止某個人失戀了要刪數據庫走人.

還有約束目標的IP,對我們生產環境管理的理念是息息相關的,少數的像系統運維,因為他負責整個10萬臺機器,一次1萬臺也要分10次處理,而不是說一個命令把10萬臺搞定,因為人總會犯錯的.

做完這些CMDB流程系統,還有傳輸通道,如果大家所在企業的規模或者你所管理的設備量不大的話,效率已經提到很高了.

大家可以想一下,我要操作的對象都存在配置管理里面,配置好一個流程做執行,就是先安裝包,再去啟動相關的包,再把測試程序調用一下,把灰度接入兩臺在域名上,然后去驗證一下沒有問題,然后再接著全量上線.我們點幾下按紐就解決了,不需要完全無人職守.

但是在騰訊這個體量還是不夠,所以我們做了無人職守,做了無人職守還要做到這七點：你的設備怎么管理?究竟怎么樣決策?應該用哪個設備?

還有我們的智能決策,依賴什么樣的數據決策,應該起什么樣的流程?

假設我們有一個Web層有10臺機器同時掛了8臺,當只掛了一臺時我們可以不馬上發告警,因為有一個決策系統在.

我知道Web層的機器無狀態,我直接重啟它把它踢下線,但是又掛、又掛,掛了5臺時候決策系統就可以做一個決策,它的IP數量超過30%的不可用的時候,不能夠再不發通知了,這個時候就應該發通知給運維人員,讓人來干預這個事情,這是我們的智能決策.

還有我們的自動測試、灰度放量.

灰度放量基于怎樣的策略來灰度放量是灰度管理系統考慮的.還有變更體檢,有沒有基礎指標,CPU,你新上線的設備是不是跟現在設備CPU曲線吻合,或者說有沒有一些業務監控能夠告訴我,這就是變更體檢要做的一些事情.

還有日志通知,自動化系統跟監控系統聯動的時候,就像做一個變更,那邊有業務告警,這兩個數據一關聯起來,可能業務告警就不發了,那個取決于監控系統那邊告警策略建設.

3、實戰案例

做完了這七點,可以實現什么狀態?上面是騰訊QQ會員的一個真實案例,大家如果有用騰訊的產品肯定都收過騰訊給你推的紅點.

有些人處女座一定要點那個紅點,馬上請求量就來了.這一點對于運維來說就是一個惡夢,如果沒有提前準備容量,業務請求量就會飆高.

但是在無人守職的運維能力下,你也什么都不用做.你會收到一條短信提醒,無論是聊天工具的彈框,還是手機短信提醒你,現在正在有一個自動擴容在執行,它自己就跑完了整個流程.

因為我們把最核心的那三個部分,還有輔助它能實現最后一步七步做完,在自動化這一塊是可以說走在到了人生的巔峰.

最后想跟大家一起小結一下：今天分享的主題沒有把它鋪得特別大,大家回去可以看一下,我們有什么樣管理對象可以做成標準化,要怎么樣把它框起來,框起來之后針對這種標準的場景怎么樣做到最高效的運維.

我們的標準化、配置化,再把流程系統,把我們對標準對象要做的一切連接起來,最終就可以實現我們的運維自動化.好了,今天的分享講完了,謝謝大家.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4331.html