隨著大數(shù)據(jù)、人工智能捉撮、云計算技術(shù)的日漸成熟和飛速發(fā)展怕品，傳統(tǒng)的運維技術(shù)和解決方案已經(jīng)不能滿足需求，智能運維已成為運維的熱點領(lǐng)域巾遭。同時肉康，為了滿足大流量闯估、用戶高質(zhì)量體驗和用戶分布地域廣的互聯(lián)網(wǎng)應(yīng)用場景，大型分布式系統(tǒng)的部署方式也成為了高效運維的必然之選吼和。如何提升運維的能力和效率涨薪，是保障業(yè)務(wù)高可用所面臨的最大挑戰(zhàn)。

6 月 23 日炫乓，由百度開發(fā)者中心刚夺、百度云智學院主辦，極客邦科技承辦的第 79 期百度技術(shù)沙龍邀請了來自百度智能云主任架構(gòu)師王棟末捣，百度智能云架構(gòu)師哈晶晶光督，百度智能云資深運維架構(gòu)師楊濤，百度智能云架構(gòu)師章淼塔粒，百度智能云架構(gòu)師余杰及百度智能云資深工程師廖洪流六位講師结借，分享百度在 AIOps 、DevOps 上的實戰(zhàn)經(jīng)驗卒茬，并以百度統(tǒng)一前端接入（ Baidu Front End 船老，BFE ）、數(shù)據(jù)庫以及 Redis 三個具體系統(tǒng)為例圃酵，介紹百度在系統(tǒng)架構(gòu)設(shè)計和變更柳畔、監(jiān)控、故障處理和性能管理等貫穿線上系統(tǒng)生命周期的運維層面上郭赐，如何保證系統(tǒng)的高可用薪韩。

高可用性系統(tǒng)的架構(gòu)與運維實踐

百度智能云主任架構(gòu)師王棟做了開場演講。他首先介紹了百度運維發(fā)展的歷史捌锭，主要分為三個階段：一俘陷、基礎(chǔ)運維階段。提供機器管理观谦，服務(wù)管理和權(quán)限管理拉盾，保證線上基本服務(wù)運行，并對線上基本數(shù)據(jù)管理進行監(jiān)控豁状。二捉偏、開放運維時代。以開放 API 的形式泻红，把第一階段業(yè)務(wù)層面的運維交給各個業(yè)務(wù)部門夭禽。但是面臨著垂直場景重復制造輪子，所積累運維知識和數(shù)據(jù)難以匯聚的問題谊路。三讹躯、智能運維階段。構(gòu)建統(tǒng)一的運維知識庫，一致的運維工具開發(fā)框架以及全局可見的算法復用平臺蜀撑。

下圖為百度智能運維整體框架圖。最下方是基礎(chǔ)運維平臺剩彬，提供最基本的運維能力酷麦，在此平臺的基礎(chǔ)上構(gòu)建運維開發(fā)框架、運維知識庫和運維策略庫喉恋，在面臨不同的場景和不同的業(yè)務(wù)將所有場景的算法抽樣出來提供服務(wù)沃饶。

智能運維和要解決的問題場景

王棟現(xiàn)場對運維問題的復雜程度做了區(qū)分，如下圖所示轻黑『簦縱軸表示問題的難易程度，橫軸表示問題發(fā)生的頻率氓鄙。這樣運維問題可以總結(jié)分成四個象限馆揉，對于每一個象限采取不同的應(yīng)對措施。左上角低頻高復雜問題抖拦，可以希望智能輔助決策升酣，增強人的能力；右上角高頻復雜問題态罪，希望達到智能的決策噩茄，智能執(zhí)行，并可遷移复颈，而人只需做一些基本輔助工作即可绩聘；左下角低頻且簡單的場景，這是比較好解決的問題耗啦，只需把問題的解決策略規(guī)范化凿菩、流程化；右下角高頻但是簡單問題可通過自動化帜讲、自助化將問題解決蓄髓。

百度 AIOps 實踐

百度運維經(jīng)歷了腳本 & 工具、基礎(chǔ)運維平臺舒帮、開放運維平臺階段会喝，在 2014 年開始智能化運維的探索，并且圍繞可用性玩郊、成本和效率方向的運維目標肢执，在諸多運維場景落地。百度架構(gòu)師译红，智能監(jiān)控業(yè)務(wù)技術(shù)負責人预茄，智能故障自愈方向技術(shù)負責人哈晶晶以百度故障處理場景為例，介紹百度故障預(yù)防的智能 checker 自動攔截異常變更，故障發(fā)現(xiàn)的異常檢測算法耻陕，以及故障自愈的單機房故障自動止損實踐拙徽。

百度 AIOps 技術(shù)架構(gòu)

百度智能運維將 Gartner 中提到 AIOps 的大數(shù)據(jù)和機器學習的理念應(yīng)用于四大運維場景，開發(fā)成一系列的智能模型和策略诗宣，并融入到運維系統(tǒng)中膘怕，幫助提升運維自身的效率，以及解決傳統(tǒng)運維方法所不能解決的挑戰(zhàn)召庞。

首先岛心，為了解決不同業(yè)務(wù)線對運維對象的定義、操作接口篮灼、運維模式差異化的問題忘古，百度提出了指導智能運維的三個原則：

書同文：一致運維“語言”；如運維應(yīng)用诅诱、服務(wù)髓堪、機房、集群的定義娘荡；

車同軌：一致運維“方法”旦袋；如擴縮容執(zhí)行污抬、流量切換執(zhí)行酗宋；

行同倫：一致運維“模式”；如故障診斷策略距境、彈性伸縮策略央拖、流量調(diào)度策略祭阀。

根據(jù)以上 AIOps 中書同文、車同軌鲜戒、行同倫的指導思想专控，百度基礎(chǔ)運維和智能運維平臺也聚焦在：數(shù)據(jù)、工程和策略三個方向遏餐。如下圖所示伦腐。

數(shù)據(jù)方向：運維數(shù)據(jù)倉庫 & 運維知識庫；

工程方向：運維大數(shù)據(jù)平臺 & 運維工程研發(fā)框架失都；

策略方向：運維策略算法平臺和運維大腦（運維策略庫）柏蘑。

該平臺最終支持了故障管理、變更管理粹庞、服務(wù)咨詢和容量管理場景的解決方案咳焚，并且應(yīng)用到百度的內(nèi)部、公有云和私有云客戶庞溜。

運維知識庫

運維知識庫是一個基于 CMDB 革半、數(shù)據(jù)倉庫、知識圖譜技術(shù)，對各類型運維數(shù)據(jù)又官，進行統(tǒng)一的 ETL 處理延刘，形成一個完整的運維數(shù)據(jù)存儲并且提供查詢和使用的服務(wù)。該知識庫系統(tǒng)功能第一要全第二要準六敬，同時對整個架構(gòu)的可用性要求較高碘赖，以便供運維使用。

運維數(shù)據(jù)分為元數(shù)據(jù)觉阅、狀態(tài)數(shù)據(jù)和事件數(shù)據(jù)三大類：

CMDB（ MetaDB ）：存儲運維元數(shù)據(jù)和配置數(shù)據(jù)崖疤，包括不限于產(chǎn)品秘车、人員典勇、應(yīng)用、服務(wù)叮趴、機器割笙、實例、數(shù)據(jù)中心眯亦、網(wǎng)絡(luò)等信息和關(guān)系伤溉；

TSDB（ 基于 HBase ）：存儲運維時序指標數(shù)據(jù)，包括不限于硬件和軟件的可用性指標妻率、資源使用率指標和性能指標乱顾；

EventDB（ 基于 Elasticsearch ）：存儲運維事件數(shù)據(jù)，包括不限于異常報警事件走净、故障處理事件、變更事件等孤里。

運維工程研發(fā)框架

每個運維智能操作都可以分解成感知伏伯、決策、執(zhí)行這樣一個標準流程捌袜，這樣一個流程叫做智能運維機器人说搅。如下圖所示。運維工程研發(fā)框架提供感知虏等、決策弄唧、執(zhí)行過程常用的組件，便于用戶快速構(gòu)建智能運維機器人霍衫。例如這三種組件可以組織成簡單的報警回調(diào)機器人和自動編排機器人套才。報警回調(diào)機器人可以應(yīng)用于故障自愈，自動編排機器人可用于分級變更慕淡。

先來看 Sensor 背伴，Sensor 是運維機器人的眼睛和耳朵，就像人有兩個眼睛和兩個耳朵一樣。運維機器人也可以掛載多個 Sensor 來獲取不同事件源的消息傻寂，比如監(jiān)控的指標數(shù)據(jù)或者是報警事件息尺，變更事件這些，甚至可以是一個定時器疾掰。這些消息可以通過推拉兩種方式被 Sensor 獲取到搂誉。這些消息也可以做一定的聚合，達到閾值再觸發(fā)后續(xù)處理静檬。

再來看 Decision-Maker 炭懊，DM 是運維機器人的大腦，所以為了保證決策的唯一拂檩，機器人有且只能有一個 DM 侮腹，DM 也是使用者主要要擴展實現(xiàn)的部分。除了常見的邏輯判斷規(guī)則之外稻励，未來我們還會加入決策樹等模型父阻，讓運維機器人自主控制決策路徑。

最后看 Executor 望抽，執(zhí)行器是運維機器人的手腳加矛，所以同樣的，執(zhí)行器可以并行的執(zhí)行多個不同的任務(wù)煤篙。執(zhí)行器將運維長流程抽象成狀態(tài)機和工作流兩種模式斟览。這樣框架就可以記住當前的執(zhí)行狀態(tài)，如果運維機器人發(fā)生了故障遷移辑奈，還可以按照已經(jīng)執(zhí)行的狀態(tài)讓長流程斷點續(xù)起苛茂。

運維大腦

有了數(shù)據(jù)和工程就有運維大腦。運維大腦包括異常檢測和故障診斷身害，這兩個部分的共同基礎(chǔ)是基本的恒定閾值異常檢測算法味悄。恒定閾值異常檢測算法利用多種概率模型估計數(shù)據(jù)的概率分布，并由此產(chǎn)生報警閾值塌鸯。在數(shù)據(jù)的特點隨時間發(fā)生改變時侍瑟，算法可以利用最近的數(shù)據(jù)修正概率模型，自動產(chǎn)生新的報警閾值丙猬。

由于許多數(shù)據(jù)具有上下波動的特性涨颜，恒定閾值法不能很好的描述數(shù)據(jù)的特點，所以百度發(fā)展了基于環(huán)比和基于同比的異常檢測方法茧球。環(huán)比的異常檢測方法假設(shè)輸入的時序數(shù)據(jù)總體上比較平滑庭瑰，通過平滑算法預(yù)測數(shù)據(jù)的基準值。然后將數(shù)據(jù)的觀測值與基準值相減即可獲得殘差抢埋，恒定閾值算法應(yīng)用在殘差上就能夠檢測異常弹灭。環(huán)比方法主要用于檢測突增突降類型的異常督暂，但是有些數(shù)據(jù)在發(fā)生異常時上漲或者下跌比較平緩，這就是環(huán)比算法無法勝任的了穷吮。

在故障診斷方面逻翁，百度基于異常檢測算法開發(fā)了指標自動排查算法和多維度分析算法。指標自動排查算法能夠自動掃描所有監(jiān)控指標捡鱼，并篩選出在故障發(fā)生前后發(fā)生劇烈變化的異常指標八回。然后算法將這些異常指標整理為異常 pattern ，并將異常 pattern 排序驾诈，把與故障原因最相關(guān)的異常 pattern 呈現(xiàn)給運維工程師缠诅。

而多維度分析聚焦于帶有多個 tag 的業(yè)務(wù)數(shù)據(jù)。它先利用異常檢測算法標記異常的業(yè)務(wù)數(shù)據(jù)乍迄，然后利用信息理論的方法尋找覆蓋多數(shù)異常的 tag 組合管引。這些 tag 組合常常可以直接指明故障的原因就乓。如果把每個 tag 看作是高維空間的一個維度汉匙，異常數(shù)據(jù)相當于分布在一個超立方體中的點拱烁。尋找覆蓋最多點的子立方體生蚁，所以稱為多維度分析。

故障管理 AIOps 實踐

故障的完整生命周期包括隱患階段戏自、故障發(fā)生邦投、故障發(fā)現(xiàn)、故障止損擅笔、故障恢復志衣、故障分析、故障改進和故障規(guī)范階段猛们，每個階段都可以使用 AIOps 相關(guān)的方法提升故障管理的質(zhì)量念脯。如下圖所示。

故障預(yù)防實踐

互聯(lián)網(wǎng)企業(yè)產(chǎn)品迭代的速度非常之快弯淘，但是有變化就會有風險绿店，2017 年的服務(wù)故障有 54% 是來源于發(fā)布，release 是當之無愧的服務(wù)穩(wěn)定性第一殺手庐橙〖傥穑基于此問題，百度提出了不同的預(yù)防措施：

從測試流量到真實流量态鳖，百度首先部署 sandbox 转培，這種情況下是無損失的；

從一個 IDC 到更多 IDC浆竭，百度挑選流量最少的 IDC 浸须，異常情況下?lián)p失較少惨寿，或者可以快速切流量止損；

從少數(shù)實例到更多的實例：百度先部署某個機房的 1% 删窒，再部署 99% 缤沦。

有了合理的 stage ，就可以基于發(fā)布平臺做自動化檢查的工作易稠。在每個 stage 結(jié)束之后缸废，會自動檢查是否有報警發(fā)生，如果有則會停止變更驶社。

變更通常會檢查可用性指標企量、系統(tǒng)相關(guān)指標和業(yè)務(wù)邏輯類的指標。但是人工檢查的時候會遇到以下問題：指標覆蓋率不會很高亡电，閾值設(shè)置困難導致的漏報 & 誤報届巩。使用智能 Checker 的程序自動檢查方法可以解決這些問題。

故障發(fā)現(xiàn)實踐

我們面臨的業(yè)務(wù)種類繁多份乒，業(yè)務(wù)指標類型眾多恕汇，比如請求數(shù)、拒絕數(shù)或辖、響應(yīng)時間瘾英、流水和訂單等類型的數(shù)據(jù)。不同業(yè)務(wù)不同數(shù)據(jù)的曲線颂暇，波動模式也不一樣缺谴，在監(jiān)控閾值配置時通常會遇到以下的問題：

不同的監(jiān)控項需要應(yīng)用不同的算法；

忙時 & 閑時耳鸯、工作日 & 休息日閾值設(shè)置不同湿蛔；

后期隨著業(yè)務(wù)發(fā)展需要不斷完善閾值配置财喳；

監(jiān)控指標爆發(fā)式增長栗弟，配置成本極高雷厂。

在這樣的背景下，我們對數(shù)據(jù)進行分類缕题，針對不同的場景提供不同的異常檢測算法解決人工配置困難和監(jiān)控漏報 & 誤報的問題宵睦。

周期波動的數(shù)據(jù)酵使，典型場景：廣告收入、搜索流量等业踢。算法：同比基準值檢測；

關(guān)心突變的數(shù)據(jù)礁扮，典型場景：交易訂單知举、流水等瞬沦。算法：環(huán)比基準值檢測；

關(guān)心是否超出了一定波動范圍的數(shù)據(jù)雇锡，典型場景：pvlost逛钻。算法：基于概率的恒定閾值檢測。

故障自愈實踐

人工處理故障通常面臨著響應(yīng)時間不夠迅速锰提、決策不夠精準曙痘、執(zhí)行誤操作的情況發(fā)生。故障自愈是通過自動化立肘、智能化處理故障節(jié)省人力投入屡江，通過設(shè)定的處理流程提高故障處理可靠性，同時降低故障時間赛不，為業(yè)務(wù)可用性保駕護航惩嘉。

單機房故障是業(yè)務(wù)的常見故障，百度的核心業(yè)務(wù)線均實現(xiàn)了 2 到 5 分鐘內(nèi)的故障自愈踢故。如下圖所示文黎，整個這個框架充分利用了前面提到的運維策略庫、運維開發(fā)框架和運維知識庫構(gòu)建單機房故障自愈程序殿较。整個自愈程序也是感知耸峭、決策、執(zhí)行判斷的淋纲。自愈程序分兩個劳闹，一個是機房外網(wǎng)入口故障，通過外網(wǎng)監(jiān)控發(fā)現(xiàn)問題洽瞬，通過 DNS 流量調(diào)度來解決本涕；另一個是在百度內(nèi)網(wǎng)機房故障和業(yè)務(wù)單集群故障，通過業(yè)務(wù)監(jiān)控發(fā)現(xiàn)故障伙窃，通過內(nèi)網(wǎng)流量流量調(diào)度菩颖、服務(wù)降級和主備切換多種手段結(jié)合進行止損。

大規(guī)模數(shù)據(jù)中心變更風險應(yīng)對之道

在大規(guī)模數(shù)據(jù)中心中为障，對生產(chǎn)環(huán)境的變更來自于各個方面晦闰，有機器類操作、機器環(huán)境變更鳍怨、服務(wù)操作等等呻右。這些變更無論是自動化的還是手動的，任何一次變更都會帶來服務(wù)穩(wěn)定性風險鞋喇。百度智能云資深運維架構(gòu)師楊濤從具體的案例出發(fā)声滥，介紹百度應(yīng)對變更風險的防御機制演變及最佳實踐。

變更是什么确徙？

變更就是對于生產(chǎn)環(huán)境醒串，也就是線上環(huán)境進行的任何非只讀動作执桌。比如說最基礎(chǔ)的機房網(wǎng)絡(luò)調(diào)整變更、物理機重裝重啟芜赌、基礎(chǔ)環(huán)境變更仰挣、容器實例的變更等等。這些變更有很多來源缠沈，以前最主要來源是人工膘壶，根據(jù)業(yè)務(wù)需求或者穩(wěn)定性的需求進行；另外一個主要的來源是自動觸發(fā)洲愤，包括發(fā)布流水線颓芭、機器自愈系統(tǒng)、彈性擴縮容等柬赐。

歷史上出現(xiàn)的三次 Case

楊濤首先介紹了百度歷史上出現(xiàn)的三次 Case：

誤操作導致網(wǎng)頁數(shù)據(jù)庫被大規(guī)模刪除亡问；

程序 Bug 導致網(wǎng)頁數(shù)據(jù)庫丟失 1% 數(shù)據(jù)；

程序 Bug 導致少量虛擬機被 Kill 肛宋。

然后從 Case 中分析出了變更的基本模式：

方案審核：所有線上變更方案州藕，均需要進行方案 Review ；

變更檢查：線上變更之前以及完成后酝陈，需要按照檢查列表進行檢查床玻，保證服務(wù)正常；

分級操作：并發(fā)度沉帮、間隔锈死、小流量、抽樣穆壕、分組操作待牵。

但是同時提出，最大的困難是如何指定合理的機制來確保所有人和系統(tǒng)都遵守變更的基本模式粱檀。

變更怎么做洲敢？

楊濤介紹了變更的四大風險，其實本質(zhì)上就是人的風險：

第一是操作不一致的風險

操作內(nèi)容受操作者自身經(jīng)驗茄蚯、知識深度、對服務(wù)的了解程度睦优、穩(wěn)定性意識而不同渗常，從而制定出完全不同的變更方案，并有不同的變更流程汗盘。

解決方案有二皱碘，一是制定流程規(guī)范，變更之后要有變更方案評審隐孽。百度的實踐是一周完成全部變更計劃癌椿，然后再審核健蕊、發(fā)單、檢查踢俄；二是制定標準 SOP 手冊缩功，形成指導日常工作的規(guī)范，所有的人參照標準的 SOP 進行線上變更都办，從而保證操作內(nèi)容一致性嫡锌。

第二是操作不準確的風險

變更方案和具體實際執(zhí)行不一致，特別是手動的誤操作的風險琳钉。這個解決方案就是運維最基本的能力 - 自動化势木。而 SOP 進行自動化的時候，需要有先后順序歌懒，主要根據(jù)如下標準選擇：復雜程度啦桌，風險程度，操作頻次及皂。

第三是流程退化的風險

流程存在退化情況震蒋，剛開始遵守流程，隨著時間的推移躲庄，例外越來越多查剖；另外自動化的腳本或系統(tǒng)，維護成本較高噪窘，其很難實現(xiàn)全流程（如變更自動檢查）笋庄。于是可以通過軟件工程的方式解決問題 – 平臺化。平臺化的要點是：使用 API 關(guān)聯(lián)相關(guān)系統(tǒng)倔监，提供穩(wěn)定有效的服務(wù)直砂，對基礎(chǔ)流程進行標準化，保證流程可執(zhí)行浩习。

以 UItron 為例静暂，它解決了機器管理的三個問題。第一個問題是怎么做機器環(huán)境初始化和怎么保證線上所有機器一致性谱秽。第二個是故障機器自動維修洽蛀，自動恢復服務(wù)。第三個問題是如何在不停服務(wù)維修磁盤故障疟赊。Ultron 中每一臺機器都有一個狀態(tài)機郊供，依賴百度的標準化服務(wù)，當機器發(fā)生硬件故障時進行服務(wù)遷移近哟，維修成功后又加入到資源池驮审，保證容量的穩(wěn)定性。

第四是檢查不充分的風險

解決方法是檢查機制，分為變更后的檢查和變更前的檢查疯淫。變更后的檢查主要是通過聯(lián)動 SLA 系統(tǒng)地来、監(jiān)控系統(tǒng)、冒煙平臺等第三方系統(tǒng)熙掺，進行變更效果檢查未斑。而變更前的檢查，則重點關(guān)注操作風險的防御适掰，在操作尚未實施的時候就將危險操作攔截住颂碧，從而保證線上服務(wù)的穩(wěn)定性。

更多的問題

最后类浪，楊濤以一個開放性的 Case 結(jié)束了本次分享：當自動化平臺不可用的時候载城，人工執(zhí)行了虛機遷移操作，操作錯誤出現(xiàn)故障

這個 Case 引申的問題很多：

如何保證自動化平臺的高可用以及進行風險控制费就；

如何保證人在習慣了自動化平臺后诉瓦，不喪失故障處理的能力。

百度統(tǒng)一前端平臺技術(shù)面面觀

網(wǎng)絡(luò)接入服務(wù)是用戶和后臺服務(wù)間的橋梁力细，對服務(wù)質(zhì)量影響巨大睬澡。百度智能云架構(gòu)師章淼介紹了 BFE 研發(fā)中包括網(wǎng)絡(luò)協(xié)議、網(wǎng)絡(luò)安全眠蚂、高性能系統(tǒng)在內(nèi)的多個技術(shù)方向煞聪，以及提升平臺穩(wěn)定性和研發(fā)效率的研發(fā)方法優(yōu)化。

百度統(tǒng)一前端

百度統(tǒng)一前端 BFE 分為四個版塊逝慧，上游是四層的網(wǎng)關(guān) BGW 昔脯，下面作為七層的轉(zhuǎn)發(fā)網(wǎng)關(guān)具有七大功能，第一是轉(zhuǎn)發(fā)笛臣，包括多種協(xié)議云稚，除了最基本的 HTTP ，HTTPS 沈堡，還有 HTTP2 静陈。第二是流量調(diào)度，一個是外部還有一個內(nèi)網(wǎng)诞丽。第三是安全和反攻擊鲸拥。第四個是海量訪問日志分析與做實時流量報表。

BFE 若干技術(shù)點的深入

章淼將 BFE 的技術(shù)點分了四個方向率拒，首先是接入轉(zhuǎn)發(fā)崩泡，第二點全局流量調(diào)度系統(tǒng)，第三點數(shù)據(jù)分析猬膨，第四點平臺運維和運營。

轉(zhuǎn)發(fā)模型

如下圖所示為 BFE 基礎(chǔ)轉(zhuǎn)發(fā)的步驟。用戶解析域名勃痴，當達到第三步時谒所，可以拿到 IP 地址請求四層網(wǎng)關(guān) , BGW 會把流量轉(zhuǎn)到 BFE。左側(cè)是 BFE 四步要做的工作沛申，首先根據(jù)外網(wǎng)的 IP 或者運營確定租戶劣领，第二步確定它屬于哪一個集群，第三步是 BFE 要確定它屬于哪一個子集群铁材，可以看這右圖尖淘，三個橢圓表示三個不同的 IDC，最后確定把這個流量打到哪一個實例著觉。

全流量調(diào)度系統(tǒng)

全局流量調(diào)度架構(gòu)分為兩層: GTC（外網(wǎng)） + GSLB（內(nèi)網(wǎng)） 村生。下面是內(nèi)網(wǎng)調(diào)度，任務(wù)是把 BFE 接入到流量饼丘，轉(zhuǎn)發(fā)到下流多個應(yīng)用的集群上趁桃。這個機制在 2013 年上線，當出現(xiàn)問題時可以通過內(nèi)網(wǎng)調(diào)度執(zhí)行肄鸽。內(nèi)網(wǎng)的處理百度主要考慮了兩個因素卫病，首先是到 BFE 流量，第二是考慮下游的流量是什么樣的典徘，同時考慮內(nèi)網(wǎng)的因素蟀苛，以本地優(yōu)先為原則，如果出現(xiàn)流量大于本地流量的情況下逮诲，要負載均衡這是內(nèi)網(wǎng)帜平。

數(shù)據(jù)分析

章淼介紹了數(shù)據(jù)分析在 BFE 的價值，首先可以產(chǎn)生業(yè)務(wù)相關(guān)的報表汛骂，還可以用它了解下游集群的健康狀況罕模，另外還可以感知外部網(wǎng)絡(luò)的狀況。

那么 BFE 是如何實現(xiàn)準實時流量報表呢帘瞭？ 百度自己定義了一個系統(tǒng)淑掌，內(nèi)部稱之為 FLOW 。采用多級的方式蝶念，在 BFE 做一次匯計算抛腕，把匯計算結(jié)果打到一級匯聚，打到二級匯聚媒殉，最后把數(shù)據(jù)結(jié)果存十幾個數(shù)據(jù)庫 TSDB 担敌。

平臺運維和運營

運維：保證整個平臺的穩(wěn)定運行；監(jiān)控：轉(zhuǎn)發(fā)引擎對外暴露數(shù)千個變量廷蓉。

運營：提高用戶的滿意度

投入 2 年以上時間研發(fā)用戶平臺全封；

用戶配置在 2 分鐘內(nèi)自動下發(fā)生效；

每個租戶都有獨立的數(shù)據(jù)報表；

完整的用戶手冊刹悴。

百度數(shù)據(jù)庫運維及 Redis 異地多活實踐

最后行楞，由百度智能云架構(gòu)師余杰和百度智能云資深工程師廖洪流共同介紹百度 DBA 的 MySQL 服務(wù)和百度 Redis 異地多活實踐。全面呈現(xiàn)百度 MySQL 服務(wù)生命周期內(nèi)服務(wù)運維保障以及百度在使用分布式緩存系統(tǒng)時會遇到的問題以及對應(yīng)架構(gòu)的演化過程土匀。

數(shù)據(jù)庫高可用

當前百度 MySQL 提供的架構(gòu)為三層架構(gòu)子房，業(yè)務(wù)方面使用的是 BGW 方式以及內(nèi)部的 BNS 服務(wù)，中間層為自研中間層的代理就轧，最底層為 MySQL 集群服務(wù)证杭。如下圖所示。

對 MHA 架構(gòu)的調(diào)研：

MHA（ Master High Availability ）是一套優(yōu)秀的作為 MySQL 高可用性環(huán)境下故障切換的高可用軟件妒御。在考慮不用代理的情況下解愤，使用 Manager 提供的服務(wù)，直接對租戶進行對接携丁，可以處理在一些簡單場景下對于高可用的需求琢歇，且 MHA 內(nèi)部有一些數(shù)據(jù)補齊的能力和處理方式。

MHA 無法滿足百度當前面臨的需求梦鉴，原因如下：

故障識別方面的一些處理方式無法滿足當前遇到的場景李茫；

由于 MHA 對集群內(nèi)部信任關(guān)系的強依賴，出于對安全方面的考慮肥橙，百度不允許在上萬臺機器之間建設(shè)信任關(guān)系魄宏；

還有一些數(shù)據(jù)補齊，選取主庫過程的一些問題存筏。

數(shù)據(jù)庫高可用—故障識別

結(jié)合完整數(shù)據(jù)庫內(nèi)部識別故障宠互。首先收集節(jié)點信息以及狀態(tài)，查看連接數(shù)椭坚，判斷是否是由于 MySQL 實例自身的壓力問題或其他問題導致感知到 DB 有異常的狀態(tài)予跌，進而上升到聯(lián)合從庫的信息檢測當前的主庫是不是正常。檢測感知異常是否是由于假死或壓力過大善茎，然后上升集群內(nèi)部的聯(lián)合診治機制券册。最終上升到整體數(shù)據(jù)庫 APP 檢測機制，以此來決策到底要進行怎樣的切換垂涯。同時烁焙，在切換時要考慮主從之間延時的問題「福基于前面的感知骄蝇，以及識別，做真正的故障處理操骡。

數(shù)據(jù)庫高可用—故障處理

當在前面的識別階段感知到做的主從切換的時候九火，百度會在代理層把主庫完全替換掉赚窃，這個問題在一定程度解決切換的過程中出現(xiàn)主庫重新寫的問題。接下來就是選擇主庫的過程吃既，當真正拓撲完成后考榨，會將完成信息通過網(wǎng)通節(jié)點發(fā)送至代理節(jié)點跨细。這一選取新主庫的過程鹦倚，就是進行故障處理的過程。

數(shù)據(jù)庫高可用—腦裂問題解決

對這一問題的解決方案為引入第三方仲裁機制和機房區(qū)域內(nèi)分機房的監(jiān)測機制冀惭。通過兩個管控節(jié)點震叙，一個是區(qū)域內(nèi)的 Agent ，另外一個是全局管控節(jié)點散休，識別是否可以和其他區(qū)域內(nèi)的實例通信媒楼，進一步判斷是否屬于區(qū)域性的網(wǎng)絡(luò)問題，以及是否會出現(xiàn)腦裂戚丸，通過一系列的機制划址，來制定相應(yīng)的決策。

一旦識別當前出現(xiàn)區(qū)域性網(wǎng)絡(luò)問題限府，Zmaster 可以暫停本區(qū)域有主庫夺颤，屏蔽區(qū)域內(nèi)不可管制的部分實例的信息，杜絕了出現(xiàn)腦裂問題胁勺。

區(qū)域網(wǎng)絡(luò)恢復后世澜，Zmaster 和 Xmaster 會檢測整體主從架構(gòu)，再恢復區(qū)域網(wǎng)絡(luò)代理信息署穗，最終通過自動化方式寥裂，恢復至整體可用。

Redis 異地多活

隨著業(yè)務(wù)發(fā)展案疲，百度需要將服務(wù)部署至多個地域封恰，同時要求數(shù)據(jù)一致。為了滿足這個需求褐啡，百度提出了主地域的概念诺舔，所有數(shù)據(jù)寫到主地域，其他從地域通過 Redis 自帶的復制功能實現(xiàn)同步春贸，這樣就實現(xiàn)了不同地域間的數(shù)據(jù)同步混萝。同時考慮到多地域之間數(shù)據(jù)主機房出現(xiàn)故障能夠止損自愈，百度對整機房切換方案進行了支持萍恕。另外由于考慮到服務(wù)有可能不斷擴容的需求逸嘀，實現(xiàn)了在線擴容。

百度 Redis 架構(gòu)是如圖所示允粤。設(shè)置一個 Reader 崭倘，和地域之間的關(guān)系是 1 ：1 翼岁。每一個 Redis 只對應(yīng)一個 Reader 溪食，而這個 Reader 同步數(shù)據(jù)的目的地不是其他地域的 Redis 始鱼，而是一個消息中間件，通過消息中間件的轉(zhuǎn)發(fā)能力亭螟，實現(xiàn)地域的同步残家，而所有的 Reader 只負責將本地的信息傳到 Redis榆俺。

但是在真正實踐方案時會遇到什么技術(shù)難點？

Redis 跟 Reader 數(shù)據(jù)同步采取什么方案坞淮？很自然用 Redis 主從同步來做茴晋。但是主從同步是可靠的嗎？先簡單回顧一下 Redis 原生的增量同步的方案是什么回窘，原生的增量同步是數(shù)據(jù)寫入了 Redis Master诺擅，Redis Master 有一個環(huán)形隊列，當 Redis 跟 Master 進行數(shù)據(jù)同步的時候啡直，它會先嘗試使用它當前同步點烁涌，就是 Offset，當這個 Offset 在這個里面會一次性同步給 Slave酒觅。但是這里面存在什么問題呢撮执？當你的 Offset 不在這個序列里面，這個存在全量同步阐滩，同時還有一個問題在于它為了保證數(shù)據(jù)一致性二打，Slave 進行全量同步的時候，先將自己本身數(shù)據(jù)清掉掂榔，清掉以后再進行同步继效。

所以針對這個問題百度做了一些思考，在 AOF 基礎(chǔ)上做了一些調(diào)整装获。采用按照一定大小進行切割的方式瑞信，同時引入 OP_ID 的概念。每一次操作名由 OP_ID 決定穴豫，這樣從庫拿原生的命令凡简，還有 OP_ID 的信息，如果主從關(guān)系斷了精肃，它會拿現(xiàn)在 OPID 請求 Master秤涩，Master 會查找，找到這個 OP_ID司抱，并基于 AOF 的數(shù)據(jù)進行同步筐眷。

來源：http://www.infoq.com/cn/articles/Baidu-AIOps-Redis?utm_source=articles_about_NoSQL&utm_medium=link&utm_campaign=NoSQL