阿里云公开了其SIGCOMM2020入选论文《VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network》的内容，发布在微信公众号“洛神云计算网络技术”。
论文继承了SIGCOMM一贯的务实作风，大部分篇幅集中于对问题本身的剖析以及对技术路线的介绍，而解决方案本身并不涉及太过复杂的技术，因此可读性很强。
论文虽然面向云网环境，阿里云也在其介绍中特意强调这是国内历年来唯一一篇云网络方向的入选论文，但其中讨论的核心问题和互联网的历史一样悠久——网络状态管理，更准确地说，是网络软状态管理。通常情况下，网络中的网管系统能够对网元状态（硬状态）进行有效的管理，但是这些网元状态是以离散个体的形式出现，相互之间的关联性主要取决于网络拓扑，因此网管系统中的告警也主要是网元级别的告警。
但网元的状态和网络的状态并不属于同一个层面。网络的状态虽然包含网元状态，但其侧重点应该是网络资源组织调度的状态（软状态）。在网络层，这些状态至少应该包括IP路径的状态、端到端连接的质量等，但在大多数网管系统中，这些状态是被忽视的。尽管有些第三方供应商专门提供这类产品，但是从实际部署和运用的效果来看，并不理想。其中的原因，我认为在于四个方面：
第一，第三方系统无法直接从网络设备或网管系统中获取所需全量信息，因而还原的颗粒度、时效性和准确性都面临难以克服的障碍。比如很多IP路由状态监控系统是通过伪装成路由器加入网络，获取路由协议中的网络状态信息的方式来还原网络中的路由结构，这些信息对于路由器独立计算路径完全够用，但要推导出其他路由器计算路由的结果则暴露出很多不足，因为路由协议的分布式设计模式使每个路由器的计算逻辑或多或少地存在某些细微的随机性，而这些随机性并不会通告给其他邻居。
第二，网络中的ECMP和NAT等干扰端到端透明性和唯一性的因素进一步增加了精确还原IP路径信息的难度，对于第三方管理工具来说，这些问题是不可解的。
第三，由于运营商网络中广泛存在ECMP，因此即使能够还原出端到端的IP路径，其信息量也极为庞杂，以至于会对网管人员造成信息过载，反而无法发挥出提升排障效率的作用。当然另一个原因是运营商对网络资源的管理往往在大颗粒度上展开，过于细节的信息未必真正有用。
第四，运营商供给和管理的网络资源偏底层且颗粒度很大，更倾向于以资源的冗余供给来对冲管理复杂性带来的不可控风险，因此更愿意关心网元状态、资源池状态而不是每一个连接的状态。
这四个方面的原因，植根于基础设施网络以网络为核心的运营模式，但在阿里这样的互联网公司眼里，服务、内容、用户体验才是一切网络资源组织调度行为的核心。这种截然相反的视角，决定了阿里云的网络状态管理无论是需求还是挑战都完全不同于电信运营商：首先，故障排查的颗粒度要精细到连接级别，更极端一点来说，要能够解释每一个用户体验问题背后的原因是什么。因为互联网公司的选路模式从一开始就不限于IP层，更多是应用层主导，甚至面向每一个具体用户和应用，因此选路的复杂性也远远高于传统意义上的路由协议，说每个用户的转发路径都是被单独计算出来的也不为过。要对如此数量庞大的路径信息进行有效的管理，这是前所未有的挑战。
第二，互联网公司眼中的端到端路径是真正意义上的端到端，这和运营商只能在IP及以下各层对本网内的部分负责截然不同。其中除了传统意义上的路由转发节点，还包括大量的应用层网关和处理系统。对于运营商来说，这些都不属于网元，但在互联网公司眼里，用户的数据包经过的每一个单元或功能，都和连接的质量息息相关，因此对连接的状态管理也就自然而然地延伸到了IP层之上。
第三，在这样一个跨域TCP/IP协议栈各层的复杂巨系统中，OAM却并没有系统化和标准化的定义与框架，网络层与应用层的状态信息仍然很难做到按需自由流动，因此端到端连接状态管理中的信息透明性问题仍然困扰着大多数互联网公司。在一个系统化的解决方案出现之前，仍然必须依赖定制化工具来以CASE BY CASE的方式来解决问题。
第四，尽管大型互联网公司越来越倾向于通过自研的方式解决网络问题，但很难在自研之初就形成一个清晰可扩展的系统架构，很多情况下是根据需求和规模的自然演进，逐步完善和迭代，对网络和连接状态的管理也必然要经历这样一个摸着石头过河的过程。因此到目前为止，除了谷歌的SRE可以算作是系统化的方法论以外，大部分同行还处在DEVOPS的阶段，而很多DEVOPS面临的问题并不是缺乏自动化运维的算法或功能开发困难，而是整个网络以及业务系统本来就是野蛮生长出来的，设计之初并没有充分考虑过要为日后运维自动化预留哪些功能和接口，等网络规模完美超出人力极限，只能回过头来以打补丁的方式解决问题。打的补丁足够多了，补丁自己也经过迭代和演化融合为一个独立的物种之后，才有可能反过来影响网络和应用的研发，有目的地向SRE的方向转变。这是一种确定的趋势，但完成转变需要时间。
阿里云的这篇文章，从一个具体的运维问题入手，以具体问题具体分析的务实态度，首次给局外人提供了窥视阿里云网系统运行和运维模式的窗口，也从一个细分的侧面反映出中国互联网演进的速度以及方向。这篇文章表明，云网状态管理绝不是传统意义上的网络管理。在阿里云的云网系统中，端到端连接的状态无论是在空间、时间还是协议栈的不同层次都会面临高度的动态性，而这些动态性又往往具有不可预测性，很难依靠一套确定性的逻辑进行推演，只能通过记录微观行为日志的方式来还原真相。但要维护全量的连接状态数据又会对整个云网系统以及运维系统造成难以忍受的负担，因此采用按需启动任务、着色抽样的方式来有目的地对特定连接状态进行管理。论文中没有介绍应用服务生成VTrace任务的规则以及抽样的原则，这一方面是由于这些内容与VTrace本身的逻辑相关性不强，说了反而可能喧宾夺主，另一方面，这些规则和原则的背后，是一套复杂的运维体系，即使要说清楚，也不是那么容易的事情。但我认为这些规则和原则，要比工具本身更加值得关注。
以下是转载自阿里云公众号的正文，技术细节内容详实，不需要我再做冗余的解读。通信和网络行业的老兵们，很容易从中看到一些古老技术的影子，这很正常。互联网技术尽管迭代速度越来越快，但是很多基础设计理念仍然顽强地存在于互联网的基因当中，并在不同的历史阶段显现出令人惊讶的长期主义价值。
这也是互联网的魅力之一。技术很容易逝去，但技术背后的理念并不会随风飘散。
希望国内的互联网企业，能够更加积极地参与到国际交流当中，美美与共，和而不同，获得更加强大的生命力