Co jest potrzebne, aby pracować w obszarze DevOps? Jakie konkretne umiejętności, technologie i narzędzia trzeba znać?
W tym artykule pokażę Ci jasną ścieżkę rozwoju DevOps dla inżynierów, architektów i ekspertów. 
Artykuł podzieliłem na 3 części:

1. W pierwszej z nich skupię się na narzędziach dla inżynierów DevOps.
2. W drugiej części opowiem o umiejętnościach dla architektów DevOps.
3. W ostatniej zdradzę, co jest wymagane, aby zostać ekspertem DevOps.

Umiejętności inżynierskie

Zacznijmy od umiejętności inżynierskich. Oto 5 narzędzi technicznych i umiejętności, które są niezbędne dla inżynierów DevOps – zaczynając od juniorów, a kończąc na bardziej seniorskich stanowiskach.

1 – Kubernetes

Oczywiście, że Kubernetes jest numerem jeden, a jakże by inaczej! Nie tylko dlatego, że to moje ulubione narzędzie, ale przede wszystkim dlatego, że stał się technologią, która zmieniła branżę IT w ciągu ostatnich kilku lat.
Jest niemal wszędzie i jest używany przez większość największych firm. Jest wszechobecny, ponieważ może być używany w chmurze w modelu Kubernetes-as-a-service lub w środowiskach on-prem z wykorzystaniem zwykłych serwerów.

Kubernetes łączy wiedzę z wielu dziedzin. Nie jest to więc pojedyncza umiejętność, ale grupa wielu umiejętności.
Aby dobrze poznać Kubernetes musisz nauczyć się Linuksa – w końcu Kubernetes można postrzegać jako po prostu grupę linuksowych serwerów widocznych i zarządzanych poprzez API i to wszystko!
Musisz wiedzieć jak działa Linuks i jak go skonfigurować na serwerze oraz jak używać narzędzi zawartych w każdej dystrybucji (np. sed, find, awk, top, ps, kill, itd.). 
Z Linuksem przychodzi kolejna technologia związana z Kubernetesem – to kontenery. Dlatego powinieneś wiedzieć czym jest kontener i jak działa Docker lub inny silnik kontenerowy.
Ponadto inżynier DevOps musi rozumieć linuksowe sieci, aby móc tworzyć klastry, load balancery, kontrolować ruch i używać Service Mesh.
Zanim narodził się Kubernetes, to właśnie Linuks i chmura były podstawowymi technologiami wykorzystywanymi w DevOps. Teraz przeniosło się to na kontenery oparte na Linuksie.

Po co więc w ogóle uczyć się Kubernetesa?
Jeśli go znasz, to po prostu łatwiej i szybciej skonfigurować autoskalowalne środowiska, które reagują na zmieniające się wykorzystanie aplikacji.
Łatwiej jest też zabezpieczyć obciążenia, ponieważ z Kubernetes otrzymujesz wiele dodatkowych narzędzi (np. opartych na technologii ePBF), a także dlatego, że kontenery są szybsze w aktualizacji.
Dzięki Kubernetesowi będziesz mógł tworzyć jeszcze bardziej złożone środowiska multi-cloud, a co ważniejsze – dużo łatwiej stworzysz rozwiązania hybrydowe. Ten ostatni scenariusz wykorzystania staje się ostatnio coraz bardziej popularny.

Ale czy wiesz, co jest prawdziwym celem Kubernetesa i powodem, dla którego stał się tak popularny? Jest nim szybkość wdrożeń. I przez szybkość mam na myśli cały proces od opublikowania kodu z repozytorium git aż do wdrożenia na środowisko produkcyjne.
To dlatego deweloperzy kochają Kubernetes i dlatego Twoim zadaniem jest zapewnienie bezproblemowego, jak najłatwiejszego wykorzystania go w Twojej organizacji.
Od osób pracujących jako inżynierowie DevOps lub architekci oczekuje się eksperckiej wiedzy na temat Kubernetes – inni (tj. programiści) będą zwracać się do nich o pomoc, jak efektywnie wykorzystać jego funkcje.

Po prostu nie wyobrażam sobie nowoczesnego DevOps bez Kubernetes. Koniec. Kropka.

2 – Cloud

Teraz druga technologia, która jest niezbędna dla DevOps. Jednak chmura to technologia, która może być dostarczana przez konkretnego dostawcę (np. AWS, Azure lub GCP), ale także nowe podejście do budowania środowisk IT. Niektórzy nazywają to cloud-native i pod tym pojęciem kryje się wiele technologii, jak wspomniany wcześniej Kubernetes.
Wracając jednak do pojęcia, które wszyscy znamy jako Cloud. Jedno jest pewne – w gruncie rzeczy wszystkie chmury są do siebie podobne. Wystarczy więc poznać przynajmniej jednego dostawcę chmury dość dobrze, aby móc korzystać z pozostałych.

Zacznij od zdobycia podstawowej wiedzy.
Musisz znać część dotyczącą sieci. Prawie wszyscy dostawcy używają koncepcji Virtual Private Cloud (w skrócie VPC lub też podobne nazwy), aby odizolować Twoje maszyny i usługi na poziomie sieci. Musisz wiedzieć, jak nimi zarządzać, zabezpieczać ruch za pomocą polityk ruchu sieciowego (tzw. “security groups”) i tworzyć różne strefy prywatne i publiczne.
Wszyscy dostawcy chmury mają jakiś rodzaj zarządzania dostępen i tożsamościami (w skrócie IAM), aby kontrolować dostęp do swoich API dla użytkowników i maszyn.
A skoro już mówimy o maszynach – niezależnie od tego, jak dostawcy chmury je nazywają (maszyny wirtualne, instancje czy też zasoby obliczeniowe), są to po prostu znan nam serwery linuksowe. Trzeba wiedzieć, jak je tworzyć, dystrybuować między strefami dostępności i przygotowywać obrazy, aby umożliwić korzystanie z mechanizmów automatycznego skalowania.
Aby systemy były odporne, musisz nauczyć się korzystać z odpowiednich technologii pamięci masowych – w tym pamięci blokowych dołączanych bezpośrednio do instancji oraz pamięci obiektowych wykorzystywanych przez aplikacje i do wielowarstwowych rozwiązań backupowych.

Wszystko to jednak kosztuje, czasem nawet bardzo dużo. Więc jednym z twoich obowiązków jest nauczenie się, jak skutecznie kontrolować koszty usług. I uwierz mi – to może być czasem podstępne i trudne do ogarnięcia.
Jak więc kontrolujesz swoje środowiska chmurowe? Używasz tych wymyślnych interfejsów webowych tylko po to, aby uzyskać przegląd swojego środowiska. W innych przypadkach używasz API i to powinien być twój główny sposób interakcji z chmurą.

Wiesz, jaką zabawną rzecz w chmurze i Kubernetes zauważyłem po pracy z nimi przez wiele lat? Ucząc się Kubernetesa łatwiej jest zrozumieć chmurę i odwrotnie! Zauważysz, że istnieją wspólne koncepcje z subtelnymi różnicami. Na przykład w chmurze używasz maszyn wirtualnych jako podstawowych komponentów dla usług, podczas gdy w Kubernetes używasz zamiast tego kontenerów. Jednak nadal wchodzisz z nimi w interakcje poprzez API, ustawiasz reguły RBAC, kontrolujesz ruch, skalujesz instancje, balansujesz ruch oraz ustawiasz metryki i logowanie.

Więc ucz się chmury najpierw jako technologii, a następnie jako bardziej uniwersalnego podejścia cloud-native. 

3 – Terraform

Przejdźmy do kolejnej fascynującej technologii. Jest nią Terraform. Jeśli o nim nie słyszałeś to musiałeś przespać ostatnie kilka lat lub jesteś totalnie nowy w DevOps.
Projekt ten jest jednym z najbardziej znanych ze stajni HashiCorp, w skład którego wchodzą również Consul, Packer czy Vault.
Jest to oprogramowanie numer jeden w dziedzinie automatyzacji. Najczęściej jest wykorzystywane do automatyzacji środowisk chmurowych, ale nie tylko do tego.
Terraform jest bardziej uniwersalny, bo jego rozszerzalna architektura umożliwia korzystanie z tzw. providerów, co rozszerza jego zastosowanie na prawie każdy rodzaj oprogramowania, które ma jakieś API (np. GitLab, GitHub, Grafana, Zabbix – jest ich ponad 2 tysiące!).
Właściwie Terraform może zastąpić inny projekt, który był szeroko stosowany w obszarze zarządzania infrastrukturą – Ansible.
Korzystałem z Ansible, ale moim zdaniem nie jest to najszybszy i najwygodniejszy w obsłudze (zwłaszcza w rozwiązywaniu problemów) kawałek oprogramowania. Nie jest też całkowicie deklaratywny jak Terraform i uważam, że w większości przypadków można użyć Terraforma z jego dostawcami (providerami) i modułami.
Oprócz providerów społeczność Terraform stworzyła wiele przydatnych modułów, które zmniejszają pracę związaną z automatyzacją wszystkich rzeczy.

Moduły te mogą być szczególnie przydatne, gdy nie znasz specyfiki danego API chmury. Terraform wchodzi w bezpośrednią interakcję z API i dlatego wymaga dość dogłębnej wiedzy na jego temat, a tak możesz sobie skrócić drogę i odroczyć dogłębne poznanie API na później.
Terraform jest tak dobry w automatyzacji infrastruktury chmurowej, że Oracle wybrał go jako podstawowe narzędzie do automatyzacji w swojej chmurze OCI. Moim zdaniem to tylko potwierdza pozycję lidera Terraform jako narzędzia do automatyzacji. I jak wspomniałem – nie tylko automatyzacji środowisk chmurowych, ale także różnych komponentów instalowanych na szczycie zautomatyzowanej infrastruktury.

Wraz z innym projektem HashiCorp – Packer – może posłużyć do automatyzacji każdego skrawka infrastruktury chmurowej. I przez chmurę rozumiem zarówno środowiska publiczne jak i prywatne, ponieważ Terraform wspiera również platformy on-prem – jeśli masz OpenStack lub vSphere uruchomione na swoich serwerach to Terraform pomoże Ci zautomatyzować je w deklaratywny sposób.

A kiedy nadejdzie czas, możesz wykorzystać swoje umiejętności, aby zautomatyzować provisioning chmury publicznej na dowolnym dostawcy. Koniec z własnościowymi narzędziami, i interfejsami graficznymi – jedno narzędzie do automatyzacji ich wszystkich.
Jedną z najważniejszych części DevOps jest automatyzacja, a Terraform jest rozwiązaniem, które musisz znać, aby budować wysoce zautomatyzowane środowiska.

4 – CI/CD

Czy wiesz, kiedy deweloperzy doceniają posiadanie dobrych inżynierów DevOps na pokładzie swojego zespołu? Kiedy pomagają im uczynić procesy wdrażania bezproblemowymi i to bez większego wysiłku.
A osiąga się to poprzez stworzenie procesów Continuous Integration i Continuous Deployment lub Delivery.
Jednym z najważniejszych zadań dla inżynierów DevOps jest przygotowanie infrastruktury oraz procesów CI/CD, aby zespoły deweloperskie mogły skupić się na… tworzeniu najlepszego kodu, jaki tylko potrafią.
Nie możesz pomóc deweloperom w tworzeniu lepszego kodu, ale możesz zapewnić, że mają wszystko, czego potrzebują, aby go ulepszyć, bez spędzania zbyt wiele czasu na grzebanie w różnych częściach infrastruktury.
Dzięki automatyzacji wdrażania szybciej możliwe jest uruchomienie różnych procesów przed ujawnieniem tego wspaniałego kawałka oprogramowania użytkownikom końcowym. Procesy te obejmują pakowanie oprogramowania w artefakty, kontenery lub obrazy maszyn wirtualnych, a następnie ich testowanie. Testy te zapewniają, że oprogramowanie jest wolne od poważnych błędów, luk bezpieczeństwa lub innych potencjalnych wad.

Zaufaj mi – programiści nie chcą spędzać czasu na poznawaniu szczegółów infrastruktury i tego, jak te wszystkie kontenery, load balancery, API chmury i maszyny wirtualne współdziałają ze sobą. Oni chcą po prostu tworzyć swój niesamowity kod.
A im mniej interakcji międzyludzkich jest w tym procesie, tym lepie/szybciejj. Żadnych ticketów i żadnych prywatnych wiadomości na Slack – oni chcą platformy, która po prostu działa.

Więc które oprogramowanie powinieneś wybrać, aby nauczyć się tworzyć te potoki CI/CD? Właściwie to nie ma znaczenia, naprawdę! Wybierz dowolne, który jest używane w Twojej organizacji lub po prostu jest wygodniejsze, lepsze dla Ciebie.
Mój preferowany silnik CI/CD to Jenkins, ale tylko dlatego, że używam go od wielu lat i nauczyłem się wykorzystywać go do budowania prawie każdego, nawet najbardziej złożonego potoku. Jednak nie jest to najłatwiejszy kawałek softu.
Może w Twoim przypadku GitLab CI lub GitHub Actions mogą być lepsze i przede wszystkim łatwiejsze do nauczenia. Może wybierzesz Tekton, gdy będzie już wystarczająco dojrzały, ponieważ jest to projekt zaprojektowany z myślą o Kubernetes.

5 – Język programowania

Ostatnia część od strony inżynierskiej to nie kolejny projekt – to coś, co pozwala je buduwać.
Aby zostać dobrym inżynierem DevOps musisz wiedzieć jak połączyć ze sobą wszystkie klocki, które do tej pory wymieniłem.
Potrzebujesz jakiegoś języka programowania do tworzenia skryptów lub usług (więcej o tym później). 

Polecam naukę tych trzech w tej konkretnej kolejności.
Zacząłbym od Basha. Nie jest to język programowania per se, ale najpopularniejsza powłoka znajdująca się w prawie każdej dystrybucji Linuksa. Więc czy to maszyna wirtualna on-prem, serwer bare-metal, instancja chmury, węzeł Kubernetes, czy kontener – powłoka Bash już tam jest.
Można jej używać do interakcji z systemem lub do tworzenia skryptów. Bash ma wszystko, czego potrzebujesz do mniejszych zadań – począwszy od pętli, warunkow, a nawet wbudowanych wyrażeń regularnych.
Bash jest również często używany do tworzenia plików Dockerfile z definicją obrazów kontenerów lub w skryptach cloud-init wykonywanych przy uruchamianiu instancji chmury. 
Dzięki niesamowitemu narzędziu o nazwie curl możesz nawet wchodzić w interakcje z różnymi REST API, a wykorzystując inne dostępne polecenia możesz zautomatyzować procesy na dość przyzwoitym poziomie.
Jednak Bash jest daleki od doskonałości i może być niewystarczający dla bardziej złożonych scenariuszy.

Dlatego w dalszej kolejności zainteresuj się Pythonem. Jest to najpopularniejszy język i również dość łatwy do nauczenia. Kiedy Bash i curl nie wystarczą, Python ze swoją prostotą może wybawić Cię z kłopotów. Jest bardzo wydajny, gdy mamy do czynienia z danymi i komunikacją z usługami poprzez API. Obsługa błędów, moduły i testy – to rzeczy trudne do zaimplementowania w czystym Bashu.
Python jest zwykłym językiem programowania i można w nim napisać wszystko, co tylko dusza zapragnie. Dzięki tak wielu dostępnym bibliotekom można nawet stworzyć własny operator Kubernetesa. Jest to więc zdecydowanie pierwszy wybór dla inżynierów DevOps. Ale nie jedyny.

Czasami potrzebujesz czegoś więcej. Może chcesz napisać własny operator Kubernetes za pomocą Native SDKs lub stworzyć wtyczki dla Terraform lub Vault. Wtedy proponuję użyć Golang.
Jest to język pierwszego wyboru dla środowisk cloud-native. Tam, gdzie liczy się szybkość i rozmiar wybierz Go. Jest często używany do tworzenia obrazów kontenerów jednoplikowych, które działają na klastrach Kubernetes.
Golang jest jeszcze bliżej warstwy OS i chociaż jego składnia jest bardziej złożona (szczególnie w porównaniu do Pythona), to nadal jest on dość łatwy do nauczenia.

Umiejętności architekta

Tak więc to były umiejętności wymagane od inżyniera DevOps, a teraz przejdźmy do umiejętności architekta DevOps.
Wyróżniłem trzy takie umiejętności i skupiają się one na odpowiednim projektowaniu platform. Aby zostać architektem DevOps trzeba mieć umiejętności inżynierskie i dużo szersze doświadczenie w pracy z nowoczesną infrastrukturą. 

O ile dostęp do StackOverflow czy nawet systemów AI takich jak ChatGPT może pomóc Ci w rozwiązywaniu codziennych zadań jako inżynier, o tyle nie uczynią Cię one architektem. Potrzebujesz intuicji, która jest rozwijana przez lata praktyki i wymyślania pomysłów na ulepszenia i optymalizacje.

6 – Projektowanie API

Pierwszą umiejętnością jest projektowanie API. Teraz, gdy wiesz już, jak działają wszystkie to komponenty, musisz przełożyć tę wiedzę na oprogramowanie.
Nie mówię, że musisz zostać architektem oprogramowania, ale dla architekta DevOps nie wystarczy tylko wiedzieć, jak używać narzędzi. Musisz zacząć automatyzować wszystkie rzeczy w inteligentniejszy i bardziej zunifikowany sposób. Musisz ukryć złożoność wewnętrznych prac za zunifikowanym API.
W skrócie – inżynierowie korzystają z API, podczas gdy architekci mogą projektować nowe.
Najprostszym przykładem jest wzorzec projektowy operatora Kubernetes. Napisanie nowego operatora to tak naprawdę zaprojektowanie nowego API. Nie jest to również takie trudne, ponieważ Kubernetes został zaprojektowany tak, aby był rozszerzalny poprzez zapewnienie Custom Resource Definition i SDK do tworzenia kontrolerów.
W ten sposób można osadzić swoją wiedzę w oprogramowaniu i dostarczyć ją jako usługę. To właśnie definiuje zaawansowany DevOps – automatyzacja z samoobsługą za pomocą API.
Podobnie możesz rozszerzyć Terraform, pisząc własne providery.
Oczywiście istnieją scenariusze, w których będziesz musiał napisać swoją usługę od zera i to właśnie tam przydaje się twoja wiedza w Pythonie lub Golangu. Istnieje wiele frameworków, które pomogą ci zbudować twoje API (np. Flask, Gin i Revel).

Uważam, że ta forma automatyzacji jest dużo bardziej dojrzała. Umiejętność projektowania nowych API jest wymagana do budowania złożonych systemów na znacznie większą skalę. Nie wszystko można zrobić za pomocą istniejących narzędzi i w tych scenariuszach wiedza w tym zakresie jest kluczowa.

7 – Bezpieczeństwo

Teraz porozmawiajmy o często zaniedbywanym temacie – bezpieczeństwie. Tak, bezpieczeństwo od zawsze było “najwyższym” priorytetem w wielu organizacjach, ale myślę, że często bardziej chodzi mówienie co powinno być zrobione, niż o smutną rzeczywistość tego, co faktycznie jest robione.
Dlatego ta ważna praca jest częścią obowiązków architekta DevOps. I jeszcze raz – nie chodzi o narzędzia, ale o realny wpływ na bezpieczeństwo systemów pracujących wewnątrz organizacji.

Aby utrzymać bezpieczeństwo systemów trzeba pracować nad dwoma obszarami: nauczyć się odpowiednich technologii i praktyk, a także upewnić się, że te praktyki są w organizacji stosowane. Żadne narzędzie nie będzie wystarczająco dobre, jeśli nie ma świadomości i współpracy osadzonej w kulturze organizacji.
Mogłem umieścić ten obszar bezpieczeństwa w umiejętnościach inżynierskich i rzeczywiście wszyscy inżynierowie powinni umieć sprawić, aby systemy były bezpieczne. Rola architekta jest jeszcze ważniejsza – musi on pracować również nad aspektami nietechnicznymi.

A czym jest część techniczna? Z perspektywy DevOpsa chodzi głównie o umieszczenie praktyk bezpieczeństwa w kodzie. W dawnych czasach chodziło głównie o niezliczoną ilość dokumentów opisujących jak zabezpieczyć systemy – teraz chodzi o opisanie tego w procesach rozwoju, wdrażania i utrzymania.
Czyli zaczynając od prostych rzeczy jak OWASP Top 10 poprzez znane praktyki typu “least privilege principle” , uwierzytelnianie wieloskładnikowe (MFA), audyty itp.

W przypadku Kubernetesa chodzi też o wykorzystanie dostępnych metod jak profile seccomp i SElinux dla kontenerów, automatyczne skanowanie artefaktów aplikacji i obrazów kontenerów czy egzekwowanie najlepszych praktyk na poziomie API za pomocą tzw. admission kontrolerów (np. OPA czy Kyverno).

Mógłbym wymienić dziesiątki projektów, które skupiają się na bezpieczeństwie dla wszystkich typów środowisk. Ale powtórzę jeszcze raz – to nie narzędzia zabezpieczą Twoje systemy, ale podejście, które jest częścią kultury.
I uważam, że jest to zadanie dla architekta DevOps lub architekta DevSecOps.

8 – Wszystko w kodzie

Wraz z bezpieczeństwem powiązana jest kolejna bardzo ważna praktyka, która jest kluczowa dla architektów DevOps. Jest to utrzymywanie wszystkiego jako kodu. Innymi słowy – przejście od operacyjnego podejścia do pracy z systemami do ich projektowania i umieszczania każdego elementu w oprogramowaniu.
Ostatnio GitOps pojawił się jako praktyka zarządzania środowiskami Kubernetes i na pewno podąża za tym podejściem, ale ja widzę to szerzej. Uważam, że jest to obowiązkowe dla wszystkich części DevOps.
To zmusi cię do myślenia w innych, bardziej zaawansowanych kategoriach. 

Skalowalność jest możliwa tylko wtedy, gdy obrazy maszyn wirtualnych lub kontenerów są dostępne, a proces ich pieczenia jest przedstawiony w kodzie.
Pomyśl o powtarzalności – czy uważasz, że jest ona osiągalna bez zakodowania infrastruktury, procesów CI/CD i wspomnianego bezpieczeństwa?
Łatwość, z jaką wszystkie kluczowe części platformy mogą być aktualizowane tylko poprzez zmianę kilku linii kodu, również znacząco wzmacnia jej bezpieczeństwo.
Nie zapominaj też o testowaniu. Dzięki temu, że wszystko jest utrzymywane w postaci kodu, każda zmiana może być przetestowana i łatwo odwrócona. Wymaga to pisania scenariuszy testowych, ale to niewielki wysiłek w porównaniu z korzyściami, jakie przynosi.
Tak więc, aby osiągnąć wszystkie te rzeczy i przenieść zarządzanie platformą na następny poziom, musisz umieścić wszystko w repozytorium git. Oddzielić zarządzanie infrastrukturą od rozwoju aplikacji, zwiększyć przejrzystość, umożliwić rollbacki i umożliwić łatwe eksperymentowanie z nowymi funkcjami.

Umiejętności eksperckie

Zostały jeszcze dwie umiejętności, o których chcę powiedzieć. Są to umiejętności nietechniczne lub tzw. miękkie. Zdecydowałem się oznaczyć je jako umiejętności eksperckie, aby podkreślić jak są one ważne i jednocześnie tak rzadko używane.
Czy to oznacza, że należy się ich uczyć po poprzednich? Wręcz przeciwnie – uważam, że należy je rozwijać jak najwcześniej w trakcie swojej kariery. Szybko odkryjesz (jeśli jeszcze tego nie zrobiłeś), że narzędzia nie mają aż tak dużego znaczenia i są rzeczy o wiele ważniejsze. Są one jednak dużo trudniejsze do opanowania, ale z czasem przyniosą Ci niesamowite rezultaty.

9 – Aktywne słuchanie

Prawdziwy powód, dla którego te eksperckie umiejętności są tak ważne, widać na poniższym diagramie.