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, iż 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 choćby przy testach), a w końcu także za wypuszczenie jej produkcyjnie i monitorowanie, czy wszystko działa jak trzeba. Dzięki temu, iż 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ż, iż 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 systemu czy DevOps. Co łączy te stanowiska?
Można powiedzieć, iż 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, iż poczułem wtedy fajną ekscytację, iż udało się wszystko tak zaproponować, iż 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, iż 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 systemu 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ę, iż 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, iż 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, iż 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, iż 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 choćby 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 iż 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ę, iż coś podobnego wykorzystuje się na rzeczywistym systemie i wtedy miało to dla mnie większy sens.
Po tym wszystko poszło już bardzo gwałtownie i w miarę sprawnie dostałem pozytywną opinię, iż mogę zaczynać przygodę na nowym stanowisku.
