Zaila al da puntu nagusia ulertzea DevOps-i buruz hitz egitean? Analogia biziak, formulazio deigarriak eta adituen aholkuak bildu ditugu, espezialista ez direnei ere puntura iristen lagunduko dieten aholkuak. Azkenean, bonus Red Hat-eko langileen DevOps propioa da.
DevOps terminoa duela 10 urte sortu zen eta Twitter-eko hashtag izatetik IT munduko kultur mugimendu indartsu izatera igaro da, garatzaileak gauzak azkarrago egitera, esperimentatzera eta iteratzera bultzatzen dituen benetako filosofia. DevOps erabat lotu da eraldaketa digitalaren kontzeptuarekin. Baina IT terminologiarekin askotan gertatzen den bezala, azken hamar urteotan DevOps-ek bere buruari buruzko definizio, interpretazio eta uste oker asko eskuratu ditu.
Hori dela eta, askotan entzun ditzakezu DevOps-i buruzko galderak, hala nola, agilearen berdina al da? Edo hori metodologia berezi bat da? Edo “lankidetza” hitzaren beste sinonimo bat besterik ez da?
DevOps-ek hainbat kontzeptu biltzen ditu (etengabeko bidalketa, etengabeko integrazioa, automatizazioa, etab.), beraz, garrantzitsua dena destilatzea zaila izan daiteke, batez ere gaiarekin sutsua zarenean. Dena den, trebetasun hau oso erabilgarria da, berdin dio zure buruei zure ideiak transmititzen saiatzen ari zaren edo, besterik gabe, zure familiako edo laguneko norbaiti zure lana kontatzen ari zaren. Hori dela eta, alde batera utzi ditzagun oraingoz DevOps-en ñabardura terminologikoak eta zentra ditzagun argazki handian.
Zer da DevOps: 6 definizio eta analogia
Adituei eskatu diegu DevOps-en funtsa ahalik eta errazen eta laburren azaltzeko, bere balioa edozein ezagutza tekniko duten irakurleentzat argi geratu dadin. Elkarrizketa horien emaitzetan oinarrituta, DevOps-i buruzko zure istorioa eraikitzen lagunduko dizuten analogia eta formulazio deigarrienak hautatu ditugu.
1. DevOps kultur mugimendu bat da
"DevOps mugimendu kultural bat da, non bi alderdiek (softwarearen garatzaileek eta IT sistemaren funtzionamenduko espezialistek) onartzen duten softwareak ez duela benetako onurarik ekartzen norbait erabiltzen hasten den arte: bezeroak, bezeroak, langileak, ez da kontua", dio Eveline Oehrlich-ek, senior ikerketak. DevOps Institutuko analista. "Hori dela eta, bi alderdi hauek elkarrekin softwarearen entrega azkarra eta kalitate handikoa bermatzen dute".
2. DevOps garatzaileak ahalduntzea da.
"DevOps-ek garatzaileei ahalmena ematen die aplikazioen jabe izateko, exekutatzeko eta entrega kudeatzeko hasieratik amaierara".
"Normalean, DevOps aplikazioak ekoizpenera bizkortzeko prozesu automatizatuak eraikiz eta ezarriz hitz egiten da", dio Jai Schnieppek, Liberty Mutual aseguru konpainiako DevOps plataformen zuzendariak. "Baina niretzat askoz gauza oinarrizkoagoa da". DevOps-ek garatzaileei ahalmena ematen die aplikazioak edo software-pieza zehatzak edukitzeko, exekutatu eta haien entrega hasieratik amaierara kudeatzeko. DevOps-ek erantzukizunen nahasmena ezabatzen du eta garatzaileek gidatutako azpiegitura automatizatu bat sortzen parte hartzen duten guztiak gidatzen ditu".
3. DevOps aplikazioak sortzeko eta entregatzeko lankidetzari buruzkoa da.
"Labur esanda, DevOps denek elkarrekin lan egiten duten softwarea ekoizteko eta entregatzeko ikuspegi bat da", dio Gur Staf, BMCko negozio digitaleko automatizazioko presidente eta buruak.
4. DevOps kanalizazio bat da
"Zinta garraiatzaileak muntatzea pieza guztiak bat egiten badute soilik posible da".
"DevOps autoak muntatzeko kate batekin alderatuko nuke", jarraitzen du Gur Staffek. – Pieza guztiak aldez aurretik diseinatzea eta egitea da asmoa, gero banakako doikuntzarik gabe muntatu ahal izateko. Garraiagailuen muntaia pieza guztiak elkarrekin egokitzen badira soilik posible da. Motor bat diseinatzen eta eraikitzen dutenek kontuan hartu behar dute nola muntatu gorputzean edo markoan. Balaztak egiten dituztenek gurpiletan pentsatu behar dute, eta abar. Gauza bera gertatu beharko litzateke softwarearekin.
Negozio-logika edo erabiltzaile-interfazea sortzen duen garatzaile batek bezeroaren informazioa gordetzen duen datu-basean, erabiltzaileen datuak babesteko segurtasun-neurrietan eta hori guztia nola funtzionatuko duen pentsatu behar du zerbitzuak, agian milioika dolarreko erabiltzaile-audientzia handi bat zerbitzatzen hasten denean. ."
“Jendeak kolaboratu eta besteek egiten ari diren lanaren ataletan pentsatzea, beren zereginetan soilik zentratu beharrean, gainditzeko oztoporik handiena da. Hori egin ahal baduzu, eraldaketa digitala egiteko aukera bikaina duzu”, gaineratu du Gur Staff-ek.
5. DevOps pertsonen, prozesuen eta automatizazioaren konbinazio egokia da
Jayne Groll, DevOps Institutuko zuzendari exekutiboak, analogia bikaina eskaini zuen DevOps azaltzeko. Bere hitzetan, "DevOps hiru osagai kategoria nagusi dituen errezeta bat bezalakoa da: pertsonak, prozesua eta automatizazioa. Osagai horietako gehienak beste arlo eta iturri batzuetatik har daitezke: Lean, Agile, SRE, CI/CD, ITIL, lidergoa, kultura, tresnak. DevOps-en sekretua, edozein errezeta on bezala, osagai horien proportzio eta nahasketa egokiak nola lortu da, aplikazioak sortzeko eta askatzeko abiadura eta eraginkortasuna areagotzeko".
6. DevOps programatzaileek 1 Formulako talde baten moduan lan egiten dutenean da
«Lasterketa ez da hasieratik amaierara aurreikusita, aitzitik, amaieratik hasierara».
"DevOps ekimen batetik espero daitekeenari buruz hitz egiten dudanean, NASCAR edo Formula 1 lasterketetako talde bat pentsatzen dut adibide gisa", dio Chris Shortek, Red Hat-eko hodeiko plataformako marketin-zuzendari nagusiak eta DevOps'ish buletinaren argitaratzaileak. – Halako talde bateko liderrak helburu bat du: lasterketa amaieran ahalik eta lekurik altuena hartzea, taldeak dituen baliabideak eta bere gain hartu dituen erronkak kontuan hartuta. Kasu honetan, lasterketa ez da hasieratik amaierara planifikatzen, aitzitik, amaieratik hasierara. Lehenik eta behin, anbizio handiko helburu bat ezartzen da, eta gero hori lortzeko bideak zehazten dira. Ondoren, azpizereginetan banatu eta taldekideen esku uzten dira».
«Taldeak lasterketa baino lehen aste osoa ematen du pit stopa hobetzen. Indarra eta kardio-entrenamendua egiten du sasoian egoteko lasterketa egun nekagarri batean. Lasterketan zehar sor daitezkeen arazoak konpontzeko elkarrekin lan egiteko praktikak. Era berean, garapen-taldeak bertsio berriak maiz askatzeko trebetasuna trebatu beharko luke. Horrelako trebetasunak eta ondo funtzionatzen duen segurtasun-sistema baduzu, bertsio berriak produkziora abian jartzea ere maizago gertatzen da. Mundu ikuskera honetan, abiadura handitzeak segurtasuna areagotzea dakar», dio Shortek.
«Ez da ‘gauza zuzena’ egitea», gaineratu du Shortek, «nahi den emaitza oztopatzen duten ahalik eta gauza gehien ezabatzea baizik. Kolaboratu eta egokitu denbora errealean jasotzen dituzun iritzien arabera. Prest egon anomaliak izateko eta lan egin kalitatea hobetzeko zure helburua lortzeko aurrerapenean duten eragina minimizatzeko. Hau da DevOps-en munduan itxaroten gaituena”.
Nola eskalatu DevOps: adituen 10 aholku
DevOps eta masa DevOps gauza guztiz desberdinak direla besterik ez da. Lehenengotik bigarrenera bidean oztopoak nola gainditu esango dizugu.
Erakunde askorentzat, DevOps-erako bidaia erraz eta atseginean hasten da. Talde sutsu txikiak sortzen dira, prozesu zaharrak berriekin ordezkatzen dira eta lehen arrakastak ez dira luze etortzen.
Ala ere, hau distira faltsu bat besterik ez da, aurrerapenaren ilusio bat, dio Ben Grinnell, North Highland aholkularitzako zuzendari kudeatzaile eta digital arduradunak. Hasierako garaipenak pozgarriak dira, zalantzarik gabe, baina ez dute laguntzen erakunde osoan DevOps-a zabaltzeko azken helburua lortzen.
Erraz ikusten da emaitza “gu” eta “euren” arteko zatiketaren kultura dela.
"Askotan, erakundeek proiektu aitzindari hauek abiarazten dituzte DevOps nagusirako bidea zabalduko dutelakoan, beste batzuk bide hori jarraitzeko gai izango diren edo prest dauden kontuan hartu gabe", azaldu du Ben Grinnellek. – Horrelako proiektuak gauzatzeko taldeak, normalean, beste leku batzuetan antzeko zerbait egin duten, baina zure erakundean berriak diren “barrangiar” autokonfiantzazkoen artean kontratatzen dira. Aldi berean, gainerako guztientzat lotesleak izaten jarraitzen duten arauak hautsi eta suntsitzera animatzen dira. Erraz ikusten da emaitza ezagutza eta trebetasunen transferentzia galarazten duen “gu” eta “haien” kultura bat dela.
"Eta kultur arazo hau DevOps eskalatzeko zaila den arrazoietako bat besterik ez da. DevOps taldeek hazten ari diren IT lehen enpresen ohikoak diren erronka tekniko areagotu egiten ari dira ", esan zuen Steve Newmanek, Scalyr-eko sortzaile eta presidenteak.
«Mundu modernoan, zerbitzuak beharra sortu bezain laster aldatzen dira. Funtzio berriak etengabe inplementatzea eta ezartzea bikaina da, baina prozesu hau koordinatzea eta sortzen diren arazoak kentzea benetako buruhaustea da, gaineratu du Steve Newmanek. – Oso azkar hazten ari diren erakundeetan, funtzio gurutzatuko taldeetako ingeniariek aldaketaren ikusgarritasuna mantentzeko eta sortzen dituen menpekotasun-mailako kaska-efektuei aurre egiten die. Gainera, ingeniariak ez dira pozten aukera hori kentzen zaienean eta, ondorioz, zailagoa egiten zaie sortzen diren arazoen funtsa ulertzea».
Nola gainditu goian deskribatutako erronka hauek eta DevOps masiboki hartzea erakunde handi batean? Adituek pazientzia eskatzen dute, nahiz eta zure azken helburua zure softwarearen garapen-zikloa eta negozio-prozesuak bizkortzea izan.
1. Gogoratu kultura aldaketak denbora behar duela.
Jayne Groll, DevOps Institutuko zuzendari exekutiboa: "Nire ustez, DevOps-en hedapenak garapen arina bezain inkrementala eta errepikakorra izan behar du (eta kulturari berdin ukitzea). Agile eta DevOps talde txikiak azpimarratzen dituzte. Baina talde horiek kopuruan eta integrazioan hazten diren heinean, jende gehiagok hartzen dugu lan egiteko modu berriak, eta, ondorioz, eraldaketa kultural itzela gertatzen da».
2. Denbora nahikoa eman plataforma bat planifikatzen eta aukeratzen
Eran Kinsbruner, Perfectoko ebanjelari tekniko nagusia: "Lan egiteko eskalatzeko, DevOps taldeek lehendabizi prozesu, tresna eta trebetasunak konbinatzen ikasi behar dute, eta gero poliki-poliki DevOps-en fase indibidual bakoitza elikatu eta egonkortu behar dute. Erabiltzaileen istorioen eta balio-korronteen plangintza zehatzarekin hasten da guztia, eta ondoren softwarea eta bertsio-kontrola idazten ditu enborrean oinarritutako garapena edo kodea adarkatzeko eta batzeko egokienak diren beste ikuspegi batzuk erabiliz".
“Ondoren, integrazio- eta proba-etapa dator, non automatizaziorako plataforma eskalagarri bat beharrezkoa den jada. Hemen garrantzitsua da DevOps taldeek euren trebetasun maila eta proiektuaren azken helburuetara egokitzen den plataforma egokia aukeratzea.
Hurrengo fasea ekoizpenera hedatzea da eta hori guztiz automatizatu behar da orkestrazio tresnak eta edukiontziak erabiliz. Garrantzitsua da DevOps-en fase guztietan ingurune birtualizatuak izatea (produkzio-simulatzailea, QA ingurunea eta benetako ekoizpen-ingurunea) eta beti probak egiteko azken datuak soilik erabiltzea ondorio garrantzitsuak lortzeko. Analitikak adimentsua izan behar du eta datu handiak prozesatzeko gai izan behar du feedback azkar eta egintzazkoekin".
3. Errua arduratik kendu.
Gordon Haff, RedHat Ebanjelaria: “Esperimentazioa ahalbidetzen eta bultzatzen duen sistema eta giro bat sortzeak softwarearen garapen arinean porrot arrakastatsuak bezala ezagutzen direnak ahalbidetzen ditu. Horrek ez du esan nahi beste inor ez denik hutsegiteen erantzule. Izan ere, erantzule nor den identifikatzea are errazagoa da, "arduradun izateak" jada ez baitu "istripu bat eragitea" esan nahi. Hau da, erantzukizunaren funtsa kualitatiboki aldatzen da. Lau faktore kritiko bihurtzen dira: etenaren norainokoa, planteamenduak, ekoizpen-prozesuak eta pizgarriak». (Faktore horiei buruz gehiago irakur dezakezu Gordon Huff-en "DevOps lessons: 4 aspects of healthy experiments".)
4. Garbitu bidea
Ben Grinnell, North Highland aholkularitzako zuzendari gerentea eta digitalaren arduraduna: “Eskala lortzeko, proiektu aitzindariekin batera “bideak garbitzeko” programa bat abiaraztea gomendatzen dut. Programa honen helburua DevOps aitzindariek atzean uzten duten zaborra garbitzea da, arau zaharkituak eta horrelakoak bezala, aurrera egiteko bidea argi egon dadin».
“Eman pertsonei antolakuntzarako laguntza eta bultzada, talde aitzindaritik haratago doan komunikazioaren bidez, lan egiteko modu berrien arrakastak zabalduz ospatuz. Entrenatu hurrengo DevOps proiektuetan parte hartzen duten eta DevOps lehen aldiz erabiltzeagatik urduri dauden pertsonak. Eta gogoratu pertsona hauek aitzindariekiko oso desberdinak direla».
5. Tresnak demokratizatu
Steve Newman, Scalyr-en sortzaile eta presidentea: «Tresnak ez dira jendeari ezkutatu behar, eta nahiko errazak izan behar dute ikasteko denbora jarri nahi duenarentzat. Erregistroak kontsultatzeko gaitasuna tresna bat erabiltzeko "ziurtatuta" duten hiru pertsonei mugatzen bazaie, beti izango dituzu gehienez hiru pertsona erabilgarri arazoa kudeatzeko, nahiz eta informatika-ingurune oso handia izan. Beste era batera esanda, badago hemen ondorio larriak (negozioak) ekar ditzakeena».
6. Talde lanerako baldintza ezin hobeak sortu
Tom Clark, ITVko Plataforma Komuneko burua: «Edozer egin dezakezu, baina ez dena aldi berean. Beraz, ezarri helburu handiak, hasi txiki eta aurrera egin iterazio azkarretan. Denborarekin, gauzak egiteko ospea garatuko duzu, beraz, besteek zure metodoak ere erabili nahi izango dituzte. Eta ez kezkatu talde oso eraginkorra sortzeaz. Horren ordez, pertsonei lan baldintza ezin hobeak eskaintzea eta eraginkortasuna izango da ondoren».
7. Ez ahaztu Conwayren Legea eta Kanban taulak
Logan Daigle, CollabNetVersionOneko Software Delivery eta DevOps Estrategiaren zuzendaria: «Garrantzitsua da Conwayren Legearen ondorioak ulertzea. Nire parafrasi soltean, lege honek dio sortzen ditugun produktuak eta horretarako erabiltzen ditugun prozesuak, DevOps barne, gure erakundearen modu berean egituratzen direla».
“Erakunde batean silo asko badago eta kontrolak eskuak askotan aldatzen badira softwarea planifikatzean, eraikitzean eta kaleratzean, eskalatzearen eragina nulua edo laburra izango da. Erakunde batek funtzio gurutzatutako taldeak sortzen baditu merkatura begira finantzatutako produktuen inguruan, orduan arrakasta izateko aukerak izugarri handitzen dira".
"Eskalatzearen beste alderdi garrantzitsu bat abian dauden lan guztiak (WIP, workinprogress) Kanban tauletan bistaratzea da. Erakunde batek jendeak gauza horiek ikusteko leku bat duenean, elkarlana asko bultzatzen du, eta horrek eragin positiboa du eskalatzean».
8. Bilatu orbain zaharrak
Manuel Pais, DevOps aholkularia eta Team Topologies-en egilekidea: "DevOps praktikak Dev eta Ops-etik haratago hartzea eta beste funtzio batzuetara aplikatzen saiatzea ez da ia ikuspegi optimoa. Horrek, zalantzarik gabe, nolabaiteko eragina izango du (adibidez, eskuzko kontrola automatizatuz), baina askoz gehiago lor daiteke entrega eta feedback prozesuak ulertzen hasten bagara».
"Erakunde baten IT sisteman orbain zaharrak badaude -iraganeko gertakarien ondorioz ezarri ziren prozedurak eta kudeaketa-mekanismoak, baina garrantzia galdu dutenak (produktuetan, teknologian edo prozesuetan izandako aldaketen ondorioz)-, zalantzarik gabe, kendu egin behar dira. edo leundu, prozesu eraginkorrak edo beharrezkoak ez direnak automatizatu beharrean».
9. Ez hazi DevOps aukerak
Anthony Edwards, Eggplant-eko Operazio zuzendaria: "DevOps termino oso lausoa da, beraz, talde bakoitzak DevOps-en bertsio propioa lortzen du. Eta ez dago ezer okerragorik erakunde batek bat-batean oso ondo konpontzen ez diren 20 DevOps barietate dituenean. Ezinezkoa da hiru garapen taldeetako bakoitzak bere garapenaren eta produktuen kudeaketaren arteko interfaze berezia izatea. Produktuek ere ez lukete beren itxaropen bereziak izan iritzia kudeatzeko produkzio-simulagailu batera transferitzen direnean. Bestela, ezingo duzu inoiz DevOps eskalatu".
10. DevOps-en negozio-balioa predikatu
Steve Newman, Scalyr-en sortzaile eta presidentea: “Lan egin DevOps-en balioa aitortzeko. Ikasi eta egin duzunaren abantailei buruz hitz egin. DevOps denbora eta dirua aurrezteko izugarria da (pentsatu: geldialdi gutxiago, berreskuratzeko denbora laburragoa), eta DevOps taldeek etengabe azpimarratu behar dute (eta predikatu) ekimen hauek negozioen arrakastarako duten garrantzia. Horrela atxikimenduen zirkulua zabaldu eta DevOps-en eragina areagotu dezakezu erakundean”.
BONUS
On Gure DevOps propioa irailaren 13an iritsiko da; bai, Red Hat-ek, software fabrikatzaile gisa, bere DevOps talde eta praktikak ditu.
Gure ingeniari Mark Birger, erakunde osoko beste taldeentzako barne automatizazio zerbitzuak garatzen dituena, bere istorioa kontatuko du errusiera hutsez: Red Hat DevOps taldeak Ansible-k kudeatutako Hat Virtualization ingurune birtualetik aplikazioak nola migratu zituen edukiontzi formatu oso batera. OpenShift plataforma.
Baina hori ez da guztia:
Erakundeek lan-kargak edukiontzietara eraman dituztenean, baliteke aplikazioen monitorizazio metodo tradizionalek ez funtzionatzea. Bigarren hitzaldian erregistratzeko modua aldatzeko gure motibazioa azalduko dugu eta erregistro eta monitorizazio metodo modernoetara eraman gintuen bidearen jarraipena erakutsiko dugu.
Iturria: www.habr.com