Jak zostać DevOps Engineerem? Wywiad z Dawidem Jędrzejczakiem

Droga do wymarzonego stanowiska wypełniona jest nauką i mozolnym zdobywaniem doświadczenia. O dążeniu do celu, a także o wyzwaniach, z jakimi spotyka się DevOps Engineer na początku swojej ścieżki, rozmawialiśmy z Dawidem Jędrzejczakiem z intive. Zapytaliśmy go również o konteneryzację w IT oraz praktykę GitOps.

Zobacz też

DevOps DevOps to must have każdej firmy. Historia Pawła Kubicy

Dlaczego postanowiłeś zostać DevOps Engineerem?

Pewnego dnia pracując w pierwszej firmie jako IT System Operator, zacząłem zastanawiać się nad tym jak będzie wyglądała moja kariera w IT za trzy lub cztery lata. Miałem wtedy 21 lat i byłem najmłodszy w firmie, dookoła mnie siedzieli doświadczeni administratorzy, architekci, testerzy i programiści. Dzięki temu szybko udało mi się poznać zadania wykonywane na poszczególnym stanowisku w IT. Przeglądając internet trafiłem na termin “DevOps”. Po przeczytaniu założeń kultury pracy DevOps i zakresu obowiązków specjalisty z tego obszaru, wiedziałem, że “to jest to”.

Wyznaczyłem sobie duży cel “Znajdź pracę jako DevOps Engineer” i kilka mniejszych, które miały mi w tym pomóc np. “Naucz się Dockera”, “Naucz się Jenkinsa”, “Stwórz infrastrukturę za pomocą Terraforma”, “Stwórz CI/CD dla aplikacji Java”. Temat zafascynował mnie na tyle, że większość wolnego czasu spędzałem na pogłębianiu wiedzy. Wewnętrzny głos mówił mi, że ten kierunek to coś przyszłościowego i warto zainwestować w to czas – dziś nie żałuję, bo wciąż uczę się nowych zagadnień i robię to co lubię.  

Mówisz, że sporo czasu poświęciłeś na pogłębianie wiedzy. Czego dokładnie się uczyłeś? Ile czasu zajęła Ci nauka – od momentu, kiedy postanowiłeś zostać DevOpsem, do uzyskania pierwszej pracy?

Zaczynałem od nauki działania kontenerów na bazie Dockera. Tworzyłem proste aplikacje i bazy danych w kontenerach, aby ostatecznie połączyć je ze sobą. Później przyszedł czas na Kubernetesa. Korzystałem z poradników na YouTube, oficjalnej dokumentacji i kursów na Udemy.

Nauczyłem się wtedy podstaw obsługi linii poleceń (CLI – kubectl), tworzenia obiektów (deployment, service, itd.), wdrażania za pomocą narzędzi CI/CD (Jenkins), eksperymentowałem też z chmurą AWS i Azure, tworzyłem infrastrukturę za pomocą Terraforma. Nauka zajęła mi rok. Uczyłem się w wolnych chwilach w pracy, po pracy, a czasami nawet w weekendy, gdy nie miałem żadnych planów. 

Oferty pracy z

Jaka była Twoja ścieżka do aktualnego stanowiska?

Pierwszą pracę w IT dostałem na stanowisku o nazwie IT System Operator. Zadania, które tam wykonywałem można porównać do pracy na stanowisku administratora. Dużą częścią tej pracy był system Linux oraz odtwarzanie procedur w przypadku wystąpienia konkretnego problemu.

W wolnych chwilach pracowałem nad swoimi projektami, które miały mi pomóc poznać narzędzia DevOps na tyle, aby starać się o pracę jako DevOps Engineer – udało się, zostałem przyjęty do nowej firmy na dokładnie takie stanowisko.

Jak trafiłeś do intive?

Dostałem wiadomość z ofertą na LinkedIn od rekruterki Anity. Wiadomość w której wszystko było jasno i przejrzyście opisane. Zakres technologiczny wpisywał się bardzo dobrze w moje upodobania, ale także “widełki” finansowe były całkowicie jawne co było dodatkowym plusem. Wystarczyła wymiana dwóch wiadomości i następnego dnia o godz. 11:00 już mieliśmy umówioną rozmowę telefoniczną. Reszta procesu rekrutacyjnego była bardzo sprawna. 

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

Zaczynam od dobrego śniadania i kawy 🙂 W intive pracuję na rzecz powierzonego mi klienta. Dział odpowiedzialny za rekrutację tworzy profil pracownika i proponuje dołączenie do projektów zgodnych z umiejętnościami. Nie inaczej było w moim przypadku.

Trafiłem do projektu dla zagranicznej instytucji rządowej, która rozwija swoje aplikacje z wykorzystaniem OpenShifta. Praca jest wymagająca, ale dzięki temu można tylko zyskać ucząc się nowych rzeczy. Moje zadania to m.in. tworzenie procesów CI/CD z wykorzystaniem różnych narzędzi (Jenkins, Tekton), automatyzacja wdrożeń (Helm), migracja aplikacji.

Z jakimi największymi wyzwaniami miałeś okazję się zmierzyć w pracy DevOpsa?

Jednym z większych wyzwań może być np. migrowanie aplikacji z platformy OpenShift w wersji 3 na wersję 4. Migracje bywają kompleksowym zadaniem, wymagają obrania odpowiedniej strategii, współpracy wszystkich zespołów pracujących nad daną aplikacją.

Przeniesienie jednej aplikacji nie jest wyzwaniem, staje się nim dopiero, gdy migrować chce cała organizacja. Trzeba wtedy wypracować automatyzację, która pozwoli robić to sprawnie i bez większych komplikacji. Dla mnie to właśnie zadania związane z migracjami są tymi najbardziej wymagającymi.

Pracowałeś już dla bankowości, cyberbezpieczeństwa i instytucji rządowych. Czy praca przy tak odpowiedzialnych projektach mocno różni się od tej dla prywatnych firm?

Praca w firmach z sektora bankowości, cyberbezpieczeństwa czy dla instytucji rządowych różni się tym, że firmy z takich sektorów muszą przykładać większą niż standardową uwagę do kwestii bezpieczeństwa danych, zabezpieczeń systemów, nadawania dostępu odpowiednim osobom. W swojej dotychczasowej karierze spotkałem się z wieloma dedykowanymi rozwiązaniami mającymi poprawić bezpieczeństwo wewnątrz organizacji.

Przykład: Instalacja edytora tekstu na maszynie przez pracownika. Można zrobić to w 5 minut pobierając dany program ze strony producenta i zwyczajnie zainstalować za pomocą kilku kliknięć. Jednak firmy stawiające na bezpieczeństwo tworzą dedykowane systemy do “zamawiania” oprogramowania. Takie zamówienie stworzone przez użytkownika przechodzi przez wyznaczoną ścieżkę akceptacji kilku osób lub grup np. Przełożonego, Dział IT, Dział Bezpieczeństwa  Dzięki temu firmy mają większą kontrolę nad użytkownikami i pochodzeniem instalowanego przez nich oprogramowania . Czy to dobra praktyka? Według mnie tak, wydłuża to proces, ale skoro poprawia bezpieczeństwo to jestem za. 

Możesz opowiedzieć o pracy przy projektach opartych na wykorzystaniu konteneryzacji?

Konteneryzacja w IT to bardzo popularny temat ostatnich lat – nie bez przyczyny. Odejście od monolitycznych rozwiązań na rzecz kontenerów sprawiło, że aplikacje stały się łatwe do wdrożenia, utrzymania czy przenoszenia na różne środowiska. Zalet jest o wiele więcej, myślę, że można poświęcić temu nawet oddzielny artykuł. Obecnie najbardziej popularnym orkiestratorem kontenerów jest Kubernetes. W swojej aktualnej pracy pracuję z platformą Red Hat OpenShift, która jest dystrybucją Kubernetesa – rozszerzona o szereg dodatkowych rozwiązań, które mają pomóc w pracy z kontenerami.

Praca w projektach opartych na wykorzystaniu konteneryzacji aplikacji na pierwszy rzut oka wydaje się być kompleksowym rozwiązaniem wymagającym używania wielu narzędzi i konfigurowania wzajemnych zależności. Jak poukładać te puzzle? Odpowiedź to DevOps. Specjalista z tego obszaru wraz z zespołem odpowiedzialnym za rozwój oprogramowania tworzą strategię wdrażania aplikacji (CI/CD), tak aby cały proces był w pełni automatyczny. Według mnie ważnym elementem jest to, aby nowe wersje aplikacji, dało się wdrażać bez konieczności wyłączania aktualnie działającej wersji.

Z pomocą przychodzi tzw. rolling deployment. Taka strategia pozwala zapomnieć o wdrożeniach z czasowym oknem serwisowym czy praktykach takich jak wdrożenia w weekendy lub w nocy kiedy, jest mniej użytkowników. Obok aktualnie działającej wersji aplikacji uruchamiania jest dodatkowa wersja (zazwyczaj nowa, z dodatkowymi funkcjonalnościami), jeśli nowa wersja uruchomi się poprawnie to następuje wyłączenie starszej wersji i ruch kierowany jest do nowej. Takie dynamiczne przejście trwa kilka sekund i jest niezauważalne dla użytkownika końcowego.

Dlaczego GitOps? Jak Twoim zdaniem wdrażanie tej praktyki może pomóc w pracy?

Myślę, że o GitOps to odpowiedź na trudności w zapanowaniu nad aktualnym stanem konfiguracji naszej aplikacji czy infrastruktury, ale także znakomite uproszczenie procesu Continuous Delivery. Każdy pracując w większym zespole spotkał się z problemem dokonywania manualnych zmian w konfiguracji i braku odzwierciedlenia tych zmian w repozytorium kodu.

Dzięki praktyce GitOps możemy używać repozytorium kodu jako jedynego źródła prawdy o stanie konfiguracji naszej aplikacji czy infrastruktury. Odpowiednia konfiguracja narzędzia GitOps pozwala na ciągłą synchronizację stanu z repozytorium ze środowiskiem. Warto wspomnieć o podejściu “Pull based deployments”, które jest bardzo dużym ułatwieniem procesu Continuous Delivery. Namawiam, aby zapoznać się z narzędziem takim jak np. ArgoCD i przetestować jego funkcjonalności.

Komu poleciłbyś pracę na stanowisku DevOps? Jakie umiejętności/wymagania trzeba dziś spełniać, by odnaleźć się w tej pracy?

Każdej osobie, która lubi uczyć się wielu technologii i narzędzi. Na ścieżce DevOps pojawia się ich naprawdę dużo. Komunikatywność też jest pożądana, ponieważ często współpracujemy z wieloma zespołami, prezentujemy wypracowane rozwiązania publicznie. Według mnie, aby dziś zostać specjalistą z tego obszaru trzeba mieć solidne podstawy z zagadnień takich jak:

• usługi jednego z dostawców chmurowych (AWS, Azure, GCloud)
• konteneryzacja (Docker, Podman, Kubernetes, OpenShift)
• sieci internetowe (TCP, UDP, HTTP, TLS)
• tworzenie procesów CI/CD (Jenkins, Tekton, TeamCity itp…)
• menedżery pakietów (HELM, Kustomize)
• język skryptowy (Bash, Python)
• bazy danych (PostgreSQL, Redis)
• GitOps (ArgoCD, GIT)
• Infrastructure as Code (Terraform)
• systemy operacyjne (Linux)
• automatyzacja (Ansible)
• monitoring (Prometheus, Grafana)

Zobacz też

Zarobki w IT Zarobki w IT. Sprawdzamy, ile w 2021 roku zarabiał inżynier DevOps

Dawid Jędrzejczak. Senior DevOps Engineer w intive. Realizował projekty m.in dla bankowości, cyberbezpieczeństwa, instytucji rządowych. Pracuje w projektach opartych na wykorzystaniu konteryzacji (OpenShift / Kubernetes). Zainteresowany wdrażaniem praktyki GitOps. Prywatnie entuzjasta wycieczek oraz wszelkiego rodzaju wydarzeń sportowych, które można obejrzeć z trybun.