概述

每年的双十一对阿里的网络都是一次严峻的考验。在双十一当天，阿里的网络必须承载来自于世界各地数以亿计的用户所带来的巨大流量，任何故障的影响力都会被成倍放大。尽管大家做了很多努力尽量去避免故障的发生，但是故障仍然还是会发生，尤如阿里现今的大体量。这个时候，快速可靠的的故障恢复机制就尤为关键了。随着网络体量的急剧扩大，以及架构的多样化发展，通过人工手段去恢复故障已经不能满足业务对网络高可用性、高可靠性的要求了。在这个过程中，自动化的故障恢复应运而生。

我们处理故障的主要流程是：监控采集->故障发现->根因定位->故障恢复

图1 自动恢复整体流程

丰富的采集

目前每天的数据采集量接近万亿级的水平，采集的类型包括日志、SNMP采集（路由器交换机性能指标采集）、AliPing采集（内网质量采集）、AliInternet采集（互联网质量采集）、Netflow采集（流数据采集）等。

SNMP采集

网络设备跟服务器不一样，需要通过拉取的方式将设备的metrics抓取出来。我们采取的策略是划分采集域进行数据的拉取，然后集中计算。

各个采集域之间做好备份：

图2 SNMP&Syslog采集

AliPing采集

除了对网络设备metric的监控，同时要基于网络丢包和延时，更快速和准确地判断网络故障。我们模拟业务网络特征，构建ICMP/TCP Ping探测的报文，对全网所有物理服务器进行探测。

图3 Aliping(内网网络质量)整体架构

AliInternet采集

互联网是阿里网络的延伸，互联网的质量不是由谁统一控制的，任一节点都有故障风险，完善的监控以及快速响应就显得尤为关键了。从全球IP地址库为每个国家，每个运营商动态挑选存活IP进行探测，每分钟千万级IP进行探测。

图4 AliInternet(互联网网网络质量)整体架构

其他

除了上面所述的数据以外，我们还采集了全网路由器的Netflow数据，LVS VIP流量数据，Anat session日志等。

灵活的告警（故障发现）

• 基础事件*

我们通过实时流计算，将采集到的数据转换为一个个异常的事件，比如一次端口中断、协议中断、板卡离线、延迟超过基线等。在基础事件的生成过程中我们主要采用了Spark Streaming的技术。

为什么要采用Spark呢？

• 在线和离线的混合计算
• 非常方便整合外部数据源
• 高性能和易用性
• 机器学习和图计算
• 可以和目前的HBase、MR等复用Yarn集群资源

在两年多以前我们开始使用Spark的时候，集团没有完善的Spark任务管理平台。我们开发了RCS平台，RCS平台主要帮我们解决了如下几个问题：

• 代码或程序Jar管理
• 运行期参数管理
• 调度Spark的Yarn集群管理
• 提交Spark任务的支持
• Spark任务监控和报警管理

我们通过集成Apache Zeppelin实现了Spark任务的管理：

图5 基于Zeppelin的单集群管理

考虑到在出现恶性故障时，集群可能不稳定。但是故障发现系统要确保高可用性，我们设计了多集群容灾迁移的功能，以确保故障时任务能够在集群间迁移。

图6 基于Zeppelin的多集群管理

CEP复杂事件引擎

在产生一个个基础异常事件以后，就是如何配置合适的规则，生成正确的告警。在这里我们采用了CEP引擎Siddhi，这样就大大加强了配置的灵活性。

比如我们可以配置如下的告警：

阀值比例(流量大于70%)

发生频率（端口Down一分钟十次）

聚合阀值（链路组25%链路中断，同一集群20%NC Ping失败）

条件组合（流量超过70%并且出现丢包）

图7 整体的告警流程

告警收敛

在生成告警以后，我们又基于拓扑对告警事件进行了收敛，以确保在故障场景下能够精准地定位主要的告警。我们收敛的过程是通过在一个连通子图内基于PageRank对告警的设备和事件进行打分，打分最高的设备和事件被认定为故障主要告警。

图8 告警收敛

故障定位&自动恢复

在确定主要告警以后，我们就需要针对不同的告警定制不同的分析策略和故障恢复策略。我们提供一个平台，让运营的同学提交脚本，更全面、灵活的覆盖到所有的告警场景。

这是我们故障恢复的整体运行流程：

图9 故障恢复的流程

举一个例子，这是外围出现运营商的重大故障时：

图10 运营商故障自动恢复

总结

在过去的两年多中，我们从监控的全面性做起，逐步对阿里网络形成了一个立体的监控，并且通过告警的自定义和收敛，让故障告警更加精炼、准确。目前网络告警已经有47%通过系统自动化完成，后续这一比例会逐步提高。我们很高兴能够看到业务的运营模式从救火队员逐步迈向智能化的领域。后续我们希望能够逐步把这个比例提高到90%以上，并且进一步地减少故障的发生和缩短故障的恢复时间。