NFV如何驱动服务保障的创新

几个主要的通信服务提供商（CSP）正在朝着支持网络功能虚拟化（NFV）架构发展，这有助于降低成本并为他们的用户提供灵活、按需的服务，包括所谓“anything-as-a-service”。但NFV正在面临一系列服务保证相关的问题，这些问题亟待解决。

NFV支持的环境正在改变我们对网络管理应用程序的思考方式，“解决一切”的专有大型解决方案的时代一去不复返了。在不断变化的环境中，我们可以看到运营商正在部署不同的松耦合混合软件组件：一些是内部开发的，一些是商业化的，一些是开源的。最关键的是，他们都需要能够通过业界定义的开放API进行通信并实时交换信息，以更灵活的方式支持网络管理和服务保证功能。

这促使运营支持系统（OSS）/业务支持系统（BSS）行业的创新者对传统的方式进行反思，并提出一套全新的工具和方法来解决新的服务保障的挑战。例如，一些传统的故障管理用例包括通过高级报警过滤、二级报警抑制和根本原因分析来减少平均修复时间（MTTR）并提高网络操作中心（NOC）效率。

很多传统方法都能解决这个问题，如专家系统（expert-system）、规则驱动的原因分析（RCA）甚至是更高级的基于拓扑的方法，在NFV的环境中都不能完全解决这个问题。专家系统（expert-system）不能通过基于规则的引擎准确地预测和防止网络行为并在遇到问题时报警。基于拓扑的方式也具备有限性和不可靠的后果，因为启用NFV的网络将具备高度的动态性。同样需要注意的是，应用于故障管理的分析，要提供高水平的分析结果，仅仅是简单地指向可能存在的原因是不够的，甚至可能会造成无法估量的损失。由于NOC在保持网络正常运行方面的关键和实时性，最好是采用手动分析故障原因，而不是试图解决由RCA引擎提供的错误故障原因。但显然，这也不是企业所需的。为了实现NFV真正的优势，我们在朝着更大的自动化方向发展，在可靠性方面的要求将会提升。

可以肯定的是，所有这些挑战都需要新的方法。投资于当今混合NFV环境进行优化的新一代分析功能，将有助于CSP更好的实现其NFV的价值。这种进步的一个例子是利用自然语言处理算法来消除报警数据中的数据标准化和clean-up的需求，并且使用机器学习技术来支持RCA，而不再需要利用网络拓扑等方式来增加报警数据信息等。因为数据通常很不容易获得，使之成为成功分析的障碍。我们近期在这个领域颇有进展，通过使用报警历史数据，我们能够更准确地确定报警的根本原因，然后将这些结果实时反馈到故障管理系统，以更快、更准确地解决网络故障。

另一个独特的需求是管理和确认混合“pre-NFV”和NFV环境中物理和逻辑组件的性能，将网络向软件定义网络（SDN）和网络功能虚拟化（NFV）的迁移是渐进性的，并且需要时间来实现，很多网络组件不会发生改变。很有可能这种混合网络将会成为未来几年的标准，运营商需要更多的临时补丁来管理并确保其underlay网络组件（物理、虚拟、抽象）的性能。因此，服务保证解决方案需要能够跨域网络感知，结合传统的数据模型如TM Forum的共享信息/数据模型（SID），以实现端到端服务性能视图如OASIS的云应用程序拓扑和编排规范（TOSCA）。

以上只是新技术的转变如何推动当今服务保障解决方案创新的一些实际案例，目的是为网络管理和运营方面提供更好地支持，并顺利地向NFVi过渡。我们看到很多行业的领导者将之视为优先实现的工作，并利用它重新思考其OSS环境，但也有一些运营商比较谨慎，因为他们的OSS环境非常复杂。随着运营商对其服务保障策略的重新评估，无论他们采用何种方式，无论他们部署本地系统、开源解决方案还是商业化的产品，他们应该关注三个关键的业务点：自动化、分析和API。如果没有这三者，基本上不可能监视和确保当今的混合网络的性能。