Pierwsze 90 dni: podręcznik inżyniera DevOps krok po kroku

Hej, nowy pracowniku. Słyszałem o tobie! 

Poznałeś Kubernetes od podszewki, zautomatyzowałeś wszystko, co tylko dało się zautomatyzować, i zarządzałeś potokami. Studiowałeś strategie CI/CD, narzędzia IaC oraz kaprysy YAML-a, jakby od tego zależało twoje życie.

Gratulacje, dostałeś pracę inżyniera DevOps!

Dali ci dostęp do konsoli chmurowej, potoku kompilacji, a być może — o zgrozo — uprawnienia roota na produkcji (bez presji).

Większość procesów wdrażania nowych osób do DevOps to krucha mieszanka „przeczytaj ten przypadkowy dokument z 2021 roku”, „popytaj innych” i „nie ruszaj tego skryptu, chyba nadal coś robi”. 

Rola rzadko jest dobrze zdefiniowana, a oczekiwania są absurdalnie wysokie, podczas gdy dokumentacji jest mało. Poza tym… niektóre wdrożenia sprawiają wrażenie, jakby mogły przebudzić pradawną klątwę.

Choć rozmowa kwalifikacyjna mogła dotyczyć narzędzi, twoje pierwsze 90 dni będzie przede wszystkim poświęcone ludziom, procesom i priorytetom. To właśnie wtedy zdobywasz wiarygodność, odkrywasz to, czego nie zapisano w dokumentacji, i kładziesz fundament pod infrastrukturę, na której twój zespół będzie mógł polegać.

Ten poradnik nie naprawi infrastruktury twojego zespołu z dnia na dzień. Pomoże ci jednak uniknąć sytuacji, w której wyglądasz jak osoba, która ją zepsuła.

Głosy z terenu

„Najważniejsza lekcja, jaką wyniosłam, dotyczy tego, jak szybko trzeba zrozumieć swoich klientów — czyli deweloperów — oraz ich preferencje. W Pixarze skonfigurowałam kiedyś system CI, z którego nikt nie korzystał, dopóki nie dodałam alertów e-mail. Okazało się, że właśnie w ten sposób chcieli być powiadamiani. W innej firmie zwiększyliśmy stosowanie testów, wykorzystując grywalizację i wyświetlając na żywo rankingi w biurze. Kultura to nie tylko szczegół w tle — to prawdziwy potok dostarczania.” -Tara Hernandez, wiceprezes ds. produktywności deweloperów w MongoDB

Rola: DevOps a inżynieria platformowa i SRE

Zacznijmy od odwiecznego zastrzeżenia: „DevOps to kultura, a nie stanowisko pracy”. Jasne, Jan — ale takie stanowisko nadal istnieje. W praktyce często oznacza ono połączenie specjalisty ds. automatyzacji, architekta systemów, inżyniera SRE i eksperta ds. wewnętrznych narzędzi.

Masz być osobą umożliwiającą działanie, mnożnikiem efektywności, rzecznikiem szybkości dostarczania. Prawda jest jednak taka, że będziesz osobą, do której inni przychodzą, gdy:

• Kompilacja się psuje i nikt nie wie dlaczego.
• Ktoś potrzebuje nowego środowiska testowego natychmiast.
• Zbliża się audyt zgodności, a dane uwierzytelniające krążą w postaci zwykłego tekstu.
• „Naprawdę powinniśmy to zautomatyzować” zmienia się w „Czy możesz to zautomatyzować?”.

Inżynieria platformowa to DevOps z lepszym marketingiem.
SRE to DevOps z umową SLA.

Niezależnie od nazwy, twoim zadaniem jest sprawić, by wszystko się skalowało, działało i nie doprowadzało do szału.

Pierwsze 30 dni: jeszcze niczego nie ruszaj

Wskazówka nr 1: Zmapuj infrastrukturę, nie tylko architekturę 

Dowiedz się, za co odpowiadasz: dostawców chmurowych, potoki CI/CD, orkiestrację kontenerów, zarządzanie sekretami i procedury reagowania na incydenty. Utwórz własną „mapę infrastruktury”, aby zwizualizować stos technologiczny. Dodatkowe punkty otrzymasz, jeśli dodasz odnośniki do aktywnych pulpitów nawigacyjnych lub skryptów.

Wskazówka nr 2: Znajdź promień rażenia

Każda organizacja DevOps ma konfigurację typu „proszę tego nie ruszać”. Zrób spis wszystkiego, co może wybuchnąć przy nieprawidłowej ingerencji. Obejmuje to:

• Skrypty wdrożeniowe, które łączą się z produkcją przez SSH (dlaczego… dlaczeeeego?).
• Zadania Jenkinsa ostatnio modyfikowane w 2019 roku.
• Ręczne instrukcje operacyjne przechowywane w pliku PDF.
• Pliki Terraforma, które nigdy faktycznie nie zostały zastosowane.

Zapytaj: Co nie jest udokumentowane, ale ma kluczowe znaczenie? Kto jest za to odpowiedzialny? I jaki jest plan wycofania zmian, jeśli coś zawiedzie?

Wskazówka nr 3: Weź udział we wdrożeniu — a jeszcze lepiej, obserwuj jedno na żywo 

Więcej nauczysz się podczas jednego wdrożenia (i jego problemów) niż z wielogodzinnej lektury dokumentacji. Które kroki są wykonywane ręcznie? Co działa niestabilnie? Co jest wiedzą plemienną, a co zostało sformalizowane? Nie jesteś tu jeszcze po to, by przedstawiać genialne pomysły. Jesteś tu po to, by zebrać materiał.

Powinieneś umieć prześledzić zmianę od scalenia do produkcji z zamkniętymi oczami. Zrozum:

• Potok CI/CD (gdzie się psuje, gdzie powstają wąskie gardła)
• Zarządzanie sekretami (proszę, nie przechowujcie ich w zmiennych środowiskowych)
• Przepływy zatwierdzania (czy wdrażamy bez zastanowienia bezpośrednio ze Slacka?)

Nie dostarczaj kodu. Po prostu obserwuj infrastrukturę i zapisuj wszystko.

Głosy z terenu

„Dobre wdrożenie nie zawsze idzie w parze z dobrą dokumentacją. Czasami jedyną drogą przez chaos są ciekawość i wytrwałość. Kiedy dołączyłem do zespołu i powierzono mi złożone uruchomienie bez żadnej dokumentacji, odtworzyłem cały przepływ na podstawie analizy wstecznej. To doświadczenie nauczyło mnie, że jeśli brakuje dokumentacji, to ty stajesz się dokumentacją.” –Anant Agarwal, dyrektor techniczny w Aidora

Pierwsze 60 dni: identyfikowanie zagrożeń i zmniejszanie tarć

Wskazówka nr 4: Dostarcz małe zwycięstwo w 5 minut

Szukaj zadań powodujących duże tarcia, ale niosących niskie ryzyko, które możesz oskryptować lub ująć w szablon. Te usprawnienia o „1%” ułatwiają życie i budują dobrą atmosferę w zespole. Znajdź tylko jedną rzecz, która zajmuje o 5 minut za dużo, i przyspiesz ją:

• Powłoka Shell do konfiguracji lokalnego środowiska programistycznego
• Pomocnik CLI 
• Wielokrotnego użytku moduł Terraform
• Skrypt usuwający zablokowane środowiska testowe
• Powiadomienie na Slacku o nieudanych kompilacjach

Małe zwycięstwa budują zaufanie. Zaufanie daje ci swobodę wprowadzania dużych zmian.

Wskazówka nr 5: Przeprowadź bezkompromisowy audyt potoku CI/CD

Sprawdź czas kompilacji. Sprawdź pokrycie testami. Sprawdź, co psuje się codziennie. Zadawaj pytania takie jak:

• Czy możemy uruchamiać testy równolegle?
• Czy można było zapobiec temu wcześniej w CI?
• Czy buforujemy zależności?
• Czy wdrażamy po scaleniu… czy liczymy na łut szczęścia?

Nie jesteś tu po to, żeby szukać winnych. Jesteś tu po to, żeby zapewnić bezproblemowy przepływ.

Głosy z terenu

„Podczas niedawnego przejęcia aplikacji o dużym ruchu nie było żadnej dokumentacji — musieliśmy szybko odkryć wszystko metodą prób i błędów. Moja rada? Korzystaj intensywnie ze sztucznej inteligencji. Od analizy logów po odtwarzanie działania interfejsów API sztuczna inteligencja pomogła nam wdrożyć się i ustabilizować system szybciej, niż kiedykolwiek moglibyśmy zrobić to sami. Zamienia rutynową, żmudną pracę w realny postęp.” –Denis Tiumentsev, główny inżynier DevOps w Integro Technologies

Wskazówka nr 6: Twórz pulpity, z których ludzie naprawdę korzystają, i jasno określaj odpowiedzialność 

 Grafana, Prometheus, Datadog — to nie ma znaczenia. Liczy się:

• Czy twój zespół widzi wskaźnik udanych wdrożeń?
• Czy alerty coś znaczą, czy są tylko szumem?

Czy ktoś obserwuje wskaźniki błędów, zanim użytkownicy zaczną narzekać? Kto odpowiada za potok kompilacji? Za wykresy Helm? Za konfiguracje DNS? Granice odpowiedzialności rzadko są jasne. Sporządź listę szarych obszarów i wyjaśnij je wraz z zespołem. Zapobiegnie to późniejszemu wzajemnemu obwinianiu.

Od teraz odpowiadasz za widoczność. Wykorzystaj to dobrze.

Pierwsze 90 dni: budowanie zaufania dzięki niezawodności

Wskazówka nr 7: Dostarcz coś, co zwiększy stabilność 

Może to być:

• Dodanie alertów do niedostatecznie monitorowanego systemu
• Zwiększenie pokrycia testami w środowisku przedprodukcyjnym
• Ograniczenie niestabilności w potokach CI
• Refaktoryzacja skryptu Bash, któremu do katastrofy brakowało tylko jednego rm -rf

Nie musi to być ogromna zmiana. Musi sprawić, że twój zespół odetchnie z ulgą.

Głosy z terenu

“Jednym z pierwszych sukcesów na nowym stanowisku DevOps było wdrożenie scentralizowanego potoku CI/CD z automatycznym wycofywaniem zmian i przepływami pracy GitOps. Wcześniej zespół polegał na rozproszonych skryptach i ręcznych obejściach. Skróciło to czas wdrażania o ponad 50% i pozwoliło nam przejść od gaszenia pożarów do proaktywnego zapewniania niezawodności. Wiarygodność zbudowana dzięki temu wdrożeniu zrobiła ogromną różnicę.” –Divya Parashar, starsza inżynierka

Wskazówka nr 8: Napisz notatkę z opiniami na temat „DevEx”

Zbierz anonimowe lub nieformalne opinie od deweloperów na temat tego, gdzie infrastruktura ich spowalnia. Przedstaw swoje wnioski i zaproponuj eksperymenty (np. szybsze środowisko lokalne, efemeryczne środowiska, lepsze rejestrowanie zdarzeń).

Napisz dokument zatytułowany „Czego się dowiedziałem i co robię dalej”. To plan działania (a może nawet lista sukcesów ;). Udostępnij go swojemu menedżerowi i zespołowi.

Utwórz listę „Nie mogę o tym zapomnieć”:

• Dziwne niuanse, które odkryłeś
• Ukryta infrastruktura, do której nikt nie przyznaje się jako właściciel
• Wiedza plemienna, którą zdaje się posiadać wyłącznie Carl z działu IT

Przekształć tę listę w dokumenty, automatyzację lub zgłoszenia — albo trzymaj ją pod ręką. To pokazuje kierownictwu, że tworzysz systemy odporne na awarie.

Głosy z terenu

„Skup się na rezultatach, na które masz dziś wpływ. Pamiętaj, dlaczego Twoja praca ma znaczenie dla klientów — ta zmiana perspektywy robi ogromną różnicę w ciągu pierwszych 90 dni.” –Rukmini Reddy, starsza wiceprezeska ds. inżynierii w PagerDuty

Wskazówka nr 9: Wybierz jeden projekt o dużym wpływie i zacznij go planować 

Do tej pory powinieneś mieć wystarczająco dużo informacji, aby wskazać główny obszar wymagający poprawy. Wykorzystaj końcowy etap pierwszych 90 dni, aby określić jego zakres, przedstawić go innym i uzyskać zgodę zainteresowanych stron.

• Przenieś zawodne zadania do GitHub Actions
• Zastąp jeden unikatowy serwer infrastrukturą jako kodem
• Stwórz wzorcową ścieżkę, dzięki której deweloperzy będą mogli tworzyć nowe usługi

Zacznij od małych kroków i udowodnij swoją wartość. Wszystko dokumentuj.

Słowo końcowe

Miejmy nadzieję, że w ciągu pierwszych 90 dni uda Ci się ustabilizować sytuację, wdrożyć to cholerstwo na produkcję i — co najważniejsze — powstrzymać inżynierów przed krzyczeniem w otchłań.

Te pierwsze dni służą przede wszystkim budowaniu podstaw na dłuższą metę. Znajduj pęknięcia i dokumentuj jak szaleniec! 

Głosy z terenu

„Nie musisz udowodnić swojej wartości w jeden dzień. Oddychaj. Najpierw skup się na stabilności, a dopiero potem na szybkości. Zadawaj wcześnie głupie pytania — później będzie je tylko trudniej zadać. I pamiętaj: nudny system, który działa, jest lepszy od efektownego systemu, który się psuje.” –Pablo Gerboles, dyrektor generalny Alive DevOps

To nie jest Twoje pierwsze rodeo w branży technologicznej?

Ten podręcznik DevOps jest częścią rozwijanej serii dla nowych pracowników, którzy chcą wywrzeć wpływ, zanim ktoś przekaże im „odpowiedzialność za starsze systemy”.

👉 Dopiero zaczynasz pracę jako inżynier ds. bezpieczeństwa? Pomożemy Ci:
Pierwsze 90 dni: edycja poświęcona cyberbezpieczeństwu

👉 Bardziej interesują Cię zatwierdzenia kodu niż dostęp administratora? Sprawdź:
Pierwsze 90 dni: edycja dla inżynierów oprogramowania

I tak — wkrótce pojawią się kolejne role. Bądź na bieżąco albo, jeszcze lepiej, zapisz się do newslettera, żeby nie przegapić następnej.