Krzysztof:
To jest 315 odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT Solid Jobs, który mam przyjemność

Krzysztof:
współtworzyć, dyskutujemy o błędach, wpadkach i fuck-upach w IT. Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. Odpalamy! Cześć Łukasz.

Łukasz:
Cześć Krzysztofie.

Krzysztof:
Kontynuujemy serię podcastów o fuck-upach w IT, a dzisiaj będziemy rozmawiać o tym, co każdy robi w ukryciu i trochę boi się o tym mówić, czyli o testowaniu na produkcji. No w sumie jak ktoś troszkę w IT posiedział i nie testował na produkcji, to mam wrażenie, że chyba jeszcze mało widział. Zaczniemy jednak, bo każda od tego, żeby powiedzieć, czym to testowanie na produkcji właściwie jest.

Łukasz:
Testowanie na produkcji to jest technika, czyli takie narzędzie programistyczne, trochę o narzędziach programistycznych już mówiliśmy, no i wydaje mi się, że bardzo źle nazwana, bo się źle kojarzy. Może się wydawać, że chodzi o to, że po prostu nie testujemy przed wrzuceniem czegoś na produkcję i wrzucamy nieprzetestowany kod i oczekujemy, że za nas userzy przetestują nasze nowe funkcjonalności. Natomiast jak najbardziej nie o to chodzi, To jest złe skojarzenie, no i tego typu działanie to jest taki typowy IT fuck-up. Dzisiaj chciałbym, żebyśmy przybliżyli naszym słuchaczom, czym właściwie jest testowanie na produkcji, jak do tego podejść. Czy spotkaliście się z czymś takim jak testowanie na produkcji? Oczywiście spotkaliście się, ale nawet nie wiedzieliście, że to jest to, No bo takim przykładem testowania na produkcji na przykład w branży gier komputerowych są beta testy, czyli udostępnienie po prostu produkcji jakiejś zamkniętej grupie użytkowników, ale już w takich warunkach produkcyjnych na prawdziwych serwerach dla po prostu szerszej grupy odbiorców. I inny teraz coraz bardziej popularny także w branży gier sposób testowania na produkcji, no to są po prostu early accessy, które są, nie cieszą się zbyt dobrą sławą. No i może właśnie to jest przykład, gdzie to testowanie na produkcji jest zrobione nie tak, jak powinno, niezgodnie ze sztuką. Dzisiaj trochę więcej o tym opowiemy, ale to jest nie tylko domena gier komputerowych, no bo testują na produkcji najwięksi giganci SaaS, tacy jak, Meta, Netflix, Google i inni. Przykład, całkiem niedawno, a może to już było pięć lat temu, a po prostu nam się tutaj czas tak dobrze przyzpieszył.

Krzysztof:
Tak.

Łukasz:
Idzie do przodu, no to Facebook wprowadzał nowy, nowy layout. No i tego nowego layoutu jakby nie było tak, że wszyscy nagle dostali z dnia do dzień nowy layout, tylko najpierw część użytkowników dostała ten nowy layout. Też była możliwość opt-in i opt-out. Mogłeś wybrać, żeby jeśli nie podobało Ci się to, co widzisz, mogłeś wybrać jeszcze na początku, żeby korzystać ze starego wyglądu aplikacji. No i to jest właśnie typowy przykład testowania na produkcji.

Krzysztof:
Jak rozumiem dajesz rozgrzeszenie, tak? Można testować na produkcji, to wcale nie jest nic złego, w niektórych sytuacjach wręcz jest to zalecana technika.

Łukasz:
Tak, no i może przejdźmy właśnie do tego, dlaczego chcemy testować na produkcji, dlaczego nie możemy, my niedobrzy deweloperzy, programiści, dlaczego nie możemy tego wszystkiego zrobić jeszcze na etapie developmentu po stronie jakby zespołu, tylko chcemy, żeby przerzucić chcemy przerzucić te testy na środowisko produkcyjne no to myślę, że najważniejszym tutaj punktem jest to, że po prostu środowisko testowe, stagingowe. Deweloperskie, one są po prostu inne niż środowisko produkcyjne. To są, zawsze są różnice między środowiskami, choćby w tym, jaki jest wolumen danych, jakie jest obciążenie, jaki ruch. Też nie oszukujmy się, nigdy nikt nie wyda tych samych pieniędzy, żeby taki serwer testowy postawić, jakie pieniądze są wydawane na serwer produkcyjny. Może inne są cache’e, Inaczej działa dostęp z zewnątrz. Jest też zazwyczaj na różny sposób ograniczony, zablokowany. Także te środowiska są po prostu różne i dlatego nigdy się nie dowiemy jak to będzie wychodzić. Rzeczywiście dana funkcja działać lokalnie w stosunku do tego, jak dana funkcja działa już na produkcji.

Krzysztof:
Innym powodem, dlaczego chcielibyśmy testować na produkcji są dane. Nawet jeśli postawimy sobie jakieś środowisko testowe deweloperskie, to ono zazwyczaj jest w jakimś stopniu jałowe. W sensie możemy jakieś dane testowe sobie tym skryptem powiedzmy wrzucić, ale to zawsze będą jakieś tylko określone porcje danych. To nigdy nie będzie tak zróżnicowane, jak już dobrze wygrzane środowisko produkcyjne, gdzie ta różnorodność danych jest. Jak jest jakiś błąd do zweryfikowania, do zdebugowania, no to nieraz dosyć trudno jest te dane odtworzyć na przykład w środowisku testowym, takim powiedzmy deweloperskim, natomiast w tym produkcyjnym mamy bezpośrednio dostęp i często okazuje się, że tylko tam możemy znaleźć ten błąd, czy go poprawnie zdebugować, bo po prostu trudno jest w sposób taki wiarygodny te dane jeden do jeden zweryfikować.

Łukasz:
Tak, i właśnie te dane użytkownika to jest jedna strona medalu, a druga strona medalu to ta infrastruktura, o której już wspomniałem przed chwilą. Czyli produkcja często korzysta z różnych rodzajów cache’u, z systemów CDN, load balancerów, jakiejś konfiguracji sieciowej, która po prostu jest nieodtwarzalna, albo koszty po prostu odtworzenia tego byłyby na tyle… Duże, że to się po prostu nie opłaca.

Krzysztof:
Tak, poza tym to, co już wspomniałeś, chcemy dostać feedback od realnych użytkowników, którzy nie będą zbiosowani, spaczeni, tak jak testerzy, którzy oczywiście mają jakiś tam swój sposób testowania, swoje podejście, określone procedury wykonują, ale dobrze wiemy, że użytkownicy są często w tym lepsi, więc chcemy uzyskać realny feedback nie tylko na temat potencjalnych bugów, ale też tego, czy coś lepiej funkcjonuje, tak wspomniany przez Ciebie layout,

Krzysztof:
czy jakaś nowa funkcjonalność. Wszystko to w wykonaniu, czy wydaniu właśnie testowania na produkcji i poproszeniu jawnym, bądź też niejawnym użytkowników o testy, to jest doskonały sposób do zebrania feedbacku, albo jak użytkownicy klikają, w co klikają, czy to jest coś, co realizuje naszą potrzebę biznesową, no wszystko to możemy właśnie poprzez testowanie na produkcji sobie zrealizować.

Łukasz:
Testerzy tak naprawdę dorastali z naszym oprogramowaniem, widzieli kolejne etapy, kolejne kroki, kolejne zmiany, no i przez to są po prostu jakoś tutaj, użyję brzydkie słowa, zbajasowani. Ja pamiętam właśnie taką sytuację, że robiłem kiedyś pewną funkcję, przeklikiwałem ją 50, 100, 200 razy. Po czym dałem tą funkcję użytkownikowi do użycia i co za pierwszym razem zupełnie inaczej przeklikał takim po prostu workflowem, na który ja bym nigdy nie wpadł, bo to nie był oczywisty sposób dojścia do tej funkcji. Akurat w tym przypadku wszystko zadziałało, ale mimo wszystko byłem nieźle zdziwiony, że tak można. Liczba testerów, których mamy w zespole jest skończona. Nigdy nie jest tak, że mamy nieskończoną liczbę testerów, nieskończoną ilość czasu też na testy, także to nigdzie nie jest tak, że tester wyłapie 100% błędów w oprogramowaniu, natomiast mimo wszystko deployując taką funkcję na produkcję uzyskujemy efekt skali. Jeśli dobrze będziemy monitorować, o czym też za chwilę, jeśli dobrze będziemy monitorować co się dzieje na produkcji z tą nową funkcją, to zyskujemy po prostu… Efekt skali i to, że pokrycie po prostu wszystkich możliwych scenariuszy.

Krzysztof:
Innym rodzajem testu na produkcji, chociaż ja tutaj bardziej wolę określenie eksperymentem, są testy AB, czyli próba sprawdzenia, która z wersji layoutu, funkcjonalności, sposobu działania w jaki sposób zachowuje się lepiej. Częściu użytkownikom serwujemy jedną funkcjonalność, jeden layout, a innym drugą i porównujemy jakieś miary, jakieś KPI, żeby ten eksperyment dał nam odpowiedź na pytanie, co działa lepiej, którą wersję przejąć później jako tą obowiązującą.

Łukasz:
Tak, no to jest także to, o czym wspominaliśmy przed chwilą, że testerzy są gdzieś tam w projekcie od początku i oni są przyzwyczajeni do pewnych funkcji, do pewnych rzeczy, wiedzą, że tak musi być, a użytkownik widzi daną funkcję może po raz pierwszy

Łukasz:
albo po raz drugi i ma zupełnie inne spojrzenie, świeże.

Krzysztof:
Tak, no i nasza branża wypracowała już kilka podejść, technik czy też taktyk do tego, żeby właśnie w sposób taki sensowny, rozważny, z głową przeprowadzić testy na produkcji, więc co ty na to, żeby teraz o tych metodach porozmawiać?

Łukasz:
Podstawą testowania na produkcji jest koncepcja feature flagów, czyli taki flag chyba, to możemy tak powiedzieć po polsku. Tak, flag przełączników. Przełączników, które pozwolą nam w łatwy, szybki sposób bez konieczności deploya. Nowej wersji, po prostu włączenie lub wyłączenie danej funkcjonalności i dzięki temu, jeśli coś pójdzie nie tak, jesteśmy w stanie szybko zareagować. W jaki sposób jeszcze możemy zapewnić bezpieczeństwo takich testów? No to oczywiście nie robimy tego tak, że wrzucamy tą nową funkcję dla wszystkich użytkowników, tylko stosujemy tak zwany canary releases, czyli kanarkowe wydania. Ograniczamy po prostu dostęp do tej nowej funkcji lub zmienionej funkcji tylko do wybranej części użytkowników. Czyli nie jest tak, że wszyscy dostają tą nową funkcję naraz. Stosujemy tu jakiś plan i robimy to przyrostowo. Tu myślę o, jeśli chodzi o strategię dobierania użytkowników, to możemy jeszcze porozmawiać w kolejnej części tej rozmowy. Problemem może być przy takim uruchamianiu lub wyłączaniu danej funkcji, że włączenie takiej funkcji może ze sobą coś nieść. Na przykład, nie daj Boże, migrację danych. I teraz…

Łukasz:
Problem jest taki, czy stara i nowa wersja będą tak samo dobrze działać z na przykład bazą danych, czy tutaj jakieś nie będzie mismatcha, który spowoduje to, że nasz system po prostu przestanie działać albo, co moim zdaniem jest lepsze, wbrew pozorom, niż to, że będzie działać źle i serwować niepoprawne wyniki do użytkowników.

Krzysztof:
Tutaj dodałbym jeszcze, że istnieje już całkiem sporo takich rozwiązań czy technik DevOpsowych, które nam ułatwiają robienie tych rzeczy związanych i z Canary Releases i z Feature Flags, więc to nie jest coś, co musimy tutaj odkrywać na nowo, różnych frameworków, różnych narzędzi DevOpsowych jest całkiem sporo do wyboru. Warto jest pewnie tworząc migracje bazodanowe myśleć właśnie o tym, że być może będzie taka konieczność, żeby ten rollback dokonać i baza danych musi wrócić do jakiegoś poprzedniego stanu i czy to jest możliwe, czy nie. Oczywiście, w idealnym świecie zawsze w praktyce okazuje się, że nie wszystkie migracje bazodanowe da się cofnąć, natomiast przynajmniej trzeba być świadomym, że robimy coś takiego, żeby później nie okazało się, że budzimy się z ręką w nocniku.

Łukasz:
Jakie mogą być inne powody testowania na produkcji? Powód może być taki, że chcemy dać po prostu użytkownikowi jakąś sprawczość,

Łukasz:
jakąś możliwość wypowiedzenia się, dania nam feedbacku. To też trochę się łączy z tymi testami AB, ale też chcemy zbudować jakieś uczucie sprawczości u tego użytkownika, sprawić, żeby poczuł się wyróżniony, No i budować takie przywiązanie do marki. I w takim przypadku możemy taką funkcję sprzedawać jako Exclusive i dać ją tylko wybranej części użytkowników. Jakąś tutaj formą właśnie wdrażania, to jest fajna forma wdrażania nowych funkcji albo wręcz nowych usług. i tutaj świetnym przykładem jest Gmail. Nie wiem, czy pamiętasz Krzysztofie, na początku nie było tak, że mogłeś sobie założyć nowe konto na Gmailu, tylko musiałeś dostać zaproszenie.

Krzysztof:
Ekskluzywne zaproszenie.

Łukasz:
Ekskluzywne zaproszenie, tak. I w ten sposób ci użytkownicy tutaj wiązali się z tą marką, czuli się wyróżnieni, dzięki czemu jakby zyskiwaliśmy marketingowo po prostu w ten sposób. Jest to strategia marketingowa, tak sobie możemy powiedzieć. Pewnie ważną tutaj rzeczą jest to, żeby też zawsze dać temu użytkownikowi w ramach tego uczucia sprawczości możliwość też wycofania się, jeśli chcemy, żeby on testował, no to dajmy mu też możliwość właśnie powrotu do poprzedniej wersji danej funkcjonalności. Oczywiście nie dotyczy, jeśli to jest nowa funkcjonalność, ale tak, ważne moim zdaniem jest to, żeby ten użytkownik mógł po prostu wybrać no i teraz skoro chcemy od tego użytkownika zbierać jakieś opinie no to musimy też dać mu szansę wyrazić tą opinię, więc fajnie mieć też w systemie jakiś system, feedbacku, jakieś okienkę, no bo nie oszukujmy się, jeśli poprosimy, napiszcie do nas maila, no to nikt nie napisze tego maila. Więc to muszą być jakieś zachęty w systemie, jakieś wyskakujące okienka, może to trochę też przesadziłem, ale po prostu jakieś. Wyróżnione elementy interfejsu, które pozwolą w łatwy sposób wyrazić opinię, najlepiej jednym, dwoma klikami, podoba się, nie podoba, a w razie, jeśli ktoś będzie miał ochotę wyrazić trochę więcej, uwag, no to opcjonalne pola tekstowe, gdzie ktoś po prostu wpisze swoje żale lub pomysły. I to też buduje wtedy w tym użytkowniku przywiązanie i to uczucie takie, że jest insiderem, a nie outsiderem. Zachęcam.

Krzysztof:
Tak, tak, jest na pewno nie tylko techniczne podejście do tego problemu, ale potencjalnie może nam przynieść dużo korzyści. Niestety od tego, jaką tutaj metodę czy w jaki sposób będziemy chcieli wykorzystać, to nie możemy zapomnieć o kilku takich podstawowych fundamentach. Zdecydowanie nie możemy pominąć kwestii monitoringu i telemetrii, żeby wiedzieć co się dzieje. Żeby mieć oko na to jak nowa funkcjonalność, którą wprowadzamy się zachowuje, czy czegoś nie psuje, czy nie musimy w jakiś sposób tego rollbacku dokonać. Jeśli decydujemy się na Canary Releases, no musimy mieć pod ręką przygotowany jakiś automatyczny lub półautomatyczny sposób na docieranie z tą nową funkcjonalnością do kolejnej, najczęściej większej grupy użytkowników, więc taki plan do kogo, albo może inaczej, jaka grupa powinna otrzymać tą nową funkcjonalność musi być gotowy. Podstawą, jeśli decydujemy się na to, żeby faktycznie części użytkownikom pokazywać nowe funkcjonalności, jest to, żeby ich odpowiednio dobrać, tak jak tutaj Łukasz wspomniałeś, myślę, że to jest też osobny wątek, który warto dzisiaj poruszyć. No i posługiwać się różnymi automatami, które będą w stanie szybciej niż ludzkie oko wykryć, czy coś pod maską się nie zaczyna psuć i być może zatrzymać ten release dla kolejnych grup, albo wręcz dokonać automatycznego rollbacku. Wszystko to wymaga oczywiście jakiegoś przygotowania, ale może nam zaoszczędzić

Krzysztof:
masę problemów, jeśli to faktycznie ten release następuje i jakieś problemy zaczynają występować.

Łukasz:
Czyli co, teraz trochę Krzysztofie może o problemach.

Krzysztof:
Bo takie na pewno będą. Tutaj mnóstwo rzeczy może oczywiście się gdzieś tam wysypać, jeśli posługujemy się cashem, a to się bardzo często dzieje. Zresztą podobny problem może wystąpić też z różnymi schematami danych, niezależnie czy jest to baza danych, czy jest to powiedzmy jakiś tam Redis być może, też różne kolejki i tak dalej. Musimy być świadomi, że jeśli… Ingerujemy w jakiś sposób w to, co ten schemat już zastany, w jakiś sposób go zmieniamy, a będziemy chcieli dokonać później wycofania tego nowego kodu, no to te stare schematy nam zostają. Ten stary kod po wycofaniu musi sobie jakoś z tym poradzić, więc to jest też coś, co być może da się przetestować, da się wręcz sprawdzić, czy to będzie dobrze działało. Bo warto sobie na to zerknąć. Problemy związane, po raz kolejny ten temat przywołujemy, z dobraniem odpowiedniej grupy użytkowników, czyli zależy nam, żeby ta grupa zawierała osoby, które faktycznie będą w stanie tą funkcję użyć, coś tam poklikać więcej niż tylko powierzchniowo i być może zgłosić nam jakiś feedback.

Łukasz:
To ja tutaj może wejdę Ci w słowo i trochę opowiem o tym, jak można by wybrać taką grupę użytkowników. Potem płynnie może wrócimy do problemów. To może jeszcze zanim, to jedna ważna uwaga, jeśli mamy podział użytkowników na tych, którzy dostali tą nową funkcję i jej nie dostali, no to musimy też w jakiś sposób powiązać tą wersję z użytkownikiem. Nie może być tak, że przy każdym requestie, przy każdym odświeżeniu strony na przykład dostaje inny layout strony, bo to będzie słaby user experience, a problemy tutaj, jeśli mamy na przykład wiele serwerów, jakieś load balancery i właśnie cache na różnych poziomach, no to tego typu problemy mogą się zdarzyć, więc trzeba bardzo ostrożnie, do tego podchodzić. To teraz tak, jak możemy wybrać grupę użytkowników? Pierwszy sposób to jest taki, że po prostu najpierw wybieramy użytkowników insajderów, swoich. Czyli przykładowo u nas na SolidJobs nową funkcję najpierw dostają pracownicy SolidJobs.

Krzysztof:
DocFooding to się chyba nazywa, tak?

Łukasz:
Możliwe, że tak, natomiast DocFooding wydaje mi się, że to jest dedykowane środowisko, jakby wewnętrzne, albo my tak zawsze na to mówiliśmy, czyli właśnie taka wersja wewnętrzna systemu tak, no to, DocFooding, ale tak, no może można to po prostu jakby inny aspekt tego samego rozwiązania. W przypadku dogfoodingu to my zawsze robiliśmy tak, żeby po prostu była osobna instancja aplikacji. Ale może tutaj się mylę i może to można rozwiązać właśnie w taki sposób.

Krzysztof:
Pewnie na kilka sposobów to można rozwiązać. Chodzi o to, żeby wewnętrznie na przykład zacząć korzystać z nowej funkcjonalności, żeby zabrać taki insight wewnętrzny, zanim to gdzieś tam puścimy w świat.

Łukasz:
Tak, no i to jest pierwszy sposób, gdzie możemy wybrać użytkowników. Kolejny sposób, no to ten sposób na elitarność i na tych early adapterów. Po prostu jest jakaś grupa użytkowników, którzy chcą dostawać nowe funkcje, którzy chcą testować, którzy są tak zwanymi właśnie early adapterami. No i albo w jakiś sposób musimy wiedzieć, kto to jest, albo po prostu możemy dać taki opt-in i wyświetlić użytkownikom możliwość właśnie tej. Cały czas będę używać tego przykładu, bo on jest po prostu prosty, czyli zmiana layoutu na nowy. Jest po prostu przycisk zmień layout i dostajesz nowy layout aplikacji. Inny sposób to geolokalizacja. To jest też dość czysty sposób bym powiedział. Czyli na początku nową funkcję dostają użytkownicy z na przykład Polski. A dopiero potem użytkownicy z Europy, a potem na cały świat serwujemy nową funkcję. Jest to jakieś podejście, które gdzieś tam pewnie zależy od naszej infrastruktury. Jeśli mamy właśnie osobne serwery, które coś serwują właśnie w danej geolokalizacji. No to jest to dość czysty sposób. Natomiast pewnie problemem tutaj jest to, że dość duża jest ta grupa użytkowników. No i, ale podobny sposób to jest na przykład, jeśli mamy aplikację multitenantową, czyli załóżmy każdy klient ma swoją bazę danych lub też albo swój serwer, albo jakaś taka wersja hybrydowa pośrednia. Ja na przykład w jednej z poprzednich firm to mieliśmy taką sytuację, że na jednym serwerze aplikacyjnym było tam 10-20 klientów i każdy miał swoją bazę danych nowa wersja zawsze wchodziła pierwszego dnia na jednym serwerze badaliśmy, monitorowaliśmy nie było telefonów, no to następnego dnia dostawał kolejny serwer. Wszystko było ok, to następnego dnia cztery kolejne, wszystko ok, następnego dnia trzydzieści kolejnych, wszystko ok, no to już puszczamy do wszystkich.

Łukasz:
Czyli takie rolowanie tej wersji do coraz szerszego grona odbiorców. No tak, no i to są z grubsza takie koncepcje, jak można tych użytkowników wybrać. Wróćmy może tutaj do problemów. Co Krzysztof jeszcze tutaj?

Krzysztof:
Przyszedł jeszcze jeden potencjalny problem. W momencie, kiedy mamy różne featurey, nawet zakryte właśnie feature flagami, czy też właśnie canary releases, kiedy części użytkownikom serwujemy jedną funkcjonalność albo jakąś tam pierwszą wersję, a innym drugą, no to musimy być świadomi tego, że niezależnie od tego, jaki kod, że tak powiem, obsługuje dany request na przykład od użytkownika, to zawsze pod spodem jest jedna baza danych, która musi być na tyle odporna, żeby te różne wersje obsłużyć nie tylko jeśli chodzi o schemat, ale też o wyizolowanie tych danych. Musimy to zapewnić i z tym z całą pewnością się zderzymy, zwłaszcza jeśli właśnie te featurey nam tutaj coś zmieniają w schemacie danych.

Krzysztof:
Prędzej czy później możemy się na tym przejechać.

Łukasz:
Ok, to myślę, że jeszcze możemy takie dwie koncepcje testowania na produkcji przedstawić. Są to koncepcje dark launchingu i shadow trafiku. I na czym te koncepcje polegają? Duplikujemy po prostu logikę. Jednocześnie działa stara wersja i nowa, natomiast użytkownik nie jest tego świadomy i użytkownik dostaje dane serwowane ze starej wersji systemu, natomiast gdzieś tam w tle coś się wylicza także na nowej wersji i na przykład porównujemy to. Jakiś przykład może podam? To tak, nowe wersje e-maili ostatnio zrobiliśmy w Solid Jobs, takich e-maili dla kandydatów po zakończeniu procesu rekrutacji z takim automatycznym feedbackiem. I co w pierwszej wersji? Użytkownicy dostawali maile takie, jak dostawali, natomiast te maile w nowym layoutie i z nowymi danymi wysłaliśmy na swój prywatny adres e-mail i sprawdzaliśmy, czy jest wszystko ok, czy to wygląda dobrze, czy się nic nie rozjeżdża. I dopiero wtedy, po dwóch, trzech dniach, jak stwierdziliśmy, że wszystko jest okej, no to przepiliśmy tych właściwych użytkowników na właściwego nowego maila.

Krzysztof:
Ja to często obserwuję w momencie, kiedy, znaczy często, może nie często, ale jest to dobra taktyka w momencie, kiedy robimy jakiś na przykład refaktor albo zmieniamy sposób działania jakiegoś algorytmu. Wtedy możemy sprawdzić, czy dane serwowane po tej zmianie są przynajmniej mocno podobne do tej pierwotnej, żeby zobaczyć, czy może coś nam nie umknęło, o czymś nie zapomnieliśmy. Mamy możliwość zweryfikowania, czy feature po zmianach nadal działa poprawnie.

Łukasz:
Jeszcze pewnie pewną taką najbardziej wysokopoziomową, wysokopoziomowym sposobem na testowanie na produkcji, To jest po prostu puszczenie dwóch systemów jednocześnie. I mamy stary, nowy system. Część użytkowników korzysta z nowego, część ze starego. Dane gdzieś są zsynchronizowane w tle. Pewnie nie jest to zbyt przyjemne, żeby to utrzymać. I w ogóle to jest cały osobny projekt, żeby w ogóle coś takiego zrobić. Ale potrafię sobie wyobrazić, że na przykład migrujemy jakiś system rządowy albo finansowy. Bankowy, tak. ze starej wersji na nową no i wtedy to po prostu działają dwa systemy niezależnie, że oba robią to samo i gdzieś jest jakaś bramka, nazwijmy to, która porównuje, czy na pewno co do setnego miejsca po przecinku te wyliczenia są takie same.

Krzysztof:
Tak, z pewnością są różne zastosowania właśnie tej koncepcji.

Krzysztof:
Ok, powiedzieliśmy o tych technikach, za pomocą których da się testować na produkcji. Wspomnieliśmy chwilkę o potencjalnych problemach albo obszarach, na które trzeba zwrócić uwagę, ale oczywiście nie uchroni nas to przed różnego typu fuck-upami i wpadkami, które są z tym związane. No i tutaj taką pierwszą, o czym już kilka razy była mowa, jest to, że nam się baza danych po prostu rozjedzie, ponieważ wprowadziliśmy jakieś migracje, schemat się zmienił, no i okazuje się, że ten stary kodnik koniecznie sobie z tym radzi.

Łukasz:
Tak, oczywiście tutaj są różne techniki radzenia sobie z tego typu problemami, ale to myślę, że jest na tyle ciekawe i na tyle złożone, że możemy cały osobny odcinek kiedyś o tym nagrać.

Krzysztof:
Pewnie.

Łukasz:
To jest mój sposób na to, żeby powiedzieć, że akurat nie mam zielonego pojęcia, jak to zrobić. No, żartuję tu trochę, ale wracając do fuck upów, kolejny fuck up, zatrucie danych produkcyjnych. Czyli to, że odpaliliśmy tą nową wersję, po prostu ona działa źle i powoduje właśnie w danych odwracalne lub nieodwracalne straty, zmiany. Bym to połączył z problemem tej wersji kanarkowej, o której mówiliśmy, że puszczamy to tylko dla części użytkowników, ale to, że puściliśmy daną funkcję tylko dla części użytkowników, to nie znaczy, że ona nie wpłynie też na tych użytkowników, którzy korzystają ze starej wersji systemu, może po prostu tutaj być, jeśli nowa wersja, nie wiem, pisze danej funkcji, pisze albo, nie wiem, zwraca dane. Niepoprawnie, na przykład potrafiłbym sobie wyobrazić, że nowe query nie respektuje jakichś uprawnień albo właśnie wręcz zwraca dane dla złego użytkownika albo wprowadziliśmy jakieś dodatkowe cachowanie i ten cache powoduje to, że dostajemy dane cudze, nie swoje. No to mimo, że mieliśmy feature flagi, mimo, że mieliśmy te wersje kanarkowe to wpłynęło to na wszystkich użytkowników, nie tylko na tych, którzy korzystali z tej nowej wersji funkcji.

Krzysztof:
Tak, bo kod możemy sobie wycofać, schemat bazy możemy nawet cofnąć, ale te dane zostają. Nie zawsze możliwość zaaplikowania backupu nam tutaj zostaje, no bo chociażby tak jak wspomniałeś w Canary Releases, my tylko do części użytkowników zaaplikowaliśmy tą nową funkcjonalność, no i teraz zabawa z przywracaniem danych sprzed tej zmiany może być naprawdę niezła, więc to zatrucie danych produkcyjnych może być realnym problemem, z którym będziemy musieli żyć, nawet jeśli funkcjonalność, ta nowa, na przykład nowy feature, nowa wersja, już nie jest na produkcji.

Łukasz:
Tak, mówiliśmy tu też o shadow trafiku, czyli sytuacji, gdzie użytkownik dostaje dalej jakieś wyliczenia dane z tej starej wersji, a my tylko pod spodem coś robimy po nowemu. No i tutaj może być problem degradacji wydajności, mimo że użytkownicy nie korzystają z tej nowej funkcji, no to mogą to odczuć, bo na przykład nasze serwery zostały, czy tam wydajność bazy danych została tak dobrana, do obecnego naszego wolumenu użytkowników, wolumenu ruchu, a tu nagle podwajamy to wszystko. No i okazuje się, że któraś część systemu po prostu nie nadąża. Może to być właśnie takie jedno wąskie gardło, gdzieś jeden punkt, który powoduje, że całość po prostu puchnie, przestaje działać lub odpowiada bardzo wolno.

Krzysztof:
Tak. Wspomnieliśmy o feature flags jako o takim podstawowym podejściu do tego, żeby pewne funkcjonalności dla określonej grupy tylko użytkowników pokazywać i to jest oczywiście fajna metoda, ale problem pojawia się w momencie, kiedy mamy tych flag wiele, wówczas wpadamy w tak zwany feature flags hell, no bo jeśli powiedzmy jakaś tam funkcjonalność z feature flagą A działa poprawnie, z feature flagą B również działa poprawnie, To może się okazać, że już A i B nałożone na siebie powoduje jakieś nieoczekiwane efekty. No i też dla osób testujących, dla testerów, jeśli tych feature flag jest tam odpowiednio wiele, no to przetestowanie każdego możliwego układu jest mało realne. Są oczywiście frameworki, są wręcz zewnętrzne usługi, które nam pozwalają zarządzać tymi feature flagami, ale zawsze może się okazać, że jakiś tam wariant nie został sprawdzony, w jakimś tam wariancie coś nie działa i wtedy trzeba faktycznie nieźle się nagłówkować, żeby to znaleźć, więc jak gdyby oczywiście stosujmy te feature flagi, ale musimy to robić w takim zakresie, żeby to miało sens albo najlepiej z mojej praktyki, jeśli dana… Ten feature, ta funkcjonalność ma tam gdzieś jedną, powiedzmy, feature flagę na sobie, to wtedy da się to jakoś rozsądnie przetestować. Jeśli jest tam ich już więcej, no to może się pojawić potencjalny problem.

Łukasz:
Okej, Krzysztofie, myślę, że tutaj powoli dobijamy do brzegu. To co, krótkie podsumowanie?

Krzysztof:
Podsumowanko, róbmy tak.

Łukasz:
Podsumowanko, okej. No to dlaczego chcemy testować na produkcji? Dlatego po prostu, że produkcja to jest inne środowisko, które się inaczej zachowuje, nie środowisko, I zanim damy daną funkcję wszystkim użytkownikom, chcemy to w kontrolowany sposób, ograniczony też sposób sprawdzić na mniejszej grupie użytkowników. Chcemy także otrzymać od użytkowników feedback, poznać ich zdanie na przykład w formie testów AB. Chcemy także przetestować po prostu środowisko produkcyjne czy podoła tej nowej funkcji. Jakie są takie podstawowe elementy testowania na produkcji? No to te feature flagi, czyli możliwość włączenia lub wyłączenia danej funkcji, Canary Releases, czyli możliwość dania dostępu do danej funkcji po prostu coraz większej liczbie użytkowników i monitorowanie, telemetria, możliwość łatwego rollbacku.

Krzysztof:
FKP to pewnie przede wszystkim problemy z migracją bazy danych, to również problemy z zatruciem danych produkcyjnych, jeśli coś nie działa poprawnie, no i też możliwość wpadnięcia w problemy z nakładającymi się na siebie feature flagami, no i później konieczność przetestowania tych różnych możliwości, to nas łatwo może przyprawić obrój głowy.

Łukasz:
Tak, bardzo zgrabnie podsumowane myślę, dobra robota.

Krzysztof:
Dzięki, trochę szedłem na twoje buty, ale tak, mamy to.

Łukasz:
Mamy to, tak.

Krzysztof:
No właśnie, testowanie na produkcję, mimo tego, że obrosło trochę w mity, to okazuje się, że jest jak najbardziej legitną metodą, czy też sposobem na to, żeby pewne rzeczy sprawdzać, weryfikować, eksperymentować, udostępniać dla określonej grupy użytkowników. Na tym kończymy ten dzisiejszy odcinek. Zapraszamy też do wszystkich poprzednich z tej serii związanych właśnie z FACAP-ami w IT i również innych serii, których już trochę tutaj udało nam się z Łukaszem nagrać do tej pory. Zapraszamy na Solid Jobs, gdzie jak najbardziej testujemy na produkcji wcale się tego nie wstydzimy, tam możecie znaleźć mnóstwo ciekawych ofert pracy z IT i nie tylko.

Łukasz:
Powiem Ci, Krzysztofie, że tak wydaje mi się, że dopiero co zaczęliśmy nagrywać te odcinki, a już nagrywamy od 2023.

Krzysztof:
Tak, już tam pewnie z kilkadziesiąt się ich uzbierało.

Łukasz:
Ale to, co chciałem powiedzieć, to to, że wydaje mi się, że mało tych odcinków straciło gdzieś na, aktualności, także zachęcam też na wejście tutaj też na Solid Jobs, mamy taki landing, łamane na podcast, gdzie są pogrupowane odcinki w różne serie i zachęcam po prostu, żeby też przejrzeć te poprzednie odcinki, jeśli jeszcze nie odsłuchaliście.

Krzysztof:
Dokładnie, odsyłamy do Storyjobs łamane na podcast. Tam wszystkie poprzednie odcinki, więc teraz już nie macie wyłówki i koniecznie musicie je przesłuchać. A na dzisiaj zamykamy. Dzięki, Łukasz.

Łukasz:
Dzięki, cześć, do zobaczenia.