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í
Šablona kariérního žebříčku
Č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ý.
S revizí dělá dobře vymezené změny v infrastruktuře a pipeline a učí se, jak běží produkce.
Odpovídá za části infrastruktury od začátku do konce a plně se podílí na pohotovosti.
Navrhuje a vede infrastrukturní projekty, na kterých závisí několik týmů, a zvyšuje laťku spolehlivosti.
Určuje směr firemní platformy a odpovídá za její spolehlivost, bezpečnost a náklady.
Každý řádek je kompetence a každý sloupec úroveň. Čtěte řádek zleva doprava a uvidíte, jak očekávání rostou.
| Kompetence | Junior DevOps inženýr | Medior DevOps inženýr | Senior DevOps inženýr | Staff DevOps inženýr |
|---|---|---|---|---|
| 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. | 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 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. | 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ří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í. | 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á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. | 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.
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ší.
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.
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.
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.
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.
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.
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.
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
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í.
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.
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í.
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.
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.
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
Pět úrovní od Junior po Principal a šest kompetencí, od psaní kódu až po rozvoj týmu.
Vývoj
Čtyři úrovně od Junior po Lead QA inženýra a šest kompetencí od návrhu testů po postupy kvality.
Vývoj
Čtyři úrovně od Engineering Managera po VP of Engineering a šest manažerských kompetencí.