11月16日，第七届SD-WAN&SASE大会暨云网络大会在北京召开，阿里云受邀参会并筹办 “深度用云——释放企业潜能” 的专题分论坛，论坛邀请来自阿里云、天翼云、北京邮电大学、Palo Alto、Fortinet等产学界知名专家共同探讨在云+AI时代云网络的技术变革和产品服务演进，包括云网络架构的构建、基于云的网络安全防护，以及云上网络架构的高效运营等。
在会上，阿里云智能集团 高级技术专家肖雄带来主题分享《云原生网络AIOps工具集，助力企业深度用好云》，阐述阿里云网络近些年在云网络领域的运维和DevOps方面的实践，以及由此而沉淀释放给阿里云网络用户的AIOps工具和能力。
下面是演讲全文（约6500字，阅读约10分钟）：
大家下午好！
我叫肖雄，是来自于阿里云云网络的一名研发，很高兴今天有机会和大家汇报一下我从一个研发视角怎么看待深度用云，怎么看待云上网络运维的。
上午信通院的领导和专家也谈到，目前我国大型企业已经有80%上云了，大型企业用云的形态已经从传统的资源上云到了深度用云的阶段，那究竟什么是深度用云，云上的网络运维又是怎么做的？
个人经历上，我在2014年之前一直在阿里集团的运维部做运维系统的研发，在那个年代基本上阿里集团还在以自建IDC为主，还没有完全的上云，有幸从那时起我们连续几年经历了整个阿里巴巴集团的全面上云，过去几年又在云网络这边经历了很多传统企业上云，我们在这个过程中去做总结，会发现整个深度用云或云上运维分为五个阶段。
网络选址和规划：上云前，结合业务场景和诉求去做网络的选址、规划。
配置管理和优化：上云之后，网络配置的管理和优化。
网络监控与告警：业务部署起来之后，怎么去做网络监控和运维。
故障排查和恢复：当业务发生问题之后，怎么做网络的故障排查和恢复。
流量管理和分析：日常运维时，业务流量怎样进行管理、分析，持续实现更优的网络架构。
在这五个阶段里，传统运维和云原生运维或深度用云有什么不一样的地方。从技术角度来看，很早期的时候大部分都是以人为主，工具和脚本为辅。每年做服务器的采购预算，供应商会按照月/季度来做机器交付，那时候给运维团队有足够的空间和时间去做运维规划和部署。
到云之后，会发现有一个很大不一样，今天我们云上的资源是所见即所得的，只要有需求就能从云上立马弹出来上千台服务器，做到很快的资源交付。这个阶段我们会发现云上运维主要有三个特点和传统线下运维不太一样：
规模。我们能够在一个极短的时间内，能够快速的获取到大规模的云上资源，包括是网络资源、计算资源。
运维效率。有了云上极速的大规模资源交付，运维团队如何同样极速的把应用部署上线，对客提供服务。
站在云厂商视角，还要考虑多租的问题。面向不同场景诉求的用户，提供什么样的运维工具，提供怎样的深度用云的能力，每个客户面向的运维需求和场景还是不一样的。
在这个背景之下，我们也观察到在云原生技术，包括CNCF基金会过去几年的发展和推动下，K8s、微服务的架构和理念得到了大规模的落地应用，其中有一个很大的运维范式变化——就是从传统的以人为主、工具为辅的阶段，变成了以数据+工具为主、人为辅的阶段，比如K8s中Pod集群的弹性扩容、缩容以及驱逐完全是数据化驱动的，整个过程完全是不需要人去介入的，这样的运维效率对比传统模式有非常大的提高，更好的适应了云的特点，是完全云原生化的。
云上的网络也是一样，对于云原生的网络运维，网络数据变成了生产资料，网络模型变成了生产工具，我们怎么用好这些生产资料和工具，更好的去帮助客户进行云上网络的运维和深度用云，是我看到技术上的非常大的一个转变。
基于这个理念，我们在2016年、2017年就在做基于大数据的云网络AIOps技术平台，首先摆脱了以前传统工具和脚本视角束缚，转而面向数据驱动。我们在网络设备上线时，就提供默认的数据采集能力，同时还保障这个数据采集是云原生化的，是不侵入用户空间的，不损耗用户资源性能，不需要用户去安装任何Agent；在取得客户的授权后，我们会把用户网络的指标、流量数据采集出来，同时结合客户的网络配置，比如路由、网络拓扑的资源关系等，进行流式的计算和处理后进入到统一的网络数据仓库，再通过AIOps的算法进行学习、训练，生成适配不同客户场景的网络模型。最终基于这些数据和模型作为基础，去搭建我们的云上运维服务底座，包含监控、诊断、分析，在这套体系之上，再去做整个云上网络运维服务，包括用户画像、网络画像、故障恢复等，这就是我们一个比较大的、比较抽象的技术平台铺垫。
我们从2016年做到现在一直持续迭代，到过去几年随着更多的传统企业上云，越来越多的客户需要一套能够适应云原生化的云上网络运维和深度用云的工具，我们就在思考能不能把这些工具或能力慢慢逐步开放给我们的客户。所以过去两年我们开始把我们的技术平台逐步变成一个商业化的产品能力提供给我们的客户，这就是我们NIS的产品（网络智能服务），目标是提供云原生的网络AIOps工具，能够帮助我们的客户、帮助我们的客户能够上云，并且能够更好的深度用云。在NIS这个产品里，主要会提供四个部分的能力：
首先是监控。目前我们的数据采集覆盖云网络400+指标，通过这些指标数据和AIOps算法能力，再加上我们积累的专家经验补充，从而提供更加智能化的监控能力。
其次是定位。云网络的各种数据和指标，进入我们的数据仓库之后，再通过AIOps算法结合客户网络数据，进行各种维度的网络建模。包括用配置数据的建模，IP地址的建模、探测数据建模、流日志、操作日志、访问日志等建模，把这些建模出来之后，目的是能够通过各种数据关联、数据建模，当我们的网络出现问题的时候，能够找出它的根因，提供一些修复建议。
然后是观测。对于日常观测场景，我们提供了网络拓扑、网络性能基线等能力，还包括我们架构师也提供了最佳架构、最佳解决方案等，通过这些既有数据，还有人工经验、专家经验，把这些融合在一起，指导我们客户在云上的运维，能够把整个深度用云的最佳实践用起来。
最后是自动化。基于我们提供的能力，通过开放OpenAPI，再通过IaC等一系列工具的整合集成，能够让用户真正把这套工具用起来，集成到用户自己的运维系统和流程里。
接下来，从这几个方面稍微展开讲一下。
第一，上云是深度用云的第一个阶段，在我们看来就是怎么去做一个很好的网络选址和规划。有两个具体的场景，一是上云的第一阶段，客户在上云前，客户需要根据相应的云厂商的网络数据/基线做上云的网络规划；二是上云上了一段时间，客户的业务在扩展，可能需要在另外一个地域去开服，也可能需要做海外的业务，怎么去做进一步的网络选址和规划。
从云网络三个流量路径来看，主要分为公网（互联网性能）、AZ之间的性能、跨地域的网络性能。传统怎么做？以前客户会把应用先小规模的部署到云上，然后购买第三方的探测资源，通过第三方的探测看这个网络质量怎么样，再来决定怎么去选址、怎么去做部署，比较耗时、耗力、耗钱。
今天，我们的客户上了阿里云之后，所有这些基线数据阿里云网络都会默认提供出来，在产品控制台上展示出来，比如能看到在杭州这个Region来自于全国各地甚至全球的公网性能质量是怎样的，北京Region内AZ之间的性能又是怎样的，以及不同Region之间互访的性能又是怎样的。针对不同的业务场景，很容易就可以基于这个数据得到最低延迟部署环境是怎样的，以此来决策怎样做接下来的网络选址和部署规划。
第二，选址规划做完之后，业务就开始上云的部署等操作，因为网络比较特殊的是需要去做组网，如果没有可视化工具做组网会很痛苦，而很多组网架构图不统一，有很多甚至都是网络工程师自己用PPT或画图软件来做，然后在各种工程师之间去流转，随着一段时间变化以及日常管理的变化就失真了，很难和线上网络的真实情况匹配起来。
而当需要去排查问题或者需要去分析业务网络健壮性的时候，我们就会发现很难去描述真实的线上网络情况。针对这个阶段，阿里云网络（NIS）提供了网络拓扑可视化的能力，整个网络拓扑实时更新，通过CDC技术，用户在控制台上或通过API去下发一条路由、更改一条ACL，在我们整个数据仓库里都是实时感知的，也就意味着用户做了任何一个操作后，看到的阿里云网络的网络拓扑图、资源关系、路由拓扑都是最新的、最准的。
在这个场景里它就能解决两个问题：
第一，客户在上云部署阶段，其网络架构在部署过程中是不是符合预期的，网络架构或路由策略是不是和最终业务形态是相匹配的，通过NIS的网络拓扑功能可以及时查看当前的真实网络运行情况，以便在这个过程中及时进行纠错和调整。
第二，在问题排查过程中，当出现网络问题的时候，网络工程师能够快速通过这个网络拓扑看到相关路由的走向，经过了哪些设备节点，以及这些设备节点当前的运行状态，能够快速通过一个网络拓扑得到当前线上网络真实的情况，即通过网络拓扑做日常的管理和优化。
我们一直在思考能不能从事后“被动的”监控告警，转为“主动的”帮客户做事前的网络架构巡检优化。之前我们拜访了一些客户，印象非常深的是很多客户在上云一段时间之后，想知道自己目前云上的网络架构是否合理，是否有什么稳定性、安全的隐患。
我印象比较深的也是今年新加坡机房的火灾，当时我们云网络很快就通过容灾方案把故障机房给切换掉了，但我们也发现有些客户其实并没有享受到我们的网络容灾，是因为客户的整个架构部署在故障的机房里面，没有提前考虑做好网络架构的容灾。因为平常业务也运行比较正常，客户可能也没有意识到这个事情。
因此，今年我们重点在深挖面向客户场景的网络巡检能力，持续帮助客户去提前发现线上的风险和隐患，并在阿里云网络NIS中做了比较大的升级，提供了网络架构级别的巡检能力。
NIS的网络巡检功能，主要覆盖了4个大的方向：
第一，稳定。稳定优先，我们会从稳定性架构的视角，来帮助客户检查主备的容灾情况，故障时是不是有半径放大的风险。
第二，安全。客户的网络有没有ACL漏洞或者安全组权限过大的情况。
第三，性能。当前的网络带宽、规格，是不是水位已经过高了，是不是发生过超限丢包的情况。之前我们帮助一个出海做电商的客户发现了他有很多网络路径出现绕行问题，并通过这个提升了整体网络的性能。
第四，成本。其实有很多客户没有意识到有些资源其实并没有流量，也就是买了很多资源并没有实际的应用起来；又或者计费方式是不是可以调整为更优的，这些都可以进一步的节省客户的成本。
我们总体的目的是想通过这四大维度的定期检查，能够去帮助我们的客户提前去挖掘他在目前架构里面存在的潜在风险，把这些问题在日常就解决掉，通过平时不断持续的优化，当真正再遇到线上故障的时候，能够迅速能从故障里面去恢复。
在技术上，我们这些所有相关的巡检、诊断包括风险事件，都归一在了统一的数据仓库里，我们去巡检的时候把我们的数据从数据仓库里面拉取出来，去做各种维度的关联分析。此外，我们还为所有客户按照其自己的组网架构去做分类和建模，这样的话每个用户看他的报告其实是不一样的；未来阿里云网络还会结合AI大模型的能力，为客户提供AI深度分析和优化方案建。
客户的业务上云之后，客户就会关心另外一个非常重要的问题，就是网络日常监控的问题。日常网络监控其实是一个比较基础的问题，但是我们确实发现很多客户的监控有很多不完善的地方，一个是客户在云上用的资源规模确实过大，客户很难面面俱到的把所有的资源监控起来；第二个是因为其组网方案或者业务架构比较复杂，涉及的地域、实例、数据也比较多，还要去做应用级监控，客户很难去做一个比较完善的监控策略，或者监控策略有遗漏，或者监控策略比较复杂，往往导致漏报警或者多告警，这样的话也很难去做相应的准确的处理。
在这里，我们针对云上网络的基础监控，推出了免告警策略配置的“NIS事件中心”功能。我们其实在2018年就在做相关的机器学习算法，我们想通过AIOps的方式去做智能监测，而不是人去配置监控策略。
目前我们总结出来了一套适合于云上网络的智能告警方案——它能够通过客户流量的历史区间数据去学习、训练出来它是不是有周期性的波动，是日周期、周周期，还是季节性的，又或者节假日效应的，电商客户、游戏客户、金融客户其实都是不一样的，甚至还有短周期的突增、突降的异常波动。比如说电商类客户往往是有突发的，通常是在做各种促销活动；游戏类的客户往往是呈现周末效应，周末突发会比较多。不同客户不一样，我们做了很多AIOps的算法，一个是学习它的历史规律，第二个是做异常检测，能够在几分钟之内检测到它是不是有快速的异常波动，然后快速给客户发预警。
此外，在告警上我们很多客户面临比较多的问题是有告警，但是不知道具体的影响面是什么，这就导致他很难去做一个决策，应该做什么动作，以及准备什么样的故障恢复预案。
在这个场景下，我们做的另外一个事情就是，尝试去做告警的影响面分析，因为我们有告警的数据，同时也有资源的数据，也有资源上流量的数据，这样就能够去做一个关联，当这个告警出现的时候，在这条链路上它有多少资源受到了影响，它受到影响的流量有多大。如果客户开通了NIS的流量分析功能，则我们会默认启动这个影响面分析的能力，目前主要覆盖的是在我们公网的丢包场景。比如我们的告警会描述说某地某运营商到阿里云产生了多少的丢包异常，这个丢包异常影响到了客户的哪些EIP，这些EIP的流量是多少，很多客户有了这个指标之后就能很快去做出应急预案决策。
有了告警之后，接下来客户的场景就是怎么去做故障的定位，在这里我们主要做了两个工具，一个叫做一键诊断，一个叫做网络联通性分析。
一键诊断就是你输入一个云网络实例ID，工具就能快速的对这个实例做一个全面的扫描，能够去分析它哪里有问题，比如LB的健康检查问题、带宽的超限丢包等等，能够快速去帮用户分析哪里有问题，怎么修复，提供一个诊断的报告和修复的建议。
路径分析就更加面向网络链路分析，客户有很多场景是某个特定的流或者某一对特定的地址网络不通。路径分析就是基于网络五元组的网络连通性分析，客户可以输入IP对、协议、端口号，我们能够帮他分析出来整条路径上每一个节点的路由、ACL等情况，是不是有什么安全的拦截，在这里面帮助我们客户去发现一些比较难的一些全链路问题。
这个过程我们整合了很多的数据源分析，包括云网络所有产品的数据，还有客户配置的路由、安全组数据，以及我们和安全团队合作打通的安全的拦截数据；希望通过这一个系统，能够在网络路径上完整地把用户遇到的路由配置不正确、ACL配置错误、安全拦截等情况及时发现出来。
最后是关于网络流量的分析，日常运维过程中很多客户需要一款工具能基于流量情况做分析和管理，比如分析业务流量的热点、访问质量怎么样，以及是否有异常或者不应该出现的网络流量，甚至是安全审计和分账等场景。
我们的流量分析NPM工具，提供了多种维度包括一元组、二元组、五元组等的可视化分析，提供了公网、专线、CEN跨域、VPC等场景的流量分析功能，甚至针对公网场景我们还关联了IP地址的ISP相关信息。基于这些富化、聚合、分析后的数据，能够针对于不同的场景去提供不同的流量多维度的分析能力，并提供性能监控。
比如游戏类的客户，比较关心公网服务情况，流量分析NPM能帮助客户分析玩家来源热点、以及公网抖动等性能劣化的情况。
跨境电商的客户，比较关心跨境的网络流量情况。我记得之前我们有个客户跨境链路水位被打满，影响到了客户的线上业务，最后通过流量分析NPM定位到了是某个数据同步任务数据量突增导致的，在及时停止该任务后，业务立马得到了恢复。
还有一个场景是客户经常用流量分析做成本分账，有很多大型集团客户上云之后，他有很多子部门或者子团队在消耗网络带宽资源，究竟每个部门耗了多少的资源，客户会用我们的流量分析做相关的成本分账和优化。
此外，在技术上我们还做到了完全无侵入，不需要客户安装Agent，也不消耗客户的网络和计算资源，提供了完全旁路化的流量分析技术能力，随开随用。
刚才比较简要地描述了企业上云、深度用云的五个阶段，以及阿里云网络提供的相关产品工具。覆盖了上云选择和规划、网络监控、故障排查等日常运维工作。之前我们一直觉得，我们已经提供了很多丰富的工具，已经能够满足客户的需求了；实践中我们发现今天很多客户还是有不同的运维流程和工具使用诉求和约束的，运维能力需要一个长期持续的演进和升级。
比如海外客户很多都在通过Terraform来提升运维效率，国内很多客户会使用Ansible之类的运维流程工具，但是到目前更多的是用在资源部署阶段，能够快速把资源创建起来。但真正到了进一步的网络运维或深度用云阶段，在各种问题排查、诊断、性能观测等场景，IaC工具的支持我觉得还属于刚刚起步的阶段。
今年我们把OpenAPI开放出来，就是希望能够把云上网络运维相关的API放到客户所用的IaC工具里面，这样能够帮助我们客户在不改变他们原有运维流程和工具的框架下，快速的具备云上网络运维的能力，以更好的深度用云。
比如，今天客户去做一个网络变更、去加一条路由等，只需要在Terrafrom的Module里再加一条策略，在变更完成之后用NIS的路径分析API去PostCheck一下两个IP之间的网络路径是不是不通了，如果不通的话通过IaC工具快速去做一个自动回滚。通过集成NIS的OpenAPI到客户的IaC工具流程里，能够加速整个自动化运维效率，提升客户整个用云或深度用云的效率。因此，我们今年重点做的一个方向就是把OpenAPI开放出来，也欢迎大家来使用我们的OpenAPI。
我今天的分享主要是这些。谢谢大家！
