從鹿晗戀愛事件看運維的節假日準備工作

GIF/14K

最近運維的朋友圈流傳著一張圖

發生了什麼？

原來

鹿晗關曉彤公布戀情後 微博竟崩潰了…

鹿晗關曉彤公布戀情，微博再次宕機，相關的運維們也不得不提前結束國慶假期，執行各種緊急擴容預案。而騰訊SNG社交平台運維團隊歷經數次億級熱點活動，如「春節紅包」 「 軍裝照P圖」，那麼，他們又是如何應對每次的服務保障呢？讓我們一起走進支撐這背後的強大運維體系。

前言

又是一年國慶，針對「熱點事件」 「節日」 等的運營活動往往是眾多互聯網產品的兵家必爭之地。近年來，隨著眾多業務複雜性逐步上升，運營設備量逐步增多，對運維的要求也逐步上升。

那麼，成熟的運維體系對於海量業務的穩固運營也就至關重要。除此之外，騰訊的業務運維團隊通常會從業務準備，容量評估，資源準備，擴容與壓測四個階段著手，配合熱點應急機制，提前一個月進行節日保障準備。

節假日保障

由於社交平台部產品眾多，包含空間、微雲、相冊、P圖等，業務運維團隊一般會提前一個月進行節日準備，一般會包含以下幾個階段：

1) 業務準備

指標搜集

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

柔性準備

柔性是以應對大量業務量衝擊時，以降低業務體驗為代價而實施的一系列運維策略，如在業務高峰期降低客戶端拉取後端數據的頻率，從而減少對後端的衝擊。

2) 容量評估

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

反向評估： 結合業務上漲量倍數與當前單負載，計算出擴容的設備數量

公式為:擴容設備量 = （業務上漲倍數*當前單機負載*設備數量）/ 目標負載 – 當前設備量。

例如： 當前模塊有10台設備，單機負載40%，目標負載80%， 業務量需要上漲3倍，需要擴容的設備量為： (3*40%*10)/80% - 10 = 5台。

正向評估：需要有明確的高峰期交易量和單機承載指標。

公式為:擴容設備量 = (高峰期交易量 / 單機負載) – 當前設備量。

例如： 業務高峰期交易量為 8萬/秒，單機最承載5千/秒，當前模塊10 台設備，需要擴容的設備量為： 80000/5000 - 10 = 6台。

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

3) 資源準備

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

織雲設備供給平台依託強力的織雲IaaS介面對業務設備進行分配，上層業務只需選擇對應地域、機房、機型，即可提供kvm，實體機，docker機型。分配過程對業務透明。

4) 擴容與壓測

如前文所述，模塊非常規範的情況下，織雲能對其進行半自動/全自動擴縮容。擴容後進行壓測，進一步確認是否能達到業務上漲的需求。

業務壓測

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

單機壓測

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

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

熱點應急機制

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

節假日的運維準備工作，以上並不是全部，這背後還需要成熟的運維體系來支撐。

運維體系構成

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

技術運營團隊組織架構

組織架構在隨著業務形態在不斷地演變，一般來說，互聯網公司的組織架構演變會經歷過幾個轉變期：

1）小團隊混合期

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

2）DO分離初期

此階段運維開始從開發中分離出來，負責所有運維工作，如設備資源、環境、運維工具體系建設等。

團隊趨於扁平，但人員分工相對不明確。既管理機房、資源，又要管理運維工具、解決現網業務問題。隨著業務的複雜性進一步增大，伴隨人員流動性等問題，團隊難以應對技術多樣化場景，容易因為技術框架不統一而導致運維效率低下、組織運作混亂。從而對團隊分工演進提出了更深的要求。

3）運維團隊模塊化、職業化

運維團隊到了一定的規模後，運維設備數量達到數以萬計或十萬計，整體架構會分散自治，運維團隊的分工因此需要更加細緻明確。

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

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

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

因為無狀態組件是水平可伸縮的，短暫單機故障並不會引起服務不可用，所以對業務服務SLA要求較低。該團隊負責整個無狀態服務框架及基於其承載的服務的運維工作。

而由於有狀態服務保存了業務數據，一般會對業務服務SLA要求較高，在單機故障時甚至需要運維及時介入檢查或操作。

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

3）業務運維團隊– 負責業務的整體運維，包括業務規劃、架構部署、容災演練、節假日保障等整體協作性工作。

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

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

運維規範

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

傳統行業的運維規範相對較為嚴格，包含以下內容：

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

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

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

其他運維規範

而在互聯網行業，過於僵硬的規範不易於滿足快速迭代的業務需求，所以平時更需要關注現網運行規範，如織雲體系中的幾個常見規範：

1）設備模塊化、SET化管理理念

依據微服務的差異，將設備劃分到不同的模塊，多個模塊可組成一個SET。這是織雲管理設備的理念。

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

2）統一的包管理規範

統一的包安裝、卸載、啟停腳本名稱，統一的配置文件管理（版本管理、創建、發放等）機制，以便上層管理系統能夠統一對其進行管理。

3）名字服務接入

業務間調用時，所有被調方IP對業務透明，只需要知道名字服務ID，而對被調方擴縮容時只需要通過名字服務管理系統管理名字服務後端的IP即可。杜絕IP寫死在代碼中或寫死在配置文件中的現象。

4）程序開發規範

這裡的開發規範不是指代碼規範，而是指通過一定時間的積累，形成的程序邏輯規範，以典型的無狀態組件為例，我們從程序邏輯中剝離出來一套框架，框架上實現微線程處理、網路通信、監控等功能，而開發人員只需要根據業務邏輯開發 so 進行掛接即可。

運維工具體系架構

從而需要有一整套機制來規範，運維工具體系對規範進行支撐，總的來說，運維工具體系可以分為以下幾個方面：支撐平台、監控、管理體系，我們統稱為織雲體系。

1） 支撐平台：

所有自動化工作開展的基石，運維體系中不可缺少的部分，包含但不限於以下組件：

CMDB配置管理平台，管理設備信息與模塊屬性、人員與被管設備/模塊間運維關係，基本配置信息等。

自動化命令通道等，提供底層API在大批伺服器上執行命令。

基礎設施監控平台，如：基礎設施運營事件發布、機房設施、伺服器性能、故障監控系統等。

2） 監控系統

主動監控：一般採用從組件框架或業務代碼埋點，或採用部署探針形式，上報業務數據到監控系統，監控系統進行集中監控。如：業務模塊間調用監控、終端APM監控、手機命令字監控等。

被動監控：比較典型的是撥測系統，從內外網模擬客戶端訪問業務，對業務進行速度或成功率等測試，測試數據集中上報表監控系統，集中進行處理和監控。

旁路監控：在不接觸業務本身的情況下對業務進行監控，比較典型的是輿情監控，對外網的輿情進行搜集，進行統一監控。

一切監控的基礎是數據，但細粒度數據顯然不可能直接讓運維人員使用，基於以上數據產生的織雲監控體系產品如：多維監控、日誌監控、全鏈路監控系統，都是一些非常重要的監控產品。

3） 標準化管理體系

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

a)標準化：

模塊管理： 功能粒度上對伺服器打散，形成許多獨立的模塊，每一個模塊有自己的自治體系。

包管理，配置管理：規範開發人員按照標準來進行開發業務包。統一的包安裝、卸載、啟停、方法。集中式配置文件管理方法等。

標準化組件管控- 名字服務、容錯體系、存儲層（內存型、TSSD、硬碟）等基礎服務的管控工具。

b)容量管理：

一系列的容量評估體系，支撐運維人員快速評估容量。為資源規劃提供支撐，合理保障活動資源。

高低負載管理，擴縮容、單機負載權重調整、調度等。

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

後記

海量業務穩定運營的背後，一定有一套成熟的運維體系，需要從組織、規範、工具上進行不斷演進、持續積累，才能在節（sa）假 (gou）日（liang）準備時有條不紊，做到有備而戰，從而做到「高效運維」。

作者丨李雄政：10年+ 證券、電信、互聯網領域開發、系統集成、運維經驗。 現任騰訊高級工程師，負責社交平台業務運維組管理工作。

歡迎關注騰訊織雲，獲取最新技術資訊

END

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 高效運維 的精彩文章: