导言
后羿：阿里巴巴资深技术专家，参与8年双11大战，主导阿里“去IOE”战略落地，目前在推动阿里基础设施智能化。
后羿此次给大家分享的是双11的智能化网络实践，关于如何在网络智能领域通过数据手段极致地优化运营场景，在稳定性、成本、效率方面提升网络运营竞争力，给大家呈现了阿里巴巴在双11中主要依赖的网络相关技术。在今年双11中我们在稳定性、高性能网关、去堆叠以及25G、骨干网流量调度平台、流量的精准评估、QOS优化和成本优化方面都取得了突破性的进展。
阿里巴巴资深技术专家后羿
助力双11的重要网络技术
在稳定性的强化方面，在过去一年，阿里巴巴借助智能化手段，在故障的快速发现、自动修复、自动变更、快速诊断的能力上都有很大的强化，使之轻松应对双11流量高峰时的突发稳定性问题；在优化高性能网关方面，ANAT吞吐量性能16倍的提升和LVS性能8倍的提升使阿里巴巴轻松应对ANAT转发网关的压力；4.2架构支持去堆叠能力，提高了架构可靠性；25G技术在5.0网络架构开始规模化使用，在存储计算分离和在线混布场景中也开始落地；骨干网流量调度平台做到了保底带宽、延迟的优化等方面都有好的用户体验。
在过去一段时间内，阿里云水立方做到了基于应用维度、按时间维度、任意角度的灵活运营流量精准评估能力。利用水立方预测双11业务流量和容量的分配，在端到端QOS优化方面，阿里巴巴在存储计算分离，在线离线存储混布场景，及交易、支付等对用户体验要求较高场景中获得了更好的用户体验，保证相关的请求能得到优先的传输。在成本优化方面，AGN2.0骨干网升级取得了很大的进展，自研光模块和AOC的全面落地都使得整体成本得到很好的优化。
阿里巴巴是一个拥有百万级物理和虚拟网络设备、承载多样业务的遍布全球的统一的物理网络。不同的供应商在不同时期、不同版本、不同架构的管理都是不同的，我们需要付出更多的精力驾驭一个复杂的网络结构。面对大量级的物理和虚拟网络设备时，如何用一套优化的工程方法去进行分析数据；如何基于这些数据在后期做快速故障发现和定位；不同形态的业务对网络有不一样的需求，如何在兼顾资源利用率同时达到用户体验很好的平衡；在面临业务波动频繁的情况下，如何自证清白；在这些过程中如何快速完成综合处理……这些都是阿里巴巴需要解决的客观的工程难题。
上图呈现的是我们在2015年之后在网络稳定性提升方面的具体数据。从这张图中可以看出，我们在15年到17年期间，稳定性得到了很好的优化。2017年P1 P2故障数对比2015年全年收敛了83%；P1 P2的故障数在十分钟内的恢复率对比2016年也得到了很好的改善。2016年在10分钟内的故障恢复率为38%，而在2017年则达到了72%。需要强调的一点是，阿里巴巴网络设备大幅度增长，而网络工程师和网络运维人员并无大幅度增长。这主要得益于过去两年我们在智能化上的投入。
如何改进处理故障过程？
我们将网络运营中的故障简单的划分成变更类故障和非变更类故障：
- 对于变更类故障，借助自动化变更这类自动化工具来解决变更带来的稳定性隐患，通过快速迭代、快速优化过程让故障快速收敛。
- 对于非变更类故障，在故障发生前，通过加大巡检力度，实时探测当前线上的配置是否存在漏洞，并将巡检结果呈现给运营工程师，运营工程师会系统化的逐步修复这些漏洞。
我们也在构建科学预测方法，用网络故障库的形式逐步构建全网网络故障特征工程。利用特征库预测故障存在的可能，做到防范于未然。在故障发生后，做到快速发现、快速诊断，当我们已经可以很好的定性一个特征故障时，快速对其进行修复。
快速发现模块主要是用来提升精准探测能力，诊断模块用于提升端到端故障诊断速度。同时，我们也在积极构建整体网络故障特征库。通过分析历史网络故障体现的量化特征，精确描述故障的形态和量化特点，帮助我们预知未来网络的潜在的故障。巡检系统在过去一年已经稳定上线，自动化变更系统帮助我们很好的驾驭每一天面临的大量的变更需求。这些就是我们在解决网络稳定性方面的整体思路。
当我们已经可以发现故障、定性故障时，通过监控系统和修复系统的快速联动完成自修复，从而达成闭环，这就是阿里巴巴网络故障的自恢复。下图展示了网络自恢复过程及其自动完成信息的对接和中间逻辑的判断。
网络自恢复相当于快速发现和修复两个模块的自联动的过程。当故障已经发生时，如何做到“发现即被修复”？
网络自恢复主要有以下五部分构成：
- 端口/链路类异常自动隔离。
- 板卡类异常自动隔离。
- 运营商流量智能调度容灾切换。
- 堆叠分裂类异常自动恢复。
- 防火墙异常的自动切换。
后续会逐步加入更多的场景。随着场景的增多，到目前我们已经有60%以上的风险隐患实现了自动化的处理，大大降低了故障问题处理的时长，实现了真正的故障快速恢复，这也证明我们全面进入了自动化调度的时代。网络故障处理全面进入自动化处理和智能化调度时代，60%以上的风险隐患已经实现了自动化处理，大大降低了问题处理时长，实现故障的快速恢复。
自恢复是一种怎样的体验？当监控系统探知到一个具体故障正在发生时，就会调用修复模块来完成故障修复，并在发现故障和修复完成故障后推送一条信息告知用户情况。这个过程几乎不需要人为的干预。我们希望借助一个大脑全面评估当下稳定性的情况，精准确认问题后通过调度工具平台完成修复过程。这也是一个推动智能化的过程。
智能调度与自动隔离
如何解决好运营商的割接以及网络的抖动的问题，避免用户体验的下降和故障的发生是我们花很大时间研究的课题。通过对网络质量的全面感知，告诉业务系统哪里正在出现网络质量恶化和变动，这意味着我们需要做一些工作来改善整体用户体验。在实际操作过程中，有很多细节需要我们考虑。运营商自动切换的过程基本都能在不需人工干预的情况下快速完成。
从图中可以看出，自从上线了自动化场景后，BGP出口自动化切换的成功率是100%，每自动化切换一次都意味着系统帮助我们规避了一起故障。
在自动隔离场景中，由于网络设备在运行过程中经常会出现故障，在快速修复之前前，隔离是在网络工程师解决问题的首要工作。从图中可以看出，自动隔离功能上线后，90%以上的隔离操作能自动完成，而且成功率高达95%，这样不仅省去了很多的人工还规避了很多潜在故障。
基于北斗系统的“快速发现”
北斗故障识别智能引擎有在线日志实时分析、异常流量实时探测、告警收敛三大模块帮助精准定位和发现。在线上我们每天要处理万亿级的数据信息，通过算法识别出大概1亿条的基础事件，进一步识别后我们形成23万左右的复杂事件，对复杂事件收敛形成300条左右的事件，其中有进30条左右被转化为工单。工单一般是通过人工干预或无人值守自动化方式消化工单。
北斗故障识别智能引擎的工作流程主要分为四步：
- 利用庞大的数据采集系统，将N多维度数据实时从设备服务器中采集汇总；
- 在实时计算平台中利用各种机器学习算法和领域规则来完成基于场景的综合分析；
- 通过各种告警规则生成复杂事件；
- 对复杂事件进一步收敛。
在线日志实时分析
我们已经对海量实时日志有97%以上的识别率，每天处理数亿条平面日志，从日志中通过文本分析和积累，加上人工打标，覆盖了所有厂商日志型号。剩余3%也有经验丰富的网络工程师帮助我们进一步打标，完善知识库。这是日志分析的大概运作原理。
异常流量实时探测
为什么我们需要专门的模块来做异常流量的识别？因为某些数据不能通过传统方式确认其是否异常，如延迟、日志量、网络流量，这个数据在某个时段是正常的，但在另一个时段里是异常的。流量异常识别模块解决了如何构建一种智能决策算法，根据时间点和场景动态调整对应基线的问题。
告警收敛
当收敛出几十万条异常事件后，如何进一步确定异常的来源？我们将网络的拓扑加入在图计算引擎中。在对应一个时间窗口内，点亮所有产生告警信息的事件对应的拓扑图结构上。当连续一段拓扑被点亮后，把它当做一个故障联通子图，利用智能化算法对对应节点打分。通过rank值来确定出现故障设备源头。
自动变更的作用
自动化变更已经成为一个非常基础的能力，它和内部很多工具模块和业务平台完成对接，使数据得到了打通，降低故障率的同时提高效率。
为什么要有自动变更模块？
在运营百万级网络设备的情况下，每天会面临非常多类似打补、OsS升级、路由变化、IP扩容、回收等的变更需求。
在过去，这些变更操作高达85%的部分都是由人工来完成的。有些业务的操作需要规避白天时间，很多工程师由于长期在晚上进行高危变更操作，得不到好的休息，工作容易出错导致性循环，带来难以控制的风险。
由于变更工作的线下操作，很多可以变成经验的东西没有很好的在线上沉淀，而线下监测环节又比较薄弱。
历史上一边工程师在操作变更，一边故障在蔓延的事不仅一次出现。如何做到变更的同时进行监测，实时感受变更现场网络态势感知是非常重要的。
一些高危的变更需要引入审核机制，这些都是我们之前面临的现实问题。
我们是如何解决上述问题的呢？
总的来说就是运用通用的方法，更多的引用智能的手段，减少人工介入。一块块简单的乐高积木可以拼凑出如房子、飞机等非常复杂的形象。乐高积木的例子启示我们对需要展开的变更操作进行原子化的抽象，然后运用状态机组合成各式复杂的变更。在变更的同时，实时采集对应设备线上的告警信息，这些信息能告诉我们当下的变更是怎样一种情况。变更进行过程中是否有大量告警信息急速蔓延，决定着我们当下是否需要回滚，是否需要做现场决策和支持。
从图中可以看出，在2017年自动化变更上线后，变更引起的故障率有很大的降低，50%以上的变更实现了自动化，人员的误操作概率降为0。可想而知，变更的优化效率得到了很大的提升。
网络端到端智能快速诊断系统“庖丁”
在实际中我们经常会面临这样一个问题，某个地方丢包比较高或者两个点之间应用出现了严重的超时，究竟是怎么引起的？如果用人工的方式进行定位，首先要解决如何了解两个点之间端到端网络拓扑是怎样一种结构。拓扑上现在有故障在发生吗？如果有，这些故障设备究竟产生了哪些日志、过程中是否有变更在进行？如果已经知道是哪些设备为可疑对象，可能接下来对设备进一步下发命令、对数据做深入诊断，整个过程大概需要1-2小时。
而庖丁可以同时进行网络拓扑发现、告警信息自动聚合分析、日志信息自动获取、命令工具自动下发这四项工作，把整个复杂问题的定位时长从1-2个小时缩减为3分钟，给各类场景带来极大的诊断效率提升。针对已经确定的两个点的IP，我们自动定义出所对应的IP拓扑是怎样一种结构；对相应拓扑链路上的所有日志进行实时提取、标注关键词；对可疑设备的告警进行自动化聚合收敛、过滤无效信息；主动对可疑设备进行可疑探测、做二次分析。这些过程几乎是一键完成。
庖丁运作的可视化呈现如图。对可疑故障链路进行标红处理，通过庖丁可视化界面，轻松判断故障的发生原因。
在故障发现、探测的最终结果可以对具体的用户呈现，也可以通过API形式对业务系统进行主动的信息推送。这意味着上层业务网络查询更加开放，通过对庖丁的一次查询可以得知某个业务波动是否是属于网络带来的问题。
基于NetO做流量最优化的分配
通过最优化流量分配来榨干多余带宽成本，同时满足最优路径选择、带宽扩容、稳定性方面的现实需求。
- 技术层面。我们希望每次网络路径都是最优的。传统网络基本基于Metric机制确定最短路径。对于阿里这张具有多样链路的网络，交易链路对网络的延迟极其敏感，大数据需要很大的带宽，需要更多可达路径帮助快速进行数据的传输。
- 带宽扩容角度。在面临非常频繁的带宽扩容需求情况下，实际的定时链路存在很多延时差异，两个点之间的路径带宽差异也很明显，我们需要站在运营的角度构建某种方法，既能充分利用闲置的带宽，又能在调配流量过程中很好的兼顾时延和成本。
- 稳定性方面。并行的链路在出现单点故障时，需要对其进行隔离，隔离后如何触发高可用路由决策。这些都是NetO需要解决的问题。NetO基于SDN采用了SR-TE技术，帮助我们在全局情况下拿到全网流量信息、路由状态信息，用这些信息帮助我们按场景进行路径转发。
NetO整体智能决策层模块——阔海
阔海有两大核心职能：
- 最大化业务目标。不同的场景有不同的需求，我们希望NetO可以根据各种限制条件对每个场景综合分析，定制最优解决方案。
- 以无拥塞方式达成最优分配方案。这要求我们最少的步骤解决问题，每一步对应的命令需要设备的支持。阔海帮助我们做到最大化利用链路上限，在每次流量调整中，即不触及带宽上限又能完成最优化调整，实现最小步骤的迁移。
阔海有两种驱动方式，一是周期性运行；二是通过突事件触发，如拓扑发生变化、流量发生变化等。阔海一个数据平台，需要用各个维度的实时数据来进行现状态势感知，通过数据背后业务含义帮助我们制定最优化分配方案。这些方案完全可以按不同需求对成本、时延、带宽利用率组合定制场景。
- 阔海有非常好的可靠性来帮助它做负载均衡。每次计算出的最优化结果可以通过两种方式来呈现：
- 通过仿真在web页面来呈现，告诉运营决策人员最优化结果会达成怎样的效果，让对应运营人员做现状评估。
- 直接用最优化结果进行设备命令的下发，完成一次优化调度。
这里给大家举三种常见的场景，黑色线条代表物理链路，其他颜色线条代表逻辑链路。
故障状态下的负载均衡
从第一个场景的图中可以看到三条链路在初始状态下进行数据的通信。通信链路出现单点故障时， NetO会把蓝色链路的流量动态的分配到其他两条链路上去。
针对高费用链路的解决措施
从实际角度出发，每条链路意味着不同的资费，为了节省成本，提高资源利用率，我们完全可以采取灵活的策略来运行。如下图所示，我们在运行过程中发现其中一条链路的成本偏高，这时NetO会自动触发一次调用，把流量分配到相对来说成本较低的链路上，这个过程基本不需要人工的干预。
大数据场景优化传输时间
比如我们需要发送一个单位的数据，在初始状态下，以图中红绿两条链路发送数据时，由于带宽较小，需要两个时间周期完成数据的传输。NetO在整体链路上找到另外一条冗余带宽（蓝色链路），并提示系统把这个链路利用起来，这个调度过程触发了流量的再次优化分配。原本需要两个时间单位传输的数据在这条链路上一个时间单位就能完成。
以上就是阿里巴巴在双11中的网络智能化技术及在成本优化、流量智能化调度等方面相关实践的介绍。网络智能永远是一个在路上的过程，我们还在不断努力演进它。在未来一段时间内，我们会进一步在无人值守、成本优化和稳定性方面加大投入，给大家呈现更好的东西，带来更好的用户体验。
