熊亞軍開篇：在超級網際網路公司，隨著伺服器規模都早早邁過 10 萬台量級，加之業務模式的多樣性和 it 架構的雲化遷移，其 it 運維團隊面臨的挑戰與日俱增，常規的系統和經驗都需要不斷迭代更新。
首先我們先來看看超級網際網路公司的業務架構示例圖：
在超級網際網路公司中，通常不同的層次都由不同的團隊來負責運維管理，同層次不同的硬體/系統/應用都由不同的小組來負責運維管理。
就基礎設施即服務這層來說，隨著it裝置規模的不斷增加，it 裝置故障的告警種類與告警數量也隨之急劇增加。
告警的多面性、冗餘性、耦合性，導致某些核心層面的故障會引起大面積告警的現象，而這些告警又有可能分屬不同小組，運維人員處理故障會增加排查問題的難度以及增加小組間溝通成本。
同時因為對故障資訊缺乏統一的管理，無法對告警系統進行反饋優化，致使誤報漏報頻出。同樣也無法進行全面的故障資訊統計分析，不知道如何對基礎設施資源進行風險管理。
眾所周知，it基礎設施層的運維工作，直接影響公司服務穩定性。一次服務中斷事件便會對公司造成極大的經濟損失。
但正如上述現狀描述中提到的問題：
告警系統缺乏有效的反饋機制進行系統優化，同時缺少全面有效的故障資訊沉澱，無法幫助預算與評估採購系統進行合理採購。
這些都極大約束了運維水平的與時俱進，新的方**和新的運維技術有迫切的內部需求。
我們收斂彙總一下複雜運維場景下的主要痛點：基於上述背景下的痛點問題，一套以故障定位為核心的運維生態體系的建立便成為高逼格的不可或缺：
而在這套生態體系中，故障自動定位技術便是體系是否能夠成功建立的核心要素。
故障根因自動定位簡要科普
故障根因自動定位系統為人工智慧的分支，屬於診斷性專家系統，專家系統通常包含:
其中最重要的是知識庫和推理機。知識庫用於專家經驗的儲存，是一種靜態規則，推理機根據現象結合知識庫中的規則反覆推理得出結論。規則集的組成形式有多種方式，本文重點介紹的是二叉決策樹。
故障根因定位系統的設計架構系統
故障根因自動定位系統主要由監控系統、接入系統、推理系統、通告系統四個部分組成，分別的功能如下：
看個實際案例，看看到底能解決啥問題？
故障定位演算法採用機器學習中的二叉決策樹的方式實現:
以某公司網路故障根因定位為例，實現上述目標需要三步:
第一步：將問題排障過程的經驗提煉成二叉決策樹；看看推理樹是怎麼構建的呢？根據某公司目前網路故障時的告警特點和網路工程師運維的特點，得出下面的一些結論，而這些結論可幫助我們構建出經驗推理樹。第二步：將告警資訊按照時間分片演算法進行分類分組；
第三步：將分組的告警資訊輸出給決策樹進行自動推理輸出推理結果。
a、告警資訊是分層次的:
第一層是交換機級別，如router_id、cpu、tm告警；b、每一層的告警又可分為原子告警，衍生性告警。比如：第二層次是板卡告警，比如板卡晶元問題，板卡故障；
第三層次是埠告警，link-new告警等與埠相關的告警；
第三層告警，link-new便是衍生性的告警，而port down的告警為原子告警，即port down了一定會有link-new的告警，反之不然。根據以上結論，故障定位的原則為：重要性從最高層往最低層報，每層中重要性從原子告警到衍生性告警報。比如:
收到了router_id，port down, link-new的告警，那麼只需報router_id的告警；引入故障追蹤列表，比如第二層的【board告警】引起第三層的告警【port、ospf、link-new】，每個故障追蹤列表形成乙個case，即case的生成過程不是以某交換機為單位，而是以故障追蹤列表為單位。如果只有port down, link-new的告警，就重點報`port;
down的告警，如果只有link-new的告警，則只能報link-new`的告警。
根據上述的分析，設計推理樹如下圖所示：
沒太看明白？看看推理樹的構建原則和實現方式
a、推理樹的構建有以下四個原則：
原則一：告警從高層向底層，在邏輯層次上面，越根源性的告警越先判斷。
例如:
a出現問題必然導致b出現問題，b出現問題必然導致c出現問題，在邏輯層次上面，a的根源性最高，當a、b、c告警同時到達，先判斷a，判定a、b、c故障的根因為a。在告警關聯度上面，越明確關聯的告警越先判斷。
例如:
故障a對應有a1、a2、a3三種告警，關聯度依次為a1 > a2 > a3，先判斷a1，由a1直接確定a1、a2、a3的故障根因為a。原則二：從原子到衍生告警。
原則三：推理樹的建立根據告警來定。
原則四：驗證規則，根據經驗和知識庫來定。
b、推理過程實現有以下三種方式：
方式一：
給出特徵 —> 推理機 —> 結論 —> 驗證 —> 發出結果方式二:
自主收集特徵 —> 推理機 —> 結論 —> 驗證 —> 發出結果方式三:
資料 —> 根據特徵設計的推理機 —> 結論 —> 驗證 —> 發出結果簡單來說，方式一就是半人工方式、方式二就是簡單機器學習方式、方式三就是智慧型機器學習方式。
看完是不是有點小激動，想動手試試如何構建一套智慧型故障根因定位系統，需要如下幾個步驟:
第一步: 構建cmdb
cmdb是監控系統的基礎，資料部分通常分為靜態、動態兩大類.
就網路裝置而言，靜態資料通常包括：
機框動態資料通常包括：矩陣板卡
模組埠
ip位址第二步: 告警標準化需要統一告警資訊的格式，便於故障定位系統提取關鍵特徵級並進行分類分組。路由埠狀態
埠流量
第三步:梳理告警關係
理清告警之間的關聯關係，關聯關係需要是邏輯上面的，形成必要的關係，例如a是b上游模組，a出現問題必然會導致b出現問題。
第四步: 構建推理樹
根據人工故障定位判斷邏輯，構建推理樹，設定每個推理節點的判決條件。
ok啦，做完以上幾步，您就搭建了乙個簡單的故障根因自動定位系統，通過對每個推理節點判斷條件的不斷優化，您可以不斷提公升故障自動定位準確率，讓您的運維效率得到大幅提公升，it運營水平逐步與bat等超級網際網路公司運營水平對齊。
呀呀語音 運維經理 智慧型語音在私域場景下的一片藍海
概念 我們所有的使用者都去過飯館點餐吃飯，可以試想，乙個語音機械人幫助到店使用者完成選單推薦 輔助使用者關於 等基礎問題 完成使用者的結賬行為。我們會發現整個流程適用於所有的餐館行業，機械人代替人工，滿足了使用者的基本點菜需求，當前場景就是典型的公域內的智慧型語音互動場景。那私域的語音場景是什麼？是...
如何在一分鐘內實現微服務系統下的架構視覺化
隨著企業進行微服務架構改造，系統架構複雜度越來越高，架構變化日益頻繁，微服務改造後的實際架構模型可能與預期已經產生了巨大差異，架構師或系統運維人員很難準確記憶所有資源例項的構成和互動情況 其次，系統架構在動態演化過程中可能引入了一些不可靠的因素，比如弱依賴變強依賴 區域性容量不足 系統耦合過重等，給...
如何在一分鐘內實現微服務系統下的架構視覺化
我們每次在面對系統改造 業務大促以及穩定性治理工作之前，都會通過梳理架構圖的方式，呈現系統架構中個元件之間的互動方式，架構視覺化能夠清晰的協助我們識別架構中存在的問題以及建立高可用的系統。隨著企業進行微服務架構改造，系統架構複雜度越來越高，架構變化日益頻繁，微服務改造後的實際架構模型可能與預期已經產...