Testowanie na produkcji. Gość: Łukasz Drynkowski - POIT 315

Witam w trzysta piętnastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów o wpadkach w IT jest testowanie na produkcji.

Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.

Główne myśli o testowaniu na produkcji z tego odcinka to:

• czym naprawdę jest testowanie na produkcji i dlaczego nazwa bywa myląca
• dlaczego nawet najlepsi testerzy nie zastąpią realnych użytkowników
• różnice między środowiskami dev/test a produkcją (dane, skala, infrastruktura)
• rola rzeczywistych danych i nieprzewidywalnych zachowań użytkowników
• testy A/B jako kontrolowany eksperyment na produkcji
• feature flagi jako fundament bezpiecznego wdrażania zmian
• canary releases i stopniowe rolowanie funkcji na użytkowników
• mechanizmy rollbacku i wyzwania związane z migracją danych
• dark launching i shadow traffic jako sposób na weryfikację bez wpływu na usera
• znaczenie monitoringu, telemetrii i automatycznych systemów ochronnych
• strategie wyboru użytkowników (opt-in, geolokalizacja, tenant, pracownicy)
• typowe problemy i ryzyka: feature flag hell, degradacja wydajności, błędy w cache i “zatrucie” danych

Subskrypcja podcastu:

• zasubskrybuj w Apple Podcasts, Google Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
• poproszę Cię też o polubienie fanpage na Facebooku

Linki:

• Profil SOLID.Jobs na LinkedIn – https://www.linkedin.com/showcase/solid.jobs/
• SOLID.Jobs – https://solid.jobs/

Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/315

Transcript

SPEAKER_00 0:00

To jest 315 odcinek podcastu Porozmawiajmy IT, w którym w cyklu rozmów z Łukaszczem drękowskim z portalu z ogłoszczeniami pracy IT Stolid Jobs, który mam przyjemność współtworzyć, dyskutujemy o błędach, wpadkach i

Testowanie na produkcji

SPEAKER_00 0:13

facupach w IT. Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. Odpalamy. Cześć Łukasz, cześć Krzysztof. Kontynuujemy serię podcastów o fuck-pach 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. W sumie jak ktoś troszkę WT posiedział i nie testował na produkcji, to mam wrażenie, że chyba jeszcze mało widział. Zacznijmy jednak okaże od tego, żeby powiedzieć, czym to testowanie na produkcji właściwie jest.

SPEAKER_01 0:46

Testowanie na produkcji to jest technika, czyli takie narzędzie programistyczne, trochę 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 uzerzy przetestują nasze nowe funkcjonalności. Natomiast jak najbardziej nie o to chodzi? To jest złe skojarzenie. No i tego typu działania 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. 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 takim warunkach produkcyjnych, na prawdziwych serwerach, dla po prostu szerszej grupy odbiorców. Inny teraz, coraz bardziej popularny, także w branży gier, sposób testowania na produkcji to są po prostu early accesy, które są. Nie cieszą się zbyt dobrą sławą. No i może właśnie to jest przykład, że to testowanie na produkcji jest robione 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 SAS, tacy jak Meta, Netflix, Google i inni. Przykład całkiem niedawno, a może to już było 5 lat temu, a po prostu nam się tutaj czas tak dobrze. Przyspieszą tak. Idzie do przodu. No to Facebook wprowadzał nowy nowy laut, no i tego nowego laju jakby nie było tak, że wszyscy nagle dostali z dnia na dzień nowy laut, 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.

SPEAKER_00 3:40

Jak rozumiem, dajesz się rozgrzeszenie, tak? Można testować na produkcji, to wcale nie jest nic złego. W niektórych sytuacjach włączysz to zalecana technika.

SPEAKER_01 3:47

Tak, no i może przejdźmy właśnie do tego, dlaczego chcemy testować na produkcji, dlaczego nie możemy. My nie dobrzy deweloperzy, programiści, dlaczego nie możemy tego wszystkiego zrobić jeszcze na etapie dewelopmentu 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, jak i ruch. Też nie oszukujmy się, nigdy nigdy nie wyda tych samych pieniędzy, żeby taki serwer testowy postawić, jakie pieniądze są wydawane na serwer produkcyjny. Może inne są kasze, inaczej działa dostęp z zewnątrz, jest też zazwyczaj na różny sposób ograniczony, zablokowane, także te środowiska są po prostu różne i dlatego nigdy się nie dowiemy, jak to będzie rzeczywiście dana funkcja działać lokalnie w stosunku do tego, jak dana funkcja działa już na produkcji.

SPEAKER_00 5:20

Innym powodem, dlaczego chcielibyśmy testować na produkcji są dane. Wiesz, nawet jeśli postawimy sobie jakieś środowisko takie testowe, deweloperskie, to ono zazwyczaj jest w takim 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 też różnorodność danych jest. Jak jest, nie wiem, jakiś błąd do zweryfikowania, do zdagowania, 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 zdagować, bo po prostu trudno jest w sposób taki wiarygodny te dane jeden do jeden zweryfikować.

SPEAKER_01 6:17

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 cashów, 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.

SPEAKER_00 6:49

Tak, poza tym to, co już wspomniałeś, chcemy dostać feedback od realnych użytkowników, którzy nie będą bajesowani, 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, wspomniany przez ciebie layout, czy jakaś nowa funkcjonalność.

Feedback od użytkowników

SPEAKER_00 7:26

Wszystko to, w wykonaniu czy wydaniu właśnie testowania na produkcji i poprzeniu 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ą, wszystko to możemy właśnie poprzez testowanie na produkcji sobie zrealizować.

SPEAKER_01 7:49

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ę brzydkiego słowa, zbajasowani. Ja pamiętam właśnie taką sytuację, że robiłem kiedyś pewną funkcję, przeklikiwałem ją, nie wiem, 50, 100, 200 razy, po czym dałem tą funkcję użytkownikowi do użycia i co za pierwszym razem zupełnie inaczej przyklikał. Takim po prostu workflowem, na który ja bym nigdy nie wpadł, bo to nie był oczywisty po prostu 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ę terów, nieskończoną nieskończoną ilość czasu też na testy, także to nigdy 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 po prostu na produkcji z tą nową funkcją, no to zyskujemy po prostu efekt skali i to, że pokrycie po prostu wszystkich możliwych scenariuszy.

SPEAKER_00 9:31

Innym rodzajem testu na produkcji, chociaż ja tutaj bardziej wolę określenie eksperymentem, są testy AB, czyli próba powiedzmy sprawdzenia, która z wersji layoutu, funkcjonalności, sposobu działania, w jakiś sposób zachowuje się lepiej. Częście 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 towiązującą.

SPEAKER_01 10:07

Tak, no to jest także to, o czym wspominaliśmy przed chwilą, że te sterzy są gdzieś tam w projekcie od początku, i oni są przyzwyczajeni do pewnych funkcji, do pewnych rzeczy wiedzą, że tak musi być, no a użytkownik widzi daną funkcję może po raz pierwszy albo po raz drugi, no i ma zupełnie inne spojrzenie,

Podejścia do testowania

SPEAKER_01 10:31

świeże.

SPEAKER_00 10:31

Tak, no i nasza branża wypracowała kilka podejść, technik czy też tak 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ć.

SPEAKER_01 10:48

Podstawą testowania na produkcji jest koncepcja feature flagów, czyli takich flag chyba, to możemy tak powiedzieć po polsku. Flag przełączników, tak. Przełączników, które pozwolą nam w łatwy, szybki sposób bez konieczności diploya 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 zwane kanary 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ę na raz. Stosujemy tu jakiś plan i robimy to przyrostowo. To myślę o, jeśli chodzi o strategię dobierania użytkowników, to my możemy jeszcze porozmawiać w kolejnym tutaj w kolejnej części tej rozmowy. Problemem może być przy takim uruchamianiu lub wyłączaniu danej funkcji, że ona włączenie takiej funkcji może ze sobą coś nieść. Na przykład, nie daj Boże, migrację danych. I teraz 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 mi zmacza, które spowoduje to, że nasz system po prostu przestanie działać, albo co moim zdaniem, jest lepsze wrew pozorom, niż to, że będzie działać źle i serwować niepoprawne wyniki do użytkowników.

SPEAKER_00 12:50

Tej dodałbym, jeszcze, że istnieje już całkiem sporo takich rozwiązań czy technik DevOpsowych, które nam ułatwiają robienie tych rzeczy, tak, związanych i skanary, releases i 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 pazdenowe, myśleć właśnie o tym, że być może będzie taka konieczność, żeby ten rollback dokonać, tak? I baza danych musi wrócić do jakiegoś poprzedniego stanu, czy to jest możliwe, czy nie. Oczywiście, w idealnym świecie zawsze w praktyce okazuje się, że nie wszystkie migracje pazdonowe 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.

SPEAKER_01 13:43

Jakie mogą być inne powody testowania na produkcji? Powód może być taki, że chcemy dać po prostu użytkownikowi jakąś sprawczość, jakąś możliwość wypowiedzenia się, dania

Ekskluzywne funkcjonalności

SPEAKER_01 13:58

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ę jako sprzedawać jako ekskluz, 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. Eskluzywne zaproszenie. Ekluzywne zaproszenie, tak. I w ten sposób ci użytkownicy tutaj wiązali się z tą marką, czuli się wyróżnieni. Dzięki czemu 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ł, 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ś okienka. 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 tu trochę też przesadziłem, ale po prostu jakieś wyróżnione elementy interfejsu, które pozwolą w łatwy sposób wyrazić opinie. 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, czy 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.

SPEAKER_00 16:51

Tak, tak, jest na pewno nie tylko techniczne podejście do tego problemu, ale potencjalnie może nam przynieść dużo korzyści. Niezależnie od tego, jaką tutaj metodę, czy 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, tak ż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 kanale Releases, 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, wiedzieć, czy coś pod miaską się nie zaczyna psuć i być może zatrzymać ten reeles dla kolejnych grup, albo wręcz dokonać automatycznego rollbacku. Wszystko to wymaga oczywiście jakiegoś przygotowania, ale może tam zaoszczędzić masę problemów, jeśli faktycznie ten reele zastępuje i jakieś problemy zaczynają

Problemy z testowaniem

SPEAKER_00 18:46

występować.

SPEAKER_01 18:47

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

SPEAKER_00 18:49

Bo takie na pewno będą. Tutaj mnóstwo rzeczy może oczywiście się gdzieś tam wysypać, tak, jeśli posługujemy się kaszem, 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ż zastanie, w jaki sposób go zmieniamy, a będziemy chcieli dokonać później wycofania tego nowego kodu, 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ć, to da się wręcz sprawdzić, czy to będzie dobrze działało, warto sobie na to zerknąć. Problemy związane z 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.

SPEAKER_01 20:09

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. Pewnie. To może jeszcze za nim 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 recuście, 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ś balansery i właśnie casze 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 insiderów swoich, czyli przykładowo u nas na Solid Jobs nową funkcję najpierw dostają pracownicy Solid Jobs.

SPEAKER_00 21:22

Dogfooding to się chyba nazywa, tak? Ta technika?

SPEAKER_01 21:25

Możliwe, że tak. Natomiast dogfooding wydaje mi się, że to jest dedykowane środowisko jakby wewnętrzne, bo my tak zawsze na to mówiliśmy, czyli właśnie taka wersja wewnętrzna systemu. Tak, ten Dokwooding. Ale tak, może można to po prostu inny aspekt tego samego rozwiązania. W przypadku Dokwoodingu, to my zawsze robiliśmy tak, że po prostu była osobna instancja aplikacji. Ale może tutaj się mylę i może to można rozwiązać.

SPEAKER_00 22:01

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 zebrać taki insight, tak, wewnętrzny, zanim to gdzieś tam puścimy w świat.

SPEAKER_01 22:14

Tak, no i to jest pierwszy sposób, gdzie możemy wybrać użytkowników. Kolejny sposób, to w ten sposób na elitarność i na tych ear 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 e 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ść. Cały czas będę używać tego przykładu, bo on jest po prostu prosty, czyli zmiana layoutu na nowy, tak. Jest po prostu przycisk, zmieni laut i dostajesz nowy laut aplikacji. Inny sposób, no to geolokalizacja, jeśli mamy i 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, 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 podobny sposób to jest na przykład, jeśli mamy aplikację multitenantową, czyli załóżmy, każdy klient ma swoją bazę danych 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, nie wiem, 10-20 klientów i każdy miał swoją bazę danych. Nowa wersja zawsze wchodziła pierwszego dnia na przykład 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 30 kolejnych, wszystko okej, no to już puszczamy do wszystkich. Czyli takie rolowanie tej wersji do coraz szerszego grona

Wybór grupy użytkowników

SPEAKER_01 24:54

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 Krzysztofie jeszcze tutaj.

SPEAKER_00 25:04

Przyszedł mi jeszcze jeden potencjalny problem. Majencie, kiedy mamy różne feature, nawet zakryte właśnie feature flagami, czy też właśnie kanary releases, kiedy części użytkownikom serwujemy jedną funkcjonalizarzie albo jakąś tam pierwszą wersję, a innym drugą, no to musimy być świadomi tego, że niezależnie od tego, jaki kot, że tak powiem, obsługuje dane 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 jakby to zapewnić i z tym z całą pewnością się zderzymy, zwłaszcza jeśli właśnie te featery nam tutaj coś zmieniają w schemacie danych, prędzej czy później możemy się na

Koncepcje testowania

SPEAKER_00 26:01

tym przejechać.

SPEAKER_01 26:01

Okej, to myślę, że jeszcze możemy takie dwie koncepcje testowania na produkcji przedstawić i są to koncepcje dark launchingu i Shadow Traffiku. 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. 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 laycie i z nowymi dany, wysłaliśmy na swój prywatny adres e-mail, no i sprawdzaliśmy, czy jest wszystko okej, 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 ok, to przepiliśmy tych właściwych użytkowników na właściwego nowego maila.

SPEAKER_00 27:35

I ja to często obserwuję w momencie, kiedy często, może nie często, ale jest 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 czegoś tutaj nie coś nam nie umknęło, tak? O czymś nie zapomnieliśmy, mamy możliwość zweryfikowania, czy feature po zmianach nadal działa poprawnie na nim na tym.

SPEAKER_01 28:13

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ą synchronizowane 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 po prostu działają dwa systemy niezależnie. 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.

SPEAKER_00 29:13

Tak, z pewnością są różne zastosowania właśnie tej koncepcji. Okej, powiedzieliśmy o tych technikach, za pomocą których da się testować na produkcji.

Potencjalne fuck-upy

SPEAKER_00 29:23

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 kod niekoniecznie sobie z tym radzi.

SPEAKER_01 29:55

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ć. Pewnie. 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 fac-upów, kolejny facup, 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 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 kaszowanie i ten cash powoduje to, że dostajemy dane cudze, nie swoje. No to mimo, że mieliśmy feature flagi, mimo że mieliśmy te wersje kanerkowe, to wpłynęło to na wszystkich użytkowników, nie tylko na tych, którzy którzy korzystali z tej nowej wersji funkcji.

SPEAKER_00 31:41

Tak, bo kod możemy sobie wycofać schemat bazy możemy nawet cofnąć, ale te dane zostają. No nie zawsze możliwość zaaplikowania backupu nam tutaj zostaje. Chociażby tak jak wspomniałeś w kanale Releases, my tylko do części użytkowników zaplikowaliś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.

SPEAKER_01 32:22

Tak, mówiliśmy tu też o szado trafiku, czyli sytuacji, gdzie użytkownik dostaje dalej jakieś wyliczenia dane z tej stare 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 jakby naszego wolumenu użytkowników wolumenu ruchu, a tu nagle podwajamy to wszystko. I okazuje się, że któraś część systemu po prostu nie nadąża. Mo być właśnie takie jedno wąskie gardło. Gdzieś jeden punkt, który powoduje, że całość po prostu kuchnie przestaje działać lub odpowiada bardzo wolno.

SPEAKER_00 33:22

Tak. Wspomnieliśmy o feature Flags jako 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 flak wiele, wówczas wpadamy w tak zwany feature flag 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 tam 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 źle się nagłówkować, żeby to znaleźć. Więc jakby oczywiście stosujmy te feature flagi, ale musimy to robić w takim zakresie, żeby to miało sens, albo najlepiej jest w mojej praktyki, jeśli dana ten feature, dana 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ć potencjalne problemy.

SPEAKER_01 34:50

Okej, Krzysztofie, myślę, że tutaj powoli dobijamy do brzegu, to co? Krót podsumowanie?

SPEAKER_00 34:56

Podsumowanko róbmy, tak.

SPEAKER_01 34:58

Podsumowanko. Okej, no to dlaczego chcemy testować na produkcji? Dlatego po prostu, że produkcja to jest inne środowisko, które się inaczej zachowuje niż środowisko testowe. I zanim damy daną funkcję wszystkim użytkownikom, chcemy to w kontrolowany sposób, ograniczony też 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.

SPEAKER_00 36:03

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

SPEAKER_01 36:29

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

SPEAKER_00 36:33

Dzięki trochę przede na Twojej buty, ale tak, mamy to.

Zakończenie i podsumowanie

SPEAKER_01 36:37

Mamy to, tak.

SPEAKER_00 36:38

No właśnie, testowanie na produkcji, 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 fuck-upami 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.

SPEAKER_01 37:23

Powiem Ci Krzysztofę, że tak wydaje mi się, że dopiero co zaczęliśmy nagrywać te odcinki, ja już nagrywamy od 2023.

SPEAKER_00 37:33

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

SPEAKER_01 37:36

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 na Soli Jobs mamy taki landing łamany 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 odsyłaliście.

SPEAKER_00 38:06

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

SPEAKER_01 38:20

Dzięki, cześć, do zobaczenia.