Exam MD-100: Windows 10

為拯救網工們的頭髮，祭出了個大殺器 —— 基於意圖的主動運維繫統，並小試牛刀，輕鬆解決了網工們頭疼的 “ 幽靈丟包 ” 問題。具體來講，這個架構長得這個樣子：

左半部分下方是由自動化引擎構成的自動化層，它依據一定策略從復雜的多雲基礎架構中收集足夠的現場數據供給它的上一層—— 由洞見引擎構成的洞見層，後者對數據進行處理、分析和判斷，輔助人類做出正確的決策（ 我們稱為“ 意圖” ）。這些意圖可能是對數據收集策略的調整，也可能是直接實現某個主動運維的目標，總之在形成後都會被發送給下面的自動化層，它們被轉換為具體的執行策略，由自動化引擎驅動執行，並同時繼續收集數據反饋給洞見層完成狀態監控，從而最終形成一個不斷自我優化的閉環。 “ 幽靈丟包” 問題就是通過自動化層的AppDynamics Agent 探針收集了大量數據，在洞見層的洞見引擎AppDynamics 對這些數據分析出應用結構和結構內每一層應用體驗的定量化指標，最終找到導致端到端體驗惡化的精確位置（ 即“ 診斷意圖” ），再交給自動化層的自動化引擎ACI APIC 控制器進行底層精細化監測和診斷，從而最終抓獲幽靈丟包元兇。

其實我們看到這個例子中ACI APIC 的故障診斷工具箱內還是傳統的端口計數、差錯統計、Traceroute 等，但有了洞見層明確的診斷意圖加持，立刻功力倍增，瞬間搞定了傳統要幾天才能解決的難題。如果能把自動化層收集數據的手段進一步升級，比如引入大數據收集手段；把洞見層處理和分析數據的手段升級為大數據分佈式處理、機器學習和人工智能，那會是一幅什麼圖景呢？不用憑空想像，因為這就是 Cisco 智能主動運維繫統 Nexus Insights 。

我們就從 Nexus Insights 的自動化層如何實現大數據收集策略開始。

自動化層為什麼要加持大數據呢？我們常常把網絡流量比喻為道路交通（ 在英語裡甚至是同一個詞 Traffic ），那發現網絡異常就相當於交警檢查交通違章。傳統收集數據的手段往往是一個收集器輪流採集網絡節點數據，或者發出探測包沿線探測（ 比如ping、traceroute 等），這就好比交警輪流到路口檢查闖紅燈和超速，或者騎著摩託在路上巡邏，撞見了就抓、撞不見也沒什麼辦法。在網絡世界中也一樣，在收集器輪詢的空隙、探測包之間的間隔以及探測包沒能覆蓋的路徑上，到處都有可能存在導致用戶體驗惡化的瞬斷、丟包，突發擁塞、延遲和抖動，也就像沒能親臨現場的警察漏掉交通違章一樣被收集器漏掉了。這種由收集器方發起的數據收集模式被稱為 “ 拉取 ”（ Pull ）。

更高效的數據收集方式一定是 “ 推送 ”（ Push ）而非 “ 拉取 ”（… Continue reading