Badania pokazują, że programiści zmieniają pracę średnio co 2 lata. U Ciebie na liczniku w Piwik PRO już prawie 6 lat i działamy dalej! Zajrzyjmy zatem za kulisy – co Cię tu trzyma?
Poczucie, że mam wpływ na to, co dzieje się w firmie oraz świetni ludzie, z którymi mam tutaj przyjemność pracować. Duże znaczenie ma też dla mnie możliwość obcowania z wieloma interesującymi technologiami, takimi jak Kubernetes, Terraform czy ClickHouse – dzięki temu mam stały impuls do rozwoju.
Twoja historia w Piwik PRO miała kilka zwrotów akcji…
Tak, zaczynałem jako Python developer w firmie-siostrze Piwik PRO, Clearcode, potem pracowałem nad modułami Audience Managera i Analyticsa już w Piwiku PRO. Przez zainteresowanie CI/CD oraz release engineeringiem współpracowałem dużo z naszymi zespołami DevOps, po jakimś czasie zmigrowałem do jednego z nich.
Który z tych momentów był z perspektywy czasu dla Ciebie najbardziej przełomowy?
Wydaje mi się, że decyzja o przejściu do zespołu DevOps. Zacząłem spotykać się z problemami, których istnienia nie byłem świadom jako programista. Weźmy tutaj jako przykład problemy z replikacją bazy danych MySQL. Wiedziałem, jak programować zapytania SQL, natomiast nie miałem pojęcia na temat tego, w jaki dokładnie sposób działa synchronizacja pomiędzy serwerami bazy danych. W nowej roli musiałem się tego nauczyć, dzięki czemu jestem też lepszym programistą.
W pracy nad produktem kluczem do sukcesu jest współpraca między zespołami, a Twoja historia jest żywym przykładem, jak może ona działać w praktyce. Opowiedz o tym.
Kiedyś pijąc kawę w kuchni, usłyszałem dyskusję znajomych adminów z innego zespołu. Martwili się brakiem nacisku na automatyzację pewnych kwestii związanych z aktualizacjami naszego produktu, ale nie do końca wiedzieli, jak sobie z tym problemem poradzić. W tym czasie byłem Python developerem w zespole rozwijającym produkt, więc miałem umiejętności, dzięki którym byłem w stanie im pomóc. Wykorzystałem mechanizm Pet Projectów (kilka godzin w tygodniu do przeznaczenia na projekty własnego pomysłu, które w jakiś sposób przysłużą się celom firmy) i po kilku tygodniach miałem gotowy Proof of Concept rozwiązania, które automatyzowało bolączki ręcznych aktualizacji.
Na PoC się jednak nie skończyło…
To prawda, pomysł przyjął się tak dobrze, że dostałem dodatkowe dwie osoby do pomocy i przez kilka miesięcy pracowaliśmy wspólnie nad przekuciem PoCa w projekt, który będzie można produkcyjnie używać. Zebraliśmy wymagania, przeczesaliśmy dokumentację wszystkich aktualizacji, które były przeprowadzone do tej pory, zaplanowaliśmy automatyzację testów i zaczęliśmy kodzić.
Pomimo dość szalonego tempa, projekt zakończył się sukcesem. Mechanizm, który wtedy zaproponowaliśmy, jest używany do aktualizacji produktu do dziś. Warto tutaj dać szerszy kontekst pracy w Piwik PRO – nie mamy jednego środowiska produkcyjnego, a kilkadziesiąt. Każde z nich może różnić się sprzętem, środowiskiem uruchomieniowym, wymaganiami bezpieczeństwa. Dlatego wprowadzenie modelu deploymentu opartego o np. CD nie jest trywialnym problemem, nie mówiąc już o tym, że sama aplikacja nie jest jeszcze na to gotowa.
Po zakończeniu projektu na pewien czas wróciłeś do jednego ze stałych składów DevOpsowych. Po pewnym czasie jednak zaproponowano Ci poprowadzenie kolejnego tematu i tym sposobem stanąłeś na czele nowego zespołu. Jak doszło do jego powstania i czym się zajmujecie?
Obecnie moim zadaniem jest zaprojektowanie oraz implementacja frameworka zarządzania deploymentem, konfiguracją i aktualizacjami. Ma on nadawać się do użycia na wielu różnorodnych środowiskach – jednej maszynie wirtualnej lub laptopie, klastrze on-premises czy w chmurach Azure lub AWS z wykorzystaniem natywnych usług, które wchodzą w ich skład. Obecnie dużym problemem jest dla nas mnogość opcji konfiguracyjnych, które są udostępniane przez nasz produkt i utrzymywanie dla nich scenariuszy testowych. Zadaniem moim i mojego zespołu jest ułatwienie codziennej pracy osobom prowadzącym wdrożenia i maintenance środowisk produkcyjnych. Dbamy przy tym o zachowanie elastyczności konfiguracji produktu oraz o to, aby wszystkie konfiguracje, w których udostępniamy produkt klientom, były odpowiedniej jakości.
Pozostaje nam jeszcze jedna zagadka do rozwiązania. Nieformalna nazwa Waszego zespołu to…
Promil.
Rzuć na to trochę światła!
No cóż, nazwa świeżo uformowanego zespołu została wybrana w plebiscycie, w którym mogli brać udział wszyscy pracownicy firmy, co chyba mówi trochę o upodobaniach naszej kadry (śmiech).
Jesteś też zaangażowany w rozwój Ferajny DevOps w Piwik PRO. Co to za inicjatywa i do kogo jest skierowana?
Ferajny to inicjatywa wewnątrz Piwika PRO, która umożliwia pracownikom zbieranie się wokół interesujących ich tematów i rozwijanie swoich pasji. Spotkania, które organizowaliśmy wewnętrznie w ramach ferajny o tematyce DevOps, w pewnym momencie osiągnęły na tyle wysoki poziom merytoryczny, że poczuliśmy się w stanie wyjść z nimi na zewnątrz i przypiąć swoją pinezkę na meetupowej mapie Wrocławia. Niestety po pierwszej publicznej edycji wybuchła pandemia, co przerwało na jakiś czas nasze spotkania. W marcu udało nam się wewnętrznie wskrzesić inicjatywę i ponowne otwarcie się na publikę z zewnątrz to tylko kwestia czasu.
“Każdy członek zespołu ma kontekst, wpływ i znaczenie” – tak rzecze nasze Employee Value Proposition. Spójrzmy na nie od strony praktycznej. Jakie działania są dla Ciebie dowodem, że to hasło nie jest u nas tylko pustym frazesem?
Przykładów jest wiele. Co kwartał organizowane jest spotkanie podsumowujące naszą pracę, w którym uczestniczą wszyscy pracownicy – przed pandemią odbywało się w kinie, obecnie zdalnie. Przedstawiany tam jest stan finansów firmy, omawiane są decyzje, które wpłynęły na ten stan i prezentowane pomysły na przyszłość.
Mamy też wiele mechanizmów, dzięki którym możemy wystartować i rozwijać oddolne inicjatywy, np. wspomniane wyżej Pet Projecty czy Ferajny. Jest też nasza nowa inicjatywa – Piwik PRO SIGs, czyli grupy osób zainteresowanych rozwojem konkretnych wąskich obszarów w ramach naszego produktu. Dla przykładu SIG Security zajmuje się zarządzaniem bezpieczeństwem na poziomie organizacji, a SIG Kubernetes koordynuje implementację Kubernetesa na różnych platformach wspieranych przez nasz produkt. Przynależność do SIGów jest dobrowolna, dzięki czemu ich członkami są pasjonaci danego tematu. Bardzo fajnym mechanizmem są też publiczne sprint reviews. Raz na dwa tygodnie wszyscy w firmie wciskamy pauzę i przyglądamy się temu, co wytworzyły inne zespoły, często zgłaszając uwagi czy sugestie.
Kto Twoim zdaniem się u nas odnajdzie?
Osoby przejawiające inicjatywę, z pasją do pracy, ciągłej nauki, ale też dobrej zabawy.
