Administraatoritest, devopsidest, lõputust segadusest ja DevOps'i muutusest ettevõttes

Mida on vaja IT-ettevõtte eduks 2019. aastal? Konverentside ja kohtumiste lektorerid räägivad palju valju ja mitte alati tavainimestele arusaadavatest sõnadest. Võitlus deploy'imise aja pärast, mikroteenused, monoliidist loobumine, DevOps'i transformatsioon ja palju-palju muud. Kui jätta kõrvale sõnaline ilu ja rääkida otse, siis kõik kokkuvõttes tähendab vaid ühte: tehke kvaliteetset toodet, olles samas meeskonnaga mugavas olukorras.

Viimane on muutunud kriitiliselt oluliseks. Äri on lõpuks aru saanud, et mugav arendusprotsess tõstab tootlikkust, ja kui kõik on sujuv ja töötab nagu kellavärk, siis annab see ka teatud mänguruumi kriitilistes olukordades. Kunagi selle manöövriruumi nimel mõtles keegi nutikas inimene välja varukoopiad, kuid tööstus areneb edasi ja oleme jõudnud DevOps'i insenerideni — inimesteni, kes muudavad arenduse ja välise infraga suhtlemise protsessi mõistlikuks ning vaba šamaanlusest.

Kogu see jutt «moduli» kohta on ilus, aga... Tuli välja, et osa administraatoreid kutsuti järsku DevOps-iks, ja DevOps-inseneridelt hakati nõudma vähemalt telepaatia ja selgeltnägemise oskusi.

Enne kui räägime kaasaegsetest infrastruktuuri tagamise probleemidest, lepime kokku, mida me selle terminiga mõtleme. Praeguseks on olukord kujunenud nii, et oleme jõudnud selle mõiste kahekesisuse juurde: infrastruktuur võib olla tinglikult väline ja tinglikult sisemine.

Väline infrastruktuur hõlmab kõike, mis tagab teenuse või toote töökorrasoleku, mille arendamisega meeskond tegeleb. Need on rakenduse või saidi serverid, hõbustamise. ja muud teenused, mis tagavad toote töö.

Sisemine infrastruktuur sisaldab teenuseid ja seadmeid, mida kasutab arendustiim ning teised töötajad, keda tavaliselt on samuti palju. Need on sisemised koodihalduse serverid, kohalikult seadistatud ülesannete haldur ja kõik, mis eksisteerib ettevõtte intranetis.

Mida teeb süsteemiadministraator ettevõttes? Lisaks sellele, et ta haldab ettevõtte sisevõrku, lasub tihti tema õlul ka kontori seadmete töökorras hoidmine. Admin on see kutseis, kes toob sülearvuti või töövalmiduse saanud varuarvuti kiiresti tagatoast, jagab uue klaviatuuri ning roomab kontorites, viies võrgujuhtmeid. Admin on kohaliku süsteemi isand ja valitseja, mitte ainult sisemiste ja välimiste... serverite, vaid ka haldaja. Jah, mõned administraatorid võivad töötada ainult süsteemitasandil, ilma riistvara haldamiseta. Need tasub välja tuua eraldi alamklassina „infrastruktuuri süsteemiadministraatorid“. Keegi võib aga spetsialiseeruda ainult kontori seadmete hooldamisele; õnneks, kui ettevõttes on üle saja inimese, siis töö ei lõppe iial. Kuid ei need ega teised ei ole devopsid.

Kes on DevOps? DevOps'id on inimesed, kes tegelevad tarkvaraarenduse ja välistaristu koostoimega. Täpsemalt, kaasaegsed DevOps'id on sügavamalt kaasatud arendus- ja juurutamisprotsessidesse kui kunagi varem administraatorid, kes lihtsalt laadisid uuendusi ftp-le. Üks DevOps-inseneri peamisi ülesandeid on tagada sujuv ja tõhus koostöö arendustiimide ja toote infrastruktuuri vahel. Just need inimesed vastutavad tagasikerimise ja juurutamissüsteemide rakendamise eest, nad võtavad arendajatelt osa koormast ja keskenduvad oma äärmiselt olulisele ülesandele. Sellegipoolest ei hakka DevOps kunagi uut kaablit venima või uut sülearvutit varustusest välja andma. (c) KО

Milline on lõks?

Küsimusele "Aga kes see DevOps on?" hakkab pool valdkonna töötajatest vastama midagi sellist nagu "No, see on, noh, selline administraator, kes..." ja edasi juba tekstis. Jah, kunagi ammu, kui DevOps-inseneri amet alles-alles hargnes kõige andekamatest teenindamise administ, ei olnud erinevused nende vahel kõigile selged. Kuid nüüd, kui devopsi ja administraatori rollid meeskonnas on radikaalselt erinevad, on neid segi ajada või isegi nende vahel võrdsust märkida - vastuvõetamatu.

Aga millesse see äris lahtub?

Töölevõtt, kõik on selles.

Te avate „Süsteemi administraatori“ töötasu, ja seal on loetletud nõuded „koostöö arendajate ja tellijatega“, „CI/CD tarnesüsteem“, „ettevõtte serverite ja seadmete hooldus“, „sisemiste süsteemide haldamine“ ja nii edasi; te mõistate, et tööandja räägib mingit jama. Probleem on selles, et „Süsteemi administraatori“ pealkirja asemel peaks olema „DevOps-insener“, ja kui selle pealkirja ära vahetada, siis kõik läheb paika.

Kuid milline mulje jääb sellise töökuulutuse lugemisest? Et ettevõte otsib paljusid oskusi omavat inimest, kes suudab versioonihaldussüsteemi ja järelvalve seadistada ning kasutada ka suud…

Jah, et mitte suurendada tööturul segadust, piisab töökuulutuste nimetamisest õigete nimedega ja selge arusaamisest, et DevOps-insener ja süsteemiadministraator on kaks erinevat olendit. Kahjuks on aga mõned tööandjad liialdanud, esitades kandidaatidele võimalikult laia nõudmiste loetelu, mistõttu „klassikalised“ süsteemiadministraatorid ei saa enam aru, mis nende ümber toimub. Kas amet on mutatsioonis ja nad on elu käest lasknud?

Ei, ei ja veel kord ei. Infrastruktuuri administraatorid, kes juhivad ettevõtte sise-servereid või töötavad L2/L3 toe positsioonidel ja aitavad teisi töötajaid, ei ole kuskile kadunud ja ei kavatse ka kuhugi minna.

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

Veel üks DevOps-i probleem

Tegelikult ei piirduta kõik ainult värbamise ja pideva segadusega adminnide ja devopside vahel. Sel hetkel seisis äri silmitsi värskenduste tarnimise ja arendusmeeskonna koostööga lõpp-infrastruktuuriga.

Võib-olla juhtus see siis, kui ühe konverentsi lavale astus onu särava pilguga ja ütles: "Me teeme seda nii ja kutsume seda DevOps-iks. Need tüübid lahendavad kõik teie probleemid" — ja hakkas rääkima, kuidas on ettevõttes pärast DevOps-praktikate rakendamist hästi elada.

Kuid DevOps-inseneri palkimine ei ole piisav, et kõik hakkaks „nagu peab” töötama. Ettevõte peab läbima DevOps-i transformatsiooni, mis tähendab, et meie DevOps-i roll ja võimalused peavad olema selgelt mõistetavad ka toote arendamise ja testimise meeskonna poolel. Selle kohta on meil „hämmastav” lugu, mis illustreerib täielikult kogu aset leidvat kohati kaost.

Olukord. DevOpsilt nõutakse, et nad käivitaksid versioonide tagasivõtmise süsteemi, süvenemata sellele, kuidas see töötab. Eeldame, et Users-süsteemis on eraldi väljad nime, perekonnanime ja parooli jaoks. Tuleb uus tooteversioon, kuid arendajate jaoks on 'tagasivõtmine' lihtsalt imetegu, mis kõik korda teeb, ja nad ei oska isegi ette kujutada, kuidas see töötab. Näiteks arendajad ühendasid ühe viimase patchiga nime- ja perekonnanime väljad, viisid selle tootmisse, ning versioon hakkab mingil põhjusel aeglustuma. Mis juhtub? Juhtkond läheb DevOps'i juurde ja ütleb: "Lülita välja!", paludes tal tagasi naasta eelnevale versioonile. Mida teeb DevOps? Ta tagastab eelmise versiooni, kuid kuna arendajad ei soovinud välja selgitada, kuidas see tagasivõtmine toimub, ei öelnud keegi DevOps'ile, et tuleb tagasivõtte teha ka andmebaasist. Tulemuseks on see, et kõik kukub kokku ja kasutajad näevad aeglustava saidi asemel viga "500", kuna vana versioon ei tööta uue andmebaasi väljadega. DevOps pole sellest teadlik. Arendajad vaikivad. Juhtkond hakkab närvi minema ja raha kaotama, meenutades varukoopiaid, pakkudes, et nad tagasivõtaksid neist, et "või midagi siiski töötaks". Tulemuseks on see, et kasutajad kaotavad kõik oma andmed mingis ajavahemikus.

Selg on lihtne: DevOpsi jaoks on oluline lähenemine, vastasel juhul pole sellest suurt kasu.

Peamine, mida tuleb meeles pidada: DevOps-insener ei ole maag, ja ilma kvaliteetsete suhtlemisoskuste ja kahepoolse koostööta arendustega ei saa ta oma ülesannete täitmisega hakkama. DevOps insenerid ei saa jääda üksi oma „probleemidega“ või neile öelda „ära sekku arendajate töösse, nende asi on koodida“ ja loota, et kriitilisel hetkel kõik töötab nagu peab. Nii see ei toimi.
Mõistkem, DevOps insener ei ole imetegija, ja ilma head koostööd arendajatega ei suuda ta oma ülesandeid täita. DevOps-i ei saa üksi jätta oma ‘muredest’ või öelda, et ‘ärge sekkuge arendusse, las nad koodivad’, ja siis loota, et kõik sujub kriitilisel hetkel.

Tegelikult on DevOps oskused, mis asuvad juhtimise ja tehnoloogia piiril. Tähelepanuväärne on, et selles tehnoloogiate kokteilis ei pea juhtimist olema rohkem kui tehnoloogiat. Kui soovite tõepoolest luua kiirem ja tõhusam arenduse protsess, peate usaldama oma DevOps-i. Ta tunneb õigeid tööriistu, on selliseid projekte ellu viinud ja teab, kuidas asju teha. Aidake teda, kuulake tema nõuandeid, ärge pange teda isoleeritud autonoomsesse osakonda. Kui administraatorid saavad töötada iseseisvalt, siis DevOps-id on sel juhul kasutu, nad ei saa teid aidata, et paremaks saada, kui te ei soovi seda abi vastu võtta.

Ja viimane asi: lõpetage infrastruktuurihaldurite solvamine. Neil on oma, äärmiselt oluline töövaldkond. Jah, administreerija võib saada DevOps-inseneriks, kuid see peaks juhtuma inimesest endast lähtudes, mitte sundida. Ja ei ole midagi halba selles, et süsteemihaldur soovib jääda süsteemihalduriks — see on tema eriala ja tema õigus. Kui aga on soov läbida ametialane transformatsioon, siis ei tohi mingil juhul unustada, et tuleb arendada mitte ainult tehnilisi oskusi, vaid ka juhtimisoskusi. Kõik need inimesed tuleb kokku viia ja õpetada, et nad räägiksid ühte keelt, ja selleks peate olema just teie juht.

Allikas: habr.com