Centric Talks. Kas yra DevOps inžinierius ir kokią vertę jis kuria įmonėje (2 dalis)

Kas yra DevOps inžinierius ir kokią vertę jis kuria įmonėje (2 dalis)

Iš tikrųjų tam tikros dalys turbūt yra nesunkiai suprantamos. Yra tam tikri įrankiai, kurie būtent naudojami DevOps praktikose, jie dažnai skiriasi nuo įrankių, naudojamų programinės įrangos kūrime tiesiogiai. Bet įdomesnė dalis – kultūra. Kodėl DevOps metodologijoje ar praktikoje yra taip stipriai pabrėžiamas kultūros svarbumas? Ar tai galima laikyti pagrindiniu faktoriumi, kad būtent dėl to ši metodologija yra tokia vertinga ir naudinga?

Aš sakyčiau, kad yra toks anglų kalbos posakis „culture eats process for breakfast“. Tai tikrai atspindi situaciją, nes aš netgi esu matęs porą pavyzdžių, kai ateidavo konsultantai, išoriniai žmonės į įmonę ir jie įdiegdavo DevOps procesus. Ta prasme, visą įrankių rinkinį ir apmokydavo komandą, bet tas dažniausiai toliau nesitęsdavo, nes po to, kai tie žmonės išeina, kadangi nėra tos DevOps kultūros, tie DevOps procesai sustoja. Nes tos komandos buvo įpratusios dirbti kitaip. Ir netgi davus įrankių rinkinį, jie vis tiek grįžo prie to būdo, kuris buvo anksčiau.

Tikrai taip. Galiu netgi vieną pavyzdį paminėti iš DevOps konferencijos, kurioje dalyvavau. Viena įmonė būtent užsiimanti DevOps procesų įvedimu pasakojo savo „nuotykius“ einant per įmones. Juos pasamdė viena įmonė, kad įvestų „DevOps procesus. Tada jie pradėjo vaikščioti ir klausinėti programuotojų, „operations“ ir visų kitų, kokios jų pagrindinės bėdos, ką reiktų išspręsti? Jie labai telkėsi ties informacijos dalijimusi ir pačia kultūra įmonėje. Tada juos pasikvietė vadovas ir sako: „Palaukit, o tai ką čia dabar jūs darot? Mes ne tam jus samdėm“. Klausia: „Kaip tai?“ Sako: „Mes jus pasamdėm, kad jūs mums automatizuotumėt tam tikrus procesus. Yra įrankis „Jenkins“, mes jį labai puikiai žinom ir neturim „Jenkins“ specialistų, jūs, prašom, suautomatizuokit“. Sako: „Tai palaukit, bet juk mus samdėt DevOps procesus įvesti, o ne vieną įrankį kažkokį sutvarkyt“. Na, ir žodžiu, jie ten bandė ilgai kovoti ir aiškinti. Kovoti gal negražus žodis, bet tiesiog su jais diskutuoti dėl tų visų procesų ir, galų gale, prieš išeinant vis tiek buvo klausimas: „O tai „Jenkins“? Žodžiu visa salė juokėsi, kad vis tiek įmonė nesuprato, kas tai yra ir kodėl to reikia, ir kaip tai pasidaryti pas save įmonėje.

Yra netgi juokelis ta tema, kad anksčiau mes turėjom tą problemą, kad „Dev“ žmonės mesdavo per tvorą „Ops“ žmonėms produktą, tai dabar mes turim atvejį, kai „Dev“ žmonės per tvorą meta karštą bulvę DevOps žmonėms, o tie meta „Ops“ žmonėms.

Visiškai tiesa. Ta prasme, tai yra dar vienas papildomas laukelis žmonių, kuriems galima numesti bulvę. Taip, sutinku. Iš tikrųjų yra labai „tricky“ situacija ir įmonėms sunku į ją nepatekti, nes, kaip jau ir minėjau, visi šoka į tą DevOps traukinį, bando kurti DevOps skyrius ir t.t. Bet viskas, ką jie padaro, sukuria tik dar vieną grupelę žmonių, kuriems galima numesti bulvę. O taip neturėtų būti.

Iš tikrųjų, dažnas atvejis ant kurio įmonės, vadinkim, paslysta, yra tai, kad jie sukuria dar vieną tarpinę, su dar vieno tipo specialistais, kurie naudoja savo įrankius. Noras, aišku, yra pagreitinti procesą, bet gaunas dažnai atvirkščiai, nes dar vienas papildomas sluoksnis, vadinkim taip, pareigybių ar rolių, tik prideda sudėtingumo procesui. Kaip tas turėtų atrodyti idealiu atveju arba veikiančiu atveju?

Geriausiu atveju, tai turėtų atrodyti taip, kaip ir minėjau, kad visi supranta ir dirba pagal DevOps procesus. Tai reiškia, kad tiek „operations“, tiek programuotojai dalyvauja tuose pačiuose susitikimuose, sprinto planavimuose, „review“ ir jie kartu priima tam tikrus sprendimus, nes jie kartu sprinto gale turės ir atsiskaityti už tai, ką jie padarė per sprintą. Turbūt geriausiu atveju taip ir turėtų būti, kad visi kartu. Paminėjau aš tik dvi roles, bet yra tiek „security“ – jie irgi turėtų dalyvauti tuose susitikimuose, duombazistai irgi būtinai privalo, galų gale, „quality assurance“, testuotojai – jie visi kartu turi dalyvauti susitikimuose, nes jie visi kartu turi žinoti, kas šiuo metu bus galbūt griaunama arba naujas dalykas pristatomas, kuris gali potencialiai padaryti įtaką pačiai produkto aplinkai ir t.t. Skamba gal ir utopiškai, nes jeigu visus sukviesime į susitikimą, daug komandos žmonių, bus tiesiog gaištamas daugelio žmonių laikas, nes kiti, vietoje to, kad dalyvautų susitikimuose, kuriems galbūt tuo metu nėra įdomus, galbūt geriau jie kažką nudirbtų. Bet tam galima siųsti į tokius susitikimus tos srities atstovus. Sakykim, programuotojų „leadas“ eina arba „security leadas“ eina į tokius susitikimus ir jie kartu dalyvauja, o visi kiti žmonės gali užsiimti savo darbais. Tačiau „leadai“ grįžę iš susitikimo nuleidžia visą informaciją savo kolegoms.

Aš manau, pažiūrėti, kaip tikrai vyksta DevOps darbas, galima pažiūrėjus į atvejus, kai įvyksta kažkoks incidentas. Tada matai, kai programuotojai jau ateina pas „operations“, pas juos ateina duombazistai ir jie visi kartu sprendžia tą problemą. Tai va čia ir yra tas tikrasis DevOps „mindsetas“, kai visi susirenka į vieną vietą ir dirba ties vienu tikslu.

Yra sukviečiamas „squadas“ ir visi kartu sprendžia vieną problemą. Taip, labai tiksliai.

Dažnai pamirštamas faktorius, kad tame visame dalyke taip pat dalyvauja ir dar verslo atstovas – tas žmogus, kuris tą servisą, paslaugą parduoda galutiniams klientams.

Labai teisingai. Iš tikrųjų, vėlgi apie sprinto planavimą, nepamirškim „product ownerio“, o jis labai svarbus asmuo sprinto planavime ir tuo labiau sprinto „review“. Kažkodėl yra tokia nusistačius nuomonė, kad į sprinto „review“ visada „product owneris“ ateina, nes jam įdomu, ką mes iš per sprintą pasistatėm. Bet kai reikia planuoti, dažniausiai jo nėra. Bet tada jeigu jam neįdomu, ką mes per sprintą padarysim, kodėl jam įdomu, ką mes per sprintą padarėm? Jeigu jis net nežino, ką mes norėjom padaryti.

Kitaip sakant, jeigu pagrindinis užsakovas neateina pasakyti, ko jis nori, tuo atveju patys programuotojai sugalvoja, ko jie nori.

Tikrai taip. Ir jie turi ką sugalvoti, nes dažniausiai jie turi visą sąrašą „technical debt“ „itemų“, kurį norėtų išsispręsti, nori kažkokias patogumo funkcijas įgyvendinti. Galbūt tai nėra aktualu pačiam „product owneriui“, bet pačiam programuotojui tai palengvins darbą. Jie gali daug ką susigalvoti, bet kai sprinto gale parodys, ką jie pasidarė, „product owneris“ sakys: „Atsiprašau, bet aš to neprašiau“. Tai nėra ko kaltinti, nes pats nedalyvavai pradžioje.

Grįžtu prie DevOps. Ką mes sužinojom? Kad iš esmės DevOps tai nėra kažkokia plati pareigybė, nėra kažkokia išmokta specialybė, tai yra labiau praktika ar filosofija, galbūt galima taip sakyti, apie tai, kaip komanda turėtų veikti nuo pačios produkto gimimo pradžios programuotojų kompiuteriuose iki jo sudiegimo į serverius ar į debesiją ir toliau iki jo palaikymo. Visa tai, priešingai nei anksčiau būdavo įprasta, turėdavo atlikti atskiros komandos, kurios kartu labai retai bendraudavo. Dažniau bendraudavo tuomet, kai reikėdavo aiškintis kieno buvo klaida ar neapsižiūrėjimas. Šis požiūris siūlo visiems kartu dirbti vienoj komandoj, labai pageidautina vienoj erdvėj ofise, jeigu tai įmanoma, nes nuo to susikalbėjimas gerėja ir dėl to visi komandos nariai vienodai žino, kas šiuo metu vyksta, kur jie juda ir kokie poreikiai yra iš verslo. Ir, visgi grįžtant prie DevOps klausimo, toj komandoj vis tiek vienas žmogus, kuris yra, jį vis tiek visi vadins DevOps, rodys pirštais ir sakys: „Šita dalis, „continuous integration, continuous deployment“ yra tavo“. Ką turėtų mokytis arba norėt išmokti jaunas žmogus, kuris sakytų: „Aš įsivaizduoju, kad man patiktų dirbti DevOps‘u ir aš norėčiau komandoj šitą rolę atlikti? Ką jis turėtų žinoti, mokytis?

Galbūt reikėtų identifikuoti, kuri sritis jam labiausiai patinka. Ar tai yra „Cloud“ infrastruktūros statymas, nes tai tikrai yra DevOps procesų dalis. Beje, noriu pabrėžti, kad tai ne vien tik „cloudas“, nes kai diegi programinę įrangą į serverius, vadinamus lokalius „on prem“ serverius, tai irgi lygiai taip pat DevOps ten dalyvauja. Tas pats diegimas CI/CD („continuous integration / continuous delivery“) – galima šito mokintis. Galima infrastruktūrą mokintis. Galima testavimą mokintis. Galima saugumą mokintis. Kuri iš šių dalių tau yra įdomiausia, ją ir mokinkis. Tik visą laiką turėk omeny, kad kai išmoksi, atėjęs į kompaniją, stengtumeisi pats užkrėsti savo požiūriu į visus procesus ir dalyvavimu kartu susitikimuose. Tai turbūt tiek.

Jo, į komandą, aš manau, susirenka visi žmonės, kurie visi yra „T-shaped“ specialistai. Natūralu, kad į tą DevOps žmogų visi rodys pirštais, sakys, kad tai yra DevOps‘as, bet visa komanda vis tiek kažkiek žino iš to DevOps „stack‘o“. Visai nebūtina žinoti visko, bet svarbu žinoti kažkokią savo dalį, kur tu gali būti specialistas. Kalbant apie įrankius, beje, turiu klausimą kolegoms. Ar jūs žinote, kuo skiriasi sistemų administratorius, kuris žino visą DevOps technologijų seką, nuo DevOps inžinieriaus?

Kadangi ką tik šnekėjom, kad nėra tokio dalyko kaip DevOps inžinierius, tai tada ne, negaliu atsakyti.

Atlyginimu.

Tai iš tikrųjų atspindi tą dabartinį trendą, kad DevOps inžinieriai rinkoje labai pageidaujami ir iš tikrųjų, specifiniai jų įrankiai naudojami ir jų naudojamos metodikos labai stipriai pagreitina produkto įėjimą į rinką. Ir tas pats automatinis „continuous integration ir delivery“ reiškia, kad vieno mygtuko paspaudimu naujausią versiją galima išleisti į produkciją arba atgal „atrollbackinti“, jeigu kažkokia problema iškilo. Tai neabejotinai yra didelė nauda verslui.

Tikrai taip. Netgi yra toks posakis, kad jau nebe „rollbackina“, o „rollforward“ – visą laiką yra „forward“. Kad jeigu tu jau matai, kad tavo išleista dabartinė versija sugriuvo, tai tu leidi ant viršaus prieš tai buvusią versiją. Bet tu vis tiek leidi į priekį. Tokio dalyko kaip jau iš „backupo“ atstatinėjimas, „rollbackinimas“ jau vis mažėja. Mažiau tai daroma yra.

Bet kažkas turi tą dalyką pataisyti. Tai DevOps inžinieriaus darbas yra tada sužiūrėti arba surasti ir sutarti su tuo, kas tą dalyką gali pataisyti. Ne visada jis pats taisys tai, kas blogai suprogramuota.

Tai va, dėl ko ir sakau, kad praeitos versijos išleidimas į priekį, nes mes jau žinom, kad praeita versija tikrai veikia.

Ir žinom jos numerį, indeksą.

Taip. Va būtent. Ir leidi paeitą versiją, nes ji tikrai veikia.

Jau buvo minėta, kad DevOps tai nėra vien tiktai „cloudas“. O tai lygiai taip pat, kadangi tai yra metodologija ar filosofija, ji lygiai taip pat veikia ir „on-premise“ arba įmonės nuosavuose duomenų centruose laikomuose serveriuose. Ar yra kažkas, kas labai specifiškai skirtų „cloudinį“ DevOps nuo „on- premise“?

Įrankiai. Nes „on-prem“ dažniausiai dabar irgi jau, kad stovėtų ant grynai „barebones“ metalo, jau taip nebebūna. Dažniausiai tai būna virtualizacija ant „VMware“ ar kažkokio kito „hypervisoriaus“. Bet netgi tie „hypervisoriai“ dabar irgi palaiko automatizavimą per API ir per visa kita. Tiesiog automatizuoji tą įrankį ir viskas. Įrankiais tesiskiria.

Jeigu sudėlioti dabar tą grandinėlę teisingą, tai turbūt netgi grandinėlės nėra, tai viena komanda, kurioje yra ir programinės įrangos inžinieriai, ir „developeriai“, kaip mes juos vadiname, yra „operations“ ir kažkas atlieka tą DevOps rolę arba galbūt tam specialiai paskirtas žmogus. Bet tada ir kyla klausimas, jeigu DevOps automatizuoja pilną diegimą į visas aplinkas, programuotojai savo kodą laiko saugyklose, „GIT‘e“ arba kitur, tai turint visus šiuos automatinius procesus, kam tada reikalingi „operations“? Nes atrodo, jeigu yra problema, tai belieka atstatyti senesnę versiją ir toliau gyveni. Kam reikalingi žmonės, kurie jau tada prižiūri tą produktą?

„Operations“, vėlgi paminėsiu, yra DevOps dalis. Jie yra labai svarbūs, tiesą pasakius. Nes, kad ir kaip ten bebūtų, išleista programinė įranga vis tiek... Na, mes esam žmonės, programuotojai yra žmonės ir jie programuodami kažkokių klaidų padaro. Galų gale, įvyksta ir neprognozuojamų dalykų, net nuo žmonių nepriklausomų, kai dingsta tinklo įranga arba dar kažkas. Ir visa tai prižiūri „operations“. Jie padeda sureaguoti į tas bėdas pakankamai greitai ir jas išspręsti kiek įmanoma greičiau. Bet žinoma, kad jie reaguotų greitai į tas bėdas, jie turi turėti atitinkamus įrankius. Jie turi turėti „alertinimo“ sistemą implementuotą, jie turi turėti įrankius ir „scriptus“ parašytus, kurie gali būti parašyti, pvz., infrastruktūros „developerio“. Bet kadangi tas kodas jau yra ištestuotas, „operations“ lygiai taip pat gali tą kodą paleisti ir su jo pagalba atstatyti infrastruktūrą. Ir nebūtina žadinti vidury nakties ar savaitgalį tos infrastruktūros programuotojo. „Operations“ labai svarbi dalis lygiai taip pat.

Kalbant apie „operations“, reikia irgi paminėti taip vadinamą „site reliability“ inžineriją, kilusią iš „Google“. Tai būtent iš tikrųjų DevOps dalis, kur žmonės fokusuojasi būtent į tai, kad išlaikyti „operations“ visą veikiančią platformą. Ir turbūt nenuostabu, kodėl kilo iš „Google“, nes jie turi tam tikrų „challenges“ ir jie turi labai aukštus reikalavimus.

Dar galiu paminėti, būtent teko „Google“ SRE mokymuose dalyvauti ir man labai patiko, ką daro „operations“, kai jiems nėra darbo. Čia kabutėse, žinoma, nes niekados taip nebūna, kai jie turi laisvo laiko. Netgi yra pasamdyti atskiri žmonės, kurie visą dieną, visą savo darbo laiką skiria būtent skaičiuoti, kiek jie turi procentaliai laiko „downtime‘ui“. Vis tiek šimtu procentu „uptime‘o“ neįmanoma padaryti niekada. Reikia su tuo susitaikyti, dėl to reikia paskaičiuoti, kiek gali sau leisti turėti to „downtime‘o“. Ir yra netgi nustatytas vadinamas „downtime‘o“ biudžetas. Kai turi nusistatęs tą biudžetą, tu netgi vėl gali pradėti žaisti tokiu lygiu, kad išleidi tam tikrą neištestuotą programos versiją, kuri turi tam tikrų klaidų, bet tos klaidos turi išsitekti į tą biudžetą. Tai netgi iki tokio lygio jie skaičiuoja, kad mes turim kažkokį „downtime‘o“ biudžetą, pabandykim pagyventi drąsiai, išleiskim neištestuotą versiją. Ir jie tai naudoja. Bet tam sėdi pasamdyti atskiri SRE žmonės.

Beje, „Netflix“ irgi turi labai įdomų požiūrį į infrastruktūrą. Jie būtent tam reikalui turi taip vadinamą armiją monstrų, tai yra programos, „scriptai“, kurie bando griauti infrastruktūrą pastoviai. Ir jie turi skirtingas iki Kong. „Chaos monkey“ mažiausia, o dabar jie auga ir griauna visą šalių duomenų struktūrą. Tam, kad ištestuotų, kiek jie moka atsilaikyti ir išlaikyti tą „operational“ lygį. Tai jeigu DevOps žmogus kažkuriuo metu neturi ką veikti, jis visada gali paleisti tokį „scriptą“.

Ne, kiek aš žinau, jiems iš tikrųjų netgi nežinant, jis visą laiką veikia „backgrounde“ ir jie patys save testuoja ant kiek jie „resilient“ yra.

Na ką gi, ačiū labai kolegoms už apsilankymą podcaste. Tikimės, kad sugebėjom bent jau išsklaidyti keletą mitų ir atsakyti į tam tikrus klausimus, susijusius su DevOps. Labai tikimės, kad šitas podcastas jums patiko ir tikimės, kad tų podcastų mes galėsime suorganizuoti daugiau, įvairiomis temomis. Ačiū jums labai, kad apsilankėt.

Dėkui už pakvietimą.

Ačiū už pakvietimą.

Iki.

Viso gero!