Në kohët e fundit, këto njoftime kanë mbushur internetin. Pavarësisht nga paga e këndshme, nuk mund të mos shqetësojë që brenda është shkruar një absurditet i dhimbshëm. Fillimisht supozohet se 'DevOps' dhe 'inxhinier' mund të ngjiten ndonjë mënyrë në një fjalë, dhe pastaj vjen një listë rastësore kërkesash, disa prej të cilave janë qartazi kopjuar nga një njoftim për punë për sistem-admin.
Në këtë post, do të doja të flisja paksi për si arritëm në këtë pikë, çfarë është në të vërtetë DevOps dhe çfarë duhet të bëjmë tani me të.
Këto njoftime mund të kritikohen në shumë mënyra, por fakti mbetet fakt: ato janë të shumta, dhe tregu është ndërtuar kështu për momentin. Ne organizuam një konferencë DevOps dhe e shpallim hapur: — nuk është për inxhinierët DevOps”. Këtu shumë njerëz mund t’i duket e çuditshme dhe të çmendura: pse njerëz që organizojnë një ngjarje krejtësisht tregtare, shkojnë kundër tregut. Tani do të shpjegojmë gjithçka.
Për kulturën dhe proceset
Të fillojmë nga fakti që DevOps nuk është një disiplinë inxhinierike. Të gjitha filloi nga ndarja historike e roleve që nuk funksionon për cilësinë e produkteve. Kur programuesit vetëm programojnë, por nuk duan të dëgjojnë për testimin — softi është i mbushur me defekte. Kur administratoret nuk i intereson si dhe pse është shkruar softi — mbështetja shndërrohet në ferr.
Për shembull, përshkrimi i ndryshimit midis qasjes sistem-admin dhe SRE ndaj menaxhimit të shërbimeve Studime interesante janë kryer në kuadër të — është e dukshme se zhvilluesit më të mirë arrijnë ndonjë mënyrë të depozitojnë ndryshime të reja në prodhim më shpesh se një herë në orë. Ata gjithashtu testojnë me dorë jo më shumë se 10% (kjo është e dukshme nga ). Si ia dalin atyre? ‘Excel or die’ – thotë një nga titujt e raportit. Për diskutimin e hollësishëm të kësaj statistike në lidhje me testimin, mund t’i referoheni keynote-it të Baruch Sadogursky në një tjetër konferencë tonën, Heisenbug.
‘Kur në shokët nuk ka pajtim,
Këtu puna nuk do të shkojë,
Dhe nuk do të dalë nga ajo asnjë punë, vetëm mundim.
Njëherë një Qyq dhe dy Kreshnikë…’
Çfarë mendoni, sa pjesë e programuesve të uebit e kuptojnë vërtet në cilat kushte shfrytëzohen aplikacionet e tyre në prodhim? Sa prej tyre do të shkojnë te administratorët dhe do të përpiqen të kuptojnë se çfarë do të ndodhë në rastin e dështimit të bazës së të dhënave? E kush do të shkojë te testerët dhe do të kërkojë t'i mësojnë si të shkruajnë teste siç duhet? Pastaj ka edhe ekspertë për sigurinë, menaxherë produktesh dhe shumë të tjerë.
Ideja e përgjithshme e DevOps është të krijohet një bashkëpunim mes roleve dhe departamenteve. Kjo arrihet kryesisht jo përmes ndonjë software-i të përfolur, por përmes praktikës së komunikimit. DevOps është për kulturën, praktikën, metodologjinë dhe proceset. Nuk ekziston një profesion inxhinierie që përgjigjet në këto pyetje.
Cikli i mbyllur
Si ka lindur disiplina e «inxhinierisë devops»? Ne kemi një version! Idetë e DevOps rezultuan të jenë shumë të mira — aq të mira sa që u bënë viktima të suksesit të tyre. Rreth kësaj teme filluan të rrethojnë disa rekruterë të dyshimtë dhe tregtarë njerëzish, të cilët kanë një atmosferë shumë të veçantë.
Imagjinoni: dje në Khimki ishit duke shërbyer shawarma, dhe sot — ju jeni një njeri i madh, rekruter senior. Ka një proces të tërë kërkimi dhe seleksioni të kandidatëve, gjithçka nuk është e thjeshtë, duhet kuptuar. Supozoni se shefi i departamentit thotë: gjej një specialist për X. Shtojmë fjalën «inxhinier» për X dhe punët janë e thjeshtë. Të nevojitet Linux? Atëherë padyshim është inxhinier Linux, do një DevOps — inxhinier DevOps. Vendi i punës nuk përbëhet vetëm nga titulli, por brenda duhet të shkruhet një tekst. Më e lehta është të shtosh një grup fjalësh kyç nga Google, kush ka fantazi sa të mjaftueshme. DevOps përbëhet nga dy fjalë — «Dev» dhe «Ops», që do të thotë se duhet të kombinohen fjalët kyç që i përkasin zhvilluesve dhe administratorëve, të gjitha në një vend. Kështu lindin vendet e punës që kërkojnë njohjen e 42 gjuhëve të programimit dhe 20 vjet përdorim të Kubernetes dhe Swarm njëkohësisht. Një skemë e punës.
Në mendjen e njerëzve u ndërtua një imazh pa kuptim dhe pa mëshirë i një superheroi të «devops», i cili do të konfigurojë të gjithë deployment-in në Jenkins, dhe do të ndodhë lumturia. Ah, po sikur të ishte aq e thjeshtë. «Dhe gjithashtu kështu mund të gjuajmë sistem administratorët,» mendon HR-i, «është një fjalë e njohur, fjalët kyç janë të njëjta, duhet të kapin».
Kërkesa krijon ofertën, dhe për të gjitha këto vende pune të çuditshme ka shkaktuar një fluks të madh të administratorëve të sistemeve, që kuptuan: mund të bësh gjithçka ashtu si më parë, por të fitosh disa herë më shumë, duke u quajtur "devops". Ashtu siç e konfiguratonit serverët përmes SSH me duar një nga një, do të vazhdoni ta konfiguroni, por tani kjo supozohet të jetë praktikë devops. Kjo është një dukuri e ndërlikuar, e lidhur pjesërisht me nënvlerësimin e administratorëve klasikë dhe me hype rreth DevOps, por në përgjithësi — ajo që ndodhi, ndodhi.
Pra, kemi kërkesë dhe ofertë. Një cikël i mbyllur, që ushqehet vetë. Këtë ne po e luftojmë (duke përfshirë krijimin e konferencës DevOops).
Sigurisht, përveç administratorëve të sistemeve që e kanë ndryshuar emrin në "devops", ka edhe pjesëmarrës të tjerë — për shembull, SRE profesionistë ose zhvillues të Infrastructure-as-Code.
Çfarë bëjnë njerëzit në DevOps (në të vërtetë)
Kështu, dëshironi të avanconi në studimin dhe aplikimin e praktikave DevOps. Por si ta bëni këtë, në cilin drejtim të shikoni? Qartë është se nuk duhet të drejtoheni verbërisht nga fjalët kyçe të njohura.
Nëse ka punë, dikush duhet ta bëjë atë. Ne tashmë e kemi përcaktuar se nuk janë "inxhinierët devops", atëherë kush? Duket se është më e saktë ta formuloni këtë jo në terma pozita, por në terma të drejtimeve specifike të punës.
Së pari, mund të merremi me zemrën e DevOps — proceset dhe kulturën. Kultura është një çështje që merr kohë dhe nuk është e lehtë, dhe megjithëse tradicionalisht kjo është sfera e përgjegjësisë së menaxherëve, të gjithë, nga programuesit te administratorët, marrin pjesë në këtë. Disa muaj më parë, Tim Lister :
"Kultura përcaktohet nga vlerat themelore të organizatës. Zakonisht njerëzit nuk e vërejnë këtë, por ne, duke punuar në konsulencë për shumë vite, jemi mësuar ta vërejmë. Hy në një kompani dhe për disa minuta fillon të ndiesh se çfarë po ndodh. Ne e quajmë këtë 'aromë'. Ndonjëherë kjo aromë është vërtet e mirë. Ndonjëherë ajo shkakton të vjella. (...) Nuk mund ta ndryshosh kulturën përpara se të kuptohen vlerat dhe besimet që qëndrojnë pas veprimeve të caktuara. Sjellja është e lehtë për t'u vëzhguar, ndërsa të kërkosh besime është e vështirë. DevOps është pikërisht një shembull i shkëlqyer se si gjithçka bëhet gjithnjë e më e komplikuar."
Ka një pjesë teknike të çështjes, natyrisht. Nëse kodi yt i ri arrin për testim pas një muaji, ndërsa në lëshim del vetëm pas një viti, dhe nuk është e mundur ta përshpejtojë këtë fizikisht — nuk do të arrish në praktikat e mira. Praktikat e mira mbështeten nga mjetet e mira. Për shembull, duke pasur në mendje idenë e Infrastructure-as-Code, mund të përdorësh çfarëdo, nga AWS CloudFormation dhe Terraform deri te Chef-Ansible-Puppet. Kjo është diçka që duhet ta dish dhe ta dish, dhe kjo tashmë është një disiplinë inxhinierike. Është e rëndësishme të mos ngatërrohesh me shkakun dhe pasojat: fillimisht punon sipas parimeve SRE dhe vetëm më pas i implementon këto parime në njëfarë forme të zgjidhjeve teknike specifike. Në këtë mënyrë, SRE është një metodologji shumë komplekse, që tregon jo vetëm se si të konfigurosh Jenkins, por pesë parime kryesore:
- Përmirësimi i bashkëpunimit midis roleve dhe departamenteve
- Pranimi i gabimeve si një pjesë e pandashme e punës
- Zbatimi gradual i ndryshimeve
- Përdorimi i mjeteve dhe automatikës tjetër
- Matja e gjithçkaje që mund të matet
Kjo nuk është thjesht një grup shpalljesh, por një . Për shembull, në rrugën e pranimit të gabimeve do të duhet të kuptosh rreziqet, të masësh disponueshmërinë dhe mungesën e shërbimeve me ndihmën e diçkaje si SLI () dhe SLO (), duhet të mësosh të shkruash postmortema dhe të bësh që të shkruash ato të mos jetë e frikshme.
Në disiplinën SRE, përdorimi i mjeteve është vetëm një nga pjesët e suksesit, megjithatë, jo e pa rëndësishme. Na duhet të zhvillohemi vazhdimisht në aspektin teknik, të shohim se çfarë ndodh në botë dhe si mund ta aplikojmë këtë në punën tonë.
Në anën e saj, tani janë bërë shumë të njohura zgjidhjet Cloud Native. Sipas kuptimit modern të Fondacionit për Compute Cloud Native, teknologjitë Cloud Native u lejojnë organisatave të zhvillojnë dhe lançojnë aplikacione të shkallëzueshme në mjedise dinamike moderne, siç janë re publike, private dhe hibride. Një shembull mund të jetë kontejnerët, karkasit e shërbimeve, mikroshërbimet, infrastruktura e pandryshueshme dhe API-të deklarative. Të gjitha këto teknika i lejojnë sistemet e lidhura dobët të mbeten elastike, të menaxhueshme dhe të monitorueshme mirë. Automatizimi i mirë u lejon inxhinierëve të bëjnë ndryshime të mëdha shpesh dhe me rezultate të parashikueshme, pa e kthyer këtë në një punë të tmerrshme. Të gjitha këto mbështeten në një grup mjetesh të njohura, si Docker dhe Kubernetes.
Kjo është një përcaktim mjaft i ndërlikuar dhe i gjërë, i lidhur me faktin se edhe fusha është mjaft e ndërlikuar. Nga njëra anë, pohohet se ndryshime të reja në këtë sistem duhet të shtohen mjaft lehtë. Nga ana tjetër, për të kuptuar se si të krijohet një mjedis i kontejnerizuar, ku shërbimet e lidhura dobët jetojnë në një infrastrukturë të definuar me softuer dhe shpërndahen atje me CI/CD të vazhdueshme, dhe për të ndërtuar praktikat DevOps rreth kësaj - duhet të kesh përvojë të mjaftueshme.
Çfarë duhet bërë me të gjitha këto?
Çdo njeri i zgjidh këto probleme në mënyrën e tij: për shembull, mund të publikoni vende normale pune, për të prishur ciklin e mbyllur. Mund të kuptoni se çfarë do të thonë fjalët si DevOps dhe Cloud Native dhe t'i përdorni ato në mënyrë të saktë dhe për qëllim. Mund të zhvilloheni në DevOps dhe të demonstroni metoda të drejta përmes shembullit tuaj.
Ne po organizojmë një konferencë. , e cila ofron mundësinë për të kuptuar më thellë gjërat mbi të cilat sapo folëm. Për këtë ka disa grupe të prezantimeve:
- Proceset dhe kultura;
- Inxhinieria e Bashkëpunueshmërisë së Uebit;
- Cloud Native;
Si e zgjedh të shkuari diku? Ka një moment të hollë. Nga njëra anë, DevOps lidhet me bashkëpunimin, dhe ne dëshirojmë që të shkoni në prezantime nga blloqe të ndryshme. Nga ana tjetër, nëse jeni një menaxher zhvillimi që ka ardhur në konferencë për t'u përqendruar në një detyrë të caktuar, askush nuk ju kufizon — padyshim, ky do të jetë blloku mbi proceset dhe kulturën. Mos harroni, që pas konferencës do t'ju mbeten regjistrimet (pas plotësimit të formularit të feedbackut), prandaj gjithmonë do të mund të shihni prezantimet më pak të rëndësishme më vonë.
Është e qartë, që në konferencë nuk mund të shkoni menjëherë në tre rrjedha njëkohësisht, prandaj ne e organizojmë programin kështu që në çdo slot kohor të ketë tema për çdo shijë.
Tani mbetet vetëm të kuptoni se çfarë të bëni nëse jeni një inxhinier DevOps! Së pari, provoni të përcaktoni se me çfarë vërtet jeni duke u marrë. Zakonisht, ky term përdoret për të përshkruar:
- Zhvilluesit që merren me infrastrukturën. Për ju, grupet e prezantimeve mbi SRE dhe Cloud Native janë më të përshtatshme.
- Administratorët e sistemeve. Këtu është më e komplikuar. DevOops nuk është për administrimin e sistemeve. Fatmirësisht, ka shumë konferenca, libra, artikuj, video etj. të shkëlqyera mbi temën e administratës së sistemeve. Nga ana tjetër, nëse jeni të interesuar për të zhvilluar njohuritë mbi kulturën dhe proceset, studimin e teknologjive cloud dhe detajet mbi jetë me Cloud Native, do të na kënaqte t'ju shihnim! Mendoni këtë: ju merret me administrimin, dhe pastaj çfarë do bëni? Për të mos përfunduar në një situatë të pakëndshme, është mirë të mësoni tashmë.
Ka edhe një opsion tjetër: ju insistoni dhe vazhdoni të thoni se jeni pikrish inxhinier DevOps dhe ashtu siç do të thotë, që do të thotë. Atëherë duhet të ju zhgënjej, DevOops nuk është një konferencë për inxhinierët DevOps!
Slide nga në Munih
DevOops 2020 Moscow do të mbahet më 29-30 prill në Moskë, biletat tashmë mund të .
Përveç kësaj, ju mund të para 8 shkurtit. Kushtojini vëmendje, se gjatë plotësimit të formularit duhet të zgjidhni audience e cila do të përfitojë më shumë nga prezantimi juaj (brenda listës është një surprizë).
Burimi: habr.com
