E vështirë të kapësh thelbin, duke folur për DevOps? Ne kemi mbledhur për ju analogji të qarta, formulime të fuqishme dhe këshilla nga ekspertët, të cilat do t'ju ndihmojnë të arrini thelbin madje edhe për ata që nuk janë specialistë. Në fund, një bonus – DevOps i punonjësve të Red Hat.
Termi DevOps u shfaq 10 vjet më parë dhe kaloi nga një hashtag në Twitter në një lëvizje kulturore të fuqishme në botën e IT, një filozofi e vërtetë që inkurajon zhvilluesit të arrijnë rezultate më shpejt, të eksperimentohet dhe të ecet përpara me metoda iteracioni. DevOps është bërë pandashëm i lidhur me konceptin e transformimit digjital. Por siç ndodh shpesh me terminologjinë e IT, në një dekadë DevOps ka grumbulluar shumë përkufizime, interpretime dhe keqkuptime për veten e tij.
Prandaj, shpesh dëgjohet pyetje si: a është kjo e njëjtë me agile? Ose është ndonjë metodologji e veçantë? A është thjesht një sinonim tjetër për fjalën "bashkëpunim"?
DevOps përfshin shumë koncepte të ndryshme (dërgimi i vazhdueshëm, integrimi i vazhdueshëm, automatizimi etj.), prandaj mund të jetë e vështirë të veçosh thelbin, veçanërisht kur je i interesuar për temën. Megjithatë, kjo aftësi është shumë e dobishme, pavarësisht nëse po përpiqesh të arrish idetë tua te eprorët apo thjesht t'i tregosh punën tënde dikujt nga familja ose miqtë. Prandaj, për momentin, le të anashkalojmë nuancat terminologjike të DevOps dhe të përqendrohemi në tablonë e përgjithshme.
Çfarë është DevOps: 6 përkufizime dhe analogji
Ne i kërkuam specialistëve të shpjegonin thelbin e DevOps sa më thjeshtë dhe shkurt, për t'i bërë vlerën të kuptueshme për lexuesit me çdo nivel përgatitjeje teknike. Pas këtyre bisedave, ne zgjodhëm analogjitë më të spikatura dhe formulimet më të fuqishme që do t'ju ndihmojnë të ndërtoni tregimin tuaj për DevOps.
1. DevOps – është një lëvizje kulturore
"DevOps është një lëvizje kulturore, ku të dy palët (zhvilluesit e softuerit dhe specialistët e operacioneve të sistemeve IT) pranojnë se softuari nuk sjell dobi reale deri sa dikush të fillojë ta përdorë: klientët, konsumatorët, punonjësit, nuk ka rëndësi, – thotë Evelina Oehrlich, analiste e lartë hulumtuese në Institutin DevOps. – Prandaj, këto dy palë bashkërisht sigurojnë dërgimin e shpejtë dhe cilësor të softuerit."
2. DevOps – është ajo që fuqizon zhvilluesit
"DevOps fuqizon zhvilluesit me autoritetin për të zotëruar aplikacionet, për t'i nisur dhe menaxhuar dërgimin nga fillimi deri në fund"
"Zakonisht flitet për DevOps si një mënyrë për të përshpejtuar dërgimin e aplikacioneve në prodhim përmes ndërtimit dhe përdorimit të proceseve automatizuar, – thotë Jai Schniepp, drejtori i platformave DevOps në kompaninë e sigurimeve Liberty Mutual. – Por për mua, kjo është diçka shumë më thelbësore. DevOps fuqizon zhvilluesit me autoritetin për të zotëruar aplikacionet ose pjesët e caktuara të softuerit, për t'i nisur dhe menaxhuar dërgimin nga fillimi deri në fund. DevOps zgjidh konfuzionin e përgjegjësisë dhe ndihmon të gjithë pjesëmarrësit të krijojnë një infrastrukturë të automatizuar dhe të menaxhuar nga zhvilluesi."
3. DevOps – është bashkëpunimi në krijimin dhe dërgimin e aplikacioneve
"Thjesht, DevOps është një qasje për prodhimin dhe dërgimin e softuerit, kur të gjithë punojnë së bashku", – vëren Gur Staff, presidenti dhe kreu i departamentit të automatizimit të biznesit digjital në BMC.
4. DevOps – është një linjë montimi
"Linja e montimit është e mundur, vetëm nëse të gjitha pjesët përputhen me njëra-tjetrën."
"Unë do ta krahasonja DevOps me një linjë montimi makinash, – vazhdon Gur Staff. – Ideja është që të dizajnohen dhe prodhohen paraprakisht të gjitha pjesët që më vonë mund të mblidhen pa nevojën e përshtatjeve individuale. Linja e montimit është e mundur, vetëm nëse të gjitha pjesët përputhen me njëra-tjetrën. Ata që projektojnë dhe prodhojnë motorin, duhet të mendojnë se si ta lidhin atë me karrocerinë ose kornizën. Ata që bëjnë frenat, duhet të mendojnë për rrotat, e kështu me radhë. 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 informacionin mbi klientët, për mjetet e sigurisë për të mbrojtur të dhënat e përdoruesve, si dhe për mënyrën se si do të funksionojë gjithçka kur shërbimi fillon të shërbejë një audiencë të madhe, ndoshta madje 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, e jo të përqendrohen vetëm në detyrat e tyre, është pengesa më e madhe që duhet kaluar. Nëse kjo arrihet, ju keni shanse të shkëlqyera për transformimin digjital", – shton Gur Staff.
5. DevOps – është kombinimi i duhur i njerëzve, proceseve dhe automatizimit
Jane Groll (Jayne Groll), drejtoreshë ekzekutive e Institutit DevOps, ofroi një analogji të shkëlqyer për të shpjeguar DevOps. Ajo thotë: «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ë marrin 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 ti përzgjidhësh proporcioni dhe të përziejmë këta përbërës për të përmirësuar shpejtësinë dhe efikasitetin në krijimin dhe lëshimin e aplikacioneve.»
6. DevOps – është kur programuesit punojnë si një ekip i Formula 1
«Gatimi planifikohet jo nga fillimi në fund, por përkundrazi, nga fundi në fillim.»
«Duke folur për atë çfarë mund të pritet nga iniciativa DevOps, unë jap shembullin e një ekipi garash NASCAR ose Formula 1,» thotë Chris Short, menaxheri kryesor i marketingut të platformave cloud të Red Hat dhe botuesi i newsletter-it DevOps’ish. «Kryetari i këtij ekipi ka një qëllim: të arrijë vendin më të lartë të mundshëm në fund të garës duke marrë parasysh burimet e disponueshme për ekipin dhe sfidat që i kanë rënë. Në të njëjtën kohë, gara planifikohet jo nga fillimi në fund, por përkundrazi, nga fundi në fillim. Fillimisht vendoset një qëllim ambicioz, pastaj përcaktohen rrugët për ta arritur atë. Më pas, ato ndahen në nën detyra dhe delegohen anëtarëve të ekipit.»
«Gjatë gjithë javës para garës, ekipi i finalizon ndihmën. Pjesa fizike dhe stërvitjet kardiovaskulare bëhen, në mënyrë që të jenë në formë në atë ditë të lodhshme garash. Ata stërvitin veprimet e përbashkëta për të zgjidhur çdo problem që mund të lindë gjatë garës. Po ashtu, ekipi i zhvilluesve duhet të stërvitet për të lëshuar shpesh versione të reja. Duke pasur këto aftësi dhe një sistem të kuruar të sigurisë, lëshimi i versioneve të reja në prodhim ndodh më shpesh. Në kuadër të këtij mendimi, rritja e shpejtësisë do të thotë rritje të sigurisë,» thotë Short.
«Nuk bëhet fjalë për të bërë “gjërat e duhura”, – shton Short, – por për të eliminuar sa më shumë gjëra që qëndrojnë në rrugën e rezultatit të dëshiruar. Bashkëpunoni dhe adaptohuni me informacionin që merrni në kohë reale. Bëhuni të gatshëm për anomalitë dhe punoni për të rritur cilësinë, për të minimizuar ndikimin e tyre në arritjen e qëllimit. Ky është realiteti që na pret në botën e DevOps.»
Si të shkallëzohet DevOps: 10 këshilla nga ekspertët
DevOps-i i thjeshtë dhe DevOps-i masiv janë plotësisht gjëra të ndryshme. Ne do të tregojmë se si të tejkaloni pengesat 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ë rejat dhe sukseset e para nuk vonojnë.
Për fat të keq, kjo është vetëm një shkëlqim i rremë, një iluzion progresi, siç thotë Ben Grinnell, drejtori menaxhues dhe kreu i ndarjes së teknologjive dixhitale të firmës konsulente North Highland. Sukseset e hershme natyrisht inkurajojnë, por nuk ndihmojnë në arritjen e qëllimit përfundimtar, që është përdorimi masiv i DevOps në organizatë.
Është e lehtë të shihet se si formohet një kulturë ndarjeje në “ne” dhe “ata”.
«Shpesh organizatat nisin projekte pionierë, duke menduar se do të hapin rrugën për DevOps masiv, pa menduar nëse të tjerët do të mund dhe do të duan të ndjekin këtë rrugë,» shpjegon Ben Grinnell. «Ekipet për të realizuar këto projekte shpesh përbëhen nga “vargë” me vetëbesim, që tashmë kanë bërë diçka të ngjashme në vende të tjera, por janë të rinj në organizatën tuaj. Ndërkohë, ata inkurajohen të heqin dhe shkatërrojnë rregullat që mbeten të detyrueshme për të tjerët. Është e lehtë të shihet se si rezulton një kulturë ndarjeje në “ne” dhe “ata”, që pengon transferimin e njohurive dhe aftësive.»
«Dhe kjo problematikë kulturore është vetëm një nga arsyet pse DevOps është e vështirë për t'u shkallëzuar. Ekipet DevOps përballen me rritjen e vështirësive teknike, të zakonshme për kompanitë me rritje të shpejtë që kanë vënë bast në teknologjitë IT,» thotë Steve Newman, themelues dhe kryetar i kompanisë Scalyr.
«Në botën moderne, shërbimet ndryshojnë menjëherë sapo shfaqet nevoja. Të realizosh dhe implementosh funksione të reja është për të ardhur mirë, por koordinimi i këtij procesi dhe zgjidhja e problemeve që lindin është një vështirësi e vërtetë», thotë Steve Newman. «Në organizatat që rriten shumë shpejt, inxhinierët në skuadrat ndërfunksionale luftojnë për të ruajtur mundësinë për të gjurmuar ndryshimet dhe efektet kaskadë që krijohen në nivelin e varësive. Më shumë se kaq, inxhinierët nuk ndihen mirë kur u hiqet kjo mundësi, duke i bërë ata të kenë më shumë vështirësi për të kuptuar thelbin e problemeve që lindin».
Si të kaloni këto vështirësi dhe të kaloni në përdorimin masiv të DevOps në një organizatë të madhe? Ekspertët këshillojnë të jeni të durueshëm, edhe nëse qëllimi juaj përfundimtar është të aceleroni 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 graduale dhe iterativ sa zhvillimi Agile (dhe duhet të ndikojë po ashtu në kulturë). Në Agile dhe DevOps fokusi është në grupe të vogla. Por ndërsa numri dhe integrimi i grupeve të tilla rritet, gjithnjë e më shumë njerëz aplikojnë metoda të reja pune, duke sjellë kështu një transformim kulturor të madh».
2. Dedikoni mjaft kohë planifikimit dhe zgjedhjes së platformës
Eran Kinsbruner, evangelisti kryesor teknologjik i Perfecto: «Për të funksionuar zgjerimi, grupet DevOps në fillim duhet të mësojnë të kombinojnë proceset, mjetet dhe aftësitë tradicionale, dhe pastaj gradualisht të rrisin çdo fazë të veçantë të DevOps dhe ta stabilizojnë atë. Çdo gjë fillon me planifikimin e kujdesshëm të historive përdoruese (user stories) dhe rrjedhave të krijimit të vlerës (value streams), pas së cilës vijon shkruarja e software-it dhe kontrolli i versioneve duke përdorur development bazuar në trunk ose qasje të tjera më të përshtatshme për degëzimin dhe bashkimin e kodit».
«Më pas, ka faza e integrimit dhe testimit, ku kërkohet një platformë e shkallëzuar për automatizim. Është e rëndësishme që grupet DevOps të zgjedhin platformën e duhur që t’i përshtatet nivelit të tyre të aftësive dhe qëllimeve përfundimtare të projektit.
Faza tjetër është shpërndarja në mjedisin e prodhimit, dhe ajo duhet të jetë plotësisht e automatizuar duke përdorur mjete orkestrimi dhe kontejnerësh. Është gjithashtu e rëndësishme të ketë mjedise të virtualizuara në të gjitha fazat e DevOps (simulator i mjedisit të prodhimit, mjedisi i kontrollit të cilësisë dhe, natyrisht, mjedisi i prodhimit) dhe gjithmonë përdorimi i të dhënave më të fundit për test, për të marrë konkluzione të sakta. Analitika duhet të jetë e mençur dhe në gjendje të përpunojë të dhëna të mëdha me feedback të shpejtë dhe efektiv».
3. Çlironi përgjegjësinë nga ndjenja e fajit
Gordon Haff, evangelisti i RedHat: «Krijimi i një sistemi dhe një atmosfere që lejon dhe inkurajon eksperimente, bën të mundur realizimin e ashtuquajturave dështime të suksesshme në zhvillimin Agile të software-it. Kjo nuk do të thotë se askush nuk është përgjegjës për dështimet. Në të vërtetë, vendosja e përgjegjësit bëhet edhe më e lehtë, sepse 'të jesh përgjegjës' nuk do të thotë më 'të jesh shkaktar i një aksidenti'. Thelbi i përgjegjësisë prandaj ndryshon në mënyrë kualitative. Në këtë proces, katër faktorë bëhen jashtëzakonisht të rëndësishëm: shkalla e dështimit, metodat, proceset prodhuese dhe incentivat». (Më shumë rreth këtyre faktorëve mund të lexoni në artikullin e Gordon Haff: 'Mësimet DevOps: 4 aspekte të eksperimenteve të shëndetshme').
4. Pastroni rrugën përpara
Ben Grinnell, drejtor menaxhues dhe lider i departamentit të teknologjive digjitale të firmës këshilluese North Highland: «Për të arritur shkallëzimin, ju rekomandoj të filloni një program 'pastrimi të rrugës' së bashku me projektet pionierë. Qëllimi i këtij programi është të hiqni mbeturinat që mbeten pas pionierëve të DevOps, si për shembull rregullat që kanë humbur rëndësinë dhe gjëra të tjera të ngjashme, për të mbajtur rrugën përpara të lirë».
«Dajini njerëzve mbështetje organizative dhe jepni një nxitje nëpërmjet 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 DevOps dhe që janë të nervozuar sepse po përdorin DevOps për herë të parë. Dhe kini parasysh se këta njerëz ndryshojnë shumë nga pionierët».
5. Bëni mjetet më demokratike
Steve Newman, themelues dhe kryetari 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 zotëruar për këdo që është i gatshëm të investojë kohë për këtë. Nëse mundësia për të kërkuar logët i jepet vetëm tre njerëzve, 'të certifikuar' për të punuar me ndonjë mjet, do të keni gjithmonë maksimumi tre njerëz që mund të merren me problemin përkatës, edhe nëse keni një mjedis shumë të madh kompjuterik. Në fjalë të tjera, kjo krijon një ngushticë që mund të ketë pasoja serioze (për biznesin).»
6. Krijoni kushtet ideale për ekipin tuaj
Tom Clark, drejtues i seksionit Common Platform në ITV: «Mund të bëni çfarëdo, por jo gjithçka njëherësh. Prandaj, vendosni qëllime të mëdha, filloni me pak dhe ecni përpara me iteracione të shpejta. Me kalimin e kohës do të fitoni një reputacion si një ekip që arrin rezultate, kështu që të tjerët do të dëshirojnë të përdorin metodat tuaja. Dhe mos ndjekni krijimin e një ekipi me performancë të lartë. Në vend të kësaj, ofroni njerëzve kushte ideale për të punuar dhe efektiviteti do të vijë vetvetiu.»
7. Mos e harroni ligjin e Conway-t dhe tabelat kanban
Logan Daigle, drejtor për shpërndarjen e softuerit dhe strategjinë DevOps në CollabNetVersionOne: «Është e rëndësishme të kuptoni pasojat e ligjit të Conway-t. Në një përkthim të lirë, ky ligj thotë se produktet që krijojmë dhe proceset që përdorim, përfshirë DevOps, organizohen ashtu si organizata jonë.»
«Nëse organizata është shumë e shpërndarë dhe gjatë planifikimit, krijimit dhe lëshimit të softuerit menaxhimi kalon shpesh nga një dorë në tjetrën, efekti i shkallëzimit do të jetë zero ose i përkohshëm. Nëse, përkundrazi, organizata formon ekipa ndër-funksionale rreth produkteve që financohen me këndvështrim tregtar, shanset 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 ta shohin atë, kjo nxit shumë bashkëpunimin, që ndikon pozitivisht në shkallëzim.»
8. Kërkoni plagë të vjetra
Manuel Pais, këshilltar për DevOps dhe bashkëautor i librit 'Team Topologies': «Të nxjerrësh praktikat DevOps jashtë vetë Dev dhe Ops dhe të përpiqesh t'i aplikosh ato për funksione të tjera shpesh nuk është një qasje optimale. Kjo padyshim që 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ë shpërndarjes dhe reagimit.»
«Nëse në sistemin IT të organizatës ka plagë të vjetra – procedura dhe mekanizma menaxhimi që u vunë në vend pas incidenteve të kaluara, por që tani janë të paefektshëm (për shkak të ndryshimeve në produkte, teknologji ose procese) – ato patjetër duhet të hiqen ose të nivelohen, e jo të automatizohen proceset e panevojshme ose joefektive.»
9. Mos krijoni variante DevOps
Antony Edwards, drejtor për prodhimin në Eggplant: «DevOps është një term shumë i paqartë, kështu që çdo ekip krijon variantin e tij të DevOps. Nuk ka gjë më të keqe se sa të kesh 20 lloje të ndryshme DevOps në organizatë, të cilat nuk i përballojnë mirë njëra-tjetrën. Nuk është e pranueshme që çdo ekip prej tre zhvilluesish të ketë një ndërfaqe të veçantë midis zhvillimit dhe menaxhimit të produktit. Po ashtu, produktet nuk duhet të kenë pritshmëri unike për trajtimin e reagimeve në kalimin në simulatorin e mjedisit prodhues. Në të kundërt, nuk do të arrini kurrë të shkallëzoni DevOpsin.»
10. Propagoni vlerën e DevOps për biznesin
Steve Newman, themelues dhe kryetari i bordit të kompanisë Scalyr: «Punoni për njohjen e vlerës së DevOps. Mësoni dhe mos ngurroni të flisni për përfitimet e asaj që bëni. DevOps kursen kohë dhe para në mënyrë të jashtëzakonshme (mendoni: më pak ndalese, koha më e shpejtë e rikuperimit), dhe ekipet DevOps duhet të theksojnë pa ndalur (dhe të përhapin) rëndësinë e këtyre iniciativave për suksesin e biznesit. Kështu do të mund të zgjerojmë rrethin e adhuruesve dhe të forcojmë ndikimin e DevOps në organizatë.»
BONUS
Në Më 13 Shtator do të vijë DevOps-i ynë – po, Red Hat, si prodhuese softuerësh, ka ekipet dhe praktikat e veta DevOps.
Inxhinieri ynë Mark Birger, i cili merret me zhvillimin e shërbimeve të automatizimit të brendshëm për grupe të tjera në gjithë organizatën, do të tregojë historinë e tij në gjuhën e pastër ruse - si ekipi DevOps i Red Hat migroi aplikacionet nga mjediset virtuale të Hat Virtualization, të menaxhuara nga Ansible, në një format të plotë kontejnerësh në platformën OpenShift.
Por kjo nuk është e gjitha:
Pasi organizatat transferuan ngarkesat e punës në kontejnerë, metodat tradicionale të monitorimit të aplikacioneve mund të mos funksionojnë. Në raportin e dytë do të shpjegojmë motivimin tonë për të ndryshuar mënyrën e regjistrimit dhe do të tregojmë vazhdimin e rrugës që na çoi në metodat moderne të regjistrimit dhe monitorimit.
Burimi: habr.com
