#TeamSpeednet: Leszek, DevOps
Poznajcie Leszka, DevOpsa, który od lat wspiera rozwój innowacyjnych rozwiązań, automatyzując procesy i dbając o efektywność zespołów w Speednet. W tej rozmowie opowiada o swojej pracy, codziennych wyzwaniach, ulubionych technologiach i tym, co daje mu największą satysfakcję zawodową.
Jak długo pracujesz w Speednet i czym się zajmujesz?
Leszek: W Speednet pracuję od 7 lat, przy czym podzieliłbym ten okres na dwa etapy, które różniły się rolą oraz zakresem moich obowiązków. Przez pierwsze cztery lata byłem administratorem IT wewnątrz firmy. Odpowiadałem za naszą wewnętrzną sieć, infrastrukturę IT w biurze, jak i wszystkie narzędzia wspierające rozwój oprogramowania takie jak np. środowiska dla deweloperów.
Natomiast od trzech lat jestem w pełni zaangażowany w projekt dla klienta zewnętrznego, co oznacza, że nie zajmuję się już naszą wewnętrzną infrastrukturą czy innymi projektami wewnętrznymi. Moje obecne obowiązki skupiają się wyłącznie na zarządzaniu infrastrukturą klienta. Zmiana ta przyniosła kilka istotnych różnic. Pracując wewnętrznie, często musiałem równolegle zajmować się wieloma projektami, co generowało sytuacje konfliktowe. Każdy projekt miał swoje pilne potrzeby, a podział czasu bywał wyzwaniem. Obecnie skupiam się na jednym projekcie, co pozwala lepiej organizować pracę, mimo że nadal trzeba ustalać priorytety dla różnych zadań.
Plus teraz zupełnie nie martwię się o infrastrukturę fizyczną. W Speednet mamy swoje serwery lokalne i różne urządzenia sieciowe, które wymagają stałego nadzoru. Natomiast w moim obecnym projekcie wszystko działa w chmurze i zdecydowanie bardziej mi to odpowiada.
Czym rola DevOpsa różni się od pracy admina czy programisty? Jakie są Twoje główne obowiązki?
Leszek: Z perspektywy Speednet, rola DevOpsa polega przede wszystkim na automatyzacji procesów wspierających wytwarzanie oprogramowania. Programiści, aby móc efektywnie tworzyć kod, potrzebują odpowiedniej infrastruktury, narzędzi, środowisk testowych oraz miejsca, gdzie mogą wdrażać i testować swój kod. Moim zadaniem jako DevOpsa jest właśnie zapewnienie, by te procesy były maksymalnie zautomatyzowane i intuicyjne, co pozwala programistom być bardziej samowystarczalnymi. Dzięki temu nie muszą na każdym etapie swojej pracy zwracać się do administratora, abym coś im wgrał, zaktualizował czy przygotował. Automatyzacja sprawia, że np. po wgraniu kodu do repozytorium uruchamiają się automaty, które sprawdzają go pod kątem błędów, wdrażają na środowisko testowe, a w razie potrzeby nawet tworzą to środowisko.
Natomiast w kontekście klienta, tam również jest wytwarzanie oprogramowania, ale trochę w inny sposób. Klient posiada swoje wewnętrzne aplikacje, które muszą działać na środowiskach spełniających odpowiednie wymagania (bezpieczeństwa, dostępności itp.). Moim obowiązkiem jest dbanie o te środowiska. Zapewnienie, że działają sprawnie, są odpowiednio skonfigurowane i maksymalnie zautomatyzowane. Celem jest umożliwienie użytkownikom wewnętrznym samodzielnego zarządzania swoimi aplikacjami w tych środowiskach w sposób jak najmniej angażujący zespół DevOps.
Warto tutaj podkreślić różnicę pomiędzy administratorem a DevOpsem w klasycznym znaczeniu tego słowa. Administrator zazwyczaj konfiguruje systemy ręcznie, korzystając z interfejsów czy paneli zarządzania. DevOps natomiast działa w oparciu o metodologię „infrastruktury jako kod” (IaC). Zamiast ręcznego klikania w panelach, opisuje infrastrukturę w postaci kodu, definiuje konfigurację i stan środowiska w narzędziach, które następnie automatycznie wdrażają tę konfigurację. W ten sposób tworzy i zarządza infrastrukturą za pomocą kodu. Mimo że pisze kod, aby opisać stan infrastruktury, nie jest to klasyczne programowanie w rozumieniu pracy programisty.
Jakie narzędzia i technologie najczęściej wykorzystujesz w swojej pracy?
Leszek: Obecnie korzystam wyłącznie z narzędzi i środowisk dostarczonych przez klienta. Dlatego cała moja praca skupia się na środowisku chmurowym AWS. To właśnie na AWS oraz Kubernetesie opiera się większość moich zadań. Są to dwa kluczowe elementy infrastruktury, którą zarządzam. Platforma, którą obsługuję dla klienta, służy do uruchamiania aplikacji i bazuje na tych technologiach.
Do monitorowania i zarządzania Kubernetesem korzystam z narzędzia LENS. Wdrażanie aplikacji odbywa się w metodologii gitops przy użyciu ArgoCD. Infrastrukturą zarządzam wykorzystując Continuous Deployment z użyciem GitLab Pipelines. Jeśli chodzi o zarządzanie konfiguracją usług w chmurze AWS, używam AWS Cloud Development Kit (CDK), który umożliwia definiowanie infrastruktury w formie kodu. W CDK pracuję głównie w języku Python, a do pisania kodu używam edytora Visual Studio Code.
Zaczynając pracę w tym projekcie, musiałem nauczyć się obsługi niektórych nowych narzędzi, zwłaszcza związanych z AWS. Kubernetes oraz GitLab Pipelines były mi wcześniej znane, ale część specyficznych narzędzi do zarządzania AWS była dla mnie nowością.
Jakie wyzwania napotykasz w pracy i jak sobie z nimi radzisz?
Leszek: Jednym z najczęstszych wyzwań są problemy komunikacyjne. Dotyczy to głównie użytkowników platformy, którą zarządzam. Oprócz rozwijania platformy świadczymy również wsparcie dla jej użytkowników, którzy zgłaszają różne pytania lub problemy. Często opisują je w sposób bardzo ogólny, np. „nie działa mi aplikacja XYZ”, co z naszej perspektywy nie dostarcza wystarczających informacji do zdiagnozowania problemu. W takich sytuacjach staramy się zadawać szczegółowe pytania, aby zrozumieć, na czym dokładnie polega problem. Zdarza się również, że sami posługujemy się zbyt technicznym językiem, co może być niezrozumiałe dla użytkownika. Staramy się wtedy unikać żargonu i tłumaczyć techniczne kwestie w sposób prosty i przystępny.
Drugim wyzwaniem jest ograniczony dostęp do informacji, co wynika z charakteru pracy dla dużej korporacji. Obszary odpowiedzialności są tam ściśle podzielone, a my jako administratorzy platformy często nie mamy dostępu do pewnych elementów, np. związanych z łącznością sieciową. Może to rodzić problemy – gdy coś nie działa, a my nie mamy wglądu w to co dzieje się w warstwie sieciowej lub gdy jakiś ruch jest blokowany. W takich sytuacjach często jesteśmy zmuszeni do domyślania się przyczyn problemu.
Taka sytuacja staje się szczególnie trudna w przypadku awarii w warstwach infrastruktury, które wpływają na działanie naszej platformy. Użytkownicy zgłaszają wtedy problemy, natomiast z naszej perspektywy platforma działa poprawnie, ponieważ mamy ograniczone pole widzenia. W takich przypadkach musimy współpracować z innymi działami, aby zidentyfikować źródło problemu i znaleźć rozwiązanie.
Jak wygląda Twój typowy dzień? Czy istnieje coś takiego jak “typowy dzień”?
Leszek: Trudno mówić o „typowym dniu” w pełnym tego słowa znaczeniu, ponieważ każdego dnia pojawiają się inne spotkania i tematy do załatwienia. Mogę jednak wskazać pewne stałe punkty, które powtarzają się codziennie.
Zazwyczaj dzień zaczynam od przyjazdu do biura, ponieważ większość czasu pracuję stacjonarnie. Po uruchomieniu komputera sprawdzam plan spotkań na dany dzień, żeby zaplanować sloty czasowe na realizację zadań. Następnie przeglądam komunikatory i e-maile, aby upewnić się, czy od mojego wyjścia z biura dnia poprzedniego nie wydarzyło się nic pilnego. Nasi klienci pracują w różnych strefach czasowych, dlatego czasami pojawiają się wiadomości poza naszymi godzinami pracy. Jeśli coś wymaga natychmiastowej interwencji, zajmuję się tym od razu. W przeciwnym razie kolejnym punktem jest kawa.
Po kawie skupiam się na standardowych zadaniach, jakie mam przydzielone w sprincie. W międzyczasie mam też jakieś spotkania, średnio są to 1-2 spotkania dziennie, ale zdarzają się też te ad hoc, wynikające z bieżących potrzeb. Do takich powtarzających się zadań dodałbym jeszcze przegląd kodu (code review) kolegów z zespołu i tzw. gaszenie pożarów, czyli szybka reakcja na awarie i problemy, które mogą pojawić się nagle i wymagają natychmiastowego działania. Od czasu do czasu zdarzają się również większe zadania, jak np. aktualizacja wersji Kubernetesa na platformie, co powoduje cały łańcuszek działań. Jednak zadania tego typu pojawiają się średnio raz w miesiącu, zwłaszcza w przypadku aktualizacji krytycznych komponentów.
Co sprawia Ci największą satysfakcję w pracy?
Leszek: Największą satysfakcję sprawia mi budowanie rozwiązań od podstaw. Mam na myśli projektowanie od strony architektury jakiegoś rozwiązania, potem jego implementacja. Cieszę się, jeśli mam namacalny efekt końcowy w postaci jakiegoś narzędzia, usługi czy rozwiązania, które trafia do użytkowników i ułatwia im codzienną pracę. Przeważnie taki kreatywny projekt pojawia się raz na kwartał i pracuję nad nim przez około miesiąc.
Wspomniałeś, że w większości pracujesz z biura, opowiesz, dlaczego wybierasz biuro, a nie pracę zdalną?
Leszek: Głównym powodem jest chyba higiena zdrowia psychicznego. Podczas pandemii pracowałem z domu i ciężko było mi rozgraniczyć pracę od życia prywatnego, zachować pewien balans. Za dużo było tzw. przeszkadzajek. Mogłem zająć się milionem innych rzeczy, a nie pracą. Natomiast jak jestem w biurze, to zajmuję się robotą. Dodatkowo lubię spotkać się z ludźmi i wypić dobrą kawę z naszego ekspresu. Jest to mój taki poranny rytuał.
Oprócz tego, że pracujesz jako DevOps, jesteś również DJ-em i zdarzało Ci się grać na kilku firmowych imprezach. Którą z imprez wspominasz najlepiej i dlaczego?
Leszek: Zdecydowanie najlepiej wspominam nasz bal zimowy, który odbył się w Starym Maneżu. Było to wyjątkowe wydarzenie, ponieważ wystąpiłem tam w dwóch rolach: jako wokalista i DJ. To duże przeżycie móc stanąć na scenie, na której występowały największe polskie gwiazdy. Dodatkowo miałem okazję zobaczyć, jak wygląda backstage takiego klubu i współpracować z profesjonalną ekipą nagłośnieniowców.
Moja część DJ-ska była nieco mniej rozbudowana, czułem lekki stres, ale jednocześnie ogromną satysfakcję z możliwości wzięcia udziału w takim wydarzeniu.
