Kas ir DevOps?

Pašlaik tā ir viena no dārgākajām pozīcijām tirgū. Sastrēgumi ap "DevOps" inženieriem pārsniedz visus iedomājamos limitus, un jo sliktāk ir ar Senior DevOps inženieriem.
Es strādāju par integrācijas un automatizācijas nodaļas vadītāju, uzminiet angļu atšifrējumu — DevOps Manager. Vai tiešām angļu atšifrējums atspoguļo mūsu ikdienas darbību — drīzāk nē, bet krievu variants šajā gadījumā ir precīzāks. Ņemot vērā manu darbības veidu, ir skaidrs, ka man ir nepieciešams intervēt nākamos komandas dalībniekus, un, pagājušā gada laikā, caur mani ir izgājuši ap 50 cilvēku, kā vēl tikpat tika noraidīti pēc preskrīna ar maniem darbiniekiem.

Mēs joprojām meklējam kolēģus, jo aiz DevOps zīmolā slēpjas ļoti liela dažādu inženieru kārta.

Visi tālāk minētie ir mani personīgie uzskati, jūs neesat pienākuma tiem piekrist, tomēr es pieļauju, ka tas var piešķirt nokrāsu jūsu attieksmei pret šo tēmu. Neskatoties uz risku iekulties nepatikšanās, es publicēju savu viedokli, jo uzskatu, ka tam ir vieta.

Uzņēmumi dažādi saprot, kas ir DevOps inženieri, un, lai ātri nolīgu resursus, piešķir šo zīmolu visiem. Situācija ir diezgan dīvaina, jo uzņēmumi ir gatavi maksāt neticamas atlīdzības šiem cilvēkiem, iegūstot par viņiem, lielākoties, administratoru-instrumentu speciālistu.

Tātad, kas ir DevOps inženieri?

Sāksim ar stāstu par to, kā radās – Development Operations radās kā vēl viens solis, lai optimizētu sadarbību nelielās komandās, lai palielinātu ražošanas ātrumu, kā sagaidāmu rezultātu. Ideja bija nostiprināt izstrādes komandu ar zināšanām par procedūrām un pieejām produktu vidē. Citiem vārdiem sakot, izstrādātājam jāizprot un jāzina, kā viņa produkts darbojas dažādos apstākļos, jāzina, kā novietot savu produktu, kādas vides īpašības jāmaina, lai uzlabotu veiktspēju. Tādējādi, kādu laiku vēlāk, parādījās izstrādātāji ar DevOps pieeju. DevOps izstrādātāji rakstīja apkopošanas un iepakošanas skriptus, lai atvieglotu savu darbību un nodrošinātu produkcijas vides darbību. Tomēr risinājumu arhitektūras sarežģītība un infrastruktūras komponentu savstarpējā ietekme ar laiku sāka pasliktināt vidi veiktspēju, ar katru iterāciju prasīja aizvien dziļākas izpratnes par konkrētiem komponentiem, samazinot paša izstrādātāja produktivitāti papildu izdevumu dēļ, lai izprastu komponentus un pielāgotu sistēmas konkrētām vajadzībām. Izstrādātāja izmaksas pieauga, līdz ar to pieauga arī produkta izmaksas, strauji pieauga jauno izstrādātāju prasības komandā, jo viņiem vajadzēja segt «zvaigznes» izstrādātāja pienākumus, un, protams, «zvaigznes» kļuva arvien mazāk pieejamas. Arī jāatzīmē, ka, pēc manas pieredzes, maz kurš izstrādātāju interesē operētājsistēmas kodola paketēšanas apstrādes specifika, paketes maršrutēšanas noteikumi, hosta drošības aspekti. Loģisks solis bija piesaistīt administratoru, kuram šīs lietas ir pazīstamas, un uzlikt viņam šāda veida pienākumus, kas, pateicoties viņa pieredzei, ļāva sasniegt tos pašus rādītājus par zemākām izmaksām salīdzinājumā ar «zvaigznes» izstrādātāja izmaksām. Šādus administratorus iekļāva komandā, un viņa galvenais uzdevums bija pārvaldīt testēšanas un produkcijas vides, pēc konkrētās komandas noteikumiem, ar resursiem, kas piešķirti tieši šai komandai. Tā, faktiski, arī radās DevOps lielākā daļa izpratnes.

Daļēji vai pilnīgi, laika gaitā, datorsistēmu administratori sākotnēji sāka saprast konkrētās izstrādātāju komandas vajadzības, kā atvieglot izstrādātājiem un testētājiem dzīvi, kā izlaist atjauninājumu un nepalikt piektdienas vakarā birojā, labojot izvietošanas kļūdas. Laiks pagāja, un tagad "zvaigznes" kļuva par datorsistēmu administratoriem, kas sapratāja, ko vēlas izstrādātāji. Mērķis minimizēt ietekmi nozīmēja, ka tika ieviestas pārvaldības utilītas, visi atcerējās vecos un uzticamos operētājsistēmas izolācijas metodes, kas ļāva minimizēt drošības prasības, tīkla pārvaldību un vispārējo hosta konfigurāciju, un rezultātā samazināja prasības jaunajām "zvaigznēm".

Parādījās "brīnišķīgs" rīks — docker. Kāpēc brīnišķīgs? Tāpēc, ka izolācijas izveide chroot vai jail, kā arī OpenVZ prasīja ne trivālas operētājsistēmas zināšanas, bet šajā utilītē bija iespējams vienkārši izveidot izolētu lietojumprogrammu vidi uz kāda hosta ar visu nepieciešamo iekšā un atdot izstrādātājiem tiesības pārvaldīt paši, kamēr datorsistēmu administrators varēja pārvaldīt tikai vienu hostu, nodrošinot tā drošību un augstu pieejamību — loģisks vienkāršošanas solis. Tomēr progress neapstājas un sistēmas kļūst arvien sarežģītākas, komponentu kļūst arvien vairāk, viens hosts vairs nepietiek sistēmas vajadzībām un ir nepieciešams veidot klasterus, mēs atkal atgriežamies pie datorsistēmu administratoriem, kas spēj veidot šīs sistēmas.

Cikls 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ācijas sistēmas, kas, kamēr nav nepieciešams atkāpties no standarta procesa, ir viegli lietojamas. Mikroservisu arhitektūra arī parādījās, lai vienkāršotu iepriekš minēto — mazāk saikņu, vieglāk pārvaldāma. Manā pieredzē es pilnībā nesaskaros ar mikroservisu arhitektūru, es teiktu, ka tas ir 50 pret 50 — 50 procenti mikroservisu, melnā kaste, kas ienāk iekšā, iznāk apstrādāta, citi 50 — saplēsts monolīts, pakalpojumi nespēj darboties atsevišķi no citiem komponentiem. Viss šis process atkal nosaka ierobežojumus gan izstrādātāju, gan administratoru zināšanu līmenim.

Šāda veida "šūpošanās" ar konkrētā resursa ekspertu zināšanām turpinās arī šodien. Bet mēs nedaudz novirzījāmies no tēmas, ir daudz momentu, kurus vērts apspriest.

Build Engineer/Release Engineer

Ļoti šauras specialitātes inženieri, kas radušies, lai standartizētu programmatūras būves un izlaišanas procesus. Ieviešot plašu Agile izmantošanu, šķita, ka viņi ir zaudējuši pieprasījumu, taču tas ir tālu no patiesības. Šī specializācija radās kā līdzeklis tieši programmatūras būves un piegādes standartizēšanai industriālās mērogos, t.i., izmantojot standarta tehnikas visiem uzņēmuma produktiem. Ar DevOps parādīšanos izstrādātāji daļēji zaudēja savas funkcijas, jo tieši izstrādātāji sāka sagatavot produktu piegādei. Ņemot vērā Mainīgās infrastruktūras un piegādes pieejas, tie visātrāk pārvērtās par aprobežojumiem izmaiņām, jo standartiem kvalitātes saglabāšanai neatņemami palēnina piegādes. Tādējādi pakāpeniski daļa Build/Release inženieru funkcionalitātes pārcēlās uz sistēmu administratoru pleciem.

Ops’ī ir tik dažādi

Mēs virzāmies tālāk, un atkal liels uzdevumu loks un kvalificētu darbinieku trūkums mudina mūs uz stingru specializāciju, kā sēnes pēc lietus, parādās dažādas Operations:

• TechOps — sistēmu administratori eņģeļi aka HelpDesk Engineer
• LiveOps — sistēmu administratori, kas galvenokārt atbild par produktīvajām vidēm
• CloudOps — sistēmu administratori, kas specializējas publiskajos "mākonī" Azure, AWS, GCP utt.
• PlatOps/InfraOps/SysOps — infrastruktūras sistēmu administratori.
• NetOps — tīklu administratori
• SecOps — sistēmu administratori, kas specializējas informācijas drošībā — PCI atbilstība, CIS atbilstība, ielāpi utt.

DevOps — (teorētiski) persona, kura patiesi izprot visus izstrādes cikla procesus — izstrādi, testēšanu, izprot produkta arhitektūru, spēj novērtēt drošības riskus, ir pazīstama ar automatizācijas pieejām un līdzekļiem vismaz augstā līmenī, turklāt izprot arī produktu pirms un pēc izlaišanas atbalstu. Persona, kas spēj kalpot kā starpnieks gan Operācijām, gan Izstrādei, ļaujot izveidot labvēlīgu sadarbību starp šiem diviem balstiem. Izprot komandu darba plānošanas procesus un klientu cerību vadību.

Lai veiktu šāda veida darbu un pienākumu, šai personai jābūt rīkiem ne tikai izstrādes un testēšanas procesu, bet arī produkta infrastruktūras pārvaldībai un resursu plānošanai. DevOps šajā izpratnē nedrīkst būt tikai IT, R&D vai pat PMO, tam jābūt ietekmei visās šajās jomās — uzņēmuma tehniskajam direktoram, Chief Technical Officer.

Vai tas tā ir jūsu uzņēmumā? — Šaubos. Vairumā gadījumu tas ir vai nu IT, vai R&D.

Līdzekļu un iespēju ietekmēt vismaz vienu no šiem trim darbības virzieniem trūkums radīs problēmu smaguma pārvietošanos uz to, kur šīs izmaiņas vieglāk piemērot, piemēram, tehnisko ierobežojumu noteikšanu izlaidumiem saistībā ar “netīro” kodu, saskaņā ar statiskā koda analīzes sistēmas datiem. Proti, kad PMO nosaka stingru termiņu funkcionalitātes izdošanai, R&D nespēj nodrošināt kvalitatīvu rezultātu šajos termiņos un dara, kā var, atlikdams refaktoringu uz vēlāk, DevOps, kas attiecas uz IT, ar tehniskajiem līdzekļiem bloķē izlaidumu. Pilnvaru trūkums situācijas maiņai, attiecībā uz atbildīgajiem darbiniekiem, noved pie pārmērīgas atbildības par to, uz ko viņi nevar ietekmēt, jo īpaši, ja šie darbinieki izprot un redz kļūdas un to, kā tās labot — “Laime nezināšanā”, un kā sekas — uz plūdu un šo darbinieku zudumu.

DevOps resursu tirgus

Apskatīsim dažas vakances DevOps pozīcijai no dažādām kompānijām.

Mēs esam gatavi tikties ar jums, ja jūs:

1. Pārzināt Zabbix un zināt, kas ir Prometheus;
2. Iptables;
3. BASH aspirants;
4. Ansible profesors;
5. Linux guru;
6. Jūs spējat izmantot debugu un kopā ar izstrādātājiem atrast problēmas lietojumprogrammās (php/java/python);
7. Maršrutēšana jūs nesatrauc;
8. Jūs pievēršat lielu uzmanību sistēmas drošībai;
9. Jūs veicat «visi un viss» dublēšanu un veiksmīgi atjaunojat šo «visi un viss»;
10. Jūs spējat konfigurēt sistēmu tā, lai maksimāli izmantotu minimumu;
11. Jūs iestatāt replikācijas pirms miega uz Postgres un MySQL;
12. CI/CD konfigurācija un koriģēšana jums ir nepieciešama kā brokastis/pusdienas/vakariņas.
13. Jums ir pieredze darbā ar AWS;
14. Jūs esat gatavs attīstīties kopā ar uzņēmumu;

Tātad:

• no 1 līdz 6 – sistēmas administrators
• 7 – nedaudz tīkla administrēšanas, kas arī iekļaujas vidējā līmeņa administrēšanas jomā
• 8 – nedaudz drošības, kas ir obligāta vidējā līmeņa administratoram
• 9-11 – Vidējā līmeņa Sistēmas administrators
• 12 – Atkarībā no uzdotajiem uzdevumiem vai nu vidējā līmeņa sistēmas administrators, vai Build Engineer
• 13 – Virtualizācija – Vidējā līmeņa Sistēmas administrators, vai saukts arī par CloudOps, ar padziļinātām zināšanām tieši konkrētās platformas pakalpojumos, lai efektīvi izmantotu finanšu līdzekļus un samazinātu apkalpošanas slodzi hostings Apkopojot šo vakanci, var teikt, ka puišiem pietiek ar vidējā / vecākā līmeņa sistēmas administratoru.

Starpcitu, nevajag ļoti dalīt administratorus Linux / Windows. Es protams saprotu, ka šo divu pasauļu pakalpojumi un sistēmas atšķiras, bet pamats visiem ir viens, un jebkurš sevi cienošs administrators ir iepazinies ar abiem, un pat ja nav iepazinies, tad prasmīgam administratoram nebūs grūti to izpētīt.

Apspriedīsim citu vakanci:

Pieredze augsti noslogotu sistēmu būvēšanā;

1. Lieliskas zināšanas par OS Linux, vispārējām sistēmu programmām un tīmekļa steku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
2. Pieredze darbā ar virtualizācijas sistēmām (
3. , VMWare, LXC/Docker);KVMIzpratne par skriptu valodām;
4. Izpratne par tīkla protokolu darbības principiem;
5. Izpratne par noturīgu sistēmu veidošanas principiem;
6. Patstāvība un iniciatīva;
7. Izskatām:

1 – Senior Sistēmas administrators

• 2 – Atkarībā no jēgas, ko mēs ieguldām šajā stekā – vidējā / vecākā līmeņa sistēmas administrators
• 3 – Pieredze darbā, tostarp var nozīmēt – «Klastu neesmu cēlis, bet radīju un pārvaldīju virtualizācijas, bija viens Docker viesējo hostu, piekļuve konteineriem» – vidējā līmeņa sistēmas administrators
• 4 – Pieredze ar DevOps procesiem, kas ir saprātīga vidējā līmeņa sistēmas administratoram
• 4 — Junior System Administrator — jā, administrators, kurš neprot rakstīt elementārus automatizācijas skriptus, neatkarīgi no valodas, nav administrators — ēne.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Kopsavilkums — Middle/Senior System Administrator

Vēl viena:

1. DevOps darba pieredze;
2. Pieredze darbā ar vienu vai vairākiem produktiem CI/CD procesu izveidē. GitLab CI būs priekšrocība;
3. Darbs ar konteineriem un virtualizāciju; Ja esat izmantojuši Docker – labi, bet ja Kubernetes – lieliski!
4. Pieredze darbā agile komandā;
5. Zināšanas par jebkuru programmēšanas valodu;

Apskatīsim:

• 1 — Hmm… Ko puiši ar to domā? =) Iespējams, viņi paši nezina, kas ar to slēpjas
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Mīkstās prasmes, pagaidām neapskatīsim, lai gan Agile ir vēl viena lieta, ko interpretē kā ērti.
• 5 — Pārāk plaši — tas var būt skriptu valoda vai kompilējama. Interesanti, vai tās uzrunās cilvēku, kurš skolā rakstījis uz Pascal un Basic? =)

Gribētu arī atstāt piezīmi attiecībā uz 3. punktu, lai stiprinātu izpratni, kāpēc šo punktu sedz sistēmu administrators. Kubernetes ir tikai orķestrēšana, rīks, kas aploks tiešās komandas tīkliem un virtualizācijas/izolācijas viesdienestiem divās komandās un ļauj veikt saziņu ar tiem abstraktu, un tas ir viss. Piemēram, ņemsim ‘build framework’ Make, kuru es, starp citu, neuzskatu par framework. Jā, es zinu par modi ielikt Make, kur nu jau ir un nav nepieciešams — aploksim Maven savā Make piemēram, nopietni?
Pati Make ir tikai apvalks virs shell, kas atvieglo kompIlācijas, linkēšanas, kompIlācijas vidēšanas komandas, tāpat kā Kubernetes.

Reiz es intervēju puisi, kurš izmantoja Kubernetes savā darbā virs OpenStack, un viņš stāstīja, kā izveidoja pakalpojumus uz tā, tomēr, kad es jautāju tieši par OpenStack, izrādījās, ka to administrē, tāpat kā uzstāda sistēmu administratori. Vai jūs tiešām domājat, ka cilvēks, kurš uzstādījis OpenStack, neatkarīgi no tā, kuru platformu viņš izmanto, nav spējīgs izmantot Kubernetes?=)
Šis pretendents patiesībā nav DevOps, bet tāds pats Sistēmas Administrators un, lai būtu precīzāks, Kubernetes Administrators.

Kopsavilkumā, Middle/Senior System Administrator viņiem būs pietiekami.

Cik kg piestiprināt

Piedāvāto algu diapazons minētām vakancēm — 90k-200k
Tagad vēlētos izdarīt salīdzinājumu starp Sistēmu Administratoru un DevOps inženieru naudas atlīdzībām.

Principā, vienkāršošanas labad varētu sadalīt grādus pēc darba pieredzes, lai gan tas nebūs precīzi, raksta vajadzībām pietiks.

Pieredze:

1. līdz 3 gadiem — Junior
2. līdz 6 gadiem — Middle
3. vairāk par 6 gadiem — Senior

Darbinieku meklēšanas vietne piedāvā:
Sistēmu administratori:

1. Junior — 2 gadi — 50k rub.
2. Middle — 5 gadi — 70k rub.
3. Senior — 11 gadi — 100k rub.

DevOps inženieri:

1. Junior — 2 gadi — 100k rub.
2. Middle — 3 gadi — 160k rub.
3. Senior — 6 gadi — 220k rub.

Attiecībā uz «DevOps» pieredzi tika izmantota pieredze, kas kaut kādā mērā attiecās uz SDLC.

No augstāk minētā secināms, ka uzņēmumiem patiesībā nav nepieciešami DevOps speciālisti, un tie varētu ietaupīt ne mazāk kā 50 procentus no sākotnēji plānotajām izmaksām, pieņemot darbā Administrators. Turklāt tie varētu skaidrāk noteikt meklētā cilvēka pienākumus un ātrāk apmierināt vajadzības. Nav arī j forgetting, ka skaidra atbildības sadale ļauj samazināt prasības pret personālu un radīt labvēlīgāku atmosfēru kolektīvā, jo nav pārklāšanās. Lielākajā daļā vakances ir piepildītas ar utilītām un DevOps uzlīmēm, taču tām nav īstu prasību attiecībā uz DevOps inženieri, tikai pieprasījumi pēc rīku administratora.

DevOps inženieru apmācības process ir arī ierobežots tikai ar specifisku darbu un utilītām, nesniedzot kopēju izpratni par procesiem un to atkarībām. Protams, ir labi, kad cilvēks var, izmantojot Terraform, izvietot AWS EKS, saistībā ar Fluentd sānu konteineru šajā klasterī un AWS ELK steku sistēmas žurnālvēstures veikšanai 10 minūtēs, izmantojot tikai vienu komandu konsolē, bet, ja viņš nesaprot pati principus žurnālu apstrādē un kādēļ tie ir nepieciešami, nezinot, kā savākt metrikas un izsekot pakalpojuma degradāciju, tad tas būs tas pats enkidī, kas spēj izmantot dažas utilītas.

Piedāvājums, protams, rodas no pieprasījuma, un mēs redzam ļoti pārkarsto tirgu DevOps amatu, kur prasības neatbilst reālajai lomai, bet ļauj sistēmu administratoriem pelnīt vairāk.

Kas tad viņi ir? DevOps vai alkatīgi sistēmu administratori? =)

Kā dzīvot tālāk?

Darbiniekiem — precīzāk formulēt prasības un meklēt tieši tos, kas nepieciešami, nevis izplatīt birkas. Ja nezināt, ko dara DevOps, viņi jums šajā gadījumā nav nepieciešami.

Darbiniekiem — mācīties. Pastāvīgi pilnveidot savas zināšanas, skatīties uz kopējo procesu ainu un sekot ceļam uz nolikto mērķi. Var kļūt par ko vien vēlies, tikai jārūpējas.

Avots: habr.com