騰訊：3億人次實戰演習驗證異地容災架構與快速排程能力
作者介紹：
李光
現就職於騰訊SNG社交網路運營部，負責SNG移動類產品的業務運維，同時也負責運營平臺規劃與運維產品運營推廣工作
前言
社交網路事業群擁有眾多海量規模的業務，在海量的運營壓力下，伺服器裝置的數量也突破了10w大關，並有序的分佈在全國不同的IDC中實現異地容災的高可用架構。
但正因為社交業務的多IDC管理的複雜性，使運維小夥伴們經常會遇見一些難搞定的場景，如運營商網路出口異常流量驟降、網路延時突增、IDC斷電斷網、光纖被挖斷等突發事件，假設沒有第一時間發現和處理好這些事件，就會有較大的機率影響騰訊社交產品的服務質量，甚至會造成使用者大範圍的登入與訪問中斷。
如何在種種不可控的突發情況來臨時，業務能在使用者“零感知”的情況下第一時間恢復服務質量呢？這就需要我們的業務要有健壯的異地容災架構與快速的全網排程能力。
本文介紹的是手機QQ與Qzone兩個服務於海量使用者的平臺級業務，在無損使用者服務質量的基準原則下，通過億量級人次的限時排程實戰演習來驗證我們的異地容災架構與快速排程能力。
- 三地三活的容災能力
- 風馳電掣的排程能力
- 3億人次的實戰演習
一、三地三活的容災能力
海量服務之道就是要給億級使用者持續提供高質量與分級可控的服務，所有的研發與運維行為都應該圍繞保障與提升使用者服務質量展開，面對種種不可控的突發情況時，恢復業務的服務質量為最高優先順序要務。
讓我們把時間撥回一年前，2015年8.13日天津爆炸事件，相信很多的網際網路從業人員都印象頗深，騰訊天津資料中心距離起爆點直線距離僅一公里，可能會受到波及，華北7000多萬QQ使用者將面臨著登陸和訪問中斷的可能，那天晚上我們通過多次排程與柔性控制，在使用者“零感知”的情況下，順利的將天津全量使用者調回深圳。
容災能力是服務於業務，隨著業務的持續發展。現在我們的整體容災架構是三地分佈，三地三活，在各業務分佈上實現set化部署，鏈路均衡分佈，完善容量架構，從而減少風險。
QQ與Qzone的容災能力演進主路線也是單地—>雙地—>三地，三地分佈也提升了服務質量，方便使用者更加的就近接入。
- QQ與Qzone使用者資料三地均勻分佈1：1：1；
- 單地常態負載不高於66%兩地容一地，可在使用者“零感知”的情況下，將使用者調往三地之一；
為了行文方便，後續出現“雙平臺”字眼時，如無特殊說明均指“QQ+Qzone”的統一體。
二、風馳電掣的排程能力
對於排程使用者，一般都是從流量入口即接入層分流使用者，雙平臺也沿用與此思路。
1.手機QQ接入層
前端支撐手Q2.59億同時線上使用者，後端連線幾百個業務模組，接入層上千臺機器主要分佈在三大城市的數十個IDC，每分鐘處理20多億個業務包，7*24小時不間斷為億萬使用者提供著穩定的接入服務……這就是手Q接入層SSO。
手Q終端與SSO之間並不是直連的，兩者之間還加入了TGW，TGW全稱是TencentGateway，它是公司內部自主研發的一套多網統一接入，支援負載均衡的系統；它具有可靠性高、擴充套件性強、效能好、抗攻擊能力強等特點。加入TGW後終端與SSO、後臺之間的關係如下圖所示：
QQ使用者登入概要流程如下圖所示：
Qzone的主要流量入口來自手Q，因此雙平臺使用者可以聯動排程。
2. 排程能力介紹
排程動作概要來說就是干預使用者的接入點，下圖是一個非常概要的流程：
根據業務發展的推動與場景的細化，雙平臺的排程能力主要為兩個方向。
測速排程：
- 全網網路質量的最優路徑測算；
- 實時干預能力即將使用者排程到最優路徑上；
- 更細力度排程 如按閘道器ip排程；
重定向排程：
- 禁用VIP新建客戶端連結；
- 將原VIP已登入使用者重定向到新VIP；
在對後臺無衝擊壓力的情況下，我們可以完成千萬線上使用者10分鐘之內排程完畢，並且在排程期間使用者無感知 ，上圖就是我們在單次排程時清空一地線上使用者數的下降速率。
排程場景：
- 三地使用者常態分佈比例選用全網質量測速排程；
- 緊急事件時選用快速的重定向排程方式；
- 非極端情況下不會選用跨運營商排程，例如將電信使用者調往聯通；
排程操作：
- 分鐘級完成排程配置，並實時計算下發；
- 全自動化估算三地容量變化；
三、3億人次的實戰演習
我們先來看兩個場景，相信這兩個場景運維小夥伴或多或少都可能經歷過。
故事場景1：
某個電閃雷鳴、風雨交加的夜晚，運維小哥正舒服的窩在床上看著電影，突然手機一波告警襲來，N個服務延時集體飆高，經排查是運營商網路出口異常，運營商也暫時未能反饋修復時間，經評估後快速根本的解決方法就是將故障城市的xxx萬用戶排程到B城市，運維小哥正準備使出洪荒之力乾坤大挪移的將使用者移走，但杯具的是排程系統掉鏈子了，排程任務計算與下發異常，極速吼上相關同學排查排程系統問題，同時開啟後臺柔性撐過故障期。
故事場景2：
活動開始，使用者量逐步攀升，並且有地域聚集現象，A城市的整體負載已經偏高了，需要遷移XXX萬用戶排程到B城市，以便減少A的整體負載，在排程過程中發現B因某條業務鏈路的短板，所能承載的增量使用者要小於前期建設評估的整體使用者量，增量壓過去，會把B壓垮。
上面兩個場景，直接折射出問題是什麼？
只有通過實際場景檢驗的能力，才是我們運維手裡真正可用的武器，而不是在軍械庫裡放著，只是在盤點的時候“具備”的能力。
1. 為什麼要現網演習？
容災能力與容量架構把控是海量運維必修內功，能力的鍛鍊就是要通過不斷的實戰演習得來，要讓我們所“具備”的能力變為關鍵時刻的武器。
如上圖所示，通過一個完整的閉環流程，來不斷的精耕細作以便提升我們的能力，通過實戰將問題暴露出來，避免緊急事件時的被動。
2. 如何規劃演習？
QQ是一個體量非常之大的業務（DAU:8.3億），業務功能樹複雜，一個葉子節點的異常就有可能導致大範圍使用者的有損體驗與投訴。假設演習期間某個環節有問題，將有可能導致一個大範圍的事故。
我們在思考如何安全落地演習的時候，也主要基於以上緯度的考慮。話說不打無準備的仗，事前評估越完善，相應的就能提升我們整體演習的成功率，下圖就是我們最終落地的一個可執行的詳細演習流程圖。
如上圖所示 演習也是一個節點較多的閉環流程，生命週期主要分為以下三部分
- 演習前期規劃與準備；
- 演習實施，過程監控；
- 演習結束，整體質量評估與問題跟蹤；
3. 演習的目標
要通過演習生產出我們所需的資料與檢驗我們的業務質量，雙平臺是服務於海量使用者，全網業務鏈路複雜，我們期望能從下面三個維度檢驗我們的能力。
驗證業務質量與容量：
- 通過實戰演習驗證三地條帶化容量建設是否符合預期？
- 每增加千萬使用者時整體與關鍵業務鏈路負載是否可控？
- 短時間內因千萬使用者集中登入與關聯行為所產生的壓力後臺是否能抗的住？
- 柔性控制是否符合預期？
量化排程能力：
- 異地排程時每分鐘能遷移走多少使用者？
- 異地排程1000W使用者需要多少時間？
- 清空一個城市的使用者需要多少時間？
- 排程速率是否均衡穩定？
運營平臺：
- 現有的平臺能力(實時容量、地區容量、排程平臺、業務質量監控)是否能較好的支撐到演習與實際場景排程；
- 發現平臺能力的短板，以容量指標來及時度量排程的效果；
4. 演習效果
我們堅持月度/季度的實際演習排程，並在業務峰值實施排程演習。整個演習期間使用者“零感知”，業務質量無損，無一例使用者投訴。如此量級的演習在雙平臺的歷史上也屬於首次。演習也是灰度逐步遞進的節奏，下面圖例展示了，我們對一個城市持續三次的排程演習，使用者量級也是逐步增多 2000W4000W清空一個城市。
如上圖所示 演習也是一個節點較多的閉環流程，生命週期主要分為以下三部分
- 演習前期規劃與準備；
- 演習實施，過程監控；
- 演習結束，整體質量評估與問題跟蹤；
3. 演習的目標
要通過演習生產出我們所需的資料與檢驗我們的業務質量，雙平臺是服務於海量使用者，全網業務鏈路複雜，我們期望能從下面三個維度檢驗我們的能力。
驗證業務質量與容量：
- 通過實戰演習驗證三地條帶化容量建設是否符合預期？
- 每增加千萬使用者時整體與關鍵業務鏈路負載是否可控？
- 短時間內因千萬使用者集中登入與關聯行為所產生的壓力後臺是否能抗的住？
- 柔性控制是否符合預期？
量化排程能力：
- 異地排程時每分鐘能遷移走多少使用者？
- 異地排程1000W使用者需要多少時間？
- 清空一個城市的使用者需要多少時間？
- 排程速率是否均衡穩定？
運營平臺：
- 現有的平臺能力(實時容量、地區容量、排程平臺、業務質量監控)是否能較好的支撐到演習與實際場景排程；
- 發現平臺能力的短板，以容量指標來及時度量排程的效果；
4. 演習效果
我們堅持月度/季度的實際演習排程，並在業務峰值實施排程演習。整個演習期間使用者“零感知”，業務質量無損，無一例使用者投訴。如此量級的演習在雙平臺的歷史上也屬於首次。演習也是灰度逐步遞進的節奏，下面圖例展示了，我們對一個城市持續三次的排程演習，使用者量級也是逐步增多 2000W4000W清空一個城市。
- 排程質量
- 排程效率是否符合預期：例如計劃10分鐘遷移多少使用者量；
- 排程速率是否可控：排程的使用者量細化到分鐘粒度應該是基本均等，不能忽快忽慢；
- 排程量級是否符合預期：整體遷移使用者量級穩定可控；
- 業務質量
- 排程期間是否有使用者共性投訴反饋；
- 後臺服務質量是否可控；
- 監控系統是否有批量告警；
- 業務負載增長是否符合預期；
6. 演習流程的閉環跟蹤
演習的目的就是在於發現問題而不是秀肌肉，暴露的問題越多越好，每個問題都要完全閉環，幫助業務架構和運維能力持續優化與完善。
總結
在海量使用者場景與複雜的網際網路環境下，全網排程要做到 排程使用者量精準與快速排程使用者，其實也是一個蠻複雜坑也蠻多的的事情，通過這9次的實戰演習，我們的排程平臺、業務架構、排程速率均還有繼續優化深挖的空間。這裡並不是說單獨有一個很強大的排程平臺就可以了，而是一個環環相扣的閉環。
文章出處：高效運維（公眾號ID：greatops）