A është e vështirë të kuptosh pikën kryesore kur flasim për DevOps? Ne kemi mbledhur për ju analogji të gjalla, formulime mbresëlënëse dhe këshilla nga ekspertë që do të ndihmojnë edhe jo-specialistët të arrijnë te pika. Në fund, bonusi është DevOps i punonjësve të Red Hat.
Termi DevOps e ka origjinën 10 vjet më parë dhe është shndërruar nga një hashtag në Twitter në një lëvizje të fuqishme kulturore në botën e IT, një filozofi e vërtetë që inkurajon zhvilluesit t'i bëjnë gjërat më shpejt, të eksperimentojnë dhe të përsërisin përpara. DevOps është bërë i lidhur pazgjidhshmërisht me konceptin e transformimit dixhital. Por, siç ndodh shpesh me terminologjinë e IT-së, gjatë dhjetë viteve të fundit DevOps ka fituar shumë përkufizime, interpretime dhe keqkuptime për veten.
Prandaj, shpesh mund të dëgjoni pyetje rreth DevOps si, a është njësoj si i shkathët? Apo është kjo ndonjë metodologji e veçantë? Apo është thjesht një sinonim tjetër i fjalës "bashkëpunim"?
DevOps përfshin shumë koncepte të ndryshme (dorëzimi i vazhdueshëm, integrimi i vazhdueshëm, automatizimi, etj.), kështu që distilimi i asaj që është e rëndësishme mund të jetë sfiduese, veçanërisht kur jeni të apasionuar pas temës. Sidoqoftë, kjo aftësi është shumë e dobishme, pavarësisht nëse po përpiqeni t'i përcillni idetë tuaja eprorëve tuaj ose thjesht po i tregoni dikujt nga familja ose miqtë tuaj për punën tuaj. Prandaj, le të lëmë mënjanë nuancat terminologjike të DevOps tani për tani dhe të përqendrohemi në pamjen e madhe.
Çfarë është DevOps: 6 përkufizime dhe analogji
I kërkuam ekspertëve të shpjegojnë thelbin e DevOps sa më thjeshtë dhe shkurt, në mënyrë që vlera e tij të bëhet e qartë për lexuesit me çdo nivel njohurish teknike. Bazuar në rezultatet e këtyre bisedave, ne kemi zgjedhur analogjitë dhe formulimet më të habitshme që do t'ju ndihmojnë të ndërtoni historinë tuaj rreth DevOps.
1. DevOps është një lëvizje kulturore
“DevOps është një lëvizje kulturore në të cilën të dyja palët (zhvilluesit e softuerëve dhe specialistët e funksionimit të sistemit të TI-së) pranojnë se softueri nuk sjell përfitime reale derisa dikush të fillojë ta përdorë atë: klientët, klientët, punonjësit, jo thelbi”, thotë Eveline Oehrlich, hulumtuese e lartë. analist në Institutin DevOps. “Prandaj, të dyja këto palë së bashku sigurojnë shpërndarje të shpejtë dhe me cilësi të lartë të softuerit.”
2. DevOps ka të bëjë me fuqizimin e zhvilluesve.
"DevOps fuqizon zhvilluesit të zotërojnë aplikacione, t'i ekzekutojnë ato dhe të menaxhojnë shpërndarjen nga fillimi në fund."
“Në mënyrë tipike, DevOps flitet si një mënyrë për të përshpejtuar shpërndarjen e aplikacioneve në prodhim duke ndërtuar dhe zbatuar procese të automatizuara,” thotë Jai Schniepp, drejtor i platformave DevOps në kompaninë e sigurimeve Liberty Mutual. "Por për mua është një gjë shumë më thelbësore." DevOps fuqizon zhvilluesit të zotërojnë aplikacione ose pjesë specifike të softuerit, t'i ekzekutojnë ato dhe të menaxhojnë shpërndarjen e tyre nga fillimi në fund. DevOps eliminon konfuzionin e përgjegjësisë dhe udhëzon të gjithë të përfshirë në krijimin e një infrastrukture të automatizuar, të drejtuar nga zhvilluesit.”
3. DevOps ka të bëjë me bashkëpunimin në krijimin dhe shpërndarjen e aplikacioneve.
“Thënë thjesht, DevOps është një qasje për prodhimin dhe shpërndarjen e softuerit ku të gjithë punojnë së bashku”, thotë Gur Staf, president dhe drejtues i automatizimit të biznesit dixhital në BMC.
4. DevOps është një tubacion
"Montimi i transportuesit është i mundur vetëm nëse të gjitha pjesët përshtaten së bashku."
"Unë do ta krahasoja DevOps me një linjë montimi makinash," vazhdon Stafi i Gur. – Ideja është që të projektohen dhe bëhen paraprakisht të gjitha pjesët në mënyrë që ato të mund të montohen më pas pa rregullime individuale. Montimi i transportuesit është i mundur vetëm nëse të gjitha pjesët përshtaten së bashku. Ata që projektojnë dhe ndërtojnë një motor duhet të mendojnë se si ta montojnë atë në trup ose kornizë. Ata që bëjnë frenat duhet të mendojnë për rrotat, e kështu me radhë. E njëjta gjë duhet të jetë e vërtetë me softuerin.
Një zhvillues që krijon logjikën e biznesit ose një ndërfaqe përdoruesi duhet të mendojë për bazën e të dhënave që ruan informacionin e klientit, masat e sigurisë për të mbrojtur të dhënat e përdoruesit dhe sesi e gjithë kjo do të funksionojë kur shërbimi të fillojë t'i shërbejë një audiencë të madhe, ndoshta edhe multimilionëshe përdoruesish. ."
“Të bësh njerëzit të bashkëpunojnë dhe të mendojnë për pjesët e punës që të tjerët po bëjnë, në vend që të fokusohen vetëm në detyrat e tyre, është pengesa më e madhe për t'u kapërcyer. Nëse mund ta bëni këtë, keni një shans të shkëlqyeshëm për transformim dixhital,” shton Staff Gur.
5. DevOps është kombinimi i duhur i njerëzve, proceseve dhe automatizimit
Jayne Groll, drejtor ekzekutiv i Institutit DevOps, ofroi një analogji të madhe për të shpjeguar DevOps. Sipas fjalëve të saj, “DevOps është si një recetë me tre kategori kryesore përbërësish: njerëzit, procesi dhe automatizimi. Shumica e këtyre përbërësve mund të merren nga fusha dhe burime të tjera: Lean, Agile, SRE, CI/CD, ITIL, udhëheqja, kultura, mjetet. Sekreti i DevOps, si çdo recetë e mirë, është se si të merrni përmasat dhe përzierjen e duhur të këtyre përbërësve për të rritur shpejtësinë dhe efikasitetin e krijimit dhe lëshimit të aplikacioneve.”
6. DevOps është kur programuesit punojnë si një ekip i Formula 1
“Gara nuk është planifikuar nga fillimi në fund, por përkundrazi, nga fundi në fillim”.
"Kur flas për atë që duhet të pres nga një iniciativë DevOps, mendoj për një ekip garash NASCAR ose Formula 1 si shembull," thotë Chris Short, menaxher i lartë i marketingut të platformës cloud në Red Hat dhe botues i buletinit të DevOps'ish. – Drejtuesi i një skuadre të tillë ka një synim: të zërë vendin më të lartë të mundshëm në fund të garës, duke marrë parasysh burimet në dispozicion të skuadrës dhe sfidat që i hasën. Në këtë rast, gara është planifikuar jo nga fillimi në fund, por përkundrazi, nga fundi në fillim. Fillimisht vendoset një qëllim ambicioz dhe më pas përcaktohen mënyrat për ta arritur atë. Më pas ato ndahen në nën-detyra dhe u delegohen anëtarëve të ekipit.”
“Ekipi shpenzon gjithë javën para garës duke përsosur pit stopin. Ai bën stërvitje forcash dhe kardio për të qëndruar në formë për një ditë rraskapitëse gare. Praktika duke punuar së bashku për të zgjidhur çdo problem që mund të lindë gjatë garës. Po kështu, ekipi i zhvillimit duhet të trajnojë aftësinë e lëshimit të shpeshtë të versioneve të reja. Nëse keni aftësi të tilla dhe një sistem sigurie që funksionon mirë, lëshimi i versioneve të reja në prodhim ndodh gjithashtu më shpesh. Në këtë botëkuptim, shpejtësia e rritur do të thotë siguri më e madhe”, thotë Short.
"Nuk është të bësh "gjënë e duhur", shton Short, "është të eliminosh sa më shumë gjëra që të jetë e mundur që pengojnë rezultatin e dëshiruar. Bashkëpunoni dhe përshtatuni bazuar në komentet që merrni në kohë reale. Jini të përgatitur për anomali dhe punoni për të përmirësuar cilësinë për të minimizuar ndikimin e tyre në përparimin drejt qëllimit tuaj. Kjo është ajo që na pret në botën e DevOps.”
Si të shkallëzoni DevOps: 10 këshilla nga ekspertët
Thjesht DevOps dhe DevOps masiv janë gjëra krejtësisht të ndryshme. Ne do t'ju tregojmë se si të kapërceni pengesat në rrugën nga e para në të dytën.
Për shumë organizata, udhëtimi drejt DevOps fillon lehtësisht dhe këndshëm. Krijohen ekipe të vogla pasionante, proceset e vjetra zëvendësohen me të reja dhe sukseset e para nuk vonojnë të vijnë.
Mjerisht, ky është vetëm një shkëlqim i rremë, një iluzion progresi, thotë Ben Grinnell, drejtor menaxhues dhe drejtues i sektorit dixhital në konsulencën North Highland. Fitoret e hershme janë sigurisht inkurajuese, por ato nuk ndihmojnë në arritjen e qëllimit përfundimtar të adoptimit të gjerë të DevOps në të gjithë organizatën.
Është e lehtë të shihet se rezultati është një kulturë e ndarjes midis "ne" dhe "ata".
“Shpesh, organizatat i lançojnë këto projekte pioniere duke menduar se do të hapin rrugën për DevOps të rrymës, pa marrë parasysh nëse të tjerët do të jenë në gjendje ose të dëshirojnë ta ndjekin atë rrugë,” shpjegon Ben Grinnell. – Ekipet për zbatimin e projekteve të tilla zakonisht rekrutohen nga “Varangians” me vetëbesim, të cilët tashmë kanë bërë diçka të ngjashme në vende të tjera, por janë të reja për organizatën tuaj. Në të njëjtën kohë, ata inkurajohen të thyejnë dhe shkatërrojnë rregullat që mbeten të detyrueshme për të gjithë të tjerët. Është e lehtë të shihet se rezultati është një kulturë e "ne" dhe "ata" që pengon transferimin e njohurive dhe aftësive."
“Dhe ky problem kulturor është vetëm një nga arsyet që DevOps është i vështirë për t'u shkallëzuar. Ekipet e DevOps po përballen me sfida të shtuara teknike që janë tipike për kompanitë e para të IT-së me rritje të shpejtë, "tha Steve Newman, themeluesi dhe kryetar i Scalyr.
“Në botën moderne, shërbimet ndryshojnë sapo lind nevoja. Është mirë të zbatosh dhe zbatosh vazhdimisht veçori të reja, por koordinimi i këtij procesi dhe eliminimi i problemeve që lindin është një dhimbje koke e vërtetë, shton Steve Newman. – Në organizatat me rritje shumë të shpejtë, inxhinierët në ekipet ndërfunksionale luftojnë për të ruajtur dukshmërinë ndaj ndryshimit dhe efektet kaskaduese të nivelit të varësisë që krijon. Për më tepër, inxhinierët nuk janë të lumtur kur privohen nga kjo mundësi dhe, për rrjedhojë, bëhet më e vështirë për ta të kuptojnë thelbin e problemeve që dalin.”
Si të kapërceni këto sfida të përshkruara më sipër dhe të kaloni në adoptimin masiv të DevOps në një organizatë të madhe? Ekspertët kërkojnë durim, edhe nëse qëllimi juaj përfundimtar është të përshpejtoni ciklin tuaj të zhvillimit të softuerit dhe proceset e biznesit.
1. Mos harroni se ndryshimi i kulturës kërkon kohë.
Jayne Groll, Drejtore Ekzekutive, Instituti DevOps: “Për mendimin tim, zgjerimi i DevOps duhet të jetë po aq në rritje dhe përsëritës sa zhvillimi i shkathët (dhe po aq prek kulturën). Agile dhe DevOps theksojnë ekipet e vogla. Por ndërsa këto ekipe rriten në numër dhe integrim, ne përfundojmë me më shumë njerëz që adoptojnë mënyra të reja pune dhe si rezultat ka një transformim masiv kulturor.”
2. Kaloni mjaft kohë duke planifikuar dhe zgjedhur një platformë
Eran Kinsbruner, Ungjilltari kryesor teknik në Perfecto: “Që shkallëzimi të funksionojë, ekipet e DevOps duhet së pari të mësojnë të kombinojnë proceset, mjetet dhe aftësitë tradicionale, dhe më pas ngadalë të ushqejnë dhe stabilizojnë çdo fazë individuale të DevOps. Gjithçka fillon me planifikimin e kujdesshëm të tregimeve të përdoruesve dhe rrjedhave të vlerave, e ndjekur nga shkrimi i softuerit dhe kontrolli i versionit duke përdorur zhvillim të bazuar në trunk ose qasje të tjera më të përshtatshme për degëzim dhe bashkim të kodit.
“Më pas vjen faza e integrimit dhe testimit, ku tashmë kërkohet një platformë e shkallëzueshme për automatizimin. Këtu është e rëndësishme që ekipet e DevOps të zgjedhin platformën e duhur që i përshtatet nivelit të tyre të aftësive dhe qëllimeve përfundimtare të projektit.
Faza tjetër është vendosja në prodhim dhe kjo duhet të automatizohet plotësisht duke përdorur mjete dhe kontejnerë orkestrimi. Është e rëndësishme të keni mjedise të virtualizuara në të gjitha fazat e DevOps (imitues prodhimi, mjedisi QA dhe mjedisi aktual i prodhimit) dhe të përdorni gjithmonë vetëm të dhënat më të fundit për teste për të marrë konkluzionet përkatëse. Analytics duhet të jetë e zgjuar dhe e aftë për të përpunuar të dhëna të mëdha me reagime të shpejta dhe të zbatueshme.
3. Hiqni fajin nga përgjegjësia.
Gordon Haff, Evangjelist i RedHat: “Krijimi i një sistemi dhe atmosfere që lejon dhe inkurajon eksperimentimin lejon ato që njihen si dështime të suksesshme në zhvillimin e softuerit të shkathët. Kjo nuk do të thotë se askush tjetër nuk është përgjegjës për dështimet. Në fakt, të identifikosh se kush është përgjegjës bëhet edhe më i lehtë, pasi "të jesh përgjegjës" nuk do të thotë më "të shkaktosh një aksident". Kjo do të thotë, thelbi i përgjegjësisë ndryshon cilësisht. Katër faktorë bëhen kritikë: shkalla e ndërprerjes, qasjet, proceset e prodhimit dhe stimujt.” (Mund të lexoni më shumë rreth këtyre faktorëve në artikullin e Gordon Huff "Mësimet e DevOps: 4 aspekte të eksperimenteve të shëndetshme.")
4. Pastroni rrugën përpara
Ben Grinnell, drejtor menaxhues dhe drejtues i sektorit dixhital në konsulencën North Highland: “Për të arritur shkallë, unë rekomandoj nisjen e një programi “pastrimit të rrugëve” së bashku me projekte pioniere. Qëllimi i këtij programi është të pastrojë mbeturinat që pionierët e DevOps lënë pas, si rregullat e vjetruara dhe gjëra të tilla, në mënyrë që rruga përpara të mbetet e qartë.”
“Jepuni njerëzve mbështetje organizative dhe vrull përmes komunikimit që shkon përtej grupit pionier duke festuar gjerësisht sukseset e mënyrave të reja të punës. Trajnoni njerëzit që janë të përfshirë në valën e ardhshme të projekteve DevOps dhe janë nervozë për përdorimin e DevOps për herë të parë. Dhe mbani mend se këta njerëz janë shumë të ndryshëm nga pionierët.”
5. Demokratizo mjetet
Steve Newman, themelues dhe kryetar i Scalyr: “Mjetet nuk duhet t'u fshihen njerëzve dhe ato duhet të jenë relativisht të lehta për t'u mësuar për këdo që dëshiron t'i kushtojë kohë. Nëse aftësia për të kërkuar regjistrat është e kufizuar në tre persona "të certifikuar" për të përdorur një mjet, do të keni gjithmonë maksimum tre persona në dispozicion për të trajtuar problemin, edhe nëse keni një mjedis kompjuterik shumë të madh. Me fjalë të tjera, këtu ka një pengesë që mund të çojë në pasoja të rënda (të biznesit).
6. Krijoni kushte ideale për punë ekipore
Tom Clark, kreu i Platformës së Përbashkët në ITV: “Mund të bësh gjithçka, por jo gjithçka menjëherë. Kështu që vendosni qëllime të mëdha, filloni të vogla dhe ecni përpara me përsëritje të shpejta. Me kalimin e kohës, do të zhvilloni një reputacion për t'i kryer gjërat, kështu që edhe të tjerët do të duan të përdorin metodat tuaja. Dhe mos u shqetësoni për ndërtimin e një ekipi shumë efektiv. Në vend të kësaj, u siguroni njerëzve kushte ideale të punës dhe efikasiteti do të pasojë.”
7. Mos harroni për bordet e Ligjit të Conway dhe Kanban
Logan Daigle, Drejtor i Ofrimit të Softuerit dhe Strategjisë DevOps në CollabNetVersionOne: “Është e rëndësishme të kuptohen pasojat e ligjit të Conway. Në parafrazën time të lirë, ky ligj thotë se produktet që krijojmë dhe proceset që përdorim për ta bërë këtë, duke përfshirë DevOps, rezulton të jenë të strukturuara në të njëjtën mënyrë si organizata jonë.”
“Nëse ka shumë kapanone në një organizatë dhe kontrolli ndryshon duart shumë herë kur planifikon, ndërton dhe lëshon softuerin, efekti i shkallëzimit do të jetë zero ose jetëshkurtër. Nëse një organizatë ndërton ekipe ndërfunksionale rreth produkteve që financohen me fokus tregu, atëherë shanset për sukses rriten në mënyrë dramatike.”
“Një aspekt tjetër i rëndësishëm i shkallëzimit është shfaqja e të gjithë punës në progres (WIP, progresi i punës) në bordet Kanban. Kur një organizatë ka një vend ku njerëzit mund t'i shohin këto gjëra, ajo inkurajon shumë bashkëpunimin, i cili ka një ndikim pozitiv në shkallëzimin."
8. Kërkoni për plagë të vjetra
Manuel Pais, konsulent DevOps dhe bashkautor i Topologjive të Ekipit: “Marrja e praktikave DevOps përtej Dev dhe vetë Ops dhe përpjekja për t'i zbatuar ato në funksione të tjera nuk është një qasje optimale. Kjo sigurisht që do të ketë njëfarë ndikimi (për shembull, duke automatizuar kontrollin manual), por shumë më tepër mund të arrihet nëse fillojmë me të kuptuarit e proceseve të dorëzimit dhe reagimit.”
"Nëse ka plagë të vjetra në sistemin IT të një organizate - procedura dhe mekanizma menaxhimi që janë zbatuar si rezultat i incidenteve të kaluara, por kanë humbur rëndësinë e tyre (për shkak të ndryshimeve në produkte, teknologji ose procese) - atëherë ato me siguri duhet të hiqen. ose të zbuten, në vend që të automatizojnë procese joefikase ose të panevojshme.”
9. Mos krijoni opsione DevOps
Anthony Edwards, Drejtor i Operacioneve në Eggplant: “DevOps është një term shumë i paqartë, kështu që çdo ekip përfundon me versionin e tij të DevOps. Dhe nuk ka asgjë më të keqe kur një organizatë ka papritmas 20 lloje të DevOps që nuk shkojnë mirë së bashku. Është e pamundur që secili nga tre ekipet e zhvillimit të ketë ndërfaqen e tij të veçantë midis zhvillimit dhe menaxhimit të produktit. As produktet nuk duhet të kenë pritshmëritë e tyre unike për trajtimin e reagimeve kur transferohen në një simulator prodhimi. Përndryshe, nuk do të jeni kurrë në gjendje të shkallëzoni DevOps.”
10. Predikoni vlerën e biznesit të DevOps
Steve Newman, themelues dhe kryetar i Scalyr: “Punoni për të njohur vlerën e DevOps. Mësoni dhe ndjehuni të lirë të flisni për përfitimet e asaj që bëni. DevOps është një kursim i jashtëzakonshëm i kohës dhe parave (thjesht mendoni: më pak kohë joproduktive, kohë mesatare më e shkurtër për rikuperim) dhe ekipet e DevOps duhet të theksojnë pa u lodhur (dhe të predikojnë) rëndësinë e këtyre nismave për suksesin e biznesit. Në këtë mënyrë ju mund të zgjeroni rrethin e adhuruesve dhe të rrisni ndikimin e DevOps në organizatë."
bONUS
Mbi DevOps-et tona do të mbërrijnë më 13 shtator - po, Red Hat, si prodhues softuerësh, ka ekipet dhe praktikat e veta DevOps.
Inxhinieri ynë Mark Birger, i cili zhvillon shërbime të automatizimit të brendshëm për grupet e tjera në të gjithë organizatën, do të tregojë historinë e tij në rusisht të qartë - se si ekipi i Red Hat DevOps migroi aplikacionet nga mjediset virtuale të Hat Virtualization të menaxhuara nga Ansible në një format kontejneri të plotë në platformën OpenShift.
Por kjo nuk është e gjitha:
Pasi organizatat të kenë zhvendosur ngarkesat e punës në kontejnerë, metodat tradicionale të monitorimit të aplikacioneve mund të mos funksionojnë. Në bisedën e dytë do të shpjegojmë motivimin tonë për ndryshimin e mënyrës së regjistrimit dhe do të tregojmë vazhdimin e rrugës që na çoi drejt metodave moderne të prerjeve dhe monitorimit.
Burimi: www.habr.com