尽管部署前运行了大量测试，但在部署应用程序后，性能问题经常让 DevOps 团队感到困惑。经过进一步调查，最常被忽视的问题是应用程序本身的分布式特性。从多个位置访问应用程序的最终用户永远不会拥有相同水平的互联网服务，因此在纽约、旧金山或伦敦等主要城市技术中心位置运行良好的软件不一定会继续运行。为更遥远的地区，特别是跨越半个地球的农村地区提供同样的体验。
所有互联网服务并非生来平等。由于物理定律，间歇性网络延迟问题可能会对应用程序性能产生深远影响。最终用户距离托管应用程序的数据中心越远，网络延迟就越有可能对应用程序性能产生不利影响。
不幸的是，大多数 DevOps 团队缺乏超出应用程序运行的数据中心环境的任何可见性。当然，获得这种洞察力的第一步是从网络边缘开始的。
互联网堆栈可见性
互联网堆栈由多种服务组成，每种服务都会对分布式应用程序的性能产生不利影响。从虚拟专用网络 (VPN) 和内容交付网络 (CDN) 到域名系统 (DNS) 服务器和交换机，所有内容都会增加延迟，根据网络流量的路由方式，延迟可能会对应用程序性能产生重大影响。这些服务中的任何一项都可能会遇到中断，或者更难以检测的间歇性降级，从而不可预测地影响应用程序性能。无论是在云中访问的软件即服务 (SaaS) 应用程序还是在网络边缘运行的物联网 (IoT) 平台，查明哪个互联网服务可能是问题的根本原因都需要密切监视和观察该流量的能力。
如果没有对互联网堆栈的任何可见性，以提供优化和排除特定应用程序故障所需的上下文的方式呈现所需的见解就成为一项不可能的挑战。构建应用程序所花费的所有时间和精力都可能化为乌有，因为在部署应用程序之前没有人了解网络延迟会对应用程序产生的影响。即使在部署应用程序之后，对网络流量路由方式的任何更改都可能会产生重大后果。如果没有任何方法了解可能发生了哪些变化，组织可能需要几周或几个月的时间才能意识到可能需要记录服务请求或更换服务提供商。
任何真正全面的可观察性方法显然都需要包括对组织关键依赖的互联网服务的分析，以确保提供和维护一致的应用程序体验。根据 IT 团队的结构方式，这些见解可以输入到组织采用的可观察性平台中，或者使用互联网性能监控 (IPM)平台进行关联。
DevOps 需要 NetOps
无论采用哪种方法，对于网络运营 (NetOps) 和 DevOps 团队来说，能够调整其监控分布式计算环境的方法从未如此重要。正在部署比以往更多的延迟敏感应用程序。在理想情况下，与 NetOps 密切合作的 DevOps 团队应该能够根据需要以编程方式配置和更改网络服务。并非所有互联网服务都可以通过应用程序编程接口 (API) 进行调整，但大多数 NetOps 团队都可以访问控制台，使他们能够在需要时升级到不同的服务级别。至少，服务提供商将与他们合作进行所需的任何更改。
当然，如果 NetOps 团队不知道互联网堆栈的哪个元素需要升级，那么谈判就会变得更具挑战性。通常对应用程序没有任何可见性的服务提供商可能会花费数周的时间来尝试确定他们管理的互联网堆栈的哪个元素出现了故障。拥有自己的监控一组互联网服务的方法的 IT 团队将能够与其服务提供商合作，更快地解决这些问题。
概括
精明的 IT 团队非常清楚互联网服务很容易发生中断和限电，因此通常他们倾向于确保网络流量可以从一项服务重新路由到另一项服务。这种方法还提供了额外的好处，即在他们协商所提供服务的费用时保持一定的定价杠杆。
还值得记住的是，知道客户被锁定的网络服务提供商可能没有太多动力来确保网络服务以最高效率运行。当然，IT 团队要了解在任何给定时间提供的服务级别的唯一方法是生成 IPM 报告，该报告准确详细说明在什么性能级别上实际可用的服务。否则，他们完全依赖于服务提供商随每月账单提供的报告。
同样重要的是，IPM 平台生成的报告还可以提供见解，当向应用程序开发人员展示这些见解时，可以创造优化其代码的潜在机会。如果没有这种级别的分析，每个开发人员都会认为网络服务要么已损坏，要么管理不善。现在的挑战和机遇是提供互联网性能情报，让每个利益相关者不能只是采取行动，而且同样重要的是，隐含地信任。
