Voucherify pod maską: Tomek Sikora i jego ścieżka do stabilnej platformy

Jak trafiłeś do Voucherify? 

Choć dziś zajmuję się sprawami site reliability engineering, moje początki sięgają 2014 i pierwszych dni firmy. Na początku pracowałem przy projektach dla start-upów z zachodu. W pierwszych latach istnienia firmy uczyliśmy się, na czym polega tworzenie produktów od zera.

Dwa projekty, które zapadły mi w pamięć to Kisi i ShareIQ. Pierwszy, Kisi, dotyczył zamków keyless otwieranych za pomocą aplikacji mobilnej. ShareIQ z kolei to produkt, który pomagał między innymi wykrywać nieautoryzowane użycie zdjęć. Ich platforma crawlowała Internet i skanowała pliki graficzne, po czym autorski algorytm generował  z nich hash i identyfikował kopie (nawet, jeśli dane zdjęcie było edytowane, np. miało inne kolory czy było odbiciem lustrzanym). 

Platforma ta zbierała również informacje o tym kto pierwszy i gdzie zamieścił dane zdjęcie (np. na social media). ShareIQ tworzyło mapę dystrybucji, która pokazywała, gdzie dane zdjęcie było dalej udostępniane, przez kogo, na jakich portalach.

Klientami ShareIQ były np. globalne marki, które chciały dotrzeć do najbardziej wpływowych influencerów promujących ich produkty. Innym zastosowaniem było wykrywanie oszustów używających oryginalnych zdjęć do sprzedaży podróbek oryginalnego produktu. 

Produkt miał bardzo doświadczonych założycieli i nic dziwnego, że w ciągu jedynie dwóch lat został sprzedany gigantowi rynku monitorowania mediów, Cision.

Naprawdę szybki wzrost – co w tak dynamicznym projekcie najbardziej zapadło Ci w pamięci?

Trochę przewrotnie i na bardziej osobistym poziomie, jednym z najlepszych doświadczeń z ShareIQ była rekrutacja do ich zespołu. Zorganizowali 2-dniowy hackathon w Berlinie, na który mnie zaprosili. To był właściwie jedyny hackathon, po którym wróciłem z większą ilością energii niż przed wyjazdem.

Całe doświadczenie dopełnił piękny zachód słońca podczas lotu powrotnego.

Potem przyszła pora na pracę nad własnym produktem. Na czym polegała Twoja rola w pierwszych dniach budowania produktu?

Pierwsza wersja Voucherify powstała na podstawie pomysłu jednego z naszych klientów (więcej informacji w tym artykule). Szkielet zaczęliśmy budować na wewnętrznym hackatonie, w którym też wziąłem udział. Później włączaliśmy kolejnych programistów w rozwój platformy, ja dołączyłem do projektu około rok po hackatonie. Od razu zacząłem wtykać swoje palce wszędzie, gdzie się da. Budowałem back-end i architekturę softu, front-end i rozwijałem procesy deploymentu – w skrócie wszystko, co było potrzebne, żeby zgarniać nowych klientów i zadbać o to, żeby downtime nie spowodował, że anulują subskrypcję.

Szybko poczułem się częścią zespołu. Kiedy dołączyłem, firma była kilkuosobowa, większość ludzi już znałem z poprzednich projektów. Zżyty team przełożył się na sprawczość i szybkość w dostarczaniu od pierwszych dni – i tak zostało do dziś.

Co aktualnie robisz w Voucherify? 

Teraz zajmuję się głównie site reliability, czyli skalowalnością i stabilnością platformy. Moim celem jest zminimalizować nocne pobudki zespołu (kiedy trzeba resuscytować platformę i przywrócać ją do życia) i zapewnić skalowalność platformy, czyli rozwiązać potencjalne problemy z wydajnością zawczasu. 

Wymaga to w wielu przypadkach przepisywania i poprawiania obecnych rozwiązań, adresowania długu technicznego lub budowania skalowalnych rozwiązań w miejsce tego, co kiedyś zakodowaliśmy na szybko, po spartańsku.

Często pracujemy zaczynając od MVP i kiedy platforma ma większe użycie lub zastosowania danego rozwiązania są większe, dana funkcjonalność przestaje być wystarczająca i trzeba ją usprawnić. Jednym z usprawnień przez wielkie “U” było na przykład przejście z MongoDB na Postgres.

Większość developerów narzeka na dług techniczny i poprawianie “po innych”. Nie nudzi Cię taka praca? 

Narzekanie na pracę innych, bugi, kwiatki znalezione w kodzie, to codzienność developerów. Mnie też zdarza się jeszcze ponarzekać na pracę swoich kolegów (a także własną!) sprzed lat. Aczkolwiek, trzeba sobie zdać sprawę, że nigdy nie będzie tak, że ktoś napisze kod idealny, który będzie wspaniały, piękny, za którego dostanie Nobla, i którego nigdy nie trzeba będzie poprawić.

Z drugiej strony, pragmatyzm i budowanie szybkich rozwiązań ma sens. Nie warto od początku budować rozrośniętego rozwiązania, jeśli nie wiadomo jaka będzie skala, a jedyne co wiadomo to to, że klient potrzebuje danej funkcji na już. Koniec końców, najbardziej wartościowy kod to ten, który zarabia.

Ta sama zasada dotyczy infrastruktury, która powinna naturalnie rosnąć razem z rozwojem platformy. Nasza platforma na początku korzystała z samego Heroku, dopiero z czasem przenieśliśmy się na AWS.

W większości nasz dług techniczny i problemy nie są spowodowane “złym kodem”, choć bugi mogą zdarzyć się każdemu. Większość bugów (95% przypadków) wychodzi na code review. Pozostałe 5% wychodzi na produkcji. 

U nas dług techniczny głównie wynika z tego, jak rozwiązaliśmy dany problem wcześniej, a robiliśmy to pragmatycznie, tj. pokrywaliśmy tylko taką część funkcjonalności, żeby można było ją przetestować na produkcji i upewnić się, że jest przydatna dla klienta. 

Wcześniej takie rozwiązanie było wystarczające, teraz, ze względu na skalę i kaliber klientów, już nie jest.

Co masz w planach jako szef działu SRE?

Chciałbym nadal wpływać na rozwój platformy, celując w zadowalanie przyszłych klientów. Chciałbym rozwijać platformę dla skali, którą będziemy mieć w ciągu kilku miesięcy/lat. Mieć strategiczne podejście do rozwoju platformy, nie tylko rozwiązywać obecne problemy SRE i gasić pożary. Tak się składa, że przy 300 klientach i rosnącej liczbie requestów na minutę platforma wymaga ode mnie właśnie długofalowego planowania i przygotowania porządnej ochrony przeciwpożarowej.

Warto wspomnieć, że nasza platforma działa aktualnie w 6 różnych regionach (mamy na ten moment 14 klastrów). Ciągle udoskonalamy, ale jednocześnie staramy się upraszczać proces wdrażania nowych zmian na platformie oraz infrastrukturze.

Dlatego cały czas, od 5 lat, uczę się czegoś nowego – SRE to taka studnia bez dna (w pozytywnym sensie), miejsce, gdzie można zaspokoić kreatywność. 

Jakie było Twoje największe osiągnięcie w Voucherify? 

Z ostatnich osiągnięć było to zredukowanie obciążenia platformy i kosztu infrastruktury. Zoptymalizowaliśmy jedną kluczową funkcjonalność, segmenty klientów, które muszą być przeliczone raz lub kilka razy na dzień. 

Przeładowywanie segmentów, czyli wchodzenie i wychodzenie użytkowników z grupy charakteryzującej się jakimiś konkretnymi cechami, żeby pobrać informację o tym, do jakiego segmentu przynależą, to bardzo powolny proces. Im więcej danych, tym dłużej się to przeładowywało. W przypadku jednego z większych klientów, wykorzystujących Voucherify na bardzo dużą skalę, zajmowało to ponad dzień. Obecnie zajmuje to od kilku sekund do kilku minut.

Ruch wychodzący z jednej z maszynek, na której działają aplikacje:

Z jakimi problemami skali mierzycie się dzisiaj na platformie? 

Mamy dług techniczny, pozostałość po pierwszych latach szybkiego wzrostu, i wiele z nich musi być nadal rozwiązanych. Na przykład, autorski mechanizm kolejek, który działał fantastycznie i przez 5 lat pozwalał z łatwością zarządzać wiadomościami na kolejce, szybko dostarczać nowe funkcjonalności oraz iterować z istniejącymi, ale który powoli nas “kopie” przy obecnej skali.

Ponadto musieliśmy zmienić podejście do zapytań, normalizacji danych, przesyłania danych. Dlatego wdrażamy ElasticSearch, data caches na innych warstwach.

Główne wskaźniki, które próbujemy poprawić, to liczba requestów do naszego API oraz ich czas odpowiedzi. Skupiamy się głównie na percentylu 95 (~ 600ms), rzadziej na średnich czasach odpowiedzi. RPM, z którym się mierzymy, to średnio 1-1.5k w pojedynczym klastrze. Zdarzają się natomiast skoki typu 5k RPMów, które też obsługujemy.

Przy batchowych procesach po stronie naszych klientów skacze poziom IOPSów na naszych bazach, nieraz przekracza 4000 IOPSów. Z tego też powodu optymalizujemy zapytania, zmieniamy podejście do normalizacji i przesyłania danych. Wdrożyliśmy już ElasticSearch oraz data caches na innych warstwach.

Bardzo łatwo rozwiązać problem podbijając zasoby, my staramy się nie iść na skróty i wręcz pracujemy nad obniżeniem kosztów infrastruktury.

Co Ci się najbardziej podoba w pracy?

Zaangażowanie w projekt jest ogromne, za tym idzie zaufanie do kolegów. Mamy idealny zespół, bardzo zgrany, wspieramy się i uzupełniamy. Atmosfera pracy jest bardzo dobra. Lubię i cenię ludzi, z którymi pracuję – tylko tyle i aż tyle.  

A czy jest coś, co Cię uwiera?

Ciągły i bardzo dynamiczny wzrost bazy klientów oraz ich oczekiwań wymaga od samego początku iterowania wokół architektury. Mieliśmy dotychczas około 4 większych refactorów infra. Wdrażanie kolejnych zmian wymaga wielu kroków, tym bardziej, że w trakcie tego procesu zawsze staramy się zapewnić pełną dostępność platformy – nie akceptujemy wyłączenia API na kilka godzin. W praktyce to ciągle jest niezła gonitwa z nadążaniem za wymaganiami. Weźmy teraz pod uwagę, że mamy 14 klastrów. Staramy się unikać nowych procesów, idziemy raczej w kierunku podważania sensu istnienia lub upraszczania istniejących.

Zawsze byliśmy i jesteśmy krok z przodu, niemniej dla mnie osobiście to za mało. Chciałbym poczuć większą swobodę i mieć większy “zapas”. Na szczęście nasz zespół SRE rośnie w siłę.

Jak pracuje zespół SRE? 

Mamy elastyczne podejście. Sporo piszemy na Slacku. Zespół często zadaje pytania, dzieli się wiedzą. Najczęściej, jak są incydenty albo grubsze problemy to wchodzimy razem na calla, dyskutujemy, analizujemy i rozwiązujemy problem lub ustalamy kolejne action pointy. Długość rozmów zależy od problemu. Wszyscy są raczej zadowoleni z długości spotkań, patrząc na ich feedback po spotkaniach. U nas takie spotkania są bardzo produktywne, możemy coś szybko ustalić na callu. Z reguły na takim callu są deweloperzy, team leaderzy oraz CTO. Darek świetnie o tym opowiadał w swoim wywiadzie.

Cieszy mnie też to, że zarząd zawsze pyta nas o opinię w sprawach, które dotyczą nas lub naszej pracy. Wiemy, że nam ufają i że bierzemy udział w podejmowaniu decyzji.

Czy po kilku latach rozwijania platformy jest jeszcze coś, co Cię stresuje?

Najczęściej stres związany jest z incydentami, kiedy wyciągamy “wszystkie ręce na pokład” i działamy ad hoc. Najgorzej, kiedy platforma wysypie się w nocy. Nie mamy ustalonych dyżurów, ale jako że mamy osoby, które wolą pracować w godzinach wieczornych, zawsze znajdzie się ktoś, kto będzie w stanie postawić platformę na nogi. 

Stres i nawał pracy zależą od okresu, czasem nic się nie dzieje, czasem incydenty pojawiają się co tydzień. Na szczęście czasy zabierania laptopa na wakacje już minęły, bo zespół SRE dzisiaj to kilka osób, którym mogę w pełni zaufać.

Ale wciąż szukacie wsparcia – jakie kryteria są najważniejsze podczas rekrutacji do zespołu?

Dwie wartości, które widziałbym u każdego, z kim bym miał pracować, to umiejętność przyznania się do błędu (otwartość na krytykę) oraz chęć nauki. 

Chętnie pracuję z juniorami, chętnie dzielę się wiedzą i doświadczeniem. Technologia jest drugorzędna, najważniejsze żeby programista chciał i lubił robić to, co robi, i jak popełni błąd, to był otwarty na feedback.

{{CTA}}

Zobacz jak pracujemy w Voucherify

Dowiedz się więcej

{{ENDCTA}}