本文根據 2018 GOPS·深圳站演講整理發佈
首先，來說一下我們的組件運維團隊的職責範疇：負責整個SNG接入和邏輯層業務的運營維護，有1.8萬的域名，3000個業務模塊，4萬臺設備，單人運維設備超過2萬臺，這麼大的規模，我們面臨五大挑戰。
第一個挑戰，大家都知道，中國幅員遼闊，橫跨八個時區，有30多個省級單位，上萬個域名如何保證就近接入？我們機房是上海、天津、深圳三地分佈。考大家一個題，江西離上海近還是離深圳近？（現場問答互動）回答上海和深圳都是不完全正確:) 其實是江西北面離上海近，江西南面離深圳近。
我們在招運維的時候，還要求運維上通天文、下通地理才能幹好，這顯然不靠譜。中國有三大運營商，電信、聯通、移動，還有很多小的運營商。中國有一個段子，世界上最遠的距離不是天涯海角，而是你在電信、我在聯通，相信大家做運維這個體驗特別深刻，所以我們要儘量避免跨運營商。
第二個挑戰，自從蘋果啟用ATS安全規範之後，域名支持https接入就成為標準了，https證書是有有效期的，需要不斷的掃描、續期、更新。上萬個域名的https接入如何高效統一維護，由運維完全搞定這個問題，這是面臨的第二個挑戰。
第三個挑戰，一個人運維服務器超過萬臺的時候，你會發現每天名下有幾臺設備宕機是一個常態。像前面講的，你不能在床上躺下了馬上就起來，運維也是人乾的活，我們如何保證宕機無需運維干預自動處理，而且還對業務無損。
第四個挑戰，互聯網中有一句話上線容易、維護難，互聯網服務的運營維護週期比研發週期長，一個產品的研發週期，開發出來就幾個月，但是運營維護的時間往往是幾年甚至超過十年，很容易進入長尾死而不僵的狀態，所以對運維也有挑戰。
第五個挑戰，大規模的縮擴容。比如說在春節、元旦這些節假日用戶都喜歡在QQ空間發感想、在QQ群裡發祝福，社交網絡還會借勢推波助瀾一把，在節假日的時候搞一些活動，QQ紅包每年都搞，大家happy的節假日就變成我們運維的苦難日，因為涉及到大量設備上線、模塊擴容，這是我們面對的第五個挑戰，如何應對大規模的縮擴容。
本文從3方面進行闡述如何應對挑戰
1. 海量服務的基礎架構
我將從海量服務的基礎架構、在運維過程中堅持的一些原則和支撐大型活動事件的技巧三個方面來分別闡述我們如何應對上述的挑戰。
首先看一下騰訊SNG的基礎架構。用戶一個請求過來之後，任何一個訪問首先是DNS查詢，查詢得到TGW和STGW的網關IP。這個TGW與業界開源的LVS和商用的F5是類似的東西。請求經過網關的負載均衡，到web層服務器，然後到邏輯層、存儲層，圖中間的織雲路由是內網的負載均衡系統。我們的整個訪問鏈路做到了三個基本點：第一，做到名字服務實現沒有調不走的流量，這對運維是非常重要的。第二，容錯做到沒有不能宕機的設備，也就是沒有不能死掉的設備。我們在網上看到一些段子，運維請法師來機房開光保佑不要宕機，其實求佛不如求己。第三，統一框架提升研發運維效率，保證服務的基本質量，對於運維這有很大的意義，後續我會重點闡述。
牛頓說，如果我看得比別人更遠，是因為站在巨人的肩膀上。如果我們能夠運維萬臺服務器，是因為我們站在巨人的肩膀上，踮起腳尖，做了一次一米八的眺望。
巨人的肩膀，一個是GSLB，是騰訊自研的DNS服務，通過識別LocalDNS出口IP國家+省份+ISP屬性，然後給對應請求返回相應的IP，實現就近接入。北京、上海、天津每個地域有三大運營商+中小運營商出口CAP，然後再加上香港，所有海外的通過香港接入的方式，根據運營商來進行調度，這樣一個是避免了跨運營商，二是做到運營商網絡出口故障快速切換，依賴的就是GSLB的兩點：第一，GSLB有一個強大的基礎數據庫，它有全面而精準的IP地址庫，國家和運營商的信息準確率做到100%，省份的信息準確率做到98%，我們通過亞洲網絡中心和中國網絡中心的數據、運營商路由數據等通過一些算法校驗得到ip地址庫的數據。第二，我們擁有各IDC機房對各地用戶覆蓋質量的實時數據，通過機房撥測和前端頁面的一些js抽樣上報得到這個數據。
第二個巨人的肩膀是TGW，也就是騰訊的網關係統。2012年之前騰訊也使用了LVS tunnel模式，但是騰訊的業務發展太迅猛了，特別是遊戲很快面臨一個問題，外網資源耗盡。這種背景下，TEG的基礎架構部推出了TGW這個系統。它的最大特點是能夠收斂外網IP，只需要一個外網IP，所有數據包的進出都是通過TGW，對後端真實的服務器是沒有外網需求的。LD本身的VIP怎麼做到高可用的呢？通過OSPF路由一致性協議，一般是4臺為一個集群，共享這個VIP，任何一個LD掛掉之後都不會對這個VIP產生影響。
另外，TGW還做了多通接入，每個機房有三大運營商的出口和CAP的出口，我們部署的服務器對運營商機房沒有要求，電信的機房一樣有三網+CAP的出口。以前用LVS tunnel模式的時候，電信的容量必須靠電信機房的服務器，所以對服務器機房的限制就非常多。
除了外網IP收斂之外，TGW也支持4/7層，特別是在7層，可以做到幾百域名共享一個外網的VIP，當然TGW LD 集群所在的機房都是萬兆，承載能力非常強。
第三個巨人的肩膀是STGW。你可以認為跟TGW是差不多的，它只是在TGW基礎上支持了https，自從蘋果啟用ATS安全規範之後，新上線域名默認就會支持https接入，因為你說你的網站不支持https就不好跟人家打招呼。我們面臨的情況是域名特別多，在沒有STGW之前，對於https的支持方式，開發或者運維都是自己上傳證書到服務器，放在自己想放的路徑下，每個人的style都不一樣，證書沒有統一管理，一旦人員流動，他做的這些事情就爛在生產環境了，所以出現很多證書沒有及時續期和更新證書產生的故障。我們痛定思痛之後，對全網的域名推動上STGW，所有證書統一部署在STGW平臺，申請、續期、更新等操作全部由組件運維團隊來做。證書通過域名一個一個的去掃描是否過期的可靠性就比較低，如果是STGW託管，我們直接從服務器上讀取證書的過期時間，這是不可能失誤的，而且證書安裝更新的環境更加純淨，變更風險小了很多。
第四個巨人的肩膀是織雲路由。剛才sam也做了詳細分享，它的定位是內網的名字服務系統。它是我們的用戶請求經過TGW到內網之後，是接入層到邏輯層，邏輯層到存儲層的尋址系統。有一些企業在內網負載均衡也會用F5，我們為什麼不用呢？是差錢嗎？我們根本不差錢。講一下我們為什麼不用，我們的路由是強嵌入式的，對用戶主調是有要求的，這裡有兩個函數，接口非常簡單，首先通過GetRoute獲取ip端口，之後去訪問，然後你訪問我是成功還是失敗，通過對API RouteResultUpdate上報，對上報數據進行統計之後，做一個負載均衡的決策。
我們的織雲路由跟業界大家熟知的東西到底有什麼區別？我來詳細介紹一下。剛才說了，我們不差錢，為什麼要用織雲路由呢？因為我們對服務的精細化治理有要求，所以它本身是一套服務精細化治理的解決方案。
它唯一的劣勢是在使用門檻方面需要業務調用API代碼，但是這也帶來了好處，相對F5和LVS這種無侵入的方式，基於調用方上報織雲路由實現了後臺服務質量的精細化管理，織雲路由的成功率是SNG後臺服務質量的考核標準，通過這個推動後臺服務的質量。
二是負載均衡根據業務上報的成功率設置了過載保護的能力，後臺能力不行的時候會把多餘的請求拒絕掉，只給能夠成功的請求。與其把請求全部發送給後端，把後端壓死，不如在前端獲取IP+端口的時候就告訴你過載了、不要請求了，把請求控制在後端能夠承受的極限來發。
三是容錯能力，F5和LVS的容錯只能探測到端口的連通性，而織雲路由可以自定義容錯場景。四是相比F5和LVS的四層代理，對於被調服務獲取主調IP會有很大的困難，對服務問題追蹤是一個很大的門檻，而織雲路由不會造成這種困擾。
第五個巨人的肩膀，邏輯層統一框架SPP。後臺框架對運維的意義重大，SPP由Proxy、Worker和Controller三部分組成。開發可以很簡單就寫一個魯棒性強的高大上後臺server，Controller對Worker和Proxy有監控能力，如果發現Worker和Proxy有問題會重新拉起，還可以通過配置Worker的進程數來控制程序的併發能力。
統一框架對運維的意義：
一是我們可以跨業務實現維護策略的統一。
二是網絡框架和業務邏輯SO分離管理，運維具備快速升級框架的能力。有很多統一框架是集成的，和業務程序包打在一起、編譯進去的，當框架推出一個新的優化，想全網快速普及的時候，要讓所有業務系統重新編譯發佈。而我們的框架和SO分離的管理方式，框架是由運維統一部署的，SO是由業務部署的。框架有一個好的特性或者緊急的BUG要升級的時候，運維可以快速升級框架，不需要重新編譯就可以做到這一點。
三是運維專業度提升。大家知道，鐵打的業務，流水的兵，人員流動是非常快的，我們統一框架之後可以做到運維在問題定位方面具備更強的能力，專業度的提升非常大，框架數據包的流轉流程非常清楚，運維就比開發更懂他寫的這個程序，當然除了業務邏輯除外，大部分方面運維比開發更專業。
四是Controller對proxy和worker具備監控和起停的能力。C語言後臺程序經常出現coredump，指針使用不善就會core掉，Controller使worker進程即使掛調也能夠快速恢復。
2. 運維實踐中總結的幾個原則
說完了巨人的肩膀，接下來說一下踮起腳尖一米八的眺望。如何讓運維變得更加高效？
第一個原則是“名字服務原則”
前面說了，名字服務非常關鍵，我們要保證系統任何一個尋址都有名字服務。我們每年有上萬臺設備裁撤，沒有IP是不能動的，所有IP都是可以變的。近10萬臺設備，每天幾臺設備宕機成為一個常態，名字服務和容錯是自動化運維的基礎之一，重要性我前面也講了很多，那麼這裡我分享一下運維是如何去影響研發側，把名字服務的原則落實的。
我們從三方面來做：
一是聯合QA建立質量考核體系。我們把訪問關係梳理好，和名字服務的訪問關係來對比，發現哪些調用沒有使用名字服務，從名字服務的覆蓋率和QA推動所有研發必須用。這是中策，畢竟推動也不是那麼容易。
二是後臺框架支持RPC，封裝路由尋址調用，讓主調方在不知不覺中已經使用了名字服務，服務提供方就可以具備流量快速切換的能力。
三是拓展名字服務的場景，織雲路由支持按照UIN的有狀態尋址和一致性hash尋址，同時支持了DNS協議，降低接入門檻，這樣來普及我們的名字服務。
第二個原則是“一致性原則”。
大家做過運維，我們SNG的服務是按照模塊管理的。織雲CMDB模塊錄入包、名字ID、配置文件、權限等資源。你要看錄入的資源和現網使用的是不是一樣的，所以我們運營的時候也遇到一致性的問題，我們對裝包的權限進行了收攏，由組件運維這邊統一控制，為了實現模塊下所有設備包的一致性管理，不能有的機器裝了、有的機器沒有裝，這會對現網帶來運營風險。
配置文件方面，你通過配置系統發送到現網，有人篡改了，系統登記的和現網使用的配置不一致，只要你動這個配置就會出現問題，所以我們正在啟動一個改造，開啟強一致功能，把現網機器上的配置文件和配置中心的進行一致性對比，發現不一致就強制修改回來。同時，我們在想，配置管理為什要以文件的方式，而不能以Key-value這種內存鍵值對呢？使用Key-value，你不需要在本地文件進行讀取，有一些是服務熱重啟的，有一些不支持，配置文件變更重啟難免就會有影響，Key-value的模式天然的就是不需要重啟的，這種方案也有很多實現。我們後續主推Key-value的方式，讓生效時間和影響都變得最優。
權限方面，最開始我們按照IP去管理，後來發現IP模塊歸屬變化之後帶來冗餘，而且每次擴容都需要對新IP單獨申請權限，短板很大，所以我們就跟模塊綁定，不是跟IP綁定，按照模塊管理，只要在這個模塊下就有這個權限，這個管理比IP管理要優一些的。
某種程度上，我們織雲按照模塊的管理維度，你這個模塊綁定了哪些名字，這個模塊的IP是不是接入這些服務，如果有的沒有接、有的接了，對於你縮容的時候會產生風險，會有把某一個名字踢空的風險，所以我們定期進行比對，一旦發現有問題就派單去去處理，保持模塊下IP和服務接入名字兩者的一致性。
第三個原則是無數據原則。
這個原則是很重要的，對於我們接入和邏輯層，一個人維護2萬臺設備是非常關鍵的基礎。我們要求所有的接入層和邏輯層設備無數據。首先對於上報超時這種假死狀態的告警，因為它無數據，所以整個處理過程變得很簡單，需要考慮的點比較少，有告警我們首先判斷是不是接入層和邏輯層設備，如果是就可以直接重啟。剛剛說了，我們的織雲路由是具備流量自動恢復的，會在設備故障之後發現端口連通性恢復之後就把流量自動恢復過來，如果重啟不能修復就看駐場能不能修復，如果駐場不能修復就退役了，如果駐場能夠修復就可以繼續服務，這種就是簡單粗暴可靠的。第二個無數據還帶來設備要求的簡化，無raid，硬盤故障之後直接換盤重裝。第三個無數據的要求，磁盤在保存儘可能多日誌的前提下實現自動化清理。我們一步一步的縮短日誌保存的時間，直到磁盤不告警為止，對我們來說騷擾就會變得非常少。
第四個原則是統一原則。
我們有統一後臺框架、統一名字服務、統一配置中心、統一數據上報通道、統一包發佈系統，這些是自動化平臺的基礎，因為統一帶來維護對象的減少和對上層調用系統呈現出來的的簡單，可以大大提升上層自動化系統的可靠性。我們有一句話，不要在沙盤上建高樓，底子沒有打好，自動化程度很難提升上來。
3. 支撐大型活動事件的實踐技巧
接下來說一下我們針對大型支撐活動事件的實戰技巧。針對社交業務的活動、節假日做的事情，是比較個性化的，大家可以聽一下，看看有沒有什麼啟發。
我們大型活動的挑戰：擴容設備量大、模塊多、擴容狀態跟進難，一個人要擴容一個模塊還好，要擴容幾十、上百個模塊，你發現流程狀態跟進很難。留給擴容部署的時間也緊，剛剛過去的2018年春節和紅包活動，組件運維團隊擴容641次，涉及535個模塊，15701臺設備，擴容操作要求在設備交付後一週內完成。
看一下春節擴容的大概流程。首先是資源申請，要進行資源合理性PK，然後要去採購，進行資源交付，之後要有虛擬化的過程，設備生產和擴容部署在織雲，驗證灰度和全量上線涉及到織雲路由（通過織雲路由調度流量）和監控系統（通過監控系統查看新擴容IP的服務質量）。活動搞完了，要下線，要進行設備隔離，整個資源的退還要在資源管理系統去做。我們面臨和不同部門各個團隊的溝通，各個系統單獨操作的成本是很大的。打一個簡單的比方，當你有15000臺設備分配下來的時候，你要把它劃到對應的模塊，這個事情如果不用工具去做，人肉去操作都要搞兩三天，而且還很容易出錯。
織雲對於單個服務的自動化部署流程：首先是部署準備，二是發佈部署，三是發佈自檢，四是灰度上線。
首先是部署準備，檢查一致性、檢查設備連通性、獲取資源、屏蔽警告。
二是發佈部署申請權限、安裝程序包、發配置、同步文件。
-
三是發佈自檢，啟動軟件包、進程端口掃描、治行測試工具。
四是灰度上線，一臺灰度10%，調用變更體檢，全量接入。
我們比較好的具備單個服務的自動化部署能力，但是對於我們應對幾百個模塊的同時擴容還不夠。在這個基礎上，我們做了批量部署的系統，各個系統對其功能對外都有接口化的能力，對外提供http接口，那麼批量系統可以把各個系統的這些操作串聯起來。
批量部署系統：一是集中展示和管理，各個步驟封裝成原子接口，在統一界面操作。二是對接各個系統，比如說哪個模塊擴容多少，在資源申請單的時候這是錄入了的，批量系統根據資源申請單自動生產設備，把設備分配給相應的模塊，批量在織雲上發起擴容流程。三是規模效應，批量操作上百個業務模塊。四是狀態自動跟進，我們把關鍵節點的狀態全部記錄下來，在統一的頁面上去展現，才知道這幾百個模塊擴容狀態到底是什麼樣的，完成了多少，有哪些正在進行中、哪些失敗了，便於聚焦擴容出現了問題的模塊。
我們最終做到的效果就是能夠在一週內把15701臺設備600多次擴容全部搞定。春節期間的組件團隊單人最多的時候運維超過2萬臺設備。
4. QA環節
提問：你們可以識別小運營商的多出口來調度到運營商嗎？張黎明：我們中小運營商是調度到統一的CAP出口。
提問：小運營商走專門的出口？張黎明：對，電信、聯通、移動不跨網，中小運營商我們有一個加速平臺叫CAP，每個域名都會申請CAP的VIP。
提問：你們調度是根據機器密度還是根據業務？如果機器現在有問題了，你把機器的流量都切走，還是把理想的流量切到這裡來？張黎明：比如說福建電信原來走深圳電信的服務，當我們一旦發現深圳電信故障的時候，它會調度到上海電信，因為我們三地分部，所以會有一個自動切換到上海電信的過程。
提問：根據業務來的嗎？它隻影響了一部分業務。張黎明：VIP故障一般都是運營商網絡故障，掛在這個VIP下面的所有業務都會受影響，無一倖免的，這個VIP承載的運營服務都需要調度走
如何解鎖更多自動化運維新技能？
來 DevOps 國際峰會·自動化運維專場
來自阿里，京東，華為，招行的四位專家手把手傳授你經驗
當然，這裡還有更多高端，大氣，上檔次的精彩演講
掃描二維碼進入大會官網
閱讀更多 高效運維 的文章
