新浪微博平臺自動化運維演進之路

內容來源：2016年12月16日，微博產品資深運維架構師王關勝在「GIAC全球互聯網架構大會」進行《新浪微博平臺自動化運維演進之路》演講分享。IT大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。
閱讀字數: 2557 用時: 4分鐘

摘要

新浪微博是一個由新浪網推出，提供微型博客服務類的社交網站。用戶能夠經過網頁、WAP頁面、手機客戶端、手機短信、彩信發佈消息或上傳圖片，是當下中國最火熱的社交APP。微博產品資深運維架構師王關勝給咱們分享新浪微博平臺自動化運維演進之路。

嘉賓演講視頻

Sina Weibo業務介紹

微博業務簡介

微博平臺是屬於偏後端的一個產品，它所提供的服務就是固定量的接口，好比信息流裏的接口、用戶接口、關係接口等等。

微博核心業務

微博最核心的產品就是信息流，以信息流爲中心出發，它周邊的用戶、關係以及通知等主路徑的服務都在內部平臺，屬於核心服務。

微博業務部署結構

咱們對於核心業務要求多機房部署，電信和聯通機房都部署了完整的鏈路。

服務保障——服務治理（開發主導）

在這樣一個複雜的架構下，運維和開發須要緊密配合。咱們內部組織架構調整後，運維團隊屬於開發團隊，配合起來就很是緊密。

內部分爲了兩個方向。第一個方向的部分是開發主導，運維參與。好比創建完善的SLA體系，咱們這個SLA體系作在應用層上，從開發和運維層面在代碼上作一些改造，在數據層面上作收集。降級/封禁也是類似的方法，開發在代碼上作降級/封禁的入口，具體提供的功能和平臺是在運維作的系統裏。

服務保障——防護體系（運維主導）

第二個方向就是由運維全程主導，開發參與。例如容量、監控、干預還有運維的部署架構。

架構要作到極簡、穩健、美麗；

監控要求具備實時性，報警快、準，覆蓋全面；

容量的性能要好，冗餘足夠，能快速動態擴容，有壓測、容量預警；

干預的預案要全，手段多，操做快速，方案細緻，要作到干預行之有效。

總體的防護體系要由標準化轉化爲可視化、自動化，最後升級到智能化。

微博平臺運維進化歷程

微博平臺的運維進化歷程大概分紅四個階段。

最先是人工階段，全部的腳本都要依賴於人工，也就是所謂的腳本時代；

第二階段是工具系統。當規模有必定的成長以後，作到了工具系統化和運維標準化；

下一個階段就是綜合運維平臺。要把不少運維繫統作成一個運維平臺，就須要讓系統平臺化、數據API化和運維服務化；

目前咱們比較推崇的是利用混合雲DCP的思路來作一些系統。

百臺規模運維標準化

百臺規模——一切皆需求

這個階段主要的工做就是平常的需求對接、完善監控警報、代碼的發佈和回滾、還有服務的擴縮容以及以前的一些配管工具。

這些工做都要作到快速迭代、快速上線、快速響應。

百臺規模——需求達成

當時只須要利用Python、Perl、Shell等去寫各類腳本，平常的需求基本都能達成。

咱們也在研究一些開源的工具。當時在業務部署的層面最開始是用腳本，後來發現腳本比較麻煩，就改用配管。

百臺規模——標準化梳理

配管是該階段比較核心的內容，需求通過抽象可分爲三類，機器上的基礎配置、機房相關和業務相關。

全部配置要能經過標準化的配管工具管理起來，每一類服務都進行標準化梳理，就能達到咱們這個階段的目標了。

百臺規模——CMDB&配管

新浪在不少部門都會用到Puppet來作配置管理工做。咱們當時借鑑了這樣一套配管工具，把全部能經過Puppet作的需求在標準化以後儘可能用到Puppet。這樣就能基本上知足那個階段的需求。

百臺規模——配管UI化

在三大需求之上，咱們也給Puppet作了完善管理的UI。與Puppet相關全部配置的需求再也不須要經過手工管理，直接UI化，就能夠在頁面上修改配置，把配置管理起來，再經過Puppet的API下發。知足了當時的需求。

千臺規模平臺化&可視化

千臺規模——挑戰性加大

咱們面臨了不少的挑戰：服務器規模線性增加；業務單元線性增加；系統變動及代碼上線次數線性增加；大型運營活動及三節保障；每日不定時段的PUSH。因此要作一些工具來知足需求。

但同時也出現了人力成本線性增加、差別化加重致使認知成本線性增加的問題。

千臺規模——構建運維平臺

咱們當時內部作了一套比較完善的運維管理系統Jpool。它是一個通用的集羣管理平臺，核心模塊包含了用戶權限、資源管理、配置管理、部署管理、任務管理、Nginx變動管理、降級/封殺管理和日誌查詢平臺。

Dispatch和Puppet Master組成了這個平臺裏最核心的部分。Puppet Master管理了配管方面，Dispatch是一個分佈式的命令通道。

千臺規模——運維平臺Joopl框架

千臺規模——Joopl核心組件

Dispatch是一個分佈式任務調度引擎。在Dispatch裏有三大任務線程，任務處理線程、與agent鏈接的通訊協議層及通訊線程和主線程。

千臺規模——統一運維平臺

整合工單流程變動、統一配管系統、統一負載均衡系統、持續集成和監控報警系統這些工具系統，造成完整的運維平臺。

平臺建成後還能在上面作一些平常的變動手段，例如Puppet/Nginx變動、服務的部署變動、服務降級/封禁、擴容/縮容以及業務docker化。還有其它的像流量切換、限流、數據修復等等都是能夠在運維平臺上完成的。

萬臺規模自動化&智能化

萬臺規模——面臨的核心挑戰

針對一些突發的娛樂事件，咱們須要有峯值應對才能保證服務的穩定。

在這個階段咱們要設置混合雲系統，主要從四個點出發。

最核心的是峯值應對，能夠進行快速擴容，及時回收；

其次是成本優化，可伸縮的業務利用公有云，私有云的內部進行彈性部署；

打通多語言環境，全公司統一平臺，作到運維統一化；

業務快速迭代，基礎設施標準化，提升發佈效率。

萬臺規模——峯值應對——混合雲DCP

峯值應對：目標「無人值守」的擴縮容

因爲近幾年突發的爆炸性事件增多，因此咱們要作到擴縮容「無人值守」。

基於運維自動化之上再作「無人值守」就須要各類各樣的業務指標，而咱們的監控能夠收集全部的業務指標。有了詳細指標就能夠作到「無人值守」。

總結：自動化核心——任務調度引擎

一個產品要想發展壯大，必須得有一套完整的任務通道。利用任務通道把全部運維相關的操做抽象爲標準化的操做庫，加上流程引擎，而後再作統一的任務編排。

有了這四大核心內容，再作平臺或自動化思路就比較方便了。

今天要分享的就是這些，謝謝你們！

相關推薦

• XpmJS —— 小程序後端開發思考和實踐
  

• 魅族推薦平臺架構
  

近期活動

• 活動 | 區塊鏈技術如何改變咱們的生活
  

• 活動 | 一塊兒出發，吹響Container+的號角
  

原文地址：t.cn/R9frEKf