Izstrāde
Programmatūras izstrādātājs
Pieci līmeņi no jaunākā izstrādātāja līdz galvenajam inženierim sešās kompetencēs — no koda piegādes līdz komandas izaugsmei.
- 5 līmeņi
- 6 kompetences
Karjeras kāpņu veidne
DevOps inženiera karjeras kāpņu veidne
Četri līmeņi no jaunākā līdz vadošajam DevOps inženierim sešās kompetencēs — no infrastruktūras līdz atbalstam izstrādātājiem.
Bezmaksas plāns · Kredītkarte nav vajadzīga
Šīs karjeras kāpnes ir paredzētas DevOps, platformas un infrastruktūras inženieriem uzņēmumos ar aptuveni 20–200 darbiniekiem. Šādā izmērā infrastruktūras komandā parasti ir viens līdz seši cilvēki, kuri pārvalda mākoņa kontus, piegādes konveijerus, monitoringu un dežūras un kuri tikpat daudz laika velta palīdzībai izstrādātājiem kā darbam ar serveriem. Tās apraksta četrus līmeņus — no cilvēka, kurš veic skaidri definētas infrastruktūras izmaiņas, līdz cilvēkam, kurš atbild par uzņēmuma platformas attīstības kursu. Augstākais līmenis, vadošais DevOps inženieris, ir speciālista līmenis; infrastruktūras komandas vadīšana ir atsevišķs darbs.
Katru līmeni nosaka tas, ko cilvēks dara un cik lielu sistēmas daļu viņam uztic, nevis darba stāžs vai rīku skaits CV. Lasiet kompetenču matricas rindu no kreisās uz labo, lai redzētu, kā aug viena prasība; lasiet līmeņa sadaļu, lai redzētu visu, kas šajā līmenī sagaidāms. Izmantojiet tās, lai paskaidrotu, ko nozīmē nākamais līmenis, lai strukturētu check-in sarunas un lai pieņemtu paaugstinājuma lēmumus, kurus varat pamatot.
Pielāgojiet tās pirms publicēšanas. Aizstājiet vispārīgos formulējumus ar saviem tehnoloģiju rīkiem un praksi un izņemiet daļas, kas pieder citai komandai, — piemēram, ja par drošību vai datubāzēm atbild kāds cits.
Līmeņi īsumā
Jaunākais DevOps inženieris
Veic skaidri definētas izmaiņas infrastruktūrā un konveijeros ar pārskatīšanu un mācās, kā darbojas produkcija.
- Atbildības joma
- Atsevišķas izmaiņas esošajā infrastruktūras kodā un konveijeros, kuras plāno un pārskata kāds pieredzējušāks kolēģis.
DevOps inženieris
Pilnībā atbild par infrastruktūras daļām un piedalās dežūrās vienlīdzīgi ar citiem.
- Atbildības joma
- Servisi, vides vai konveijeri vienai vai divām produkta komandām — no projektēšanas līdz ikdienas darbībai.
Vecākais DevOps inženieris
Projektē un vada infrastruktūras projektus, no kuriem ir atkarīgas vairākas komandas, un paaugstina uzticamības latiņu.
- Atbildības joma
- Kopīgā infrastruktūra, ko izmanto lielākā daļa inženierijas, un projekti, piemēram, migrācijas, kas skar katru komandu.
Vadošais DevOps inženieris
Nosaka uzņēmuma platformas attīstības kursu un atbild par tās uzticamību, drošību un izmaksām.
- Atbildības joma
- Visa produkcijas platforma, tās attīstība vairāku gadu garumā un tās budžets visās inženierijas komandās.
Kompetenču matrica
Katra rinda ir kompetence, katra kolonna — līmenis. Lasiet rindu no kreisās uz labo, lai redzētu, kā aug prasības.
Ko nozīmē katra kompetence
- Infrastruktūra kā kods
- Infrastruktūras veidošana un mainīšana ar pārskatītu, atkārtojamu kodu, nevis manuāli.
- Būvēšanas un piegādes konveijeri
- Koda nogādāšana no sapludināta izmaiņu pieprasījuma līdz produkcijai — ātri un droši.
- Uzticamība un reaģēšana uz incidentiem
- Produkcijas pieejamības uzturēšana un ātra atjaunošana, ja tā nav pieejama.
- Monitorings un novērojamība
- Iespēja redzēt, kas notiek produkcijā, un uzzināt, kad kaut kas noiet greizi.
- Drošība un piekļuve
- Sistēmu un datu aizsardzība ar drošiem noklusējumiem, minimālām privilēģijām un ātru ielāpu uzstādīšanu.
- Atbalsts izstrādātājiem un sadarbība
- Palīdzība izstrādātājiem pašiem uzturēt savus servisus un zināšanu nodošana, lai platforma nebūtu atkarīga no viena cilvēka.
| Kompetence | Jaunākais DevOps inženieris | DevOps inženieris | Vecākais DevOps inženieris | Vadošais DevOps inženieris |
|---|---|---|---|---|
| Infrastruktūra kā kods | Maina esošo infrastruktūras kodu, ievērojot jau iedibinātos modeļus, pirms piemērošanas pārbauda plānoto izmaiņu sarakstu un nekad nemaina produkciju manuāli, iepriekš nepajautājot. | Raksta atkārtoti izmantojamus infrastruktūras moduļus jauniem servisiem un vidēm, droši apietas ar stāvokli un noslēpumiem un izņem resursus, kas vairs netiek izmantoti. | Projektē uzņēmuma infrastruktūras koda un vižu uzbūvi, vada tādas izmaiņas kā tīkla vai klasteru atjauninājumi ar pārbaudītu atcelšanas plānu un uztur mākoņa izmaksas redzamas katrai komandai. | Izvēlas platformas pamatelementus un pakalpojumu sniedzējus nākamajiem gadiem, nosaka standartus, kuriem seko katras komandas infrastruktūra, un kopā ar vadību atbild par infrastruktūras budžetu. |
| Būvēšanas un piegādes konveijeri | Labo salūzušus konveijera soļus un pievieno vienkāršus darbus esošajiem konveijeriem, kā arī paskaidro izstrādātājam, kāpēc viņa būvējums neizdevās. | Izveido un uztur pilnu servisa konveijeru — būvēšanu, testus, artefaktus, izvietošanu katrā vidē — un saīsina lēnos soļus, par kuriem sūdzas izstrādātāji. | Projektē kopīgas konveijeru veidnes, ko izmanto katra komanda, ievieš drošākas laidienu metodes, piemēram, canary vai blue-green izvietošanu, un seko izvietošanas biežumam un neveiksmju īpatsvaram. | Nosaka, kā viss uzņēmums piegādā programmatūru — no zarošanas līdz atcelšanai —, un novērš sašaurinājumus, kas palēnina piegādi visās komandās. |
| Uzticamība un reaģēšana uz incidentiem | Dežūrē kopā ar pieredzējušāku kolēģi, zināmiem brīdinājumiem seko rīcības instrukcijām un ātri eskalē, nododot informāciju, kas vajadzīga nākamajam cilvēkam. | Piedalās dežūrās vienlīdzīgi ar citiem, lielāko daļu savas jomas incidentu atrisina bez palīdzības, raksta rīcības instrukcijas par to, ko izlaboja, un pārbauda rezerves kopijas, tās tiešām atjaunojot. | Vada reaģēšanu uz lieliem incidentiem, rīko pēcincidentu analīzes bez vainīgo meklēšanas un panāk turpmāko darbību izpildi, kā arī plāno kritisko sistēmu jaudu un rezerves pārslēgšanos. | Kopā ar produkta kolēģiem un vadību nosaka uzticamības mērķus, projektē dežūru un incidentu procesu visai inženierijai un plāno rīcību katastrofās, piemēram, zaudējot reģionu vai pakalpojuma sniedzēju. |
| Monitorings un novērojamība | Pievieno informācijas paneļus un brīdinājumus pēc esošiem piemēriem un, ja kaut kas šķiet aizdomīgs, vispirms pārbauda žurnālus un metrikas. | Iestata žurnālošanu, metrikas un brīdinājumus jauniem servisiem, noregulē brīdinājumus tā, lai katrs izsaukums prasītu rīcību, un palīdz izstrādātājiem atrast datos vajadzīgo. | Projektē novērojamības pieeju uzņēmuma galvenajām sistēmām, definē servisu veselības signālus, pēc kuriem mēra komandas, un samazina brīdinājumu troksni vairākās komandās. | Izvēlas uzņēmuma novērojamības rīkus un to izmaksu modeli un nodrošina, ka vadība var redzēt platformas veselību, nejautājot inženierim. |
| Drošība un piekļuve | Ievēro komandas noteikumus par noslēpumiem un piekļuvi, uzstāda kārtējos ielāpus un nekavējoties ziņo par visu, kas izskatās pēc drošības problēmas. | Pārvalda savu servisu piekļuvi un noslēpumus pēc minimālo privilēģiju principa, novērš ievainojamības atbilstoši to nopietnībai un izlabo drošības skenēšanā atrasto. | Projektē tīkla robežas, identitāšu un noslēpumu pārvaldību visā platformā, sagatavo pierādījumus klientu drošības pārbaudēm un vada reaģēšanu uz drošības incidentiem. | Kopā ar vadību atbild par platformas drošības stāvokli, nosaka kontroles, ko prasa atbilstība (piemēram, SOC 2 vai ISO 27001), un padara drošo ceļu par vienkāršāko katrai komandai. |
| Atbalsts izstrādātājiem un sadarbība | Atbild uz izstrādātāju jautājumiem par vidēm un konveijeriem, dokumentē veiktos labojumus un laikus lūdz pārskatīšanu. | Raksta skaidras instrukcijas biežākajiem uzdevumiem, kopā ar izstrādātājiem izvieto un atkļūdo viņu servisus un ievada jaunus komandas biedrus infrastruktūrā. | Veido pašapkalpošanās rīkus, ar kuriem komandas var izveidot servisus un vides, neiesniedzot pieteikumu, mentorē citus DevOps inženierus un piedalās darbinieku atlasē. | Veido platformu kā iekšēju produktu, kura lietotāji ir izstrādātāji, izlemj, par ko atbild komandas un par ko platformas komanda, un sagatavo nākamos vecākos inženierus. |
Ritiniet tabulu uz sāniem, lai redzētu visus līmeņus.
Lejupielādēt CSV Atveras programmās Excel, Google Sheets vai Numbers.
Jaunākais DevOps inženieris: ko sagaida
Veic skaidri definētas izmaiņas infrastruktūrā un konveijeros ar pārskatīšanu un mācās, kā darbojas produkcija. Atsevišķas izmaiņas esošajā infrastruktūras kodā un konveijeros, kuras plāno un pārskata kāds pieredzējušāks kolēģis.
- Infrastruktūra kā kods
- Maina esošo infrastruktūras kodu, ievērojot jau iedibinātos modeļus, pirms piemērošanas pārbauda plānoto izmaiņu sarakstu un nekad nemaina produkciju manuāli, iepriekš nepajautājot.
- Būvēšanas un piegādes konveijeri
- Labo salūzušus konveijera soļus un pievieno vienkāršus darbus esošajiem konveijeriem, kā arī paskaidro izstrādātājam, kāpēc viņa būvējums neizdevās.
- Uzticamība un reaģēšana uz incidentiem
- Dežūrē kopā ar pieredzējušāku kolēģi, zināmiem brīdinājumiem seko rīcības instrukcijām un ātri eskalē, nododot informāciju, kas vajadzīga nākamajam cilvēkam.
- Monitorings un novērojamība
- Pievieno informācijas paneļus un brīdinājumus pēc esošiem piemēriem un, ja kaut kas šķiet aizdomīgs, vispirms pārbauda žurnālus un metrikas.
- Drošība un piekļuve
- Ievēro komandas noteikumus par noslēpumiem un piekļuvi, uzstāda kārtējos ielāpus un nekavējoties ziņo par visu, kas izskatās pēc drošības problēmas.
- Atbalsts izstrādātājiem un sadarbība
- Atbild uz izstrādātāju jautājumiem par vidēm un konveijeriem, dokumentē veiktos labojumus un laikus lūdz pārskatīšanu.
DevOps inženieris: ko sagaida
Pilnībā atbild par infrastruktūras daļām un piedalās dežūrās vienlīdzīgi ar citiem. Servisi, vides vai konveijeri vienai vai divām produkta komandām — no projektēšanas līdz ikdienas darbībai.
- Infrastruktūra kā kods
- Raksta atkārtoti izmantojamus infrastruktūras moduļus jauniem servisiem un vidēm, droši apietas ar stāvokli un noslēpumiem un izņem resursus, kas vairs netiek izmantoti.
- Būvēšanas un piegādes konveijeri
- Izveido un uztur pilnu servisa konveijeru — būvēšanu, testus, artefaktus, izvietošanu katrā vidē — un saīsina lēnos soļus, par kuriem sūdzas izstrādātāji.
- Uzticamība un reaģēšana uz incidentiem
- Piedalās dežūrās vienlīdzīgi ar citiem, lielāko daļu savas jomas incidentu atrisina bez palīdzības, raksta rīcības instrukcijas par to, ko izlaboja, un pārbauda rezerves kopijas, tās tiešām atjaunojot.
- Monitorings un novērojamība
- Iestata žurnālošanu, metrikas un brīdinājumus jauniem servisiem, noregulē brīdinājumus tā, lai katrs izsaukums prasītu rīcību, un palīdz izstrādātājiem atrast datos vajadzīgo.
- Drošība un piekļuve
- Pārvalda savu servisu piekļuvi un noslēpumus pēc minimālo privilēģiju principa, novērš ievainojamības atbilstoši to nopietnībai un izlabo drošības skenēšanā atrasto.
- Atbalsts izstrādātājiem un sadarbība
- Raksta skaidras instrukcijas biežākajiem uzdevumiem, kopā ar izstrādātājiem izvieto un atkļūdo viņu servisus un ievada jaunus komandas biedrus infrastruktūrā.
Vecākais DevOps inženieris: ko sagaida
Projektē un vada infrastruktūras projektus, no kuriem ir atkarīgas vairākas komandas, un paaugstina uzticamības latiņu. Kopīgā infrastruktūra, ko izmanto lielākā daļa inženierijas, un projekti, piemēram, migrācijas, kas skar katru komandu.
- Infrastruktūra kā kods
- Projektē uzņēmuma infrastruktūras koda un vižu uzbūvi, vada tādas izmaiņas kā tīkla vai klasteru atjauninājumi ar pārbaudītu atcelšanas plānu un uztur mākoņa izmaksas redzamas katrai komandai.
- Būvēšanas un piegādes konveijeri
- Projektē kopīgas konveijeru veidnes, ko izmanto katra komanda, ievieš drošākas laidienu metodes, piemēram, canary vai blue-green izvietošanu, un seko izvietošanas biežumam un neveiksmju īpatsvaram.
- Uzticamība un reaģēšana uz incidentiem
- Vada reaģēšanu uz lieliem incidentiem, rīko pēcincidentu analīzes bez vainīgo meklēšanas un panāk turpmāko darbību izpildi, kā arī plāno kritisko sistēmu jaudu un rezerves pārslēgšanos.
- Monitorings un novērojamība
- Projektē novērojamības pieeju uzņēmuma galvenajām sistēmām, definē servisu veselības signālus, pēc kuriem mēra komandas, un samazina brīdinājumu troksni vairākās komandās.
- Drošība un piekļuve
- Projektē tīkla robežas, identitāšu un noslēpumu pārvaldību visā platformā, sagatavo pierādījumus klientu drošības pārbaudēm un vada reaģēšanu uz drošības incidentiem.
- Atbalsts izstrādātājiem un sadarbība
- Veido pašapkalpošanās rīkus, ar kuriem komandas var izveidot servisus un vides, neiesniedzot pieteikumu, mentorē citus DevOps inženierus un piedalās darbinieku atlasē.
Vadošais DevOps inženieris: ko sagaida
Nosaka uzņēmuma platformas attīstības kursu un atbild par tās uzticamību, drošību un izmaksām. Visa produkcijas platforma, tās attīstība vairāku gadu garumā un tās budžets visās inženierijas komandās.
- Infrastruktūra kā kods
- Izvēlas platformas pamatelementus un pakalpojumu sniedzējus nākamajiem gadiem, nosaka standartus, kuriem seko katras komandas infrastruktūra, un kopā ar vadību atbild par infrastruktūras budžetu.
- Būvēšanas un piegādes konveijeri
- Nosaka, kā viss uzņēmums piegādā programmatūru — no zarošanas līdz atcelšanai —, un novērš sašaurinājumus, kas palēnina piegādi visās komandās.
- Uzticamība un reaģēšana uz incidentiem
- Kopā ar produkta kolēģiem un vadību nosaka uzticamības mērķus, projektē dežūru un incidentu procesu visai inženierijai un plāno rīcību katastrofās, piemēram, zaudējot reģionu vai pakalpojuma sniedzēju.
- Monitorings un novērojamība
- Izvēlas uzņēmuma novērojamības rīkus un to izmaksu modeli un nodrošina, ka vadība var redzēt platformas veselību, nejautājot inženierim.
- Drošība un piekļuve
- Kopā ar vadību atbild par platformas drošības stāvokli, nosaka kontroles, ko prasa atbilstība (piemēram, SOC 2 vai ISO 27001), un padara drošo ceļu par vienkāršāko katrai komandai.
- Atbalsts izstrādātājiem un sadarbība
- Veido platformu kā iekšēju produktu, kura lietotāji ir izstrādātāji, izlemj, par ko atbild komandas un par ko platformas komanda, un sagatavo nākamos vecākos inženierus.
Kā pielāgot šīs kāpnes
Nosauciet prasībās savus rīkus
Vispārīgām frāzēm, piemēram, „infrastruktūras kods“ vai „konveijeri“, ir viegli piekrist un grūti tās novērtēt. Aizstājiet tās ar saviem reālajiem rīkiem un praksi, lai jaunākais inženieris precīzi zinātu, kas viņam jāapgūst vispirms.
Nesteidzieties ieviest vadošā inženiera līmeni
Ja jums ir viens līdz trīs DevOps inženieri, parasti pietiek ar jaunāko, vidējo un vecāko līmeni. Pievienojiet vadošā inženiera līmeni, kad kāds tiešām nosaka platformas attīstības kursu un atbild par tās budžetu visā inženierijā, nevis kā amata nosaukumu pieredzējušākajam cilvēkam nelielā komandā.
Ierakstiet dežūru noteikumus karjeras kāpnēs
Norādiet, kurā līmenī cilvēki pievienojas dežūru grafikam, kad viņi vada incidentus un kā tiek kompensēts dežūru laiks. Nepierakstītas gaidas attiecībā uz dežūrām ir viens no biežākajiem iemesliem, kāpēc infrastruktūras inženieri izdeg un aiziet.
Salāgojiet līmeņus ar izstrādātāju karjeras kāpnēm
Piesaistiet katru DevOps līmeni izstrādātāja līmenim ar tādu pašu atbildības apjomu un atalgojumu. Platformas darbs ir inženierijas darbs, un, ja abas karjeras kāpnes ir salāgotas, pāreja starp produkta un platformas komandām ir vienkārša.
BUJ
Jautājumi par šīm kāpnēm
Kāda ir atšķirība starp DevOps inženieri, SRE un platformas inženieri?
Stingri ņemot, DevOps ir darba veids, nevis amata nosaukums; praksē uzņēmumos ar 20–200 darbiniekiem šie nosaukumi lielākoties apzīmē vienu un to pašu darbu ar atšķirīgu uzsvaru: SRE koncentrējas uz uzticamības mērķiem — parasti SLO un kļūdu budžetiem — un incidentiem, platformas inženieri uz pašapkalpošanās rīkiem izstrādātājiem, bet DevOps inženieri uz konveijeriem un infrastruktūru. Parasti visus trīs aptver vienas karjeras kāpnes; pielāgojiet kompetenču formulējumus, nevis veidojiet atsevišķas karjeras kāpnes.
Kad jaunuzņēmumam vajag pirmo DevOps inženieri?
Parasti tad, kad izstrādātāji ievērojamu nedēļas daļu velta izvietošanai, vidēm un produkcijas problēmām, nevis funkcijām, vai kad klienti sāk prasīt pieejamības saistības un drošības pārbaudes. Daudziem uzņēmumiem tas notiek, kad tajos ir aptuveni 15–30 inženieru.
Vai dežūru darbs jāņem vērā, lemjot par DevOps inženiera paaugstinājumu?
Jā, taču vērtējiet to, ko cilvēki iemācās un uzlabo, nevis to, uz cik izsaukumiem viņi atbildējuši. Labi vadīts liels incidents, pēcincidentu analīzes, kuru darbības tiek izpildītas, un mazāks brīdinājumu troksnis ir skaidri pierādījumi nākamajam līmenim. Bieža dežurēšana tāds pierādījums nav.
Vai mākoņu sertifikāti ietekmē DevOps inženiera līmeni?
Tie var palīdzēt apgūt platformu, taču tiem nevajadzētu noteikt līmeni. Novērtējiet, ko cilvēks ir izveidojis un uzturējis jūsu vidē, salīdzinot to ar kompetenču matricu. Sertifikāts bez šādiem pierādījumiem neapliecina nākamo līmeni; šādi pierādījumi bez sertifikāta to apliecina.
Cik līmeņu vajag DevOps inženiera karjeras kāpnēm?
Trīs vai četrus, jo infrastruktūras komandas šāda izmēra uzņēmumos ir nelielas. Šajā veidnē ir četri — jaunākais DevOps inženieris, DevOps inženieris, vecākais un vadošais DevOps inženieris —, un tā labi darbojas līdzās piecu līmeņu izstrādātāja karjeras kāpnēm, ja vadošie līmeņi ir salāgoti.
Izveidojiet šīs karjeras kāpnes platformā LadderKit — bez maksas
Iestatiet to līmeņus un prasmes savai komandai, vērtējiet cilvēkus pēc tiem check-in sarunās un pieņemiet konsekventus lēmumus par paaugstinājumiem.
Bezmaksas plāns · Kredītkarte nav vajadzīga
Saistītās veidnes
Izstrāde
QA inženieris
Četri līmeņi no jaunākā līdz vadošajam QA inženierim sešās kompetencēs — no testu projektēšanas līdz kvalitātes praksei.
- 4 līmeņi
- 6 kompetences
Izstrāde
Izstrādes vadītājs
Četri līmeņi no izstrādes vadītāja līdz izstrādes viceprezidentam sešās vadības kompetencēs.
- 4 līmeņi
- 6 kompetences