摘要：月日，首期沙龍海量運(yùn)維實(shí)踐大曝光在騰訊大廈圓滿舉行?？椩聘咝У膶?shí)踐是，它是以運(yùn)維標(biāo)準(zhǔn)化為基石，以為核心的自動(dòng)化運(yùn)維平臺(tái)。

作者丨周小軍，騰訊SNG資深運(yùn)維工程師，負(fù)責(zé)社交產(chǎn)品分布式存儲(chǔ)的運(yùn)維及團(tuán)隊(duì)管理工作。對(duì)互聯(lián)網(wǎng)網(wǎng)站架構(gòu)、數(shù)據(jù)中心、云計(jì)算及自動(dòng)化運(yùn)維等領(lǐng)域有深入研究和理解。

12月16日，首期沙龍“海量運(yùn)維實(shí)踐大曝光”在騰訊大廈圓滿舉行。沙龍出品人騰訊運(yùn)維技術(shù)總監(jiān)、復(fù)旦大學(xué)客座講師、DevOps專家梁定安，講師騰訊手機(jī)QQ運(yùn)維負(fù)責(zé)人郭智文，騰訊高級(jí)工程師魏旸，騰訊SNG資深運(yùn)維專家周小軍出席沙龍，并帶來精彩的技術(shù)分享。為了便于大家學(xué)習(xí)，特將本次沙龍講師的演講內(nèi)容進(jìn)行了整理。您也可以在騰訊織云公眾號(hào)下載本次演講PPT。

運(yùn)維有三座大山：大活動(dòng)、大變更、大故障。這幾個(gè)運(yùn)維場(chǎng)景是最消耗運(yùn)維人力的。特別是大活動(dòng)，非?？简?yàn)彈性能力，對(duì)運(yùn)維自動(dòng)化挑戰(zhàn)很大。

我今天所分享的主題就是深入百億次紅包大活動(dòng)的背后，解析騰訊運(yùn)維的方法體系，了解織云平臺(tái)如何幫助運(yùn)維實(shí)現(xiàn)大活動(dòng)高效運(yùn)維，如何減少運(yùn)維人海戰(zhàn)術(shù)。

過年大家都刷過微信紅包和 QQ 紅包，QQ 紅包的業(yè)務(wù)主要有幾種產(chǎn)品形態(tài)：刷一刷紅包、拼手氣紅包、AR紅包和空間紅包等。2016年跨年除夕這天有2.6億的在線用戶刷了729億次的紅包。這么大的體量給整個(gè)架構(gòu)體系帶來的沖擊是非常大的。

今天將從”刷一刷紅包”的業(yè)務(wù)架構(gòu)、活動(dòng)背景、計(jì)劃擴(kuò)容、壓測(cè)和演習(xí)、運(yùn)維策略及活動(dòng)現(xiàn)場(chǎng)這幾個(gè)方面來分享我們的活動(dòng)型背后的運(yùn)維支撐工作，希望給大家在產(chǎn)品大活動(dòng)時(shí)提供參考和幫助。

大活動(dòng)前的二個(gè)月，產(chǎn)品會(huì)給研發(fā)和運(yùn)維提供詳細(xì)的產(chǎn)品運(yùn)營指標(biāo)，春節(jié)前”刷一刷”紅包所規(guī)劃的產(chǎn)品指標(biāo)預(yù)估為峰值每秒800萬，同時(shí)活動(dòng)及節(jié)假日也帶來相關(guān)QQ消息量和空間說說量2-5倍的上漲。

根據(jù)運(yùn)營指標(biāo)，運(yùn)維按歷史性能數(shù)據(jù)、容量模型和業(yè)務(wù)架構(gòu)，評(píng)估出春節(jié)活動(dòng)需要2萬臺(tái)虛擬機(jī)和3千臺(tái)數(shù)據(jù)庫服務(wù)器擴(kuò)容支撐。

節(jié)前恰好遇到廠商內(nèi)存供貨問題，服務(wù)器供應(yīng)非常緊張，采購比原計(jì)劃延期了一個(gè)多月。甚至有個(gè)別型號(hào)的服務(wù)器到春節(jié)封網(wǎng)前一天才到貨。緊張的設(shè)備供給運(yùn)維增加了擴(kuò)容壓力。

運(yùn)維有2個(gè)月時(shí)間來準(zhǔn)備和實(shí)施紅包活動(dòng)，上圖是活動(dòng)日程表。在確定產(chǎn)品策略和活動(dòng)方案后，12月進(jìn)入資源采購流程，元旦前后進(jìn)入擴(kuò)容部署。

業(yè)務(wù)擴(kuò)容有兩周時(shí)間，到1月的中旬，也就是離春節(jié)還有2周的時(shí)間開始進(jìn)行業(yè)務(wù)和模塊壓測(cè)，以及活動(dòng)演習(xí)及預(yù)案，大年三十我們開始進(jìn)入活動(dòng)現(xiàn)場(chǎng)。

在活動(dòng)現(xiàn)場(chǎng)，產(chǎn)品、開發(fā)和運(yùn)維全部在第一線保障紅包，一直堅(jiān)守到大年初一的凌晨一兩點(diǎn)鐘。

由于活動(dòng)涉及業(yè)務(wù)多，模塊核心鏈條關(guān)系錯(cuò)蹤復(fù)雜，運(yùn)維在前期的活動(dòng)梳理中，要做好基礎(chǔ)能力、外部服務(wù)壓力和支撐等復(fù)雜的評(píng)估準(zhǔn)備工作。

支撐工作梳理包括內(nèi)網(wǎng)專線穿越流量梳理，因?yàn)闃I(yè)務(wù)均為多地部署（深圳、天津和上海），同城也有幾個(gè)大的核心IDC，業(yè)務(wù)不僅有同城跨IDC 部署，也有跨城異地部署，評(píng)估同城、跨城的專線容量是容量評(píng)估重點(diǎn)之一，如果超出閾值有什么應(yīng)急方案，跨城調(diào)度與容災(zāi)怎么做，柔性與過載保護(hù)策略等，這些都是運(yùn)維要考慮的核心保障工作。

在分享擴(kuò)容之前，我先從刷一刷紅包的系統(tǒng)架構(gòu)開始，先讓大家對(duì)業(yè)務(wù)進(jìn)一步的了解。

業(yè)務(wù)架構(gòu)由抽獎(jiǎng)系統(tǒng)、消息系統(tǒng)和支付系統(tǒng)三個(gè)核心架構(gòu)組成。

接入層SSO統(tǒng)一接入：手Q自身系統(tǒng)與客戶端唯一連接。

抽獎(jiǎng)主邏輯：含抽獎(jiǎng)相關(guān)邏輯、數(shù)據(jù)上報(bào)等、排行榜、訂單管理等。路由采用L5（自研內(nèi)部路由系統(tǒng)簡(jiǎn)稱）的HASH一致性功能，保證同一個(gè)用戶的不同請(qǐng)求會(huì)落到同一臺(tái)機(jī)器。

存儲(chǔ)：中獎(jiǎng)記錄和獎(jiǎng)品等信息統(tǒng)一存儲(chǔ)。統(tǒng)一使用公共組件Grocery（自研NoSQL分布式存儲(chǔ)系統(tǒng)）進(jìn)行存儲(chǔ)。

禮包發(fā)貨：現(xiàn)金外的其他獎(jiǎng)品發(fā)貨，包括公司內(nèi)外業(yè)務(wù)的禮券。

公眾號(hào)消息：負(fù)責(zé)用戶中獎(jiǎng)以及發(fā)貨通知。

支付系統(tǒng)：現(xiàn)金和獎(jiǎng)品發(fā)貨，還包括后端的銀行接口等。

CDN 資源：用于獎(jiǎng)品圖片信息等資源下載。

根據(jù)這三個(gè)層，架構(gòu)分成無狀態(tài)層和有狀態(tài)層，無狀態(tài)層為接入層和邏輯層；有狀態(tài)層即數(shù)據(jù)存儲(chǔ)層，數(shù)據(jù)持久化存儲(chǔ)。

擴(kuò)容包括無狀態(tài)層和有狀態(tài)層的設(shè)備擴(kuò)容。

上圖是系統(tǒng)的架構(gòu)圖

下面講一下怎么做無狀態(tài)的擴(kuò)容，這是傳統(tǒng)的擴(kuò)容流程，傳統(tǒng)運(yùn)維的擴(kuò)容流程一般是通過腳本來部署。我們把流程拆解下，可以看到它主要由以下核心步驟組成，包括部署操作系統(tǒng)、服務(wù)部署、配置下發(fā)、業(yè)務(wù)模塊關(guān)聯(lián)、業(yè)務(wù)代碼包發(fā)布、業(yè)務(wù)權(quán)限管理、啟動(dòng)服務(wù)、模塊測(cè)試、服務(wù)上線和加入監(jiān)控告警。

藍(lán)色圓圈是流程執(zhí)行的時(shí)間消耗，這里一臺(tái)設(shè)備約消耗半小時(shí)。如果擴(kuò)容一千臺(tái)機(jī)器需要兩個(gè)人/月。如果用腳本或開源運(yùn)維工具批量的擴(kuò)容，一個(gè)模塊按一人一天，這樣的工作量還是非常繁瑣的，非常依賴人海。

3.2.2 一鍵擴(kuò)容

在我們強(qiáng)大的織云自動(dòng)化運(yùn)維平臺(tái)支撐下，我們的業(yè)務(wù)模塊都是一鍵式擴(kuò)容模式，也稱一鍵上云。一個(gè)模塊下的上百臺(tái)設(shè)備，整個(gè)擴(kuò)容流程跑完只消耗5分鐘時(shí)間。

我們來看一下我們這邊是怎么做的，這是我們基于CMDB的全自動(dòng)擴(kuò)容，CMBD 是我們非常核心的擴(kuò)容系統(tǒng)，包括資產(chǎn)、模塊、業(yè)務(wù)對(duì)象、軟件包、配置等等的數(shù)據(jù)信息都在這里面。

新部署服務(wù)器從 CMBD 獲取屬性以后，會(huì)進(jìn)入到服務(wù)包的部署，之后到告警屏蔽，下面有發(fā)布自檢，會(huì)檢測(cè)裝的包是否正常的。然后到業(yè)務(wù)測(cè)試，灰度上線，體檢報(bào)告。整個(gè)流程效率比較高，一般來講部署一臺(tái)設(shè)備或一個(gè)模塊也就5分鐘，因?yàn)樗遣l(fā)來做擴(kuò)容的?？椩埔呀?jīng)把運(yùn)維操作抽象成幾百個(gè)流程。

整個(gè)春節(jié)期間走了700多次擴(kuò)容流程，每天都有上百個(gè)業(yè)務(wù)模塊并行，春節(jié)我們擴(kuò)容了200多個(gè)模塊，平均一個(gè)模塊是100多臺(tái)設(shè)備。

上圖是織云的一鍵上云頁面，左邊是管理列表，右邊是服務(wù)器屬性。包括它屬于哪個(gè)模塊，IP是多少，什么機(jī)型，運(yùn)營狀態(tài)，操作系統(tǒng)，監(jiān)控等等。

變更具備交付后不管的能力。

報(bào)告根據(jù)變更和監(jiān)控記錄，取得變更設(shè)備和變更對(duì)象列表，然后分析這些變更對(duì)象的監(jiān)控?cái)?shù)據(jù)，得出體檢結(jié)果。

體檢報(bào)告的檢測(cè)結(jié)果為正常，需關(guān)注，異常。正常表示本次變更正常；需關(guān)注表示此次變更中有一些監(jiān)控指標(biāo)波動(dòng)比較大，需要相關(guān)人員關(guān)注下，對(duì)業(yè)務(wù)本身沒有造成重要影響；異常表示本次變更造成了現(xiàn)網(wǎng)故障，需要立即回滾。正常的體檢報(bào)告不發(fā)送任何通知，需關(guān)注的體檢報(bào)告發(fā)送郵件通知，異常的體檢報(bào)告既發(fā)送郵件也發(fā)送短信通知。

檢查項(xiàng)大體可分為兩類：基礎(chǔ)特性檢查項(xiàng)，業(yè)務(wù)檢查項(xiàng)。

基礎(chǔ)特性檢查項(xiàng)是指與機(jī)器相關(guān)的監(jiān)控項(xiàng)，如cpu，流量，包量等。

業(yè)務(wù)檢查項(xiàng)則是與業(yè)務(wù)相關(guān)的服務(wù)間調(diào)用（簡(jiǎn)稱模調(diào)），自動(dòng)化測(cè)試等。

體檢周期為5、10、20、30分鐘。

7個(gè)檢查特性包括CPU、網(wǎng)外卡流量、內(nèi)外網(wǎng)卡包量、CPU超過80%的設(shè)備數(shù)、自動(dòng)化測(cè)試告警、模調(diào)告警等，并分別進(jìn)行評(píng)分。評(píng)分為0則正常，小于一定值則需要關(guān)注，總分大于一定值為異常。

上圖里面，變更5分鐘，告警數(shù)，容量告警、DLP 告警都是零，第10分鐘也是這個(gè)告警，到了第20分鐘出現(xiàn)四條模調(diào)告警，就觸發(fā)一條告警信息給運(yùn)維，運(yùn)維通過郵件把這個(gè)發(fā)給業(yè)務(wù)負(fù)責(zé)人。保證這個(gè)變更是閉環(huán)，從設(shè)備的申請(qǐng)到發(fā)布自檢到報(bào)告都是一個(gè)閉環(huán)的流程，這個(gè)運(yùn)維是非常高效的。

剛才說過的傳統(tǒng)的擴(kuò)容跟織云擴(kuò)容的對(duì)比，傳統(tǒng)擴(kuò)容基于用 Excel 或 Word 來管理業(yè)務(wù)信息和資源信息，稍進(jìn)步一點(diǎn)的用數(shù)據(jù)庫來管理。運(yùn)維要登錄跳板機(jī)或總控臺(tái)，在總控臺(tái)用命令行或頁面跑各種安裝腳本，腳本之間需要人工確認(rèn)。

比如說裝一個(gè) MySQL，安裝完成以后要手工把IP、端口等信息粘貼到下一個(gè)腳本或流程來由運(yùn)維繼續(xù)執(zhí)行，腳本間沒有全流程概念，需要人工去更新信息。一個(gè)業(yè)務(wù)工程師同時(shí)只能做一個(gè)模塊的變更或擴(kuò)容，如果并發(fā)同時(shí)做多個(gè)變更，極易出錯(cuò)出現(xiàn)故障。

織云高效的實(shí)踐是，它是以運(yùn)維標(biāo)準(zhǔn)化為基石，以 CMDB 為核心的自動(dòng)化運(yùn)維平臺(tái)。通過 Web 界面的一鍵式上云，基于業(yè)務(wù)原子任務(wù)和流程引擎，形成一個(gè)完整的運(yùn)維流程，最后并行執(zhí)行。一個(gè)模塊一個(gè)人5到10分鐘就可以做完所有操作。

高效擴(kuò)容的背后是基于一套標(biāo)準(zhǔn)化的理念。包括分層標(biāo)準(zhǔn)化、可運(yùn)維規(guī)范、軟件標(biāo)準(zhǔn)化，并且標(biāo)準(zhǔn)化以 CMDB 落地。

在DevOps的實(shí)踐中，織云在后面這二環(huán)。開發(fā)交付包、配置和模塊名稱，通過織云完成部署。

我們以 CMDB 為核心，把資產(chǎn)配置、硬件配置、軟件配置、運(yùn)營配置，比如說這個(gè)IP是在哪個(gè)地方部署的，因?yàn)槲覀冇腥轂?zāi)，還有權(quán)限的管理，我們模組之間有管理，把這些配置都打包到 CMDB 里面，通過引擎實(shí)現(xiàn)自動(dòng)化發(fā)布機(jī)制。到線上服務(wù)以后，后面還會(huì)有監(jiān)控告警、一致性、變更體檢等等閉環(huán)的服務(wù)。從 CMDB 到線上服務(wù)，整個(gè)流程都是閉環(huán)的。

這是運(yùn)維標(biāo)準(zhǔn)化的實(shí)踐。把架構(gòu)、配置、監(jiān)控、軟件包、工具等等先實(shí)現(xiàn)標(biāo)準(zhǔn)化，然后落實(shí)到 CMDB 配置中心，通過工具或流程快速交付。標(biāo)準(zhǔn)化是要落地，如果沒有這些跟 CMDB 的實(shí)踐，標(biāo)準(zhǔn)化就是一個(gè)紙面的東西，是沒有辦法實(shí)現(xiàn)的，這四步缺一不可。

剛才講到無狀態(tài)的擴(kuò)容，現(xiàn)在是講有狀態(tài)的數(shù)據(jù)層擴(kuò)容。通常來講，數(shù)據(jù)層擴(kuò)容是 DBA 工作中工作量最大、最易出故障的變更。但在我們這邊，數(shù)據(jù)層擴(kuò)容已經(jīng)實(shí)現(xiàn)了與無狀態(tài)層一樣的靈活性。

我們的數(shù)據(jù)層分兩層架構(gòu)，上層是無狀態(tài)接入機(jī)，負(fù)責(zé)數(shù)據(jù)路由配置，下層是存儲(chǔ)機(jī)，負(fù)責(zé)數(shù)據(jù)存儲(chǔ)。

接入機(jī)擴(kuò)容跟無狀態(tài)層的擴(kuò)容方法類似。

存儲(chǔ)層通過數(shù)據(jù)搬遷，同時(shí)并行修改接入機(jī)路由表來實(shí)現(xiàn)擴(kuò)容。

存儲(chǔ)層擴(kuò)容的原理是，我們首先把記錄 KEY HASH 1萬到桶，桶再分配到存儲(chǔ)機(jī)的存儲(chǔ)單元，通常是 1GB 一個(gè)內(nèi)存存儲(chǔ)單元，一臺(tái) 64GB 內(nèi)存的存儲(chǔ)機(jī)有56個(gè)存儲(chǔ)單元。

桶是搬遷最小單元，通過桶搬遷方式來實(shí)現(xiàn)記錄的擴(kuò)縮容，整個(gè)桶搬遷是全自動(dòng)化，運(yùn)維只要指定一臺(tái)或一批目標(biāo)存儲(chǔ)機(jī)，桶和記錄就會(huì)自動(dòng)搬遷分布到目標(biāo)存儲(chǔ)機(jī)之上，搬遷過程中代理機(jī)的路由表是實(shí)時(shí)更新的，因此搬遷過程中業(yè)務(wù)的訪問不受任何影響，只是搬遷過程中的KEY不能刪除，但這個(gè)過程只有數(shù)秒時(shí)間，業(yè)務(wù)基本無感知。

運(yùn)維擺脫了設(shè)備擴(kuò)容的人海戰(zhàn)術(shù)后，就像特種部隊(duì)一樣，把精力聚焦到有價(jià)值的工作中，譬如業(yè)務(wù)架構(gòu)評(píng)審、資源評(píng)估和規(guī)劃，壓測(cè)及演習(xí)、應(yīng)急預(yù)案、監(jiān)控等等和業(yè)務(wù)相關(guān)的事情,這是業(yè)務(wù)運(yùn)維應(yīng)該更關(guān)注的地方。

4.1 紅包容量評(píng)估

如何評(píng)估活動(dòng)容量？我們會(huì)根據(jù)四個(gè)維度來評(píng)估容量。首先是IDC 的容量，像電力、機(jī)柜、專線的容量等等。以服務(wù)器為維度，會(huì)關(guān)注四個(gè)核心指標(biāo)，CPU、網(wǎng)絡(luò)的磁盤IO、網(wǎng)卡流量、網(wǎng)卡包量，判斷這個(gè)設(shè)備的整體容量水平。這是基礎(chǔ)的維度。

業(yè)務(wù)這邊，我們會(huì)有業(yè)務(wù)維度的評(píng)估，譬如紅包業(yè)務(wù)的每秒紅包容量。根據(jù)設(shè)備的能力來推導(dǎo)出業(yè)務(wù)容量的水平，譬如模塊單機(jī)能抗3千個(gè) QPS，假設(shè)模塊下有一百臺(tái)設(shè)備，那么該模塊的 QPS 就能支撐30萬 QPS，并且這個(gè)容量負(fù)載必須是線性的增長。

容量完成擴(kuò)容前后，我們會(huì)多次對(duì)模塊和業(yè)務(wù)進(jìn)行壓測(cè)，來評(píng)估容量基準(zhǔn)值，擴(kuò)容之后的水位能否支持到業(yè)務(wù)高峰。

我們通過演習(xí)的方式來模擬實(shí)際的用戶請(qǐng)求。

我們的業(yè)務(wù)是多地部署的，譬如 QQ 是分布到深圳、上海和天津三地。那么，我們把全國流量調(diào)度到其中一地，譬如深圳，觀察容量、延遲等指標(biāo)，因?yàn)槲覀儤I(yè)務(wù)關(guān)鍵鏈路會(huì)有幾十個(gè)模塊，在這個(gè)過程中，有些模塊如果有問題會(huì)出現(xiàn)異?；蚋婢热缯f有些模塊 CPU 會(huì)過熱，會(huì)上到 80%-90% 的高水位，或者失敗率開始增加。業(yè)務(wù)會(huì)根據(jù)這些模塊的容量，根據(jù)高負(fù)荷的模塊做一些性能的優(yōu)化或擴(kuò)容。保證這些模塊負(fù)載都是合理范圍。

第二部分是線上灰度，我們會(huì)逐漸放開搶紅包的活動(dòng)，譬如對(duì)華南區(qū)域的用戶放開”刷一刷紅包”的入口，用戶有提示先去刷，刷的時(shí)候發(fā)現(xiàn)這個(gè)產(chǎn)品的測(cè)試是否符合預(yù)期，關(guān)鍵模塊的容量是不是達(dá)到我們的標(biāo)準(zhǔn)。我們會(huì)有灰度逐步放量，最后全部放量。還有一個(gè)小年夜的多時(shí)段，比如說在晚上定點(diǎn)來分別放開”刷一刷”這個(gè)活動(dòng)的流量。

這是有一個(gè)壓測(cè)出問題的例子，我們?cè)趬簻y(cè)的時(shí)候發(fā)現(xiàn)有一些存儲(chǔ)機(jī)的網(wǎng)卡流量被壓爆了，這是一臺(tái)網(wǎng)卡流量的巔峰，平時(shí)是 200-300Mb 的水平，到了壓測(cè)的時(shí)候壓滿 1Gb 的帶寬。我們分析發(fā)現(xiàn)，這個(gè)是存儲(chǔ)器上有熱 KEY，然后我們根據(jù)壓測(cè)出的情況繼續(xù)推動(dòng)各種優(yōu)化。

演習(xí)不僅能驗(yàn)證單個(gè)業(yè)務(wù)，還能驗(yàn)證多個(gè)業(yè)務(wù)的實(shí)際支撐能力。譬如QQ、空間、相冊(cè)和廣點(diǎn)通等業(yè)務(wù)關(guān)聯(lián)性非常強(qiáng)，幾大業(yè)務(wù)通過聯(lián)合演習(xí)來評(píng)估大活動(dòng)峰值的支撐水平。

因?yàn)楹诵闹Ц断到y(tǒng)在深圳，為了減少深圳IDC壓力，我們還主動(dòng)把非春節(jié)業(yè)務(wù)，如音樂等調(diào)度到上海，降低深圳IDC和網(wǎng)絡(luò)的水位。

業(yè)務(wù)策略多變，之前評(píng)估供給的設(shè)備不一定能滿足實(shí)際產(chǎn)品指標(biāo)，因此我們還做了業(yè)務(wù)錯(cuò)峰部署，在一批服務(wù)器上同時(shí)部署了紅包和空間的服務(wù)，一臺(tái)機(jī)器會(huì)部署兩套服務(wù)。在紅包活動(dòng)時(shí)這些設(shè)備用于紅包活動(dòng)，紅包活動(dòng)結(jié)束后，通過調(diào)度快速把機(jī)器調(diào)度到空間服務(wù)進(jìn)程上，這樣錯(cuò)峰來重用服務(wù)器計(jì)算資源。

大家可能會(huì)覺得這種切換風(fēng)險(xiǎn)比較高，后來經(jīng)過我們的驗(yàn)證，我們的調(diào)度能力還是確保這些多設(shè)備的復(fù)用達(dá)到我們的預(yù)期。我們通過技術(shù)的方式來做，即可以做到業(yè)務(wù)錯(cuò)峰，也可以進(jìn)行擴(kuò)容。

在活動(dòng)過程中還有很多服務(wù)故障，我們還需要對(duì)服務(wù)的柔性做一些測(cè)驗(yàn)。我把我們”刷一刷紅包”分層，針對(duì)每個(gè)層出現(xiàn)的問題做一切特殊的過載保護(hù)。比如說QQ用戶，如果8點(diǎn)準(zhǔn)點(diǎn)開放給用戶，同時(shí)會(huì)有2億的用戶涌入這個(gè)架構(gòu)，系統(tǒng)的峰值會(huì)非常高。

在用戶層我們做了錯(cuò)峰的開放，譬如在20：00到05分把用戶隨機(jī)放進(jìn)來，把請(qǐng)求隨機(jī)分布在300秒?yún)^(qū)間。

如果接入層這邊出現(xiàn)容量和負(fù)載過高，我們會(huì)在這里隨機(jī)丟棄一些請(qǐng)求，根據(jù)用戶UIN的HASH進(jìn)行隨機(jī)丟包。

如果是銀行這邊的接口出現(xiàn)瓶頸，我們會(huì)降低現(xiàn)金的的派發(fā)速度等等。消息系統(tǒng)出現(xiàn)瓶頸，我們會(huì)設(shè)置一定比例的用戶不發(fā)送消息。每一個(gè)層都會(huì)跟研發(fā)一起考慮這個(gè)容量出現(xiàn)問題的時(shí)候怎么做柔性保護(hù)。

這是我們運(yùn)維這邊一鍵下發(fā)屬性的界面（見PPT），我們可以選擇不同的模塊，然后選擇柔性的配置表，通過一鍵下發(fā)的方式將柔性策略實(shí)時(shí)下發(fā)，并實(shí)時(shí)生效。

前面的擴(kuò)容、壓測(cè)和應(yīng)急預(yù)案等已經(jīng)做完了，到了春節(jié)活動(dòng)現(xiàn)場(chǎng)，運(yùn)維主要有三類工作，一是看現(xiàn)場(chǎng)視圖，二是擴(kuò)容過熱模塊，三是處理熱KEY。

有些業(yè)務(wù)模塊，通過壓測(cè)手段是沒有辦法模擬現(xiàn)網(wǎng)的，在現(xiàn)網(wǎng)情況下會(huì)出現(xiàn)容量超過閾值的情況。運(yùn)維會(huì)通過視圖或告警快速發(fā)現(xiàn)，經(jīng)過簡(jiǎn)單評(píng)估后從備用資源池中緊急提取設(shè)備，對(duì)模塊進(jìn)行擴(kuò)容，把容量負(fù)載降到正常水位。

這是大年30運(yùn)維部門的現(xiàn)場(chǎng)（見PPT），大家都在看視圖和快速擴(kuò)容模塊，這是我們運(yùn)維主要做的事情。

上圖是織云的運(yùn)維核心視圖（見PPT），可以看到集成了各業(yè)務(wù)核心視圖，包括紅包大盤、紅包相關(guān)模塊告警，QQ 核心模塊容量，紅包視圖等等，運(yùn)維主要是看這些視圖，看告警來保證活動(dòng)是正常的。

數(shù)據(jù)存儲(chǔ)在活動(dòng)高峰面臨的挑戰(zhàn)之一是熱 KEY。即某一些熱點(diǎn)記錄的訪問量過大，高峰期甚至上漲百倍。

我們有幾種常用方法來處理熱KEY。首先是拆記錄，比如說這個(gè)記錄的訪問量非常大，每秒有十幾萬，我們會(huì)把 KEY 的 Value 分拆成多份，分布到不同的表實(shí)例。

其二是限制記錄的長度，有些 KEY 的 Value 很長，在熱點(diǎn)訪問時(shí)會(huì)給存儲(chǔ)機(jī)內(nèi)存拷貝、網(wǎng)卡造成壓力。我們會(huì)查找出過長的 KEY-Value，讓業(yè)務(wù)通過字段壓縮、刪除冗余字段等方式來減少記錄長度。

第三是把千兆的存儲(chǔ)機(jī)換成萬兆的存儲(chǔ)機(jī)，讓網(wǎng)卡流量突破1Gb限制，在現(xiàn)網(wǎng)萬兆存儲(chǔ)機(jī)能跑到 5-6Gb 的水平。

第四是記錄打散，快速通過搬遷方式，把集中的熱點(diǎn) KEY 分布到十幾臺(tái)存儲(chǔ)機(jī)來支撐。

最后，業(yè)務(wù)在前端可能會(huì)有幾十臺(tái)邏輯設(shè)備，業(yè)務(wù)可在邏輯設(shè)備上用內(nèi)存做前端緩存，減少對(duì)后端存儲(chǔ)機(jī)的訪問。

回顧整個(gè)紅包的活動(dòng)策略，萬臺(tái)級(jí)設(shè)備擴(kuò)容僅用了2天時(shí)間，極大解救了運(yùn)維。運(yùn)維從擴(kuò)縮容的工作量中解脫出來后，可以把更多的時(shí)間和精力更深入理解業(yè)務(wù)，為業(yè)務(wù)在質(zhì)量、成本和速度幾個(gè)方面給用戶提供更多的價(jià)值，為業(yè)務(wù)保駕護(hù)航。

騰訊云運(yùn)維干貨沙龍-海量運(yùn)維實(shí)踐大曝光 （一）

騰訊云運(yùn)維干貨沙龍-海量運(yùn)維實(shí)踐大曝光 （二）

https://share.weiyun.com/5c406a57164ed4cf7e248160aebf74c3