Telekomunikacja opiera się na faktach. Ruch w sieci, poziomy SLA czy koszty – wszystko to widać w danych dużo wcześniej, niż trafi na slajdy w prezentacji. Dlatego podejście oparte na danych polega na tym, by traktować wydajność, niezawodność i koszty jako coś mierzalnego i pozwolić, by to właśnie te liczby kierowały architekturą systemu.
W tym artykule dzielimy się naszym doświadczeniem z projektów w branży telekomunikacyjnej w oparciu o Microsoft Azure. Pokazujemy, jak konkretne pomiary pomogły podejmować lepsze decyzje projektowe i dlaczego w chmurze dowody zawsze wygrywają z założeniami.

Najpierw mierz, potem projektuj

Platforma BI w telekomunikacji musi być mierzalna od pierwszego dnia. Najpierw wdraża się narzędzia do zbierania danych, a dopiero potem projektuje rozwiązanie. Dzięki temu decyzje podejmowane są na podstawie faktów, a nie intuicji.

Te wskaźniki obejmują kilka obszarów. Wydajność można mierzyć poprzez przepustowość odczytu/zapisu, opóźnienia w kolejkach, czasy realizacji wsadów i efektywność przetwarzania równoległego. Niezawodność ocenia się na podstawie wskaźników powodzenia zadań, czasu potrzebnego na odzyskanie sprawności po awarii oraz aktualności dostarczanych danych. Koszty monitoruje się dzięki wskaźnikom takim jak cena za przetworzony terabajt, koszt pojedynczego raportu lub zapytania, współczynnik pracy w trybie bezczynności czy proporcje ruchu wychodzącego i przychodzącego. Wreszcie procesy wdrożeniowe ocenia się, patrząc na czas realizacji zmian, częstotliwość wdrożeń i odsetek wycofań.

Połączone w całość, te miary stają się tzw. „bramkami” w procesach CI/CD (Continuous Integration/Continuous Delivery). Jeśli zmiana nie spełnia ustalonych progów, musi zostać poprawiona lub uzasadniona konkretnymi danymi.

Dzięki temu podejściu operatorzy telekomunikacyjni mogą tworzyć platformy BI, które skalują się przewidywalnie, pozostają opłacalne i stale się doskonalą.

Case #1 — Migracja do chmury: większe maszyny, wolniejsze działanie

Podczas jednego z projektów migracyjnych dla klienta z branży telekomunikacyjnej oczekiwania były proste: przeniesienie procesów ETL (Extract, Transform, Load) z serwerów fizycznych na większe, mocniejsze maszyny wirtualne Microsoft Azure powinno je przyspieszyć. Rzeczywistość okazała się inna.

W infrastrukturze on-premise dyski SSD podłączone bezpośrednio do płyty głównej osiągały prędkości zapisu i odczytu powyżej 1 GB/s. W Azure natomiast dostępne dla wybranych maszyn wirtualnych dyski zarządzane osiągały jedynie około 250 MB/s. Zadania, które już wcześniej były mocno obciążone operacjami I/O, w chmurze stały się jeszcze większym wyzwaniem.

Aby temu zaradzić, trzeba było na nowo przemyśleć sposób przetwarzania danych. Zmieniono okna wsadowe, wprowadzono kompresję danych pośrednich i przeniesiono część transformacji bliżej systemów źródłowych, aby ograniczyć powtarzalne skanowanie dużych zbiorów danych. Niektóre usługi przeniesiono do modelu PaaS (Platform as a Service), gdzie zasoby obliczeniowe i pamięci masowe były lepiej dopasowane do wzorców dostępu. Dostosowano też stopień równoległości do rzeczywistej przepustowości dysków, a nie teoretycznych możliwości procesora. Wprowadzono także bramki benchmarkowe, tak aby każda nowa konfiguracja czy SKU musiała spełniać określone cele wydajnościowe i kosztowe przed wdrożeniem.

Równie ważna była lekcja finansowa. Opcje w portalu Azure, takie jak poziomy redundancji, klasy dysków premium czy dodatkowe repliki, z osobna wyglądają rozsądnie, ale w połączeniu mogą zwiększyć koszty o dziesiątki tysięcy euro rocznie. Projektując pod kątem najwolniejszego płatnego łącza i granic rozliczeniowych, udało się odzyskać wydajność i ustabilizować wydatki.

Przykładowy dashboard ze strategicznymi KPI dla kadry zarządzającej: liczba abonentów, churn, przychody, EBITDA i dostępność sieci

Zasada: projektuj zgodnie z modelem rozliczeniowym, który możesz udowodnić

W chmurze cena zawsze odzwierciedla wybory techniczne. Skalowalność działa dobrze tylko do pewnego momentu, później koszty rosną szybko. Kluczowe jest więc weryfikowanie założeń na podstawie danych, a nie domysłów. FinOps (Financial Operations) pozwala zamienić koszty w analitykę: zasoby są tagowane, wydatki przypisywane do konkretnych obszarów biznesowych, a prognozy tworzone na podstawie rzeczywistych obciążeń. Alerty pokazują, kiedy koszt jednostkowy zaczyna się wymykać spod kontroli. Dzięki temu cena staje się kolejnym zbiorem danych – śledzonym w czasie w euro za terabajt, za zapytanie czy za środowisko – a wszelkie zmiany lub odchylenia są widoczne i podlegają ocenie.

Case #2 — Wybór właściwej podstawy pod nową platformę

Budowa nowej platformy danych w całości w Azure dała możliwość przetestowania kilku podejść, zanim zapadła decyzja o docelowym rozwiązaniu. Porównano Azure Synapse, Azure SQL Database i SQL Server na maszynach wirtualnych. Każda z opcji miała swoje zalety, ale też ograniczenia — Synapse był zbyt mało elastyczny dla naszego obciążenia, Azure SQL Database w wyższych klasach zapewniał wydajność, lecz przy wielu środowiskach kosztował bardzo dużo, a SQL Server na VM-ach przywracał wyzwania związane z zarządzaniem i skalowaniem.

Dzięki eksperymentom udało się znaleźć rozwiązanie, które łączyło wydajność z efektywnością kosztową. Dane operacyjne były przetwarzane w mniejszych bazach Azure SQL Database, co okazało się bardziej opłacalne, a raportowanie wspierała ujednolicona struktura gwiazdy w Azure SQL Database. Dzięki automatycznym zasadom skalowania platforma zwiększała zasoby w godzinach szczytu i niemal całkowicie redukowała je w okresach niskiego obciążenia.

Efekt końcowy to nowoczesne środowisko BI, które wspierało rozwój biznesu, pozostawało opłacalne i zapewniało, że klient płacił tylko za faktycznie wykorzystane zasoby.

Przykładowy dashboard z operacyjnymi KPI: wydajność sieci, zgłoszenia, wykorzystanie pasma i monitorowanie awarii

Pętla operacyjna: decyzje w oparciu o dane

Prowadzenie platformy BI w telekomunikacji to nie jednorazowa konfiguracja, ale proces ciągły. Każda zmiana – od ustawień pamięci masowej, przez lokalizację obciążeń, po zasady skalowania – wpływa zarówno na wydajność, jak i na koszty. Dlatego decyzje powinny być zawsze podejmowane na podstawie danych, a nie założeń.

Dashboardy i telemetria tworzą tu niezbędną pętlę zwrotną. Pokazują, kiedy koszty lub przepustowość odbiegają od celu, kiedy warto przenieść obciążenia na tańsze poziomy usług lub kiedy można automatycznie wyłączać zasoby w godzinach nocnych. Dzięki temu zespoły mogą szybko reagować, wycofywać nieudane zmiany i utrzymywać platformę w zgodzie z celami biznesowymi i budżetowymi.

Co to oznacza dla zespołów telekomunikacyjnych

W przypadku projektów migracyjnych takie podejście pomaga uniknąć niespodzianek i zapewnia efektywne wykorzystanie zasobów. Przy budowie nowych platform eksperymenty z różnymi usługami Azure często pokazują, że zestaw mniejszych, dobrze skoordynowanych komponentów może dać lepszy efekt niż jedno duże i kosztowne rozwiązanie.

Kluczem jest odpowiednie zarządzanie i automatyzacja. Bez tagowania, alertów kosztowych i kontroli budżetu wydatki mają tendencję do niekontrolowanego wzrostu. Z kolei z tymi mechanizmami koszty pozostają przewidywalne, a usprawnienia osiągnięte w trakcie migracji czy budowy utrzymują się w czasie.

Jak pomaga Business Reporting Solutions

W Business Reporting Solutions dbamy o to, aby platformy danych dostarczały realną wartość biznesową, a nie tylko wynik techniczny. Pomagamy organizacjom projektować, budować i utrzymywać środowiska BI, które są niezawodne, skalowalne i opłacalne. Nasze doświadczenie obejmuje pełną ścieżkę pracy z danymi: od strategii i architektury, przez raportowanie i automatyzację, po bieżące wsparcie i optymalizację.

Co najważniejsze, pracujemy jako partner. Niezależnie od tego, czy chodzi o migrację do chmury, nową platformę BI, czy też dopracowanie już istniejącej, naszą rolą jest pomaganie zespołom w maksymalnym wykorzystaniu ich danych.