Ericsson kojarzy się z telefonami komórkowymi sprzed ery telefonów. W rzeczywistości jest to firma, która działa w sektorze komunikacyjnym od prawie 150 lat, dzisiaj budująca i obsługująca sieci mobilne. Z naszych produktów korzystają miliardy ludzi na całym świecie, choć nie zawsze wiedzą, kto je wyprodukował.
Klientami dla Ericssona są operatorzy sieci, a nie użytkownicy telefonów. Szukając sposobów na optymalizację pracy, korzystamy z innowacyjnych narzędzi takich jak sztuczna inteligencja. Poniżej opisuję to, jak wykorzystujemy uczenie maszynowe w praktyce.
Pracuję w obszarze GSM, czyli pierwszej spopularyzowanej technologii komórkowej, rozwijanej od początku lat 90. Sieć 2G nie tylko zapewnia zasięg słabo zurbanizowanym obszarom świata, ale także w centrach wielkich miast, gdzie nadaje równolegle do 4G oraz 5G, żeby zapewnić działanie bankomatom, terminalom płatniczym czy choćby połączeniom głosowym, gdy wyższe technologie nie są w stanie ich obsłużyć.
Praca z tak dojrzałym produktem ma swoją specyfikę. Zakupiło i wdrożyło go wielu klientów. Codziennie obsługuje on miliardy użytkowników, co oznacza, iż stabilność działania jest krytycznie ważna. Nie możemy pozwolić sobie na błędy, które mogłyby skutkować odcięciem połowy kraju od dostępu do sieci, a w konsekwencji dostępu do telefonów alarmowych czy gotówki.
Rozwój produktu, a zwłaszcza dużych funkcjonalności, diametralnie wpływających na jego działanie, nie jest już tak dynamiczny, jak dekadę temu (choć może nie powinienem tego pisać, biorąc pod uwagę to, co akurat szykujemy do wypuszczenia). Większość ludzi została przerzucona do wyższych technologii, które są na innym etapie rozwoju. Stosunkowo niewielkie zasoby ludzkie (porównując z sytuacją choćby sprzed pięciu lat) oznaczają, iż dostarczeń kodu jest mniej. Nie zmienia to jednak faktu, iż każde z nich trzeba jak najdokładniej przetestować przed dostarczeniem kolejnego kawałka funkcjonalności.
Dostarczanie kodu
Zespoły zachęcane są do sukcesywnego dostarczania kodu. Nikomu nie jest jednak na rękę masowe dostarczanie, które nazywam big bang, w piątek po południu. Zbyt duża liczba „zakolejkowanego” kodu do testu na ograniczonej liczbie serwerów oznacza, iż będą wykonywały się długo. A każde z nich potencjalnie zawiera krytyczny błąd, który może skończyć się niepowodzeniem dla kolejnych w sekwencji.
Dlatego kolejne dostawy kodu spływają sukcesywnie przez cały tydzień. Z reguły obejmują zmiany w pojedynczych blokach lub grupach bloków kodu, a nie całe gotowe funkcjonalności, dotykające wielu obszarów działania centrali. Podczas dostarczania, deweloper powinien oznaczyć, na jakie obszary miał wpływ. Czy zmiany dotyczyły zarządzania komórkami sieci, zestawianiem połączeń głosowych, ruchu pakietowego, a może ograniczały się jedynie do dokumentacji. To tylko kilka przykładów tzw. Impact Area.
Typowa kampania testowa
W tym miejscu warto wspomnieć, jak wygląda kampania testowa. Zespoły deweloperskie przed dostarczeniem wykonują testy funkcjonalne nowego kodu. Natomiast po dostarczeniu wykonują się automatyczne test suity, utrzymywane przez organizację Continous Integration (CI).
Testy są podzielone na kilka etapów, nazywanych promotion level. Pierwszy mówi o tym, czy kod w ogóle się kompiluje, czy unit testy przechodzą. Następnie sprawdzane są najbardziej podstawowe funkcjonalności w grupie testów nazywanej First Feedback. To jest dopiero pierwszy promotion level, który daje informację czy software nadaje się do ładowania na centrale w laboratorium.
Drugi promotion level (PL2) zaczyna się od sprawdzania, czy stare funkcjonalności (Legacy) działają na nowym kodzie. Następnie uruchamiane są: krótki Stability Test oraz pakiet negatywnych testów (Robustness), który sprawdza odporność systemu na zdarzenia zaburzające działanie centrali.
Dopiero tak przetestowany software możemy uznać za stabilny. W teorii mógłby zostać posłany do klientów, jednak w praktyce jest to dopiero kwalifikacja do bardziej długotrwałych i skomplikowanych testów pogrupowanych w kolejne dwa promotion levele. Tam testowane jest zachowanie centrali pod dużym obciążeniem, długotrwałe stability, ze sprawdzeniem charakterystyk. Testowane jest także zachowanie bez symulatorów, gdzie prawdziwe jest wszystko od telefonu komórkowego po sieć szkieletową.
