隨著大數據、人工智能、雲計算技術的日漸成熟和飛速發展，傳統的運維技術和解決方案已經不能滿足需求，智能運維已成為運維的熱點領域。同時，為了滿足大流量、用戶高質量體驗和用戶分佈地域廣的互聯網應用場景，大型分佈式系統的部署方式也成為了高效運維的必然之選。如何提升運維的能力和效率，是保障業務高可用所面臨的最大挑戰。
6 月 23 日，由百度開發者中心、百度雲智學院主辦，極客邦科技承辦的第 79 期百度技術沙龍邀請了來自百度智能雲主任架構師王棟，百度智能雲架構師哈晶晶，百度智能雲資深運維架構師楊濤，百度智能雲架構師章淼，百度智能雲架構師餘傑及百度智能雲資深工程師廖洪流六位講師，分享百度在 AIOps、DevOps 上的實戰經驗，並以百度統一前端接入（Baidu Front End, BFE）、數據庫以及 Redis 三個具體系統為例，介紹百度在系統架構設計和變更、監控、故障處理和性能管理等貫穿線上系統生命週期的運維層面上，如何保證系統的高可用。
1 高可用性系統的架構與運維實踐
百度智能雲主任架構師王棟做了開場演講。他首先介紹了百度運維發展的歷史，主要分為三個階段：一、基礎運維階段。提供機器管理，服務管理和權限管理，保證線上基本服務運行，並對線上基本數據管理進行監控。二、開放運維時代。以開放 API 的形式，把第一階段業務層面的運維交給各個業務部門。但是面臨著垂直場景重複製造輪子，所積累運維知識和數據難以匯聚的問題。三、智能運維階段。構建統一的運維知識庫，一致的運維工具開發框架以及全局可見的算法複用平臺。
下圖為百度智能運維整體框架圖。最下方是基礎運維平臺，提供最基本的運維能力，在此平臺的基礎上構建運維開發框架、運維知識庫和運維策略庫，在面臨不同的場景和不同的業務將所有場景的算法抽樣出來提供服務。
智能運維和要解決的問題場景
王棟現場對運維問題的複雜程度做了區分，如下圖所示。縱軸表示問題的難易程度，橫軸表示問題發生的頻率。這樣運維問題可以總結分成四個象限，對於每一個象限採取不同的應對措施。左上角低頻高複雜問題，可以希望智能輔助決策，增強人的能力；右上角高頻複雜問題，希望達到智能的決策，智能執行，並可遷移，而人只需做一些基本輔助工作即可；左下角低頻且簡單的場景，這是比較好解決的問題，只需把問題的解決策略規範化、流程化；右下角高頻但是簡單問題可通過自動化、自助化將問題解決。
百度運維經歷了腳本 & 工具、基礎運維平臺、開放運維平臺階段，在 2014 年開始智能化運維的探索，並且圍繞可用性、成本和效率方向的運維目標，在諸多運維場景落地。百度架構師，智能監控業務技術負責人，智能故障自愈方向技術負責人哈晶晶以百度故障處理場景為例，介紹百度故障預防的智能 checker 自動攔截異常變更，故障發現的異常檢測算法，以及故障自愈的單機房故障自動止損實踐。
百度智能運維將 Gartner 中提到 AIOps 的大數據和機器學習的理念應用於四大運維場景，開發成一系列的智能模型和策略，並融入到運維繫統中，幫助提升運維自身的效率，以及解決傳統運維方法所不能解決的挑戰。
首先，為了解決不同業務線對運維對象的定義、操作接口、運維模式差異化的問題，百度提出了指導智能運維的三個原則：
書同文：一致運維“語言”；如運維應用、服務、機房、集群的定義
車同軌：一致運維“方法”；如擴縮容執行、流量切換執行
行同倫：一致運維“模式”；如故障診斷策略、彈性伸縮策略、流量調度策略
根據以上 AIOps 中書同文、車同軌、行同倫的指導思想，百度基礎運維和智能運維平臺也聚焦在：數據、工程和策略三個方向。如下圖所示。
數據方向：運維數據倉庫 & 運維知識庫
工程方向：運維大數據平臺 & 運維工程研發框架
策略方向：運維策略算法平臺和運維大腦（運維策略庫）
該平臺最終支持了故障管理、變更管理、服務諮詢和容量管理場景的解決方案，並且應用到百度的內部、公有云和私有云客戶。
運維知識庫
運維知識庫是一個基於 CMDB、數據倉庫、知識圖譜技術，對各類型運維數據，進行統一的 ETL 處理，形成一個完整的運維數據存儲並且提供查詢和使用的服務。該知識庫系統功能第一要全第二要準，同時對整個架構的可用性要求較高，以便供運維使用。
運維數據分為元數據、狀態數據和事件數據三大類：
CMDB（MetaDB）：存儲運維元數據和配置數據，包括不限於產品、人員、應用、服務、機器、實例、數據中心、網絡等信息和關係
TSDB（基於 HBase）：存儲運維時序指標數據，包括不限於硬件和軟件的可用性指標、資源使用率指標和性能指標
EventDB（基於 Elasticsearch）：存儲運維事件數據，包括不限於異常報警事件、故障處理事件、變更事件等
運維工程研發框架
每個運維智能操作都可以分解成感知、決策、執行這樣一個標準流程，這樣一個流程叫做智能運維機器人。如下圖所示。運維工程研發框架提供感知、決策、執行過程常用的組件，便於用戶快速構建智能運維機器人。例如這三種組件可以組織成簡單的報警回調機器人和自動編排機器人。報警回調機器人可以應用於故障自愈，自動編排機器人可用於分級變更。
先來看 Sensor，Sensor 是運維機器人的眼睛和耳朵，就像人有兩個眼睛和兩個耳朵一樣。運維機器人也可以掛載多個 Sensor 來獲取不同事件源的消息，比如監控的指標數據或者是報警事件，變更事件這些，甚至可以是一個定時器。這些消息可以通過推拉兩種方式被 Sensor 獲取到。這些消息也可以做一定的聚合，達到閾值再觸發後續處理。
再來看 Decision-Maker，DM 是運維機器人的大腦，所以為了保證決策的唯一，機器人有且只能有一個 DM，DM 也是使用者主要要擴展實現的部分。除了常見的邏輯判斷規則之外，未來我們還會加入決策樹等模型，讓運維機器人自主控制決策路徑。
最後看 Executor，執行器是運維機器人的手腳，所以同樣的，執行器可以並行的執行多個不同的任務。執行器將運維長流程抽象成狀態機和工作流兩種模式。這樣框架就可以記住當前的執行狀態，如果運維機器人發生了故障遷移，還可以按照已經執行的狀態讓長流程斷點續起。
運維大腦
有了數據和工程就有運維大腦。運維大腦包括異常檢測和故障診斷，這兩個部分的共同基礎是基本的恆定閾值異常檢測算法。恆定閾值異常檢測算法利用多種概率模型估計數據的概率分佈，並由此產生報警閾值。在數據的特點隨時間發生改變時，算法可以利用最近的數據修正概率模型，自動產生新的報警閾值。
由於許多數據具有上下波動的特性，恆定閾值法不能很好的描述數據的特點，所以百度發展了基於環比和基於同比的異常檢測方法。環比的異常檢測方法假設輸入的時序數據總體上比較平滑，通過平滑算法預測數據的基準值。然後將數據的觀測值與基準值相減即可獲得殘差，恆定閾值算法應用在殘差上就能夠檢測異常。環比方法主要用於檢測突增突降類型的異常，但是有些數據在發生異常時上漲或者下跌比較平緩，這就是環比算法無法勝任的了。
在故障診斷方面，百度基於異常檢測算法開發了指標自動排查算法和多維度分析算法。指標自動排查算法能夠自動掃描所有監控指標，並篩選出在故障發生前後發生劇烈變化的異常指標。然後算法將這些異常指標整理為異常 pattern，並將異常 pattern 排序，把與故障原因最相關的異常 pattern 呈現給運維工程師。
而多維度分析聚焦於帶有多個 tag 的業務數據。它先利用異常檢測算法標記異常的業務數據，然後利用信息理論的方法尋找覆蓋多數異常的 tag 組合。這些 tag 組合常常可以直接指明故障的原因。如果把每個 tag 看作是高維空間的一個維度，異常數據相當於分佈在一個超立方體中的點。尋找覆蓋最多點的子立方體，所以稱為多維度分析。
故障管理 AIOps 實踐
故障的完整生命週期包括隱患階段、故障發生、故障發現、故障止損、故障恢復、故障分析、故障改進和故障規範階段，每個階段都可以使用 AIOps 相關的方法提升故障管理的質量。如下圖所示。
故障預防實踐
互聯網企業產品迭代的速度非常之快，但是有變化就會有風險，2017 年的服務故障有 54% 是來源於發佈，release 是當之無愧的服務穩定性第一殺手。基於此問題，百度提出了不同的預防措施：
從測試流量到真實流量，百度首先部署 sandbox，這種情況下是無損失的
從一個 IDC 到更多 IDC，百度挑選流量最少的 IDC，異常情況下損失較少，或者可以快速切流量止損
從少數實例到更多的實例：百度先部署某個機房的 1%，再部署 99%
有了合理的 stage，就可以基於發佈平臺做自動化檢查的工作。在每個 stage 結束之後，會自動檢查是否有報警發生，如果有則會停止變更。
變更通常會檢查可用性指標、系統相關指標和業務邏輯類的指標。但是人工檢查的時候會遇到以下問題：指標覆蓋率不會很高，閾值設置困難導致的漏報 & 誤報。使用智能 Checker 的程序自動檢查方法可以解決這些問題。
故障發現實踐
我們面臨的業務種類繁多，業務指標類型眾多，比如請求數、拒絕數、響應時間、流水和訂單等類型的數據。不同業務不同數據的曲線，波動模式也不一樣，在監控閾值配置時通常會遇到以下的問題：1. 不同的監控項需要應用不同的算法；2. 忙時 & 閒時、工作日 & 休息日閾值設置不同；3. 後期隨著業務發展需要不斷完善閾值配置；4. 監控指標爆發式增長，配置成本極高。
在這樣的背景下，我們對數據進行分類，針對不同的場景提供不同的異常檢測算法解決人工配置困難和監控漏報 & 誤報的問題。
週期波動的數據，典型場景：廣告收入、搜索流量等。算法：同比基準值檢測
關心突變的數據，典型場景：交易訂單、流水等。算法：環比基準值檢測
關心是否超出了一定波動範圍的數據，典型場景：pvlost。算法：基於概率的恆定閾值檢測。
故障自愈實踐
人工處理故障通常面臨著響應時間不夠迅速、決策不夠精準、執行誤操作的情況發生。故障自愈是通過自動化、智能化處理故障節省人力投入，通過設定的處理流程提高故障處理可靠性，同時降低故障時間，為業務可用性保駕護航。
單機房故障是業務的常見故障，百度的核心業務線均實現了 2 到 5 分鐘內的故障自愈。如下圖所示，整個這個框架充分利用了前面提到的運維策略庫、運維開發框架和運維知識庫構建單機房故障自愈程序。整個自愈程序也是感知、決策、執行判斷的。自愈程序分兩個，一個是機房外網入口故障，通過外網監控發現問題，通過 DNS 流量調度來解決；另一個是在百度內網機房故障和業務單集群故障，通過業務監控發現故障，通過內網流量流量調度、服務降級和主備切換多種手段結合進行止損。
3 大規模數據中心變更風險應對之道
在大規模數據中心中，對生產環境的變更來自於各個方面，有機器類操作、機器環境變更、服務操作等等。這些變更無論是自動化的還是手動的，任何一次變更都會帶來服務穩定性風險。百度智能雲資深運維架構師楊濤從具體的案例出發，介紹百度應對變更風險的防禦機制演變及最佳實踐。
變更是什麼？
變更就是對於生產環境，也就是線上環境進行的任何非只讀動作。比如說最基礎的機房網絡調整變更、物理機重裝重啟、基礎環境變更、容器實例的變更等等。這些變更有很多來源，以前最主要來源是人工，根據業務需求或者穩定性的需求進行；另外一個主要的來源是自動觸發，包括髮布流水線、機器自愈系統、彈性擴縮容等。
歷史上出現的三次 Case
楊濤首先介紹了百度歷史上出現的三次 Case：
誤操作導致網頁數據庫被大規模刪除
程序 Bug 導致網頁數據庫丟失 1% 數據
程序 Bug 導致少量虛擬機被 Kill
然後從 Case 中分析出了變更的基本模式：
方案審核：所有線上變更方案，均需要進行方案 Review
變更檢查：線上變更之前以及完成後，需要按照檢查列表進行檢查，保證服務正常
分級操作：併發度、間隔、小流量、抽樣、分組操作
但是同時提出，最大的困難是如何指定合理的機制來確保所有人和系統都遵守變更的基本模式。
變更怎麼做？
楊濤介紹了變更的四大風險，其實本質上就是人的風險：
第一是操作不一致的風險
操作內容受操作者自身經驗、知識深度、對服務的瞭解程度、穩定性意識而不同，從而制定出完全不同的變更方案，並有不同的變更流程。
解決方案有二，一是制定流程規範，變更之後要有變更方案評審。百度的實踐是一週完成全部變更計劃，然後再審核、發單、檢查；二是制定標準 SOP 手冊，形成指導日常工作的規範，所有的人參照標準的 SOP 進行線上變更，從而保證操作內容一致性。
第二是操作不準確的風險
變更方案和具體實際執行不一致，特別是手動的誤操作的風險。這個解決方案就是運維最基本的能力 - 自動化。而 SOP 進行自動化的時候，需要有先後順序，主要根據如下標準選擇：複雜程度，風險程度，操作頻次。
第三是流程退化的風險
流程存在退化情況，剛開始遵守流程，隨著時間的推移，例外越來越多；另外自動化的腳本或系統，維護成本較高，其很難實現全流程（如變更自動檢查）。於是可以通過軟件工程的方式解決問題 – 平臺化。平臺化的要點是：使用 API 關聯相關係統，提供穩定有效的服務，對基礎流程進行標準化，保證流程可執行。
以 UItron 為例，它解決了機器管理的三個問題。第一個問題是怎麼做機器環境初始化和怎麼保證線上所有機器一致性。第二個是故障機器自動維修，自動恢復服務。第三個問題是如何在不停服務維修磁盤故障。Ultron 中每一臺機器都有一個狀態機，依賴百度的標準化服務，當機器發生硬件故障時進行服務遷移，維修成功後又加入到資源池，保證容量的穩定性。
第四是檢查不充分的風險
解決方法是檢查機制，分為變更後的檢查和變更前的檢查。變更後的檢查主要是通過聯動 SLA 系統、監控系統、冒煙平臺等第三方系統，進行變更效果檢查。
而變更前的檢查，則重點關注操作風險的防禦，在操作尚未實施的時候就將危險操作攔截住，從而保證線上服務的穩定性。
更多的問題
最後，楊濤以一個開放性的 Case 結束了本次分享：
當自動化平臺不可用的時候，人工執行了虛機遷移操作，操作錯誤出現故障
這個 Case 引申的問題很多：
如何保證自動化平臺的高可用以及進行風險控制
如何保證人在習慣了自動化平臺後，不喪失故障處理的能力
網絡接入服務是用戶和後臺服務間的橋樑，對服務質量影響巨大。百度智能雲架構師章淼介紹了 BFE 研發中包括網絡協議、網絡安全、高性能系統在內的多個技術方向，以及提升平臺穩定性和研發效率的研發方法優化。
百度統一前端 BFE 分為四個版塊，上游是四層的網關 BEW，下面作為七層的轉發網關具有七大功能，第一是轉發，包括多種協議，除了最基本的 HTTP，HTTPS，還有 HTTP2。第二是流量調度，一個是外部還有一個內網。第三是安全和反攻擊。第四個是海量訪問日誌分析與做實時流量報表。
BFE 若干技術點的深入
章淼將 BFE 的技術點分了四個方向，首先是接入轉發，第二點全局流量調度系統，第三點數據分析，第四點平臺運維和運營。
轉發模型
如下圖所示為 BFE 基礎轉發的步驟。用戶解析域名，當達到第三步時，可以拿到 IP 地址請求四層網關 BW，BW 會把流量轉到 BFE。左側是 BFE 四步要做的工作，首先根據外網的 IP 或者運營確定租戶，第二步確定它屬於哪一個集群，第三步是 BFE 要確定它屬於哪一個子集群，可以看這右圖，三個橢圓表示三個不同的 IDC，最後確定把這個流量打到哪一個實例。
全流量調度系統
全局流量調度架構分為兩層: GTC(外網) + GSLB(內網) 。下面是內網調度，任務是把 BFE 接入到流量，轉發到下流多個應用的集群上。這個機制在 2013 年上線，當出現問題時可以通過內網調度執行。內網的處理百度主要考慮了兩個因素，首先是到 BFE 流量，第二是考慮下游的流量是什麼樣的，同時考慮內網的因素，以本地優先為原則，如果出現流量大於本地流量的情況下，要負載均衡這是內網。
數據分析
章淼介紹了數據分析在 BFE 的價值，首先可以產生業務相關的報表，還可以用它瞭解下游集群的健康狀況，另外還可以感知外部網絡的狀況。
那麼 BFE 是如何實現準實時流量報表呢？ 百度自己定義了一個系統，內部稱之為 FLOW。採用多級的方式，在 BFE 做一次匯計算，把匯計算結果打到一級匯聚，打到二級匯聚，最後把數據結果存十幾個數據庫 TSDB。
平臺運維和運營
運維：保證整個平臺的穩定運行
監控：轉發引擎對外暴露數千個變量
運營：提高用戶的滿意度
投入 2 年以上時間研發用戶平臺
用戶配置在 2 分鐘內自動下發生效
每個租戶都有獨立的數據報表
完整的用戶手冊
5 百度數據庫運維及 Redis 異地多活實踐
最後，由百度智能雲架構師餘傑和百度智能雲資深工程師廖洪流共同介紹百度 DBA 的 MySQL 服務和百度 Redis 異地多活實踐。全面呈現百度 MySQL 服務生命週期內服務運維保障以及百度在使用分佈式緩存系統時會遇到的問題以及對應架構的演化過程。
數據庫高可用
當前百度 MySQL 提供的架構為三層架構，業務方面使用的是 BGW 方式以及內部的 BNS 服務，中間層為自研中間層的代理，最底層為 MySQL 集群服務。如下圖所示。
對 MHA 架構的調研：
MHA（Master High Availability）是一套優秀的作為 MySQL 高可用性環境下故障切換的高可用軟件。在考慮不用代理的情況下，使用 Manager 提供的服務，直接對租戶進行對接，可以處理在一些簡單場景下對於高可用的需求，且 MHA 內部有一些數據補齊的能力和處理方式。
MHA 無法滿足百度當前面臨的需求，原因如下：
故障識別方面的一些處理方式無法滿足當前遇到的場景；
由於 MHA 對集群內部信任關係的強依賴，出於對安全方面的考慮，百度不允許在上萬臺機器之間建設信任關係；
還有一些數據補齊，選取主庫過程的一些問題。
數據庫高可用—故障識別
結合完整數據庫內部識別故障。首先收集節點信息以及狀態，查看連接數，判斷是否是由於 MySQL 實例自身的壓力問題或其他問題導致感知到 DB 有異常的狀態，進而上升到聯合從庫的信息檢測當前的主庫是不是正常。檢測感知異常是否是由於假死或壓力過大，然後上升集群內部的聯合診治機制。最終上升到整體數據庫 APP 檢測機制，以此來決策到底要進行怎樣的切換。同時，在切換時要考慮主從之間延時的問題。基於前面的感知，以及識別，做真正的故障處理。
數據庫高可用—故障處理
當在前面的識別階段感知到做的主從切換的時候，百度會在代理層把主庫完全替換掉，這個問題在一定程度解決切換的過程中出現主庫重新寫的問題。接下來就是選擇主庫的過程，當真正拓撲完成後，會將完成信息通過網通節點發送至代理節點。這一選取新主庫的過程，就是進行故障處理的過程。
數據庫高可用—腦裂問題解決
對這一問題的解決方案為引入第三方仲裁機制和機房區域內分機房的監測機制。通過兩個管控節點，一個是區域內的 Agent，另外一個是全局管控節點，識別是否可以和其他區域內的實例通信，進一步判斷是否屬於區域性的網絡問題，以及是否會出現腦裂，通過一系列的機制，來制定相應的決策。
一旦識別當前出現區域性網絡問題，Zmaster 可以暫停本區域有主庫，屏蔽區域內不可管制的部分實例的信息，杜絕了出現腦裂問題。
區域網絡恢復後，Zmaster 和 Xmaster 會檢測整體主從架構，再恢復區域網絡代理信息，最終通過自動化方式，恢復至整體可用。
Redis 異地多活
隨著業務發展，百度需要將服務部署至多個地域，同時要求數據一致。為了滿足這個需求，百度提出了主地域的概念，所有數據寫到主地域，其他從地域通過 Redis 自帶的複製功能實現同步，這樣就實現了不同地域間的數據同步。同時考慮到多地域之間數據主機房出現故障能夠止損自愈，百度對整機房切換方案進行了支持。另外由於考慮到服務有可能不斷擴容的需求，實現了在線擴容。
百度 Redis 架構是如圖所示。設置一個 Reader，和地域之間的關係是 1：1。每一個 Redis 只對應一個 Reader，而這個 Reader 同步數據的目的地不是其他地域的 Redis，而是一個消息中間件，通過消息中間件的轉發能力，實現地域的同步，而所有的 Reader 只負責將本地的信息傳到 Redis。
但是在真正實踐方案時會遇到什麼技術難點？
Redis 跟 Reader 數據同步採取什麼方案？很自然用 Redis 主從同步來做。但是主從同步是可靠的嗎？先簡單回顧一下 Redis 原生的增量同步的方案是什麼，原生的增量同步是數據寫入了 Redis Master，Redis Master 有一個環形隊列，當 Redis 跟 Master 進行數據同步的時候，它會先嚐試使用它當前同步點，就是 Offset，當這個 Offset 在這個裡面會一次性同步給 Slave。但是這裡面存在什麼問題呢？當你的 Offset 不在這個序列裡面，這個存在全量同步，同時還有一個問題在於它為了保證數據一致性，Slave 進行全量同步的時候，先將自己本身數據清掉，清掉以後再進行同步。
所以針對這個問題百度做了一些思考，在 AOF 基礎上做了一些調整。採用按照一定大小進行切割的方式，同時引入 OP_ID 的概念。每一次操作名由 OP_ID 決定，這樣從庫拿原生的命令，還有 OP_ID 的信息，如果主從關係斷了，它會拿現在 OPID 請求 Master，Master 會查找，找到這個 OP_ID，並基於 AOF 的數據進行同步。
閱讀更多 InfoQ 的文章
