终于不再苦逼割接了，要灰度升级！

老司机提醒您：指令千万条，安全第一条，割接不规范，悔出两行泪!

迎着晚霞，送走日出，别人在酣睡，我们却要精神百倍，深夜割接，几乎是每个通信人都经历过的痛。搞核心网的人，体验尤其深：信令，路由，各种东西一点都不能错，一错影响一大片，计费，通话，数据…转眼脑袋就要掉的节奏啊!

割接，割接，就是先割后接, 把旧的设备割掉，再把新的接上去。

割接是对正运行的网络进行改造、升级、迁移等变更，会造成业务中断，稍有疏忽，就可能影响业务，甚至会酿成通信事故。

割接前要进行反复论证、周密测试、数据备份、失败紧急回退演练等，以规避割接风险。

割接时，通常选择在晚上零点之后进行，以减少对用户的影响，并要求每一个割接人员、每一个时间点、每一个步骤都必须精准、清晰落实，以保证次日凌晨前完成割接。

割接后，还要完成业务验证，不影响第二天的业务运营，才算割接完毕，如释重负!

一旦割接失败，最崩溃的是回退，比回退更崩溃的是回退失败，而比回退失败更更崩溃的是业务影响面积太大!

从固网到移动，从1G到4G，电信业经历了无数次新功能割接上线，而每一次操作对于通信工程师就像是上战场，对技术、体力、脑力、经验等是一次严峻的综合考验，不累趴下是不可能的。

不想再苦逼割接了

要灰度升级

电信业务升级割接这么苦逼，可微信、QQ经历了N个版本，为啥腾讯从不像运营商那样发一个割接公告，停了业务半夜做升级?

亚马逊每秒钟都在部署新软件，这些互联网巨头的新功能升级为啥如此轻松?

他们的秘密就是----灰度升级。

灰度升级(又称灰度发布、灰度更新)指在黑与白之间，能够平滑过渡的一种发布方式。灰度发布不必一次性中断业务，它可在不影响已上线业务的前提下，在初始灰度的时候及时发现、调整问题，以保证平稳升级。

金丝雀发布和A/B测试都属于灰度发布方式。

由于金丝雀对空气中的甲烷和一氧化碳浓度十分敏感，约在18世纪时，人类已经知道用金丝雀来侦测危险气体了，矿工们将金丝雀带入矿井，如果金丝雀停止唱歌，就知道必须赶快撤离。

矿井里的金丝雀

这就是金丝雀发布的由来，即先部署少量的新版本服务作为“金丝雀”来测试验证，确认整体稳定无异常后再全面部署。

A/B测试(A/B testing)就是让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

Google是A/B测试的先驱，早在2000年，Google工程师们首次将A / B测试应用于搜索引擎，以确定搜索页面上显示最佳结果数量。仅在2011年，Google就进行了7000次A / B测试。如今A/B测试已是互联网巨头们的家常便饭了。

灰度升级可以应用于电信领域的割接升级吗?

没有问题，云原生来拯救

在IT领域，早就经历了从虚拟化到云原生(Cloud Native)的演进历程。

IT领域的云原生演进

在电信领域，自2012年由AT&T、英国电信、中国移动、德国电信等12家运营商联合发布NFV白皮书后，5年后23家运营商再次联合发布新版NFV 5G白皮书。与2012版的白皮书不同，这份NFV 5G白皮书除了关注网络虚拟化本身，更关注5G应用，并提出了云原生概念。

2017年，3GPP确认5G核心网基于云原生构架设计，采用以微服务为中心的软件架构。

从IT到CT，为什么都要从NFV演进到云原生?

因为早期的NFV，从传统专用设备中解耦出的网络功能软件(VNF)是“大块头”的单体式应用程序，无法充分利用云环境的灵活性。

为此，业界提出了基于云原生的设计原则，将VNF进一步分解和细粒度化，通过软件模块化、轻量化的方式来提升应用开发的整体敏捷性和弹性，并通过开放API接口和开源来简化集成过程，从而加速创新和新业务上线，适应瞬息万变的市场环境。

正是基于云原生架构设计，5G核心网实现了“化整为零、由硬变软”的空前变革，以灵活、敏捷应对5G多样化业务时代。

云原生是一套充分利用云环境优势来构建、测试、部署和运行软件的办法，其主要由微服务架构、DevOps、容器、动态编排等组成，

微服务架构将传统单体式应用程序分解为无状态(Stateless)、松散耦合、粒度更小的“微”服务，以提升应用部署的弹性。

DevOps让运维和开发人员共同协作发布服务(包括微服务)，它创造了一种文化和环境，以快速、频繁且更可靠地构建、测试和发布服务，提高运作效率。

同时出镜的还有灰度升级。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!