点击视频查看完整分享回放

上图所示为腾讯云网路underlay架构，腾讯云的层级架构从上到下看，先是从地域Region级别，再到各可用区，最后到达网络计划模块。从这张图来看，往上走就是腾讯云的内网，往下走就是腾讯云的外网。

腾讯云的内网有三个连接：网络计划模块之间的连接，可用区之间的连接，以及跨地域之间的连接。腾讯云的外网主要接入了腾讯云三网带宽，以及BGP，另外还承载着外网流量调度的功能。

上图所示是腾讯云网络的overlay架构，overlay是基于underlay网络架构之上的，云的用户所使用的都是overlay的网络。overlay网络主要分为两个节点，一个是网络节点，一个是计算节点。

简单来讲overlay可以理解为：通过腾讯自研的SDN控制器来构建点到点的隧道。比如子机跟子机之间的通信在所在母机上面构建一个隧道，如果子机跟paas服务进行通信，就在SDN控制机上面构建一个母机到网关集群的隧道。

腾讯云现在已经拥有了40多个可用区，100多个Zone，服务器已经达到100W+了。这样的体量是非常大的，而且腾讯云还是在不停地演进当中，它的网络架构也在快速进行迭代，底层光缆错综复杂，不管是underlay还是overlay网络变更也非常得多，网络的故障也是各式各样的。

腾讯云网络作为腾讯云的基础设施，它承载所有云上数据的传输，它的稳定性决定云网络质量以及用户口碑。我们对网络的稳定性提出了更高的要求，对网络故障要做到：1分钟发现故障，3分钟故障恢复。

很多时候，网络隐患并不会立即演变成网络故障。网络故障在我理解看来它是有生命周期的，分为：事前的隐患阶段、事中网络变更阶段和事后网络故障阶段。

事前属于网络隐患阶段，可能会有一些异常事件发生，但是不至于影响到业务的正常使用；事中阶段很多基于网络的变更导致的网络突发情况；事后阶段，即由意外事件导致了网络故障。

为此，我们在隐患阶段引入了混沌工程的实践；在网络变更的时候，为了遏制网络变更导致的网络突发，我们引入了网络变更体检；在网络故障已经发生的阶段，我们通过建立网络监控，快速定位网络故障，尽快恢复，从而提升网络的可用性。

到2020年11月份，在混沌工程方面我们全年已经支持了500多起演习，发现了30+的网络问题；另外网络变更已经接入了1000多次，将网络变更故障总时长压缩在20分钟以下；在网络监控方面，我们做到了15-30秒发现网络问题。

1. 混沌工程

依上文所述，我们因为想要在网络故障前解决网络隐患，从而引入了混沌工程。那么混沌工程是怎么做的，它又是怎么在腾讯云网络上落地的呢？

首先我们需要了解一下什么是混沌工程？在我看来，混沌工程就是在生产环境上做一些探索性的实验，发现现网系统的脆弱环节，然后不断地提升这个系统的弹性。

因为随着服务化或微服务化的普及，以及CI/CD的引入，从开发到上线的整个过程开始变得非常便捷，但是这却使得在一个复杂的分布式系统里面，业务故障的随机不可预知的概率大大增加，进而引发整个网络的紊乱和故障，导致用户业务上的不可用。

虽然故障发生的时候我们有相应的监控和处理，但是我们还是希望在隐患还没有演变成网络故障的时候就能把它们挖掘出来，由此我们引入了混沌工程。

混沌工程跟测试是有一定区别的，最主要的一点我认为是环境的问题。混沌工程最终还是希望能到生产环境中去做印证演习，而测试主要还是以非生产环境为主。

此外演习对于运维人员也是一个考验，对大家的应急反应能力要求很高。另一个主要区别在于输入，测试一般是来做一些功能印证，输入和输出通常都是可以预知的，而混沌工程更多是一种意外事件的引入。

混沌工程在腾讯云网络故障产品中落地是网络演习，我们的演习场景一般都来自于现网的故障。一般情况下网络的异常包括：质量丢包、流量突增以及流量哈希负载不均，了解了这个事件以后，做演习时候就要找出它的关键路径，然后是它的业务指标。云网络的业务指标包括：路由的收敛、网络的质量和流量等。

在这个过程中，要有一些视图来指导你的演习，不然容易迷失。当我们有了稳态指标，在任务执行过程中对一些异常事件做处理，比如你要做隔离，那么隔离的工具是不是好用，设备是不是响应，网络是不是异常都是需要考虑的。

最为重要的一点是，在做混沌工程的时候，不能把实验变成一次网络故障。你需要极力控制它的影响范围，一旦影响范围扩大了就需要有回滚措施。主要就是故障注入和故障销毁，故障注入就是异常的注入，故障销毁就是如果演习终止或者结束了故障要及时销毁。

最后我们做的这些演习都希望演变成可自动化执行的流程，所以对稳态指标的判定、故障的自动销毁、异常的处理、故障的隔离都要有相应的措施，不能让意外演变成一次故障。演习结束的时候，我们也要对演习报告和产生的问题进行汇总分析，抽象成一些场景以及后续推进演习的优化方案。

2. 变更体检

整个腾讯云的体量在不断增长，网络架构也在不断演进，相应的网络变更数量也是水涨船高。网络变更在腾讯云上有一套比较标准的管理规范，需要建立规范基线，变更要有时间窗口，变更的申请、审批、实施、公告都要做到很全面。

对网络变更需要归类出场景，由这些场景再提炼出比较好的实施方案。另外变更还需要进行审批，审批主要是去看变更的技术环节以及风险控制，以及对横向影响面的评估把握。

最后在变更实施的时候，我们还要沉淀出一套风险控制的理论，尽量把风险压缩到最低，找出一些最佳实践。当我们有了比较成熟的或者风险比较小的方案后，将它引入自动化的变更实施，做到无人值守。

即使有了这些规范，实际情况还是会存在一些网络变更的问题，主要是哪些问题呢？一个是网络变更对业务团队是不透明的。第二个问题是网络变更人员其实是没有感知业务的指标数据，做不到故障的感知，业务方在定位问题的时候也不能很快地关联到网络变更。

经分析，最主要的问题在于：网络变更的时候缺少自己的业务指标的监控。所以这块我们引入了网络变更体检。

网络变更体检主要是在什么环节呢？网络变更审批完之后我们就要添加相应的网络变更任务。在网络变更任务的变更实施的窗口期就要做执行监控分析，由于网络变更往往基于一个点的变更，所以存在一些能很好探测业务的指标作为异常评判。

但是有些变更业务指标很难采到样本，那么该去做呢？在这里我们会做一些关联业务指标的告警分析。

3. 网络监控

除了网络变更，还有一项举措是必不可少的，那就是网络监控。我们对网络监控的要求是：快、准、全，并且颗粒度要求足够细。

腾讯云网络监控需要覆盖非常多的场景，包括外网运营商、内网LAN&DCI、网关集群质量、转发质量监控、专线监控等，监控的方式也各式各样，包括Ping、TraceRoute、Curl、Socket等。

另外还需要提高告警精准性，能够做到快速精准定位，减少故障影响时间，监控粒度为5-10秒这个级别，故障发生后要求15-30秒发现问题。

怎么做到精准呢？首先你的探测源必须是稳定的，不能有高负载的情况。另外探测源和探测目标之间的路径应该是很短的，如果路径很长，当异常发生的时候你的问题往往也定位不清。此外你采集的样本必须是较为稳定的，不能这一会儿是活的，下一会儿直接不通了。

做网络监控我们又面临了哪些挑战呢？首先在于目标指标的采集，其实不是样本越多就越好，我们希望能用比较少量但精准的样本来反应情况，但是准确的样本还要保证它是长期活跃的，如果它的状态是“半死不活”的，那么对监控采样数据的干扰性就会比较大。最后探测的问题也需要覆盖得比较全面。

第二个挑战在于快速发现问题，只有探测的粒度足够细，监控定位的速度才能够快上来，但是探测快了多了以后，别人发现了可能就做一些动作来限制你。

其次我们还需要采取一些策略，当数据采集上来之后，能够对这些数据做快速全面的异常检测。网络异常不仅仅指突发性持续异常，对于网络不连续抖动这样的异常，我们也需要能监控到。

对此，腾讯云制定了下面的网络监控的方案。在探活阶段把高质量样本调进来，然后进入到探测池，在探测池里构建出循环探测，探测器就只管自己的探测，探测完之后数据快速落到存储里面。数据落进来之后，我们的探测不再是纯粹的探测发现问题，还需要具备问题分析能力。

在探测的时候，我们需要结合探测路径以及路径上的网络设备的日志，再结合一些指标，比如流量是否发生变化等做分析，来定位网络问题。

如上文所述，在网络排障方面，我们针对网络隐患采用了混沌工程的实验；对于网络变更，我们引入了变更体检；在网络监控方面我们已经比较全面和准确的覆盖了现网问题。

未来我们还需要深入探索，在网络隐患层面，除了混沌工程还有没有其他更好的方法呢。另外，我们现在很多的网络定位是通过抓包来实现的，但是路径一旦变长，这件事就开始变得不可控，而且也不好进行协调，所以我们也在思考：在故障定位上是不是也有一些别的方法可以去做呢？最后，我们也希望在网络故障的时候系统能做到一定的网络自愈。

为此，我们也做了很多的尝试。在网络故障预测方面，我们想结合网络设备的syslog、snmp等数据提前挖掘出网络隐患。

在排障方面，我们希望能够做到全链路的排障，结合网络拓扑、流量染色、镜像等综合分析，把网络故障的定位做得更好。

最后是故障自愈方面，在于网络流量的自动化调度和网络设备、链路故障自动化隔离。

A：通过点来做主要是因为点的监控会更加精准，只要这个点可以采集到业务指标。另外做探测一定要靠近它，链路要短，这样探测到问题那基本上就是这个点的问题了。但是当我没办法拿到这个点的探测业务指标数据该怎么办呢？根据网络层级结构，会有关联到上下联的网络设备，这时候你把关联做起来，如果发现上下联出问题了，就要第一时间定位是不这个点引起的，因为正常的话上下联是不会有问题的，通常是网络变更导致产生问题。前文也提到了我们会设有红绿灯机制，对于准确率很高的联系就会直接强制要求马上回滚，减少故障影响，对于这种面的问题通常需要运维的介入。

Q：刚刚老师讲到：链路比较长的话要缩短探测链路。如果链路很长就会分成多段探测，还有很多分支，对于各种故障的点，可能一下子检测出来的点会很多，这种人工去分析的话很难，有没有技术上的手段做判断？

A：这是自动化分析，异常目标数据是有探测路径的，我们在探测路径上可以做一层汇聚，大家走的公共节点是哪个，那大概率就是你的问题。

Q：我们的log那么多，除了自动化的分析方法之外，还有没有利用深度学习或机器学习的方法来进行？

A：有一些尝试，主要是做日志异常的检测。

Q：我们对监控的数据要做标注，是之前已经做好的还是怎样的？

A：我们现在采用的是以无监督的居多。日志打标是比较耗时耗力的工作，但不是说完全不可以做，目前也有团队在做这个事情，会对日志做一些基于规则的打标工作。

Q：刚刚提到网络变更可能会导致网络故障，如果业务监控不全，它自己排查不出来业务故障，能不能单个业务去做网络变更？比如这个应用没有做好灾备就故障了，事后我要去排查为什么会故障，要去解决这个问题，但是我又想把这个场景复现一下，需要运维团队协助吗？

A：我们就是全链路的排障，这样就能通过模拟流量把问题分析出来。