從鹿晗關曉彤戀情事件看運維的節假日準備工做

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

導語：鹿晗關曉彤公佈戀情，形成微博服務短暫不可用。相關的運維們也不得不提早結束國慶假期，執行各類緊急擴容預案。 而騰訊SNG社交平臺運維團隊歷經數次億級熱點活動，如「春節紅包」 「 軍裝照P圖」，他們又是如何應對每次的服務保障呢？

前言

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

那麼，面對這種突如其來的花式秀恩愛熱點，做爲運維的咱們，該如何提早預防呢？騰訊的業務運維團隊一般會從業務準備，容量評估，資源準備，擴容與壓測四個階段着手，配合熱點應急機制，提早一個月進行節日保障準備。固然，還有對於海量業務的穩固運營相當重要的成熟的運維體系。這一切互相配合，最大化地保障節假日的運維工做有條不紊。

節假日保障

因爲社交平臺部產品衆多，包含空間、微雲、相冊、P圖等，業務運維團隊通常會提早一個月進行節日準備，通常會包含如下幾個階段：

1) 業務準備

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

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

2) 容量評估

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

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

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

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

3) 資源準備

評估的設備量提交資源團隊進行準備。通常設備量不大的狀況下會利用存量資源知足，反之則須要提早進行採購備貨。

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

4) 擴容與壓測

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

業務壓測
一般業務多地SET化部署，每地各有一條讀訪問鏈，咱們能夠經過前端調度，將業務調度到單地SET，以評估單地SET的支撐能力。

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

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

熱點應急機制

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

節假日的運維準備工做，以上並非所有，這背後還須要成熟的運維體系來支撐。

運維體系構成

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

技術運營團隊組織架構

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

1）小團隊混合期
通常在組織相對較小的時候，開發人員即運維人員。此階段通常出如今10人如下的團隊，但因爲開發要兼作運維工做， 隨着人員、業務的增加，容易形成組織混亂、團隊效率、故障風險不可控等問題。

2）DO分離初期
此階段運維開始從開發中分離出來，負責全部運維工做，如設備資源、環境、運維工具體系建設等。團隊趨於扁平，但人員分工相對不明確。既管理機房、資源，又要管理運維工具、解決現網業務問題。隨着業務的複雜性進一步增大，伴隨人員流動性等問題，團隊難以應對技術多樣化場景，容易由於技術框架不統一而致使運維效率低下、組織運做混亂。從而對團隊分工演進提出了更深的要求。

3）運維團隊模塊化、職業化
運維團隊到了必定的規模後，運維設備數量達到數以萬計或十萬計，總體架構會分散自治，運維團隊的分工所以須要更加細緻明確。

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

• 資源職能團隊 - 負責設備資源採購、機房管理（或雲上資源管理）、 操做系統層及如下的管理，跨部門運做以保障資源的調度及供應能力。
• 組件運維團隊 – 負責各自的組件運維， 通常根據人員技能要求、組件響應SLA要求，能夠劃分紅有狀態(stateful)組件團隊和無狀態(stateless)組件團隊。

由於無狀態組件是水平可伸縮的，短暫單機故障並不會引發服務不可用，因此對業務服務SLA要求較低。該團隊負責整個無狀態服務框架及基於其承載的服務的運維工做。而因爲有狀態服務保存了業務數據，通常會對業務服務SLA要求較高，在單機故障時甚至須要運維及時介入檢查或操做。

固然隨着大型業務架構演進，自動化的加強，存儲層實現故障自愈，咱們的業務也實現多地部署，總體業務或模塊粒度可進行多地切換容災。內存型業務的服務SLA也能夠相對放鬆，在這裏先不細述。

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

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

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

運維規範

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

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

• 運維操做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）準備時有條不紊，作到有備而戰，從而作到「高效運維」。

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

在本文的運維體系下，騰訊SNG社交平臺運維團隊又是運用了何種技術來保障節假日服務的？ 點擊下文閱讀。↓↓↓

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