Šobrīd šī ir gandrīz visdārgākā pozīcija tirgū. Satraukums ap “DevOps” inženieriem pārsniedz visus iedomājamos ierobežojumus, un tas ir vēl sliktāks ar vecāka gadagājuma DevOps inženieriem.
Es strādāju par integrācijas un automatizācijas nodaļas vadītāju, uzminiet angļu valodas dekodēšanu - DevOps Manager. Diez vai angļu stenogramma atspoguļo mūsu ikdienas aktivitātes, taču krievu versija šajā gadījumā ir precīzāka. Manas darbības rakstura dēļ ir likumsakarīgi, ka man ir jāintervē nākamie savas komandas locekļi, un pēdējā gada laikā caur mani ir izgājuši apmēram 50 cilvēki, un tikpat daudz ir nogriezts priekšskatījumā ar maniem darbiniekiem.
Joprojām meklējam kolēģus, jo aiz DevOps etiķetes slēpjas ļoti liels slānis dažāda veida inženieru.
Viss zemāk rakstītais ir mans personīgais viedoklis, tam nav jāpiekrīt, bet pieļauju, ka tas pieliks kādu krāsu tavai attieksmei pret tēmu. Neskatoties uz risku izkrist no labvēlības, publicēju savu viedokli, jo uzskatu, ka tam ir kur būt.
Uzņēmumiem ir atšķirīga izpratne par to, kas ir DevOps inženieri, un, lai ātri pieņemtu darbā resursus, tie visiem pieliek šo etiķeti. Situācija ir visai dīvaina, jo uzņēmumi ir gatavi šiem cilvēkiem maksāt nereālus atalgojumus, vairumā gadījumu par tiem saņemot rīku administratoru.
Tātad, kas ir DevOps inženieri?
Sāksim ar tā parādīšanās vēsturi – attīstības operācijas parādījās kā vēl viens solis ceļā uz mijiedarbības optimizēšanu mazās komandās, lai palielinātu produktu ražošanas ātrumu, kā paredzamās sekas. Ideja bija stiprināt izstrādes komandu ar zināšanām par procedūrām un pieejām produktu vides pārvaldībā. Citiem vārdiem sakot, izstrādātājam ir jāsaprot un jāzina, kā viņa produkts darbojas noteiktos apstākļos, ir jāsaprot, kā izvietot savu produktu, kādas vides īpašības var pielāgot, lai uzlabotu veiktspēju. Tātad kādu laiku parādījās izstrādātāji ar DevOps pieeju. DevOps izstrādātāji rakstīja veidošanas un iepakošanas skriptus, lai vienkāršotu savas darbības un ražošanas vides veiktspēju. Tomēr risinājuma arhitektūras sarežģītība un infrastruktūras komponentu savstarpējā ietekme laika gaitā sāka pasliktināt vidi veiktspēju; ar katru iterāciju bija nepieciešama arvien dziļāka izpratne par atsevišķiem komponentiem, samazinot izstrādātāja produktivitāti papildu izmaksas, kas saistītas ar komponentu un regulēšanas sistēmu izpratni konkrētam uzdevumam. Pieauga paša izstrādātāja pašizmaksa, līdz ar to arī produkta pašizmaksa, strauji uzlēca prasības jaunajiem izstrādātājiem komandā, jo bija jāsedz arī izstrādes “zvaigznes” pienākumi un, protams, “zvaigžņu” kļuva mazāk. un mazāk pieejami. Ir arī vērts atzīmēt, ka, pēc manas pieredzes, dažus izstrādātājus interesē operētājsistēmas kodola pakešu apstrādes specifika, pakešu maršrutēšanas noteikumi un resursdatora drošības aspekti. Loģisks solis bija piesaistīt administratoru, kurš to pārzina un viņam uzticēt līdzīgus pienākumus, kas, pateicoties viņa pieredzei, ļāva sasniegt tos pašus rādītājus ar zemākām izmaksām, salīdzinot ar “zvaigznes” izstrādes izmaksām. Šādi administratori tika ievietoti komandā, un viņa galvenais uzdevums bija pārvaldīt testēšanas un ražošanas vidi, saskaņā ar noteiktas komandas noteikumiem, ar resursiem, kas piešķirti šai komandai. Tā patiesībā DevOps parādījās vairākuma prātos.
Daļēji vai pilnībā ar laiku šie sistēmu administratori sāka izprast šīs konkrētās komandas vajadzības izstrādes jomā, kā atvieglot dzīvi izstrādātājiem un testētājiem, kā izlaist atjauninājumu un nav jāpaliek pa nakti piektdien birojā, labojot izvietošanas kļūdas. Laiks pagāja, un tagad “zvaigznes” bija sistēmu administratori, kuri saprata, ko izstrādātāji vēlas. Lai samazinātu ietekmi, sāka parādīties pārvaldības utilītas; visi atcerējās vecās un uzticamās OS līmeņa izolācijas metodes, kas ļāva samazināt prasības drošībai, tīkla daļas pārvaldībai un resursdatora konfigurācijai. kopumā un rezultātā samazinās prasības pēc jaunām “zvaigznēm”.
Ir parādījusies "brīnišķīga" lieta - dokeris. Kāpēc brīnišķīgi? Jā, tikai tāpēc, ka, lai izveidotu izolāciju chroot vai cietumā, kā arī OpenVZ, bija nepieciešamas netriviālas zināšanas par OS, turpretim utilīta ļauj vienkārši izveidot izolētu lietojumprogrammu vidi noteiktā resursdatorā ar visu nepieciešamo iekšpusē un rokā. atkal pāri attīstības grožiem, un sistēmas administrators var pārvaldīt tikai ar vienu resursdatoru, nodrošinot tā drošību un augstu pieejamību - loģisks vienkāršojums. Taču progress nestāv uz vietas un sistēmas atkal kļūst arvien sarežģītākas, komponentu ir arvien vairāk, viens resursdators vairs neatbilst sistēmas vajadzībām un ir jāveido klasteri, mēs atkal atgriežamies pie sistēmu administratoriem, kuri ir spēj izveidot šīs sistēmas.
Ciklu pēc cikla parādās dažādas sistēmas, kas vienkāršo izstrādi un/vai administrēšanu, parādās orķestrēšanas sistēmas, kuras, kamēr nav jāatkāpjas no standarta procesa, ir ērti lietojamas. Mikropakalpojumu arhitektūra parādījās arī ar mērķi vienkāršot visu iepriekš aprakstīto – mazāk attiecību, vieglāk pārvaldīt. Pēc savas pieredzes es neatradu pilnībā mikropakalpojumu arhitektūru, es teiktu, 50 līdz 50 - 50 procenti mikropakalpojumu, melnās kastes, ienāca, iznāca apstrādāti, pārējie 50 ir saplēsts monolīts, servisi nespēj strādāt atsevišķi no citiem. sastāvdaļas. Tas viss atkal uzlika ierobežojumus gan izstrādātāju, gan administratoru zināšanu līmenim.
Līdzīgas “šūpoles” ekspertu zināšanu līmenī par konkrētu resursu turpinās līdz pat šai dienai. Bet mēs nedaudz novirzāmies, ir daudzi punkti, kurus vērts izcelt.
Celtniecības inženieris/izlaiduma inženieris
Ļoti augsti specializēti inženieri, kas parādījās kā līdzeklis programmatūras veidošanas procesu un izlaidumu standartizēšanai. Plaši izplatītā Agile ieviešanas procesā šķiet, ka tie vairs nav pieprasīti, taču tas nebūt nav tā. Šī specializācija parādījās kā līdzeklis programmatūras montāžas un piegādes standartizēšanai rūpnieciskā mērogā, t.i. izmantojot standarta metodes visiem uzņēmuma produktiem. Līdz ar DevOps parādīšanos izstrādātāji daļēji zaudēja savas funkcijas, jo tieši izstrādātāji sāka gatavot produktu piegādei, un, ņemot vērā mainīgo infrastruktūru un pieeju piegādei pēc iespējas ātrāk, neņemot vērā kvalitāti, laika gaitā tie kļuva par izmaiņu apturētājs, jo kvalitātes standartu ievērošana neizbēgami bremzē piegādes. Tāpēc pakāpeniski daļa no Build/Release inženieru funkcionalitātes pārgāja uz sistēmas administratoru pleciem.
Ops ir tik dažādas
Mēs virzāmies uz priekšu un atkal liela pienākumu loka klātbūtne un kvalificēta personāla trūkums virza mūs uz stingru specializāciju, kā sēnes pēc lietus, parādās dažādas Operācijas:
- TechOps — enikey sistēmas administratori jeb HelpDesk Engineer
- LiveOps — sistēmu administratori, kas galvenokārt ir atbildīgi par ražošanas vidēm
- CloudOps — sistēmu administratori, kas specializējas publiskos mākoņos Azure, AWS, GCP utt.
- PlatOps/InfraOps/SysOps – infrastruktūras sistēmu administratori.
- NetOps - tīkla administratori
- SecOps - sistēmu administratori, kas specializējas informācijas drošībā - PCI atbilstība, CIS atbilstība, ielāpēšana utt.
DevOps (teorētiski) ir cilvēks, kurš no pirmavotiem izprot visus izstrādes cikla procesus – izstrādi, testēšanu, izprot produkta arhitektūru, spēj novērtēt drošības riskus, pārzina pieejas un automatizācijas rīkus, vismaz augstā līmenī. līmenī, papildus tam saprot arī pirms- un pēcapstrādi.produkta izlaišanas atbalsts. Persona, kas spēj darboties gan kā darbības, gan attīstības aizstāve, kas nodrošina labvēlīgu sadarbību starp šiem diviem pīlāriem. Izprot komandu darba plānošanas un klientu vēlmju pārvaldīšanas procesus.
Lai veiktu šāda veida darbu un pienākumus, šai personai ir jābūt līdzekļiem, lai vadītu ne tikai izstrādes un testēšanas procesus, bet arī produkta infrastruktūras pārvaldību, kā arī resursu plānošanu. DevOps šajā izpratnē nevar atrasties ne IT, ne pētniecībā un attīstībā, ne pat PMO; tai ir jābūt ietekmei visās šajās jomās - uzņēmuma tehniskajam direktoram, galvenajam tehniskajam direktoram.
Vai tā ir taisnība jūsu uzņēmumā? - ES šaubos. Vairumā gadījumu tas ir IT vai pētniecība un attīstība.
Līdzekļu trūkums un spēja ietekmēt vismaz vienu no šīm trim darbības jomām novirzīs problēmu smagumu uz tām vietām, kur šīs izmaiņas ir vieglāk piemērojamas, piemēram, tehnisko ierobežojumu piemērošana izlaidumiem saistībā ar “netīro” kodu saskaņā ar statisku. analizatoru sistēmas. Tas ir, ja PMO nosaka stingru termiņu funkcionalitātes izlaišanai, pētniecība un attīstība šajos termiņos nevar nodrošināt augstas kvalitātes rezultātu un nodrošina to pēc iespējas labāk, atstājot pārstrukturēšanu vēlākam, ar IT saistītais DevOps bloķē izlaišanu, izmantojot tehniskos līdzekļus. . Pilnvaru trūkums mainīt situāciju atbildīgu darbinieku gadījumā noved pie hiperatbildības izpausmēm par to, ko viņi nevar ietekmēt, it īpaši, ja šie darbinieki saprot un redz kļūdas un kā tās labot - “Svētlaime ir nezināšana”, un kā sekas šo darbinieku izdegšanai un zaudēšanai.
DevOps resursu tirgus
Apskatīsim vairākas vakances DevOps pozīcijām no dažādiem uzņēmumiem.
Mēs esam gatavi tikties ar jums, ja:
- Jums pieder Zabbix un zināt, kas ir Prometejs;
- Iptables;
- BASH doktorants;
- profesors Ansible;
- Guru Linux;
- Zināt, kā izmantot atkļūdošanu un atrast aplikāciju problēmas kopā ar izstrādātājiem (php/java/python);
- Maršrutēšana nerada jūs histēriski;
- Pievērsiet lielu uzmanību sistēmas drošībai;
- Dublējiet "visu un visu", kā arī veiksmīgi atjaunojiet šo "visu un visu";
- Jūs zināt, kā konfigurēt sistēmu tā, lai no minimuma iegūtu maksimumu;
- Iestatiet replikāciju pirms gulētiešanas vietnēs Postgres un MySQL;
- CI/CD iestatīšana un pielāgošana jums ir tikpat nepieciešama kā brokastis/pusdienas/vakariņas.
- Ir pieredze darbā ar AWS;
- Gatavs attīstīties kopā ar uzņēmumu;
Tātad:
- no 1 līdz 6 - sistēmas administrators
- 7 - neliela tīkla administrēšana, kas iekļaujas arī sistēmas administratora vidējā līmenī
- 8 - neliela drošība, kas ir obligāta vidējā līmeņa sistēmas administratoram
- 9-11 – vidējās sistēmas administrators
- 12 — Atkarībā no piešķirtajiem uzdevumiem vai nu vidējā sistēmas administrators, vai būvinženieris
- 13 — Virtualizācija — Vidējā līmeņa sistēmas administrators jeb tā sauktais CloudOps, padziļinātas zināšanas par konkrētas sistēmas pakalpojumiem hostings vietnēs, lai efektīvi izmantotu līdzekļus un samazinātu pakalpojumu slogu
Apkopojot šo vakanci, varam teikt, ka puišiem pietiek ar vidējo/vecāko sistēmas administratoru.
Starp citu, nevajadzētu pārāk daudz sadalīt administratorus Linux/WindowsEs, protams, saprotu, ka šo divu pasauļu pakalpojumi un sistēmas atšķiras, taču pamati ir vieni un tie paši, un jebkurš sevi cienošs administrators pārzina abus, un pat ja tie nav pazīstami, kompetents administrators var viegli ar tiem iepazīties.
Apskatīsim vēl vienu vakanci:
- Pieredze lielas slodzes sistēmu būvniecībā;
- Teicamas zināšanas par Linux OS, vispārējo sistēmas programmatūru un tīmekļa steku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Pieredze darbā ar virtualizācijas sistēmām (KVM, VMWare, LXC/Docker);
- skriptu valodu prasme;
- Izpratne par tīkla protokolu tīklu darbības principiem;
- Izpratne par defektizturīgu sistēmu veidošanas principiem;
- Patstāvība un iniciatīva;
Apskatīsim:
- 1 – vecākais sistēmas administrators
- 2 — atkarībā no nozīmes, kas ievietota šajā kaudzē – vidējais/vecākais sistēmas administrators
- 3 - Darba pieredze, tai skaitā, var nozīmēt - "Klasteris nevis cēla, bet izveidoja un pārvaldīja virtuālās mašīnas, bija viens Docker resursdators, piekļuve konteineriem nebija pieejama" - Vidējās sistēmas administrators
- 4 - jaunākais sistēmas administrators - jā, administrators, kurš nezina, kā rakstīt pamata automatizācijas skriptus, neatkarīgi no valodas, nevis administrators - enikey.
- 5 - vidējais sistēmas administrators
- 6 – vecākais sistēmas administrators
Rezumējot - vidējais/vecākais sistēmas administrators
Vēl viens:
- Devops pieredze;
- Pieredze viena vai vairāku produktu izmantošanā, lai izveidotu CI/CD procesus. Gitlab CI būs priekšrocība;
- Darbs ar konteineriem un virtualizāciju; Ja izmantojāt docker, labi, bet, ja izmantojāt k8s, lieliski!
- Pieredze darbā veiklā komandā;
- Jebkuras programmēšanas valodas zināšanas;
Paskatīsimies:
- 1 - Hmm... Ko puiši domā? =) Visticamāk, viņi paši nezina, kas aiz tā slēpjas
- 2 — būvinženieris
- 3 - vidējais sistēmas administrators
- 4 - Mīksta prasme, mēs to pagaidām neapsvērsim, lai gan Agile ir vēl viena lieta, kas tiek interpretēta ērtā veidā.
- 5. Pārāk detalizēta — tā varētu būt skriptu valoda vai kompilēta valoda. Nez vai viņiem derēs rakstīt skolā Pascal un Basic? =)
Vēlos atstāt piezīmi arī par 3.punktu, lai stiprinātu izpratni par to, kāpēc šo punktu sedz sistēmas administrators. Kubernetes ir tikai orķestrēšana, rīks, kas iesaiņo tiešās komandas tīkla draiveriem un virtualizācijas/izolācijas resursdatoriem pāris komandās un ļauj sazināties ar tiem abstraktu, tas arī viss. Piemēram, ņemsim 'build framework' Make, ko, starp citu, es neuzskatu par ietvaru. Jā, es zinu par modi bāzt Make jebkur, kur vajag un nevajag - ietīt Maven in Make, piemēram, nopietni?
Būtībā Make ir tikai apvalks, kas vienkāršo kompilācijas, saistīšanas un kompilācijas vides komandas, tāpat kā k8s.
Reiz es intervēju puisi, kurš savā darbā izmantoja k8s virs OpenStack, un viņš stāstīja par to, kā viņš tajā izvietoja pakalpojumus, tomēr, kad jautāju par OpenStack, izrādījās, ka tas ir administrēts, kā arī sistēmas radīts. administratori. Vai tiešām jūs domājat, ka cilvēks, kurš ir instalējis OpenStack, neatkarīgi no tā, kādu platformu viņš izmanto aiz sevis, nevar izmantot k8s? =)
Šis pretendents faktiski nav DevOps, bet gan sistēmas administrators un, precīzāk, Kubernetes administrators.
Rezumēsim vēlreiz – viņiem pietiks ar vidējo/vecāko sistēmas administratoru.
Cik daudz jāsver gramos
Piedāvāto algu diapazons norādītajām vakancēm ir 90k-200k
Tagad es vēlos vilkt paralēli starp sistēmu administratoru un DevOps inženieru naudas atlīdzību.
Principā, lai vienkāršotu lietas, jūs varat izkaisīt atzīmes pēc darba pieredzes, lai gan tas nebūs precīzi, bet raksta mērķiem ar to pietiks.
Pieredze:
- līdz 3 gadiem – Junior
- līdz 6 gadiem – Vidējais
- vairāk nekā 6 – vecākais
Darbinieku meklēšanas vietne piedāvā:
Sistēmas administratori:
- Juniors - 2 gadi - 50k rub.
- Vidējais - 5 gadi - 70k rub.
- Seniors - 11 gadi - 100k rub.
DevOps inženieri:
- Juniors - 2 gadi - 100k rub.
- Vidējais - 3 gadi - 160k rub.
- Seniors - 6 gadi - 220k rub.
Pēc “DevOps” pieredzes tika izmantota pieredze, kas vismaz kaut kādā veidā ietekmēja SDLC.
No iepriekš minētā izriet, ka patiesībā uzņēmumiem nav nepieciešami DevOps, kā arī, algojot administratoru, tie varētu ietaupīt vismaz 50 procentus no sākotnēji plānotajām izmaksām, turklāt varētu skaidrāk definēt meklējamās personas pienākumus. un aizpildiet vajadzību ātrāk. Tāpat nevajadzētu aizmirst, ka skaidra pienākumu sadale ļauj samazināt prasības pret personālu, kā arī radīt labvēlīgāku atmosfēru kolektīvā, jo nav pārklāšanās. Lielākā daļa vakanču ir pilnas ar utilītprogrammām un DevOps etiķetēm, taču tās nav balstītas uz faktiskajām DevOps inženiera prasībām, ir tikai rīka administratora pieprasījumi.
Arī DevOps inženieru apmācības process ir ierobežots tikai ar konkrētu darbu, utilītu kopumu un nesniedz vispārēju izpratni par procesiem un to atkarībām. Noteikti ir labi, ja cilvēks var izvietot AWS EKS, izmantojot Terraform, kopā ar Fluentd blakusvāģi šajā klasterī un AWS ELK steku reģistrēšanas sistēmai 10 minūtēs, izmantojot tikai vienu komandu konsolē, bet, ja viņš nesaprot pats žurnālu apstrādes princips un kam tie ir nepieciešami, ja jūs nezināt, kā par tiem savākt metriku un izsekot pakalpojuma degradācijai, tad tas joprojām būs tas pats enikey, kurš zina, kā izmantot dažas utilītas.
Pieprasījums tomēr rada piedāvājumu, un mēs redzam ārkārtīgi pārkarsētu DevOps pozīcijas tirgu, kur prasības neatbilst reālajai lomai, bet ļauj tikai sistēmas administratoriem nopelnīt vairāk.
Tātad, kas viņi ir? DevOps vai mantkārīgi sistēmu administratori? =)
Kā turpināt dzīvot?
Darba devējiem vajadzētu precīzāk formulēt prasības un meklēt tieši tos, kuri ir vajadzīgi, nevis mētāties ar etiķetēm. Jūs nezināt, ko dara DevOps — tādā gadījumā jums tie nav vajadzīgi.
Strādnieki — mācieties. Pastāvīgi pilnveido savas zināšanas, aplūko kopējo procesu ainu un seko ceļam uz savu mērķi. Jūs varat kļūt par kuru vēlaties, jums tikai jāmēģina.
Avots: www.habr.com
