DevOps w teorii i w praktyce. Jak wygląda praca DevOpsa? Wywiad z Pawłem Kantorem

Czym zajmuje się DevOps w teorii, a czym w praktyce? Jak wygląda typowy dzień w pracy DevOpsa? Jakie są największe wyzwania związane z tą rolą w IT? Opowiada nam Paweł Kantor, DevOps Engineer w KMD Poland.

Na początek: czym zajmuje się DevOps w teorii, a czym w praktyce? Jaka jest jego rola w firmie?

Sama nazwa DevOps powstała (jak pewnie większość może wiedzieć lub się domyślać) z dwóch angielskich słów: [Dev]elopment i [Ope]rations. No i w teorii osoba pracująca na tym stanowisku powinna łączyć pracę nad rozwojem produktu lub aplikacji z późniejszym jej utrzymaniem. 

Historycznie każda firma miała swój oddzielny dział Developmentu, który właśnie rozwijał produkty, tworzył aplikacje i robił testy wewnętrzne, a potem publikował na produkcji swoje dzieło i zapominał o nim. Wtedy pod opiekę brał ją dział Operations, który sprawdzał, czy aplikacja działa i czy klienci są zadowoleni. Niestety, jak pojawiały się jakieś błędy, były one spowodowane głównie tym, że Operations nie pisało tej aplikacji, więc ciężko im było odpowiedzieć klientom jasno i klarownie, co może być nie tak i gdzie może być jakiś błąd. Dlatego ważna jest rola DevOpsa, który powinien rozwijać aplikację/produkt od początku, wiedzieć, do czego on powstał, jak jest napisany i po wdrożeniu na środowisko łatwo powinien zdiagnozować problemy, które mogą powstać, ponieważ sam tę konfigurację pisał i robił. 

W firmie osoba na stanowisku DevOps jest właśnie odpowiedzialna za produkt od początku jego implementacji na środowisku, pomoc przy jej wdrażaniu (czasem nawet przy testach), a w końcu także za wypuszczenie jej produkcyjnie i monitorowanie, czy wszystko działa jak trzeba. Dzięki temu, że taka osoba wie, jak działa środowisko końcowe (produkcyjne) to podczas tworzenia tej aplikacji może pomagać innym zespołom przy tworzeniu produktu. DevOps wie, jakie będzie finalne środowisko, gdzie działa aplikacja i jaki może być wolumen danych.

Tyle w teorii, a jak to wygląda w praktyce? Z tego, co zauważyłem to główne założenia pracy DevOpsa są jak najbardziej widoczne – staramy się brać udział przy tworzeniu aplikacji. Oczywiście sami jej nie piszemy, jednak pomagamy developerom zrozumieć, z jakim środowiskiem mają do czynienia i jak komunikacja z innymi serwisami lub platformami powinna wyglądać. Następnie pomagamy przy wdrażaniu napisanej aplikacji najpierw na środowiska testowe i monitorowanie parametrów, które są krytyczne na środowisku produkcyjnym.

Z kim ściśle współpracują DevOpsi w swojej pracy?

Jak już wspomniałem, DevOps pracuje głównie z developerami aplikacji – oni piszą główną logikę aplikacji i tworzą całą funkcjonalność produktu, natomiast my pomagamy im tę aplikację skonteneryzować tak, aby mogła zostać wdrożona na środowisko chmurowe, które mamy u siebie. 

Zdarza się też, że pracujemy z innymi DevOps’ami w celu integracji wielu środowisk lub też po prostu wymieniamy się doświadczeniami już zdobytymi, np. jak dany produkt został wdrożony, najlepsze metody zabezpieczeń, jakie alarmy monitorujące środowisko czy po prostu ponownie użyć już istniejących rozwiązań, aby na nowo nie wymyślać koła 🙂

Developer aplikacji, Architekt oprogramowania czy DevOps. Co łączy te stanowiska?

Można powiedzieć, że wszystko i nic 🙂 Developerzy aplikacji tworzą aplikację, piszą jej funkcje, dokładają nowe funkcjonalności i utrzymują kod. Architekci tworzą infrastrukturę, na której dane aplikacje będą chodzić, czyli całe środowisko end-to-end dla danego rozwiązania. DevOps robi trochę wszystkiego po trochu – tworzy aplikacje lub jej komponenty jako mikrousługi oraz tworzy całe środowisko end-to-end, gdzie ta aplikacja będzie wdrażana. 

Pamiętam, jak zaczynałem udział w pewnym projekcie, gdzie developerzy chcieli swoją usługę wystawić na chmurze. Oni byli odpowiedzialni za funkcjonalność, natomiast nas poprosili o pomoc przy wdrożeniu na chmurę. Zebraliśmy od nich wymagania (np. jaka baza danych), jaki ruch przewidują, ile potrzebują zasobów itp. i na podstawie tych danych przedstawiliśmy im środowisko docelowe – klaster Kubernetes z określonymi węzłami i parametrami z możliwością skalowania, do tego baza danych Postgress, sieć zabezpieczona z możliwością komunikacji z internetu z określonych adresów IP. Wszystko miało się zamknąć w kwocie X zgodnie z kalkulatorem Azure, w którym łatwo można oszacować koszty rozwiązania – jako DevOps musieliśmy też przedstawić koszty architektury 🙂 

Pamiętam, jak wielkie było zadowolenie developerów i project managerów, jak przedstawiliśmy im to wszystko i oni mogli spokojnie pisać swoje rozwiązanie, a cały trud implementacji na środowisku był po naszej stronie. Dla nas to akurat była pestka wdrażać aplikacje na chmurę, natomiast nie wszyscy mają łatwość z tą technologią. Pamiętam, że poczułem wtedy fajną ekscytację, że udało się wszystko tak zaproponować, że zespół wewnętrzny był mega zadowolony. No i już po paru miesiącach szykujemy się na wdrożenie produkcyjne, przez co jeszcze wchodzi większa ekscytacja, że nasz pomysł zaraz będzie miał swoją wielką premierę dla klientów. 

Jak można się domyślić, w tym projekcie miałem bardziej rolę architekta oprogramowania niż developera, natomiast przy innym projekcie musiałem wejść w rolę deva, gdyż pomagałem programiście w debugowaniu, czemu jego aplikacja nie działa. Wdrażał właśnie swój kod na nasze środowisko projektowe i był bardzo zdziwiony, czemu nie może się dostać do aplikacji. Przecież u niego na komputerze to działa! Sprawdzałem z nim logi jego aplikacji i zadawałem pytania: “A czemu Ty się z tym łączysz, czemu taki log powstał, albo tutaj czemu ta linijka jest?”. I w końcu natrafiliśmy na błąd! Okazało się, że jego aplikacja nasłuchuje na porcie HTTP (80), natomiast on ze swojej przeglądarki dobijał się na port HTTPS (443) – niestety nie umiał mi wytłumaczyć, czemu jest taka rozbieżność w konfiguracji. Koniec końców był szczęśliwy z tego, że na środowisku projektowym udało mu się zalogować poprawnie.

Dlaczego wybrałeś taką ścieżkę kariery? Jaka była Twoja droga do obecnego stanowiska?

To może śmiesznie zabrzmi, ale jakoś nigdy wcześniej nie marzyłem o tym, aby być DevOpsem 🙂 Po prostu na pewnym etapie mojej kariery poznałem Dockera i zacząłem zgłębiać Kubernetesa. Obie technologie tak mi się spodobały, że postanowiłem się ich nauczyć, a wg mnie najlepiej jest się uczyć czegoś, pracując na tym. Zacząłem  więc szukać szkoleń na platformach elerningowych (Udemy, Coursera) o podstawach chmurowych i w międzyczasie szukałem pracy jako inżynier od Kubernetes. Tak właśnie trafiłem na stanowisko DevOps, gdzie Kubernetes jest wykorzystywany w codziennej pracy – cały produkt, za który jestem odpowiedzialny właśnie stoi na Azure Kubernetes Service (AKS).

Pamiętasz swoją rozmowę rekrutacyjną w KMD?

Ależ oczywiście, że tak – to był jeden z bardziej stresujących dni w moim życiu! Zanim doszło do rozmowy, dostałem test i w ciągu bodajże godziny musiałem odpowiedzieć na jak największą ilość pytań. Na szczęście pytanie były z cyklu ABCD, ale stopień trudności rósł z każdym następnym pytaniem i z tego co pamiętam, nie udało mi się dojść do ostatniego. 

Jednak chyba musiało mi pójść całkiem dobrze, skoro zaprosili mnie na rozmowę z szefem i inżynierem, który miał sprawdzić moją wiedzę. Tym stresowałem się najbardziej, bo musiałem pokazać, jak dobrze znam się na Kubernetesie. Na szczęście trochę już na tym pracowałem i przynajmniej wiedziałem, jakie są tam obiekty i jak sprawdzić coś, co może nie działać,za to brakowało mi wiedzy, jak taki system działa komercyjnie na produkcji i na wielką skalę. 

Podczas części technicznej rozmowy dostałem klaster, w którym nie działała jedna z aplikacji i miałem dojść do tego, dlaczego tak się dzieje, tłumacząc po kolei, co robię, jakie widzę objawy i jakie kroki bym poczynił. Wszystko szło nawet dobrze do momentu, w którym naprawdę nie wiedziałem, czemu aplikacja nie działa. Na szczęście inżynier, który mnie sprawdzał podpowiedział mi, gdzie mogę szukać przyczyny i że to mogła być zamierzona konfiguracja, o której nie miałem pojęcia. Nigdy wcześniej nie widziałem takiej konfiguracji, ale potem okazało się, że coś podobnego wykorzystuje się na rzeczywistym systemie i wtedy miało to dla mnie większy sens. 

Po tym wszystko poszło już bardzo szybko i w miarę sprawnie dostałem pozytywną opinię, że mogę zaczynać przygodę na nowym stanowisku.

Oferty pracy z

Jak wygląda Twój typowy dzień w pracy?

Wydaje mi się, że nie różni się tak bardzo od innych stanowisk. Przychodzę rano do pracy, siadam przy swoim biurku, bo akurat mamy ustalone miejsca, gdzie siedzimy jako zespół, odpalam laptopa i najczęściej idę wtedy po kubek kawy, żeby przyjemniej przeglądało się zadania, które mam akurat przypisane. W międzyczasie przeglądam też firmowe komunikatory, czy przypadkiem nie ma jakiś krytycznych rzeczy, na które powinienem zwrócić uwagę. 

W naszym zespole korzystamy z metodologii agile i codziennie o 9:30 mamy daily, na którym wspólnie przeglądamy wszystkie zadania w zespole i omawiamy problemy, które napotkaliśmy. Zawsze staram się przejrzeć swoje zadania przed wspólnym spotkaniem, aby szybko i sprawnie przekazać, nad czym pracuję i gdzie potrzebuję pomocy od zespołu.

Czym zajmujesz się w pracy, jakie są twoje zadania?

W pracy głównie zajmuję się infrastrukturą na Azure i wspomagam różne projekty i produkty w firmie, które właśnie na tej platformie są wdrożone lub chcą się na taką platformę dostać.

Naszym głównym produktem jest Nexus, czyli system dla opieki zdrowotnej w Danii, którego wszystkie komponenty są wdrażane właśnie na Azure. Cały produkt jest zrobiony w technologii mikroserwisów wdrożonych na klastrze Kubernetes i naszym zadaniem jako DevOps jest monitorowanie stanów wszystkich komponentów, czy działają poprawnie, a także wszystkich elementów wokół platformy, jak: bazy danych, dostęp zewnętrzny czy komunikacja do serwisów klienckich. Na szczęście nie musimy wiedzieć, jak dokładnie każdy z komponentów działa, bo za nie odpowiedzialne są zespoły developerów, które je rozwijają niezależnie. Natomiast do nas należy monitorowanie, czy te kontenery/pody w Kubernetes działają prawidłowo – jeśli coś jest nie tak, informujemy developerów, że coś się dzieje z ich komponentem i prosimy, aby zdiagnozowali problem. Czasem stary dobry restart mikroserwisu pomaga i nie musimy już wtedy prosić developerów o pomoc natychmiastową, jednak w praktyce zbieramy im dane z mikroserwisu do późniejszej analizy, czemu takie zdarzenie miało miejsce, żeby mogli zdiagnozować problem.

Natomiast dla nowych projektów, które właśnie się migrują do chmury, jako zespół DevOps jesteśmy odpowiedzialni za pomoc przy wdrażaniu ich aplikacji na infrastrukturę Azure. Mamy wtedy wewnętrzne spotkania z zespołem developerów, którzy specyfikują wymagania do aplikacji i czego dokładnie potrzebują, a następnie my na tej bazie proponujemy rozwiązanie architektury na Azure, żeby ich produkt jak najlepiej tam działał. Na szczęście jest to czynność powtarzalna. 

Oczywiście, prócz wdrożenia aplikacji trzeba ją jeszcze w prosty sposób utrzymać, więc napisaliśmy wzorzec architektury na Azure w Terraform, gdzie możemy wdrażać kod, co jakiś czas uwzględniając specyficzne wymagania projektowe, jednak rdzeń każdego projektu jest taki sam – wszędzie działamy na Kubernetes i potrzebujemy mikroserwisów 🙂  

Dodatkowo część z nas, w tym ja, pracuje w trybie 24/7, co oznacza, że mamy cotygodniowe dyżury, jesteśmy wtedy pod telefonem 24h na dobę 7 dni w tygodniu. Jeśli cokolwiek złego stanie się z systemem – jakiś mikroserwis pada, coś dzieje się z klastrem lub serwis klienta jest niedostępny, wówczas dostajemy powiadomienie w aplikacji na telefonie i musimy zareagować jak najszybciej, żeby sprawdzić, co się takiego dzieje. Z racji tego, że mamy obszerną wiedzę na temat infrastruktury i tego, jak ona działa to coraz więcej produktów chce od nas te dodatkowe usługi 24/7, żeby mieć pewność, że ich system będzie zawsze działał.

Stack technologiczny, z którego korzystasz na co dzień to…?

Pracujemy głównie na platformie Microsoft Azure, gdzie całość naszej infrastruktury mamy zautomatyzowaną za pomocą Ansible oraz Terraform. Ze względów historycznych część projektów jest wdrożona za pomocą Ansible runbooków, gdzie każdą zmianę czy modyfikację staramy się opisać w kodzie. Jednak nowsze projekty wdrażamy już za pomocą Terraform, gdzie naszym celem jest stworzenie modułów, które możemy używać między różnymi projektami. Dzięki temu łatwiej w przyszłości będziemy mogli dodawać nowe funkcjonalności.

Jak już mamy infrastrukturę w kodzie, to po jej wdrożeniu możemy instalować aplikacje i tutaj korzystamy z podejścia CI/CD, wykorzystując Azure DevOps. Mamy tam opisane wszystkie kroki, które wykonujemy podczas wdrażania i konfigurowania aplikacji i tutaj jest najciekawsza część, bo nie mamy tylko jednego języka, w którym opisujemy te kroki, tylko korzystamy z tego, który najlepiej wg nas się nadaje albo dana osoba zna najlepiej. Część kroków opisana jest w skryptach bash/shell (tego jest chyba najwięcej), część  w skryptach PowerShell, możemy też znaleźć skrypty Python czy Golang. Natomiast coś, co pozostaje niezmienne to fakt, że nasze aplikacje wdrażamy głównie za pomocą Helm chartów na platformę Kubernetes, żeby ułatwić zarządzanie nimi. 

Do monitorowania klastra i stanów różnych aplikacji korzystamy ze standardowego podejścia, czyli zbieramy metryki za pomocą Prometheus i analizujemy je w wykresach na Grafanie, natomiast do logów aplikacyjnych wykorzystujemy na razie Elasticsearch i Kibany.

Co Ci się najbardziej podoba w Twojej pracy? 

Wydaje mi się, że najbardziej lubię technologie, z którymi pracuję – to, jak się zmieniają i ewoluują. Mimo tego, że z samym Kubernetesem pracuję już parę lat, to wciąż jest on rozwijany, powstają nowe obiekty i aplikacje. Już nie wspominając o Azure, który cały czas ma rozwijane kolejne funkcje i coraz więcej serwisów możemy tam znaleźć. 

Wydaje mi się, że nie udało mi się poznać jeszcze wszystkich aspektów chmury, bo łapię się na tym, że wciąż poznaję tam coś nowego. Na przykład ostatnio wspomagałem kolegów i koleżanki od projektu ML/AI (Machine Learning/Artificial Intelligence), którzy potrzebowali środowiska do pracy z odpowiednimi narzędziami i wtedy poznałem nową gałąź Azure właśnie poświęconą AI.

Dodatkowym atutem jest dla mnie fakt, że mogę współpracować z developerami aplikacji i pomagać im wdrażać ich kod na chmurę. Sam nie potrafiłbym siedzieć tyle nad kodem i pisać kolejnych funkcjonalności, jednak jako DevOps świetnie pracuje mi się z infrastrukturą i jej automatyzacją. Nawet mimo tego, że to też poniekąd jest kod, ale już trochę inny i jakoś łatwiej mi się go pisze.

A czy możemy mówić o jakichś “cieniach” pracy w roli DevOpsa? Jakie są największe bolączki, problemy związane z tą rolą w IT?

Na pewno swego rodzaju bolączką jest to, że DevOps musi być ekspertem od wszystkiego – nawet od aplikacji developerów 🙂 Często jest tak, że gdy jakiś zespół wdraża swoją aplikację na chmurę, to ma tendencję do zrzucania całej odpowiedzialności właśnie na DevOpsów, bo jak to stare przysłowie mówi: “u mnie działa lokalnie, a w chmurze już nie” czyli wina leży po stronie DevOps, a to nie zawsze jest prawda. Czasem aplikacja jest po prostu błędnie napisana, bo w chmurze panują trochę inne prawa i mechanizmy połączeń czy konfiguracji, dlatego dana aplikacja musi być napisana zgodnie ze sztuką. 

Zdarzyło mi się też parę razy, że pomagałem developerom w debugowaniu ich własnej aplikacji i patrzeniu w logi, czemu ona nie działa, a przecież sami te logi pisali i powinni umieć je czytać i interpretować. Jednak tutaj może działać efekt już wcześniej wspomniany – “jest to na chmurze, to już nie mój problem”. 

Kolejnym cieniem, który nasuwa mi się na myśl jest mnogość dostępnych rozwiązań i narzędzi do pracy. Weźmy chociażby proces CI/CD – same aspekty wdrażania aplikacji są w miarę wspólne, jednak sposób ich implementacji może być nieco inny. Na szczęście korzystamy z jednej platformy Azure DevOps, gdzie mamy opisane wszystkie procesy – część z nich jest stworzona jako obiekty wyklikane przez GUI, a część jest opisana w kodzie w plikach YAML – obie metody konfiguruje się inaczej i nieco inaczej się nimi zarządza poprzez portal. Natomiast to, że my używamy Azure DevOps, wcale nie jest regułą i podobne funkcjonalności moglibyśmy uzyskać w Jenkins, GitHub Actions czy GitLab-CI – wszystkie te narzędzia służą do tego samego, jednak mają inną składnię, przez co korzystając z jednego narzędzia nie możemy być ekspertami w drugim. Niestety, patrząc na różne oferty pracy i Stacki wykorzystywane przez firmy, to różnie możemy trafić i może się okazać, że przy zmianie firmy będziemy musieli się nauczyć wszystkiego od nowa.