微博現(xiàn)在日活達(dá)到了 2 億，微博廣告是微博最重要且穩(wěn)定的收入來源，沒有之一，所以微博廣告系統(tǒng)的穩(wěn)定性是我們廣告運維所有工作中的重中之重。

作者：孫燕來源

?

微博現(xiàn)在日活達(dá)到了 2 億，微博廣告是微博最重要且穩(wěn)定的收入來源，沒有之一，所以微博廣告系統(tǒng)的穩(wěn)定性是我們廣告運維所有工作中的重中之重。

圖片來自 Pexels

微博廣告的運維主要負(fù)責(zé)資產(chǎn)管理、服務(wù)穩(wěn)定性維護(hù)、故障應(yīng)急處理以及成本控制等多個責(zé)任。

微博廣告運維發(fā)展經(jīng)歷了如下階段：從早期小規(guī)模的手工運維到工具化運維，隨著服務(wù)器數(shù)量的發(fā)展，業(yè)務(wù)模型日漸發(fā)展，開發(fā)、運營、QA 都參與到產(chǎn)品的生命周期中，我們現(xiàn)在也進(jìn)入了自動化運維的階段，在新的虛擬化技術(shù)、算法技術(shù)的驅(qū)動下，我們也在朝著 AIOps 的方向努力。

在整個運維過程中，我們遇到了很多痛點，幸福的人生都是一樣的，不幸的人生各有各的不幸，各家的運維都各有各的痛點。

我們的服務(wù)器在 3000 臺以上，業(yè)務(wù)線及輔助資源各種各樣，產(chǎn)品迭代非常快，且依賴關(guān)系復(fù)雜，流量變更，切換損失不可接受。

在這種情況下，我們面臨資產(chǎn)管理困難、環(huán)境不統(tǒng)一、上線難度大、運維成本高的問題。

基于這些問題，微博廣告運維工作主要集中在以下四個方面：

• 運維自動化
• 彈性計算
• 智能監(jiān)控
• 服務(wù)治理

運維自動化

一個健全的自動化運維平臺必須要具備如下幾個功能：

• 基礎(chǔ)監(jiān)控
• 資源管理
• 事件集中分析
• 配置管理
• 批量運維工具
• 持續(xù)集成和發(fā)布

基于這些功能和需求，我們廣告運維自主研發(fā)了 Kunkka 平臺(微博廣告運維自主研發(fā)的自動化運維平臺)、資產(chǎn)管理、自動化上線等運維平臺。

資產(chǎn)管理是基于公司 CMDB(公司級別的資產(chǎn)管理系統(tǒng))獲取到主機云服務(wù)器，針對微博廣告對資源的管理需求自建定制化的資產(chǎn)管理平臺。

配置中心包括服務(wù)注冊、服務(wù)配置等功能;自動化上線涵蓋了開發(fā)在上線過程中所需要的節(jié)點和流程。

自主終端是行業(yè)變化的功能實現(xiàn)，大家可以通過頁面完成文件或命令下發(fā)、日志審計等各種工作。

Kunkka 基于主機和容器，通過 Salt 作為傳輸層進(jìn)行命令下發(fā)，組件層包含開源軟件，操作層將命令頁面化，通過頁面進(jìn)行日常工作和管理。

這樣的自動化運維平臺基本上滿足了運維的日常操作需求，在 Kunkka 平臺中還有自動擴縮容的功能，我們針對這個功能進(jìn)行延伸。

在自動擴所容的基礎(chǔ)上，根據(jù)時間段，流量進(jìn)行動態(tài)判斷，自動決策的擴所容夠功能。

彈性計算

為什么需要彈性計算

首先，在產(chǎn)品方面，我們的產(chǎn)品線很多，依賴關(guān)系比較復(fù)雜。

微博廣告相當(dāng)于一個橋梁，左邊連接的是廣告主，右邊連接的是客戶，需要將廣告主的廣告計劃轉(zhuǎn)化為用戶的需求，讓用戶看到自己想要看的廣告。

為了滿足兩邊不同的需求，產(chǎn)品的變更和發(fā)布非常重要且頻繁。

其次，在運營方面，很多有推廣需求計劃的大型活動都有臨時擴容需要，比如 618 跟雙十一，對于我們而言這兩個活動帶來了很大的沖擊。

在 618 和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實現(xiàn)廣告主廣告計劃的轉(zhuǎn)化。

在 618 和雙十一大促之前，為了加大自己的影響力，各個廣告主會增加廣告計劃，微博廣告這邊再針對廣告主的行為加大我們的曝光量，實現(xiàn)廣告主廣告計劃的轉(zhuǎn)化。

傳統(tǒng)的業(yè)務(wù)運維

按照傳統(tǒng)運維模式，擴容計劃從立項到服務(wù)器上線，會經(jīng)過諸多的流程跟漫長的等待。

從結(jié)果上來看，服務(wù)器擴容了，而且對傳統(tǒng)項目而言，整體流程都是可控的，這是它的優(yōu)點。

它的缺點不言而喻，有以下幾點：

首先，它時效性太差，如果按照新浪服務(wù)器的采購周期，從審計到上線需要兩個月的流程。兩個月后服務(wù)器上線，恐怕剛結(jié)婚的明星都已經(jīng)離婚了，突發(fā)事件流量都已經(jīng)過去了。

另外，它無法準(zhǔn)確預(yù)估容量，在傳統(tǒng)的業(yè)務(wù)運維模式下，范冰冰分手、雙宋離婚帶來的流量是無法實現(xiàn)的，我們無法評估擴容量。

除此之外，傳統(tǒng)模式下資源利用率比較低，服務(wù)器很難在業(yè)務(wù)間共享。

在這些問題共同作用下催生了動態(tài)擴縮容體系。

彈性計算：實時動態(tài)擴縮容

動態(tài)擴縮容不是一個工具，是一整套體系。它基于云服務(wù)，包含了在線壓力檢測和消耗度評測的功能，最終實現(xiàn)分級治理。

①彈性計算架構(gòu)

首先簡單介紹一下彈性計算的架構(gòu)，彈性計算依托于 Kunkka 自動化運維平臺，以及 Oops 監(jiān)控平臺，在業(yè)務(wù)壓測的情況下獲取業(yè)務(wù)指標(biāo)監(jiān)控，將數(shù)據(jù)送到容量決策系統(tǒng)，做出是否擴縮容的決定。

在云服務(wù)商方面，我們常用阿里云、華為云跟一部分自建的私有云。DCP 混合平臺是我們微博另外一個團(tuán)隊做了幾年的平臺，它能夠?qū)釉品?wù)，快速生成云主機快速擴容。

今天的重點跟業(yè)務(wù)方有著最直接的關(guān)系：業(yè)務(wù)上要不要擴容?什么時候擴容?擴多少?我們要解決這樣的問題。

②決策系統(tǒng)

在上文的架構(gòu)中，我們提到了容量決策系統(tǒng)，容量決策系統(tǒng)實際上指的是計算系統(tǒng)，會對我們獲取到的業(yè)務(wù)指標(biāo)進(jìn)行計算、評估。

比如系統(tǒng)的基礎(chǔ)信息、一些業(yè)務(wù)上日志來源的信息等，得到當(dāng)前業(yè)務(wù)的容量，通過對歷史數(shù)據(jù)進(jìn)行同比、環(huán)比的分析，得到流量趨勢，了解接下來流量會變成什么樣子，這兩組數(shù)據(jù)計算結(jié)果會給出擴縮容的建議。

同時，他們會計算這些數(shù)據(jù)并予以呈現(xiàn)，提供一個輔助的 API 接口，給上下游部門做擴縮容數(shù)據(jù)。

③容量評估方法

這個業(yè)務(wù)的當(dāng)前容量是什么樣的?是不是健康的?這個指標(biāo)靠什么來評估?

由于業(yè)務(wù)系統(tǒng)、業(yè)務(wù)形態(tài)、架構(gòu)的不同，選取一個實時且通用的指標(biāo)是非常具有挑戰(zhàn)性的，我們也嘗試了很久，引入了 AVG-hits 的概念。

對于處在不同時間內(nèi)的請求數(shù)進(jìn)行加權(quán)、求和來擬合實際的單機消耗量，這個代表的是在不同的區(qū)間的耗時數(shù)，我們給它一個系數(shù)，大于 5 毫秒小于 10 毫秒，根據(jù)自己的業(yè)務(wù)給予耗時分區(qū)，這樣就能計算出來。

事實證明，與之前傳統(tǒng)的單一 QPS 負(fù)載對比起來，綜合的數(shù)據(jù)對業(yè)務(wù)的評估比這種單一指標(biāo)是更加準(zhǔn)確的。

在獲得這個數(shù)據(jù)之后是不是就能夠描述當(dāng)前的系統(tǒng)容量呢?

回答是肯定不能，AVG-hits 這個概念第一次接觸，確實是有點生澀，舉個簡單的例子來幫助理解，比如說某個業(yè)務(wù)消耗指標(biāo)衡量非常簡單，需要通過內(nèi)存判斷消耗情況。

如果監(jiān)控指標(biāo)提示內(nèi)存消耗到 80G，那能不能用 80G 來描述當(dāng)前系統(tǒng)的消耗情況?

這樣問就比較容易理解，回答肯定是不能的，因為不知道服務(wù)器最大的內(nèi)存是多少，如果最大是 96G，那么 80G 已經(jīng)超過 80% 了，接近危險值，如果最大內(nèi)存是 256G 則消耗不到 30%，是非常安全的值。

道理是一樣的，僅拿到當(dāng)前消耗值是不能對業(yè)務(wù)當(dāng)前狀態(tài)進(jìn)行描述的，還需要另一個評估標(biāo)準(zhǔn)。

這個業(yè)務(wù)當(dāng)前能承載的最大容量是多少?如果是看內(nèi)存就簡單了，可這是一個綜合評估標(biāo)準(zhǔn)，要怎么拿到它呢?

作為一個有經(jīng)驗的運維，我覺得根據(jù)服務(wù)器當(dāng)前硬件的表現(xiàn)，猜測最大容量不是困難的事情，但現(xiàn)在都 2019 年了，靠猜是不行的，我們通過壓測獲取最大容量值。

在實際環(huán)境中減少服務(wù)器數(shù)量，減少到不能再少，記錄當(dāng)前的容量值，作為最大容量，用壓測開始之前的實際消耗值除以壓測獲取的最大容量，得到整個系統(tǒng)的消耗比。這個消耗比就認(rèn)為是當(dāng)前這個系統(tǒng)消耗的畫像。

壓測壓到什么情況下達(dá)到最大容量不能再壓呢?是要壓到服務(wù)器宕機?

我們接入了另外一個概念叫消耗比，在耗時最大區(qū)間的 Ahits(請求數(shù)量)數(shù)(PPT 上顯示：慢速比=100.0*當(dāng)前容量(Ahits)/最大容量(max_Ahts))與總的請求數(shù)之比超過一定的比例，則是影響用戶的體現(xiàn)。

這個壓力達(dá)到最大值就不能再壓了，就會記錄當(dāng)時的 Ahit 數(shù)，作為這個接口最大容量。

④分級治理：水位線

現(xiàn)在拿到了一個非常重要的容量值及消耗比來進(jìn)行容量評估，用于描述當(dāng)前的容量消耗情況。

拿到這個消耗比之后是不是就可以擴容了?還是可以縮容了?此處還需要一個評估標(biāo)準(zhǔn)，是 30% 就擴?還是 50% 再擴?

我們基于歷史數(shù)據(jù)給予分析，制定了三條水位線，包括安全線、警戒線和致命線，拿當(dāng)前消耗值與水位線進(jìn)行對比，在不同階段采取不同的措施。

比如，現(xiàn)在的消耗度遠(yuǎn)遠(yuǎn)低于安全線，說明現(xiàn)在服務(wù)器部署有冗余，我們可以進(jìn)行逐步的縮容。

如果說現(xiàn)在已經(jīng)高于致命線，則需要擴容，讓這個值更加接近安全線，保證系統(tǒng)的穩(wěn)定性。

⑤在線容量評估體系

現(xiàn)在自動擴縮容的三個要素，當(dāng)前消耗、水位線、容量決策系統(tǒng)都已經(jīng)具備了，我們?nèi)绾伟堰@三個點聯(lián)動起來?如何讓它串在一起完成擴容動作?這些環(huán)節(jié)都包含在在線容量評估體系內(nèi)，這個體系可以實現(xiàn)壓測的過程。

我們剛才說了壓測不是通過流量拷貝進(jìn)行模擬測試的，我們是針對目標(biāo)服務(wù)，就用線上的流量，記錄當(dāng)前(Ahits)數(shù)，開始減少服務(wù)器的數(shù)量，一直到慢速比達(dá)到臨界值的時候，記錄 Ahits 數(shù)作為本服務(wù)單元最大的消耗。

得到消耗值后和水位線進(jìn)行對比，調(diào)用決策系統(tǒng)做出是否擴縮容的決定，接下來再對接云服務(wù)商，就完成了擴容的動作。

⑥實時演練體系

前面進(jìn)行的數(shù)據(jù)采集、計算，以及動作的串聯(lián)，都是為了完成最后一個目標(biāo)，服務(wù)擴容成功。

真正的服務(wù)器擴容到線上之后，怎么樣才能保證服務(wù)是健康可用的呢?我們還有另外一套輔助系統(tǒng)叫擴容演練。在實時演練過程中，要注意以下幾點：

部署效率：我們通過擴容演練來尋找整個擴容過程中的瓶頸，比如，我們下發(fā)是通過 DCP 對接云服務(wù)商來完成擴容的。

在真正的線上擴容過程中，DCP 有時要同時承載幾千臺節(jié)點的擴容并發(fā)。DCP 的效率是否能夠滿足?在擴容演練過程中需要確認(rèn)這一點。

帶寬限制：微博和云服務(wù)商之間確實是拉了專線，但是微博和云服務(wù)商不只是微博廣告的一個業(yè)務(wù)，還有很多其他大戶。

而且一般在流量增加的時候他們的擴容也是非常猛烈的，所以帶寬是否可用，也是我們在日常演練過程中非常注意的現(xiàn)象。

依賴服務(wù)：這方面有很多案例，在這里簡單分享一下，2015 年春節(jié)，自動擴縮容的流程才剛剛開始，春節(jié)當(dāng)天晚上我們擴容完幾千個節(jié)點后，忽然發(fā)現(xiàn)負(fù)載均衡加不上去。

之前做過演練，但不會拿幾千臺云服務(wù)器進(jìn)行擴容，可能幾十臺確保功能可用就可以了，到時候要讓負(fù)載均衡的同事通過配置文件增加下 Memeber 就可以。

如果上千臺的服務(wù)器沒有辦法增加到負(fù)載均衡設(shè)備，那個時候大家手忙腳亂，最后通過手動的方式擴容節(jié)點。

大家知道春晚的流量高峰很短，但那天確實給了我們當(dāng)頭一棒。接下來我們在擴容演練過程中，不僅會對負(fù)載均衡進(jìn)行確認(rèn)，還會對我們依賴的服務(wù)進(jìn)行確認(rèn)。

比如每次發(fā)生熱點事件時，大家會說微博又崩了，評論又崩了，熱搜出不來了。

其實應(yīng)對峰值流量是件很頭大的事情，我把事情解決了，兄弟部門沒有解決，兄弟部門解決了，姐妹部門又出現(xiàn)了問題。

安全限制：618 大促時，京東的同學(xué)分享了在擴容的時候新增的服務(wù)器 IP 與 VIP 發(fā)生了沖突，而微博主要的體現(xiàn)就是數(shù)據(jù)庫會對很多業(yè)務(wù)的請求設(shè)置白名單，可是云服務(wù)器擴容之后 IP 是隨機的。

另外，新浪對于通行證有很多 IP 限制，所以我們通過擴容演練體系不斷發(fā)現(xiàn)各個環(huán)節(jié)中的問題，加以解決，保證在擴容動作進(jìn)行時能夠順利地完成，保證擴容出來的云主機真正安全上線服務(wù)。

有了這個系統(tǒng)的加持，截止到現(xiàn)在自動擴容服務(wù)都處于比較穩(wěn)定的狀態(tài)。

智能監(jiān)控

在上文提到的自動擴縮容體系當(dāng)中，提到一個叫 Oops 的系統(tǒng)，這是微博廣告運維人員建立的智能監(jiān)控系統(tǒng)，接下來給大家簡單介紹一下。

監(jiān)控面臨的挑戰(zhàn)

說到監(jiān)控，不得不說監(jiān)控遇到的很多問題。市面上有很多開源的監(jiān)控軟件，比如說常見的 Zabbix，在監(jiān)控數(shù)據(jù)量少的情況下，不管是基礎(chǔ)監(jiān)控還是業(yè)務(wù)監(jiān)控，這些開源軟件都是可以直接滿足需求的。

但是隨著監(jiān)控指標(biāo)的增多，加上我們的指標(biāo)是實時性變化的，數(shù)據(jù)要求又比較高，這些原生軟件不再滿足我們需求了。

另外，微博廣告的業(yè)務(wù)數(shù)據(jù)有特殊性，一般運維關(guān)注的數(shù)據(jù)是系統(tǒng)的性能，系統(tǒng)的性能數(shù)據(jù)有時候來源于業(yè)務(wù)日志。

但是微博廣告的業(yè)務(wù)日志是收入，很多業(yè)務(wù)日志是一條都不能丟的，比如說結(jié)算的曝光。

每一條曝光對于廣告來說，都是真金白銀，對精準(zhǔn)性要求比較高，單獨通過性能監(jiān)控的日志收集方法是不能滿足需求的，這也是我們面臨的挑戰(zhàn)。

另外，監(jiān)控系統(tǒng)一般都會具備告警功能，有告警就會有告警問題，接下來會詳細(xì)地介紹告警問題。

還面臨定位方面的挑戰(zhàn)，在監(jiān)控越來越完善的基礎(chǔ)上，很多開發(fā)的操作情況發(fā)生了變化。

一旦發(fā)生問題，第一個反應(yīng)并不是上服務(wù)器看一下系統(tǒng)怎么了，而是翻監(jiān)控，看看哪些監(jiān)控指標(biāo)發(fā)生了問題，所以監(jiān)控系統(tǒng)會越來越多地面向于問題定位這個方向。

Oops 整體架構(gòu)面臨的挑戰(zhàn)

作為監(jiān)控系統(tǒng)，Oops 在架構(gòu)上并沒有什么出奇的地方，所有的監(jiān)控?zé)o非就是四個階段：

• 從客戶端進(jìn)行數(shù)據(jù)采集
• 數(shù)據(jù)的清洗和計算
• 數(shù)據(jù)存儲
• 數(shù)據(jù)展示

監(jiān)控數(shù)據(jù)流向特點

所有的監(jiān)控系統(tǒng)都逃不開這四個階段，只是根據(jù)業(yè)務(wù)的不同進(jìn)行了定制化的工作。

針對廣告業(yè)務(wù)的監(jiān)控流向，我們把數(shù)據(jù)分成兩類，有一部分精密數(shù)據(jù)的計算，我們采取的是離線分析的方式，通過采集軟件將所有的日志采集到 Kafka，通過計算的工具進(jìn)行拆洗、計算，計算之后落存儲。

還有另外一個團(tuán)隊開發(fā)的針對于這一部分?jǐn)?shù)據(jù)的頁面展示化，還有一個系統(tǒng)叫 Hubble，針對精細(xì)數(shù)據(jù)的展現(xiàn)，實現(xiàn)個性化定制的展現(xiàn)。

另外一部分是運維比較關(guān)心的數(shù)據(jù)，今天來了多少流量?流量有多少是正常的?有多少是異常的?平均耗時是多少?針對這一部分，我們采取了實時數(shù)據(jù)計算的方法。

在數(shù)據(jù)采集階段發(fā)生了變化，我們并不采集全量日志，而是在客戶端做了預(yù)處理，進(jìn)行分類計算。

比如說監(jiān)控數(shù)據(jù)，就按監(jiān)控數(shù)據(jù)的方法計算;告警數(shù)據(jù)，就按告警數(shù)據(jù)的計算。而且按照用戶讀取的需求進(jìn)行分類存儲，保證了高并發(fā)數(shù)據(jù)的實時性。

海量指標(biāo)監(jiān)控系統(tǒng)流程

接下來詳細(xì)介紹實時數(shù)據(jù)計算。

首先從數(shù)據(jù)采集上講，上文提到我們不采取全量的采集方式，而是通過 Agent 對數(shù)據(jù)進(jìn)行處理。

在數(shù)據(jù)采集階段，在數(shù)據(jù)產(chǎn)生的服務(wù)器上，針對不同的需求按不同的時間進(jìn)行分類聚合，最終向后推送的數(shù)據(jù)是 key-value、計算方法這種模式，推送給 Proxy。

Proxy 拿到已經(jīng)被打包的數(shù)據(jù)進(jìn)行拆包，然后送給不同的計算結(jié)點，再按照 Key 進(jìn)行計算，打時間戳。

這個數(shù)據(jù)并不精準(zhǔn)，但我們可以接受部分損失，只需要保證數(shù)據(jù)的趨勢是正確的。

另外，關(guān)于分類計算，不同的需求推送給不同的計算節(jié)點。存儲也進(jìn)行了分類，實時性要求比較強的話會直接放到內(nèi)存，以最精細(xì)粒度進(jìn)行存儲。

前三個小時的數(shù)據(jù)是按秒存的，按天計算的數(shù)據(jù)是按 10 秒、30 秒存的，一些單機數(shù)據(jù)是按分鐘存的。

另外一些歷史性的數(shù)據(jù)需要出報表的，比如說要看前一周的數(shù)據(jù)，前一個月的數(shù)據(jù)，按照大數(shù)據(jù)的方式存到 OpenTSDB 當(dāng)中。

存儲的數(shù)據(jù)提供一個 API，通過 API 我們進(jìn)行了分類計算、分類存儲，這種分類的需求來源于用戶，需要看用戶有什么要求，要什么樣的數(shù)據(jù)。

比如，Dashboard 的展示數(shù)據(jù)會直接被放到內(nèi)存里。另外，上文提到的在線擴縮容數(shù)據(jù)，會相應(yīng)獲取數(shù)據(jù)給用戶，其他相關(guān)的獲取需求 API 也會進(jìn)行分類獲取。

接下來我們計算過的數(shù)據(jù)還有一部分會存儲到 Redis 通過 WatchD 作為告警中心的數(shù)據(jù)，因為告警數(shù)據(jù)一般都只要求當(dāng)前數(shù)據(jù)，不會有人需要查看上個月這臺機器的負(fù)載有沒有告警。

所以 Alert 節(jié)點計算之后的數(shù)據(jù)直接存在 Redis，Redis 把這個數(shù)據(jù)拿出來之后經(jīng)過告警中心根據(jù)告警規(guī)則進(jìn)行清洗，通過各種方式推送到需求方。

同時有一個相對個性化的展示叫九宮格。我們的九宮格實際上是一個結(jié)合報警功能的監(jiān)控，它是一個頁面，但具備了告警功能。

接下來看一下監(jiān)控圖，下面三張圖是范冰冰宣布分手拿到的流量，我們的反映是非常靈敏的，平均耗時也漲上來了。

第三張圖是拿到這些數(shù)據(jù)之后，自動平臺顯示應(yīng)該擴容了。藍(lán)色跟綠色的流量線已經(jīng)降下來了，大部分量調(diào)到云服務(wù)器上。

下圖是我們的九宮格，因為時效性比較強，正常來說是以產(chǎn)品為頁面，以業(yè)務(wù)線為格子，每個格子記錄的是單機的詳細(xì)信息。

如果在這一組服務(wù)器當(dāng)中單機故障數(shù)超過一定的比例，這個格子會變顏色。

所以在正常的運維工位上都會有這樣的大屏幕，運維可以一目了然發(fā)現(xiàn)自己所有負(fù)責(zé)的業(yè)務(wù)線情況，而不是讓一臺臺機器在這里展現(xiàn)，這樣就沒有辦法看到業(yè)務(wù)線情況了。九宮格可以讓運維更加直觀地看到當(dāng)前的告警情況。

告警

告警有很多的問題，我們遇到的問題可以分為以下四個方面：

①告警數(shù)量巨大

運維人員需要關(guān)注所有部分，從系統(tǒng)到服務(wù)、接口等等，維度很多，一旦有問題，各種策略都會觸發(fā)報警，報警數(shù)量多到一定程度，基本上等于沒有報警。

②重復(fù)告警率高

告警策略一般會周期性執(zhí)行，一直到告警條件不被滿足，如果服務(wù)一直不恢復(fù)，就會重復(fù)報下去，另外，同一個故障也可能引發(fā)不同層次的告警。

比如，我們有一個業(yè)務(wù)線叫超粉，會有 360 臺服務(wù)器，流量高峰時 360 臺服務(wù)器會同時發(fā)送告警，這種告警的重復(fù)率很高。

③告警有效性不足

很多時候，網(wǎng)絡(luò)抖動、擁堵、負(fù)載暫時過高或者變更等原因，會觸發(fā)報警，但這類報警要么不再重現(xiàn)，要么可以自愈。

比如一個硬盤在接近 80% 的時候開始告警了，你讓它告嗎?好像得告，但似乎不告也可以。

④告警模式粗放

無論是否重要、優(yōu)先級如何，告警都通過郵件、短信、App PUSH 發(fā)送到接收人，就像暴風(fēng)一樣襲擊著接收人，接收人沒有辦法從中獲取到有效的信息，經(jīng)常會讓真正重要的告警淹沒在一大堆普通告警中。

針對這些問題，我們采取了以下措施：

①抖動收斂

對于這種大規(guī)模服務(wù)器的維護(hù)，抖動是非常常見的現(xiàn)象。網(wǎng)絡(luò)抖一抖，整個服務(wù)單元就會向你告警。

針對這種抖動，我們增加了一些策略，抖動的時候會前后比較，監(jiān)測重復(fù)性，看看是不是具備告警的意義，通過增加告警策略這種方式來進(jìn)行收斂。

比如說流量突增的時候，需要查看是不是同單元都出現(xiàn)了這個情況。

②告警的分類和分級

詳細(xì)定義告警級別，發(fā)送優(yōu)先級、升級策略等，可有效減少粗放模式下告警接收量。比如，一些低優(yōu)先等級的告警會讓它告，處理的級別會低一點。

③同類合并

同一個原因可能會觸發(fā)一個服務(wù)池里面的所有實例都報警，比如同時無法連接數(shù)據(jù)庫，其實只需要報一次即可。

④變更忽略

我們的好多變更都是在 Kunkka 平臺上操作的，開發(fā)有時候會選中一個通知，現(xiàn)在是變更，告警請忽略。

以上措施能解決告警問題中 80% 的問題，現(xiàn)在大家都在朝著更高級的方向發(fā)展，我們也簡單做了一些探索。

在原有告警數(shù)據(jù)流情況下引入了工具 SkyLine，這個工具包含了多種算法，在異常檢測環(huán)節(jié)中，能夠通過它內(nèi)置的算法將我們傳入的數(shù)據(jù)自動去抖動，提供平滑的數(shù)據(jù)，等你再拿到這個數(shù)據(jù)時就不需要再檢測是不是告警。

這個工具避免了人工操作，通過 Skyline 將數(shù)據(jù)進(jìn)行平滑，提供一份準(zhǔn)確的數(shù)據(jù)，我們只需要通過這份數(shù)據(jù)，進(jìn)行規(guī)則判斷，決定是否需要告警就好了，減少了對數(shù)據(jù)準(zhǔn)確性判斷的復(fù)雜過程。

接著是根因分析部分，隨著監(jiān)控的覆蓋面越來越廣，監(jiān)控精確性越來越高。

等故障出現(xiàn)的時候，開發(fā)人員就會去翻監(jiān)控圖，去查看大概是哪些原因?qū)е铝斯收稀?/p>

隨著 Dashboard 越來越多，即便是經(jīng)驗非常豐富的工作人員也很難快速地定位到原因會出現(xiàn)哪個方面、該去看哪張監(jiān)控圖。

出現(xiàn)流量突增的情況時，Skyline 會通過內(nèi)部的算法 Luminosity 尋找相似的情況，查看相同的時間內(nèi)是否有其他地方出現(xiàn)流量異常，并將根源問題展示在 TOPN 上。

這樣就能夠快速查看在故障出現(xiàn)的前后哪些業(yè)務(wù)也出現(xiàn)了流量變化，方便對故障原因進(jìn)行分析和定位。

服務(wù)治理

還有一項非常重要的工作——服務(wù)治理，這里只進(jìn)行簡單的介紹。

為什么需要服務(wù)治理

微博廣告現(xiàn)階段所出現(xiàn)的問題主要有：架構(gòu)越來越復(fù)雜，上文提到微博廣告的服務(wù)器已經(jīng)達(dá)到 3000 臺。

所以在這種服務(wù)器數(shù)量情況下，架構(gòu)會越來越復(fù)雜，穩(wěn)定性要求也變得非常高;開發(fā)的多語言環(huán)境對上線發(fā)布也造成了挑戰(zhàn);資源使用是否合理，對運維來說也是一個挑戰(zhàn)。

低成本和高可用的平衡

針對這些問題，我們進(jìn)行了低成本和高可用的平衡，爭取用最小的服務(wù)器達(dá)到最穩(wěn)定的架構(gòu)。

在保證服務(wù)穩(wěn)定的情況下，將流量進(jìn)行均分，分到最小服務(wù)單元三機房部署為基本規(guī)則，保障在一個機房掛掉的情況下，另外 2/3 的服務(wù)器能承載全部的流量。

關(guān)于上下游之間調(diào)用的平衡，盡量減少跨運營商的調(diào)用，微博廣告每一毫秒的消耗都會影響到收入。

我們的請求時間是 1 毫秒、1 毫秒地優(yōu)化下來的，這些損耗產(chǎn)生在網(wǎng)絡(luò)和服務(wù)器上，很難通過人力彌補，因此在這方面我們也非常謹(jǐn)慎。

另外，小功能會抽象出功能的共同點，將這些功能服務(wù)化，服務(wù)則按單元化部署。

服務(wù)發(fā)現(xiàn)及負(fù)載均衡

在服務(wù)治理過程中，我們會根據(jù)服務(wù)的引入服務(wù)自動發(fā)現(xiàn)，盡量減少服務(wù)變更環(huán)節(jié)的人工干預(yù)，提高安全性和實時性，自建負(fù)載均衡會有標(biāo)準(zhǔn)的數(shù)據(jù)輸入和數(shù)據(jù)發(fā)布的過程，可以大大提升后期的可擴展性和可用性。

服務(wù)治理成績

經(jīng)過近半年的服務(wù)治理，我們達(dá)到了這樣的成績：

• 架構(gòu)更加強健，容災(zāi)能力提高
• 系統(tǒng)、數(shù)據(jù)、配置標(biāo)準(zhǔn)化
• 服務(wù)器的合理使用，成本控制

其中，我覺得最重要的是系統(tǒng)、數(shù)據(jù)、配置標(biāo)準(zhǔn)化的過程。

今天好多分享的嘉賓也提到了 AIOps，這些上層的建設(shè)都是依賴于整個業(yè)務(wù)標(biāo)準(zhǔn)化的過程。

中國有句古話，工欲善其事，必先利其器，我們所有的標(biāo)準(zhǔn)化過程就是為下一步人工智能打下堅實的基礎(chǔ)，希望我們的工作能夠以技術(shù)保證微博系統(tǒng)穩(wěn)定，助力微博廣告的收入。

閱讀目錄（置頂)(長期更新計算機領(lǐng)域知識）https://blog.csdn.net/weixin_43392489/article/details/102380691

閱讀目錄（置頂)(長期更新計算機領(lǐng)域知識）https://blog.csdn.net/weixin_43392489/article/details/102380882

閱讀目錄（置頂)(長期科技領(lǐng)域知識）https://blog.csdn.net/weixin_43392489/article/details/102600114

歌謠帶你看java面試題 https://blog.csdn.net/weixin_43392489/article/details/102675944

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的第七十六期：3000台服务器不宕机，微博广告系统全景运维大法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。