A është e vështirë të kapësh thelbin, duke folur për DevOps? Ne kemi mbledhur për ju analogji të dukshme, formulime goditëse dhe këshilla nga ekspertë që do t'ju ndihmojnë të arrini thelbin edhe për ata që nuk janë specialistë. Në fund, një bonus – DevOps-in e punonjësve të Red Hat.
Termi DevOps u shfaq 10 vjet më parë dhe ka kaluar nga një hashtag në Twitter në një lëvizje kulturore të fuqishme në botën e IT-së, një filozofi reale që inkurajon zhvilluesit të arrijnë rezultate më shpejt, të eksperimentojnë dhe të përparojnë me metodën e iteracioneve. DevOps është bërë një koncept i pandashëm me transformimin digjital. Por siç ndodh shpesh me terminologjinë e IT-së, gjatë një dekade DevOps ka mbledhur shumë definicione, interpretime dhe keqkuptime mbi vete.
Prandaj, shpesh herë për DevOps mund të dëgjosh pyetje si, a është e njëjta gjë me agile? Apo është një metodologji e veçantë? Apo është vetëm një sinonim tjetër për fjalën "bashkëpunim"?
DevOps përfshin shumë koncepte të ndryshme (dërgesë të vazhdueshme, integrim të vazhdueshëm, automatizim etj.), prandaj të nxjerrësh thelbin mund të jetë e vështirë, sidomos kur je i interesuar për temën. Megjithatë, kjo aftësi është shumë e dobishme, pavarësisht nëse përpiqeni të komunikoni idetë tuaja me menaxhimin ose thjesht po tregoni për punën tuaj ndokujt nga familja ose shokët. Prandaj, deri atëherë, do të largohemi nga nuancat terminologjike të DevOps dhe do të përqendrohemi në pamjen e përgjithshme.
Çfarë është DevOps: 6 definime dhe analogji
Ne i kemi kërkuar specialistëve të shpjegojnë thelbin e DevOps sa më thjesht dhe shkurt, në mënyrë që vlerësimi i saj të bëhet i qartë për lexuesin me çdo nivel përgatitjeje teknike. Si rezultat i këtyre bisedave, ne zgjodhëm analogjitë më të dukshme dhe formulimet goditëse, të cilat do t'ju ndihmojnë të ndërtoni rrëfimin tuaj për DevOps.
1. DevOps – është një lëvizje kulturore
"DevOps – është një lëvizje kulturore, në të cilën të dy palët (zhvilluesit e softuerit dhe specialistët e operacioneve të sistemeve IT) pranojnë se softueri nuk ka vlerë reale deri sa dikush të fillojë ta përdorë atë: klientë, konsumatorë, punonjës, është e papërcaktuar, – thotë Evelina Oehrlich, analiste e lartë-hetuese në Institutin DevOps. – Prandaj, këto dy palë së bashku ofrojnë dërgesën e shpejtë dhe cilësore të softuerit."
2. DevOps – ajo që fuqizon zhvilluesit
«DevOps u jep zhvilluesve fuqinë për të menaxhuar aplikacionet, për t'i nisur ato dhe për të menaxhuar dorëzimin nga fillimi deri në fund»
«Zakonisht flitet për DevOps si një mënyrë për të përshpejtuar dorëzimin e aplikacioneve në prodhim përmes krijimit dhe zbatimit të proceseve automatike, – thotë Jai Schniepp, drejtori për platformat DevOps të kompanisë së sigurimeve Liberty Mutual. – Por për mua është një gjë shumë më themelore. DevOps i jep zhvilluesve fuqinë për të menaxhuar aplikacionet ose pjesë të caktuara të softuerit, për t'i nisur ato dhe për të menaxhuar dorëzimin nga fillimi deri në fund. DevOps eleminon konfuzionin me përgjegjësitë dhe drejton të gjithë pjesëmarrësit në proces drejt krijimit të një infrastrukture të automatizuar dhe të menaxhuar nga zhvilluesi.»
3. DevOps është bashkëpunim në krijimin dhe dorëzimin e aplikacioneve
«Në terma të thjeshtë, DevOps është një qasje për prodhimin dhe dorëzimin e softuerit, kur të gjithë punojnë së bashku», – thekson Gur Staff, president dhe lider i automatizimit të biznesit digital në kompaninë BMC.
4. DevOps është një linjë prodhimi
«Montimi në linjë është i mundur vetëm nëse të gjitha pjesët i përshtaten njëra-tjetrës».
«Do ta krahasoja DevOps me një linjë prodhimi automjetesh, – vazhdon Gur Staff. – Ideja është të projektohen dhe prodhohen të gjitha pjesët paraprakisht, në mënyrë që më pas të mund të assemblehen pa nevojën për përshtatje individuale. Montimi në linjë është i mundur vetëm nëse të gjitha pjesët i përshtaten njëra-tjetrës. Ata që projektuan dhe prodhuan motorin duhet të mendojnë se si ta bashkangjisin atë në karrocerinë ose kornizën. Ata që prodhojnë frenat duhet të mendojnë për rrotat, dhe kështu me radhë. Po ashtu duhet të jetë edhe me softin.
Zhvilluesi që krijon logjikën e biznesit ose ndërfaqen e përdoruesit duhet të mendojë për bazën e të dhënave që ruan informacion mbi klientët, për masat e sigurisë për mbrojtjen e të dhënave të përdoruesve, si dhe për mënyrën se si do të funksionojë gjithçka kur shërbimi të fillojë të shërbejë një audiencë të madhe, ndoshta madje edhe miliona përdorues.»
«Të bësh që njerëzit të bashkëpunojnë dhe të mendojnë për ato pjesë të punës që kryhen nga të tjerët, dhe jo të përqendrohen ekskluzivisht në detyrat e tyre, është pengesa më e madhe që duhet tejkaluar. Nëse është e suksesshme, ju keni një mundësi të shkëlqyer për transformimin digjital», shton Gur Staf.
5. DevOps është kombinimi i duhur i njerëzve, proceseve dhe automatizimit
Jane Groll, drejtoresha ekzekutive e Institutit DevOps, ofroi një analogji të shkëlqyer për të shpjeguar DevOps. Sipas saj, «DevOps është si një recetë gatimi, ku ka tri kategori kryesore përbërësish: njerëzit, proceset 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, liderësia, kultura, mjetet. Sekreti i DevOps, si çdo recetë e mirë, është se si t'i përzini saktësisht përbërësit dhe të bëni që ata të rritin shpejtësinë dhe efikasitetin e punës në zhvillimin dhe lëshimin e aplikacioneve».
6. DevOps është kur programuesit punojnë si një ekip Formula 1
«Garimi planifikohet jo nga starti në finish, por anasjelltas, nga finishi në start».
«Duke folur për atë çfarë të pritet nga iniciativën DevOps, unë jap si shembull një ekip garash NASCAR ose Formula 1,» thotë Chris Short, menaxheri kryesor i marketingut të platformave cloud në Red Hat dhe botues i buletinit DevOps’ish. «E gjithë qëllimi i një ekipi të tillë është: të arrijë pozitat më të larta të mundshme në përfundim të garës, duke marrë parasysh burimet e disponueshme për ekipin dhe sfidat e përballuara. Në këtë kuptim, gara planifikohet jo nga starti në finish, por anasjelltas, nga finishi në start. Në fillim vendoset një qëllim ambicioz dhe pastaj përcaktohen rrugët për ta arritur atë. Më pas, ato ndahen në nënprojekte dhe delegohen anëtarëve të ekipit».
«Gjatë javës para garës, ekipi përmirëson pit-stopin. Pjesëmarrësit bënë trajtime fizike dhe kardiovaskulare për t'u mbajtur në formë në ditën e shterrshme të garave. Pjesën tjetër e ekipit punon për të koordinuar veprimet në rast të ndonjë problemi që mund të lindë gjatë garës. Po ashtu, ekipi i zhvilluesve duhet të stërvisë aftësitë e lëshimit të shpeshtë të versioneve të reja. Me këto aftësi dhe një sistem sigurie të besueshëm, lëshimi i versioneve të reja në prodhim ndodh më shpesh. Në këtë kuptim, rritja e shpejtësisë nënkupton rritjen e sigurisë, - thotë Short.
«Nuk është e rëndësishme të bësh ‘gjërat e duhura’, - shton Short, - por të eliminosh sa më shumë gjëra që qëndrojnë në rrugën e rezultatit të dëshiruar. Collaboroni dhe adaptohuni në përputhje me reagimet që merrni në kohë reale. Programoni 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. Kjo është pikërisht ajo që na pret në botën DevOps».
Si të shkallëzojmë DevOps: 10 këshilla nga ekspertët
DevOps i thjeshtë dhe DevOps në masë janë dy gjëra krejtësisht të ndryshme. Ne do të tregojmë se si të kaloni barrierat nga i pari në të dytin.
Për shumë organizata, rruga drejt DevOps fillon lehtë 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ë.
Fatkeqësisht, kjo është vetëm një shkëlqim fals, iluzion progresi, siç thotë Ben Grinnell, drejtori menaxhues dhe drejtuesi i fushës së teknologjive dixhitale në firmën e konsulencës North Highland. Fitorja e hershme, sigurisht, jep shpresë, por nuk ndihmon në arritjen e qëllimit përfundimtar, atë të përdorimit masiv të DevOps në organizatë.
Është e lehtë të shihet se si po formohet një kulturë ndarjeje në ‘ne’ dhe ‘ata’.
«Shumë shpesh organizatat fillojnë projekte pionierë me mendimin se do të paveçojnë rrugën për DevOps-in masiv, pa menduar nëse të tjerët do të duan dhe do të jenë në gjendje ta ndjekin këtë rrugë», shpjegon Ben Grinnell. «Ekipet për të realizuar këto projekte zakonisht përbëhen nga “vikingët” vetëbesues, të cilët kanë bërë diçka të ngjashme diku tjetër, por janë të rinjtë në organizatën tuaj. Në këtë kohë, ata inkurajohet të thyejnë dhe shkatërrojnë rregullat që mbeten të detyrueshme për të gjithë të tjerët. Është e lehtë të shikohet se si rezulton një kulturë ndarjeje në “ne” dhe “ata”, e cila pengon transferimin e njohurive dhe aftësive».
«Dhe ky problem kulturor është vetëm një nga arsyet pse DevOps është i vështirë për t'u shkallëzuar. Ekipet DevOps përballen me rritjen e vështirësive teknike, tipike për kompanitë që po rriten shpejt dhe që kanë bërë një bast në teknologjitë IT», thotë Steve Newman, themelues dhe kryetar i bordit të kompanisë Scalyr.
«Në botën e sotme shërbimet ndryshojnë menjëherë sapo shfaqet nevoja. Të realizosh dhe implementosh funksionalitete të reja është padyshim e shkëlqyer, por të koordinosh këtë proces dhe të zgjidhësh problemet e përfshira është një vështirësi serioze», shton Steve Newman. «Në organizatat me rritje shumë të shpejtë, inxhinierët në ekipet ndër-funksionale luftojnë për të ruajtur mundësinë për të ndjekur ndryshimet dhe efektet e këtyre ndryshimeve në nivelin e varësive. Më shumë, inxhinierët nuk janë aspak të lumtur kur u hiqet kjo mundësi dhe rezultati është se u bëhet më e vështirë për të kuptuar natyrën e problemeve që ndodhin».
Si të tejkaloni këto vështirësi të përmendura dhe të kaloni në përdorimin masiv të DevOps në një organizatë të madhe? Ekspertët rekomandojnë të jeni të duruar, edhe nëse qëllimi juaj përfundimtar është të përshpejtoni ciklin e zhvillimit të software-it dhe proceset biznesore.
1. Mbani mend se ndryshimet në kulturë kërkojnë kohë.
Jayne Groll, drejtoresha ekzekutive e Institutit DevOps: Sipas mendimit tim, zgjerimi i DevOps duhet të jetë po aq gradual dhe iterativ sa zhvillimi agile (dhe në të njëjtën masë të prekë kulturën). Në Agile dhe DevOps, fokusimi është në grupe të vogla. Por ndërsa numri i grupeve rritet dhe integrimi i tyre vijon, kemi gjithnjë e më shumë njerëz që aplikojnë metoda të reja pune, dhe si pasojë, ndodhi një transformim kulturor në shkallë të gjerë.
2. Kushtoni mjaftueshëm kohë planifikimit dhe zgjedhjes së platformës
Eran Kinsbruner, evangjelist teknik i kompanisë Perfecto: «Për të arritur shkallëzimin, ekipet DevOps në fillim duhet të mësojnë të kombinojnë proceset tradicionale, mjetet dhe aftësitë, dhe pastaj të rrisin ngadalë secilën fazë të veçantë të DevOps dhe ta stabilizojnë atë. Gjithçka fillon me planifikimin e kujdesshëm të historive të përdoruesve dhe flukseve të krijimit të vlerës, pas së cilës vjen faza e programimit të softuerit dhe kontrollit të versioneve përmes zhvillimit të bazuar në trunk ose qasjeve të tjera më të përshtatshme për degëzimin dhe bashkimin e kodit.»
«Më pas vjen faza e integrimit dhe testimit, ku kërkohet tashmë një platformë e shkallëzuar për automatizimin. Në këtë pikë, është e rëndësishme për ekipet DevOps të zgjedhin platformën e duhur që do të përshtatej me nivelin e tyre të aftësive dhe synimet përfundimtare të projektit.
Faza e ardhshme është shpërndarja në ambientin e prodhimit, e cila duhet të jetë plotësisht e automatizuar duke përdorur mjetet e orkestrimit dhe konteinerëve. Në këtë proces, është e rëndësishme të kemi ambiente të virtualizuara në të gjitha fazat e DevOps (simulator për ambientin e prodhimit, ambient të kontrollit të cilësisë dhe, në fakt, ambientin e prodhimit) dhe gjithmonë të përdorim për provat të dhënat më të fundit, për të marrë përfundime të sakta. Analitika duhet të jetë inteligjente dhe e aftë të përpunojë të dhënat e mëdha me një kthim të shpejtë dhe efikas.
3. Çliro nga përgjegjësia e ndjenjës së fajit
Gordon Haff, evangjelist i RedHat: «Krijimi i një sistemi dhe atmosfere që lejon dhe inkurajon eksperimente, mundëson realizimin e ashtuquajturave dështime të suksesshme në zhvillimin agjil të softuerit. Kjo nuk do të thotë që askush nuk merr më përgjegjësi për dështimet. Në të vërtetë, përcaktimi i përgjegjësit bëhet edhe më i lehtë, pasi “të jesh përgjegjës” tani nuk do të thotë “të jesh fajtor për aksidentin”. Pra, e thella e përgjegjësisë ndryshon në mënyrë cilësore. Në këtë kuptim, katër faktorët bëhen jashtëzakonisht të rëndësishëm: shkalla e dështimit, qasjet, proceset e prodhimit dhe stimulimi». (Më shumë rreth këtyre faktorëve mund të lexoni në artikullin e Gordon Huff: «Mësimet DevOps: 4 aspekte të eksperimenteve të shëndetshme».)
4. Hapur rrugën përpara
Ben Grinnell, drejtor menaxhues dhe kryesues i teknologjive digjitale në firmën konsultuese North Highland: «Për të arritur shkallëzim, rekomandoj që së bashku me projektet pionierë të nisni një program “pastrimi rruge”. Qëllimi i këtij programi është të heqë mbeturinat që mbeten pas pionierëve të DevOps, siç janë rregullat e skaduara dhe gjëra të tjera të ngjashme, në mënyrë që rruga përpara të mbetet e hapur».
«Jepni mbështetje organizative njerëzve dhe jepni nxitje përmes komunikimit që shkon shumë përtej grupit të pionierëve, duke festuar gjerësisht sukseset e metodave të reja të punës. Trajnoni njerëzit që janë të angazhuar në valën e ardhshme të projekteve të DevOps dhe që janë të shqetësuar sepse po përdorin DevOps për herë të parë. Dhe mbani mend se këta njerëz janë shumë ndryshe nga pionierët».
5. Bëni mjetet më demokratike
Steve Newman, themelues dhe kryetar i bordit të kompanisë Scalyr: «Mjetet nuk duhet të fshihen nga njerëzit, dhe ato duhet të jenë relativisht të thjeshta për t'u mësuar për çdo kush që është i gatshëm të investojë kohë në to. Nëse mundësia për të kërkuar regjistrat u jepet vetëm tre njerëzve, “të certifikuar” për të punuar me ndonjë mjet, do të keni gjithmonë maksimumi tre persona që mund të përballen me problemin përkatës, madje edhe nëse keni një ambient të shumëfishtë llogaritës. Me fjalë të tjera, këtu formohet një ngushticë, që mund të ketë pasoja serioze (për biznesin)».
6. Krijoni kushte ideale për punën e ekipit
Tom Clark, udhëheqës i sektorit Common Platform në kompaninë televizive ITV: «Mund të bëni çfarëdo, por jo të gjitha njëherësh. Prandaj, vendosni qëllime të mëdha, filloni nga e vogla dhe lëvizni përpara me iteracione të shpejta. Me kalimin e kohës, do të fitoni reputacionin e një ekipi që arrin rezultatet, kështu që të tjerët gjithashtu do të duan të përdorin metodat tuaja. Dhe mos u përpiqni të krijoni një ekip me performancë të lartë. Në vend të kësaj, siguroni njerëzve kushte perfekte për punë dhe efikasiteti do të vijë vetë».
7. Mos harroni ligjin e Conway-it dhe tabelat Kanban
Logan Daigle, drejtor i dorëzimit të softuerit dhe strategjisë DevOps në CollabNetVersionOne: «Është e rëndësishme të kuptojmë pasojat e ligjit të Conway-it. Në përmbledhjen time të lirë, ky ligj thotë se produktet që krijojmë dhe proceset që përdorim, përfshirë DevOps, rezultojnë të strukturuara ashtu si organizata jonë».
«Nëse organizata ka një ndarje të lartë dhe menaxhimi kalon shumë herë nga dora në dorë gjatë planifikimit, krijimit dhe lëshimit të softuerit, efekti i shkallëzimit do të jetë zero ose jokohë. Nëse organizata formon ekipe ndër-funksionale rreth produkteve që financohen me orientim ndaj tregut, atëherë mundësitë për sukses rriten ndjeshëm».
«Një aspekt tjetër i rëndësishëm i shkallëzimit është të shfaqni në tabelat Kanban të gjitha punët që janë në proces (WIP, work in progress). Kur në organizatë ka një vend ku njerëzit mund të shohin këto gjëra, kjo nxit shumë bashkëpunimin, gjë që ka një efekt pozitiv në shkallëzim».
8. Kërkoni plagët e vjetra
Manuel Pais, konsultant për DevOps dhe bashkautor i librit 'Team Topologies': «Të nxjerrësh praktikat DevOps jashtë vetë DevOps dhe të përpiqesh t'i aplikosh ato në funksione të tjera vështirë se mund të quhet një qasje optimale. Kjo padyshim do të japë një efekt të caktuar (për shembull, përmes automatizimit të menaxhimit manual), por mund të arrihet shumë më tepër nëse fillon me kuptimin e proceseve të dorëzimit dhe reagimit».
«Nëse në sistemin IT të organizatës ka shenja të vjetra – procedura dhe mekanizma menaxhimi që janë zbatuar si rezultat i incidenteve të kaluara, por kanë humbur relevancën (për shkak të ndryshimeve në produkte, teknologji ose procese), atëherë ata patjetër duhet të hiqen ose të sheshohen, e jo të automatizohen procese joefektive ose të panevojshme».
9. Mos krijoni variante DevOps
Antony Edwards, drejtor i prodhimit në kompaninë Eggplant: «DevOps është një term shumë i paqartë, ndaj çdo ekipse merr versionin e vet të DevOps. Nuk ka gjë më të keqe se sa kur në një organizatë krijohen 20 variacione të DevOps që nuk përputhen mirë me njëra-tjetrën. Nuk duhet që çdo grup zhvilluesish të ketë një ndërfaqe të veçantë mes zhvillimit dhe menaxhimit të produktit. Ashtu si nuk duhet që produktet të kenë pritshmëri unike për mënyrën e trajtimit të feedback-ut kur transferohen në simulimin e mjedisit të prodhimit. Përndryshe, asnjëherë nuk do të mund të shkallëzoni DevOps».
10. Predikoni vlerën e DevOps për biznesin
Steve Newman, themelues dhe kryetar i bordit të kompanisë Scalyr: «Punoni për njohjen e vlerës së DevOps. Mësoni dhe mos hezitoni të flisni për përfitimin e asaj që bëni. DevOps kursen jashtëzakonisht kohë dhe para (mjafton të mendoni: më pak ndalesa, kohë më e shkurtër rikuperimi), dhe ekipet DevOps duhet të theksojnë (dhe të predikojnë) rëndësinë e këtyre nismave për suksesin e biznesit. Kështu, do të mund të zgjeroni radhet e përkrahësve dhe të forconi ndikimin e DevOps në organizatë».
BONUS
Në Më 13 Shtator do të vijë DevOps-i ynë – po, Red Hat, si prodhues i softuerit, ka ekipet dhe praktikat e veta të DevOps.
Inxhinieri ynë Mark Birger, i cili merret me zhvillimin e shërbimeve të automatizimit të brendshëm për grupe të tjera në të gjithë organizatën, do të tregojë historinë e tij në një gjuhë të pastër ruse – si ekipi DevOps i Red Hat migroi aplikacionet nga ambientet virtuale të menaxhuara nga Ansible në një format të plotë kontejnerësh në platformën OpenShift.
Por kjo nuk është gjithçka:
Pas pas që organizatat transferuan ngarkesat e punës në kontejnerë, metodat tradicionale të monitorimit të aplikacioneve mund të mos funksionojnë. Në raportin e dytë, ne 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 në metodat moderne të regjistrimit dhe monitorimit.
Burimi: habr.com
