在可见性变小的时代,如何修复网络问题?

修复问题的***步是认识到自己遇到了问题。

有时候，一个新IT技术出现会需要一些特殊的工具;但是，有时候是因为我们长期依赖的重要工具无法满足我们的要求。随着我们越来越多地将业务迁移到云、软件即服务(SaaS)和混合IT环境上，一些像traceroute等重要的工具已经不能用了。在一个越来越不透明的环境中，管理权限变得越来越小，管理员应该如何开始修复网络问题呢?

奔向不透明环境

云与SaaS最吸引人的一个特点是它从一开始就出自工程师之手，但是却深深地刺激着IT管理人员：“因为不需要管理”。将一些关键服务迁移到一个带有服务水平协议(SLA)的方法本身并没有问题，因为我们信任SLA。提供商的承诺是很好的，他们通常都会尽一切努力去服务他们的用户。

然而，问题在于，网络工程师仍然必须负责保证良好的用户体验。他们同意推翻多年积累的丰富的监控技术，而这种转变是必然的。IT愿意将决定业务成功的系统迁移到一个新环境上，即使他们无法像以前那样修复故障，也很难跟踪和报告整体性能。大家可能都知道，虽然亚马逊、谷歌、Salesforce和Azure已经很好，而且正变得越来越好，但是它们肯定不是完全没有故障的，也不是无上限的基础架构。它们仍然符合数据中心既定的物理原理，它们的服务台仍然会不断地收到问题单。

API取代SNMP

有很多很好的理由决定了云提供商不会开放防火墙或允许用户监控他们的软件定义基础架构。相反，我们被迫依靠他们所提供的管理API和私有工具，用它们来检查和分析所遇到的网络问题。但是，这些接口所提供的信息完全无法和我们在自己数据中心内所积累的信息相比;它们有一定的使用难度，而且没有跨平台和广泛支持ICMP、SNMP及其他协议。但是，他们能做的就是给应用程序流量开放一些特殊的访问路径。

即使在我们的内部网络，traceroute和ping也会受到路由多样性的影响，从而限制它们修复用户与服务器之间网络问题的能力。traceroute假定观察者与服务之间的路径是线性的，因此会返回该测试的近似路由路径。在混合IT网络中，互联网路由的互连多宿主会成倍地放大这个问题，而且会在UDP或ICMP流量上进一步增加难度。那么问题来了，在4条各自分担25%应用流量的链接中出现了延迟，我们该如何从中分辨出影响Salesforce性能的根源问题呢?

答案是要忘掉我们曾经精心设计的内部网络，而要认真思考互联网。在内部网络中，我们在设计时尽量考虑了各种不确定性;而互联网则依靠限制路由不确定性来保证健壮性。如果不去考虑和想象应用程序特有的数据包，那么从用户到云服务器的全部流量路径可以在多个维度上观察到多个可能出现的路由，其中包括时间维度。这种方法不会马上产生像traceroute一样的效果——它需要一定时间去检测和传播，但是它的结果会很全面且可视化。

虽然在本地设备上执行基于请求的监控会继续给运营人员返回重要信息，但是可视化路径监控能够帮助我们重新获得因为混合IT网络而丢失的监控能力。它不仅能够帮助我们简化内部网络问题中误操作和错误配置的检测，还能够将网络问题的修复通过互联网扩展到服务提供商的网络上。

这种方法之所以有效，是因为现代网络路径监控工具能够模拟应用程序特有的流量，它们会像用户流量一样通过防火墙。在出现不对称的多宿主链路延迟问题时，它们能够通过负载均衡解决特定协议或端口的路由问题，而且它们会发现所有影响服务性能的节点。我们不再需要依靠路由器CPU的警报，而只需要处理网络节点的警报，将警报信息告知提供商服务台，他们就能得到解决问题所需要的信息，大大缩短了他们分析问题的时间。

如果我们能够重新获得混合IT环境下的可见性，并且还能让用户开心，那么在修复网络问题方面，“不需要管理”可能就不是一件坏事了。