微博現在日活達到了 2 億，微博廣告是微博最重要且穩定的收入來源，沒有之一，所以微博廣告系統的穩定性是我們廣告運維所有工作中的重中之重。
微博廣告的運維主要負責資產管理、服務穩定性維護、故障應急處理以及成本控制等多個責任。
微博廣告運維發展經歷了如下階段：從早期小規模的手工運維到工具化運維，隨著服務器數量的發展，業務模型日漸發展，開發、運營、QA 都參與到產品的生命周期中，我們現在也進入了自動化運維的階段，在新的虛擬化技術、算法技術的驅動下，我們也在朝著 AIOps 的方向努力。
在整個運維過程中，我們遇到了很多痛點，幸福的人生都是一樣的，不幸的人生各有各的不幸，各家的運維都各有各的痛點。
我們的服務器在 3000 臺以上，業務線及輔助資源各種各樣，產品迭代非常快，且依賴關系復雜，流量變更，切換損失不可接受。
在這種情況下，我們面臨資產管理困難、環境不統一、上線難度大、運維成本高的問題。
基于這些問題，微博廣告運維工作主要集中在以下四個方面：
- 運維自動化
- 彈性計算
- 智能監控
-
服務治理
運維自動化
一個健全的自動化運維平臺必須要具備如下幾個功能：
- 基礎監控
- 資源管理
- 事件集中分析
- 配置管理
- 批量運維工具
-
持續集成和發布
基于這些功能和需求，我們廣告運維自主研發了 Kunkka 平臺（微博廣告運維自主研發的自動化運維平臺）、資產管理、自動化上線等運維平臺。
資產管理是基于公司 CMDB（公司級別的資產管理系統）獲取到主機云服務器，針對微博廣告對資源的管理需求自建定制化的資產管理平臺。
配置中心包括服務注冊、服務配置等功能；自動化上線涵蓋了開發在上線過程中所需要的節點和流程。
自主終端是行業變化的功能實現，大家可以通過頁面完成文件或命令下發、日志審計等各種工作。
Kunkka 基于主機和容器，通過 Salt 作為傳輸層進行命令下發，組件層包含開源軟件，操作層將命令頁面化，通過頁面進行日常工作和管理。
這樣的自動化運維平臺基本上滿足了運維的日常操作需求，在 Kunkka 平臺中還有自動擴縮容的功能，我們針對這個功能進行延伸。
在自動擴所容的基礎上，根據時間段，流量進行動態判斷，自動決策的擴所容夠功能。
彈性計算
為什么需要彈性計算
首先，在產品方面，我們的產品線很多，依賴關系比較復雜。
微博廣告相當于一個橋梁，左邊連接的是廣告主，右邊連接的是客戶，需要將廣告主的廣告計劃轉化為用戶的需求，讓用戶看到自己想要看的廣告。
為了滿足兩邊不同的需求，產品的變更和發布非常重要且頻繁。
其次，在運營方面，很多有推廣需求計劃的大型活動都有臨時擴容需要，比如 618 跟雙十一，對于我們而言這兩個活動帶來了很大的沖擊。
在 618 和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實現廣告主廣告計劃的轉化。
在 618 和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實現廣告主廣告計劃的轉化。
傳統的業務運維
按照傳統運維模式，擴容計劃從立項到服務器上線，會經過諸多的流程跟漫長的等待。
從結果上來看，服務器擴容了，而且對傳統項目而言，整體流程都是可控的，這是它的優點。
它的缺點不言而喻，有以下幾點：
首先，它時效性太差，如果按照新浪服務器的采購周期，從審計到上線需要兩個月的流程。兩個月后服務器上線，恐怕剛結婚的明星都已經離婚了，突發事件流量都已經過去了。
另外，它無法準確預估容量，在傳統的業務運維模式下，范冰冰分手、雙宋離婚帶來的流量是無法實現的，我們無法評估擴容量。
除此之外，傳統模式下資源利用率比較低，服務器很難在業務間共享。
在這些問題共同作用下催生了動態擴縮容體系。
彈性計算：實時動態擴縮容
動態擴縮容不是一個工具，是一整套體系。它基于云服務，包含了在線壓力檢測和消耗度評測的功能，最終實現分級治理。
①彈性計算架構
首先簡單介紹一下彈性計算的架構，彈性計算依托于 Kunkka 自動化運維平臺，以及 Oops 監控平臺，在業務壓測的情況下獲取業務指標監控，將數據送到容量決策系統，做出是否擴縮容的決定。
在云服務商方面，我們常用阿里云、華為云跟一部分自建的私有云。DCP 混合平臺是我們微博另外一個團隊做了幾年的平臺，它能夠對接云服務，快速生成云主機快速擴容。
今天的重點跟業務方有著最直接的關系：業務上要不要擴容？什么時候擴容？擴多少？我們要解決這樣的問題。
②決策系統
在上文的架構中，我們提到了容量決策系統，容量決策系統實際上指的是計算系統，會對我們獲取到的業務指標進行計算、評估。
比如系統的基礎信息、一些業務上日志來源的信息等，得到當前業務的容量，通過對歷史數據進行同比、環比的分析，得到流量趨勢，了解接下來流量會變成什么樣子，這兩組數據計算結果會給出擴縮容的建議。
同時，他們會計算這些數據并予以呈現，提供一個輔助的 API 接口，給上下游部門做擴縮容數據。
③容量評估方法
這個業務的當前容量是什么樣的？是不是健康的？這個指標靠什么來評估？
由于業務系統、業務形態、架構的不同，選取一個實時且通用的指標是非常具有挑戰性的，我們也嘗試了很久，引入了 AVG-hits 的概念。
對于處在不同時間內的請求數進行加權、求和來擬合實際的單機消耗量，這個代表的是在不同的區間的耗時數，我們給它一個系數，大于 5 毫秒小于 10 毫秒，根據自己的業務給予耗時分區，這樣就能計算出來。
事實證明，與之前傳統的單一 QPS 負載對比起來，綜合的數據對業務的評估比這種單一指標是更加準確的。
在獲得這個數據之后是不是就能夠描述當前的系統容量呢？
回答是肯定不能，AVG-hits 這個概念第一次接觸，確實是有點生澀，舉個簡單的例子來幫助理解，比如說某個業務消耗指標衡量非常簡單，需要通過內存判斷消耗情況。
如果監控指標提示內存消耗到 80G，那能不能用 80G 來描述當前系統的消耗情況？
這樣問就比較容易理解，回答肯定是不能的，因為不知道服務器最大的內存是多少，如果最大是 96G，那么 80G 已經超過 80% 了，接近危險值，如果最大內存是 256G 則消耗不到 30%，是非常安全的值。
道理是一樣的，僅拿到當前消耗值是不能對業務當前狀態進行描述的，還需要另一個評估標準。
這個業務當前能承載的最大容量是多少？如果是看內存就簡單了，可這是一個綜合評估標準，要怎么拿到它呢？
作為一個有經驗的運維，我覺得根據服務器當前硬件的表現，猜測最大容量不是困難的事情，但現在都 2019 年了，靠猜是不行的，我們通過壓測獲取最大容量值。
在實際環境中減少服務器數量，減少到不能再少，記錄當前的容量值，作為最大容量，用壓測開始之前的實際消耗值除以壓測獲取的最大容量，得到整個系統的消耗比。這個消耗比就認為是當前這個系統消耗的畫像。
壓測壓到什么情況下達到最大容量不能再壓呢？是要壓到服務器宕機？
我們接入了另外一個概念叫消耗比，在耗時最大區間的 Ahits（請求數量）數（PPT 上顯示：慢速比=100.0*當前容量（Ahits）/最大容量（max_Ahts））與總的請求數之比超過一定的比例，則是影響用戶的體現。
這個壓力達到最大值就不能再壓了，就會記錄當時的 Ahit 數，作為這個接口最大容量。
④分級治理：水位線
現在拿到了一個非常重要的容量值及消耗比來進行容量評估，用于描述當前的容量消耗情況。
拿到這個消耗比之后是不是就可以擴容了？還是可以縮容了？此處還需要一個評估標準，是 30% 就擴？還是 50% 再擴？
我們基于歷史數據給予分析，制定了三條水位線，包括安全線、警戒線和致命線，拿當前消耗值與水位線進行對比，在不同階段采取不同的措施。
比如，現在的消耗度遠遠低于安全線，說明現在服務器部署有冗余，我們可以進行逐步的縮容。
如果說現在已經高于致命線，則需要擴容，讓這個值更加接近安全線，保證系統的穩定性。
⑤在線容量評估體系
現在自動擴縮容的三個要素，當前消耗、水位線、容量決策系統都已經具備了，我們如何把這三個點聯動起來？如何讓它串在一起完成擴容動作？這些環節都包含在在線容量評估體系內，這個體系可以實現壓測的過程。
我們剛才說了壓測不是通過流量拷貝進行模擬測試的，我們是針對目標服務，就用線上的流量，記錄當前（Ahits）數，開始減少服務器的數量，一直到慢速比達到臨界值的時候，記錄 Ahits 數作為本服務單元最大的消耗。
得到消耗值后和水位線進行對比，調用決策系統做出是否擴縮容的決定，接下來再對接云服務商，就完成了擴容的動作。
⑥實時演練體系
前面進行的數據采集、計算，以及動作的串聯，都是為了完成最后一個目標，服務擴容成功。
真正的服務器擴容到線上之后，怎么樣才能保證服務是健康可用的呢？我們還有另外一套輔助系統叫擴容演練。在實時演練過程中，要注意以下幾點：
部署效率：我們通過擴容演練來尋找整個擴容過程中的瓶頸，比如，我們下發是通過 DCP 對接云服務商來完成擴容的。
在真正的線上擴容過程中，DCP 有時要同時承載幾千臺節點的擴容并發。DCP 的效率是否能夠滿足？在擴容演練過程中需要確認這一點。
帶寬限制：微博和云服務商之間確實是拉了專線，但是微博和云服務商不只是微博廣告的一個業務，還有很多其他大戶。
而且一般在流量增加的時候他們的擴容也是非常猛烈的，所以帶寬是否可用，也是我們在日常演練過程中非常注意的現象。
依賴服務：這方面有很多案例，在這里簡單分享一下，2015 年春節，自動擴縮容的流程才剛剛開始，春節當天晚上我們擴容完幾千個節點后，忽然發現負載均衡加不上去。
之前做過演練，但不會拿幾千臺云服務器進行擴容，可能幾十臺確保功能可用就可以了，到時候要讓負載均衡的同事通過配置文件增加下 Memeber 就可以。
如果上千臺的服務器沒有辦法增加到負載均衡設備，那個時候大家手忙腳亂，最后通過手動的方式擴容節點。
大家知道春晚的流量高峰很短，但那天確實給了我們當頭一棒。接下來我們在擴容演練過程中，不僅會對負載均衡進行確認，還會對我們依賴的服務進行確認。
比如每次發生熱點事件時，大家會說微博又崩了，評論又崩了，熱搜出不來了。
其實應對峰值流量是件很頭大的事情，我把事情解決了，兄弟部門沒有解決，兄弟部門解決了，姐妹部門又出現了問題。
安全限制：618 大促時，京東的同學分享了在擴容的時候新增的服務器 IP 與 VIP 發生了沖突，而微博主要的體現就是數據庫會對很多業務的請求設置白名單，可是云服務器擴容之后 IP 是隨機的。
另外，新浪對于通行證有很多 IP 限制，所以我們通過擴容演練體系不斷發現各個環節中的問題，加以解決，保證在擴容動作進行時能夠順利地完成，保證擴容出來的云主機真正安全上線服務。
有了這個系統的加持，截止到現在自動擴容服務都處于比較穩定的狀態。
智能監控
在上文提到的自動擴縮容體系當中，提到一個叫 Oops 的系統，這是微博廣告運維人員建立的智能監控系統，接下來給大家簡單介紹一下。
監控面臨的挑戰
說到監控，不得不說監控遇到的很多問題。市面上有很多開源的監控軟件，比如說常見的 Zabbix，在監控數據量少的情況下，不管是基礎監控還是業務監控，這些開源軟件都是可以直接滿足需求的。
但是隨著監控指標的增多，加上我們的指標是實時性變化的，數據要求又比較高，這些原生軟件不再滿足我們需求了。
另外，微博廣告的業務數據有特殊性，一般運維關注的數據是系統的性能，系統的性能數據有時候來源于業務日志。
但是微博廣告的業務日志是收入，很多業務日志是一條都不能丟的，比如說結算的曝光。
每一條曝光對于廣告來說，都是真金白銀，對精準性要求比較高，單獨通過性能監控的日志收集方法是不能滿足需求的，這也是我們面臨的挑戰。
另外，監控系統一般都會具備告警功能，有告警就會有告警問題，接下來會詳細地介紹告警問題。
還面臨定位方面的挑戰，在監控越來越完善的基礎上，很多開發的操作情況發生了變化。
一旦發生問題，第一個反應并不是上服務器看一下系統怎么了，而是翻監控，看看哪些監控指標發生了問題，所以監控系統會越來越多地面向于問題定位這個方向。
Oops 整體架構面臨的挑戰
作為監控系統，Oops 在架構上并沒有什么出奇的地方，所有的監控無非就是四個階段：
- 從客戶端進行數據采集
- 數據的清洗和計算
- 數據存儲
-
數據展示
監控數據流向特點
所有的監控系統都逃不開這四個階段，只是根據業務的不同進行了定制化的工作。
針對廣告業務的監控流向，我們把數據分成兩類，有一部分精密數據的計算，我們采取的是離線分析的方式，通過采集軟件將所有的日志采集到 Kafka，通過計算的工具進行拆洗、計算，計算之后落存儲。
還有另外一個團隊開發的針對于這一部分數據的頁面展示化，還有一個系統叫 Hubble，針對精細數據的展現，實現個性化定制的展現。
另外一部分是運維比較關心的數據，今天來了多少流量？流量有多少是正常的？有多少是異常的？平均耗時是多少？針對這一部分，我們采取了實時數據計算的方法。
在數據采集階段發生了變化，我們并不采集全量日志，而是在客戶端做了預處理，進行分類計算。
比如說監控數據，就按監控數據的方法計算；告警數據，就按告警數據的計算。而且按照用戶讀取的需求進行分類存儲，保證了高并發數據的實時性。
海量指標監控系統流程
接下來詳細介紹實時數據計算。
首先從數據采集上講，上文提到我們不采取全量的采集方式，而是通過 Agent 對數據進行處理。
在數據采集階段，在數據產生的服務器上，針對不同的需求按不同的時間進行分類聚合，最終向后推送的數據是 key-value、計算方法這種模式，推送給 Proxy。
Proxy 拿到已經被打包的數據進行拆包，然后送給不同的計算結點，再按照 Key 進行計算，打時間戳。
這個數據并不精準，但我們可以接受部分損失，只需要保證數據的趨勢是正確的。
另外，關于分類計算，不同的需求推送給不同的計算節點。存儲也進行了分類，實時性要求比較強的話會直接放到內存，以最精細粒度進行存儲。
前三個小時的數據是按秒存的，按天計算的數據是按 10 秒、30 秒存的，一些單機數據是按分鐘存的。
另外一些歷史性的數據需要出報表的，比如說要看前一周的數據，前一個月的數據，按照大數據的方式存到 OpenTSDB 當中。
存儲的數據提供一個 API，通過 API 我們進行了分類計算、分類存儲，這種分類的需求來源于用戶，需要看用戶有什么要求，要什么樣的數據。
比如，Dashboard 的展示數據會直接被放到內存里。另外，上文提到的在線擴縮容數據，會相應獲取數據給用戶，其他相關的獲取需求 API 也會進行分類獲取。
接下來我們計算過的數據還有一部分會存儲到 redis 通過 WatchD 作為告警中心的數據，因為告警數據一般都只要求當前數據，不會有人需要查看上個月這臺機器的負載有沒有告警。
所以 Alert 節點計算之后的數據直接存在 Redis，Redis 把這個數據拿出來之后經過告警中心根據告警規則進行清洗，通過各種方式推送到需求方。
同時有一個相對個性化的展示叫九宮格。我們的九宮格實際上是一個結合報警功能的監控，它是一個頁面，但具備了告警功能。
接下來看一下監控圖，下面三張圖是范冰冰宣布分手拿到的流量，我們的反映是非常靈敏的，平均耗時也漲上來了。
第三張圖是拿到這些數據之后，自動平臺顯示應該擴容了。藍色跟綠色的流量線已經降下來了，大部分量調到云服務器上。
下圖是我們的九宮格，因為時效性比較強，正常來說是以產品為頁面，以業務線為格子，每個格子記錄的是單機的詳細信息。
如果在這一組服務器當中單機故障數超過一定的比例，這個格子會變顏色。
所以在正常的運維工位上都會有這樣的大屏幕，運維可以一目了然發現自己所有負責的業務線情況，而不是讓一臺臺機器在這里展現，這樣就沒有辦法看到業務線情況了。九宮格可以讓運維更加直觀地看到當前的告警情況。
告警
告警有很多的問題，我們遇到的問題可以分為以下四個方面：
①告警數量巨大
運維人員需要關注所有部分，從系統到服務、接口等等，維度很多，一旦有問題，各種策略都會觸發報警，報警數量多到一定程度，基本上等于沒有報警。
②重復告警率高
告警策略一般會周期性執行，一直到告警條件不被滿足，如果服務一直不恢復，就會重復報下去，另外，同一個故障也可能引發不同層次的告警。
比如，我們有一個業務線叫超粉，會有 360 臺服務器，流量高峰時 360 臺服務器會同時發送告警，這種告警的重復率很高。
③告警有效性不足
很多時候，網絡抖動、擁堵、負載暫時過高或者變更等原因，會觸發報警，但這類報警要么不再重現，要么可以自愈。
比如一個硬盤在接近 80% 的時候開始告警了，你讓它告嗎？好像得告，但似乎不告也可以。
④告警模式粗放
無論是否重要、優先級如何，告警都通過郵件、短信、App PUSH 發送到接收人，就像暴風一樣襲擊著接收人，接收人沒有辦法從中獲取到有效的信息，經常會讓真正重要的告警淹沒在一大堆普通告警中。
針對這些問題，我們采取了以下措施：
①抖動收斂
對于這種大規模服務器的維護，抖動是非常常見的現象。網絡抖一抖，整個服務單元就會向你告警。
針對這種抖動，我們增加了一些策略，抖動的時候會前后比較，監測重復性，看看是不是具備告警的意義，通過增加告警策略這種方式來進行收斂。
比如說流量突增的時候，需要查看是不是同單元都出現了這個情況。
②告警的分類和分級
詳細定義告警級別，發送優先級、升級策略等，可有效減少粗放模式下告警接收量。比如，一些低優先等級的告警會讓它告，處理的級別會低一點。
③同類合并
同一個原因可能會觸發一個服務池里面的所有實例都報警，比如同時無法連接數據庫，其實只需要報一次即可。
④變更忽略
我們的好多變更都是在 Kunkka 平臺上操作的，開發有時候會選中一個通知，現在是變更，告警請忽略。
以上措施能解決告警問題中 80% 的問題，現在大家都在朝著更高級的方向發展，我們也簡單做了一些探索。
在原有告警數據流情況下引入了工具 SkyLine，這個工具包含了多種算法，在異常檢測環節中，能夠通過它內置的算法將我們傳入的數據自動去抖動，提供平滑的數據，等你再拿到這個數據時就不需要再檢測是不是告警。
這個工具避免了人工操作，通過 Skyline 將數據進行平滑，提供一份準確的數據，我們只需要通過這份數據，進行規則判斷，決定是否需要告警就好了，減少了對數據準確性判斷的復雜過程。
接著是根因分析部分，隨著監控的覆蓋面越來越廣，監控精確性越來越高。
等故障出現的時候，開發人員就會去翻監控圖，去查看大概是哪些原因導致了故障。
隨著 Dashboard 越來越多，即便是經驗非常豐富的工作人員也很難快速地定位到原因會出現哪個方面、該去看哪張監控圖。
出現流量突增的情況時，Skyline 會通過內部的算法 Luminosity 尋找相似的情況，查看相同的時間內是否有其他地方出現流量異常，并將根源問題展示在 TOPN 上。
這樣就能夠快速查看在故障出現的前后哪些業務也出現了流量變化，方便對故障原因進行分析和定位。
服務治理
還有一項非常重要的工作——服務治理，這里只進行簡單的介紹。
為什么需要服務治理
微博廣告現階段所出現的問題主要有：架構越來越復雜，上文提到微博廣告的服務器已經達到 3000 臺。
所以在這種服務器數量情況下，架構會越來越復雜，穩定性要求也變得非常高；開發的多語言環境對上線發布也造成了挑戰；資源使用是否合理，對運維來說也是一個挑戰。
低成本和高可用的平衡
針對這些問題，我們進行了低成本和高可用的平衡，爭取用最小的服務器達到最穩定的架構。
在保證服務穩定的情況下，將流量進行均分，分到最小服務單元三機房部署為基本規則，保障在一個機房掛掉的情況下，另外 2/3 的服務器能承載全部的流量。
關于上下游之間調用的平衡，盡量減少跨運營商的調用，微博廣告每一毫秒的消耗都會影響到收入。
我們的請求時間是 1 毫秒、1 毫秒地優化下來的，這些損耗產生在網絡和服務器上，很難通過人力彌補，因此在這方面我們也非常謹慎。
另外，小功能會抽象出功能的共同點，將這些功能服務化，服務則按單元化部署。
服務發現及負載均衡
在服務治理過程中，我們會根據服務的引入服務自動發現，盡量減少服務變更環節的人工干預，提高安全性和實時性，自建負載均衡會有標準的數據輸入和數據發布的過程，可以大大提升后期的可擴展性和可用性。
服務治理成績
經過近半年的服務治理，我們達到了這樣的成績：
- 架構更加強健，容災能力提高
- 系統、數據、配置標準化
- 服務器的合理使用，成本控制
其中，我覺得最重要的是系統、數據、配置標準化的過程。
今天好多分享的嘉賓也提到了 AIOps，這些上層的建設都是依賴于整個業務標準化的過程。
中國有句古話，工欲善其事，必先利其器，我們所有的標準化過程就是為下一步人工智能打下堅實的基礎，希望我們的工作能夠以技術保證微博系統穩定，助力微博廣告的收入。
作者：孫燕
編輯：陶家龍、孫淑娟
出處：轉載自微信公眾號 DBAplus 社群（ID：dbaplus），本文根據孫燕老師在〖2019 DAMS 中國數據智能管理峰會〗現場演講內容整理而成。
孫燕，微博廣告基礎運維負責人，2009 年入職新浪，任職 10 年間參與博客、圖片、視頻、微博平臺監控、微博廣告多個產品運維，致力于運維自動化、產品架構優化、服務治理、智能監控及以監控為依托的服務容災建設。
