一、云上网络运维面临的挑战

根据新能源最新的云计算白皮书，目前我国大型企业的上云率已经超过了80%，而且运营的知识也从资源上发展到了深度用云，云计算已经成为了助力企业应用发展的主力军，这是因为云计算基于分布式、虚拟化、多租户等等一系列复杂的技术手段，让客户的应用部署更简单更普惠，但是随着系统越来越复杂，不可避免的运维也越来越复杂了，这道理很简单，就像一个自行车如果坏了，我们可以很简单就能看出来，但是如果是一个汽车坏了，就很难看出来了。

运维的复杂主要体现在三个方面，第一是工具的割裂，根据调查目前有超过63%的企业同时用了10种以上的工具在做运维，这种点式的工具造成很多的问题，让客户频于应对点式的问题，另外很多传统的运维工具在云上已经不太适用了，所以这些问题里面还有很多是噪声。第二是运维演进的速度天然就滞后于业务，因为运维是服务于业务的，现在很多客户已经将云上业务部署实现了inc不同自动化。很多游戏客户可以在一分钟内谈起一个新的游戏服，但是运维的自动化才刚刚开始。第三是随着业务的不断发展，需要观测的数据规模越来越大，需要投入的成本越来越高，但是因为工具的割裂、数据的不标准，造成产出还比较低，这样形成了一个恶性循环。nis产品的目标就是让云网络这么复杂的一个系统，也可以让客户自主运维。

二、解决思路:打造云原生网络AIOps工具集

为了解决上述问题呢，持续投入打造云原生的AlOps平台，AlOps有两个要素:数据和模型。数据主要是广度和标准化，广度很好理解，所有云网络600多个指标全部都进入到nis。vpc、nat、tr都有流日志，标准化就是把所有的流日志都统一标准，甚至里面每一个字段都统一标准，这样可以将所有的数据联合起来做分析，提升问题的准确性。第2个是模型，现在业界没有成熟的模型可以用，但是阿里云运营了多年的云网络，服务了几百万的客户，每天都会处理大量的客户问题，阿里云将这些问题和经验沉淀下来就形成了自己的模型。对于AlOps的模型分为5层，在实际的工程应用中把它分为了4层。

以一个最典型的公网指标劣化来作为案例，最底层是监控，通过一些组件级的指标数据，然后关联客户的阈值可以帮助发现问题。比方说通过eip的监控发现公网有一些问题了，然后通过vpc的流日志可以发现到底是哪些ip出的问题。

第2层是定位。这一层通过更多的产品级的数据关联，可以帮助发现问题的根因。比如说通过ip地址库的关联可以发现这些ip到底属于哪个运营商，然后根据所有运营商的探测的基线数据做对比，可以发现到底是运营商的问题还是阿里云自身系统的问题。

第3层是观测。通过解决发出去的关联可以帮助分析出问题的影响面，比如说这个eip关联的是哪个LB？这个LB上面有多大的流量？这个LB后面挂载的是那个ecs？ecs上面存在什么业务？这个业务对时衍的敏感性要求是什么样子？另外还可以通过观察这一层给出问题的解决方案。比如说这个运营商受损了，周围有没有其他的运营商可以切换？切换过去以后时衍是什么样子的？最后一层是自动化。

运维是服务于业务的，最好的运维方式是将运维集成到业务流程里面去，所以说产生了DevOps、itOps、FinOps等一系列xx-Ops的概念，比如说DevOps就是将开发和运维的流程结合起来做到自动化的开发部署和运维，持续的提升开发的效率，在这一层要达到自动化的目标还比较遥远，需要客户和合作伙伴参与进来和阿里云一起持续共建。自动化的第1步是要提供运维的open api，所以nis产品的发展基本上伴随着这个平台的发展，阿里云前两年主要是在监控和定位这两层，今年带来了网络的可观测，包括流量的可观测、流量分析npm和架构的可观测网络巡检，同时商业化了所有运维工具的open api。

三、可观测是客户业务稳定性重要保障手段

可观测非常重要，它是在监控基础上不但可以帮助发现问题，还可以帮助分析问题的根因、提供问题的影响链以及问题的修复建议。可观测是客户业务进一步提供可信SLA的基础，也是进一步自动化的基础。但是因为现在可观测工具的割裂以及数据的不标准，所以目前的情况还不太乐观，调查显示目前有超过55%的故障平均恢复时长超过了一个小时，其中还有6%的故障超过了一周。

四、产品重磅发布

1、流量分析NPM商业化发布

对于网络可观测而言首先是流量的可观测。它的应用场景非常广泛，举三个最典型的场景说明。

第一是性能优化，阿里云有很多游戏和金融客户对网络的时延非常敏感，基本上在毫秒级的去优化时延，之前介绍过公网运营商抖动的案例实际上公网传输的路径不是想象那么简单，不是从客户端直接到云端，中间可能经过了非常多的中转点，如果其中的一个中转点发生了问题，这个时候定位非常复杂，过去通常需要好几个小时解决问题，但是现在通过nis的流量分析，可以分钟级的定位住问题。只需要两步操作，第1步是选择问题发生的时间，第2步是根据运营商维度来看时延的性能数据，还可以通过和基线、和历史情况的对比来做出修复的判断。

第二是问题定位，通常企业客户为了节约成本，多个应用会共享一份网络带宽，很容易发生的问题就是其中一个应用突发影响了其他业务。这个时候对运维来讲需要快速的找出是哪个应用，然后一起去优化。同样通过nis的流量分析也只需要两步，第1步是选择问题发生的时间，第2步是根据五元组视图查看流量的用量数据，这样很快的就能找出问题所在。另外因为业务的波动具有一定的周期性，同时期的流量是差不多的，阿里云还可以支持和同期的流量做对比将监控不断前置来及时的发现问题。

第三是账单的分账，多个应用共享一份带宽，但是带宽的账单只有一份，最好的分账方式就是根据每个应用的用量来做分配，但是分账的话，不需要像前面两个场景那么高精度分钟级的数据，通常按月分账就可以了。所以可以支持从数据采集到数据分析都降低数据的采样频率，通过降低整个观测数据量来降低成本。另外所有的观测数据都在云上，不需要数据导出，又省了一笔导出的费用，综合的成本可以降低60%。

2、隐藏的架构缺陷不易发现，但是一旦触发影响巨大

nis流量分析这个产品阿里云公测了一年多的时间，现在有很多的客户都在使用，已经打造非常成熟，接下来阿里云将会在12月底正式商业化nis产品。第2点是网络架构的可观测，网络架构的缺陷通常不容易发现，但是一旦出问题就会造成很严重的后果。在处理各种各样客户问题的时候发现，客户隐藏的架构缺陷问题不太容易发现。举一个非常典型的真实的一个案例，一个客户在做大促的时候，突然发现有很多订单支付失败，根据定位，发现这个问题的根因很简单，就是因为他购买的公网带宽超限了，超过了100%，但实际上这个问题早就有迹可循，因为他平时在小促的时候带宽峰值就达到了60%。

如果在大促前发现这个风险，然后及时的扩容，这个问题就不会发生。而且更为可惜的是客户是按95带宽计费的，95的按带宽计费的规则是有一个20%的保底，如果没有达到保底会按保底来收，但如果超过了保底是按实际的用量来收费。这意味着客户如果提前发现了这个问题，进行扩容带宽，它的成本就不会增加。阿里云在处理所有的问题的时候都会举一反三，首先看客户问题发生的原因是什么，思考和阿里云的最佳架构是不是符合的，有没有隐藏的缺陷。然后将这个过程不断的沉淀下来，形成了网络架构可观测的产品网络巡检。

3、网络巡检，网络架构可观测

网络巡检主要目前覆盖了稳定、安全、性能、成本和运营5个支柱，目前有24个巡检项目，未来还会逐步的去持续的去增加。阿里云每周会给所有的客户免费产生一个巡检报告，这个巡检报告里面会有整个网络架构健康的评分以及所有没有通过的巡检项。同时对于所有不通过的巡检项，还会提供影响的实例范围，这对很多物理网络抖动会很有效，比如说公网抖动到底影响的是哪些eip,跨域抖动到底影响的是哪些tr tagement。另外客户的环境通常同时会有生长环境或者测试环境，不同环境对稳定性要求也不一样。所以阿里云支持按实例、按资源组、按标签来指定巡检范围来减少巡检的噪声。另外提供问题的高中低3个风险级别，方便用户来根据风险级别来做优化的排期。还有完整的优化建议，客户只需要按照优化建议一步一步去操作就可以修复网络缺陷。所以网络巡检是从问题发现到影响面的分析到优化建议提供端到端的架构可观测的运维工具。

4、iac自动化运维:商业化openAPI重磅发布

最后是自动化运维，运维是服务于业务，所以最好的运维方式是集成到业务里面去，比如财务根据底层的业务的用量数据，结合财务的成本数据和分账规则来做自动化的分账，或者进一步结合业务的预测数据来做自动化的预算。为了达到这个目标，阿里云今年开放了所有商业化的运维工具的open api。同时持续不断的集成到开源的iac平台也支持集成到云原生的平台，方便客户更方便的去运维。其实达到自动化的目标，还比较遥远，需要客户和合作伙伴参与进来和阿里云持续的去共建。另外关于自动化运维，完全的自动化运维永不可能，它的价值在于提升运维的稳定性和效率，而不是取而代之。