（CWW）近期，日本电信运营商KDDI和加拿大电信运营商Rogers相继出现断网事件，网络中断时间长，波及面积大，影响范围广，引起了全球电信行业的普遍关注。通常而言，运营商对于电信网络质量有着较高要求，不会轻易出现故障问题。那么，向来以质量可靠著称的电信网络为何出现重大质量事故？电信级的高可靠网络服务在网络IT化、云化的时代如何继续保持？

断网事故接连发生

加拿大三大电信运营商之一的Rogers近期出现大规模断网事故，该公司遍布加拿大全境的无线网络用户、有线电视用户和互联网用户都受到影响，与此相关联的公共服务公司也因为网络故障而不得不停止服务，缺少通信和网络的社会毫无征兆地进入了“停摆”状态。根据互联网检测公司NetBlocks在推特上发布的信息，该故障影响了加拿大近1/4可监测到的连接。

(资料图片)

与此相类似，日本电信运营商KDDI在7月初也出现了通信中断故障。该故障影响了约1/3的日本人口，且持续时间很长，时隔86小时网络才全面恢复。信息社会对网络和通信的依赖放大了故障的影响，不要说电子商务、移动支付、电子门票、电子政务、远程办公、在线教育、视频直播等应用，就连抢险救灾、医疗救助、气候预警等紧急需求，也都被迫进入非正常的状态。

加拿大创新、科技及工业部长François-Philippe Champagne对Rogers断网事故发表评述：“这一不可接受的局面说明了，为什么质量、选择多样性和可靠性在电信网络中如此关键。”

在随后的一份声明中，Rogers的CEO Tony Staffieri将可能导致断网的原因范围缩小到了核心网络的维护升级，以及由此所导致的路由器工作异常。他还提出将更为深入地定位问题的根源，并通过增加冗余的方式避免故障的重复出现。Tony Staffieri说道：“我们将采取所有必要的举措，持续加大网络投资，以强化系统、增加网络健壮性，并加强相关的网络测试。”

从这段简短的表述中，我们可以解读出一些重要信息：第一，该网络中断不是因为遭受外部攻击所致，而是因为内部升级引起的，换句话说，这是一个“主动”变化所引起的；第二，通过冗余方式能够避免故障的重现，说明网络中某些关键部分存在单点故障的风险；第三，“加强测试”，可能意味着在“主动”变化后缺乏相关的测试，没有及时发现问题或是为变化的回退留出余地；第四，“持续加大网络投资”，可能意味着当前对网络可靠性/健壮性的投入不足。

电信网络IT化的必然挑战

在服务中断的时候，网络服务的可靠性以及出现故障后的及时恢复、自愈、防灾备份等问题，充分凸显出来——尤其在电信系统IT化、云化的过程中，这些问题需要得到特别的关注。传统电信网络的设计思路与IT网络是不相同的。电信级服务对可靠性和容灾有着严苛的要求，这就需要电信网络从各个层面提供可靠性和容灾保护，包括服务器设备、网卡设备、交换机设备、交换机链路、网关设备，至少要提供“1+1”的冗余。除此之外，还要提供高效的备份恢复能力、异地容灾能力。

在虚拟层面，配置虚机的重生和自愈等要提供自动化的网络调整能力。IT化、云化的进程与这样的理念有可能有个磨合的过程。因为从IT化的机制角度看，原先网络资源是稀缺的，很多服务质量方面的工作可以交给端侧来解决，“尽力服务(Best-Effort)”是网络设计的出发点。互联网遵循“边缘”设计原则，其特征是网络传输采用无连接分组交换，高层功能放置在网络边缘，按“尽力服务”原则向用户提供服务。这种设计方式能够让服务的承载呈现出分布式特点，尽管在服务资源不足的情况下，可能会因为服务请求的丢弃导致服务等级的下降，然而这样的“去中心化”在一定程度上分散了大规模阻断的风险。在电信网络IT化和互联网化的趋势下，如何做好网络架构的合理规划、平衡好投入与可靠性是需要面对的挑战。

海因里希法则适用于此

当谈及网络服务中断时，我们需要关注海因里希法则。海因里希法则是指，当一个企业有300起隐患或违章，还有很大可能要发生29起轻伤或故障，另外再有一起重伤、死亡事故。对于企业的安全管理或者服务安全管理而言，这一法则是道理相通的，即在一起重大事故的背后必有29起轻度事故，还有300个潜在的隐患。

实际上，在快速发展的网络经济中，运营商的业务发展和网络运维也面临着快速迭代的问题，这些变化过程中的隐患常会被发展的压力所掩盖。海因里希法则指出，在所有发生的事故中，“未遂事故”虽然没有造成巨大损失，但其发生的原因和发展的过程与重大事故是一致的。而如果没有意外事件中断“未遂事故”的发展，那么极有可能出现重大事故。因此必须对“未遂事故”进行深入研究，探讨其发生的原因和发展的规律，进而采取相应措施，消除事故原因或中断事故发展进程，达到控制和预防事故的目的。

根据海因里希法则，在同类事故中，“未遂事故”和轻伤事故发生的可能性要比严重伤害事故大得多，对“未遂事故”的关注和研究是控制严重事故发生的重要手段，必需要找好快速迭代与对“未遂事故”进行透彻分析之间的平衡点。

诸多潜在问题值得重视

从需求的角度，我们必须了解运营商所面临的境地：网络故障是不可避免的。这其中最重要的原因在于业务的变化和发展导致了频繁的网络调整，组网需求在这样的环境下快速变化。与此同时，云化和虚拟化给网络带来了更多的复杂性，伴随着NFV、切片和微服务等技术的引入，网络的管理愈加复杂,管理对象增多使得变更操作愈加频繁。运营商在如此复杂的环境中进行大量变更操作，很难做到在制定方案时遍历所有的业务和服务场景，更难对功能性或非功能性要求进行精准测算。

这样的复杂度给实施变化的人带来了更多发生过失的可能，很大比例的网络事故都是在变更过程中人为操作失误引起的。而所谓专家，或者有经验的网络人员，也都是在处理这些故障和事故中不断成长起来的。电信网络运行涉及的环节和设备较多，具有很高的复杂性。一旦在运行中某一环节或者设备出现问题，就会对整个通信网络系统造成严重影响，导致出现通信网络节点失衡的情况。因此在电信网络的运维中，全程全网的概念很重要。

大部分情况下，由于服务和业务的高可用设计，对于进行网络调整时出现的故障，用户不见得有直观感受。例如服务器出现问题，集群内其他服务器就会接管业务；传输出现中断，业务承载就能够智能地调度到备用传输系统上；甚至业务平台出现问题，也能够通过调度将业务承载到灾备环境上。更何况，运营商还有完善的服务热线等沟通手段，在用户服务质量下降或短时间服务中断的情况下，也能通过有效沟通的方式舒缓用户的焦虑和不满。

比较可怕的是故障出现在网络核心位置时，运营商无法像处理边缘故障那样解开耦合；或者业务的接管机制出现问题时，业务的处理无法切换到正常网元上；甚至出现类似加拿大的案例，业务中断后形成“业务风暴”——运营商的“规模”会给这些场景下的故障恢复提出更多挑战。

值得重视的是，“可用性悖论”也需要考虑。随着网络管理的智慧化发展，其更多地通过专业的系统开展，网元的底层操作会被封装。在网络状态良好时，网络管理系统可用可看；当网络发生故障时，网络管理系统可能因为网络阻断或者网元不可及等原因，不能继续有效发挥作用，进而无法对网络进行必要的配置以使其恢复正常。这时可能需要运维人员绕开网络管理系统进行相对底层的故障排除操作。这对操作复杂度、操作效率、操作人员的经验等又提出了新的挑战。

此外，新的安全隐患问题（IT化带来的网络安全问题、各类网络攻击等）也是运营商在IT化和互联网化过程中需要面对的新课题——而这又是不确定性非常强的领域，运营商之前的积累比较薄弱。

边缘计算的用武之地

尽管云化对于追求更为合理架构的运营商而言成为趋势，然而在数据可靠性层面，云架构同样存在需要解决的问题。尤其是在那些数据量大、数据敏感度高、数据安全性要求高的场景，云架构的实现方式需要把可靠性作为非常重要的因素，毕竟“云端”的故障有可能给用户业务带来很大的威胁。

2018年6月，阿里云曾出现技术故障，而阿里云最终将其定义为S1级别事故——核心业务重要功能不可用，影响了部分用户，造成了一定损失。2019年3月3日，阿里云发布公告，称华北2地域可用区C部分的ECS服务器（云服务器）等实例出现IO HANG（IO不响应）。在云计算服务市场，无论是AWS、GoogleCloud还是Azure的服务，都曾经因为数据中心硬件问题、硬盘故障或是自动化失效等问题而受到影响。因此，在云服务架构下，即便故障率在服务提供商所承诺的0.01%以下，即便云服务商在故障出现时也都有相应的容灾方案，在不少应用场景下业务的中断还是会给用户带来巨大损失。因此，业务架构在集中化的同时也需要着重考虑业务风险分担的问题。

在此情况下，边缘计算（MEC）将有一定的用武之地。边缘计算改变了只有云端作为“大脑”、“管道”和“端系统”智能程度不足的状况，使“端”变成了辅助“大脑”工作的“智能神经网络”。这样一来，边缘服务在终端设备上运行，反馈更迅速，解决了时延问题，使得一些工业应用场景成为可能。另一方面，边缘计算将内容与计算能力下沉，提供智能化的流量调度，业务实现了本地化，内容实现了本地缓存，解决方案的效率得到了显著提升。此外，边缘计算还有着丰富的应用场景设计。边缘计算作为一种开放的IT体系架构，能够向第三方提供开放接口，引入外部专业力量开发功能和服务。这种模式有可能引发商业模式变革，刺激并促进产业发展。

总结

网络服务中断可以从各种角度进行反思，有几点值得关注。

第一，“连接”在信息通信产业价值链上仍然具有举足轻重的地位，值得运营商高度关注。尽管在一段时间内业务的拓展似乎成为运营商摆脱“管道宿命”的重心，然而一旦“连接”出现问题，运营商就会丧失安身立命之本。因此，时时用海因里希法则来审视自己存在的问题非常必要。

第二，运营商在业务及网络架构演进的过程中，要充分理解海因里希法则，在投入资源、采取快速迭代方法对“未遂事故”进行彻底分析后，找到合理的方式；同时充分评估服务质量下降与服务中断带来的损失，在演进过程中寻求可靠且经济的路径。

第三，用系统性、长期演进的眼光来观察运营商IT化进程，充分关注云架构与边缘计算带来的机会。