Duela gutxi DevOpsForum 2019ra joan nintzen, Logrocon-ek antolatuta. Jardunaldi honetan, parte hartzaileak negozioen eta garapenaren eta informazio teknologien zerbitzuetako espezialisten arteko interakzio eraginkorra lortzeko irtenbideak eta tresna berriak bilatzen saiatu ziren.
Jardunaldia arrakastatsua izan zen: benetan txosten erabilgarriak, aurkezpen formatu interesgarriak eta hizlariekin komunikazio handia izan zen. Eta bereziki garrantzitsua da inor ez ninduela ezer saltzen saiatu, azkenaldian hitzaldi handietako hizlariek errudun izan duten zerbait.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom-en esperientzia automatizazioa eta beste xehetasun batzuk moztuta.
Nire izena Yana da, probatzaile gisa lan egiten dut, automatizazioa egiten dut, baita DevOps ere, eta hitzaldietara eta topaguneetara joatea gustatzen zait. Azken bi urteetan, Oleg Bunin-en kongresuetan egon naiz (HighLoad++, TeamLead Conf), Jug ekitaldietan (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Mosku, Big Data Mosku.
Lehenik eta behin, hitzaldiaren egitaraua deitzen dut arreta. Gutxiago begiratzen diot erreportajea zertaz arituko den, eta gehiago hizlariari. Txostena oso teknologikoa eta interesgarria suertatzen bada ere, ez da egia txosteneko jardunbide egokietako batzuk zure enpresan aplikatzeko gai izango zarenik. Eta orduan bozgorailu bat behar duzu.
Argia Raiffeisenbank-en hodiaren amaieran
Normalean, interesatzen zaizkidan alboan hiztunak bilatzen ditut. DevOpsForum 2019-n, Raiffeisenbankeko hizlari batek, Mikhail Bizhan-ek, piztu zuen nire interesa. Bere hitzaldian, pixkanaka-pixkanaka euren taldeak DevOps-ra konektatzen ari diren, zergatik behar duten eta DevOps eraldaketaren ideia negozioei nola saldu behar zaien hitz egin zuen. Bada, orokorrean, hodiaren amaieran argia nola ikusi behar den hitz egin nuen.
Mikhail Bizhan, Raiffeisenbankeko automatizazio zuzendaria
Orain ez dute "DevOps" enpresan. Hau da, lan egiten du, baina ez talde guztietan. DevOps ezartzerakoan, taldeen prestutasunean oinarritzen dira, bai ingeniari espezifikoei dagokienez, bai produktuaren beharrari eta produktu hau eraikitzen den plataformaren heldutasunari dagokionez. Misha-k esan zuen nola azaldu negozio bati DevOps zergatik behar den.
Banku-segmentuak hainbat hazkunde-motor ditu: zerbitzuen kostua eta bezero-basearen hedapena. Zerbitzuen kostua handitzea ez da oso eragile ona, baina bezeroen oinarria haztea alderantziz da. Lehiakideek produktu objektiboki fresko bat kaleratzen badute, bezero guztiak bertara joaten dira, eta denborarekin merkatua mailaz joango da. Hori dela eta, produktu berriak merkatuan sartzea eta horiek sartzeko abiadura da bankuek bideratzen duten gauza nagusia. Horixe da DevOps-entzat, eta enpresek hori ulertzen dute.
Hurrengo ohar garrantzitsua: DevOps-ek ez du beti merkaturatzeko denbora murrizten. DevOps-ek ezin du bakarrik funtzionatu, produktu bat sortzeko eta merkatura eramateko prozesuaren zati bat da garapenetik ekoizpenera (kodetik bezerora). Baina kodearen aurreko guztia ez dago DevOps-ekin zuzenean lotuta. Hau da, merkatariek merkatua urtez azter dezakete eta bizitza osoa eman dezakete lehiakideekin harrapatzen. Beharrezkoa da bezeroak zer behar duen azkar ulertzea eta eginbide hau edo beste inplementatzea planifikatzea; askotan hori da nahikoa ez dena DevOps-ek funtziona dezan eta konpainiak bere helburua lortzeko. Horregatik, lehenik eta behin, Raiffeisenbankek negozioekin adostu zuen beharrezkoa zela DevOps erabiltzen ikastea. Automatizazioaren mesedetan automatizazioak ez du asko lagunduko bezero berrien borrokan.
Oro har, Misha-k uste du DevOps inplementatu behar dela, baina zentzuz. Eta prest egon behar dugu eraldaketaren hasieran taldearen produktibitatea jaitsi egingo dela, diru gutxiago irabaziko duela, baina gero justifikatuta egongo da.
Proben automatizazioa Mango Telecom-en
Tester gisa niretzat beste txosten interesgarri bat Mango Telecom-eko Egor Maslov-ek eman zuen. Aurkezpena "Proba ziklo osoaren automatizazioa SCRUM talde batean" izena zuen. Egorrek uste du DevOps SCRUMerako bereziki sortu zela, baina, aldi berean, DevOps SCRUM talde batean sartzea nahiko problematikoa da. Hau gertatzen da SCRUM taldea beti nonbait exekutatzen ari delako, ez dago astirik berrikuntzekin distraitu eta prozesua berreraikitzeko. Arazoa, gainera, SCRUMek taldean azpitaldeen bereizketarik ez izatean datza (proba taldea, garapen taldea, eta abar). Tira, gainera, lehendik dagoen prozesu bat automatizatzeko, dokumentazioa behar da, eta SCRUM-en, gehienetan, ez dago dokumentaziorik guztiz: "produktua idazkera bat baino garrantzitsuagoa da".
SCRUMera aldatu ondoren, probatzaileak garatzaileekin eginbideak probatzeko moduari buruz kontsultatzen hasi ziren. Pixkanaka-pixkanaka, funtzionalitate-bolumena handitu egin zen, ez zegoen dokumentaziorik, eta probak estali gabeko funtzionalitatean akats asko harrapatzen hasi ziren eta, oro har, jada ez zegoen argi nork eta noiz probatu zuen. Laburbilduz - nahasmena eta zalantza. Testen automatizaziora aldatzea erabaki genuen. Baina orduan ere erabateko porrota izan zen. Etxeko probatzaileentzat ezezaguna den pila batean idazten zuten automatizazio espezialistak kontratatu zituzten. Autotesten esparruak funtzionatu zuen, noski, baina azpikontratatzaileak alde egin ostean, bi aste iraun zuen. Hurrengoa bigarren zenbakia autotesta sartzeko saiakera izan zen. Hasi zen dena enpresa barruan eraiki behar zela, zure kabuz (bektore egokia: barnean espezializazioa sortu), SCRUM-en esparruan, eta prozesuan dokumentazioa sortu. Automatizaziorako pila produktuaren pilaren berdina izan behar da (hemen gehitzen ari naiz, ez probatu zure JavaScript proiektua beste ezerrekin). Esprintaren amaieran, autotestak talde osoarekin nola funtzionatzen duen erakustaldi bat egin zuten (lagungarria). Horrela, taldekide guztien inplikazioa areagotu egin zen automatizazio-prozesuan, baita autotestekiko konfiantza eta autotest hau behin betiko erabiltzeko aukera (eta hilabete batean ez da komentatuko etengabeko hutsegiteengatik).
Bide batez, DevOpsForum 2019-n mikrofono ireki bat zegoen - aspaldiko hitzaldi formatu ezaguna eta, nire ustez, erabilgarria. Horrela ibiltzen zara, txostenak entzun eta gero erabakitzen duzu hitzaldian merezi duela gai edo arazo jakin bat eztabaidatzea, arazoa konpontzeko esperientzia garrantzitsua partekatuz.
Antolatzaileek erreportaje laburren jarioa egiten zutela ere ohartu nintzen. Txosten bakoitzak 10 minutu baino gehiago irauten du, eta ondoren galderak egiten dira. Horrela, gai asko aldi berean landu eta galderak egin ditzakezu interesatzen zaizkizun hizlariei.
Aurkezpenen artean, hitzaldiko bazkideen txosnetan ibili eta gauza asko lapurtu/irabazi nituen. Ai, maite dut esku-orria!
Mahai-ingurua eta DevOps arazoak Alfastrakhovanie-ko garapen zuzendariarekin
Niretzat DevOpsForum 2019ko opilaren ginda ordubeteko osoko bilkura izan zen DevOps adituekin. Saioko lau parte-hartzaile gonbidatu zituzten DevOps ikuspegi ezberdinetatik aztertzera: Anton Isanin (Alfastrakhovanie, garapen zuzendaria), Nailya Zamashkina (Fintech Lab, operazio zuzendaria), Oleg Egorkin (Rostelecom, Agile entrenatzailea) eta Anton Martyanov (aditu independentea, DevOps-a aztertu zuten). negozioaren ikuspuntutik).
Jendearengandik gertuago eseri ziren adituak eta orduan hasi ziren gauzak gertatzen: ordu betez, entzuleen parte-hartzaileek galderak egin zituzten, eta adituek rapa hartu zuten. Batzuetan benetako eztabaidak izaten ziren. Galderak oso desberdinak ziren, adibidez: DevOps ingeniariak behar ote diren, zergatik ezin diren sistema-administratzaile gisa trebatu, DevOps guztiei eskaini behar zaie, zein den bere balioa, etab.
Gero, Anton Isaninekin pertsonalki hitz egin nuen. DevOps kultura etxe guztietara eramatearen beharraz eztabaidatu genuen eta DevOps eraldaketaren alde iluna agerian utzi genuen.
Imajina dezagun denak elkartu zirela eta erabaki zutela DevOps behar dela bai produktuak bai negozioak eta taldeak. Goazen inplementatzen. Dena atera zen. Arnasa bota genuen. DevOps-ek bezeroarengana hurbildu gaitu, orain azkar bete ditzakegu bere nahi guztiak. Ondorioz, Ops sail handi bat dugu araudi eta eskakizun zorrotzekin, eta etengabe aurkitzen ditu produktuan akatsak eta eskaera mordoa sortzen ditu. Gainera, akats guztiei "premiazko" egoera esleitzen zaie, bezeroak ustekabean botoia berdez ordez horiz koloreztatu nahi bazuen ere. Proiektua hazten ari da, kaleratze kopurua hazten ari da eta, horren arabera, bezeroek funtzionalitate berrien akats eta gaizki-ulertu kopurua. Ops-ek 10 pertsona gehiago kontratatzen ditu akatsen berri emateko, eta garapenak beste 15 kontratatzen ditu horiek ixten jarraitzeko. Eta funtzio berriak sartu beharrean, taldeak SD amaigabeekin lan egiten du, erabiltzaileari funtzionaltasuna eta laguntza aldi berean azalduz. Ondorioz, bai Ops eta bai garapena lanean ari dira, baina bezeroa eta negozioa ez daude pozik: funtzio berriak trabatu egiten dira. DevOps existitzen dela dirudi, baina ez dirudi existitzen denik.
DevOps ezartzeko beharrari dagokionez, Antonek argi eta garbi adierazi zuen hori negozioaren eskalaren araberakoa dela zuzenean. Urtean bezero bati zerbitzua emateak enpresari milioi bat milioi ekartzen badio, DevOps ez da beharrezkoa (betiere, bezero honi aldian-aldian aldaketa berriak egin behar ez badituzu). Dena txokolatez estalita dago. Baina negozioa hazten bada eta bezero gehiago agertzen badira, orduan bete behar duzu. Oro har, hasieran ez dago konpainian Ops politrik. Lehenik eta behin produktua mozten dugu, eta orduan bakarrik ulertzen dugu produktuak funtziona dezan, zerbitzariak zaindu eta hornidura kontrolatu behar ditugula. Orduan sortzen da Ops. Ulertzekoa da Ops, aparteko dibisio gisa, garapenerako oztopo mordoa jartzen hasiko dela eta entrega guztiak gelditzen hasiko direla. Hau da, kasu honetan, DevOps kultura dagoeneko garrantzitsua da, baina ez dugu ahaztu behar bere alde ilunaz.
Iturria: www.habr.com