本文作者：魏航
思科首席架構(gòu)師
思享家
是一個(gè)介紹如何利用思科先進(jìn)技術(shù)解決客戶難題的欄目。每期聚焦一個(gè)技術(shù)熱點(diǎn)或應(yīng)用場景，邀請(qǐng)資深思科技術(shù)專家深入淺出地介紹，為讀者提供實(shí)用性強(qiáng)的建議。
防患未然、主動(dòng)運(yùn)維一直是網(wǎng)工們夢寐以求的運(yùn)維境界。
然而雖然擁有看似強(qiáng)大的網(wǎng)管工具，但網(wǎng)工們?nèi)燥柺苣涿畹木W(wǎng)絡(luò)問題的折磨，以至于網(wǎng)絡(luò)經(jīng)常成為 IT 故障默認(rèn)的背鍋俠。
舉個(gè)栗子：一場真實(shí)經(jīng)歷的網(wǎng)工噩夢 —— 幽靈丟包。
最早的故障現(xiàn)象是一部分用戶反映登錄超時(shí)。于是網(wǎng)工們開始檢查網(wǎng)絡(luò)，網(wǎng)管工具顯示自然是一片綠，看不出什么問題，ping 故障服務(wù)器集群，竟然發(fā)現(xiàn)在部分主機(jī)上 ping 不通，這些主機(jī)分布在不同網(wǎng)段，完全看不出規(guī)律。
奇怪的是有些主機(jī)換個(gè)網(wǎng)段或換個(gè) IP 又能 ping 通，于是認(rèn)定通路上或許存在路由黑洞或訪問控制列表，一通檢查后都排除了。一個(gè)網(wǎng)工偶然發(fā)現(xiàn)很多不能 ping 通目標(biāo)服務(wù)器的主機(jī)是完全能訪問目標(biāo)應(yīng)用的，是否 ping 通好像和應(yīng)用是否成功登錄沒有關(guān)系，這下網(wǎng)工們集體陷入懵圈……
兩天后，問題最終被找出來了，只是網(wǎng)絡(luò)主管少不了被內(nèi)部用戶一通投訴、一線網(wǎng)工們少不了多掉了許多頭發(fā)。
是網(wǎng)工們的工具不夠強(qiáng)大，發(fā)現(xiàn)不了故障嗎？
其實(shí)工具是可以監(jiān)測到問題端倪的，那為什么管理員又難以找到原因呢？
你以為用戶體驗(yàn)的惡化是這樣的：
但現(xiàn)實(shí)中用戶體驗(yàn)的惡化卻常常是這樣的：
這種現(xiàn)象揭示出，工具雖然強(qiáng)大，但它們都是 “ 豎井化 ” 的本領(lǐng)域的 “ 專家 ” 。它們對(duì)系統(tǒng)健康評(píng)判標(biāo)準(zhǔn)基于本領(lǐng)域的各類測量閾值，什么算 “ 綠 ” 什么算 “ 黃 ” 什么算 “ 紅 ”，卻缺乏端到端的全局視野。
網(wǎng)工們?nèi)绻幌氡桓鞣N假警報(bào)吵得睡不著覺，就會(huì)把報(bào)警的閾值門檻設(shè)得高一點(diǎn)，很多 “ 端倪 ” 雖然能被發(fā)現(xiàn)，但只要算不上災(zāi)難就不會(huì)報(bào)警。
隨著現(xiàn)代數(shù)據(jù)中心系統(tǒng)復(fù)雜性的升高，單一領(lǐng)域崩潰級(jí)的故障導(dǎo)致用戶體驗(yàn)惡化的 “ 好事 ” 很難遇到了，往往是以多領(lǐng)域 “ 亞健康 ” 的持續(xù)積累、跨領(lǐng)域的配合失調(diào)等方式造成用戶體驗(yàn)惡化的。
多領(lǐng)域、全局視野衡量用戶應(yīng)用體驗(yàn)的測量工具到底存在嗎？
業(yè)界的應(yīng)用性能監(jiān)測系統(tǒng)（ Application Performance Monitor，APM ）大多具備端到端應(yīng)用健康度視圖，形如下面：
但這樣的 APM 工具缺乏每個(gè)單獨(dú)領(lǐng)域的專業(yè)性，又無法檢測出問題領(lǐng)域內(nèi)故障產(chǎn)生的根因。
背鍋俠網(wǎng)工們真的沒法保住頭發(fā)了嗎？
聰明的你一定想到了，如果由同一家廠商提供世界上最好的 APM 和最好的數(shù)據(jù)中心基礎(chǔ)架構(gòu)會(huì)怎樣呢？
讓我們看看 Gartner 魔力象限 APM 領(lǐng)導(dǎo)象限的 Cisco AppDynamics 和數(shù)據(jù)中心網(wǎng)絡(luò)領(lǐng)導(dǎo)象限的 Cisco ACI 這對(duì) “ 夢幻組合 ” 是如何解決這個(gè)問題的吧。
AppDynamics 通過應(yīng)用內(nèi)的探針敏銳的捕捉到端到端用戶體驗(yàn)的惡化，就像下圖典型的 3-Tier 應(yīng)用（ 前端、應(yīng)用、數(shù)據(jù)庫 ）中影響用戶體驗(yàn)的那一段被用鮮紅的線段標(biāo)識(shí)出來。
雖然 AppDynamics 能夠標(biāo)識(shí)出應(yīng)用體驗(yàn)惡化的應(yīng)用層級(jí)位置，但對(duì)基礎(chǔ)架構(gòu)發(fā)生了什么并不完全知曉，我們把鼠標(biāo)放在故障層級(jí)的位置就會(huì)變成手指形狀，點(diǎn)擊它就會(huì)彈出下圖的菜單。
點(diǎn)擊菜單中的 Troubleshoot（ Cisco APIC ），Cisco ACI 的 SDN 控制器 APIC 的圖形界面就會(huì)自動(dòng)登錄并打開 ACI 著名的故障診斷工具箱 Visibility & Troubleshooting 。
工具箱啟用高強(qiáng)度診斷模式，針對(duì) AppDynamics 告知的與故障層級(jí)相關(guān)的IP地址、協(xié)議和 TCP/UDP 端口號(hào)收集過去 24 小時(shí)內(nèi)的所有數(shù)據(jù)記錄，如異常告警、端口狀態(tài)變化、配置修改、流量統(tǒng)計(jì)、Buffer 變化、丟包和延遲數(shù)據(jù)等等，并提供自動(dòng)化的全路徑可視化跟蹤、逐包遙測、安全策略分析和端口鏡像工具等等。
如果沒有 AppDynamics 提供與業(yè)務(wù)體驗(yàn)直接相關(guān)的精準(zhǔn)上下文，這樣強(qiáng)度的診斷是不可能常態(tài)性的發(fā)生在網(wǎng)絡(luò)中所有的通訊節(jié)點(diǎn)之間的。
背鍋俠網(wǎng)工們的頭發(fā)終于有救了
正是這種 “ 意圖 ” 明確的診斷需求，引導(dǎo)我們把日常忽視的眾多模棱兩可的基礎(chǔ)架構(gòu)閾值告警關(guān)聯(lián)起來，重新聚焦審視，從而幫助我們定位到了問題的根因 —— 正如上圖中右下角被過濾出的故障告警所示，問題沒有發(fā)生在 Fabric 上，而是虛機(jī)網(wǎng)絡(luò)內(nèi)部。
原來這又是一起因?yàn)楣芾韱T之間的誤解而導(dǎo)致的跨領(lǐng)域配合失誤的事故——
在給應(yīng)用集群增加新服務(wù)器時(shí)，網(wǎng)絡(luò)管理員認(rèn)為服務(wù)器雙上連應(yīng)當(dāng)是基于LACP端口捆綁的負(fù)載均衡，而服務(wù)器管理員則認(rèn)為是基于端點(diǎn)動(dòng)態(tài)pinning的雙網(wǎng)卡負(fù)載均衡，如果不幸這臺(tái)服務(wù)器被負(fù)載均衡命中，又在Fabric的Hash中被命中到了錯(cuò)誤的網(wǎng)卡上，丟包就會(huì)出現(xiàn)，而稍稍改變一個(gè)條件可能就會(huì)命中正常的服務(wù)器或問題服務(wù)器的正確網(wǎng)卡上，一切就又會(huì)正常。
如果沒有能夠關(guān)聯(lián)基礎(chǔ)架構(gòu)能力的跨領(lǐng)域視野的檢測系統(tǒng)，即便反復(fù)在狹窄領(lǐng)域內(nèi)自查，這種幽靈丟包原因也很難被發(fā)現(xiàn)。
找到問題根源，解決問題就不是難事了。下面是排除故障后ACI診斷工具箱和AppDynamics的正常狀態(tài)顯示：
這種故障診斷方法具備普遍適用性嗎？換一種故障是不是就無能為力了呢？
當(dāng)然不是！
前面雖然只是一個(gè)典型案例，但是揭示了一種全新的智能主動(dòng)運(yùn)維架構(gòu) —— 基于意圖的自動(dòng)化運(yùn)維。
AppDynamics 代表了一大類能夠自動(dòng)生成診斷意圖的智能洞見引擎（ Insights Engine ），而 ACI APIC 則代表了另一大類能夠高效采集基礎(chǔ)架構(gòu)大數(shù)據(jù)、能夠根據(jù)意圖自動(dòng)化完成故障診斷和故障恢復(fù)的自動(dòng)化引擎（ Automation Engine ），兩類引擎的有機(jī)互動(dòng)，構(gòu)建了新型的基于意圖的主動(dòng)運(yùn)維系統(tǒng)。
洞見引擎和自動(dòng)化引擎還有哪些新技術(shù)？它們和AI、大數(shù)據(jù)分析處理有哪些聯(lián)系？它們的互動(dòng)還能產(chǎn)生哪些神奇的化學(xué)反應(yīng)？
敬請(qǐng)關(guān)注下期，精彩仍將繼續(xù)！
京公網(wǎng)安備 11010502049343號(hào)