Přeskočit na obsah
Menu

Šablona kariérního žebříčku

Šablona kariérního žebříčku pro DevOps inženýry

Čtyři úrovně od Junior po Staff DevOps inženýra a šest kompetencí od infrastruktury po podporu vývojářů.

Tarif Zdarma · Bez platební karty

Tento kariérní žebříček je určen DevOps, platformním a infrastrukturním inženýrům ve firmách s přibližně 20 až 200 lidmi. Při této velikosti má infrastrukturní tým obvykle jednoho až šest lidí, kteří spravují cloudové účty, pipeline pro dodávání, monitoring a pohotovost a kteří stráví pomocí vývojářům stejně času jako prací se servery. Popisuje čtyři úrovně, od člověka, který dělá dobře vymezené změny v infrastruktuře, až po toho, kdo odpovídá za směr platformy celé firmy. Nejvyšší úroveň, Staff DevOps inženýr, je odborná úroveň; vedení infrastrukturního týmu je samostatná práce.

Každá úroveň je definována tím, co člověk dělá a jakou část systému mu lze svěřit, ne počtem let praxe ani počtem nástrojů v životopise. Řádek matice kompetencí čtěte zleva doprava a uvidíte, jak jedno očekávání roste; část věnovanou jedné úrovni čtěte, když chcete vidět vše, co se na ní očekává. Použijte ho k vysvětlení, co znamená další úroveň, ke strukturování check-inů a k rozhodnutím o povýšení, která dokážete obhájit.

Než ho zveřejníte, upravte ho. Obecné formulace nahraďte vlastním stackem a postupy a vyřaďte části, které patří jinému týmu — například pokud bezpečnost nebo databáze spravuje někdo jiný.

Úrovně v kostce

  1. Junior DevOps inženýr

    S revizí dělá dobře vymezené změny v infrastruktuře a pipeline a učí se, jak běží produkce.

    Rozsah
    Jednotlivé změny v existujícím kódu infrastruktury a v pipeline, které naplánuje a zreviduje někdo zkušenější.
  2. Medior DevOps inženýr

    Odpovídá za části infrastruktury od začátku do konce a plně se podílí na pohotovosti.

    Rozsah
    Služby, prostředí nebo pipeline pro jeden či dva produktové týmy, od návrhu po každodenní provoz.
  3. Senior DevOps inženýr

    Navrhuje a vede infrastrukturní projekty, na kterých závisí několik týmů, a zvyšuje laťku spolehlivosti.

    Rozsah
    Sdílená infrastruktura, kterou používá většina vývoje, a projekty, jako jsou migrace, které se dotýkají každého týmu.
  4. Staff DevOps inženýr

    Určuje směr firemní platformy a odpovídá za její spolehlivost, bezpečnost a náklady.

    Rozsah
    Celá produkční platforma, její víceletý směr a rozpočet napříč všemi vývojovými týmy.

Matice kompetencí

Každý řádek je kompetence a každý sloupec úroveň. Čtěte řádek zleva doprava a uvidíte, jak očekávání rostou.

Co jednotlivé kompetence znamenají

Infrastruktura jako kód
Budování a změny infrastruktury pomocí revidovaného, opakovatelného kódu místo ruční práce.
Pipeline pro build a dodávání
Dostat kód z mergnutého pull requestu do produkce rychle a bezpečně.
Spolehlivost a řešení incidentů
Udržet produkci dostupnou a rychle ji obnovit, když dostupná není.
Monitoring a observabilita
Umožnit vidět, co produkce dělá, a poznat, kdy se něco kazí.
Bezpečnost a přístupy
Ochrana systémů a dat pomocí bezpečných výchozích nastavení, minimálních oprávnění a rychlého záplatování.
Podpora vývojářů a spolupráce
Pomáhat vývojářům provozovat vlastní služby a sdílet znalosti, aby platforma nezávisela na jednom člověku.
DevOps inženýr: očekávání podle kompetence a úrovně
KompetenceJunior DevOps inženýrMedior DevOps inženýrSenior DevOps inženýrStaff DevOps inženýr
Infrastruktura jako kódMění existující kód infrastruktury podle zavedených vzorů, před aplikací zkontroluje plánovaný diff a nikdy nemění produkci ručně, aniž by se předem zeptal.Píše znovupoužitelné infrastrukturní moduly pro nové služby a prostředí, bezpečně zachází se stavem a tajnými údaji a odstraňuje prostředky, které se už nepoužívají.Navrhuje uspořádání infrastrukturního kódu a prostředí firmy, vede změny, jako jsou upgrady sítě nebo clusterů, s otestovaným plánem návratu a drží náklady na cloud viditelné pro každý tým.Volí klíčové stavební kameny a poskytovatele platformy na několik dalších let, stanovuje standardy, které dodržuje infrastruktura každého týmu, a spolu s vedením odpovídá za rozpočet na infrastrukturu.
Pipeline pro build a dodáváníOpravuje rozbité kroky pipeline a do existujících pipeline přidává jednoduché joby a dokáže vývojáři vysvětlit, proč jeho build selhal.Staví a udržuje celou pipeline služby — build, testy, artefakty, nasazení do všech prostředí — a zkracuje pomalé kroky, na které si vývojáři stěžují.Navrhuje sdílené šablony pipeline, které používá každý tým, zavádí bezpečnější způsoby vydávání, jako jsou canary nebo blue-green nasazení, a sleduje četnost nasazení a míru jejich selhání.Definuje, jak celá firma dodává software, od větvení po rollback, a odstraňuje úzká hrdla, která zpomalují dodávání ve všech týmech.
Spolehlivost a řešení incidentůDoprovází kolegy na pohotovosti, u známých alertů postupuje podle runbooků a rychle eskaluje s informacemi, které další člověk potřebuje.Plně se podílí na pohotovosti, většinu incidentů ve své oblasti vyřeší bez pomoci, k tomu, co opravil, píše runbooky a zálohy testuje skutečnou obnovou.Vede řešení velkých incidentů, vede post-mortemy bez hledání viníka a dotahuje následná opatření a plánuje kapacitu a failover kritických systémů.S produktem a vedením stanovuje cíle spolehlivosti, navrhuje pohotovostní a incidentní proces pro celý vývoj a plánuje pro katastrofy, jako je ztráta regionu nebo poskytovatele.
Monitoring a observabilitaPřidává dashboardy a alerty podle existujících příkladů, a když něco nevypadá dobře, nejdřív se podívá do logů a metrik.Nastavuje logování, metriky a alerty pro nové služby, ladí alerty tak, aby každý alert vyžadoval zásah, a pomáhá vývojářům najít v datech, co potřebují.Navrhuje přístup k observabilitě hlavních systémů firmy, definuje signály zdraví služeb, podle kterých se týmy měří, a snižuje šum alertů napříč týmy.Volí nástroje observability ve firmě a jejich nákladový model a zajišťuje, aby vedení vidělo zdraví platformy, aniž by se muselo ptát inženýra.
Bezpečnost a přístupyDodržuje pravidla týmu pro tajné údaje a přístupy, nasazuje běžné záplaty a vše, co vypadá jako bezpečnostní problém, okamžitě hlásí.Spravuje přístupy a tajné údaje svých služeb podle principu minimálních oprávnění, záplatuje zranitelnosti podle jejich závažnosti a opravuje nálezy z bezpečnostních skenů.Navrhuje síťové hranice, správu identit a tajných údajů v celé platformě, připravuje podklady pro bezpečnostní prověrky zákazníků a vede reakci na bezpečnostní incidenty.Spolu s vedením odpovídá za bezpečnostní úroveň platformy, nastavuje kontroly, které vyžaduje compliance (například SOC 2 nebo ISO 27001), a dělá z bezpečné cesty tu nejsnazší pro každý tým.
Podpora vývojářů a spolupráceOdpovídá vývojářům na otázky k prostředím a pipeline, dokumentuje opravy, které udělá, a o revizi žádá včas.Píše srozumitelné návody k běžným úkolům, s vývojáři ve dvojici nasazuje a ladí jejich služby a zaškoluje nové kolegy do infrastruktury.Staví samoobslužné nástroje, díky kterým týmy zakládají služby a prostředí bez zakládání tiketu, mentoruje další DevOps inženýry a účastní se náboru.Pojímá platformu jako interní produkt, jehož uživateli jsou vývojáři, rozhoduje, za co odpovídají týmy a za co platformní tým, a vychovává další seniorní inženýry.

Posuňte tabulku do strany, abyste viděli všechny úrovně.

Stáhnout jako CSV Otevře se v Excelu, Tabulkách Google nebo Numbers.

Junior DevOps inženýr: co se očekává

S revizí dělá dobře vymezené změny v infrastruktuře a pipeline a učí se, jak běží produkce. Jednotlivé změny v existujícím kódu infrastruktury a v pipeline, které naplánuje a zreviduje někdo zkušenější.

Infrastruktura jako kód
Mění existující kód infrastruktury podle zavedených vzorů, před aplikací zkontroluje plánovaný diff a nikdy nemění produkci ručně, aniž by se předem zeptal.
Pipeline pro build a dodávání
Opravuje rozbité kroky pipeline a do existujících pipeline přidává jednoduché joby a dokáže vývojáři vysvětlit, proč jeho build selhal.
Spolehlivost a řešení incidentů
Doprovází kolegy na pohotovosti, u známých alertů postupuje podle runbooků a rychle eskaluje s informacemi, které další člověk potřebuje.
Monitoring a observabilita
Přidává dashboardy a alerty podle existujících příkladů, a když něco nevypadá dobře, nejdřív se podívá do logů a metrik.
Bezpečnost a přístupy
Dodržuje pravidla týmu pro tajné údaje a přístupy, nasazuje běžné záplaty a vše, co vypadá jako bezpečnostní problém, okamžitě hlásí.
Podpora vývojářů a spolupráce
Odpovídá vývojářům na otázky k prostředím a pipeline, dokumentuje opravy, které udělá, a o revizi žádá včas.

Medior DevOps inženýr: co se očekává

Odpovídá za části infrastruktury od začátku do konce a plně se podílí na pohotovosti. Služby, prostředí nebo pipeline pro jeden či dva produktové týmy, od návrhu po každodenní provoz.

Infrastruktura jako kód
Píše znovupoužitelné infrastrukturní moduly pro nové služby a prostředí, bezpečně zachází se stavem a tajnými údaji a odstraňuje prostředky, které se už nepoužívají.
Pipeline pro build a dodávání
Staví a udržuje celou pipeline služby — build, testy, artefakty, nasazení do všech prostředí — a zkracuje pomalé kroky, na které si vývojáři stěžují.
Spolehlivost a řešení incidentů
Plně se podílí na pohotovosti, většinu incidentů ve své oblasti vyřeší bez pomoci, k tomu, co opravil, píše runbooky a zálohy testuje skutečnou obnovou.
Monitoring a observabilita
Nastavuje logování, metriky a alerty pro nové služby, ladí alerty tak, aby každý alert vyžadoval zásah, a pomáhá vývojářům najít v datech, co potřebují.
Bezpečnost a přístupy
Spravuje přístupy a tajné údaje svých služeb podle principu minimálních oprávnění, záplatuje zranitelnosti podle jejich závažnosti a opravuje nálezy z bezpečnostních skenů.
Podpora vývojářů a spolupráce
Píše srozumitelné návody k běžným úkolům, s vývojáři ve dvojici nasazuje a ladí jejich služby a zaškoluje nové kolegy do infrastruktury.

Senior DevOps inženýr: co se očekává

Navrhuje a vede infrastrukturní projekty, na kterých závisí několik týmů, a zvyšuje laťku spolehlivosti. Sdílená infrastruktura, kterou používá většina vývoje, a projekty, jako jsou migrace, které se dotýkají každého týmu.

Infrastruktura jako kód
Navrhuje uspořádání infrastrukturního kódu a prostředí firmy, vede změny, jako jsou upgrady sítě nebo clusterů, s otestovaným plánem návratu a drží náklady na cloud viditelné pro každý tým.
Pipeline pro build a dodávání
Navrhuje sdílené šablony pipeline, které používá každý tým, zavádí bezpečnější způsoby vydávání, jako jsou canary nebo blue-green nasazení, a sleduje četnost nasazení a míru jejich selhání.
Spolehlivost a řešení incidentů
Vede řešení velkých incidentů, vede post-mortemy bez hledání viníka a dotahuje následná opatření a plánuje kapacitu a failover kritických systémů.
Monitoring a observabilita
Navrhuje přístup k observabilitě hlavních systémů firmy, definuje signály zdraví služeb, podle kterých se týmy měří, a snižuje šum alertů napříč týmy.
Bezpečnost a přístupy
Navrhuje síťové hranice, správu identit a tajných údajů v celé platformě, připravuje podklady pro bezpečnostní prověrky zákazníků a vede reakci na bezpečnostní incidenty.
Podpora vývojářů a spolupráce
Staví samoobslužné nástroje, díky kterým týmy zakládají služby a prostředí bez zakládání tiketu, mentoruje další DevOps inženýry a účastní se náboru.

Staff DevOps inženýr: co se očekává

Určuje směr firemní platformy a odpovídá za její spolehlivost, bezpečnost a náklady. Celá produkční platforma, její víceletý směr a rozpočet napříč všemi vývojovými týmy.

Infrastruktura jako kód
Volí klíčové stavební kameny a poskytovatele platformy na několik dalších let, stanovuje standardy, které dodržuje infrastruktura každého týmu, a spolu s vedením odpovídá za rozpočet na infrastrukturu.
Pipeline pro build a dodávání
Definuje, jak celá firma dodává software, od větvení po rollback, a odstraňuje úzká hrdla, která zpomalují dodávání ve všech týmech.
Spolehlivost a řešení incidentů
S produktem a vedením stanovuje cíle spolehlivosti, navrhuje pohotovostní a incidentní proces pro celý vývoj a plánuje pro katastrofy, jako je ztráta regionu nebo poskytovatele.
Monitoring a observabilita
Volí nástroje observability ve firmě a jejich nákladový model a zajišťuje, aby vedení vidělo zdraví platformy, aniž by se muselo ptát inženýra.
Bezpečnost a přístupy
Spolu s vedením odpovídá za bezpečnostní úroveň platformy, nastavuje kontroly, které vyžaduje compliance (například SOC 2 nebo ISO 27001), a dělá z bezpečné cesty tu nejsnazší pro každý tým.
Podpora vývojářů a spolupráce
Pojímá platformu jako interní produkt, jehož uživateli jsou vývojáři, rozhoduje, za co odpovídají týmy a za co platformní tým, a vychovává další seniorní inženýry.

Jak tento žebříček přizpůsobit

  1. V očekáváních jmenujte svůj stack

    S obecnými frázemi jako „kód infrastruktury“ nebo „pipeline“ se snadno souhlasí a špatně se podle nich hodnotí. Nahraďte je skutečnými nástroji a postupy, aby junior přesně věděl, co se má naučit nejdřív.

  2. S úrovní Staff počkejte

    S jedním až třemi DevOps inženýry obvykle stačí úrovně junior, medior a senior. Úroveň Staff přidejte, až někdo skutečně určuje směr platformy a odpovídá za její rozpočet napříč celým vývojem — ne jako titul pro nejzkušenějšího člověka v malém týmu.

  3. Zapište pravidla pohotovosti do žebříčku

    Uveďte, na které úrovni se lidé zapojují do rotace, kdy vedou incidenty a jak se čas na pohotovosti kompenzuje. Nevyslovená očekávání ohledně pohotovosti patří k nejčastějším důvodům, proč infrastrukturní inženýři vyhoří a odejdou.

  4. Slaďte úrovně se žebříčkem softwarových vývojářů

    Každou úroveň DevOps přiřaďte k úrovni softwarového vývojáře se stejným rozsahem a mzdou. Práce na platformě je vývojářská práce a sladění obou žebříčků usnadňuje přechody mezi produktovými a platformními týmy.

Časté dotazy

Otázky k tomuto žebříčku

Jaký je rozdíl mezi DevOps inženýrem, SRE a platformním inženýrem?

Přísně vzato je DevOps způsob práce, ne pracovní pozice; v praxi ve firmách s 20 až 200 lidmi tyto tituly většinou popisují stejnou práci s jiným důrazem: SRE se soustředí na cíle spolehlivosti — typicky SLO a error budgety — a na incidenty, platformní inženýři na samoobslužné nástroje pro vývojáře a DevOps inženýři na pipeline a infrastrukturu. Všechny tři obvykle pokryje jeden žebříček; místo samostatných žebříčků upravte formulace kompetencí.

Kdy startup potřebuje prvního DevOps inženýra?

Obvykle když vývojáři tráví znatelnou část týdne nasazováním, prostředími a problémy v produkci místo funkcí nebo když se zákazníci začnou ptát na závazky dostupnosti a bezpečnostní prověrky. V mnoha firmách se to stane zhruba při 15 až 30 vývojářích.

Má se pohotovost započítávat do povýšení DevOps inženýra?

Ano, ale počítejte to, co se lidé naučí a zlepší, ne kolik alertů zvedli. Dobře vedený velký incident, post-mortemy, jejichž opatření se opravdu udělají, a snížení šumu alertů jsou jasným dokladem pro další úroveň. Častá pohotovost jím není.

Záleží u úrovně DevOps inženýra na cloudových certifikacích?

Mohou pomoci platformu se naučit, ale o úrovni by rozhodovat neměly. Hodnoťte podle matice kompetencí, co člověk ve vašem prostředí postavil a provozuje. Certifikát bez takových dokladů další úroveň neprokazuje; takové doklady bez certifikátu ano.

Kolik úrovní potřebuje kariérní žebříček DevOps inženýra?

Tři nebo čtyři, protože infrastrukturní týmy jsou ve firmách této velikosti malé. Tato šablona používá čtyři — Junior, Medior, Senior a Staff — a dobře funguje vedle pětiúrovňového žebříčku softwarového vývojáře, se srovnanými úrovněmi Staff.

Vytvořte tento kariérní žebříček v LadderKitu – zdarma

Nastavte jeho úrovně a dovednosti pro svůj tým, hodnoťte podle nich lidi v check-inech a rozhodujte o povýšení konzistentně.

Tarif Zdarma · Bez platební karty

  • Vývoj

    Softwarový vývojář

    Pět úrovní od Junior po Principal a šest kompetencí, od psaní kódu až po rozvoj týmu.

    • 5 úrovní
    • 6 kompetencí
  • Vývoj

    QA inženýr

    Čtyři úrovně od Junior po Lead QA inženýra a šest kompetencí od návrhu testů po postupy kvality.

    • 4 úrovně
    • 6 kompetencí
  • Vývoj

    Engineering Manager

    Čtyři úrovně od Engineering Managera po VP of Engineering a šest manažerských kompetencí.

    • 4 úrovně
    • 6 kompetencí

Procházet všechny šablony