摘要：導語鹿晗關曉彤公布戀情，造成微博服務短暫不可用。業(yè)務運維團隊負責業(yè)務的整體運維，包括業(yè)務規(guī)劃架構部署容災演練節(jié)假日保障等整體協(xié)作性工作。

作者：李雄政，10年+ 證券、電信、互聯(lián)網(wǎng)領域開發(fā)、系統(tǒng)集成、運維經驗。 現(xiàn)任騰訊高級工程師，負責社交平臺業(yè)務運維組管理工作。
導語：鹿晗關曉彤公布戀情，造成微博服務短暫不可用。相關的運維們也不得不提前結束國慶假期，執(zhí)行各種緊急擴容預案。 而騰訊SNG社交平臺運維團隊歷經數(shù)次億級熱點活動，如“春節(jié)紅包” “ 軍裝照P圖”，他們又是如何應對每次的服務保障呢？

又是一年國慶，10月8日12點，鹿晗在微博公布與關曉彤戀情，截至當日14:50, 該微博共收獲462,884次轉發(fā)、986,409條評論，2,566,617個點贊。造成微博服務短暫不可用。作為運維同行，對此深表同情和理解。

那么，面對這種突如其來的花式秀恩愛熱點，作為運維的我們，該如何提前預防呢？騰訊的業(yè)務運維團隊通常會從業(yè)務準備，容量評估，資源準備，擴容與壓測四個階段著手，配合熱點應急機制，提前一個月進行節(jié)日保障準備。當然，還有對于海量業(yè)務的穩(wěn)固運營至關重要的成熟的運維體系。這一切互相配合，最大化地保障節(jié)假日的運維工作有條不紊。

由于社交平臺部產品眾多，包含空間、微云、相冊、P圖等，業(yè)務運維團隊一般會提前一個月進行節(jié)日準備，一般會包含以下幾個階段：

指標搜集
由業(yè)務運維團隊牽頭對產品進行梳理，由產品團隊提供產品技術指標，如某功能上漲多少的業(yè)務量。這些業(yè)務產品團隊的輸入作為擴容需求的原始輸入。

柔性準備
柔性是以應對大量業(yè)務量沖擊時，以降低業(yè)務體驗為代價而實施的一系列運維策略，如在業(yè)務高峰期降低客戶端拉取后端數(shù)據(jù)的頻率，從而減少對后端的沖擊。

業(yè)務運維與相關開發(fā)進行業(yè)務指標 與業(yè)務模塊對應關系適配，進一步評估設備量，通常評估模塊設備量有以下幾種辦法：

反向評估： 結合業(yè)務上漲量倍數(shù)與當前單負載，計算出擴容的設備數(shù)量
公式為:擴容設備量 = （業(yè)務上漲倍數(shù)當前單機負載設備數(shù)量）/ 目標負載 – 當前設備量。
例如： 當前模塊有10臺設備，單機負載40%，目標負載80%， 業(yè)務量需要上漲3倍，需要擴容的設備量為： (340%10)/80% - 10 = 5臺。

正向評估：需要有明確的高峰期交易量和單機承載指標。
公式為:擴容設備量 = (高峰期交易量 / 單機負載) – 當前設備量。
例如： 業(yè)務高峰期交易量為 8萬/秒，單機最承載5千/秒，當前模塊10 臺設備，需要擴容的設備量為： 80000/5000 - 10 = 6臺。

隨著經驗不斷完善，自動容量評估工具也在不斷建設與完善中。

評估的設備量提交資源團隊進行準備。一般設備量不大的情況下會利用存量資源滿足，反之則需要提前進行采購備貨。

織云設備供給平臺依托強力的織云IaaS接口對業(yè)務設備進行分配，上層業(yè)務只需選擇對應地域、機房、機型，即可提供kvm，實體機，docker機型。分配過程對業(yè)務透明。

如前文所述，模塊非常規(guī)范的情況下，織云能對其進行半自動/全自動擴縮容。擴容后進行壓測，進一步確認是否能達到業(yè)務上漲的需求。

業(yè)務壓測
通常業(yè)務多地SET化部署，每地各有一條讀訪問鏈，我們可以通過前端調度，將業(yè)務調度到單地SET，以評估單地SET的支撐能力。

單機壓測
通過名字服務，將流量逐步調度到某一臺機器，測量單機的業(yè)務支撐能力。從而推導模塊設備能否支撐業(yè)務量。

擴容完成后，如果仍然存在短板，則重新補齊后進行壓測。對于不可預見的突發(fā)熱點，又該如何來保障業(yè)務呢？下面給大家介紹下突發(fā)熱點容量管控機制。

節(jié)假日難免會有一些突發(fā)的事件產生，如前所述，基于織云標準，我們的模塊非常容易伸縮，可借助織云托管功能進行服務托管，模塊出現(xiàn)容量緊缺時，提前進行自動擴容干預。如果由于資源等問題，自動擴容無法解決問題，可由運維啟動柔性機制，保障業(yè)務可用。

節(jié)假日的運維準備工作，以上并不是全部，這背后還需要成熟的運維體系來支撐。

一個成熟的運維體系通常包括三個部分：人員組織、工具體系和技術規(guī)范。三者隨著業(yè)務的擴張而日益成熟。從組織上保障人員技能專業(yè)度與服務質量成熟度，良好的規(guī)范約束為組織協(xié)同、工具自動化提供了基礎；工具解放生產力，提升運維效率，使人員成長更為專業(yè)。

組織架構在隨著業(yè)務形態(tài)在不斷地演變，一般來說，互聯(lián)網(wǎng)公司的組織架構演變會經歷過幾個轉變期：

1）小團隊混合期
一般在組織相對較小的時候，開發(fā)人員即運維人員。此階段一般出現(xiàn)在10人以下的團隊，但由于開發(fā)要兼做運維工作， 隨著人員、業(yè)務的增長，容易造成組織混亂、團隊效率、故障風險不可控等問題。

2）DO分離初期
此階段運維開始從開發(fā)中分離出來，負責所有運維工作，如設備資源、環(huán)境、運維工具體系建設等。團隊趨于扁平，但人員分工相對不明確。既管理機房、資源，又要管理運維工具、解決現(xiàn)網(wǎng)業(yè)務問題。隨著業(yè)務的復雜性進一步增大，伴隨人員流動性等問題，團隊難以應對技術多樣化場景，容易因為技術框架不統(tǒng)一而導致運維效率低下、組織運作混亂。從而對團隊分工演進提出了更深的要求。

3）運維團隊模塊化、職業(yè)化
運維團隊到了一定的規(guī)模后，運維設備數(shù)量達到數(shù)以萬計或十萬計，整體架構會分散自治，運維團隊的分工因此需要更加細致明確。

團隊分工沒有標準或準則，典型的分工可能是這樣的：

資源職能團隊 - 負責設備資源采購、機房管理（或云上資源管理）、 操作系統(tǒng)層及以下的管理，跨部門運作以保障資源的調度及供應能力。

組件運維團隊 – 負責各自的組件運維， 一般根據(jù)人員技能要求、組件響應SLA要求，可以劃分成有狀態(tài)(stateful)組件團隊和無狀態(tài)(stateless)組件團隊。

因為無狀態(tài)組件是水平可伸縮的，短暫單機故障并不會引起服務不可用，所以對業(yè)務服務SLA要求較低。該團隊負責整個無狀態(tài)服務框架及基于其承載的服務的運維工作。而由于有狀態(tài)服務保存了業(yè)務數(shù)據(jù)，一般會對業(yè)務服務SLA要求較高，在單機故障時甚至需要運維及時介入檢查或操作。

當然隨著大型業(yè)務架構演進，自動化的增強，存儲層實現(xiàn)故障自愈，我們的業(yè)務也實現(xiàn)多地部署，整體業(yè)務或模塊粒度可進行多地切換容災。內存型業(yè)務的服務SLA也可以相對放松，在這里先不細述。

業(yè)務運維團隊 – 負責業(yè)務的整體運維，包括業(yè)務規(guī)劃、架構部署、容災演練、節(jié)假日保障等整體協(xié)作性工作。

比如業(yè)務的多地容災部署架構，需要業(yè)務運維團隊來牽頭實施，以項目實施管理的形式將整個項目進行推進，以達到最終保障業(yè)務高可用的目的。

如上圖所示，以上團隊職責相對比較明確，運維工具的開發(fā)與健全貫穿在整個運維工作中，并逐步形成工具體系。

龐大的業(yè)務體系運作，運維團隊不可能隨著業(yè)務的急劇增長而擴張，從而需要有一系列的規(guī)范來保證業(yè)務運維的有序運作。

傳統(tǒng)行業(yè)的運維規(guī)范相對較為嚴格，包含以下內容：

運維操作SOP – 嚴格約定操作的步驟、甚至細化到命令操作等。

流程 – 一般指變更、故障處理的審批、確認流程，比較常見的規(guī)范有ITIL等。

SLA/OLA協(xié)議 – 流程中Milestone點之間的時長或整體時長限制。因故障/變更等級不同而可能有所差異。

其他運維規(guī)范

而在互聯(lián)網(wǎng)行業(yè)，過于僵硬的規(guī)范不易于滿足快速迭代的業(yè)務需求，所以平時更需要關注現(xiàn)網(wǎng)運行規(guī)范，如織云體系中的幾個常見規(guī)范：

1） 設備模塊化、SET化管理理念
依據(jù)微服務的差異，將設備劃分到不同的模塊，多個模塊可組成一個SET。這是織云管理設備的理念。

SET化后，一方面可以將模塊間訪問盡量限制在單地，防止跨城流量穿越而帶來額外的流量開銷，另一方面可以實現(xiàn)跨地域容災，保障業(yè)務高可用。

2） 統(tǒng)一的包管理規(guī)范
統(tǒng)一的包安裝、卸載、啟停腳本名稱，統(tǒng)一的配置文件管理（版本管理、創(chuàng)建、發(fā)放等）機制，以便上層管理系統(tǒng)能夠統(tǒng)一對其進行管理。

3） 名字服務接入
業(yè)務間調用時，所有被調方IP對業(yè)務透明，只需要知道名字服務ID，而對被調方擴縮容時只需要通過名字服務管理系統(tǒng)管理名字服務后端的IP即可。杜絕IP寫死在代碼中或寫死在配置文件中的現(xiàn)象。

4） 程序開發(fā)規(guī)范
這里的開發(fā)規(guī)范不是指代碼規(guī)范，而是指通過一定時間的積累，形成的程序邏輯規(guī)范，以典型的無狀態(tài)組件為例，我們從程序邏輯中剝離出來一套框架，框架上實現(xiàn)微線程處理、網(wǎng)絡通信、監(jiān)控等功能，而開發(fā)人員只需要根據(jù)業(yè)務邏輯開發(fā) so 進行掛接即可。

從而需要有一整套機制來規(guī)范，運維工具體系對規(guī)范進行支撐，總的來說，運維工具體系可以分為以下幾個方面：支撐平臺、監(jiān)控、管理體系，我們統(tǒng)稱為織云體系。

所有自動化工作開展的基石，運維體系中不可缺少的部分，包含但不限于以下組件：
CMDB配置管理平臺，管理設備信息與模塊屬性、人員與被管設備/模塊間運維關系，基本配置信息等。
自動化命令通道等，提供底層API在大批服務器上執(zhí)行命令。
基礎設施監(jiān)控平臺，如：基礎設施運營事件發(fā)布、機房設施、服務器性能、故障監(jiān)控系統(tǒng)等。

主動監(jiān)控：一般采用從組件框架或業(yè)務代碼埋點，或采用部署探針形式，上報業(yè)務數(shù)據(jù)到監(jiān)控系統(tǒng)，監(jiān)控系統(tǒng)進行集中監(jiān)控。如：業(yè)務模塊間調用監(jiān)控、終端APM監(jiān)控、手機命令字監(jiān)控等。
被動監(jiān)控：比較典型的是撥測系統(tǒng)，從內外網(wǎng)模擬客戶端訪問業(yè)務，對業(yè)務進行速度或成功率等測試，測試數(shù)據(jù)集中上報表監(jiān)控系統(tǒng)，集中進行處理和監(jiān)控。
旁路監(jiān)控：在不接觸業(yè)務本身的情況下對業(yè)務進行監(jiān)控，比較典型的是輿情監(jiān)控，對外網(wǎng)的輿情進行搜集，進行統(tǒng)一監(jiān)控。

一切監(jiān)控的基礎是數(shù)據(jù)，但細粒度數(shù)據(jù)顯然不可能直接讓運維人員使用，基于以上數(shù)據(jù)產生的織云監(jiān)控體系產品如： 多維監(jiān)控、日志監(jiān)控、全鏈路監(jiān)控系統(tǒng)，都是一些非常重要的監(jiān)控產品。

支撐運維標準能嚴格執(zhí)行的是一個成熟的管理體系，這個體系包括以下組成部分。

a) 標準化：
模塊管理： 功能粒度上對服務器打散，形成許多獨立的模塊，每一個模塊有自己的自治體系。
包管理，配置管理：規(guī)范開發(fā)人員按照標準來進行開發(fā)業(yè)務包。統(tǒng)一的包安裝、卸載、啟停、方法。集中式配置文件管理方法等。
標準化組件管控 - 名字服務、容錯體系、存儲層（內存型、TSSD、硬盤）等基礎服務的管控工具。

b) 容量管理：
一系列的容量評估體系，支撐運維人員快速評估容量。為資源規(guī)劃提供支撐，合理保障活動資源。
高低負載管理，擴縮容、單機負載權重調整、調度等。

c) 其他支撐工具：
為業(yè)務場景設計的工具, 如：運營事件管理、機房裁撤、智能調度、等工具。

海量業(yè)務穩(wěn)定運營的背后，一定有一套成熟的運維體系，需要從組織、規(guī)范、工具上進行不斷演進、持續(xù)積累，才能在節(jié)（sa）假 (gou）日（liang）準備時有條不紊，做到有備而戰(zhàn)，從而做到“高效運維”。

歡迎關注【騰訊織云】公眾號，獲取最新技術資訊。

在本文的運維體系下，騰訊SNG社交平臺運維團隊又是運用了何種技術來保障節(jié)假日服務的？ 點擊下文閱讀?！?/p>

8億人曬軍裝，背后的運維技術大揭密！