Inżynieria
Programista
Pięć poziomów od Junior Developera do Principal Engineera i sześć kompetencji – od dostarczania kodu po rozwój zespołu.
- 5 poziomów
- 6 kompetencji
Szablon drabiny kariery
Szablon drabiny kariery DevOps Engineera
Cztery poziomy od Junior do Staff DevOps Engineera i sześć kompetencji – od infrastruktury po wsparcie programistów.
Plan bezpłatny · Bez karty kredytowej
Ta drabina kariery jest przeznaczona dla inżynierów DevOps, platformowych i infrastruktury w firmach liczących mniej więcej od 20 do 200 osób. Przy tej wielkości zespół infrastruktury to zwykle od jednej do sześciu osób, które utrzymują konta chmurowe, pipeline’y wdrożeniowe, monitoring i dyżury on-call, a pomaganiu programistom poświęcają tyle samo czasu co serwerom. Opisuje cztery poziomy – od osoby wprowadzającej dobrze określone zmiany w infrastrukturze po kogoś, kto odpowiada za kierunek rozwoju platformy firmy. Najwyższy poziom, Staff DevOps Engineer, jest poziomem eksperckim; zarządzanie zespołem infrastruktury to osobna praca.
Każdy poziom określa to, co dana osoba robi i jak dużą część systemu się jej powierza, a nie lata doświadczenia czy liczba narzędzi w CV. Czytaj wiersz matrycy kompetencji od lewej do prawej, aby zobaczyć, jak rośnie jedno oczekiwanie; czytaj sekcję poziomu, aby zobaczyć wszystko, czego się na nim oczekuje. Wykorzystaj ją, by wyjaśnić, co oznacza kolejny poziom, uporządkować check-iny i podejmować decyzje o awansie, których da się bronić.
Dopasuj ją przed publikacją. Zastąp ogólne sformułowania własnym stosem technologicznym i praktykami oraz usuń części, które należą do innego zespołu – na przykład jeśli bezpieczeństwem lub bazami danych zajmuje się ktoś inny.
Poziomy w skrócie
Junior DevOps Engineer
Wprowadza – zawsze po review – dobrze określone zmiany w infrastrukturze i pipeline’ach i uczy się, jak działa produkcja.
- Zakres
- Pojedyncze zmiany w istniejącym kodzie infrastruktury i pipeline’ach, zaplanowane i przejrzane przez kogoś bardziej doświadczonego.
Mid DevOps Engineer
Odpowiada od początku do końca za części infrastruktury i w pełni uczestniczy w dyżurach on-call.
- Zakres
- Serwisy, środowiska lub pipeline’y dla jednego lub dwóch zespołów produktowych – od projektu po codzienne utrzymanie.
Senior DevOps Engineer
Projektuje i prowadzi projekty infrastrukturalne, od których zależy kilka zespołów, i podnosi poprzeczkę niezawodności.
- Zakres
- Wspólna infrastruktura, z której korzysta większość inżynierii, oraz projekty takie jak migracje dotykające każdego zespołu.
Staff DevOps Engineer
Wyznacza kierunek rozwoju platformy firmy i odpowiada za jej niezawodność, bezpieczeństwo i koszty.
- Zakres
- Cała platforma produkcyjna, jej kierunek na kilka lat i jej budżet, we wszystkich zespołach inżynierii.
Matryca kompetencji
Każdy wiersz to kompetencja, a każda kolumna – poziom. Czytaj wiersz od lewej do prawej, aby zobaczyć, jak rosną oczekiwania.
Co oznacza każda kompetencja
- Infrastruktura jako kod
- Budowanie i zmienianie infrastruktury za pomocą przeglądanego, powtarzalnego kodu, a nie ręcznie.
- Pipeline’y budowania i wdrażania
- Przeprowadzanie kodu od scalonego pull requesta do produkcji szybko i bezpiecznie.
- Niezawodność i reagowanie na incydenty
- Utrzymywanie dostępności produkcji i szybkie przywracanie jej, gdy coś przestaje działać.
- Monitoring i obserwowalność
- Umożliwianie wglądu w to, co dzieje się na produkcji, i wiedzy, kiedy coś idzie źle.
- Bezpieczeństwo i dostępy
- Ochrona systemów i danych przez bezpieczne ustawienia domyślne, zasadę najmniejszych uprawnień i szybkie łatanie.
- Wsparcie programistów i współpraca
- Pomaganie programistom w samodzielnym utrzymaniu ich serwisów i dzielenie się wiedzą, by platforma nie zależała od jednej osoby.
| Kompetencja | Junior DevOps Engineer | Mid DevOps Engineer | Senior DevOps Engineer | Staff DevOps Engineer |
|---|---|---|---|---|
| Infrastruktura jako kod | Wprowadza zmiany w istniejącym kodzie infrastruktury zgodnie z przyjętymi wzorcami, sprawdza planowany diff przed zastosowaniem i nigdy nie zmienia niczego ręcznie na produkcji bez wcześniejszego zapytania. | Pisze wielokrotnego użytku moduły infrastruktury dla nowych serwisów i środowisk, bezpiecznie obchodzi się ze stanem i sekretami oraz usuwa nieużywane już zasoby. | Projektuje układ kodu infrastruktury i środowisk firmy, prowadzi zmiany takie jak aktualizacje sieci czy klastrów z przetestowanym planem wycofania i dba o to, by koszty chmury były widoczne w podziale na zespoły. | Wybiera podstawowe elementy i dostawców platformy na najbliższe lata, ustala standardy, których przestrzega infrastruktura każdego zespołu, i razem z kierownictwem odpowiada za budżet infrastruktury. |
| Pipeline’y budowania i wdrażania | Naprawia zepsute kroki pipeline’u, dodaje proste joby do istniejących pipeline’ów i potrafi wyjaśnić programiście, dlaczego jego build się nie powiódł. | Buduje i utrzymuje pełny pipeline dla serwisu – build, testy, artefakty, wdrożenia na każde środowisko – i skraca wolne kroki, na które narzekają programiści. | Projektuje wspólne szablony pipeline’ów, z których korzysta każdy zespół, wprowadza bezpieczniejsze metody wydawania, takie jak wdrożenia canary lub blue-green, i śledzi częstotliwość wdrożeń oraz odsetek nieudanych wdrożeń. | Określa, jak cała firma dostarcza oprogramowanie – od strategii gałęzi po wycofywanie zmian – i usuwa wąskie gardła spowalniające dostarczanie we wszystkich zespołach. |
| Niezawodność i reagowanie na incydenty | Towarzyszy osobom na dyżurze on-call, postępuje według runbooków przy znanych alertach i szybko eskaluje, przekazując informacje potrzebne kolejnej osobie. | W pełni uczestniczy w dyżurach on-call, rozwiązuje bez pomocy większość incydentów w swoim obszarze, pisze runbooki do tego, co naprawił, i testuje kopie zapasowe, faktycznie je odtwarzając. | Prowadzi reagowanie na poważne incydenty, przeprowadza post-mortemy bez szukania winnych i doprowadza działania naprawcze do końca oraz planuje pojemność i przełączanie awaryjne dla krytycznych systemów. | Ustala z produktem i kierownictwem cele niezawodności, projektuje proces dyżurów i obsługi incydentów dla całej inżynierii i planuje na wypadek katastrof, takich jak utrata regionu lub dostawcy. |
| Monitoring i obserwowalność | Dodaje dashboardy i alerty na wzór istniejących przykładów, a gdy coś wygląda niepokojąco, najpierw sprawdza logi i metryki. | Konfiguruje logowanie, metryki i alerty dla nowych serwisów, dostraja alerty tak, by każde powiadomienie wymagało działania, i pomaga programistom znaleźć w danych to, czego potrzebują. | Projektuje podejście do obserwowalności głównych systemów firmy, definiuje sygnały kondycji serwisów, według których mierzone są zespoły, i ogranicza szum alertów w wielu zespołach. | Wybiera narzędzia obserwowalności firmy i ich model kosztów oraz dba o to, by kierownictwo widziało kondycję platformy bez pytania inżyniera. |
| Bezpieczeństwo i dostępy | Przestrzega zasad zespołu dotyczących sekretów i dostępów, instaluje rutynowe poprawki i natychmiast zgłasza wszystko, co wygląda na problem z bezpieczeństwem. | Zarządza dostępami i sekretami swoich serwisów zgodnie z zasadą najmniejszych uprawnień, łata podatności według ich wagi i usuwa problemy wykryte przez skany bezpieczeństwa. | Projektuje granice sieci, zarządzanie tożsamością i sekretami w całej platformie, przygotowuje materiały dowodowe do audytów bezpieczeństwa prowadzonych przez klientów i prowadzi reagowanie na incydenty bezpieczeństwa. | Razem z kierownictwem odpowiada za poziom bezpieczeństwa platformy, ustala mechanizmy kontrolne wymagane przez zgodność z normami (na przykład SOC 2 lub ISO 27001) i sprawia, że bezpieczna droga jest dla każdego zespołu najłatwiejsza. |
| Wsparcie programistów i współpraca | Odpowiada na pytania programistów o środowiska i pipeline’y, dokumentuje wprowadzane poprawki i wcześnie prosi o review. | Pisze jasne instrukcje do typowych zadań, pracuje w parze z programistami przy wdrażaniu i debugowaniu ich serwisów i wprowadza nowe osoby w zespole w infrastrukturę. | Buduje narzędzia samoobsługowe, dzięki którym zespoły tworzą serwisy i środowiska bez zakładania zgłoszenia, mentoruje innych inżynierów DevOps i bierze udział w rekrutacji. | Kształtuje platformę jako wewnętrzny produkt, którego użytkownikami są programiści, decyduje, za co odpowiadają zespoły, a za co zespół platformowy, i rozwija kolejnych seniorów. |
Przewiń tabelę w bok, aby zobaczyć wszystkie poziomy.
Pobierz jako CSV Otwiera się w Excelu, Arkuszach Google lub Numbers.
Junior DevOps Engineer: czego się oczekuje
Wprowadza – zawsze po review – dobrze określone zmiany w infrastrukturze i pipeline’ach i uczy się, jak działa produkcja. Pojedyncze zmiany w istniejącym kodzie infrastruktury i pipeline’ach, zaplanowane i przejrzane przez kogoś bardziej doświadczonego.
- Infrastruktura jako kod
- Wprowadza zmiany w istniejącym kodzie infrastruktury zgodnie z przyjętymi wzorcami, sprawdza planowany diff przed zastosowaniem i nigdy nie zmienia niczego ręcznie na produkcji bez wcześniejszego zapytania.
- Pipeline’y budowania i wdrażania
- Naprawia zepsute kroki pipeline’u, dodaje proste joby do istniejących pipeline’ów i potrafi wyjaśnić programiście, dlaczego jego build się nie powiódł.
- Niezawodność i reagowanie na incydenty
- Towarzyszy osobom na dyżurze on-call, postępuje według runbooków przy znanych alertach i szybko eskaluje, przekazując informacje potrzebne kolejnej osobie.
- Monitoring i obserwowalność
- Dodaje dashboardy i alerty na wzór istniejących przykładów, a gdy coś wygląda niepokojąco, najpierw sprawdza logi i metryki.
- Bezpieczeństwo i dostępy
- Przestrzega zasad zespołu dotyczących sekretów i dostępów, instaluje rutynowe poprawki i natychmiast zgłasza wszystko, co wygląda na problem z bezpieczeństwem.
- Wsparcie programistów i współpraca
- Odpowiada na pytania programistów o środowiska i pipeline’y, dokumentuje wprowadzane poprawki i wcześnie prosi o review.
Mid DevOps Engineer: czego się oczekuje
Odpowiada od początku do końca za części infrastruktury i w pełni uczestniczy w dyżurach on-call. Serwisy, środowiska lub pipeline’y dla jednego lub dwóch zespołów produktowych – od projektu po codzienne utrzymanie.
- Infrastruktura jako kod
- Pisze wielokrotnego użytku moduły infrastruktury dla nowych serwisów i środowisk, bezpiecznie obchodzi się ze stanem i sekretami oraz usuwa nieużywane już zasoby.
- Pipeline’y budowania i wdrażania
- Buduje i utrzymuje pełny pipeline dla serwisu – build, testy, artefakty, wdrożenia na każde środowisko – i skraca wolne kroki, na które narzekają programiści.
- Niezawodność i reagowanie na incydenty
- W pełni uczestniczy w dyżurach on-call, rozwiązuje bez pomocy większość incydentów w swoim obszarze, pisze runbooki do tego, co naprawił, i testuje kopie zapasowe, faktycznie je odtwarzając.
- Monitoring i obserwowalność
- Konfiguruje logowanie, metryki i alerty dla nowych serwisów, dostraja alerty tak, by każde powiadomienie wymagało działania, i pomaga programistom znaleźć w danych to, czego potrzebują.
- Bezpieczeństwo i dostępy
- Zarządza dostępami i sekretami swoich serwisów zgodnie z zasadą najmniejszych uprawnień, łata podatności według ich wagi i usuwa problemy wykryte przez skany bezpieczeństwa.
- Wsparcie programistów i współpraca
- Pisze jasne instrukcje do typowych zadań, pracuje w parze z programistami przy wdrażaniu i debugowaniu ich serwisów i wprowadza nowe osoby w zespole w infrastrukturę.
Senior DevOps Engineer: czego się oczekuje
Projektuje i prowadzi projekty infrastrukturalne, od których zależy kilka zespołów, i podnosi poprzeczkę niezawodności. Wspólna infrastruktura, z której korzysta większość inżynierii, oraz projekty takie jak migracje dotykające każdego zespołu.
- Infrastruktura jako kod
- Projektuje układ kodu infrastruktury i środowisk firmy, prowadzi zmiany takie jak aktualizacje sieci czy klastrów z przetestowanym planem wycofania i dba o to, by koszty chmury były widoczne w podziale na zespoły.
- Pipeline’y budowania i wdrażania
- Projektuje wspólne szablony pipeline’ów, z których korzysta każdy zespół, wprowadza bezpieczniejsze metody wydawania, takie jak wdrożenia canary lub blue-green, i śledzi częstotliwość wdrożeń oraz odsetek nieudanych wdrożeń.
- Niezawodność i reagowanie na incydenty
- Prowadzi reagowanie na poważne incydenty, przeprowadza post-mortemy bez szukania winnych i doprowadza działania naprawcze do końca oraz planuje pojemność i przełączanie awaryjne dla krytycznych systemów.
- Monitoring i obserwowalność
- Projektuje podejście do obserwowalności głównych systemów firmy, definiuje sygnały kondycji serwisów, według których mierzone są zespoły, i ogranicza szum alertów w wielu zespołach.
- Bezpieczeństwo i dostępy
- Projektuje granice sieci, zarządzanie tożsamością i sekretami w całej platformie, przygotowuje materiały dowodowe do audytów bezpieczeństwa prowadzonych przez klientów i prowadzi reagowanie na incydenty bezpieczeństwa.
- Wsparcie programistów i współpraca
- Buduje narzędzia samoobsługowe, dzięki którym zespoły tworzą serwisy i środowiska bez zakładania zgłoszenia, mentoruje innych inżynierów DevOps i bierze udział w rekrutacji.
Staff DevOps Engineer: czego się oczekuje
Wyznacza kierunek rozwoju platformy firmy i odpowiada za jej niezawodność, bezpieczeństwo i koszty. Cała platforma produkcyjna, jej kierunek na kilka lat i jej budżet, we wszystkich zespołach inżynierii.
- Infrastruktura jako kod
- Wybiera podstawowe elementy i dostawców platformy na najbliższe lata, ustala standardy, których przestrzega infrastruktura każdego zespołu, i razem z kierownictwem odpowiada za budżet infrastruktury.
- Pipeline’y budowania i wdrażania
- Określa, jak cała firma dostarcza oprogramowanie – od strategii gałęzi po wycofywanie zmian – i usuwa wąskie gardła spowalniające dostarczanie we wszystkich zespołach.
- Niezawodność i reagowanie na incydenty
- Ustala z produktem i kierownictwem cele niezawodności, projektuje proces dyżurów i obsługi incydentów dla całej inżynierii i planuje na wypadek katastrof, takich jak utrata regionu lub dostawcy.
- Monitoring i obserwowalność
- Wybiera narzędzia obserwowalności firmy i ich model kosztów oraz dba o to, by kierownictwo widziało kondycję platformy bez pytania inżyniera.
- Bezpieczeństwo i dostępy
- Razem z kierownictwem odpowiada za poziom bezpieczeństwa platformy, ustala mechanizmy kontrolne wymagane przez zgodność z normami (na przykład SOC 2 lub ISO 27001) i sprawia, że bezpieczna droga jest dla każdego zespołu najłatwiejsza.
- Wsparcie programistów i współpraca
- Kształtuje platformę jako wewnętrzny produkt, którego użytkownikami są programiści, decyduje, za co odpowiadają zespoły, a za co zespół platformowy, i rozwija kolejnych seniorów.
Jak dopasować tę drabinę
Nazwij swój stos w oczekiwaniach
Ogólne sformułowania w rodzaju „kod infrastruktury” czy „pipeline’y” łatwo zaakceptować, ale trudno ocenić. Zastąp je swoimi prawdziwymi narzędziami i praktykami, tak by junior dokładnie wiedział, czego ma się nauczyć najpierw.
Nie spiesz się z poziomem Staff
Przy jednym–trzech inżynierach DevOps zwykle wystarczą poziomy Junior, Mid i Senior. Dodaj Staff, gdy ktoś faktycznie wyznacza kierunek platformy i odpowiada za jej budżet w całej inżynierii – nie jako tytuł dla najbardziej doświadczonej osoby w małym zespole.
Wpisz zasady dyżurów on-call do drabiny
Określ, na którym poziomie ludzie dołączają do grafiku dyżurów, kiedy prowadzą incydenty i jak wynagradzany jest czas dyżuru. Niespisane oczekiwania wobec dyżurów to jeden z najczęstszych powodów, dla których inżynierowie infrastruktury się wypalają i odchodzą.
Dopasuj poziomy do drabiny programistów
Przypisz każdemu poziomowi DevOps poziom programisty o tym samym zakresie i wynagrodzeniu. Praca platformowa to praca inżynierska, a zgrane ze sobą drabiny ułatwiają przejścia między zespołami produktowymi i platformowymi.
FAQ
Pytania o tę drabinę
Czym różni się DevOps Engineer od SRE i Platform Engineera?
Ściśle biorąc, DevOps to sposób pracy, a nie nazwa stanowiska; w praktyce w firmach liczących 20–200 osób te tytuły opisują przeważnie tę samą pracę z innym akcentem: SRE skupia się na celach niezawodności – zwykle SLO i budżetach błędów – oraz na incydentach, Platform Engineer na narzędziach samoobsługowych dla programistów, a DevOps Engineer na pipeline’ach i infrastrukturze. Jedna drabina zwykle obejmuje wszystkie trzy role; zamiast tworzyć osobne drabiny, dopasuj sformułowania kompetencji.
Kiedy startup potrzebuje pierwszego DevOps Engineera?
Zwykle wtedy, gdy programiści spędzają zauważalną część tygodnia na wdrożeniach, środowiskach i problemach produkcyjnych zamiast na funkcjach albo gdy klienci zaczynają pytać o gwarancje dostępności i audyty bezpieczeństwa. W wielu firmach dzieje się to przy około 15–30 programistach.
Czy dyżury on-call powinny się liczyć przy awansie DevOps Engineera?
Tak, ale licz to, czego ludzie się nauczyli i co usprawnili, a nie liczbę obsłużonych powiadomień. Dobrze poprowadzony poważny incydent, post-mortemy, których działania naprawcze zostały wykonane, i ograniczenie szumu alertów to wyraźne dowody gotowości na kolejny poziom. Częste dyżury – nie.
Czy certyfikaty chmurowe mają znaczenie dla poziomu DevOps Engineera?
Mogą pomóc w nauce platformy, ale nie powinny decydować o poziomie. Oceniaj, co dana osoba zbudowała i utrzymuje w twoim środowisku, względem matrycy kompetencji. Certyfikat bez takich dowodów nie pokazuje gotowości na kolejny poziom; takie dowody bez certyfikatu – owszem.
Ile poziomów potrzebuje drabina kariery DevOps Engineera?
Trzy lub cztery, bo zespoły infrastruktury w firmach tej wielkości są małe. Ten szablon ma cztery – Junior, Mid, Senior i Staff – i dobrze współgra z pięciopoziomową drabiną programisty, jeśli poziomy Staff są na tej samej wysokości.
Zbuduj tę drabinę kariery w LadderKit – za darmo
Ustaw jej poziomy i umiejętności dla swojego zespołu, oceniaj według nich ludzi w check-inach i zachowaj spójność decyzji o awansach.
Plan bezpłatny · Bez karty kredytowej
Powiązane szablony
Inżynieria
QA Engineer
Cztery poziomy od Junior do Lead QA Engineera i sześć kompetencji – od projektowania testów po praktyki jakości.
- 4 poziomy
- 6 kompetencji
Inżynieria
Engineering Manager
Cztery poziomy od Engineering Managera do VP of Engineering i sześć kompetencji menedżerskich.
- 4 poziomy
- 6 kompetencji