"Nola inplementatu devops" galdera urteak daramatza, baina ez dago material on asko. Batzuetan, beren denbora saldu behar duten aholkulari ez hain adimentsuen iragarkien biktima izaten zara, nolanahi ere. Batzuetan, megakorporazioen ontziek unibertsoaren hedadurak nola arakatzen dituzten hitz lauso eta oso orokorrak dira. Galdera sortzen da: zer axola zaigu honek? Egile maitea, argi eta garbi formula ditzakezu zure ideiak zerrenda batean?
Hori guztia, enpresaren kulturaren eraldaketaren emaitza errealaren praktika eta ulermen handirik ez izateak sortzen du. Kultura aldaketak epe luzerako gauzak dira, eta horien emaitzak ez dira aste batean edo hilabetean agertuko. Urteetan zehar enpresak nola eraiki eta porrot egin duten ikusteko adinako norbait behar dugu.
John Willis - DevOps-en gurasoetako bat. Johnek hamarkada askotako esperientzia du enpresa kopuru handi batekin lanean. Duela gutxi, John haietako bakoitzarekin lan egitean gertatzen diren eredu zehatzak nabaritzen hasi zen. Arketipo hauek erabiliz, Johnek DevOps eraldaketaren benetako bidetik gidatzen ditu enpresak. Irakurri gehiago arketipo horiei buruz DevOops 2018 konferentziako bere txostenaren itzulpenean.
Hizlariari buruz:
35 urte baino gehiago IT kudeaketan, OpenCloud-en aurrekoaren sorreran parte hartu zuen Canonicalen, 10 startup-etan parte hartu zuen, horietako bi Dell eta Docker-i saldu zitzaizkien. Gaur egun, DevOps eta Praktika Digitaleko presidenteordea da SJ Technologies-en.
Hurrengoa Johnen ikuspuntutik istorioa da.
Nire izena John Willis da eta ni aurkitzeko lekurik errazena Twitter-en da, . Ezizena bera dut Gmail eta GitHub-en. A nire txostenen eta haien aurkezpenen bideo-grabaketak aurki ditzakezu.
Hainbat enpresa handitako CIOekin bilera asko izaten ditut. Askotan kexatzen dira ez dutela ulertzen zer den DevOps, eta hori azaltzen saiatzen diren guztiak beste zerbaiti buruz ari dira. Ohiko beste kexa bat DevOps-ek ez duela funtzionatzen da, nahiz eta badirudi zuzendariak dena egiten ari direla azaldu zaien moduan. Ehun urte baino gehiago dituzten enpresa handiez ari gara. Haiekin hitz egin ondoren, arazo askotarako ez dela goi-teknologia egokiena, teknologia baxuko irtenbideak baizik. Asteetan sail ezberdinetako jendearekin hitz egin nuen. Argitalpeneko lehenengo argazkian ikusten duzuna nire azken proiektua da, hau da gelak hiru eguneko lanaren ondoren.
Zer da DevOps?
Izan ere, 10 pertsona desberdinei galdetzen badiezu, 10 erantzun ezberdin emango dituzte. Baina hona hemen gauza interesgarria: hamar erantzun hauek zuzenak izango dira. Hemen ez dago erantzun okerrik. Nahiko sakondu nuen DevOps-en, 10 bat urtez, eta lehen amerikarra izan nintzen DevOpsDay-n. Ez dut esango DevOps-en parte hartzen duten guztiak baino adimentsuagoa naizenik, baina ia ez dago horretan hainbeste ahalegin egin duenik. Uste dut DevOps giza kapitala eta teknologia elkartzen direnean gertatzen dela. Askotan ahazten zaigu giza dimentsioa, nahiz eta era guztietako kulturaz asko hitz egiten dugun.
Orain datu asko ditugu, bost urteko ikerketa akademikoa, teoriak eskala industrialean probatzea. Azterketa hauek esaten digutena da antolakuntza-kultura batean jokabide-eredu batzuk konbinatzen badituzu, 2000x bizkortzea lor dezakezula. Azelerazio horri egonkortasunaren hobekuntza berdinarekin bat dator. DevOps-ek edozein enpresari ekar diezaiokeen onuraren neurketa kuantitatiboa da. Duela urte pare bat, Fortune 5000 enpresa bateko zuzendari nagusiarekin DevOps-i buruz hitz egiten ari nintzen. Aurkezpena prestatzen ari nintzela, oso urduri nengoen, nire urteetako esperientzia 5 minututan laburtu behar nuelako.
Azkenean honako hau eman nuen DevOps-en definizioa: Giza kapitala errendimendu handiko erakunde-kapital bihurtzea ahalbidetzen duten praktika eta eredu multzo bat da. Adibide bat da Toyotak azken 50 edo 60 urteotan funtzionatu duen modua.
(Aurrerantzean, diagramak ez dira erreferentziazko material gisa ematen, ilustrazio gisa baizik. Haien edukia desberdina izango da enpresa berri bakoitzeko. Hala ere, argazkia bereizita ikusi eta handitu daiteke.
Horrelako praktika arrakastatsuenetako bat da balio erreka mapping. Horri buruz hainbat liburu on idatzi dira, arrakastatsuenak Karen Martinenak dira. Baina azken urtean, planteamendu hori ere goi-teknologikoa dela ondorioztatu dut. Zalantzarik gabe, abantaila asko ditu eta asko erabili dut. Baina zuzendari nagusiak galdetzen dizunean zergatik bere konpainiak ezin duen trenbide berrietara aldatu, goizegi da balio-korronteen mapari buruz hitz egiteko. Askoz eta oinarrizko galdera gehiago daude lehen erantzun beharrekoak.
Nire ustez, nire lankide askok egiten duten akatsa da enpresari bost puntuko gida ematea besterik ez dutela eta sei hilabete geroago itzuli eta zer gertatu den ikusteko. Balio-korronteen mapak bezalako eskema on batek ere, demagun, puntu itsuak ditu. Hainbat enpresatako zuzendariekin ehunka elkarrizketa egin ondoren, arazoa bere osagaietan banatzeko aukera ematen duen eredu jakin bat garatu dut, eta orain osagai horietako bakoitza ordenan aztertuko dugu. Edozein soluzio teknologiko aplikatu aurretik, eredu hau erabiltzen dut, eta, ondorioz, nire horma guztiak diagramez estalita daude. Duela gutxi mutualitate batekin ari nintzen lanean eta horrelako 100-150 eskemekin amaitu nuen.
Kultura txarrak planteamendu onak jaten ditu gosaltzeko
Ideia nagusia hau da: Lean, Agile, SAFE eta DevOps kopururik ez du lagunduko erakundearen kultura bera txarra bada. Urpeko ekipamendurik gabe sakonerara murgiltzea edo erradiografiarik gabe funtzionatzea bezalakoa da. Beste era batera esanda, Drucker eta Deming parafraseatuz: antolakuntza-kultura txarrak edozein sistema on irentsiko du hura ito gabe.
Arazo nagusi hau konpontzeko, urrats hauek eman behar dituzu:
- Egin lan guztiak ikusgai: lan guztiak ikusgai jarri behar dituzu. Ez nahitaez pantailaren batean bistaratu behar den zentzuan, behagarria izan behar duen zentzuan baizik.
- Lanak Kudeatzeko Sistema bateratuak: kudeaketa sistemak sendotu behar dira. Ezagutza βtribalarenβ eta ezagutza instituzionalaren arazoan, 9etik 10 kasutan botila-lepoa pertsonak dira. Liburuan arazoa pertsona bakar batekin zegoen, Brent, eta horrek proiektua hiru urte atzeratzea eragin zuen. Eta βBrentβ hauekin topo egiten dut nonahi. Botil-lepo hauek konpontzeko, gure zerrendako hurrengo bi elementuak erabiltzen ditut.
- Murrizketen Teoria Metodologia: murrizketen teoria.
- Lankidetza hack: lankidetza hackeak.
- Toyota Kata (): Ez dut asko hitz egingo Toyota Katari buruz. Interesa baduzu, nire github-en gai horietako ia guztietan.
- Merkatuari zuzendutako erakundea: merkatura bideratutako antolakuntza.
- Shift-ezkerreko ikuskariak: auditoria zikloaren hasierako faseetan.
Oso erraz hasten naiz erakunde batekin lanean: enpresara joaten naiz eta langileekin hitz egiten dut. Ikusten duzunez, goi-teknologiarik ez. Behar duzun guztia idazteko zerbait da. Gela batean hainbat talde biltzen ditut eta esaten didatena aztertzen dut nire 7 arketipoen ikuspegitik. Eta gero beraiek errotulagailu bat ematen diet eta orain arte ozen esandako guztia arbelean idazteko eskatzen diet. Normalean bilera mota hauetan dena idazten duen pertsona bat egoten da, eta, onenean, eztabaidaren %10 idatz dezake. Nire metodoarekin, zifra hau %40 ingurura igo daiteke.
(Ilustrazio hau bereiz ikus daiteke )
Nire ikuspegia William Schneiderren lanean oinarritzen da. ). Planteamendua edozein erakunde lau laukitan banatu daitekeen ideian oinarritzen da. Niretzat eskema hau erakunde bat aztertzean sortzen diren beste ehunka eskema horiekin lan egitearen emaitza izan ohi da. Demagun kontrol maila handiko erakunde bat dugula, baina gaitasun baxukoa. Hau oso desiragarria den aukera bat da: denek marrari eusten diotenean, baina inork ez daki zer egin.
Aukera apur bat hobea kontrol eta gaitasun maila altua duena da. Horrelako enpresa bat errentagarria bada, agian ez du DevOps behar. Interesgarriena da kontrol maila altua, gaitasun eta lankidetza baxua, baina aldi berean kultura (laborantza) maila altua duen enpresa batekin lan egitea. Horrek esan nahi du enpresak bertan lan egitea gustuko duen jende asko duela eta lan-fakturazioa txikia dela.
(Ilustrazio hau bereiz ikus daiteke )
Iruditzen zait jarraibide zurrunak dituzten metodoek egia lortzeko oztopatzen amaitzen dutela. Balio-korronteen kartografian bereziki, informazioa nola egituratu behar den arau asko daude. Lanaren hasierako faseetan, orain ari naizen honetan, inork ez ditu arau hauek behar. Markagailua eskuetan duen pertsona batek enpresaren benetako egoera deskribatzen badu taulan, hau da egoera ulertzeko modurik onena. Informazio hori ez da zuzendarietara iristen. Momentu honetan, ergela da pertsona etetea eta gezi moduko bat gaizki marraztu zuela esatea. Etapa honetan, hobe da arau sinpleak erabiltzea, adibidez: maila anitzeko abstrakzioa kolore anitzeko markatzaileak erabiliz besterik gabe sor daiteke.
Berriro diot, goi-teknologiarik ez. Errotulagailu beltzak dena nola funtzionatzen duen errealitate objektiboa irudikatzen du. Errotulagailu gorri batekin, jendeak gaur egungo egoerari buruz gustatzen ez zaiona markatzen du. Garrantzitsua da hau idaztea, ez nik. Bilera baten ondoren CIOra joaten naizenean, ez dut konpondu beharreko 10 gauzen zerrendarik eskaintzen. Enpresako jendeak esaten duenaren eta dauden eredu frogatuen artean loturak aurkitzen ahalegintzen naiz. Azkenik, marka urdin batek arazoari irtenbide posibleak iradokitzen ditu.
(Ilustrazio hau bereiz ikus daiteke )
Ikuspegi honen adibide bat goian azaltzen da orain. Urte honen hasieran banku batekin lan egin nuen. Segurtasuneko jendea sinetsita zegoen ez zutela etorri behar diseinu eta eskakizunen berrikuspenetara.
(Ilustrazio hau bereiz ikus daiteke )
Eta gero beste sail batzuetako jendearekin hitz egin genuen eta ondorioztatu zen duela 8 urte inguru, software garatzaileek segurtasun langileak kaleratu zituzten lana moteltzen ari zirelako. Eta gero debeku bihurtu zen, eta hori normaltzat hartzen zen. Errealitatean debekurik ez zegoen arren.
Gure bilera oso modu nahasian joan zen: hiru ordu inguruz, bost talde ezberdin ezin izan zidaten kodearen eta muntaketaren artean gertatzen ari zena azaldu. Eta hau badirudi gauzarik sinpleena dela. DevOps-eko aholkulari gehienek uste dute denek dagoeneko dakitela hori.
Orduan, lau orduz isilik egon zen IT gobernantzako arduradunak bat-batean bizia hartu zuen bere gaiari heldu genionean, eta oso denbora luzez okupatu gintuen. Bukaeran galdetu nion zer iritzi duen bilerari buruz, eta ez dut inoiz ahaztuko bere erantzuna. Esan zuen: "Lehen pentsatzen nuen gure bankuak bi modu besterik ez zituela softwarea emateko, baina orain badakit bost daudela, eta ez nituen hiru ezagutzen".
(Ilustrazio hau bereiz ikus daiteke )
Banku honetan azken bilera inbertsio software taldearekin izan zen. Berarekin atera zen orri batean errotulagailu batekin diagramak idaztea arbelean baino hobea dela, eta are hobea dela arbel adimendun batean baino.
Ikusten dituzun argazkiak gure bilerako laugarren egunean hoteleko hitzaldi-aretoa nolakoa zen. Eta ereduak, hau da, arketipoak bilatzeko erabili genituen eskema horiek.
Beraz, langileei galderak egiten dizkiet, hiru koloretako errotulagailuekin (beltza, gorria eta urdina) idazten dituzte erantzunak. Haien erantzunak arketipoetarako aztertzen ditut. Orain eztabaida ditzagun arketipo guztiak ordenan.
1. Egin lan guztiak ikusgai: Egin lanak ikusgai
Lan egiten dudan enpresa gehienek lan ezezagunen ehuneko oso altua dute. Esaterako, hau da langile bat beste bati etortzen zaionean eta besterik gabe zerbait egiteko eskatzen dio. Erakunde handietan, planifikatu gabeko lanak %60 egon daitezke. Eta lanaren %40a ez dago inola ere dokumentatuta. Boeing balitz, inoiz ez nintzateke haien hegazkinera igoko nire bizitzan. Lanaren erdia bakarrik dokumentatuta badago, orduan ez da jakiten lan hori behar bezala egiten ari den ala ez. Beste metodo guztiak alferrikakoak izaten dira - ezer automatizatzen saiatzea ez da ezertarako balio, ezagutzen den % 50a lanaren zati koherente eta argiena izan daitekeelako, automatizazioak ez baitu emaitza handirik emango, eta txarrena. gauzak erdi ikustezinean daude. Dokumentaziorik ezean, ezinezkoa da mota guztietako hack eta lan ezkutuak aurkitzea, botila-leporik ez aurkitzea, lehendik hitz egin nituen βBrentβ horiek beraiek. Dominica DeGrandisen liburu zoragarri bat dago . Agertzen du bost "denbora isuri" ezberdin (denbora lapurrak):
- Prozesuan lan gehiegi (WIP)
- Mendekotasun ezezagunak
- Aurreikusi gabeko lanak
- Lehentasun gatazkatsuak
- Utzitako lana
Hau oso analisi baliotsua da eta liburua bikaina da, baina aholku guzti hauek ez dute ezertarako balio datuen %50 soilik ikusten bada. Dominikak proposatutako metodoak erabil daitezke %90etik gorako zehaztasuna lortzen bada. Nagusi batek menpeko bati 15 minutuko zeregina ematen dion egoerei buruz ari naiz, baina hiru egun behar ditu; baina nagusiak ez daki benetan menpeko hori beste lauzpabost pertsonen menpe dagoenik.
Phoenix Project hiru urte beranduegi izan zen proiektu bati buruzko istorio zoragarria da. Pertsonaietako batek kaleratzeari aurre egiten dio horregatik, eta Sokrates moduko bat bezala aurkezten den beste pertsonaia batekin egiten du topo. Zehazki zer gaizki gertatu den asmatzen laguntzen du. Bihurtzen da konpainiak sistema-administratzaile bat duela, Brent izena duena, eta lan guztiak nolabait berarengandik igarotzen dira. Bileretako batean, menpeko bati galdetzen zaio: zergatik behar du ordu erdiko zeregin bakoitzak aste bat? Erantzuna ilararen teoriaren eta Little-ren legearen aurkezpen oso sinplifikatua da, eta aurkezpen honetan ikusten da %90eko okupazioan, lan ordu bakoitzak 9 ordu behar dituela. Zeregin bakoitza beste zazpi pertsonei bidali behar zaie, ordu hori 63 ordu bihurtzen da, 7 aldiz 9. Esaten dudana da Little-ren legea edo ilararen teoria konplexua erabiltzeko, gutxienez datuak eduki behar dituzula.
Beraz, ikusgarritasunaz hitz egiten dudanean, ez dut esan nahi dena pantailan dagoenik, baizik eta gutxienez datuak dituzula. Hori egiten dutenean, askotan gertatzen da planifikatu gabeko lan asko dagoela, nolabait Brent-era beharrik ez dagoenean bidaltzen ari dena. Eta Brent tipo bikaina da, ez du inoiz ezetz esango, baina ez dio inori esaten nola egiten duen bere lana.
Lana ikusgai dagoenean, datuak txukun sailkatu daitezke (argazkian hori egiten ari da Dominika), bost denborako filtrazioen abstrakzioa aplikatu, eta automatizazioa aplikatu.
2. Lanak Kudeatzeko Sistemak finkatu: Zereginen kudeaketa
Hitz egiten ari naizen arketipoak piramide moduko bat dira. Lehenengoa ondo egiten bada, bigarrena dagoeneko gehigarri moduko bat da. Hauetako askok ez dute funtzionatzen startupentzat, kontuan izan behar dira Fortune 5000 bezalako enpresa handientzat. Lan egin nuen azken enpresak 10 txartel-sistema zituen. Talde batek Remedy zuen, beste batek bere sistemaren bat idatzi zuen, hirugarren batek Jira erabiltzen zuen eta batzuek posta elektronikoarekin konformatu zuten. Arazo bera sortzen da enpresak 30 kanalizazio ezberdin baditu, baina ez dut horrelako kasu guztiak eztabaidatzeko astirik.
Jendearekin eztabaidatzen dut sarrerak nola sortzen diren, zer gertatzen zaien gero eta nola saihestu diren. Interesgarriena da gure bileretako jendeak nahiko zintzo hitz egiten duela. Galdetu nion zenbatek jartzen duten "inpaktu txikia / eza" benetan "eragin handia" eman behar zaien sarreretan. Ia denek hori egiten dutela ikusi zen. Ez naiz salaketa egiten eta ahalik eta modu guztietan saiatzen naiz pertsonak ez identifikatzen. Zintzoki zerbait aitortzen didatenean, ez dut pertsona hori lagatzen. Baina ia denek sistema saihesten dutenean, segurtasun guztia funtsean leiho-apainketa dela esan nahi du. Beraz, sistema honen datuetatik ezin da ondoriorik atera.
Txartelaren arazoa konpontzeko, sistema nagusi bat aukeratu behar duzu. Jira erabiltzen baduzu, mantendu Jira. Alternatibarik badago, izan dadila bakarra. Ondorioz, sarrerak garapen prozesuaren beste urrats bat bezala ikusi behar dira. Ekintza bakoitzak txartel bat izan behar du, garapen-fluxuan zehar joan behar duena. Sarrerak taldeari bidaltzen zaizkio, honek storyboard-ean argitaratzen ditu eta gero haien ardura hartzen du.
Hau sail guztietan aplikatzen da, azpiegitura eta eragiketa barne. Kasu honetan, gerta daiteke egoeraren ideia sinesgarriren bat gutxienez osatzea. Prozesu hau ezarri ondoren, bat-batean erraza da aplikazio bakoitzaren arduraduna nor den identifikatzea. Orain ez dugulako jasotzen zerbitzu berrien %50, %98 baizik. Oinarrizko prozesu honek funtzionatzen badu, zehaztasuna hobetzen da sistema osoan.
Zerbitzuen kanalizazioa
Hau berriro korporazio handiei bakarrik aplikatzen zaie. Eremu berri bateko enpresa berria bazara, bildu mahukak eta lan egin zure Travis CI edo CircleCI-rekin. Fortune 5000 enpresei dagokienez, lan egiten nuen bankuan gertatu zen kasua. Google etorri zitzaien eta IBM sistema zaharren diagramak erakutsi zizkieten. Google-ko mutilek nahastuta galdetu zuten: non dago honen iturburu kodea? Baina ez dago iturburu-koderik, ezta GUIrik ere. Hau da erakunde handiek aurre egin behar dioten errealitatea: 40 urteko banku-erregistroak antzinako mainframe batean. Nire bezeroetako batek Circuit Breaker ereduekin Kubernetes edukiontziak erabiltzen ditu, gehi Chaos Monkey, guztiak KeyBank aplikaziorako. Baina edukiontzi hauek, azken finean, COBOL aplikazio batera konektatzen dira.
Google-ko mutilak guztiz ziur zeuden nire bezeroaren arazo guztiak konponduko zituztela, eta orduan galderak egiten hasi ziren: zer da IBM datapipe? Esaten zaie: hau konektore bat da. Zerekin konektatzen da? Sperry sistemara. Eta zer da hori? Eta abar. Lehen begiratuan badirudi: nolako DevOps izan daiteke? Baina, egia esan, posible da. Lan-fluxua entrega-taldeei lagatzeko aukera ematen duten entrega-sistemak daude.
3. Murrizketen teoria: Murrizketen teoria
Goazen hirugarren arketipora: ezagutza instituzionala/Β«tribalaΒ». Oro har, edozein erakundetan dena dakiten eta dena kudeatzen duten hainbat pertsona daude. Hauek dira erakundean denbora gehien daramatenak eta konponbide guztiak ezagutzen dituztenak.
Diagraman hori agertzen denean, halako pertsonak marka batekin inguratzen ditut bereziki: adibidez, Lou jakin bat bilera guztietan dagoela ikusten da. Eta argi daukat: hau bertako Brent da. CIO-ak nire kamiseta eta zapatilak jantzita eta IBMko tipoa trajez jantzita aukeratzen duenean, zuzendariari beste mutilak kontatuko ez dituen eta zuzendariari agian entzutea gustatuko ez litzaiokeen gauzak kontatu diezazkidakelako aukeratzen naute. . Esaten diet haien konpainiako botila-lepoa Fred izeneko norbait eta Lou izenekoa direla. Botil-lepo hori askatu behar da, haien ezagutza nola edo hala haiengandik lortu behar da.
Arazo mota hau konpontzeko, adibidez, Slack erabiltzea iradoki dezaket. Zuzendari adimendun batek galdetuko du zergatik? Normalean, horrelako kasuetan, DevOps aholkulariek erantzuten dute: denek egiten dutelako. Zuzendaria benetan argia bada, esango du: zer. Eta hor amaitzen da elkarrizketa. Eta nire erantzuna hau da: konpainian lau botila-lepo daudelako, Fred, Lou, Susie eta Jane. Euren ezagutza instituzionalizatzeko, lehenik Slack aurkeztu behar da. Zure wiki guztiak zentzugabekeria osoa dira, inork ez baitaki haien existentziaz. Ingeniaritza taldeak front-end eta back-end garapenean parte hartzen badu eta guztiek jakin behar badute front-end garapen-taldearekin edo azpiegitura-taldearekin harremanetan jar daitezkeela galderekin. Orduan Lou edo Fredek wikian sartzeko denbora izango dute ziurrenik. Eta gero Slack-en norbaitek galdetu dezake zergatik, demagun, 5. urratsak ez duen funtzionatzen. Eta orduan Louk edo Fredek wikiko argibideak zuzenduko dituzte. Prozesu hau ezartzen baduzu, gauza asko berez sartuko dira.
Hau da nire puntu nagusia: goi-teknologiak gomendatzeko, lehenik eta behin haien oinarriak ordenatu behar dituzu, eta deskribatu berri diren teknologia baxuko irtenbideekin egin daiteke. Teknologia altuekin hasten bazara eta zergatik behar diren azaltzen ez baduzu, orduan, oro har, hau ez da ondo bukatzen. Gure bezeroetako batek Azure ML erabiltzen du, oso irtenbide merkea eta sinplea. Galderen %30 inguru autoikaskuntzarako makinak berak erantzun zituen. Eta gauza hau datu-zientzian, estatistikan edo matematikan parte hartzen ez zuten operadoreek idatzi zuten. Hau esanguratsua da. Irtenbide horren kostua minimoa da.
4. Lankidetza hack: Lankidetza hack
Laugarren arketipoa isolamenduari aurre egiteko beharra da. Jende gehienak dagoeneko badaki hau: isolamenduak etsaitasuna sortzen du. Sail bakoitza bere solairuan badago eta jendea ez bada inola ere elkar gurutzatzen, igogailuan izan ezik, orduan haien arteko etsaitasuna oso erraz sortzen da. Baina, aitzitik, jendea elkarren artean gela berean badago, berehala alde egiten du. Norbaitek salaketa orokorren bat botatzen duenean, adibidez, halako eta halako interfaze batek ez du inoiz funtzionatzen, ez dago ezer errazago horrelako akusazio bat deseraikitzea. Interfazea idatzi duten programatzaileek galdera zehatzak egiten hasi besterik ez dute egin behar, eta laster argituko da, adibidez, erabiltzaileak tresna oker erabiltzen ari zela.
Isolamendua gainditzeko modu asko daude. Behin Australiako banku baterako kontsulta egiteko eskatu zidaten, baina uko egin nion, bi seme-alaba eta emaztea ditudalako. Haiei laguntzeko egin nezakeen guztia ipuin grafikoa gomendatzea zen. Hau funtzionatzen duen zerbait da. Beste modu interesgarri bat lean kafe bilerak dira. Erakunde handi batean, ezagutza zabaltzeko aukera bikaina da. Horrez gain, barne devopsdays, hackathons-ak eta abar egin ditzakezu.
5. Kata entrenatzailea
Hasieran ohartarazi nuenez, gaur ez dut honetaz hitz egingo. Interesatzen bazaizu, begirada bat bota dezakezu .
Mike Rother-en gai honi buruzko hitzaldi ona dago:
6. Market Oriented: merkatura bideratutako antolakuntza
Hemen arazo desberdinak daude. Adibidez, "I" pertsonak, "T" pertsonak eta "E" pertsonak. βNiβ pertsonak gauza bakarra egiten dutenak dira. Normalean sail isolatuak dituzten erakundeetan daude. "T" pertsona bat gauza batean ona denean baina beste gauza batzuetan ere ona denean da. "E" edo "orrazi" pertsona batek trebetasun asko dituenean da.
Conwayren legeak hemen funtzionatzen du (), modu sinplifikatuenean honela adieraz daitekeena: hiru taldek konpilatzailean lan egiten badute, orduan hiru zatiko konpilatzailea izango da emaitza. Hori dela eta, erakunde baten barruan isolamendu-maila handia badago, Kubernetes, Circuit breaker, API hedagarritasuna eta erakunde honetako beste gauza dotore batzuk ere antolatuko dira erakundeak berak bezala. Zorrotz, Conwayren arabera eta gazte geek guztioi haserretzeko.
Arazo honen konponbidea askotan deskribatu da. Badaude, esaterako, Fernando Fernandezek deskribatutako antolakuntza-arketipoak. Hitz egin berri dudan arkitektura problematiko hori, isolatuta, funtzioetara bideratutako arkitektura da. Bigarren mota txarrena da, matrize arkitektura, beste bien nahaspila. Hirugarrena startup gehienetan ikusten dena da, eta enpresa handiak ere mota honekin bat egiten saiatzen ari dira. Merkatuari zuzendutako erakundea da. Hemen optimizatzen dugu bezeroen eskaerei erantzun azkarrena lortzeko. Batzuetan erakunde laua deitzen zaio.
Jende askok egitura hau modu ezberdinetan deskribatzen du, hitza gustatzen zait taldeak sortu/exekutatu, Amazonen deitzen diote bi pizza talde. Egitura honetan, βIβ motako pertsona guztiak zerbitzu baten inguruan biltzen dira, eta pixkanaka βTβ motara hurbiltzen dira, eta kudeaketa egokia badago, βEβ ere bihur daitezke. Hemengo lehenengo kontraargudioa da egitura horrek alferrikako elementuak dituela. Zergatik behar duzu probatzaile bat sail bakoitzean probatzaileen sail berezi bat izan dezakezu? Horri erantzuten diot: kasu honetan aparteko kostuak etorkizunean erakunde osoak "E" mota bihurtzeko prezioa dira. Egitura horretan, probatzaileak pixkanaka sareak, arkitektura, diseinua eta abar ikasten ditu. Ondorioz, antolakuntzako parte-hartzaile bakoitzak antolakuntzan gertatzen den guztiaz guztiz ezagutzen du. Eskema honek industrian nola funtzionatzen duen jakin nahi baduzu, irakurri .
7. Txanda-ezkerreko ikuskariak: zikloaren hasieran auditoria. Erakusketan dauden segurtasun-arauak betetzea
Hau da zure ekintzek usaimenaren proba gainditzen ez dutenean, nolabait esatearren. Zuretzat lan egiten duten pertsonak ez dira ergelak. Goiko adibidean bezala, eragin txikia/ez zuten leku guztietan ezarri, honek hiru urte iraun zuen, eta inork ez zuen ezer nabaritu, orduan denek ondo daki sistemak ez duela funtzionatzen. Edo beste adibide bat: aldaketa-aholku-batzordea, non txostenak aurkeztu behar diren, esate baterako, asteazkenero. Jende talde bat dago lanean (ez oso ondo ordainduta, bide batez) eta teorian sistemak bere osotasunean nola funtzionatzen duen jakin beharko luke. Eta azken bost urteotan, ziurrenik gure sistemak izugarri konplexuak direla ohartu zara. Eta bospasei lagunek egin ez duten eta ezer ez dakiten aldaketa bati buruzko erabakia hartu behar dute.
Jakina, ikuspegi honek ez du funtzionatzen. Horrelako gauzak kendu behar ditut, pertsona hauek ez dutelako sistema babesten. Erabakia taldeak berak hartu behar du, taldeak izan behar duelako horren erantzule. Bestela, egoera paradoxikoa sortzen da bere bizitzan inoiz koderik idatzi ez duen kudeatzaile batek programatzaileari kodea idazteko zenbat denbora behar duen esaten dionean. Lan egin nuen enpresa batek aldaketa guztiak berrikusten zituzten 7 batzorde ezberdin zituen, arkitektura taula bat, produktuen taula, etab. Derrigorrezko itxaronaldi bat ere bazegoen, nahiz eta langile batek esan zidan hamar urteko lanean inork ez zuela sekula baztertu pertsona honek derrigorrezko epe horretan egindako aldaketarik.
Ikuskariak gonbidatu behar dira gurekin bat egitera, ez haietatik kentzeko. Esan ontzi bitar aldaezinak idazten dituzula, proba guztiak gainditzen badituzte, betirako aldaezinak izaten jarraitzen dutenak. Esan kode gisa kanalizazio bat duzula eta azaldu horrek zer esan nahi duen. Erakuts iezaiezu eskema hau: ahultasun-proba guztiak gainditzen dituen edukiontzi batean irakurtzeko soilik den bitar aldaezina; eta orduan inork ez du ukitu, kanalizazioa sortzen duen sistema ere ez dute ukitzen, dinamikoki ere sortzen baita. Bezeroak ditut, Capital One, Bault erabiltzen ari direnak blockchain bezalako zerbait sortzeko. Ikuskariak ez du Chef-en "errezeta"rik erakutsi behar; nahikoa da blockchain-a erakustea, eta hortik argi dago Jira txartelarekin zer gertatu den ekoizpenean eta nor den horren arduraduna.
Arabera , Sonatypek 2018an sortua, 2017 milioi OSS deskargatzeko eskaera izan ziren 87an.
Ahultasunen ondorioz sortutako galerak debekagarriak dira. Gainera, orain goian ikusten dituzun zifrek ez dituzte aukera-kostuak sartzen. Zer da DevSecOps laburbilduz? Esan dezadan berehala ez zaidala interesatzen izen honek nolako arrakasta duen hitz egitea. Kontua da DevOps-ek arrakasta handia izan duenez, kanalizazio horri segurtasuna gehitzen saiatu beharko genukeela.
Sekuentzia honen adibide bat:
Hau ez da produktu zehatzetarako gomendioa, nahiz eta guztiak gustatzen zaizkidan. Adibide gisa jarri ditut erakusteko DevOps-ek, hasiera batean industriako antolakuntza-paradigman oinarritzen zena, produktu baten lan-etapa guztiak automatizatzeko aukera ematen duela.
Eta ez dago arrazoirik segurtasunari buruzko ikuspegi bera hartu ez genezakeen.
Guztira
Ondorio gisa, DevSecOps-erako aholku batzuk emango ditut. Ikuskariak sartu behar dituzu zure sistemak sortzeko prozesuan eta haiek hezten denbora eman. Ikuskariekin lankidetzan aritu behar duzu. Ondoren, positibo faltsuen aurkako borroka erabat errukigabea egin behar duzu. Nahiz eta ahultasun-tresnarik garestiena izan, zure garatzaileen artean oso ohitura txarrak sor ditzakezu zure seinale-zarata erlazioa zein den ez badakizu. Garatzaileak gertaeraz gainezka geratuko dira eta besterik gabe ezabatu egingo dituzte. Equifax istorioaren berri izan bazenuen, hori gutxi gorabehera han gertatu zen, non alerta-maila gorena baztertu zen. Horrez gain, ahultasunak negozioan nola eragiten duten argi utzi behar da. Esaterako, esan liteke Equifax istorioaren ahultasun bera dela. Segurtasun-ahuleziak beste software-arazoen antzera tratatu behar dira, hau da, DevOps prozesu orokorrean sartu behar dira. Haiekin lan egin behar duzu Jira, Kanban, etab. Garatzaileek ez dute pentsatu behar beste norbaitek hori egingo duenik; aitzitik, denek egin beharko lukete. Azkenik, jendea trebatzeko energia gastatu behar duzu.
Esteka interesgarriak
Hona hemen erabilgarriak izan daitezkeen DevOops konferentziako hitzaldi batzuk:
- Sergey Berdnikov, Artyom Kalichkin - Arrakasta-istorioa edo "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps eskala batean: tragedia greziarra hiru ekitalditan (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Begiratu DevOops 2020 Mosku β hor ere gauza interesgarri asko daude.
Iturria: www.habr.com