Kohët e fundit, reklama të tilla kanë vërshuar internetin. Pavarësisht rrogës së këndshme, njeriu nuk mund të mos turpërohet që brenda saj është shkruar herezi e egër. Në fillim supozohet se "DevOps" dhe "inxhinier" mund të ngjiten disi së bashku në një fjalë, dhe më pas ekziston një listë e rastësishme e kërkesave, disa prej të cilave janë kopjuar qartë nga vendi i lirë i sysadmin.
Në këtë postim do të doja të flisja pak se si arritëm në këtë pikë të jetës, çfarë është në të vërtetë DevOps dhe çfarë të bëjmë me të tani.
Vende të tilla vakante mund të dënohen në çdo mënyrë, por fakti mbetet: ka shumë prej tyre dhe kështu funksionon tregu për momentin. Ne mbajtëm një konferencë devops dhe deklaruam hapur: " - jo për inxhinierët DevOps." Kjo do të duket e çuditshme dhe e egër për shumë njerëz: pse njerëzit që po bëjnë një ngjarje krejtësisht komerciale shkojnë kundër tregut. Tani do të shpjegojmë gjithçka.
Rreth kulturës dhe proceseve
Le të fillojmë me faktin se DevOps nuk është një disiplinë inxhinierike. Gjithçka filloi me faktin se ndarja e roleve e krijuar historikisht nuk funksionon për cilësinë e produkteve. Kur programuesit vetëm programojnë, por nuk duan të dëgjojnë asgjë rreth testimit, softueri është i mbushur me defekte. Kur administratorët nuk u interesojnë se si dhe pse është shkruar softueri, mbështetja kthehet në ferr.
Për shembull, duke përshkruar ndryshimin midis një administratori të sistemit dhe një qasjeje SRE për menaxhimin e shërbimit . Studime interesante janë kryer brenda - është e qartë se zhvilluesit më të mirë arrijnë disi të vendosin ndryshime të reja në prodhim më shpejt se një herë në orë. Ata testojnë me duart e tyre jo më shumë se 10% (kjo mund të shihet nga ). Si e bëjnë këtë? "Shkëlqe ose vdis", thotë një nga titujt e raportit. Për një diskutim të hollësishëm të këtyre statistikave në kontekstin e testimit, mund t'i referoheni fjalimit kryesor të Baruch Sadogursky në konferencën tonë tjetër, Heisenbug.
“Kur nuk ka marrëveshje mes shokëve,
Gjërat nuk do të shkojnë mirë për ta,
Dhe asgjë nuk do të dalë prej saj, vetëm mundim.
Njëherë e një kohë një mjellmë, një karavidhe dhe një pike..."
Cila pjesë e programuesve të uebit mendoni se i kupton vërtet kushtet në të cilat aplikacionet e tyre përdoren në prodhim? Sa prej tyre do të shkojnë te administratorët dhe do të përpiqen të kuptojnë se çfarë do të ndodhë nëse baza e të dhënave rrëzohet? Dhe cili prej tyre do të shkojë tek testuesit dhe do t'u kërkojë atyre t'i mësojnë se si të shkruajnë saktë testet? Dhe ka gjithashtu roje sigurie, menaxherë produktesh dhe një mori njerëzish të tjerë.
Ideja e përgjithshme e DevOps është të krijojë bashkëpunim midis roleve dhe departamenteve. Para së gjithash, kjo arrihet jo nga ndonjë softuer i konfiguruar me zgjuarsi, por nga praktika e komunikimit. DevOps ka të bëjë me kulturën, praktikat, metodologjinë dhe proceset. Nuk ka asnjë specialitet inxhinierik që mund t'u përgjigjet këtyre pyetjeve.
Rrethi vicioz
Nga lindi atëherë disiplina e "devops engineering"? Ne kemi një version! Idetë e DevOps ishin të mira—aq të mira saqë u bënë viktima të suksesit të tyre. Disa rekrutues të dyshimtë dhe trafikantë njerëzish, të cilët kanë atmosferën e tyre, filluan të vërtiten rreth kësaj teme.
Imagjinoni: dje po bënit shawarma në Khimki, dhe sot jeni tashmë një burrë i madh, një rekrutues i vjetër. Ka një proces të tërë kërkimi dhe përzgjedhjeje të kandidatëve, gjithçka nuk është e lehtë, duhet ta kuptoni. Le të themi se shefi i një departamenti thotë: gjeni një specialist në X. Ne ia caktojmë fjalën "inxhinier" X dhe mbaruam. Keni nevojë për Linux? Epo, ky është padyshim një inxhinier Linux, nëse doni DevOps, atëherë një inxhinier DevOps. Vendi vakant përbëhet jo vetëm nga një titull, por duhet të futet edhe një tekst brenda. Mënyra më e lehtë është të futni një grup fjalësh kyçe nga Google, në varësi të imagjinatës suaj. DevOps përbëhet nga dy fjalë - "Dev" dhe "Ops", që do të thotë se ne duhet të ngjitim së bashku fjalë kyçe që lidhen me zhvilluesit dhe administratorët, të gjitha në një grumbull. Kështu shfaqen vendet e lira në lidhje me aftësinë në 42 gjuhë programimi dhe 20 vjet përdorimin e Kubernetes dhe Swarm njëkohësisht. Diagrami i punës.
Kështu ka zënë rrënjë në mendjet e njerëzve imazhi i pakuptimtë dhe i pamëshirshëm i një superheroi të caktuar "devops", i cili do t'i konfigurojë të gjithë të vendosen te Jenkins dhe lumturia do të vijë. Oh, sikur gjithçka të ishte kaq e thjeshtë. "Dhe kjo është gjithashtu se si mund të gjurmoni administratorët e sistemit," mendon HR, "është një fjalë në modë, fjalët kyçe janë të njëjta, ata duhet të marrin karremin."
Kërkesa krijon ofertë dhe të gjitha këto vende bosh plehrash janë mbushur me një numër të çmendur administratorësh të sistemit, të cilët e kuptuan: mund të bësh gjithçka njësoj si më parë, por të marrësh disa herë më shumë duke e quajtur veten "devops". Ashtu siç i keni konfiguruar serverët me anë të SSH manualisht një nga një, ju do të vazhdoni t'i konfiguroni ata, por tani kjo supozohet se është një praktikë e zhvilluar. Ky është një lloj fenomeni kompleks, i lidhur pjesërisht me nënvlerësimin e administratorëve klasikë dhe zhurmën rreth DevOps, por në përgjithësi, ajo që ndodhi, ndodhi.
Pra kemi ofertë dhe kërkesë. Një rreth vicioz që ushqen veten. Kjo është ajo që ne po luftojmë (përfshirë krijimin e konferencës DevOops).
Natyrisht, përveç administratorëve të sistemit që e kanë riemërtuar veten "devops", ka pjesëmarrës të tjerë - për shembull, SRE-të profesionistë ose zhvillues Infrastructure-as-Code.
Çfarë bëjnë njerëzit në DevOps (me të vërtetë)
Kështu që ju dëshironi të ecni përpara në mësimin dhe zbatimin e praktikave të DevOps. Por si ta bëjmë këtë, në cilin drejtim të shikojmë? Natyrisht, nuk duhet të mbështeteni verbërisht në fjalë kyçe të njohura.
Nëse ka një punë, dikush duhet ta bëjë atë. Ne kemi zbuluar tashmë se këta nuk janë "inxhinierë të devops", atëherë kush janë? Duket më korrekte ta formulosh këtë jo për pozicione, por për fusha specifike të punës.
Së pari, ju mund të adresoni zemrën e DevOps-proceseve dhe kulturës. Kultura është një biznes i ngadaltë dhe i vështirë, dhe megjithëse tradicionalisht është përgjegjësi e menaxherëve, të gjithë janë të përfshirë në një mënyrë ose në një tjetër, nga programuesit te administratorët. Nja dy muaj më parë Tim Lister :
“Kultura përcaktohet nga vlerat thelbësore të organizatës. Zakonisht njerëzit nuk e vënë re këtë, por pasi kemi punuar në konsulencë për shumë vite, jemi mësuar ta vërejmë. Ju hyni në një kompani dhe fjalë për fjalë brenda pak minutash filloni të ndjeni se çfarë po ndodh. Ne e quajmë këtë "shije". Ndonjëherë kjo aromë është vërtet e mirë. Ndonjëherë shkakton të përziera. (...) Nuk mund të ndryshosh një kulturë derisa të kuptohen vlerat dhe besimet pas veprimeve specifike. Sjellja është e lehtë për t'u vëzhguar, por kërkimi i besimeve është i vështirë. DevOps është vetëm një shembull i shkëlqyer se si gjërat po bëhen gjithnjë e më komplekse.”
Ka edhe një pjesë teknike të çështjes, sigurisht. Nëse kodi juaj i ri testohet brenda një muaji, por lëshohet vetëm një vit më vonë, dhe është fizikisht e pamundur ta shpejtoni atë, mund të mos i përmbushni praktikat e mira. Praktikat e mira mbështeten nga mjete të mira. Për shembull, me idenë e Infrastructure-as-Code në mendje, mund të përdorni çdo gjë nga AWS CloudFormation dhe Terraform tek Chef-Ansible-Puppet. Ju duhet të dini dhe të jeni në gjendje t'i bëni të gjitha këto, dhe kjo tashmë është një disiplinë inxhinierike. Është e rëndësishme të mos ngatërroni shkakun me efektin: fillimisht punoni sipas parimeve të SRE dhe vetëm më pas zbatoni këto parime në formën e disa zgjidhjeve teknike specifike. Në të njëjtën kohë, SRE është një metodologji shumë gjithëpërfshirëse që nuk ju tregon se si të vendosni Jenkins, por rreth pesë parime bazë:
- Komunikimi i përmirësuar ndërmjet roleve dhe departamenteve
- Pranimi i gabimeve si pjesë integrale e punës
- Bërja e ndryshimeve gradualisht
- Përdorimi i veglave dhe automatizimeve të tjera
- Matja e gjithçkaje që mund të matet
Ky nuk është vetëm një grup deklaratash, por një specifikë . Për shembull, në rrugën drejt pranimit të gabimeve, do t'ju duhet të kuptoni rreziqet, të matni disponueshmërinë dhe mosdisponueshmërinë e shërbimeve duke përdorur diçka si SLI () dhe SLO (), mësoni të shkruani postmortem dhe bëni që shkrimi i tyre të mos jetë i frikshëm.
Në disiplinën SRE, përdorimi i mjeteve është vetëm një pjesë e suksesit, megjithëse një pjesë e rëndësishme. Ne duhet të zhvillohemi vazhdimisht teknikisht, të shikojmë se çfarë po ndodh në botë dhe si mund të zbatohet në punën tonë.
Nga ana tjetër, zgjidhjet Cloud Native tani janë bërë shumë të njohura. Siç përcaktohet nga Fondacioni Cloud Native Computing sot, teknologjitë Cloud Native u mundësojnë organizatave të zhvillojnë dhe ekzekutojnë aplikacione të shkallëzueshme në mjediset e sotme dinamike, të tilla si retë publike, private dhe hibride. Shembujt përfshijnë kontejnerët, rrjetat e shërbimit, mikroshërbimet, infrastrukturën e pandryshueshme dhe API-të deklarative. Të gjitha këto teknika lejojnë që sistemet e lidhura lirshëm të mbeten elastike, të menaxhueshme dhe shumë të vëzhgueshme. Automatizimi i mirë i lejon inxhinierët të bëjnë ndryshime të mëdha shpesh dhe me rezultate të parashikueshme pa e bërë atë punë të përditshme. E gjithë kjo mbështetet nga një grumbull mjetesh të njohura si Docker dhe Kubernetes.
Ky përkufizim mjaft i ndërlikuar dhe i gjerë është për faktin se zona është gjithashtu mjaft komplekse. Nga njëra anë, argumentohet se ndryshimet e reja në këtë sistem duhen shtuar thjesht. Nga ana tjetër, për të kuptuar se si të krijoni një lloj mjedisi të kontejneruar në të cilin shërbimet e lidhura lirshëm jetojnë në një infrastrukturë të përcaktuar nga softueri dhe shpërndahen atje duke përdorur CI/CD të vazhdueshme, dhe të ndërtoni praktika DevOps rreth gjithë kësaj - e gjithë kjo kërkon më shumë. se një të hajë qenin.
Çfarë duhet bërë me gjithë këtë
Të gjithë i zgjidhin këto probleme në mënyrën e vet: për shembull, mund të publikoni vende të lira pune normale për të thyer rrethin vicioz. Ju mund të kuptoni se çfarë kuptimi kanë fjalët si DevOps dhe Cloud Native dhe t'i përdorni ato në mënyrë korrekte dhe deri në pikën e duhur. Ju mund të zhvilloheni në DevOps dhe të demonstroni qasjet e duhura me shembullin tuaj.
Ne po bëjmë një konferencë , e cila ofron një mundësi për t'u thelluar në gjërat për të cilat sapo folëm. Ekzistojnë disa grupe raportesh për këtë:
- Proceset dhe kultura;
- Site Reliability Engineering;
- Cloud Native;
Si të zgjidhni se ku të shkoni? Këtu ka një pikë delikate. Nga njëra anë, DevOps ka të bëjë me ndërveprimin dhe ne duam që ju të merrni pjesë në prezantime nga blloqe të ndryshme. Nga ana tjetër, nëse jeni një menaxher zhvillimi që erdhi në konferencë për t'u përqendruar në një detyrë specifike, atëherë askush nuk ju kufizon - padyshim, ky do të jetë një bllok mbi proceset dhe kulturën. Mos harroni se do të keni regjistrime pas konferencës (pasi të plotësoni formularin e komenteve), kështu që gjithmonë mund të shikoni prezantime më pak të rëndësishme më vonë.
Natyrisht, në vetë konferencën nuk mund të shkoni në tre pista njëherësh, kështu që ne e organizojmë programin në atë mënyrë që çdo slot kohor të ketë tema për çdo shije.
Mbetet vetëm të kuptoni se çfarë të bëni nëse jeni inxhinier DevOps! Së pari, përpiquni të përcaktoni se çfarë bëni në të vërtetë. Zakonisht ata pëlqejnë ta quajnë këtë fjalë:
- Zhvilluesit që punojnë në infrastrukturë. Grupet e raporteve rreth SRE dhe Cloud Native janë më të përshtatshmet për ju.
- Administratorët e sistemit. Këtu është më e ndërlikuar. DevOops nuk ka të bëjë me administrimin e sistemit. Për fat të mirë, ka shumë konferenca të shkëlqyera, libra, artikuj, video në internet, etj. me temën e administrimit të sistemit. Nga ana tjetër, nëse jeni të interesuar të zhvilloni veten në kuptimin e të kuptuarit të kulturës dhe proceseve, të mësoni rreth teknologjive cloud dhe detajeve të jetës me Cloud Native, atëherë do të donim t'ju shihnim! Mendoni për këtë: ju jeni duke bërë administrim, dhe atëherë çfarë do të bëni? Për të shmangur gjetjen e papritur në një situatë të pakëndshme, duhet të mësoni tani.
Ekziston një mundësi tjetër: ju këmbëngulni dhe vazhdoni të pretendoni se jeni konkretisht një inxhinier DevOps dhe asgjë tjetër, çfarëdo që të thotë kjo. Atëherë duhet t'ju zhgënjejmë, DevOops nuk është një konferencë për inxhinierët DevOps!
Rrëshqitje nga në Mynih
DevOops 2020 Moska do të mbahet në 29-30 Prill në Moskë, biletat janë tashmë të disponueshme .
Përndryshe, ju mund deri më 8 shkurt. Ju lutemi vini re se kur plotësoni formularin, duhet të zgjidhni audiencën e synuar që do të përfitojë më shumë nga raporti juaj (ka një surprizë të varrosur brenda listës).
Burimi: www.habr.com