Fejlesztés
Szoftverfejlesztő
Öt szint a Juniortól a Principalig, hat kompetenciában a kód szállításától a csapat fejlesztéséig.
- 5 szint
- 6 kompetencia
Karrierlétra-sablon
DevOps-mérnöki karrierlétra-sablon
Négy szint a Junior DevOps-mérnöktől a Staff DevOps-mérnökig, hat kompetenciában az infrastruktúrától a fejlesztők támogatásáig.
Ingyenes csomag · Bankkártya nélkül
Ez a karrierlétra DevOps-, platform- és infrastruktúra-mérnököknek szól nagyjából 20–200 fős cégekben. Ekkora méretnél az infrastruktúracsapat általában egy–hat emberből áll, akik a felhőfiókokat, a szállítási pipeline-okat, a monitorozást és az ügyeletet viszik, és ugyanannyi időt töltenek a fejlesztők segítésével, mint a szerverekkel. Négy szintet ír le, a jól körülhatárolt infrastruktúra-módosításokat végző kollégától addig, aki a cég platformjának irányáért felel. A legfelső szint, a Staff DevOps-mérnök, szakértői szint; az infrastruktúracsapat vezetése külön munka.
Minden szintet az határoz meg, amit az ember csinál, és hogy a rendszer mekkora részét bízzák rá, nem a szakmában töltött évek vagy az önéletrajzában felsorolt eszközök száma. A kompetenciamátrix egy sorát balról jobbra olvasva látod, hogyan nő egy elvárás; egy szint szakaszát olvasva mindazt látod, amit azon a szinten elvárnak. Használd arra, hogy elmagyarázd, mit jelent a következő szint, hogy keretet adj a check-ineknek, és hogy megvédhető előléptetési döntéseket hozz.
Közzététel előtt igazítsd a saját helyzetetekhez. Cseréld le az általános megfogalmazásokat a saját technológiai stacketekre és gyakorlataitokra, és hagyd ki azokat a részeket, amelyek egy másik csapathoz tartoznak – például ha a biztonság vagy az adatbázisok máshol vannak.
A szintek áttekintése
Junior DevOps-mérnök
Review mellett jól körülhatárolt módosításokat végez az infrastruktúrán és a pipeline-okon, és megtanulja, hogyan működik az éles környezet.
- Hatókör
- Egyedi módosítások a meglévő infrastruktúrakódban és pipeline-okban, amelyeket egy tapasztaltabb kolléga tervez meg és néz át.
Medior DevOps-mérnök
Elejétől a végéig gazdája az infrastruktúra egyes részeinek, és teljes részt vállal az ügyeletből.
- Hatókör
- Egy-két termékcsapat szolgáltatásai, környezetei vagy pipeline-jai, a tervezéstől a napi üzemeltetésig.
Senior DevOps-mérnök
Olyan infrastruktúra-projekteket tervez és vezet, amelyektől több csapat függ, és emeli a megbízhatósági mércét.
- Hatókör
- A fejlesztés nagy része által használt közös infrastruktúra, és az olyan projektek, például migrációk, amelyek minden csapatot érintenek.
Staff DevOps-mérnök
Kijelöli a cég platformjának irányát, és felel a megbízhatóságáért, a biztonságáért és a költségeiért.
- Hatókör
- A teljes éles platform, annak többéves iránya és költségvetése, az összes fejlesztőcsapatra kiterjedően.
Kompetenciamátrix
Minden sor egy kompetencia, minden oszlop egy szint. Olvass végig egy sort balról jobbra, és látod, hogyan nőnek az elvárások.
Mit jelentenek az egyes kompetenciák
- Infrastruktúra mint kód
- Az infrastruktúra építése és módosítása átnézett, megismételhető kóddal, nem kézzel.
- Build- és szállítási pipeline-ok
- A kód eljuttatása a beolvasztott pull requesttől az éles környezetig, gyorsan és biztonságosan.
- Megbízhatóság és incidenskezelés
- Az éles környezet elérhetőségének fenntartása, és gyors helyreállítás, ha mégsem elérhető.
- Monitorozás és megfigyelhetőség
- Láthatóvá tenni, mit csinál az éles környezet, és tudni, ha valami rosszul megy.
- Biztonság és hozzáférések
- A rendszerek és az adatok védelme biztonságos alapbeállításokkal, a legkisebb jogosultság elvével és gyors javításokkal.
- Fejlesztők támogatása és együttműködés
- Segíteni a fejlesztőknek, hogy maguk üzemeltessék a szolgáltatásaikat, és megosztani a tudást, hogy a platform ne egyetlen emberen múljon.
| Kompetencia | Junior DevOps-mérnök | Medior DevOps-mérnök | Senior DevOps-mérnök | Staff DevOps-mérnök |
|---|---|---|---|---|
| Infrastruktúra mint kód | A már bevett minták szerint módosítja a meglévő infrastruktúrakódot, alkalmazás előtt ellenőrzi a tervezett diffet, és előzetes egyeztetés nélkül soha nem módosítja kézzel az éles környezetet. | Újrahasznosítható infrastruktúramodulokat ír új szolgáltatásokhoz és környezetekhez, biztonságosan kezeli az állapotot és a titkokat, és eltávolítja a már nem használt erőforrásokat. | Megtervezi a cég infrastruktúrakódjának és környezeteinek felépítését, tesztelt visszaállítási tervvel vezeti az olyan változtatásokat, mint a hálózat- vagy klaszterfrissítések, és csapatonként láthatóvá teszi a felhőköltségeket. | Kiválasztja a platform alapvető építőelemeit és szolgáltatóit a következő néhány évre, meghatározza a sztenderdeket, amelyeket minden csapat infrastruktúrája követ, és a vezetőséggel együtt gazdája az infrastruktúra költségvetésének. |
| Build- és szállítási pipeline-ok | Kijavítja a hibás pipeline-lépéseket, egyszerű jobokat ad a meglévő pipeline-okhoz, és elmagyarázza egy fejlesztőnek, miért bukott el a buildje. | Felépíti és karbantartja egy szolgáltatás teljes pipeline-ját – build, tesztek, artefaktumok, telepítés minden környezetbe –, és lerövidíti a lassú lépéseket, amelyekre a fejlesztők panaszkodnak. | Közös pipeline-sablonokat tervez, amelyeket minden csapat használ, biztonságosabb kiadási módszereket vezet be, például canary vagy blue-green telepítést, és követi a telepítési gyakoriságot és a hibaarányt. | Meghatározza, hogyan szállít szoftvert az egész cég a branchelési stratégiától a visszaállításig, és megszünteti azokat a szűk keresztmetszeteket, amelyek az összes csapat szállítását lassítják. |
| Megbízhatóság és incidenskezelés | Tapasztaltabb kolléga mellett ismerkedik az ügyelettel, ismert riasztásoknál a runbookok szerint jár el, és gyorsan eszkalál, átadva azokat az információkat, amelyekre a következő embernek szüksége van. | Teljes részt vállal az ügyeletből, a területén a legtöbb incidenst segítség nélkül megoldja, runbookot ír arról, amit kijavított, és a mentéseket tényleges visszaállítással teszteli. | Vezeti a súlyos incidensek kezelését, hibáztatásmentes post-mortemeket tart, végigviszi a vállalt utólagos teendőket, és megtervezi a kritikus rendszerek kapacitását és failoverét. | A termékkel és a vezetőséggel együtt kitűzi a megbízhatósági célokat, megtervezi az ügyeleti és incidenskezelési folyamatot a teljes fejlesztés számára, és felkészül az olyan katasztrófákra, mint egy régió vagy egy szolgáltató kiesése. |
| Monitorozás és megfigyelhetőség | Meglévő példák alapján dashboardokat és riasztásokat ad hozzá, és ha valami gyanús, először a naplókat és a metrikákat nézi meg. | Naplózást, metrikákat és riasztásokat állít be az új szolgáltatásokhoz, úgy hangolja a riasztásokat, hogy mindegyik teendőt jelentsen, és segít a fejlesztőknek megtalálni az adatokban, amire szükségük van. | Megtervezi a cég fő rendszereinek megfigyelhetőségi megközelítését, meghatározza azokat a szolgáltatásállapot-jelzőket, amelyek alapján a csapatokat mérik, és csapatokon átívelően csökkenti a riasztási zajt. | Kiválasztja a cég megfigyelhetőségi eszközeit és azok költségmodelljét, és gondoskodik róla, hogy a vezetőség mérnök megkérdezése nélkül is lássa a platform állapotát. |
| Biztonság és hozzáférések | Betartja a csapat titkokra és hozzáférésekre vonatkozó szabályait, telepíti a rutinszerű javításokat, és azonnal jelez mindent, ami biztonsági problémának tűnik. | A legkisebb jogosultság elve szerint kezeli a szolgáltatásai hozzáféréseit és titkait, a súlyosságuk szerint javítja a sérülékenységeket, és kijavítja a biztonsági szkennelések által talált problémákat. | Megtervezi a hálózati határokat, az identitás- és titokkezelést a teljes platformon, előkészíti a bizonyítékokat az ügyfelek biztonsági auditjaihoz, és vezeti a biztonsági incidensek kezelését. | A vezetőséggel együtt gazdája a platform biztonsági helyzetének, bevezeti a megfelelőséghez szükséges kontrollokat (például SOC 2 vagy ISO 27001), és minden csapat számára a biztonságos utat teszi a legkönnyebbé. |
| Fejlesztők támogatása és együttműködés | Válaszol a fejlesztők környezetekkel és pipeline-okkal kapcsolatos kérdéseire, dokumentálja az általa végzett javításokat, és korán kér review-t. | Világos útmutatókat ír a gyakori feladatokhoz, párban dolgozik a fejlesztőkkel a szolgáltatásaik telepítésén és hibakeresésén, és bevezeti az új csapattagokat az infrastruktúrába. | Önkiszolgáló eszközöket épít, amelyekkel a csapatok jegy nyitása nélkül hozhatnak létre szolgáltatásokat és környezeteket, mentorálja a többi DevOps-mérnököt, és részt vesz a toborzásban. | Belső termékként alakítja a platformot, amelynek a fejlesztők a felhasználói, eldönti, mi a csapatok és mi a platformcsapat felelőssége, és kineveli a következő senior mérnököket. |
Görgesd oldalra a táblázatot, hogy minden szintet láss.
Letöltés CSV-ben Megnyitható Excelben, Google Táblázatokban vagy Numbersben.
Junior DevOps-mérnök: mit várunk el
Review mellett jól körülhatárolt módosításokat végez az infrastruktúrán és a pipeline-okon, és megtanulja, hogyan működik az éles környezet. Egyedi módosítások a meglévő infrastruktúrakódban és pipeline-okban, amelyeket egy tapasztaltabb kolléga tervez meg és néz át.
- Infrastruktúra mint kód
- A már bevett minták szerint módosítja a meglévő infrastruktúrakódot, alkalmazás előtt ellenőrzi a tervezett diffet, és előzetes egyeztetés nélkül soha nem módosítja kézzel az éles környezetet.
- Build- és szállítási pipeline-ok
- Kijavítja a hibás pipeline-lépéseket, egyszerű jobokat ad a meglévő pipeline-okhoz, és elmagyarázza egy fejlesztőnek, miért bukott el a buildje.
- Megbízhatóság és incidenskezelés
- Tapasztaltabb kolléga mellett ismerkedik az ügyelettel, ismert riasztásoknál a runbookok szerint jár el, és gyorsan eszkalál, átadva azokat az információkat, amelyekre a következő embernek szüksége van.
- Monitorozás és megfigyelhetőség
- Meglévő példák alapján dashboardokat és riasztásokat ad hozzá, és ha valami gyanús, először a naplókat és a metrikákat nézi meg.
- Biztonság és hozzáférések
- Betartja a csapat titkokra és hozzáférésekre vonatkozó szabályait, telepíti a rutinszerű javításokat, és azonnal jelez mindent, ami biztonsági problémának tűnik.
- Fejlesztők támogatása és együttműködés
- Válaszol a fejlesztők környezetekkel és pipeline-okkal kapcsolatos kérdéseire, dokumentálja az általa végzett javításokat, és korán kér review-t.
Medior DevOps-mérnök: mit várunk el
Elejétől a végéig gazdája az infrastruktúra egyes részeinek, és teljes részt vállal az ügyeletből. Egy-két termékcsapat szolgáltatásai, környezetei vagy pipeline-jai, a tervezéstől a napi üzemeltetésig.
- Infrastruktúra mint kód
- Újrahasznosítható infrastruktúramodulokat ír új szolgáltatásokhoz és környezetekhez, biztonságosan kezeli az állapotot és a titkokat, és eltávolítja a már nem használt erőforrásokat.
- Build- és szállítási pipeline-ok
- Felépíti és karbantartja egy szolgáltatás teljes pipeline-ját – build, tesztek, artefaktumok, telepítés minden környezetbe –, és lerövidíti a lassú lépéseket, amelyekre a fejlesztők panaszkodnak.
- Megbízhatóság és incidenskezelés
- Teljes részt vállal az ügyeletből, a területén a legtöbb incidenst segítség nélkül megoldja, runbookot ír arról, amit kijavított, és a mentéseket tényleges visszaállítással teszteli.
- Monitorozás és megfigyelhetőség
- Naplózást, metrikákat és riasztásokat állít be az új szolgáltatásokhoz, úgy hangolja a riasztásokat, hogy mindegyik teendőt jelentsen, és segít a fejlesztőknek megtalálni az adatokban, amire szükségük van.
- Biztonság és hozzáférések
- A legkisebb jogosultság elve szerint kezeli a szolgáltatásai hozzáféréseit és titkait, a súlyosságuk szerint javítja a sérülékenységeket, és kijavítja a biztonsági szkennelések által talált problémákat.
- Fejlesztők támogatása és együttműködés
- Világos útmutatókat ír a gyakori feladatokhoz, párban dolgozik a fejlesztőkkel a szolgáltatásaik telepítésén és hibakeresésén, és bevezeti az új csapattagokat az infrastruktúrába.
Senior DevOps-mérnök: mit várunk el
Olyan infrastruktúra-projekteket tervez és vezet, amelyektől több csapat függ, és emeli a megbízhatósági mércét. A fejlesztés nagy része által használt közös infrastruktúra, és az olyan projektek, például migrációk, amelyek minden csapatot érintenek.
- Infrastruktúra mint kód
- Megtervezi a cég infrastruktúrakódjának és környezeteinek felépítését, tesztelt visszaállítási tervvel vezeti az olyan változtatásokat, mint a hálózat- vagy klaszterfrissítések, és csapatonként láthatóvá teszi a felhőköltségeket.
- Build- és szállítási pipeline-ok
- Közös pipeline-sablonokat tervez, amelyeket minden csapat használ, biztonságosabb kiadási módszereket vezet be, például canary vagy blue-green telepítést, és követi a telepítési gyakoriságot és a hibaarányt.
- Megbízhatóság és incidenskezelés
- Vezeti a súlyos incidensek kezelését, hibáztatásmentes post-mortemeket tart, végigviszi a vállalt utólagos teendőket, és megtervezi a kritikus rendszerek kapacitását és failoverét.
- Monitorozás és megfigyelhetőség
- Megtervezi a cég fő rendszereinek megfigyelhetőségi megközelítését, meghatározza azokat a szolgáltatásállapot-jelzőket, amelyek alapján a csapatokat mérik, és csapatokon átívelően csökkenti a riasztási zajt.
- Biztonság és hozzáférések
- Megtervezi a hálózati határokat, az identitás- és titokkezelést a teljes platformon, előkészíti a bizonyítékokat az ügyfelek biztonsági auditjaihoz, és vezeti a biztonsági incidensek kezelését.
- Fejlesztők támogatása és együttműködés
- Önkiszolgáló eszközöket épít, amelyekkel a csapatok jegy nyitása nélkül hozhatnak létre szolgáltatásokat és környezeteket, mentorálja a többi DevOps-mérnököt, és részt vesz a toborzásban.
Staff DevOps-mérnök: mit várunk el
Kijelöli a cég platformjának irányát, és felel a megbízhatóságáért, a biztonságáért és a költségeiért. A teljes éles platform, annak többéves iránya és költségvetése, az összes fejlesztőcsapatra kiterjedően.
- Infrastruktúra mint kód
- Kiválasztja a platform alapvető építőelemeit és szolgáltatóit a következő néhány évre, meghatározza a sztenderdeket, amelyeket minden csapat infrastruktúrája követ, és a vezetőséggel együtt gazdája az infrastruktúra költségvetésének.
- Build- és szállítási pipeline-ok
- Meghatározza, hogyan szállít szoftvert az egész cég a branchelési stratégiától a visszaállításig, és megszünteti azokat a szűk keresztmetszeteket, amelyek az összes csapat szállítását lassítják.
- Megbízhatóság és incidenskezelés
- A termékkel és a vezetőséggel együtt kitűzi a megbízhatósági célokat, megtervezi az ügyeleti és incidenskezelési folyamatot a teljes fejlesztés számára, és felkészül az olyan katasztrófákra, mint egy régió vagy egy szolgáltató kiesése.
- Monitorozás és megfigyelhetőség
- Kiválasztja a cég megfigyelhetőségi eszközeit és azok költségmodelljét, és gondoskodik róla, hogy a vezetőség mérnök megkérdezése nélkül is lássa a platform állapotát.
- Biztonság és hozzáférések
- A vezetőséggel együtt gazdája a platform biztonsági helyzetének, bevezeti a megfelelőséghez szükséges kontrollokat (például SOC 2 vagy ISO 27001), és minden csapat számára a biztonságos utat teszi a legkönnyebbé.
- Fejlesztők támogatása és együttműködés
- Belső termékként alakítja a platformot, amelynek a fejlesztők a felhasználói, eldönti, mi a csapatok és mi a platformcsapat felelőssége, és kineveli a következő senior mérnököket.
Hogyan igazítsd a saját cégedhez
Nevezd meg a stacketeket az elvárásokban
Az olyan általános kifejezésekkel, mint az „infrastruktúrakód” vagy a „pipeline-ok”, könnyű egyetérteni, de nehéz értékelni őket. Cseréld le őket a valódi eszközeitekre és gyakorlataitokra, hogy egy junior mérnök pontosan tudja, mit kell először megtanulnia.
Ne siesd el a Staff szint bevezetését
Egy–három DevOps-mérnök mellett általában elég a junior, a medior és a senior szint. A Staff szintet akkor vedd fel, amikor valaki ténylegesen kijelöli a platform irányát, és a teljes fejlesztésre kiterjedően gazdája a költségvetésének – ne titulusként a kis csapat legtapasztaltabb tagjának.
Írd bele az ügyeleti szabályokat a karrierlétrába
Rögzítsd, melyik szinten kapcsolódnak be az emberek az ügyeleti beosztásba, mikortól vezetnek incidenseket, és hogyan kompenzáljátok az ügyeleti időt. A le nem írt ügyeleti elvárások az egyik leggyakoribb okai annak, hogy az infrastruktúra-mérnökök kiégnek és távoznak.
Igazítsd a szinteket a szoftverfejlesztői karrierlétrához
Rendelj minden DevOps-szinthez egy azonos hatókörű és fizetésű szoftverfejlesztői szintet. A platformmunka is fejlesztői munka, és ha a két karrierlétra összhangban van, egyszerű lesz a váltás a termék- és a platformcsapatok között.
GYIK
Kérdések erről a létráról
Mi a különbség a DevOps-mérnök, az SRE és a platformmérnök között?
Szigorúan véve a DevOps munkamódszer, nem titulus; a gyakorlatban egy 20–200 fős cégnél ezek a titulusok többnyire ugyanazt a munkát írják le, eltérő hangsúllyal: az SRE-k a megbízhatósági célokra – jellemzően SLO-kra és hibakeretekre (error budget) – és az incidensekre összpontosítanak, a platformmérnökök a fejlesztőknek szóló önkiszolgáló eszközökre, a DevOps-mérnökök pedig a pipeline-okra és az infrastruktúrára. Általában egy karrierlétra lefedi mindhármat; inkább a kompetenciák megfogalmazását igazítsd, mint hogy külön karrierlétrákat hozz létre.
Mikor van szüksége egy startupnak az első DevOps-mérnökére?
Általában akkor, amikor a fejlesztők a hetük érezhető részét funkciók helyett telepítésekkel, környezetekkel és éles hibákkal töltik, vagy amikor az ügyfelek rendelkezésre állási vállalásokat és biztonsági auditokat kezdenek kérni. Sok cégnél ez nagyjából 15–30 fejlesztőnél következik be.
Beleszámítson az ügyelet egy DevOps-mérnök előléptetésébe?
Igen, de azt számold, amit az illető megtanul és javít, ne azt, hány riasztásra reagált. Egy súlyos incidens jó levezetése, olyan post-mortemek, amelyeknek a teendői el is készülnek, és a riasztási zaj csökkentése egyértelmű bizonyítékai a következő szintnek. A gyakori ügyelet nem az.
Számítanak a felhős tanúsítványok egy DevOps-mérnök szintjénél?
Segíthetnek valakinek megtanulni egy platformot, de nem ezek döntik el a szintet. A kompetenciamátrix alapján azt értékeld, amit az illető a ti környezetetekben épített és üzemeltetett. Egy tanúsítvány ilyen bizonyíték nélkül nem igazolja a következő szintet; ilyen bizonyíték tanúsítvány nélkül igen.
Hány szint kell egy DevOps-mérnöki karrierlétrába?
Három vagy négy, mert ekkora cégeknél az infrastruktúracsapatok kicsik. Ez a sablon négyet használ – Junior, Medior, Senior és Staff DevOps-mérnök –, és jól működik egy ötszintű szoftverfejlesztői karrierlétra mellett, egymáshoz igazított Staff szintekkel.
Építsd fel ezt a karrierlétrát a LadderKitben – ingyen
Állítsd be a szintjeit és készségeit a csapatodnak, mérd hozzájuk az embereket a check-ineken, és tartsd következetesen az előléptetési döntéseket.
Ingyenes csomag · Bankkártya nélkül
Kapcsolódó sablonok
Fejlesztés
QA-mérnök
Négy szint a Junior QA-mérnöktől a Lead QA-mérnökig, hat kompetenciában a teszttervezéstől a minőségi gyakorlatokig.
- 4 szint
- 6 kompetencia
Fejlesztés
Fejlesztési vezető
Négy szint az Engineering Managertől a VP of Engineeringig, hat vezetői kompetenciában.
- 4 szint
- 6 kompetencia