创载网络
17+年IT解决方案服务商
需求提交
请您填写下列信息，并点击提交按钮，耐心等待专家代表的电话回访！
400-888-4911网工历险记 - 拿什么拯救你我的头发？
发布时间：2020-12-11
防患未然、主动运维一直是网工们梦寐以求的运维境界。
然而虽然拥有看似强大的网管工具，但网工们仍饱受莫名其妙的网络问题的折磨，以至于网络经常
成为 IT 故障默认的背锅侠。
举个栗子：一场真实经历的网工噩梦 —— 幽灵丢包。
最早的故障现象是一部分用户反映登录超时。于是网工们开始检查网络，网管工具显示自然是一片绿，
看不出什么问题，ping 故障服务器集群，竟然发现在部分主机上 ping 不通，这些主机分布在不同网段，
完全看不出规律。
奇怪的是有些主机换个网段或换个 IP 又能 ping 通，于是认定通路上或许存在路由黑洞或访问控制列表，
一通检查后都排除了。一个网工偶然发现很多不能 ping 通目标服务器的主机是完全能访问目标应用的，
是否 ping 通好像和应用是否成功登录没有关系，这下网工们集体陷入懵圈……
两天后，问题最终被找出来了，只是网络主管少不了被内部用户一通投诉、一线网工们少不了多掉了许多头发。
是网工们的工具不够强大，发现不了故障吗？
其实工具是可以监测到问题端倪的，那为什么管理员又难以找到原因呢？
你以为用户体验的恶化是这样的：
但现实中用户体验的恶化却常常是这样的：
这种现象揭示出，工具虽然强大，但它们都是 “ 竖井化 ” 的本领域的 “ 专家 ” 。它们对系统健康评判标准基于
本领域的各类测量阈值，什么算 “ 绿 ” 什么算 “ 黄 ” 什么算 “ 红 ”，却缺乏端到端的全局视野。
网工们如果不想被各种假警报吵得睡不着觉，就会把报警的阈值门槛设得高一点，很多 “ 端倪 ” 虽然能被发现，
但只要算不上灾难就不会报警。
随着现代数据中心系统复杂性的升高，单一领域崩溃级的故障导致用户体验恶化的 “ 好事 ” 很难遇到了，往往
是以多领域 “ 亚健康 ” 的持续积累、跨领域的配合失调等方式造成用户体验恶化的。
多领域、全局视野衡量用户应用体验的测量工具到底存在吗？
业界的应用性能监测系统（ Application Performance Monitor，APM ）大多具备端到端应用健康度视图，形如下面：
但这样的 APM 工具缺乏每个单独领域的专业性，又无法检测出问题领域内故障产生的根因。
背锅侠网工们真的没法保住头发了吗？
聪明的你一定想到了，如果由同一家厂商提供世界上最好的 APM 和最好的数据中心基础架构会怎样呢？
让我们看看 Gartner 魔力象限 APM 领导象限的 Cisco AppDynamics 和数据中心网络领导象限的 Cisco ACI
这对 “ 梦幻组合 ” 是如何解决这个问题的吧。
AppDynamics 通过应用内的探针敏锐的捕捉到端到端用户体验的恶化，就像下图典型的 3-Tier 应用（ 前端、
应用、数据库 ）中影响用户体验的那一段被用鲜红的线段标识出来。
虽然 AppDynamics 能够标识出应用体验恶化的应用层级位置，但对基础架构发生了什么并不完全知晓，
我们把鼠标放在故障层级的位置就会变成手指形状，点击它就会弹出下图的菜单。
点击菜单中的 Troubleshoot（ Cisco APIC ），Cisco ACI 的 SDN 控制器 APIC 的图形界面就会自动
登录并打开 ACI 著名的故障诊断工具箱 Visibility & Troubleshooting 。
工具箱启用高强度诊断模式，针对 AppDynamics 告知的与故障层级相关的IP地址、协议和 TCP/UDP
端口号收集过去 24 小时内的所有数据记录，如异常告警、端口状态变化、配置修改、流量统计、Buffer
变化、丢包和延迟数据等等，并提供自动化的全路径可视化跟踪、逐包遥测、安全策略分析和端口镜像
工具等等。
如果没有 AppDynamics 提供与业务体验直接相关的精准上下文，这样强度的诊断是不可能常态性的发生
在网络中所有的通讯节点之间的。
背锅侠网工们的头发终于有救了
正是这种 “ 意图 ” 明确的诊断需求，引导我们把日常忽视的众多模棱两可的基础架构阈值告警关联起来，重新聚焦审视，从而帮助我们定位到了问题的根因 —— 正如上图中右下角被过滤出的故障告警所示，问题没有发生在 Fabric 上，而是虚机网络内部。
原来这又是一起因为管理员之间的误解而导致的跨领域配合失误的事故——
在给应用集群增加新服务器时，网络管理员认为服务器双上连应当是基于LACP端口捆绑的负载均衡，而
服务器管理员则认为是基于端点动态pinning的双网卡负载均衡，如果不幸这台服务器被负载均衡命中，
又在Fabric的Hash中被命中到了错误的网卡上，丢包就会出现，而稍稍改变一个条件可能就会命中正常
的服务器或问题服务器的正确网卡上，一切就又会正常。
如果没有能够关联基础架构能力的跨领域视野的检测系统，即便反复在狭窄领域内自查，这种幽灵丢包
原因也很难被发现。
找到问题根源，解决问题就不是难事了。下面是排除故障后ACI诊断工具箱和AppDynamics的正常状态显示：
这种故障诊断方法具备普遍适用性吗？换一种故障是不是就无能为力了呢？
当然不是！
前面虽然只是一个典型案例，但是揭示了一种全新的智能主动运维架构 —— 基于意图的自动化运维。
AppDynamics 代表了一大类能够自动生成诊断意图的智能洞见引擎（ Insigh_ts Engine ），而 ACI
APIC 则代表了另一大类能够高效采集基础架构大数据、能够根据意图自动化完成故障诊断和故障恢
复的自动化引擎（ Automation Engine ），两类引擎的有机互动，构建了新型的基于意图的主动
运维系统。
行业动态
填写您的信息获取IT方案
