NFV上半场一路坎坷，走得不容易;笔者通过这几年在NFV底层摸石头过河的点点滴滴经验积累，思索和分析了下半场中决定电信云能否稳步爬升和真正落地开花的关键点，与大家一起探讨。文章结构分为以下几点：
- 曾经的承诺，现在还好吗?
- 困难凸显，蹒跚前行
- 下半场的命门
- 已经在路上
一、曾经的承诺，现在还好吗?
NFV，即网络功能虚拟化，Network Function Virtualization。通过使用x86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理，从而降低网络昂贵的设备成本。可以通过软硬件解耦及功能抽象，使网络设备功能不再依赖于专用硬件，资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。
概念是诱人的，但那些曾经许下的美好诺言，时过境迁，现在还好吗?让我们来一一看看。
1. NFV的引入可以降低CAPEX和OPEX
当前运营商的试验试点验证了整体方案的可行性，以及系统中单组件的特性满足需求，但一个现实情况是，各厂商实现的水平还层次不齐，如果到了现网系统的复杂环境下，是否能真正做到敏捷和灵活，还有待实践检验。
2. NFVI平台灵活扩展，VNF服务快速上线、弹性扩缩容
当前试验试点验证了整体方案的可行性，以及系统中单组件的特性，但各厂商实现的水平还层次不齐，如果到了现网系统复杂的环境下，是否能真正做到这种敏捷和灵活，还有待实践检验。
3. 云平台可以灵活地调度和统筹资源，为上层业务提供更好地资源服务
当前的NFV，实际上刚刚度过软硬解耦阶段，云资源池还处于满足上层业务部署需求的阶段，还没有像公有云一样，进入到与业务深度结合，提供更好的资源服务，对整体云平台进行高效的资源管理的阶段。
4. 防止厂商锁定(vendor lock-in)
通过云计算的技术手段，将多厂商的产品以软件化的形式运行在统一的平台，随时可以替换，打破单一供应商的锁定，这是我们美好的愿景，但厂商出于各种目的会尽量避免自家的VNF与第三方VNF集成的方案出现。厂商可能会说，兼容性不好，集成起来非常麻烦，甚至说与第三方的连接性能不如全采用自己一家。正因为此，这些年运营商花费大量时间和精力，反复进行异厂商对接测试，成熟完善企业接口规范，但即使如此，我们依然无法避免后期的集成绑定，当集成商以交钥匙的方式把系统交给我们的时候，一种集成的绑定已经悄然形成。
曾经的海市蜃楼逐渐淡去，骨感的现实袭来，难怪圈内发出了NFV倒地的担忧，这并非杞人忧天，以上的事实是残酷的。但任何技术都有它的成熟曲线，笔者在NFV底层跌跌撞撞摸爬滚打三年多，历经概念兴起后的产业界追捧，然后是雷声大雨点小，彼此观望，然后是实际落地实践中磕磕绊绊的前行，直至不久前的温吞和低迷，但是从新技术成熟度曲线来看，这恰恰是后期稳步爬升的积累。
当然这个成熟度曲线只是规律上的分析，具体到NFV的技术发展路线，还是需要从这两年NFV步履维艰的前行中去思索和分析，才能找到后续能稳步爬升的关键点所在。
二、困难凸显，蹒跚前行
这两三年运营商推进NFV真心不容易，围墙之外的看客老是抱怨NFV推进太慢，要错过发展窗口期了，说真心话，通信网络服务等级高，是事关国计民生的生产系统，岂敢儿戏，所以运营商反复验证方案，去催化产业的成熟。然而即使我们如此努力，依然凸显出如下困难。
1. 通过规范标准来约束的厂商的互操作性，推进比较缓慢
(1)NFV系统复杂，行业标准化推进缓慢
事实上从发展之初，标准化一直在积极推进， 国际上已有多个有影响力的标准组织成立了专门的工作组来开展NFV的相关研究，比如ETSI、IETF、3GPP SAS、ITU-T SG13、CCSA等;另外，在上述的标准基础上，也引入了一批NFV相关开源组织，如OPNFV、OpenStack、KVM、Open vSwitch、ONOS、OpenDaylight等，为NFV的开源实现技术提供了参考。
然而NFV系统太复杂了，组件众多，不同参与方利益出发点存异，导致标准化的推进缓慢。
(2)大企业以企业标准来要求厂商，规范NFV系统，但各厂商对规范的理解有偏差，实现能力和出发点也各不相同，只能通过试验试点去打磨成熟，但这需要大量的时间和人力。
(3)需求发展变化太快，这些标准和要求都需要不断演进和成熟，于是出现了运营商疲于去制定和修正，厂商疲于去适配。
2. 希望充分发挥云的优势，使得云平台的能力服务化，资源灵活调度分配，整体提升资源效率，但是当前产业依然是软硬解耦的初级阶段徘徊
(1)多数网元的设计还处于将传统电信设备上的软件直接移植到虚拟机镜像的阶段，并没有按照云化的方式设计和使用云平台。
(2)云平台也没有充分结合业务需求，提供丰富的云服务，进行资源灵活调度管理，也不能通过有效的手段，基于运行的业务情况，优化和提升整体的资源使用效率。
3. 运维模式转变，运维难度增加，不知该如何应对
相比较传统的以设备运维为主的模式，电信云是一个平台级的系统，涉及的组件众多，如何有效进行运维分工，如何进行有效地监控，如何通过协作，进行运维问题分析定位，甚至如何进行问题预测，都是不小的挑战，在这些方便，当前还尚未形成明确的解决方案和定义。
所有的这一切都使得NFV迟迟不能大规模上线，使得业界对NFV的成熟度一直存疑，于是有了NFV倒地出局的悲观论调。那问题到底出在哪里了?
- 是运营商不需要一张灵活的网络吗?不是
- 是技术上有难以克服的瓶颈吗?不是
- 是产业界生态不支持吗?不是
既然有运营商需求，有技术方案，有产业生态，那到底是什么原因导致这些困难的?
答案是NFV的落地模式，解决NFV建设使用***一公里的问题，千万不要小看这***一公里，多少好的概念因为没有解决好***一公里，长期处于雷声大雨点小的窘境，迟迟不能推进，甚至错过风口被淘汰。
那电信云的落地模式是什么，如何解决以上问题呢?笔者个人认为这正是NFV决胜下半场的关键，决定了电信云能否稳步爬升和真正落地开花。
三、下半场的命门
NFV使得通信网络由横向的设备连接，转变为纵向的分层系统构建，传统针对CT设备的建设使用模式要转变为针对IT云系统的建设使用模式，在这种转变中，如果还是以纯粹依赖厂商提供产品和服务的传统模式进行落地建设，就必然会出现以上的问题，从而使得NFV的建设步履维艰、NFV的优势也最终会大打折扣。
那么NFV的落地模式到底什么，也就是如何找到行之有效的方法保证NFV的快速落地，并发挥出云计算的优势，这还得从前文提到的困难点来一一探讨。
1. NFV系统组件复杂，所以在初期要加强对接适配工作，不能完全依赖规范和标准解决。而是将集成标准化，透明化，提升集成问题解决效率，加速落地建设
传统的模式，以case by case的项目建设出发，厂商产品通过标准、规范和技术要求保证其集成对接，集成商以交钥匙的方式提供集成服务，但是对于复杂系统，很多在集成中或者后期使用中出现的适配、调优等系统性问题，都是前期技术要求不容易覆盖全的。一种考虑就是打开集成工作的黑盒，标准化集成的流程，标准化集成设计，标准化集成对接等，将其中一些关键的系统设计、对接验证或者系统验证的工作提取出来，提前在一个集中平台上进行处理，并且在NFV系统集成中实施和后期使用中，也能够持续保障，这就保证了系统集成建设效率。另外，标准化后，自然地演进到自动化，帮助我们高效地发现那些规范标准所触摸不到的问题，快速地迭代规范和标准要求，加速新业务和新技术的引入。总之，这样就实现了集成过程的透明和高效，而不是低效得去对系统做黑盒的验证，缓步推进规范和标准的完善。
2. 构建IT化的集成验证模式，使云计算的优势迅速构建起来，提升NFV系统的落地质量
发挥云计算的优势，本质上来说是推动网元业务的云化设计，并完善云平台的构建和资源使用。云计算的发展历程证明这个过程不是一蹴而就，需要持续的迭代优化，需要将开发/集成/使用有效联动起来，但传统的建设和使用模式其实是产品和服务采购的方式，难以做到这一点，因而应对云模式的时候就显得力不从心了，这也是为什么我们那么辛苦，但结果却不尽如人意。
由于当前NFV组件都是厂商来提供，一种考虑是运营商构建一套和厂商联动的机制，引入 IT领域的DEVOP的模式，联合合作伙伴，把厂商的产品开发演进和运营商的集成验证结合成一个体系。推进NFV组件的快速迭代演进，以下是这***程的初步构想。
立足NFV整体的集成过程，将NFV软件组件开发/集成/验证相结合，形成一个闭环过程，篇幅所限，这里不再展开技术细节。
有了这样的平台，就可以和厂商一起迅速集成验证，生产中有了任何问题，迅速展开回归验证，这样各种网元的适配问题、云化改进、以及云平台的各种技术演进都能进行充分验证和迭代。
3. 对于复杂系统，运维问题的有效解决，需要构建建设/运营运维一体化，保障落地使用
构建建设、运营、运维一体化的新型集成，将承担落地建设的角色和技术研究验证的角色密切结合。一种运维模式的考虑是，构建集成验证中心，将属地建设和集成验证中心进行联动，帮助快速分析定位，加速运维问题的技术验证，并且沉淀下来，形成运维知识库和能力的积累，篇幅所限，这里不再详述。
在以上的这些工作中，我们看到运营商已经不能再像买产品和服务一样置身事外，而是要深度地走进自己的系统，把控自己的系统，取代客户与供应商的老式交易，形成合作共赢的伙伴式关系。具体操作上，主要是提升NFV落地中的可控性，利用厂商提供给我们的产品和服务，在技术上主导平台的设计、建设、运营运维和演进，也就是形成一种新型的落地模式。
4. 纵观国际上的实践，大家在落地模式上也在朝着这两个方向推进，强调对系统的把控，也强调产业合作
(1) AT&T的历程
在AT&T Vision 2020转型计划中，AT&T董事长兼***执行官兰德尔•斯蒂芬森说：”到2020年，我希望AT&T成为一家科技公司，我们将通过云计算来管理所有的数字业务，包括手机、有线、卫星电视和海量数据等，就像谷歌和亚马逊那样“，其实就明确了其IT化转型和自主转型的思路，而从这些年向外部释放的种种信号来看，也确实在朝这个方向迈进。
Domain2.0的云战略提出之初，ATT和IBM展开云计算和大数据的合作;2015年AIC云架构形成，构建基于openstack开源云架构，和当时的IT集成商Mirantis深度合作，历经AIC1.O/ACI2.O/AIC3.O，2018年演进到NC云架构，依靠自身的力量构建了基于容器的云平台持续集成开发体系(DEVOPS)，并且将该架构开源成AIRSHIP项目。 从工作流角度看，AIRSHIP包含了基于容器的云平台持续集成开发，同时也包含了集成部署和系统测试。
坦白的说，AT&T的实践，虽然目前成败未卜，但确实有几百人的技术团队，对整个NFV系统有很强的把控力。
(2) 瑞士电信的实践
看完了大厂，再来看看瑞士电信，他们建设NFV并不是对通信网络整体的改造，而是从TV业务出发，构建Media Cloud，承载当前和未来与娱乐相关的网络服务，一方面，他们选择了惠普作为合作伙伴，提供云平台和集成解决方案，负责生产环境的系统集成;另一方面构建了自己的实验室，开展平台以及业务的兼容性和性能、可靠性等测试。并且联合合作伙伴，就平台的容器化演进、构建基于公有云和电信云的混合云，开展技术演进的实践验证。
四、已经在路上
用NFV去重构传统CT架构。这意味着CT要接受IT的技术，接受IT的思维，于是我们看到X86通用服务器、OpenStack云平台、微服务业务设计等一系列IT的技术在CT中广泛应用，而伴随NFV步入下半场，快速规模落地，成为关注焦点，这时一个重要的IT建设模式逐步走进我们的视野，那就是快速迭代、快速演进的思维和技术体系，而这一体系的构建基础就是可控的技术能力，以及合作伙伴式的产业生态。
行文至此，已经凌晨2点多了，伏案遐思，回想这些年在NFV一线的摸爬滚打，感慨良多，虽然各种吐槽，虽然也曾经深陷各种技术细节问题，萌生沮丧，但也深深体味着NFV前进路上点点滴滴的进步，可以看到产业界在思想上，从消极抵制过渡到慢慢接受，技术上从完全不能对接到大部分问题已经解决，企业标准接口逐步细化完善，集成内容和集成流程的定义从无到有，集成设计逐步规范化，提升集成效率的自动化探索也如火如荼，虽然和我们理想中高大上的那朵云还有较远的距离，虽然落地起来还磕磕绊绊，但是NFV已然可行，同时运营商在可控模式上也一直在努力，点点滴滴默默积累。
迈进下半场后，我们只要在电信云建设/使用/演进过程中，将把控力和产业合作上结合起来，建立起集成/运营运维一体化的快速迭代模式，就必然能把NFV规模落地构建起来，那时候还会有人讨论NFV的倒地和出局吗?
