Adminnist, DevOps-ist, lõputust segadusest ja DevOps'i transformatsioonist ettevõttes

Mida on vajalik IT-ettevõtte eduks 2019. aastal? Konverentsidel ja kohtumistel räägivad lektorid palju kõlavate ja mitte alati tavainimesele arusaadavate sõnadega. Laevade paigalduse aeg, mikroteenused, monoliidist loobumine, DevOps-i transformatsioon ja veel palju muud. Kui jätta kõrvale sõnasuus ja rääkida otse ja selgelt, siis kõik kokkuvõttes seondub lihtsa teesiga: looge kvaliteetne toode, samas looge seda oma meeskonna mugavusest lähtuvalt.

Viimane on muutunud kriitilise tähtsusega. Äri on lõpuks jõudnud arusaamale, et mugav arendusprotsess tõstab tootlikkust ning kui kõik on sujuvalt ja nagu kellad töötamas, annab see ka teatava mänguruumi kriitilistes olukordades. Kunagi selle mänguruumi nimel leiutas keegi tark inimene varukoopiad, kuid tööstus areneb edasi ja oleme jõudnud DevOps-insenerideni — inimesteni, kes muudavad arenduse ja välise infrastruktuuri koostööprotsessi millekski arusaadavaks ja mitte šamaanideks.

Kogu see jutt modulaarsetest lahendustest on ilus, kuid… On nii läinud, et osa administraatoreid on kiiresti DevOps-iks ristitud, kuid DevOps-inseneridelt nõutakse vähemalt telepaatia ja selgeltnägemise oskusi.

Enne kui räägime tänapäeva ainete infrastruktuuri tagamise probleemidest, määratlemegi, mida me selle terminiga silmas peame. Praeguseks on olukord kujunenud nii, et oleme jõudnud selle mõiste kahemõttelisusele: infrastruktuur võib olla tinglikult väline ja tinglikult sisemine.

Väline infrastruktuur hõlmab kõike, mis tagab teenuse või toote töökindluse, mille arendusega tegeleb meeskond. Need on rakenduse või veebisaidi serverid, hostimine ja muud teenused, mis tagavad toote töökindluse.

Sisemine infrastruktuur sisaldab teenuseid ja seadmeid, mida kasutab arendustiim ja muud töötajad, keda on tavaliselt samuti üsna palju. Need on sisemised koodihaldussüsteemide serverid, kohapeal paigaldatud ülesandehaldur ja kõik, mis eksisteerib ettevõtte intranetis.

Mille on süsteemiadministraatori ülesanne ettevõttes? Lisaks sellele, et ta haldab ettevõtte sisevõrku, on tihti tema õlul ka kontori seadmete töökindluse tagamine. Admin on see mees, kes tõmbab kiiresti laost välja uue arvuti või töövalmis varuloodud sülearvuti, annab välja uue klaviatuuri ja roomab kabinetides, et venitada Ethernet-kabelit. Admin on kohaliku võrgu isand ja valitseja mitte ainult sisemiste ja väliste süsteemide üle, serverid, vaid ka majandaja. Jah, mõned administraatorid võivad töötada ainult süsteemi tasandil, ilma riistvarata. Neid tasub eraldi kategoriseerida kui „infrastruktuuri süsteemiadministraatoreid“. Ja mõni teine spetsialiseerub ainuüksi kontori seadmete hooldamisele, õnneks, kui ettevõttes on üle saja inimese, ei lõpeta töö kunagi. Kuid ei need, ega teised ei ole DevOpsid.

Aga kes on DevOps? DevOpsid on kutid, kes teevad koostööd tarkvaraarenduse ja välise infrastruktuuri vahel. Täpsemalt, tänapäeva DevOpsid on kaasatud arendus- ja juurutamisprotsessidesse palju sügavamalt, kui kunagi varem olid administratorid, kes lihtsalt laadisid uuendusi ftp-le üles. Üks DevOps-inseneri peamisi ülesandeid on tagada mugav ja tõhus koostöö arendustiimide ja toote infrastruktuuri vahel. Just need inimesed vastutavad süsteemide juurutamise ja tagasivõtu protsesside eest, just need inimesed võtavad arendajatelt osa koormusest ja keskenduvad oma äärmiselt olulisele ülesandele. Samas DevOps ei hakka kunagi uusi kaableid vedama või jagama uusimat sülearvutit laost (c) K. O.

Mis siin on petmine?

Kui keegi küsib: „Aga kes on DevOps?”, siis pool selle ala töötajaid alustab midagi taolist: „Noh, see on selline admin, kes... ” ja edasi, nagu ikka. Jah, ammu, kui DevOps-inseneri amet alles huvitavate administratiivsete teenuste talendist välja kasvas, ei olnud nendevahelised erinevused kõikidele ilmsed. Kuid nüüd, kui DevOpsi ja administraatori rollid tiimis on radikaalselt erinevad, on neid omavahel segada või isegi võrdsustada – vastuvõetamatu.

Aga kuidas see ettevõtetele mõju avaldab?

Töölepingud, kõik on selles.

Avate kuulutuse „Süsteemiadministraator” ja seal on nõuded: „koostöö arendajate ja klientidega”, „CI/CD tarnesüsteem”, „ettevõtte serverite ja seadmete hooldus”, „sisemiste süsteemide haldamine” jne; mõistate, et tööandja räägib mingit jama. Probleem on selles, et kuulutuse pealkirjas peaks olema „DevOps-insener”, ja kui see pealkiri ära muuta, siis kõik langeb oma kohtadele.

Kuid milline mulje sellise kuulutuse lugemine jätab? Et ettevõte otsib universaalset töötajat, kes suudab luua nii versioonihaldussüsteemi kui ka jälgimisseadmestiku...

Ja tegelikult, et mitte suurendada narkomaansust tööturul, piisab, kui nimetada ametikohti nende tõeliste nimedega ja selgelt mõista, et DevOps-insener ja süsteemiadministraator on kaks erinevat olendit. Ainult mõnede tööandjate kirekas soov esitada kandidaatidele võimalikult laia nõudmiste loetelu viib selleni, et "klassikalised" süsteemiadministraatorid ei suuda enam aru saada, mis nende ümber toimub. Mis, amet on mutatsioonis ja nad on ajast maas?

Ei, ei ja veel kord ei. Infrastruktuuriadministraatorid, kes juhtivad ettevõtte siseseid servereid või töötavad L2/L3 toe positsioonidel ning aitavad teisi töötajaid, ei ole kuhugi kadunud ja ei kavatse minema järgida.

Kas need spetsialistid saavad DevOps-insenerideks? Loomulikult saavad. Tegelikult on see neile sugulane keskkond, mis nõuab süsteemiadministreerimise oskusi, kuid lisaks sellele tuleb tegeleda jälgimise, tarnesüsteemide ja üldiselt tiheda koostööga arendus- ja testimismeeskonnaga.

Veel üks DevOps-i probleem

Tegelikult ei piirduta kõik ainult palkamise ja pideva segadusega administraatorite ja devopside vahel. Ühel hetkel seisab ettevõte silmitsi uuenduste tarnimise ja arendusmeeskonna koostoime lõpp-infrastruktuuriga.

Võib-olla juhtus see siis, kui mõne konverentsi lavale astus onu, kelle silmad õitsesid, ja ütles: "Aga meie teeme nii ja nimetame seda DevOps-iks. Need kutid lahendavad kõik teie probleemid" – ja hakkas rääkima, kui hästi on ettevõttes pärast DevOps-praktikate rakendamist elada.

Kuid ei piisa DevOps-inseneri palkamisest, et kõik töötaks "nagu peab". Ettevõte peab täielikult läbi viima DevOps-i transformatsiooni, mis tähendab, et meie devopsi roll ja võimalused peavad olema selgelt arusaadavad ka arendus- ja toote testimismeeskonna poolt. Sellel teemal on meil "suurepärane" lugu, mis illustreerib täielikult kogu aset leidvat kohati jubedust.

Situatsioon. DevOpsilt nõutakse versioonide taastamissüsteemi juurutamist, ilma et oleks süvenetud, kuidas see töötab. Oletame, et Users süsteemis on eraldi väljad nime, perekonna nime ja parooli jaoks. Tuleb uus toote versioon, kuid arendajate jaoks tähendab "tagasikäik" lihtsalt võlukeppi, mis kõik korda teeb, ja nad ei kujuta ette, kuidas see töötab. Näiteks arendajad ühendasid järgmises plaastris nime ja perekonnanime väljad, panid selle tootmisse ja versioon seab mingil põhjusel piduri peale. Mis juhtub? Juhtkond läheb DevOps-i juurde ja ütleb: "Lülita välja!", s.t. palub tal naasta eelmise versiooni juurde. Mida teeb DevOps? Ta naaseb eelmise versiooni juurde, kuid kuna arendajad ei soovinud süveneda, kuidas see tagasikäik toimub, siis ei öeldud DevOps-ile, et tuleb tagasiviia ka andmebaas. Lõppkokkuvõttes kukub meil kõik kokku ja kasutajad näevad aeglase saidi asemel viga "500", sest vana versioon ei tööta uue andmebaasi väljadega. DevOps ei tea sellest. Arendajad vaikivad. Juhtkond hakkab närvi minema ja raha kaotama ning meenutab varukoopiaid, pakkudes tagasiviimist neist, et "midagi tööle hakkaks". Tulemuseks on, et kasutajad kaotavad kõik oma andmed mingiks ajaperioodiks.

Muidugi saab peksa DevOps, kes "ei teinud õiget tagasikäigu süsteemi", kuigi selles loos on süüdi arendajad, kedagi ei huvita.

Järeldus on lihtne: ilma korraliku lähenemiseta DevOpsile ei ole sellest palju kasu.
Peamine, mida meeles pidada: DevOps-insener ei ole nõid ja ilma kvaliteetsete suhtluste ja kahepoolse koostööta arendajatega ei saa ta oma ülesandeid täita. DevOps-e ei saa jätta üksinda oma "probleemide" juurde või anda käsklust "ärge sekkuge arendajatesse, nende asi on kodeerida", ja pärast lootma jääda, et kriitilisel hetkel töötab kõik nagu peab. Nii see ei toimi.

Sisuliselt on DevOps oskused, mis asuvad juhtimise ja tehnoloogia piiril. Samuti pole selgelt näha, et selles tehnoloogiate kokteilis peaks olema rohkem tehnoloogiat kui juhtimist. Kui soovite tõesti luua kiiremaid ja tõhusamaid arendamisprotsesse, peate usaldama oma DevOps-i. Ta teab vajalikke tööriistu, on rakendanud sarnaseid projekte ja teab, kuidas edasi liikuda. Aita tal, kuula tema nõuandeid, ära püüa teda isolatsiooni panna. Kui administraatorid saavad töötada iseseisvalt, siis DevOps'id on sellisel juhul kasulikud, nad ei saa teid aidata, kui te ei soovi seda abi vastu võtta.

Ja viimasena: lõpetage infrastruktuuriadministraatorite solvamine. Neil on oma, äärmiselt oluline tööala. Jah, administraator võib saada DevOps inseneriks, kuid see peaks toimuma inimese enda soovil, mitte sundimisega. Ja süsteemse administraatori soov jätta end süsteemi administraatoriks on täiesti normaalne — see on tema eraldi amet ja tema õigus. Kui aga on soov läbida professionaalne transformatsioon, tuleb kindlasti meeles pidada, et peab arendama mitte ainult tehnilisi oskusi, vaid ka juhtimisoskusi. Kõik need inimesed tuleb koos viia ja õpetada ühte keelt rääkima, tõenäoliselt peab seda tegema just teie kui juhina.

Allikas: habr.com