Open RAN, 5G i cloud native: jak wygląda nowa architektura sieci komórkowych z perspektywy inżyniera DevOps

Nowa rzeczywistość sieci komórkowych oczami DevOpsa

Typowe pytania i obawy inżyniera DevOps przy wejściu do świata 5G

Różnice między klasyczną infrastrukturą IT a środowiskiem telekom

Osoba, która latami pracowała z klasycznymi aplikacjami webowymi, mikrousługami w chmurze publicznej czy systemami korporacyjnymi, często przeżywa lekki szok przy pierwszym kontakcie z siecią komórkową. Z jednej strony: Kubernetes, CI/CD, monitoring – wszystko wygląda znajomo. Z drugiej: dziwne skróty, protokoły, wymóg ultra-niskich opóźnień i SLA liczone w „dziewiątkach” dostępności. Do tego dochodzi fakt, że awaria nie oznacza „aplikacja się wiesza”, tylko realne przerwy w łączności dla tysięcy osób.

Klasyczna infrastruktura IT zwykle operuje w ramach jednego lub kilku centrów danych, z dość przewidywalnym ruchem i mniejszą presją na skrajne parametry opóźnień. Telekom ma inny profil: dane przepływają w czasie rzeczywistym, ruch bywa bardzo nieregularny (koncert, mecz, awaria sieci innego operatora), a sieć fizycznie rozciąga się na setki, tysiące lokalizacji. Zasady projektowania, które „uchodzą” w świecie enterprise, w telko potrafią po prostu nie zadziałać.

Największa różnica polega na tym, że funkcje sieciowe 4G/5G pracują w ścieżce krytycznej sygnału radiowego i danych. Każdy dodatkowy hop, każdy proxy, zły wybór CNI, zbyt agresywny autoscaling – to ryzyko utraty sesji, zwiększenia opóźnień czy problemów z handoverem między komórkami. To nie jest kolejna aplikacja webowa – to element infrastruktury, który ma reagować w milisekundach na zdarzenia z radia i core.

Strach przed „telco-jargonem” i zamkniętymi, drogimi boxami

Dla wielu DevOpsów „świat telko” kojarzy się z hermetycznym żargonem (eNB, gNB, MME, AMF, S1, N2, X2, NG…), drogimi szafami sprzętowymi i inżynierami, którzy mówią pół zdaniami po angielsku, pół skrótami z 3GPP. To często zniechęca już na starcie: pojawia się przekonanie, że bez dziesiątek dokumentów specyfikacyjnych i lat doświadczenia „w radiu” nie da się tam nic sensownego zrobić.

Open RAN i 5G cloud native znacząco to zmieniają. Owszem, znajomość podstawowej terminologii i topologii sieci jest potrzebna, ale coraz większa część pracy przesuwa się w stronę znanych narzędzi i wzorców: Kubernetes, Helm, GitOps, promQL, grafana, ELK/Opensearch, service mesh, policy-as-code. Mówiąc brutalnie – wielu doświadczonych inżynierów RAN/Core czuje dziś większy lęk przed „DevOps-jargonem” niż DevOps przed słownikem 3GPP.

Najskuteczniejszą strategią wejścia jest opanowanie minimum pojęć i skupienie się na miejscach styku: gdzie kończy się odpowiedzialność zespołu RAN/Core, a zaczyna rola platformy chmurowej i zespołów DevOps/SRE. Świadomy DevOps nie musi znać na pamięć wszystkich interfejsów radiowych, ale musi rozumieć, jak jego decyzje w zakresie infrastruktury wpływają na parametry radiowe, sesje użytkowników i efektywność spektrum.

Obawa przed odpowiedzialnością za „krytyczną infrastrukturę państwową”

Sieć komórkowa 4G/5G jest traktowana jako krytyczna infrastruktura państwowa. To oznacza rygorystyczne wymagania bezpieczeństwa, procesów change management, testów, a także kontakt z regulatorem lub służbami nadzorczymi. Dla DevOpsa przyzwyczajonego do „move fast and break things” to może brzmieć jak koniec zwinności i ciągłego wdrażania.

W praktyce rola DevOpsa w 5G jest bliższa temu, co wiele firm zna jako SRE w dużych chmurach publicznych: zmiany są ciągłe, ale maksymalnie zautomatyzowane, standaryzowane i kontrolowane. Duży nacisk kładzie się na SLO, error budgets, zmianę w małych porcjach i precyzyjne mechanizmy rollbacku. Pojawia się też silna współpraca z zespołami bezpieczeństwa (SecOps), bo każdy błąd konfiguracyjny w infrastrukturze chmurowej może otworzyć furtkę do ataku na sieć komórkową.

Co realnie zmienia Open RAN, 5G i cloud native w pracy DevOpsa

Przesunięcie ciężaru z hardware na software i orkiestrację

Klasyczne sieci komórkowe opierały się na zamkniętych, sprzętowo-programowych „pudłach” od jednego dostawcy. Aktualizacje były rzadkie, integracja ograniczona, a automatyzacja – głównie w rękach vendorów. Open RAN i 5G Core w architekturze cloud native rozbijają ten monolit na szereg funkcji programowych, z których część działa na standardowym sprzęcie x86, często w kontenerach zarządzanych przez Kubernetes.

Dla DevOpsa oznacza to dużo większą odpowiedzialność za „warstwę pod spodem”: od konfiguracji klastra K8s w strefach brzegowych (edge, far edge), przez CNI i storage, po orkiestrację CNF-ów i ich lifecycle. Kluczowe staje się zapewnienie spójnego, powtarzalnego środowiska dla funkcji sieciowych RAN/Core, które mają specyficzne wymagania wydajnościowe i sieciowe. To już nie jest tylko „ktoś inny zarządza siecią, my dostarczamy VM-y” – DevOps przejmuje realny wpływ na stabilność i parametry działania całej sieci komórkowej.

Od pojedynczych wdrożeń do ciągłych zmian w sieci produkcyjnej

Świat telko przyzwyczaił się do dużych, rzadkich migracji i „okien serwisowych”. modele cloud native, Open RAN i modularne 5G Core powodują, że zmiany stają się częstsze, ale drobniejsze. Wchodzą regularne aktualizacje CNF-ów, łatki bezpieczeństwa, poprawki konfiguracyjne, rollouty xApps/rApps w RIC-u, nowe polityki slicingowe, dynamiczne skalowanie funkcji typu UPF czy AMF.

Rola DevOpsa ewoluuje w stronę projektanta i strażnika procesu zmiany: jak zbudować pipeline’y CI/CD dla funkcji sieciowych, które pozwalają szybko wdrażać poprawki i nowe funkcjonalności, nie ryzykując chaosu w sieci produkcyjnej? Jak łączyć testy funkcjonalne z niefunkcjonalnymi (latencje, jitter, packet loss) i jak automatycznie wstrzymywać rollout, gdy SLO zaczynają być naruszane? To już nie jest „po prostu deploy do produkcji”, tylko ciągły balans między innowacją a niezawodnością.

Większa rola automatyzacji, testów niefunkcjonalnych i SLO

Open RAN, 5G Core i cloud native wprowadzają do sieci komórkowych filozofię infrastructure as code, policy as code i observability first. Bez silnej automatyzacji nie da się zarządzić skalą: setki lokalizacji edge, tysiące CNF-ów, różne profile ruchu i wymagania dla poszczególnych network slice’ów.

Wzmacnia się rola testów niefunkcjonalnych: obciążeniowych, wydajnościowych, odpornościowych (chaos engineering), a także testów kompatybilności między funkcjami od różnych vendorów. Dla DevOpsa to szansa, ale i wyzwanie: trzeba umieć zbudować pipeline, który nie tylko sprawdzi, czy CNF się podnosi i przechodzi testy jednostkowe, lecz także czy przy obciążeniu progiem X nie rosną opóźnienia powyżej ustalonego SLO. Pojawiają się SLI typowo telko, jak: czas zestawienia połączenia, odsetek przerwanych sesji, latency między RU a DU/CU, opóźnienia w płaszczyźnie użytkownika.

Gdzie DevOps „wpiąć się” w cykl życia sieci komórkowej

Planowanie, lab, staging, roll-out, eksploatacja, optymalizacja

Cykl życia sieci komórkowej 5G z elementami Open RAN i cloud native można podzielić na kilka etapów, w których obecność DevOpsa jest szczególnie cenna:

• Planowanie – dobór architektury chmury (central, regional, edge, far edge), projektowanie klastrów K8s, wybór CNI, storage, strategii aktualizacji.
• Lab – budowa środowisk testowych odwzorowujących realną topologię, integracja CNF/VNF od różnych dostawców, automatyzacja deployu w laboratorium.
• Staging / pre-produkcja – odwzorowanie produkcji (skala, routing, bezpieczeństwo), testy niefunkcjonalne, testy przeciążeniowe, scenariusze awarii.
• Roll-out – stopniowe wdrażanie do produkcji, canary deployment, kontrolowany rollout po regionach / site’ach, plany rollbacku.
• Eksploatacja – monitoring, incident response, utrzymywanie konfiguracji jako kodu, aktualizacje, patchowanie.
• Optymalizacja – analiza danych z RIC, SMO, systemów NMS/OSS, tuning zasobów, auto-scaling, optymalizacja kosztów CAPEX/OPEX.

Obecność DevOpsa na każdym z tych etapów pozwala uniknąć klasycznego scenariusza: „dział telko kupił i poustawiał, a teraz IT/DevOps ma to utrzymać”. Praktyka pokazuje, że im wcześniej zespół DevOps współprojektuje architekturę, tym mniej „dziwnych wyjątków” pojawia się później w procesach CI/CD czy observability.

Miejsca styku z zespołami RAN, Core, bezpieczeństwa i biznesu

Inżynier DevOps, który wchodzi do świata 5G, szybko odkrywa, że samo opanowanie narzędzi to za mało – powodzenie zależy głównie od współpracy z innymi zespołami. Najważniejsze punkty styku to:

• Zespół RAN – definiuje wymagania co do opóźnień, synchronizacji czasu, parametrów radiowych. DevOps musi przełożyć je na konkretne ustawienia sieci IP, klastrów K8s, priorytety QoS, topologię edge.
• Zespół Core – odpowiada za logikę łączenia użytkowników, sesje, billing, polityki. DevOps współtworzy z nimi proces zmian dla CNF-ów, strategię skalowania AMF/SMF/UPF, polityki bezpieczeństwa.
• Zespół bezpieczeństwa – reguły firewalli, segmentacja sieci, ochrona interfejsów N2/N3/N6/N9, hardening K8s i hostów. DevOps pomaga zautomatyzować wdrożenie polityk bezpieczeństwa jako kodu.
• Zespół biznesowy / produktowy – planuje nowe usługi (np. prywatne sieci 5G, network slicing dla przemysłu). DevOps ocenia, jak takie usługi przełożą się na wymagania infrastrukturalne, skalowanie, koszty.

Bez dobrej komunikacji między tymi obszarami, cała wizja Open RAN i 5G cloud native łatwo zmienia się w chaos konfiguracji i silosy odpowiedzialności. DevOps może tu pełnić rolę „tłumacza” między światem telko a światem chmury – i to często jest realna przewaga takiej osoby w organizacji.

Podstawy: jak działa sieć komórkowa 4G/5G bez marketingu

Architektura 4G vs 5G – minimalny zestaw pojęć

RAN, Core, transport – co jest gdzie i po co

Na wysokim poziomie każda sieć komórkowa składa się z trzech głównych warstw:

• RAN (Radio Access Network) – stacje bazowe, anteny, jednostki radiowe i sterujące. To tutaj urządzenie użytkownika (telefon, modem IoT) „widzi” sieć.
• Core – serce sieci, które decyduje, kto może się połączyć, jak zestawić sesję, jak naliczać opłaty, jak kierować ruch do internetu lub do innych sieci.
• Transport – sieć IP/MPLS, łącząca RAN z Core oraz łącząca elementy Core między sobą i z innymi sieciami (internet, sieci prywatne, inne operatory).

W 4G rolę serca pełni EPC (Evolved Packet Core), w 5G – 5G Core zbudowany wg architektury usługowej (SBA). RAN w 4G to przede wszystkim eNodeB, w 5G – gNodeB, przy czym coraz częściej rozbijany na osobne funkcje: RU/DU/CU w Open RAN. DevOps widzi to głównie jako zestaw maszyn fizycznych i wirtualnych, clusterów K8s, sieci overlay i usług L7, które trzeba ze sobą spiąć z odpowiednim QoS.

Co zmienia się przy przejściu z EPC na 5G Core (SBA)

4G EPC był zaprojektowany w duchu bardziej monolitycznym – choć działał na serwerach, często był dostarczany jako „pudełko” lub VNF z dość sztywną strukturą. 5G Core przechodzi na Service-Based Architecture (SBA): funkcje sieciowe są rozbite na mniejsze komponenty (NF – Network Functions), które komunikują się między sobą po API (HTTP/2, REST, TLS). Pojawia się rejestr usług (NRF), który pomaga w service discovery, a ruch sterowania przypomina bardziej architekturę mikrousług.

Dla DevOpsa to ogromna zmiana jakościowa. Pojawia się możliwość stosowania znanych wzorców z chmury publicznej: serwis mesh, API gateway, rate limiting, circuit breakers, versioning API. Jednocześnie rośnie złożoność – zamiast kilku dużych VNF-ów mamy kilkadziesiąt lub więcej CNF-ów, które trzeba poprawnie zintegrować, monitorować i aktualizować bez przerw w usługach.

NSA vs SA – dlaczego DevOpsa powinno to interesować

5G może być wdrażane w dwóch wariantach:

• NSA (Non-Standalone) – 5G RAN (gNB) współpracuje z istniejącym 4G EPC. Służy głównie do zwiększenia przepustowości (tzw. 5G „na sterydach 4G”).

Standalone (SA) – gdzie zaczyna się „prawdziwe” 5G

Drugi model to SA (Standalone), czyli pełnoprawne 5G z własnym 5G Core opartym o SBA. Tutaj kończy się „doklejka do LTE”, a zaczyna sieć projektowana od zera pod usługi o niskich opóźnieniach, network slicing i masowe IoT. Urządzenia mogą łączyć się bezpośrednio z 5G Core, a operator nie jest już ograniczony architekturą EPC.

Z perspektywy DevOpsa różnica jest zasadnicza. W NSA często dotykasz tylko fragmentu RAN i kilku gateway’ów, w SA – wchodzisz w cały ekosystem CNF-ów 5G Core, ich zależności, pipeline’y CI/CD, strategie rolloutów i rollbacków. Pojawiają się zagadnienia, których wcześniej w telko praktycznie nie było: blue/green dla funkcji kontrolnych, traffic mirroring NF-ów sterujących, stopniowe podłączanie nowych grup abonentów do nowej wersji Core.

Jeśli dziś pracujesz przy NSA i masz wrażenie, że „to tylko kolejny zestaw VNF-ów”, przejście do SA bywa pierwszym momentem, gdy cały stack cloud native staje się kluczowy dla działania sieci, a nie tylko „nowinką do testów w labie”.

Jak przepływa ruch: płaszczyzna sterowania vs użytkownika

Dwie płaszczyzny, dwa zestawy wyzwań dla DevOpsa

Sieci 4G/5G zawsze rozróżniają dwie płaszczyzny:

• Control Plane (CP) – sygnalizacja, uwierzytelnianie, zestawianie sesji, wymiana informacji między funkcjami sieciowymi.
• User Plane (UP) – faktyczny ruch użytkownika: dane aplikacji, głos po VoLTE/VoNR, wideo, IoT.

Dla DevOpsa to często oznacza dwa oddzielne światy w tej samej infrastrukturze. CP jest wrażliwy na latencję, jitter i krótkie przerwy, ale przerzuca stosunkowo mało danych. UP przerzuca ogromne wolumeny, ale jest bardziej odporny na pojedyncze zgubione pakiety – za to bardzo źle znosi brak przepustowości lub błędną ścieżkę routingu.

W praktyce kończy się to osobnymi politykami dla network policies w K8s, innymi klasami storage dla logów CP vs UP, odmiennymi SLO i regułami autoskalowania. Przykład: AMF/SMF w 5G Core skalujesz głównie po liczbie sesji i opóźnieniach w CP, a UPF – po throughput i wykorzystaniu CPU/DPDK.

Dlaczego rozdział CP/UP ma znaczenie w 4G i 5G

W 4G pojawiło się już CP/UP Separation (CUPS), ale dopiero w 5G stało się ono naturalnym elementem architektury. Rozdzielenie tych płaszczyzn pozwala umieszczać funkcje sterujące centralnie lub regionalnie, a funkcje użytkownika (UPF) jak najbliżej klienta – w edge/far edge.

W codziennej pracy DevOpsa przekłada się to na:

• projektowanie osobnych klastrów dla CP i UP, z różnym hardware’em (np. serwery z akceleracją SmartNIC/DPDK dla UPF);
• odrębne pipeline’y CI/CD – inne testy niefunkcjonalne, inne kryteria zatrzymania rolloutów;
• segmentację sieci (np. oddzielne VRF-y/VLAN-y, różne klasy QoS, inne zasady firewalli dla N2/N11 vs N3/N6);
• różne strategie backupu/restore (dla CP głównie stan logiczny i bazy danych, dla UP – konfiguracja i metadane, a nie sam ruch).

Jeżeli dotąd pracowałeś głównie z mikroserwisami biznesowymi, CP/UP może przypominać ci rozdział pomiędzy warstwą API a warstwą przetwarzania dużych strumieni danych – tylko, że tym razem skutki błędów odczuje cały region sieci, a nie tylko jeden produkt cyfrowy.

Open RAN – rozbijanie monolitu RAN na klocki software’owe

Klasyczny RAN vs Open RAN – z czym w ogóle mamy do czynienia

Tradycyjnie RAN był monolitem od jednego dostawcy: stacja bazowa jako „czarna skrzynka”, ściśle powiązany software i hardware, zamknięte interfejsy. Open RAN próbuje to zmienić, rozbijając RAN na RU/DU/CU oraz wprowadzając otwarte API między tymi elementami i systemami nadrzędnymi (RIC, SMO).

W uproszczeniu struktura wygląda tak:

• RU (Radio Unit) – fizyczny front-end, radio i sygnał w eterze. Najbliżej anteny, najbardziej „sprzętowy” element.
• DU (Distributed Unit) – przetwarzanie niższych warstw protokołu (np. MAC, częściowo PHY), działa często na edge, w formie VNF/CNF na COTS.
• CU (Centralized Unit) – wyższe warstwy (RLC/PDCP, kontrola połączeń), może być bardziej scentralizowany, także jako CNF.

Dla inżyniera DevOps to oznacza, że znaczna część tego, co wcześniej było zabetonowane w urządzeniu vendorowym, staje się software’em, który można:

• deployować jako kontenery lub VM-ki na standardowym sprzęcie;
• monitorować standardowymi narzędziami observability (Prometheus, OpenTelemetry, ELK);
• oskryptować i zautomatyzować przy pomocy Ansible/Terraform/Helm/Argo CD.

To przejście bywa stresujące, bo nagle pojawia się masa nowych „moving parts”. Z drugiej strony, właśnie tutaj doświadczenie z klasycznym DevOpsem staje się ogromnym atutem – osoby z telko często dopiero uczą się świata chmury, a ty już wiesz, jak ujarzmić dynamiczną infrastrukturę.

Fronthaul, midhaul, backhaul – sieć IP w służbie Open RAN

Rozbicie RAN na RU/DU/CU wprowadza trzy odcinki sieci transportowej:

• Fronthaul – RU → DU, najbardziej wrażliwy na opóźnienia i jitter.
• Midhaul – DU → CU, nadal wymagający niskiej latencji, ale z nieco większą tolerancją.
• Backhaul – CU → Core, tutaj głównym wyzwaniem jest przepustowość i niezawodność.

Dla DevOpsa fronthaul i midhaul to obszary, gdzie klasyczny „cloud networking” (CNI, overlay, SDN w DC) spotyka się z twardymi wymaganiami telko. Nie wystarczy, że „pakiety dochodzą” – trzeba dbać o:

• precyzyjną synchronizację czasu (PTP, SyncE) na hostach, na których działają DU/CU;
• profile QoS w sieci IP/MPLS, które gwarantują priorytet dla ruchu fronthaul;
• odpowiedni dobór parametrów sieciowych w K8s (np. SR-IOV, pinning CPU, hugepages).

Jeśli brzmi to jak połączenie roli sieciowca, SRE i admina K8s – tak dokładnie jest. Stąd tak duża potrzeba ludzi, którzy potrafią rozmawiać i z „radiowcami”, i z „chmurowcami”.

RIC, xApps/rApps i SMO – nowa warstwa sterowania RAN-em

Open RAN wprowadza dodatkowy mózg sieci radiowej: RIC (RAN Intelligent Controller). Występuje zwykle w dwóch wariantach:

• Near-RT RIC – działa blisko RAN, w skalach czasowych rzędu dziesiątek–setek milisekund, steruje np. przydziałem zasobów radiowych, handoverami.
• Non-RT RIC – działa bardziej centralnie, w skalach sekund, minut i wyżej, odpowiada za polityki, długoterminową optymalizację.

Na tych kontrolerach działają małe aplikacje: xApps (near-RT) i rApps (non-RT). Tu pojawia się bardzo znajomy dla DevOpsa ekosystem:

• repozytoria aplikacji RIC (wewnętrzne „markety” xApps/rApps);
• pipeline’y CI/CD dla tych aplikacji, wersjonowanie, rollbaki, canary;
• monitoring metryk skuteczności (np. poprawa throughputu, obniżenie interference).

Obok RIC funkcjonuje SMO (Service Management and Orchestration) – system odpowiedzialny za orkiestrację i zarządzanie całym Open RAN-em. To SMO integruje się z K8s, systemami inventory, OSS/BSS, a także z twoimi pipeline’ami jako centralny punkt „zamawiania” zmian w RAN-ie.

Praktycznie wygląda to tak, że DevOps tworzy i utrzymuje:

• szablony Helm/Kustomize dla xApps/rApps;
• joby w Argo CD/Jenkins, które wdrażają aplikacje na konkretnych RIC-ach;
• dashbordy (np. Grafana) pokazujące wpływ danej xApp na KPI radiowe.

Jeśli pojawia się obawa: „co jeśli zła xApp rozwali mi RAN?”, odpowiedzią są dokładnie te same wzorce, które stosuje się od lat w świecie webowym: mocne testy w stagingu, progressive rollout, szybki rollback, feature flagi. Różnica polega na tym, że zamiast spadku konwersji w sklepie internetowym obserwujesz wzrost liczby dropów połączeń.

5G Core jako system cloud native – praktyczne przejście z VNFs do CNFs

Od „appliance + hypervisor” do „CNF na K8s”

W wielu organizacjach pierwszy krok ku wirtualizacji Core wyglądał tak: fizyczne appliance zostały zamienione na VNF-y na hypervisorze. Z perspektywy DevOpsa nie było to szczególnie cloud native – statyczne VM-ki, pojedyncze wielkie obrazy vendorowe, ręczne migracje.

Przy 5G Core w wersji cloud native pojawiają się CNF-y uruchamiane na Kubernetesa. Dostawcy zaczynają dostarczać swoje funkcje jako zestawy chartów Helm, manifestów YAML czy operatorów K8s. To spora zmiana jakościowa:

• można stosować standardowe narzędzia do deklaratywnego zarządzania stanem (GitOps);
• skala zarządzania rośnie – zamiast 10 dużych VM-ek masz 100+ podów w wielu namespace’ach;
• trace’owanie problemów wymaga łączenia logów i metryk z wielu mikroserwisów (np. AMF + AUSF + UDM).

Jeśli obawiasz się, że telko-CNF to „zupełnie inny świat” niż mikroserwisy, z którymi pracowałeś w e-commerce czy fintechu – dobra wiadomość jest taka, że 70–80% praktyk jest identycznych. Różnica tkwi w wymaganiach niefunkcjonalnych, sposobie licencjonowania i integracji z bardzo specyficznymi interfejsami 3GPP.

Typowa topologia klastrów K8s pod 5G Core

W praktyce operatorzy rzadko kończą z jednym wielkim klastrem. Częściej spotkasz:

• centralny klaster Core – dla funkcji kontrolnych (AMF, SMF, AUSF, UDM, NRF, PCF);
• regionalne/edge klastry UP – dla UPF i funkcji związanych z danymi użytkownika;
• czasem osobne klastry dla systemów OSS/BSS, RIC/SMO czy aplikacji MEC.

Dla DevOpsa oznacza to zarządzanie wieloma klastrami z centralnego punktu (np. Rancher, Anthos, OpenShift, własne tooling), ujednolicenie:

• wersji K8s i CNI;
• polityk bezpieczeństwa (PSP/OPA Gatekeeper/Kyverno);
• standardów logowania i metryk (ta sama struktura labeli, te same exportery).

Dobrym podejściem jest traktowanie każdego nowego klastra jak produktu: dedykowany katalog IaC (Terraform/Ansible), definicje baseline’u (np. wspólne CRD, operatorzy, ingress), zautomatyzowane upgrady. Dzięki temu rollout kolejnego regionu 5G nie wymaga ręcznego „składania lego” za każdym razem.

Strategie migracji z VNF do CNF – jak nie wywrócić sieci

Przejście z VNF na CNF w 5G Core rzadko odbywa się „big bangiem”. Częstsze są stopniowe scenariusze, które można poukładać w kilka wzorców:

• Shadow / mirror traffic – nowa wersja CNF otrzymuje kopię ruchu (np. części sygnalizacji), ale nie wpływa na realnych użytkowników. Daje to czas na testy niefunkcjonalne.
• Canary dla wybranych abonentów – mała grupa IMSI przechodzi przez nowy AMF/SMF/UPF. Jeżeli KPI się zgadzają, stopniowo zwiększasz zakres.
• Slice-by-slice – nowe CNF-y obsługują konkretny network slice (np. prywatne sieci kampusowe), podczas gdy masowy ruch konsumencki zostaje na starej infrastrukturze.

W każdym z tych wariantów DevOps buduje automatyzację:

• konfiguracji routingu/selection (np. SMF Selection, UPF Selection Policies);
• zmiany parametrów w HSS/UDM/PCF tak, by określone grupy użytkowników trafiały do nowego Core;
• reguł zatrzymania i rollbacku, gdy KPI spadają poniżej normy.

Przykład z życia: operator uruchamia pierwszy CNF-owy UPF w edge dla małej grupy klientów biznesowych korzystających z prywatnej sieci 5G. DevOps konfiguruje pipeline, który w nocy przenosi kolejne pule adresów IP do nowego UPF-u, jednocześnie obserwując opóźnienia i packet loss. Gdy tylko któryś z SLO zostanie naruszony, pipeline automatycznie zatrzymuje migrację i przywraca poprzednią konfigurację.

Specyfika pipeline’ów CI/CD dla CNF-ów telko

Specyfika pipeline’ów CI/CD dla CNF-ów telko

Pipeline’y dla 5G Core wyglądają znajomo, ale mają kilka „telko-twistów”. Zwykłe build → test → deploy to za mało. Dochodzi kilka dodatkowych etapów, które dla webu byłyby overkill, a tu są chlebem powszednim.

Typowy przepływ dla CNF-a core’owego może wyglądać tak:

• budowa obrazu i skanowanie bezpieczeństwa (SCA, SAST, SBOM);
• testy jednostkowe i kontraktowe interfejsów 3GPP (Nxx/API);
• testy protokołów (NGAP, PFCP, HTTP2/JSON/NRF) w symulowanym środowisku;
• testy wydajnościowe pod konkretne profile ruchu (np. rejestracja terminali vs. przepływ danych);
• weryfikacja zgodności z policy telko: pinning CPU, hugepages, ograniczenia NUMA, affinity;
• automatyczna walidacja manifestów K8s względem wewnętrznych reguł (OPA/Gatekeeper, Kyverno);
• canary lub blue/green na wybranych klastrach/regionalnych instancjach.

Największa różnica polega na tym, że pipeline musi „rozumieć” KPI sieciowe. Sam sukces deploymentu i zielone testy integracyjne nie wystarczą. DevOps często dopina do CI/CD kroki, które:

• na czas testu włączają dodatkowe metryki w Prometheusie (np. latency konkretnego interfejsu N11);
• porównują wykresy KPI przed/po zmianie w zdefiniowanym oknie czasowym;
• na tej podstawie podejmują decyzję o kontynuacji rollout’u albo rollbacku.

Dobrym trikiem jest zbudowanie „telko quality gate” – zestawu automatycznych checków, które muszą przejść wszystkie releasy CNF-ów. Może to być np. minimalny odsetek udanych rejestracji UE w testowym slicie, limit wzrostu opóźnienia akceptacji PDU Session czy liczby restartów podów w czasie syntetycznego testu przeciążeniowego.

Testowanie 5G Core w praktyce – symulatory, laby i digital twin

Przy zwykłej aplikacji biznesowej wystarczy testowe API i baza danych. Dla 5G Core potrzebny jest kawał ekosystemu: symulatory gNB, UE, a czasem nawet fragmenty RAN-u i sieci transportowej. Wiele firm na początku lekceważy tę warstwę i szybko kończy z testami typu „kliknijmy coś ręcznie po wdrożeniu”. Da się to zrobić lepiej.

W praktyce stosuje się kilka warstw środowisk:

• Unit/system test bed – lekki lab, w którym CNF-y komunikują się z emulatorami pozostałych funkcji (np. emulator UDM dla testowania AMF).
• Integracyjny „mini-operator” – środowisko z pełnym łańcuchem: gNB-sim → AMF/SMF/UPF → Internet, zwykle z ograniczoną skalą, ale realną sygnalizacją.
• Digital twin – coraz częściej budowany jako kopia topologii produkcyjnej: te same wersje CNF-ów, zbliżone parametry sieci, ruch generowany na podstawie realnych statystyk.

DevOps często odpowiada za automatyzację całej ścieżki: od postawienia labu (Terraform/Ansible), przez generatory ruchu (np. UERANSIM, Spirent, własne narzędzia), aż po raporty z testów. W praktyce przydają się:

• gotowe „scenariusze ruchu” w repozytoriach – np. wysoki churn rejestracji UE, masowe SMS/VoNR, burst danych w godzinach szczytu;
• pipeline’y, które potrafią odpalić te scenariusze na żądanie dla konkretnego brancha lub taga obrazu.

Jeśli brzmi to jak skomplikowany zestaw narzędzi, spokojnie – większość rzeczy da się układać krok po kroku. Na początku wystarczy jedna automatyczna ścieżka: build → deploy do labu → syntetyczny test rejestracji → proste SLO na udane attach’e.

Observability w sieci 5G i Open RAN – jak nie utonąć w metrykach

Co monitorować w 5G Core i RAN z perspektywy DevOpsa

Monitoring w telko ma dwa wymiary: klasyczny (CPU, RAM, latency, błędy HTTP) i domenowy (KPI radiowe, sygnalizacja, dropy połączeń). DevOps zwykle zaczyna od tego pierwszego, ale prędzej czy później musi wejść w drugi, bo to on decyduje o tym, czy release jest „dobry”.

Dla 5G Core przydatnymi metrykami są m.in.:

• liczba aktywnych sesji PDU per UPF oraz ich dystrybucja po regionach/edge;
• czas zestawienia sesji (PDU Session Establishment Time) per slice/APN/DNN;
• liczba nieudanych rejestracji UE wraz z przyczyną (cause codes z 3GPP);
• obciążenie interfejsów N2/N3/N11/N4 – opóźnienia, retransmisje, błędne odpowiedzi;
• wewnętrzne metryki K8s (restarty podów CNF, throttling CPU, pending pods).

Po stronie RAN i Open RAN dodatkowo dochodzą:

• Radio KPI (RSRP, SINR, BLER, throughput per cell/UE);
• wydajność DU/CU na poziomie TTI, schedulerów i HARQ;
• stabilność fronthaul/midhaul (jitter, packet loss, czas synchronizacji PTP).

Dobry zestaw dashboardów łączy oba światy. Przykład: release nowej xApp na Near-RT RIC zmienił parametry schedulera. Na grafanie widzisz wzrost throughputu w komórkach brzegowych, ale jednocześnie niewielki wzrost CPU na DU i lekki spadek sukcesu rejestracji w godzinach szczytu. Tylko widząc te informacje razem, możesz sensownie ocenić trade-off.

Tracing i logi w CNF-ach – jak ogarnąć setki mikroserwisów

Rozproszony Core 5G liczy dziesiątki, czasem setki mikroserwisów. Diagnostyka „po logach” z pojedynczego poda to proszenie się o ból głowy. Pomaga konsekwentne stosowanie kilku zasad:

• standaryzacja formatów logów (JSON z ujednoliconymi polami: traceId, imsi, apn/dnn, slice, interfejs);
• globalny tracing (np. OpenTelemetry) z przenoszeniem correlation ID między funkcjami (AMF → SMF → UPF);
• logowanie kluczowych zdarzeń sygnalizacyjnych jako osobnych eventów, a nie „szumu” debugowego.

Prosty przykład z życia: klient zgłasza losowe problemy z VoNR w jednym regionie. Zamiast przeszukiwać gigabajty logów w stylu „grep po IMSI”, DevOps odpala zapytanie w systemie logowania po traceId przypiętym do danej sesji, a potem ogląda rozproszony trace całego przepływu. Jedno spojrzenie pokazuje, że opóźnienie skacze na interfejsie N2 między gNB a AMF, a nie w samej aplikacji głosowej.

Alerting oparty na SLO – z biznesowej perspektywy, nie tylko technicznej

Klasyczne reguły typu „CPU > 80%” czy „pod w CrashLoopBackOff” nadal są potrzebne, ale w sieci komórkowej ważniejsze stają się SLO oparte o doświadczenie użytkownika. W praktyce mogą to być:

• czas rejestracji UE mniejszy niż określona wartość dla 99% prób;
• odsetek udanych zestawień sesji PDU powyżej progu;
• latencja RAN + Core dla wybranych slice’ów (np. mMTC, URLLC) utrzymana w widełkach.

DevOps zwykle współpracuje tu z zespołami planowania i inżynierii radiowej. Z jednej strony potrzebne są twarde wartości progów, z drugiej – automatyzacja ich egzekwowania w Prometheusie, Alertmanagerze czy innych systemach. Po czasie udaje się ułożyć bibliotekę gotowych reguł SLO, które są używane powtarzalnie dla nowych regionów, slice’ów czy typów ruchu.

Bezpieczeństwo i multi-tenancy w chmurowym 5G

Security by design w CNF-ach i Open RAN

Świat telko przez lata był „zamkniętym ogródkiem”: vendorowe appliance’y, prywatne interfejsy, fizyczna separacja. Cloud native otwiera dużo nowych drzwi – także dla atakujących. DevOps, który zna praktyki bezpieczeństwa z klasycznego IT, może tu zrobić ogromną różnicę.

Na poziomie K8s i CNF-ów sprawdzają się dobrze znane mechanizmy:

• minimalne uprawnienia w podach (brak root, ograniczone capabilities, read-only filesystem tam, gdzie się da);
• network policies izolujące namespace’y telko, OSS/BSS, MEC i narzędziowe;
• regularne skanowanie obrazów CNF-ów i bazowych OS pod kątem podatności;
• wymuszanie TLS/MTLS na wszystkich interfejsach HTTP/2/Nxx między funkcjami Core.

Dochodzi też perspektywa typowo telko: ochrona sygnalizacji, separacja płaszczyzny użytkownika i sterowania, bezpieczne zarządzanie kluczami subskrybentów (K, K_AMF, itp.). Tu przydają się integracje z HSM-ami, KMS-ami chmurowymi i wewnętrznymi PKI operatora, które DevOps musi umieć „wpiąć” w pipeline’y i konfigurację klastrów.

Network slicing i izolacja tenantów

Jedną z najciekawszych funkcji 5G jest network slicing – logiczne sieci z różnymi parametrami QoS zbudowane na tej samej fizycznej infrastrukturze. Z perspektywy DevOpsa to praktycznie multi-tenancy na sterydach.

Izolacja odbywa się na wielu poziomach:

• logika Core (PCF, SMF, UDM) określa, jakie zasoby i polityki są przypisane do danego slice’a;
• UPF-y mogą być współdzielone lub dedykowane, często na osobnych klastrach/edge’ach;
• na RAN konfiguracja schedulera i parametrów radiowych rozdziela zasoby między slice’y.

DevOps musi spiąć to wszystko w powtarzalne definicje: CRD w K8s odzwierciedlające slice’y, szablony konfiguracji dla PCF/SMF, a nawet polityki w sieci transportowej (QoS, segment routing). Dobrą praktyką jest traktowanie każdego slice’a jak osobny produkt z własnym IaC i pipeline’ami – od konfiguracji Core, przez RAN, po monitoring SLO.

Przykład: prywatna sieć dla fabryki z wymaganiami niskiego opóźnienia dostaje dedykowany slice, własne UPF-y w lokalnym edge i osobne dashboardy KPI. DevOps ma w repozytorium katalog „slice-fabryka-X”, który zawiera komplet definicji – od manifestów K8s, po polityki QoS w sieci IP/MPLS.

Kompetencje DevOpsa w nowym świecie telko

Jakie umiejętności naprawdę robią różnicę

Przy pierwszym kontakcie z 5G i Open RAN można poczuć się przytłoczonym: dziesiątki skrótów 3GPP, egzotyczne protokoły, ograniczenia sprzętowe. Jednocześnie wiele fundamentów, które już znasz, jest tu na wagę złota.

Mocny zestaw startowy to:

• solidne obycie z K8s (networking, storage, operators, troubleshoot na poziomie node’ów i podów);
• praktyczny GitOps (Argo CD/Flux), podejście „wszystko jako kod” – klastry, sieć, polityki;
• observability (Prometheus, Grafana, OpenTelemetry, ELK) i projektowanie sensownych SLO;
• automatyzacja infrastruktury (Terraform, Ansible) z myśleniem o wieloregionowych wdrożeniach;
• bezpieczeństwo w praktyce: polityki K8s, skanowanie obrazów, tajemnice, certyfikaty.

Do tego dochodzi stopniowe oswajanie się z domeną telko: najpierw high-level (co to AMF/SMF/UPF, jak działa RAN), później szczegóły (interfejsy N2/N3/N11, zasady routingu ruchu, network slicing). Wiele zespołów telko bardzo docenia ludzi, którzy na początku zadają proste pytania typu „po czym poznamy, że sieć działa lepiej po tym release?”, a potem pomagają przełożyć tę odpowiedź na metryki i pipeline’y.

Typowe pułapki i jak ich unikać

Najczęstsze problemy pojawiają się zwykle w tych samych miejscach. Kilka przykładów z praktyki:

• „K8s jak w webie” – próba kopiowania 1:1 wzorców z e-commerce, bez uwzględnienia wymagań czasu rzeczywistego i pinningu zasobów. Rozwiązanie: zbliżyć się do zespołów performance i radio, zrozumieć, które komponenty potrzebują „specjalnego traktowania”.
• „Najpierw sprzęt, potem automatyzacja” – ręczne stawianie labów i klastrów „na szybko”, a dopiero później próby opisania tego jako kodu. Skutkuje niepowtarzalnymi środowiskami i trudnymi migracjami. Lepiej zacząć od minimalnego, ale od razu zautomatyzowanego baseline’u.
• „Monitoring tylko techniczny” – skupienie się na CPU/podzie/restarcie, bez powiązania z KPI sieciowymi. Efekt: release „zielony” z punktu widzenia DevOps, a z punktu widzenia abonentów – pogorszenie usług. Pomaga włączenie w projektowanie dashboardów i alertów ludzi od QoS i planowania sieci.

Najczęściej zadawane pytania (FAQ)

Czym różni się praca DevOpsa w 5G/Open RAN od klasycznego DevOps w aplikacjach webowych?

Największa różnica polega na tym, że w 5G i Open RAN dotykasz ścieżki krytycznej – Twoja platforma obsługuje realny ruch użytkowników: połączenia głosowe, transmisję danych, sygnalizację radiową. Każdy dodatkowy hop sieciowy, błędna konfiguracja CNI czy zbyt agresywny autoscaling może przełożyć się na utratę sesji, większe opóźnienia lub problemy z handoverem między komórkami.

W klasycznych aplikacjach webowych błąd to zwykle wolniejsza strona czy chwilowa niedostępność. W telko skutkiem jest realna przerwa w łączności dla tysięcy osób. Do znanych narzędzi – Kubernetes, CI/CD, monitoring – dochodzi więc dużo ostrzejsze myślenie o latencji, jitterze, SLA i o tym, jak Twoje decyzje konfiguracyjne „dotykają” radia i core.

Czy bez znajomości „telco-jargonu” (eNB, gNB, AMF itd.) mam szansę wejść w świat 5G jako DevOps?

Tak, masz. Na start nie potrzebujesz znać wszystkich interfejsów i skrótów z 3GPP na pamięć. Kluczowe jest opanowanie podstaw: co to jest RAN vs Core, jakie są główne funkcje sieciowe (np. DU, CU, UPF, AMF) i jak wygląda ogólna topologia sieci komórkowej. Resztę spokojnie dociągniesz w trakcie pracy.

Znaczna część codziennych zadań to praca na znanych klockach: Kubernetes, Helm, GitOps, observability, security, automation. Coraz częściej to właśnie zespoły RAN/Core uczą się od DevOpsów praktyk CI/CD czy GitOps, a nie odwrotnie. Dobrą strategią jest skupienie się na miejscach styku: gdzie kończy się odpowiedzialność inżynierów radiowych, a zaczyna platforma chmurowa i operacje.

Co konkretnie zmienia Open RAN w codziennej pracy inżyniera DevOps?

Open RAN rozbija „magiczne pudełka” jednego vendora na zestaw otwartych, programowych funkcji, które możesz wdrażać na standardowym sprzęcie x86 – często w kontenerach zarządzanych przez Kubernetes. Zamiast jednego zamkniętego boxa masz więc wiele CNF-ów od różnych dostawców, z własnymi wymaganiami dotyczącymi sieci, CPU, pamięci czy opóźnień.

Dla DevOpsa oznacza to więcej wpływu i odpowiedzialności: projektowanie klastrów K8s na edge/far edge, dobór CNI i storage, automatyzację deploymentu CNF-ów, update’y, rollbacki, integrację monitoringu i logów. To przeskok z „ktoś zarządza siecią, my tylko dostarczamy VM-y” do roli współwłaściciela stabilności i wydajności całej sieci komórkowej.

Czy praca przy 5G to koniec zwinności? Jak pogodzić „krytyczną infrastrukturę” z CI/CD?

Nie, to nie jest koniec zwinności – zmienia się raczej jej forma. Sieci 4G/5G są traktowane jako infrastruktura krytyczna, więc wymagania bezpieczeństwa, change managementu i testów są wyższe niż w typowej aplikacji B2C. Nie znaczy to jednak, że trzeba wrócić do ręcznych wdrożeń raz na kwartał.

Model pracy przypomina SRE w dużej chmurze publicznej: małe, dobrze opisane zmiany, silna automatyzacja, SLO i error budgets, rozbudowane testy niefunkcjonalne, precyzyjne rollbacki. CI/CD nadal jest podstawą, tylko pipeline musi od początku uwzględniać metryki telco (latencja, dropy, setup time) i mechanizmy automatycznego wstrzymywania rolloutów, gdy SLO są naruszane.

Jakie umiejętności powinien rozwinąć DevOps, który chce wejść w świat 5G i Open RAN?

Poza klasycznym zestawem (Kubernetes, sieci w chmurze, CI/CD, IaC) przydają się trzy dodatkowe obszary: rozumienie wymagań czasu rzeczywistego (latencja, jitter, QoS), podstawy topologii sieci komórkowej (RAN vs Core, gdzie płynie sygnalizacja, gdzie dane użytkownika) oraz praca z rozproszonym edge (setki lokalizacji, różne profile ruchu, ograniczone zasoby na site).

Dobrym krokiem jest też wejście mocniej w observability i testy niefunkcjonalne: load testy, testy odpornościowe, chaos engineering. W praktyce coraz częściej potrzebny jest ktoś, kto umie zbudować pipeline, który nie tylko „deployuje CNF”, ale też automatycznie sprawdza, czy opóźnienia i stabilność mieszczą się w założonych SLO.

Jak wygląda typowy pipeline CI/CD dla funkcji sieciowych 5G (CNF) z perspektywy DevOpsa?

Pipeline przypomina ten znany z mikroserwisów, ale jest bardziej wyczulony na parametry sieciowe i integrację między vendorami. Zwykle obejmuje: budowę i skanowanie obrazów, testy jednostkowe, deployment do laba odwzorowującego topologię, testy integracyjne między CNF/VNF, a potem testy niefunkcjonalne – obciążeniowe, wydajnościowe, odpornościowe.

Dopiero po przejściu tych etapów wchodzi staging z ruchem zbliżonym do produkcji, a następnie rollout do sieci live – z canary deploymentem, rolloutem per region/site i automatycznym monitorowaniem SLI typowo telko (czas zestawienia połączenia, odsetek przerwanych sesji, latency RU–DU/CU). Każdy krok powinien mieć jasny warunek „go/no-go” i ścieżkę szybkiego rollbacku.

Na jakich etapach cyklu życia sieci 5G obecność DevOpsa daje największą wartość?

Największą różnicę DevOps robi tam, gdzie w grę wchodzą powtarzalność, automatyzacja i skalowanie: od planowania architektury chmury (central, regional, edge) i projektowania klastrów K8s, przez budowę laba i stagingu, aż po sam rollout i eksploatację produkcji. Przykład z praktyki: automatyzacja deployu w labie i stagingu często skraca czas integracji nowego vendora z miesięcy do tygodni.

W fazie operacyjnej DevOps przejmuje rolę „strażnika zmiany”: zarządza aktualizacjami CNF-ów, skalowaniem funkcji typu UPF/AMF, rolloutem xApps/rApps w RIC-u, a także wspiera zespoły RAN/Core w analizie problemów wydajnościowych na bazie metryk i logów z wielu warstw. Dzięki temu zmiany w sieci produkcyjnej mogą być częstsze, ale znacznie lepiej kontrolowane.

Co warto zapamiętać

• Środowisko 5G/Open RAN przypomina klasyczną chmurę (Kubernetes, CI/CD, monitoring), ale pracuje w ścieżce krytycznej sieci – każdy dodatkowy hop, proxy czy zły CNI może bezpośrednio zepsuć opóźnienia, handover i stabilność sesji użytkowników.
• Różnica między klasycznym IT a telco to nie tylko nowe skróty, ale skala i charakter ruchu: tysiące rozproszonych lokalizacji, skrajne wymagania na latencję i bardzo nieregularne obciążenia (np. stadion, koncert, awaria innego operatora).
• Open RAN i 5G cloud native „odczarowują” telco-jargon – kluczowe stają się znane kompetencje DevOps (Kubernetes, Helm, GitOps, observability, policy-as-code), a znajomość terminologii 3GPP jest potrzebna głównie na styku odpowiedzialności z zespołami RAN/Core.
• DevOps nie przejmuje całej odpowiedzialności za radio, ale jego decyzje dotyczące klastra K8s, sieci, storage czy autoscalingu bezpośrednio wpływają na parametry radiowe, doświadczenie użytkownika i efektywność wykorzystania pasma.
• Obawa przed „krytyczną infrastrukturą państwową” jest naturalna, jednak model pracy coraz bardziej przypomina SRE w dużej chmurze: ciągłe, małe zmiany, jasno zdefiniowane SLO, error budgets, automatyczne rollbaki i ścisła współpraca z SecOps.
• Przejście z monolitycznych „pudełek” vendorów na CNF-y na x86 przesuwa ciężar z hardware na software i orkiestrację – DevOps staje się właścicielem spójności i przewidywalności platformy od edge/far-edge po core.