終于不再苦逼割接了，要灰度升級！
老司機提醒您：指令千萬條，安全***條，割接不規范，悔出兩行淚!
迎著晚霞，送走日出，別人在酣睡，我們卻要精神百倍，深夜割接，幾乎是每個通信人都經歷過的痛。搞核心網的人，體驗尤其深：信令，路由，各種東西一點都不能錯，一錯影響一大片，計費，通話，數據…轉眼腦袋就要掉的節奏啊!
割接，割接，就是先割后接, 把舊的設備割掉，再把新的接上去。
割接是對正運行的網絡進行改造、升級、遷移等變更，會造成業務中斷，稍有疏忽，就可能影響業務，甚至會釀成通信事故。
割接前要進行反復論證、周密測試、數據備份、失敗緊急回退演練等，以規避割接風險。
割接時，通常選擇在晚上零點之后進行，以減少對用戶的影響，并要求每一個割接人員、每一個時間點、每一個步驟都必須精準、清晰落實，以保證次日凌晨前完成割接。
割接后，還要完成業務驗證，不影響第二天的業務運營，才算割接完畢，如釋重負!
一旦割接失敗，最崩潰的是回退，比回退更崩潰的是回退失敗，而比回退失敗更更崩潰的是業務影響面積太大!
從固網到移動，從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讓運維和開發人員共同協作發布服務(包括微服務)，它創造了一種文化和環境，以快速、頻繁且更可靠地構建、測試和發布服務，提高運作效率。
同時出鏡的還有灰度升級。
傳統電信在升級割接時，新版本替換舊版本，都是通過批量操作，一次性的、100%的從舊版本“割接”到新版本。這種操作方式必須中斷業務，一旦操作失敗再回退到老系統時極易出錯，存在很大的風險。
割接 vs 灰度升級
而基于云原生的灰度升級意味著我們不必“一次性割接”，DevOps支持循序漸進的引入新版本的VNF(虛擬化網絡功能)組件，先挑選少量測試用戶操作試點，將少量的流量切換到新版本上，并在這個過程中持續監控性能，確保穩定之后，再進一步將其他用戶切換到新版本上。如果一旦發現少量測試用戶的性能異常，也可快速回退到舊版本上，可大幅降低割接風險。
終于核心網不用再熬夜苦逼升級割接了，采用灰度升級，大白天妥妥的就把事干了。
值得一提的是，灰度升級不再是概念，已落地現實，據悉，去年年中，華為已為拉美某大型運營商在大白天完成了灰度升級，***升級三波完成，2.3萬用戶平穩上線，妥妥的告別暗夜割接!
