企业云网SD-Branch部署实战指南

去年这个时候写了一篇SD-Branch在国内的市场与应用分析，当时调研发现很多企业IT对这个新生概念还处于了解学习阶段，基本没有实践经验，立项实施过的更是凤毛麟角。

但在这一年时间里，仅从我看到的咨询线索和实际部署案例来看，就明显能感觉到SD-Branch的市场接受度在迅速提升。尤其以互联网为代表的科技企业，因为业务已经大量云化部署的原因，迅速推动乃至倒逼着网的云化转型。

而企业网络云化转型，也就是企业云网，恰恰是SD-Branch这个概念诞生的原因之一。

Tips：云网这个词和SD-WAN一样，已经从一个技术概念变成了一个营销词汇了，市场上恨不得有无数种解读。具体到企业云网，你理解为企业业务和数据已经上云的情况下，以云和数据中心为核心构建的企业网络就是了。

当然，转型的过程不会一帆风顺。对于很多企业IT人员来说，不光是专业知识和经验方面的问题，传统组网理念的包袱更可怕。你会发现很多“真理”并不完全适用于企业云网，有时甚至会放大伪需求，让方案设计误入歧途，以至于“解放思想”成了这一年中我给出最多的建议。

正好最近接触到一个非常具有代表性的案例，我就借这个企业的实际需求，聊聊云网改造的具体思路，以及SD-Branch是否真能满足企业业务云化带来的新需求。我还实际部署了一套可以直接用做POC的Demo，看看使用行业一线厂商的产品方案能有怎样的体验，希望能帮更多有类似需求的企业IT人员直接对号入座(chao)，少走弯路(zuo)，事半功倍(ye)。

业务云化对经典组网的必然冲击

简单介绍下这个企业：一个成立只有几年的科技制造业新贵，因所处赛道享有政策红利，无论市场规模还是企业规模，都持续快速增长。目前，该企业已经拥有几千人的产品研发团队，数个自建工厂及遍布全国的自营销售服务门店，为消费者提供涵盖产品全生命周期的服务。未来两年，公司计划在二三线城市拓展直营门店，继续深挖国内市场，同时启动海外市场。

想保持高速成长，企业网络建设自然不能拖后腿。

很难通过文字把一个近万人企业的业务和组网结构描述清楚，我简单画了个图，可能理解起来会容易一些。

示意图，仅体现互联结构，不代表具体区域数量、链路/设备的种类/数量

从业务属性上，整个企业网络可以大概划分为生产与办公两个区域。这里所说的生产，主要指的是制造、经营行为所涉及的业务环境，而办公则指互联网访问(工厂生产使用的独立网络，我们暂不算在企业网络范畴)。从安全管理角度出发，除门店外，不同功能区域的设备，即便功能重叠，也不会复用，一律分开独立部署。

IDC里部署了几乎所有生产环境，是企业核心资产所在。无论总部研发、工厂制造还是门店销售与服务，都需要实时访问部署在IDC里的业务平台。一旦IDC的访问出现问题，那就是0级事故，直接造成经济损失。

有鉴于此，该企业的总部、门店与工厂都采用了专线连接到IDC，来保证业务访问的品质与可用性。同时所有节点也基于DIA做了IPSec组网，做为专线故障时的备份链路，进一步提升了业务可用性。

生产环境的安全级别要求也是最高的，不管是业务平台被攻击还是数据泄露，造成的经济损失大概率比网络中断还要高。所以在总部、工厂和IDC，企业安全部门还部署了各种安全防护方案，对访问业务平台的流量进行检测和控制。如果要接触高密级数据，流量甚至还要经过网闸，执行非常严格的访问管控。

此外，有一部分办公业务已经上云，未来计划会有包括个别生产平台在内的更多业务迁移到公有云。这类业务普遍需要频繁访问且数据密级不高，无论从成本还是效果看，都更适合部署在公有云平台。

办公网则相对简单，还是常见的多分支互联和远程接入场景。分支办公区采用专线和基于DIA的IPSec与总部组网，业务流量会统一汇总到总部再转发。无论在总部还是分支，都有员工日常需要访问海外SaaS和行业站点，这些流量也会统一从总部申请安装的优质链路进行访问。

持续已久的疫情正在改变企业的办公模式，对IT部门而言，这两年远程办公压力增长非常迅猛。去年初，该企业也遭遇了突然全员远程办公情况下的SSL VPN设备性能瓶颈，当时通过紧急升级设备、购买更多接入授权的方式加以解决。考虑到疫情发展带来的不确定性，IT部门已有考虑在IDC部署第二个SSL VPN接入点。

整体来看，目前该企业网络建设相对完善，有效支撑了日常办公与生产。那IT部门还会有什么样的痛点呢?

首当其冲的，就是线下门店的建设与运维。起初，IT部门采用两家供应商的产品搭建了标准化模型，一个传统数通厂商的网关用来解决上网和分支互联组网需求，另一个主打云管理的厂商提供交换机和AP解决内网接入的问题。

在之前开店速度并不快的情况下，他们已经感到开局效率太低。就算网关已经用上了U盘开局，异构组网的复杂性也注定需要IT人员在现场驻留更多时间。面对未来的高速开店计划，IT部门并不是很有信心。

后期运维也是个麻烦事，尤其在远程排查终端上网体验问题上，被寄予厚望的云管理平台由于缺乏网络边缘的数据，智能运维能力受到很大限制。而在两个不同平台间切换排障的结果，有时真比直接登设备敲命令还慢。现在，他们已经在调研新方案，准备转向单一供应商。

IT部门的第二个痛点，是被要求实现门店接入的降本增效。

对于工厂和总部来说，生产环境的访问品质和连通性是比较好保障的——专线带宽不够可以扩、一条不放心可以再拉一条，实在不行还有不止一条大带宽DIA起IPSec做备份，拥塞和访问中断的可能性微乎其微。但对于海量门店来说就不好办了，在成本压力面前，目前的标准化模型只包括一条专线加一条DIA，带宽也仅属于勉强够用的水平。

但门店运营部门并不满意，他们反馈了两个问题：首先，接入成本还是相对较高，希望能再降降。其次，成本高还“慢”，一些门店反馈有的操作需要等待很久，甚至以天为单位。

后者只有用IT语言才能精准描述：门店几乎所有售后服务都要与业务平台交互操作，其中大部分数据量都很小，对网络带宽没有太高要求;但某些大维修项目需要下载完整的结构数据，单次的数据量就能达到30-40GB。最要命的是，这种结构数据是针对单品输出的，任意两件都不相同，更不能混用，也就没有了缓存分发的可能。

专线品质再好，也是个小水管，如果赶上同时几个大修工单，传个一两天确实是正常的。

此外，第三方业务对DIA的刚性需求，也引起了IT部门的担忧。比如外部合作伙伴为门店策划的引流活动，需要店员使用特定终端访问第三方平台提取数据，如果赶巧DIA出现问题，专线又访问不了互联网，业务就没法办了。

这种情况已经出现过一次，IT部门觉得是个不小的雷，需要重视解决。跨平台的生产数据交互在商业场景已经比较常见，并且会越来越多。去年我做某SD-WAN方案在能源行业场景评估时就遇到过这个问题，加油站现在有大量第三方平台接入，比如滴滴司机端这种，需要商家在线核销。如果访问不了互联网了，业务就只能停办，现场会有大麻烦。

第三个痛点，就是分支办公区访问业务平台和海外SaaS的体验问题。

分支办公区通过专线与基于DIA的IPSec备线连接到总部，访问业务平台的流量经由总部再去往公有云或IDC，这有利于安全防护和权限控制，却对总部的带宽有着很高要求，并且多少会影响访问体验，尤其对那些分布距离比较远的分支来说。

另一方面，分支员工访问海外SaaS的问题也很难妥善解决，他们目前的做法是IT部门自己整理出SaaS的IP范围，通过OSPF把这些地址段推到每个分支，让匹配到的流量回到总部，再从优质链路进行访问。这除了刚才说的带宽占用和绕路带来的体验下降外，还存在一个IP范围准确度的问题。用他们自己的话说，人肉维护这个路由表的成本太高，并且费力不讨好，没人愿意干。

最后一个痛点，就是远程办公接入的品质问题。

去年初的紧急扩容解决了SSL VPN的可用性问题，但没过多久IT部门就发现，问题看似解决的背后，却牵扯出更多的麻烦。

问题根源在于员工在家访问海外SaaS的品质需求。最好的解决方案是将自行维护整理的路由表和内网IP段一起推到每个终端，让需要走总部的流量进隧道。可他们之前调研就发现，不管是目前使用的SSL VPN方案，还是其它几个知名解决方案，都不支持给终端推送那么多路由条目。所以最后他们还是下发了全0路由，将远程终端的所有流量都拉回总部。

坦率地说，疫情前这么搞不会有大问题，但在疫情反复、行政部门给出明确到岗比例要求的时候，企业总部DIA的使用率就会有明显上升了，有段时间甚至经常性地拉出一条直线。员工对远程办公的体验自然很不满，他们最直观的感受就是慢——业务平台也慢，SaaS也慢，甚至自己摸鱼追个剧都慢。而且他们有足够证据表明，这不是家里WiFi和宽带的问题。最终，IT部门被大量有关远程办公的报障工单所淹没，整体绩效长期在低水平徘徊。除了以上几个明确的痛点，IT部门还有相当多的牢骚，不过债多了不愁，那些他们自己都不觉得优先级高的问题，我在此就不展开讲了。

企业云网：SD-Branch的最佳使用场景

其实在我看来，企业IT部门面临的所有问题都有其必然性，是传统组网模式面对业务云化一定会遇到的问题。

问题的关键是业务在哪、数据在哪。在它们都放在总部机房里的年代，访问业务和数据的流量就是要回到总部，所以以企业总部为核心组网是非常合适的，性价比也是最高的。但当它们迁移到云和数据中心，总部再做为流量枢纽，无论从成本、体验还是运维复杂度来看，都显然有些不合时宜。

实际上，不管愿不愿意，业务上云都会直接驱动组网逻辑从以总部为核心，转向以云和数据中心为核心。在完成了分支业务上收、总部业务上云的过程后，企业IT部门必然会开始考虑云的访问品质保障、云上数据的安全防护和运维效率等问题。

从上面的互联结构图和介绍里就能清晰地看出，工厂和门店增加了访问IDC的独立专线和基于DIA的IPSec备线，安全防护的资源也已经在向IDC集中。这一步其实不涉及前面所说的“解放思想”，完全是不得已而为之，不这么干业务就有风险。

而在企业总部，除了个别员工需要偶尔调看下门店里的监控视频和IT部门的日常维护工作外，似乎就没有横向访问其它分支的业务需求了。流量都没有了，总部这个流量枢纽自然也就没有了存在的意义——对于网络结构而言，甚至已经不用区分是总部还是分支办公区了。

所以我的建议很简单，就是彻底转向云网架构。

示意图，仅体现互联结构，不代表具体区域数量、链路/设备的种类/数量

对案例企业来说，首要工作就是把IaaS资源也纳入企业网络范畴，与IDC共同承担网络枢纽的职责，顺带填补内部对IaaS业务的访问控制真空。无论办公区、工厂还是门店，只需要专线和DIA连接到云与IDC，即可保证大部分业务的一跳可达。就算出现跨节点访问的情况，多云互联的体验和成本通常也有着显著优势，并且易于扩展。尤其拓展海外业务时，只需做好不同区域IaaS和数据中心的连接，就能保证企业网络中任意分支节点访问业务乃至互访的体验。

另一方面，IaaS和IDC通常有着较好的互联网接入品质，远程接入和SaaS加速体验也能从中受益。对远程接入来说，IaaS带来了特别红利，虚拟化形态部署的VPN网关可以充分利用其敏捷、弹性的特点，很方便地减配/扩容——远程办公需求激增就加配置，接入能力无上限;需求减少就减配置，绝不浪费钱。IDC则在接入高品质链路方面存在价格优势，同样的链路资源，IDC接入的价格往往明显低于办公接入。此外，各地线路价格存在差异，可以尽量选择在价格洼地申请安装，将接入成本压倒最低。

互联架构到位后，就是SD-Branch的表演时间了。SD-Branch就是面向企业云网而生的，有企业云网就要有SD-Branch。

看看SD-Branch的定义：提供包括基础网元和SD-WAN在内的完整组网能力、整合安全能力、提供统一的管理运维能力、提供简化的部署与排障方式。再看看案例企业的需求和痛点，简直就是严格一一对应的关系。

第一个痛点，线下门店网络建设、管理、运维效率的问题，这是SD-Branch最能体现价值的领域。所有符合SD-Branch定义的方案，都应该包括有线、无线、路由/网关/防火墙在内的完整组网产品，并在统一的平台下提供管理、运维和网络加安全的一体化编排能力。零接触部署也是定义中的明确要求，实际上，很多市售SD-Branch方案已经开始支持4G/5G自动开局和出场预配置服务，让实施交付过程变得更快、更方便。

第二个痛点，门店接入费用的降本增效需求，对应的正是SD-Branch定义中SD-WAN的部分。从门店接入的成本构成上看，DIA接入费用比专线低一个数量级，带宽却大一个数量级，只做备线实在有点不划算。放眼全球，国内运营商的DIA品质都名列前茅，运营商之间的互联互通问题目前也基本得以解决，在保障访问品质的前提下，可以考虑让它适当承载更多的业务流量。这其实也是企业IT人员需要“解放思想”的重点，Gartner在最新报告中甚至直接提出了“摆脱MPLS”的口号——咱也别太激进，但对很多业务来说，DIA并非不可能。

第三个痛点，分支办公区访问业务平台和海外SaaS的体验问题，依然要靠SD-WAN解决。每个业务都有自己的流量模型，对链路品质的要求自然也不相同。在全网SD-WAN互联的情况下，IT人员可以根据业务对链路品质的不同需求，制定合理的选路策略，在保证体验和可用性的同时降低接入成本。对业务的定义也不再全靠人肉，Gartner在今年的报告中已经将基于应用的选路定为SD-WAN的通用属性，对主流商业SaaS的流量编排，就应该是点点鼠标那么简单。

本文不再对SD-WAN的概念、场景、市场做延展解读。如欲了解，敬请查阅《分支互联，是时候从VPN转向SD-WAN了》。

至于最后一个痛点，远程办公接入的问题，在SD-Branch定义中确实没有包含更好的解决方案。说实话，我感觉大部分厂商也没有意愿再去提升SSL VPN的产品力，也许是想把这个问题留给ZTNA或SASE去解决吧。但在云网结构下，SSL VPN的接入网关通常也会部署在IaaS和IDC，一来这里的互联网品质和连通性相对较好，二来这里距离业务也最近。

之所以说这个案例具有代表性，就是因为这个科技制造业新贵场景角色多，云网的结构很全面，SD-Branch的需求契合度最高。而SD-Branch带来的诸多价值中，我认为降本增效才是最重要的价值。为什么SD-Branch把定义从SD-WAN的WAN延展到LAN和Cloud/IDC，只因这才是连接端(用户)和云(业务)的完整管道。在完整管道上进行网络加安全的一体化编排，才是体验最好、管理运维最便捷的唯一实现方式。

用过的都懂，不理解的我举个小例子。

当一个员工反馈WiFi访问关键业务慢的时候，正常的IT排障流程肯定是排除法，要从终端接入的AP一直查到云，是一个巨长的链条。此时对企业IT人员来说，有的只能一台台登录设备去查，有的可以在不同网管平台下切换排查，而用了SD-Branch，只需在唯一且统一的一个界面下排查即可。这里效率差异有多大，干过网络运维的自然懂。

成本最高的测试是种怎样的体验

帮人帮到底，我根据案例企业的实际环境，把家里网络改造了一下，搭建了一套最小化的云网来验证需求。

云网的核心在北京AWS和广州某IDC，采用的都是虚拟化部署的FortiGate防火墙。互联网接入方面，AWS是默认的BGP接入，广州IDC是三线接入。在广州IDC顺便还拉了一条CN2，不为别的，只因单价仅为北京电信企业办公CN2(国际精品)接入的1/3。

在北京和上海，两个部署了Fortinet SAA的环境做为测试分支，都采用三线接入。这套方案本身已经在防火墙上实现了本地有线、无线的一体化管理运维，但要将这个能力和网络加安全的整体编排拓展到云网，满足SD-Branch的定义要求，还需要部署FortiManager来完成。

FortiManager早先就是Fortinet产品的统一管理平台，在云网时代，它顺理成章地转型成为SD-Branch方案的核心——大到整网SD-WAN互联，小到给某个分支某个部门甚至某个员工单独配置个SSID做接入，其管理、运维都在这一个平台上进行。在Fortinet的方案中，SD-WAN编排器甚至直接做成了FortiManager里的一个组件，用以支撑大规模组网时流量动态调度的需求。

安全和流量回溯分析则需要FortiAnalyzer来完成，这个组件其实已经包含在FortiManager里，但如果组网规模大、设备多，则通常会独立部署，以免遇到性能瓶颈。FortiAnalyzer早先主要为了满足安全方面的需求，但在云网时代，它还要留存对于动态选路极其重要的链路和应用品质的历史数据，变得有点不可或缺。

因为网络的管理分析需求总处于不断变化中，越来越多的企业都要求此类产品支持虚拟化部署，方便未来扩容。FortiManager和FortiAnalyzer在这方面做得比较完善，可以工作在各种主流虚拟化平台，比如这个Demo里，我就是在北京AWS直接拉起来的，点两下鼠标即可——当然，你的AWS账户里要先充钱。

Demo里有了云，有了网，有了产品方案，还要有业务。根据案例用户的实际情况，我在北京AWS起了一个企业网盘，在广州IDC起了个对象存储，做为测试业务。企业网盘是典型热数据的代表，需要频繁访问，尤其是通过互联网的访问，所以放在IaaS;对象存储则是冷数据的代表，访问频次低，但密级通常较高且与生产相关，所以放在IDC。

这样，一个脱胎于实际环境的企业云网Demo就搭出来了。我做了最大程度上的简化，但核心要素一个不缺，说可以直接用来POC都不为过。真要说有什么遗憾的，那就是没有拉专线——即便如此，这也是我做过的成本最高的测试了。

这个Demo我玩得很开心，感受也很多，篇幅限制就不一一列举了，捡两个重要的说。

最令人愉悦的当属全网SD-WAN互联给业务访问带来的品质与可用性提升。Demo的结构图只能简单表示互联结构，实际上双核心之间有三条隧道(AWSBGP-广州联通/广州电信/广州移动)，北京和上海分支到每个核心分别又有三条隧道(北京/上海联通-北京AWSBGP/广州联通、北京/上海电信-北京AWSBGP/广州电信、北京/上海移动-北京AWSBGP/广州移动)。也就是说，北京和上海分支的FortiGate上各有6条隧道，北京AWS和广州IDC的FortiGate-VM上各有9条隧道，做为云网的逻辑连接。

有这些连接做基础，就能利用SD-WAN实现针对业务的全网动态选路了。听起来高大上的实现其实只需两步操作，就以访问北京AWS上部署的网盘为例，首先是在FortiManager上定义针对网盘的探测参数，让设备进行不间断地探测。然后设置SD-WAN选路策略，告诉设备匹配到网盘业务流量时，根据上面的探测结果和怎样的加权算法进行选路即可。

加权算法一般根据业务流量模型来定，比如网盘通常对接口带宽使用率比较敏感，对延迟抖动丢包没那么敏感，那么就把前者的比重调大。这样的结果就是，不管北京还是上海分支访问北京AWS上的网盘，流量可能会走某条直连隧道，也可能绕行广州，可能走的不是质量最好的路径，但一定是最合适的路径。如果当前路由访问网盘突然出现中断或严重质量劣化(低于设定阈值)，设备会在很快时间内自动调整，一般也感知不到。

实际上，只要IT人员能定义出来的业务，就都可以享受全网动态选路的红利，分支间流量和海外SaaS也不例外。对海外SaaS来说，Fortinet的方案实现尤其完美。除了全网动态选路，做SD-WAN策略时只需调用FortiGate内置的应用特征和业务IP库即可，这两个库的更新比AV/IPS库还频繁，只要设备在服务期内，基本就能高枕无忧了。对IT人员来说，这无疑能极大地提升幸福感

Fortinet的SaaS分流功能之前做过详细评测，本文不再做延展解读。如欲了解，敬请查阅《海外SaaS加速指南》。

要实现海外SaaS访问的全网动态选路和案例中客户需要通过专线跑互联网流量的需求，设备侧需要进行大量复杂配置，这不是任何产品方案都能支持的，尤其是某些数通厂商的SD-WAN方案，选型时建议重点考察。别问我是怎么知道的。

这个Demo还解决了一个很关键的问题，就是远程接入时SaaS分流的难题。

FortiGate本身内置了SSL VPN接入能力，FortiClient客户端又支持包括Windows、MacOS、iOS、Android在内的几乎所有主流平台，这个功能又无需付费购买额外的License，这些都非常好。但其定位毕竟不是专用VPN网关，所以在功能上比较寻常。

不过在去年底，我注意到专门用来管理FortiClient的FortiClient EMS平台有了巨大的功能升级，支持将应用和主流SaaS的特征直接推到FortiClient，实现了终端侧的流量调度。这在两个场景中会有巨大价值，其中之一就是解决了案例中为实现SaaS访问加速而不得不把所有流量都送进隧道的问题。

虽然这不在一开始的SD-Branch测试计划里，我还是决定要试一试，因为现在有这种需求的企业实在太多了。还是北京AWS上面，直接又部署了一台FortiClient EMS，用策略将Microsoft 365、salesforce和ZOOM的特征和内网IP段一起推到FortiClient，再通过SSL VPN连接到云网后，三个海外SaaS的访问品质问题就解决了。不过可能是OS权限的限制，我发现目前MacOS版本还没有支持这个功能，苹果用户可能需要再等待一段时间了。

就这样，在这个Demo里，至少案例企业目前所面临的四个痛点被证明是可以解决的。在远程接入体验后，该企业的IT人员除了惊讶于Fortinet产品方案的效果，还提出一个很经典的问题：他们现在正在用着FortiGate防火墙，他也知道Fortinet是做网络安全的一线厂商，什么时候组网方案比网络厂商还完善了?

我觉得这恰恰说明了三个关键点。首先是之前就反复提得到过的，做为驾驭企业云网的关键能力，SD-WAN要求产品方案对业务要更敏感，安全厂商对此显然更擅长。其次，网络与安全融合的趋势是不可阻挡的，这对传统网络厂商也许需要一些时间，但对安全厂商来说，都是十几年前搞NGFW时就已经着手在解决的问题。第三点，企业云网和SD-Branch是未来方向，所有厂商都不可能忽视，尤其是那些不用只为眼前发愁的大厂，必然要提前做好充足的准备。

坦率的讲，Fortinet这套方案也不是尽善尽美，至少我感觉在管理运维方面还有相当大的提升空间。之所以我愿意用它来做改造，迭代速度快是很重要的一个因素。举个例子，你现在用着的FortiGate和两年前、两年后的FortiGate都不是一个东西——与时俱进的需求，也许很快就出现在新版本中;你用着不爽的槽点，可能很快会被改善。用互联网产品的开发套路做设备，网络和安全领域都算上，也没几个这样的厂商了。

最后也给对SD-Branch方案感兴趣的朋友提个醒，虽然它比起传统组网方案已经有着长足进步，但归根结底还是为了云网结构而生的。换句话说，想拥有这个时代IT基础架构最好的体验，企业云网和SD-Branch缺一不可。

如果你觉得通篇太抽象，体会不到SD-Branch在当今时代的价值(或者必要性)，那上周我的一次亲身经历也许更容易说明问题。

车有点小毛病，跑去4S店修车。到现场看到维修区停满了车，很多人堵在门口吵吵，一问才知道是断网了，没法维修。车主们想不明白啊，为什么断网连车都修不了呢?这两件事有毛关系啊?

赶紧找了个销售问问情况，他给我看了下工作群里的情况，恩，看起来访客网、办公网、生产网全挂了，难怪店里乱糟糟的，骂街声、投诉声此起彼伏。电信升级，非常套路化的解释。有专线和宽带一块升级的么?这个网格的装维不想混了?反正我是不信的。

等了个把钟头网还没恢复，晚上还有事，就打算先撤了。销售说您来前台给您在登记一下，出门就不用交停车费了。结果到前台才想起来没有互联网，也就没法在第三方业务平台申领停车券，结果出门还得自己花5块钱。就因为不想在路上堵着，这次去了个比较远的4S店，来回60多公里路程，最后什么都没办成，体验极差。电费、停车费什么的都不重要，就是浪费一下午的时间太让人心疼了。

我觉得以后我不会再去这个4S店了。

回家路上我就在想，这一下午的经历简直完美验证了本文案例企业在门店场景的所有需求，不光几张网全断、业务全断，连第三方平台的数据对接问题都暴露出来了。如果这个店用了SD-Branch方案，我想至少不应该断得这么彻底，IT也不会这么久做不出响应。

最关键的，业务不会停，至少不应该全停，害的客户口吐芬芳，员工无事可做，都得干等着。

当然还有一种可能性是接入线路不够多，SD-WAN也无能为力。这个时候就看出4G/5G的价值了——有4G/5G，就算专线和DIA全挂了，至少生产网还能保一下，对吧?