是时候将 DevOps 可见性扩展到网络边缘了-优快云博客

尽管部署前运行了大量测试，但在部署应用程序后，性能问题经常让 DevOps 团队感到困惑。经过进一步调查，最常被忽视的问题是应用程序本身的分布式特性。从多个位置访问应用程序的最终用户永远不会拥有相同水平的互联网服务，因此在纽约、旧金山或伦敦等主要城市技术中心位置运行良好的软件不一定会继续运行。为更遥远的地区，特别是跨越半个地球的农村地区提供同样的体验。

所有互联网服务并非生来平等。由于物理定律，间歇性网络延迟问题可能会对应用程序性能产生深远影响。最终用户距离托管应用程序的数据中心越远，网络延迟就越有可能对应用程序性能产生不利影响。

不幸的是，大多数 DevOps 团队缺乏超出应用程序运行的数据中心环境的任何可见性。当然，获得这种洞察力的第一步是从网络边缘开始的。

互联网堆栈可见性

互联网堆栈由多种服务组成，每种服务都会对分布式应用程序的性能产生不利影响。从虚拟专用网络 (VPN) 和内容交付网络 (CDN) 到域名系统 (DNS) 服务器和交换机，所有内容都会增加延迟，根据网络流量的路由方式，延迟可能会对应用程序性能产生重大影响。这些服务中的任何一项都可能会遇到中断，或者更难以检测的间歇性降级，从而不可预测地影响应用程序性能。无论是在云中访问的软件即服务 (SaaS) 应用程序还是在网络边缘运行的物联网 (IoT) 平台，查明哪个互联网服务可能是问题的根本原因都需要密切监视和观察该流量的能力。

如果没有对互联网堆栈的任何可见性，以提供优化和排除特定应用程序故障所需的上下文的方式呈现所需的见解就成为一项不可能的挑战。构建应用程序所花费的所有时间和精力都可能化为乌有，因为在部署应用程序之前没有人了解网络延迟会对应用程序产生的影响。即使在部署应用程序之后，对网络流量路由方式的任何更改都可能会产生重大后果。如果没有任何方法了解可能发生了哪些变化，组织可能需要几周或几个月的时间才能意识到可能需要记录服务请求或更换服务提供商。

任何真正全面的可观察性方法显然都需要包括对组织关键依赖的互联网服务的分析，以确保提供和维护一致的应用程序体验。根据 IT 团队的结构方式，这些见解可以输入到组织采用的可观察性平台中，或者使用互联网性能监控 (IPM)平台进行关联。

DevOps 需要 NetOps

无论采用哪种方法，对于网络运营 (NetOps) 和 DevOps 团队来说，能够调整其监控分布式计算环境的方法从未如此重要。正在部署比以往更多的延迟敏感应用程序。在理想情况下，与 NetOps 密切合作的 DevOps 团队应该能够根据需要以编程方式配置和更改网络服务。并非所有互联网服务都可以通过应用程序编程接口 (API) 进行调整，但大多数 NetOps 团队都可以访问控制台，使他们能够在需要时升级到不同的服务级别。至少，服务提供商将与他们合作进行所需的任何更改。

当然，如果 NetOps 团队不知道互联网堆栈的哪个元素需要升级，那么谈判就会变得更具挑战性。通常对应用程序没有任何可见性的服务提供商可能会花费数周的时间来尝试确定他们管理的互联网堆栈的哪个元素出现了故障。拥有自己的监控一组互联网服务的方法的 IT 团队将能够与其服务提供商合作，更快地解决这些问题。