ProHoster > Blogs > Administrācija > Nav DevOps inženieru. Kas tad eksistē un ko ar to darīt?

Nav DevOps inženieru. Kas tad eksistē un ko ar to darīt?

Nav DevOps inženieru. Kas tad eksistē un ko ar to darīt?

Pēdējā laikā Ŕādas reklāmas ir pārpludinājuÅ”as internetu. Neskatoties uz patÄ«kamo atalgojumu, nevar nesamulst, ka iekŔā ir rakstÄ«ta mežonÄ«ga Ä·ecerÄ«ba. Sākumā tiek pieņemts, ka ā€œDevOpsā€ un ā€œinženierisā€ var kaut kā salÄ«mēt vienā vārdā, un pēc tam tiek izveidots nejauÅ”s prasÄ«bu saraksts, no kuriem daži ir skaidri nokopēti no sysadmin vakances.

Å ajā ierakstā es vēlētos nedaudz pastāstÄ«t par to, kā mēs nonācām lÄ«dz Å”im dzÄ«ves punktam, kas patiesÄ«bā ir DevOps un ko ar to darÄ«t tagad.

Šādas vakances var nosodÄ«t visos iespējamos veidos, taču fakts paliek fakts: to ir daudz, un tā Å”obrÄ«d darbojas tirgus. Mēs sarÄ«kojām devops konferenci un atklāti paziņojam: ā€œDevOops - nav paredzēts DevOps inženieriem." Å eit daudziem ŔķitÄ«s dÄ«vaini un mežonÄ«gi: kāpēc cilvēki, kas rÄ«ko pilnÄ«gi komerciālu pasākumu, dodas pret tirgu. Tagad mēs visu izskaidrosim.

Par kultūru un procesiem

Sāksim ar faktu, ka DevOps nav inženierzinātņu disciplÄ«na. Viss sākās ar to, ka vēsturiski izveidotais lomu sadalÄ«jums nedarbojas uz produktu kvalitāti. Kad programmētāji tikai programmē, bet nevēlas neko dzirdēt par testÄ“Å”anu, programmatÅ«ra ir pilna ar kļūdām. Kad administratoriem ir vienalga, kā un kāpēc programmatÅ«ra ir uzrakstÄ«ta, atbalsts pārvērÅ”as par elli.

Piemēram, aprakstot atŔķirÄ«bu starp sistēmas administratoru un SRE pieeju pakalpojumu pārvaldÄ«bai sākas slavenā Google SRE grāmata. Tā ietvaros ir veikti interesanti pētÄ«jumi DORA aptauja ā€” ir skaidrs, ka labākajiem izstrādātājiem kaut kā izdodas ieviest jaunas izmaiņas ražoÅ”anā ātrāk nekā reizi stundā. Viņi pārbauda ar rokām ne vairāk kā 10% (to var redzēt no pagājuŔā gada DORA). Kā viņi to dara? ā€œExcel or dieā€ saka viens no pārskata virsrakstiem. Lai iegÅ«tu detalizētu Ŕīs statistikas apskatu testÄ“Å”anas kontekstā, varat atsaukties uz Baruha Sadogurska galveno runu. ā€œMums ir DevOps. AtlaidÄ«sim visus testētājus." citā mÅ«su konferencē Heisenbugā.

"Kad biedru starpā nav vienoŔanās,
Viņiem neklājas labi,
Un nekas no tā neiznāks, tikai mocības.
Reiz gulbis, vēži un līdaka..."

Kura daļa tÄ«mekļa programmētāju, jÅ«suprāt, patieŔām saprot apstākļus, kādos viņu lietojumprogrammas tiek izmantotas ražoÅ”anā? Cik no viņiem dosies pie adminiem un mēģinās izdomāt, kas notiks, ja datubāze avarēs? Un kurÅ” no viņiem dosies pie testētājiem un lÅ«gs viņiem iemācÄ«t pareizi rakstÄ«t kontroldarbus? Un tur ir arÄ« apsargi, produktu vadÄ«tāji un vēl daudzi citi cilvēki.

DevOps vispārējā ideja ir izveidot sadarbÄ«bu starp lomām un nodaļām. Pirmkārt, tas tiek panākts nevis ar kādu gudri konfigurētu programmatÅ«ru, bet gan ar komunikācijas praksi. DevOps ir par kultÅ«ru, praksi, metodoloÄ£iju un procesiem. Nav nevienas inženierzinātņu specialitātes, kas varētu atbildēt uz Å”iem jautājumiem.

Apburtais loks

No kurienes tad radās disciplÄ«na ā€œdevops engineeringā€? Mums ir versija! DevOps idejas bija labas ā€” tik labas, ka kļuva par savu panākumu upuriem. Ap visu Å”o tēmu sāka virpuļot daži ēnaini vervētāji un cilvēku tirgotāji, kuriem ir sava atmosfēra.

Iedomājieties: vakar jÅ«s gatavojāt Å”avarmu Himkos, un Å”odien jÅ«s jau esat liels cilvēks, vecākais vervētājs. Ir vesels kandidātu meklÄ“Å”anas un atlases process, viss nav viegli, vajag saprast. Pieņemsim, ka nodaļas vadÄ«tājs saka: atrodiet speciālistu X. Mēs pieŔķiram X vārdu ā€œinženierisā€, un viss. NepiecieÅ”ams Linux? Nu, tas noteikti ir Linux inženieris, ja vēlaties DevOps, tad DevOps inženieris. Vakance sastāv ne tikai no virsraksta, bet arÄ« jāievada kāds teksts iekŔā. VienkārŔākais veids ir ievadÄ«t Google atslēgvārdu kopu atkarÄ«bā no jÅ«su iztēles. DevOps sastāv no diviem vārdiem - "Dev" un "Ops", kas nozÄ«mē, ka mums ir jāsalÄ«mē ar izstrādātājiem un administratoriem saistÄ«ti atslēgvārdi, visi vienā kaudzē. Šādi parādās vakances par 42 programmÄ“Å”anas valodu prasmi un 20 gadu vienlaicÄ«gu Kubernetes un Swarm lietoÅ”anu. Darba diagramma.

Tā cilvēku prātos ir iesakņojies bezjēdzÄ«gais un nežēlÄ«gais supervaroņa ā€œdevopsā€ tēls, kurÅ” konfigurēs ikvienu izvietoÅ”anai Dženkinsā, un laime nāks. Ak, ja viss bÅ«tu tik vienkārÅ”i. "Un tas ir arÄ« veids, kā jÅ«s varat nomedÄ«t sistēmu administratorus," domā HR, "tas ir moderns vārds, atslēgvārdi ir tie paÅ”i, viņiem vajadzētu ņemt ēsmu."

PieprasÄ«jums rada piedāvājumu, un visas Ŕīs miskastes ir aizpildÄ«tas ar neprātÄ«gu sistēmu administratoru skaitu, kuri saprata: jÅ«s varat darÄ«t visu tāpat kā iepriekÅ”, bet iegÅ«t vairākas reizes vairāk, saucot sevi par "devops". Tāpat kā jÅ«s manuāli pa vienam konfigurējāt serverus, izmantojot SSH, jÅ«s turpināsiet to konfigurÄ“Å”anu, taču tagad tā ir it kā devops prakse. Å Ä« ir sava veida sarežģīta parādÄ«ba, kas daļēji saistÄ«ta ar klasisko administratoru nenovērtÄ“Å”anu un ažiotāžu ap DevOps, bet kopumā tas, kas notika, notika.

Tātad mums ir piedāvājums un pieprasījums. Apburtais loks, kas pats sevi baro. Tas ir tas, pret ko mēs cīnāmies (tostarp izveidojot DevOops konferenci).

Protams, bez sistēmu administratoriem, kas sevi pārdēvējuÅ”i par ā€œdevopsā€, ir arÄ« citi dalÄ«bnieki - piemēram, profesionāli SRE vai Infrastructure-as-Code izstrādātāji.

Ko cilvēki dara DevOps (tieŔām)

Tāpēc vēlaties gÅ«t panākumus DevOps prakses apguvē un pielietoÅ”anā. Bet kā to izdarÄ«t, kurā virzienā skatÄ«ties? AcÄ«mredzot nevajadzētu akli paļauties uz populāriem atslēgvārdiem.

Ja ir darbs, kādam tas jādara. Mēs jau esam noskaidrojuÅ”i, ka tie nav ā€œdevops inženieriā€, kas tad ir? Å Ä·iet pareizāk to formulēt nevis amatos, bet gan konkrētās darba jomās.

Pirmkārt, varat pievērsties DevOps bÅ«tÄ«bai ā€” procesiem un kultÅ«rai. KultÅ«ra ir lēns un grÅ«ts bizness, un, lai gan tradicionāli tā ir vadÄ«tāju atbildÄ«ba, visi ir vienā vai otrā veidā iesaistÄ«ti, sākot no programmētājiem lÄ«dz administratoriem. Pirms pāris mēneÅ”iem Tims Listers teica intervijā:

ā€œKultÅ«ru nosaka organizācijas pamatvērtÄ«bas. Parasti cilvēki to nepamana, bet, ilgus gadus strādājot konsultāciju jomā, esam pieraduÅ”i to pamanÄ«t. JÅ«s ieejat uzņēmumā un burtiski dažu minÅ«Å”u laikā sākat just, kas notiek. Mēs to saucam par "garÅ”u". Dažreiz Ŕī smarža ir patieŔām laba. Dažreiz tas izraisa sliktu dÅ«Å”u. (...) JÅ«s nevarat mainÄ«t kultÅ«ru, kamēr nav izprastas vērtÄ«bas un uzskati, kas slēpjas aiz konkrētām darbÄ«bām. UzvedÄ«bu ir viegli novērot, bet uzskatus meklēt ir grÅ«ti. DevOps ir tikai lielisks piemērs tam, kā lietas kļūst arvien sarežģītākas.

Protams, problēmai ir arÄ« tehniskā daļa. Ja jÅ«su jaunais kods tiek pārbaudÄ«ts mēneÅ”a laikā, bet tiek izlaists tikai gadu vēlāk, un to visu fiziski nav iespējams paātrināt, jÅ«s, iespējams, neievērosit labo praksi. Labo praksi atbalsta labi rÄ«ki. Piemēram, paturot prātā ideju par Infrastructure-as-Code, varat izmantot jebko, sākot no AWS CloudFormation un Terraform lÄ«dz Chef-Ansible-Puppet. Tas viss ir jāzina un jāprot, un tā jau ir diezgan inženierzinātņu disciplÄ«na. Ir svarÄ«gi nejaukt cēloni ar sekām: vispirms jÅ«s strādājat pēc SRE principiem un tikai pēc tam ievieÅ”at Å”os principus kādu konkrētu tehnisko risinājumu veidā. Tajā paŔā laikā SRE ir ļoti visaptveroÅ”a metodoloÄ£ija, kurā nav norādÄ«ts, kā iestatÄ«t Dženkinsu, bet gan aptuveni pieci pamatprincipi:

  • Uzlabota komunikācija starp lomām un nodaļām
  • Kļūdu pieņemÅ”ana kā neatņemama darba sastāvdaļa
  • Izmaiņu veikÅ”ana pakāpeniski
  • Instrumentu un citas automatizācijas izmantoÅ”ana
  • Mēra visu, ko var izmērÄ«t

Tas nav tikai daži apgalvojumi, bet gan konkrēts rÄ«cÄ«bas ceļvedis. Piemēram, ceļā uz kļūdu pieņemÅ”anu jums bÅ«s jāsaprot riski, jāizmēra pakalpojumu pieejamÄ«ba un nepieejamÄ«ba, izmantojot kaut ko lÄ«dzÄ«gu SLI (servisa lÄ«meņa rādÄ«tāji) un SLO (pakalpojumu lÄ«meņa mērÄ·i), iemācieties rakstÄ«t pēcnāves un padariet to rakstÄ«Å”anu nebaidoÅ”u.

SRE disciplÄ«nā instrumentu izmantoÅ”ana ir tikai viena no panākumiem, kaut arÄ« svarÄ«ga. Mums nepārtraukti jāattÄ«stās tehniski, jāskatās, kas notiek pasaulē un kā to var pielietot mÅ«su darbā.

Savukārt Cloud Native risinājumi Å”obrÄ«d ir kļuvuÅ”i ļoti populāri. Kā Å”odien definējis Cloud Native Computing Foundation, Cloud Native tehnoloÄ£ijas ļauj organizācijām izstrādāt un palaist mērogojamas lietojumprogrammas mÅ«sdienu dinamiskās vidēs, piemēram, publiskajos, privātajos un hibrÄ«dos mākoņos. Piemēri ietver konteinerus, pakalpojumu tÄ«klus, mikropakalpojumus, nemainÄ«gu infrastruktÅ«ru un deklaratÄ«vās API. Visas Ŕīs metodes ļauj brÄ«vi savienotām sistēmām palikt elastÄ«gām, vadāmām un labi novērojamām. Laba automatizācija ļauj inženieriem veikt lielas izmaiņas bieži un ar paredzamiem rezultātiem, nepadarot to par grÅ«tu darbu. To visu atbalsta virkne labi zināmu rÄ«ku, piemēram, Docker un Kubernetes.

Å Ä« diezgan sarežģītā un plaŔā definÄ«cija ir saistÄ«ta ar to, ka teritorija ir arÄ« diezgan sarežģīta. No vienas puses, tiek apgalvots, ka jaunas izmaiņas Å”ai sistēmai bÅ«tu jāpievieno pavisam vienkārÅ”i. No otras puses, izdomāt, kā izveidot sava veida konteinerizētu vidi, kurā brÄ«vi saistÄ«ti pakalpojumi darbojas programmatÅ«ras definētā infrastruktÅ«rā un tiek piegādāti tur, izmantojot nepārtrauktu CI/CD, un ap to visu veidot DevOps praksi - tas viss prasa vairāk nekā viens ēd suni.

Ko darīt ar to visu

Katrs Ŕīs problēmas risina savā veidā: piemēram, var publicēt parastās vakances, lai izjauktu apburto loku. Varat noskaidrot, ko nozÄ«mē tādi vārdi kā DevOps un Cloud Native, un lietot tos pareizi un mērÄ·tiecÄ«gi. Varat izstrādāt DevOps un demonstrēt pareizās pieejas ar savu piemēru.

Mēs rīkojam konferenci DevOops 2020 Maskava, kas sniedz iespēju dziļāk iedziļināties lietās, par kurām tikko runājām. Šim nolūkam ir vairākas pārskatu grupas:

  • Procesi un kultÅ«ra;
  • Vietnes uzticamÄ«bas inženierija;
  • Cloud Native;

Kā izvēlēties, kur doties? Å eit ir smalks punkts. No vienas puses, DevOps ir saistÄ«ta ar mijiedarbÄ«bu, un mēs patieŔām vēlamies, lai jÅ«s apmeklētu prezentācijas no dažādiem blokiem. Savukārt, ja esi izstrādes vadÄ«tājs, kurÅ” atnācis uz konferenci, lai koncentrētos vienam konkrētam uzdevumam, tad tevi neviens neierobežo ā€“ acÄ«mredzot Å”is bÅ«s bloks par procesiem un kultÅ«ru. Neaizmirstiet, ka pēc konferences (pēc atsauksmju veidlapas aizpildÄ«Å”anas) jums bÅ«s ieraksti, lai vēlāk vienmēr varētu noskatÄ«ties mazāk svarÄ«gas prezentācijas.

AcÄ«mredzot paŔā konferencē nevar iet uzreiz trÄ«s sliedēs, tāpēc programmu organizējam tā, lai katrā laika posmā bÅ«tu tēmas katrai gaumei.

Atliek tikai saprast, kā rÄ«koties, ja esat DevOps inženieris! Pirmkārt, mēģiniet noteikt, ko jÅ«s patiesÄ«bā darāt. Parasti viņiem patÄ«k saukt Å”o vārdu:

  • Izstrādātāji, kas strādā pie infrastruktÅ«ras. Jums vispiemērotākās ir pārskatu grupas par SRE un Cloud Native.
  • Sistēmas administratori. Å eit ir sarežģītāk. DevOops nav par sistēmas administrÄ“Å”anu. Par laimi, par sistēmu administrÄ“Å”anas tēmu ir daudz izcilu konferenču, grāmatu, rakstu, video u.c. No otras puses, ja jums ir interese attÄ«stÄ«t sevi kultÅ«ras un procesu izpratnē, uzzināt par mākoņtehnoloÄ£ijām un dzÄ«ves detaļām ar Cloud Native, mēs labprāt jÅ«s redzētu! Padomājiet par to: jÅ«s veicat administrāciju, un ko tad jÅ«s darÄ«sit? Lai pēkŔņi nenokļūtu nepatÄ«kamā situācijā, jums vajadzētu mācÄ«ties tagad.

Ir vēl viena iespēja: jÅ«s pastāvat un turpiniet apgalvot, ka esat Ä«paÅ”i DevOps inženieris un nekas cits, lai ko tas arÄ« nozÄ«mētu. Tad mums nākas jÅ«s pievilt, DevOops nav DevOps inženieru konference!

Nav DevOps inženieru. Kas tad eksistē un ko ar to darīt?
Slaids no Konstantīna Dienera ziņojums Minhenē

DevOops 2020 Moscow notiks 29.-30.aprīlī Maskavā, biļetes jau ir pieejamas iegādāties oficiālajā vietnē.

Alternatīvi, jūs varat iesniedziet savu ziņojumu līdz 8. februārim. Lūdzu, ņemiet vērā, ka, aizpildot veidlapu, jums ir jāizvēlas mērķauditorija, kas gūs vislielāko labumu no jūsu pārskata (sarakstā ir aprakts pārsteigums).

Avots: www.habr.com

Pievieno komentāru