Testowanie na produkcji przez lata było w IT czymś, do czego mało kto chciał się oficjalnie przyznać. Samo hasło wielu osobom kojarzy się z wrzucaniem nieprzetestowanego kodu i liczeniem, że „użytkownicy sami sprawdzą”. Tylko że rzeczywistość nowoczesnego developmentu wygląda dziś zupełnie inaczej. Największe firmy technologiczne świata regularnie testują na produkcji i robią to całkowicie świadomie. Netflix, Google, Meta czy Amazon od dawna budują swoje procesy właśnie wokół kontrolowanego wdrażania zmian na prawdziwych użytkownikach. Jak padło w podcaście „Porozmawiajmy o IT”, problem polega głównie na tym, że środowisko testowe nigdy nie będzie produkcją.
Można mieć staging, QA, testowe bazy danych i najbardziej rozbudowane pipeline’y CI/CD, ale prawdziwe środowisko użytkownika zawsze zachowa się inaczej. Inny ruch, inne obciążenie, inne dane, cache, load balancery czy konfiguracje sieciowe. W teorii wszystko działa poprawnie. W praktyce dopiero produkcja pokazuje, jak aplikacja zachowuje się pod realnym obciążeniem. I właśnie dlatego wiele błędów pojawia się dopiero po wdrożeniu. Nie dlatego, że ktoś nie testował, ale dlatego, że pewnych scenariuszy zwyczajnie nie da się wcześniej przewidzieć.
Ogromne znaczenie mają też same dane użytkowników. Dane testowe są zwykle uporządkowane i przewidywalne. Produkcja wygląda zupełnie inaczej. Tam pojawiają się nietypowe przypadki, stare rekordy, dziwne konfiguracje i zachowania, których żaden tester wcześniej nie odtworzył. W podcaście pojawił się świetny przykład użytkownika, który kliknął nową funkcję kompletnie inną ścieżką niż zakładał developer. Sama funkcjonalność działała poprawnie, ale sposób użycia okazał się totalnie nieoczywisty. I właśnie dlatego prawdziwi użytkownicy często są najlepszymi testerami systemu.
To jednak nie oznacza chaosu. Dobre testowanie na produkcji opiera się na konkretnych mechanizmach bezpieczeństwa. Jednym z podstawowych są feature flagi, czyli możliwość włączania i wyłączania nowych funkcji bez deployowania kolejnej wersji aplikacji. Dzięki temu, jeśli coś zaczyna się psuć, reakcja może być praktycznie natychmiastowa. Drugim ważnym podejściem są Canary Releases. Zamiast udostępniać nową funkcję wszystkim użytkownikom jednocześnie, trafia ona najpierw do małej grupy. Jeśli monitoring nie pokazuje problemów, rollout rozszerza się dalej. Właśnie tak działa dziś większość dużych platform technologicznych.
Dobrym przykładem są zmiany layoutu Facebooka sprzed kilku lat. Nowy interfejs nie pojawił się nagle u wszystkich użytkowników. Najpierw trafiał do wybranych osób, które mogły dodatkowo wrócić do starego widoku. Podobnie działały początki Gmaila, gdzie konto można było założyć wyłącznie przez zaproszenie. Z jednej strony był to świetny marketing, a z drugiej kontrolowany sposób rozwijania usługi na ograniczonej grupie użytkowników.
Oczywiście testowanie na produkcji ma też swoją ciemną stronę. Największym zagrożeniem są problemy z bazą danych i tzw. zatrucie danych produkcyjnych. Kod można wycofać. Feature flagę można wyłączyć. Ale jeśli nowa wersja systemu zapisze błędne dane albo uszkodzi część rekordów, sytuacja robi się znacznie poważniejsza. Szczególnie wtedy, gdy część użytkowników działa już na nowej wersji, a część nadal korzysta ze starej. Dochodzą do tego problemy z cache, wydajnością czy konfliktem wielu feature flag działających jednocześnie. Im bardziej rozbudowany system, tym większe ryzyko, że jakaś kombinacja scenariuszy nie została wcześniej przewidziana.
Mimo wszystko branża IT coraz wyraźniej pokazuje, że kontrolowane testowanie na produkcji nie jest oznaką braku profesjonalizmu. Wręcz przeciwnie. To często jedyny sposób, żeby realnie sprawdzić zachowanie systemu, zebrać feedback od użytkowników i uniknąć większych problemów po pełnym wdrożeniu.
Jeśli chcesz lepiej zrozumieć, jak wygląda testowanie na produkcji od kuchni, jakie są największe pułapki i jak robią to doświadczone zespoły IT, koniecznie przesłuchaj cały odcinek podcastu „Porozmawiajmy o IT” #315.