Mida on vaja selleks, et IT-ettevõte oleks 2019. aastal edukas? Konverentsidel ja kohtumistel räägivad lektorid palju valjuid sõnu, mis tavainimestele alati arusaadavad ei ole. Võitlus juurutamisaja, mikroteenuste, monoliidist loobumise, DevOpsi teisenduse ja palju-palju muu pärast. Kui jätta kõrvale sõnaline ilu ja rääkida otse ja vene keeles, siis taandub kõik lihtsale teesile: tehke kvaliteetne toode ja tehke seda meeskonna jaoks mugavalt.
Viimane on muutunud kriitilise tähtsusega. Äri on lõpuks jõudnud järeldusele, et mugav arendusprotsess tõstab tootlikkust ning kui kõik on silutud ja töötab nagu kell, annab see kriitilistes olukordades ka natukene manööverdamisruumi. Kunagi mõtles üks tark inimene selle manöövri huvides välja varukoopiad, aga tööstus areneb ja jõudsime DevOpsi inseneride juurde – inimesteni, kes muudavad arenduse ja välise infrastruktuuri vahelise suhtluse millekski adekvaatseks ja sobivaks. pole šamanismiga seotud.
Kogu see “moodulite” lugu on imeline, aga... Juhtus nii, et osad adminnid nimetati järsult DevOpsiks ning DevOpsi inseneridelt hakati nõudma vähemalt telepaatia ja selgeltnägemise oskust.
Enne kui räägime infrastruktuuri pakkumise tänapäevastest probleemidest, defineerime, mida me selle mõiste all mõtleme. Praegusel hetkel on olukord kujunenud nii, et oleme jõudnud selle mõiste duaalsuseni: infrastruktuur võib olla tinglikult väline ja tinglikult sisemine.
Välise infrastruktuuri all peame silmas kõike, mis tagab meeskonna arendatava teenuse või toote funktsionaalsuse. Need on rakendus- või veebisaidiserverid, hostimine ja muud teenused, mis tagavad toote funktsionaalsuse.
Sisemine taristu hõlmab teenuseid ja seadmeid, mida kasutavad arendusmeeskond ise ja teised töötajad, keda on tavaliselt palju. Need on koodisalvestussüsteemide siseserverid, kohapeal juurutatud tegumihaldur ja kõik, kõik, kõik, mis ettevõtte sisevõrgus olemas on.
Mida teeb süsteemiadministraator ettevõttes? Lisaks just selle ettevõtte siseveebi haldustööle kannab see sageli ka majanduslikke muresid kontoriseadmete töökindluse tagamisel. Administraator on seesama mees, kes veab kiirelt majapidamisruumist uue süsteemiploki või kasutusvalmis tagavara sülearvuti, annab välja värske klaviatuuri ja roomab neljakäpukil läbi kontorite Etherneti kaablit venitades. Administraator on mitte ainult sisemiste ja väliste serverite kohalik omanik ja valitseja, vaid ka ettevõtte juht. Jah, mõned administraatorid saavad töötada ainult süsteemitasandil, ilma riistvarata. Need tuleks eraldada eraldi alamklassiks "infrastruktuuri süsteemiadministraatorid". Ja mõned on spetsialiseerunud ainult kontoriseadmete teenindamisele, õnneks ei lõpe töö kunagi, kui ettevõttes on üle saja inimese. Kuid kumbki neist pole devops.
Kes on DevOps? Devopid on poisid, kes räägivad tarkvaraarenduse koostoimest välise infrastruktuuriga. Täpsemalt, kaasaegsed devopid on arendus- ja juurutamisprotsessidega seotud palju sügavamalt kui administraatorid, kes lihtsalt laadisid värskendusi ftp-sse. DevOpsi inseneri üks peamisi ülesandeid on praegu tagada arendusmeeskondade ja toote infrastruktuuri vaheline mugav ja tõhusalt struktureeritud suhtlusprotsess. Just need inimesed vastutavad tagasipööramis- ja juurutamissüsteemide juurutamise eest; just need inimesed võtavad osa arendajatelt maha ja keskenduvad nii palju kui võimalik oma äärmiselt olulisele ülesandele. Samal ajal ei hakka devops kunagi uut kaablit vedama ega tagatoast uut sülearvutit välja andma (c) KO
Mis on saak?
Küsimusele "Kes on DevOps?" pooled valdkonna töötajad hakkavad vastama umbes nii: "Noh, lühidalt, see on admin, kes ..." ja edasi tekstis. Jah, kunagi ammu, kui DevOpsi inseneri elukutse oli alles välja kujunemas kõige andekamate administraatorite seast teeninduse hoolduse osas, ei olnud nendevahelised erinevused kõigile ilmsed. Kuid nüüd, kui devopide ja administraatori funktsioonid meeskonnas on muutunud kardinaalselt erinevaks, on lubamatu neid omavahel segamini ajada või isegi võrdsustada.
Aga mida see äri jaoks tähendab?
Tööle võtmine, kõik käib asja juurde.
Avate vaba töökoha “Süsteemiadministraator” ja seal loetletud nõuded on “suhtlus arenduse ja klientidega”, “CI/CD kohaletoimetamise süsteem”, “ettevõtte serverite ja seadmete hooldus”, “sisesüsteemide administreerimine” jne. peal; saate aru, et tööandja ajab lolli juttu. Konks on selles, et “Süsteemiadministraatori” asemel peaks vaba ametinimetus olema “DevOps Engineer” ja kui seda tiitlit muuta, siis loksub kõik paika.
Mis mulje jääb aga sellist vaba kohta lugedes? Et ettevõte otsib mitme masina operaatorit, kes võtab kasutusele nii versioonikontrolli kui ka monitooringusüsteemi ning pigistab hammastega twister...
Kuid selleks, et mitte suurendada tööturul uimastisõltuvuse taset, piisab, kui nimetada vabu töökohti õigete nimedega ja mõista selgelt, et DevOpsi insener ja süsteemiadministraator on kaks erinevat üksust. Kuid mõne tööandja pidurdamatu soov esitada kandidaadile võimalikult lai nõuete loetelu viib selleni, et "klassikalised" süsteemiadministraatorid lakkavad mõistmast, mis nende ümber toimub. Mis, amet muteerub ja nad on ajast maha jäänud?
Ei ei ja veel kord ei. Infrastruktuuriadministraatorid, kes hakkavad haldama ettevõtte siseservereid või hõivama L2/L3 tugipositsioone ja abistavad teisi töötajaid, ei ole kuhugi kadunud ega kao.
Kas neist spetsialistidest saavad DevOpsi insenerid? Muidugi saavad. Tegelikult on tegemist seotud keskkonnaga, mis eeldab süsteemihaldusoskusi, kuid lisaks sellele lisandub töö monitooringu, tarnesüsteemidega ning üleüldiselt tihe suhtlus arendus- ja testimismeeskonnaga.
Veel üks DevOpsi probleem
Tegelikult ei piirdu kõik ainult palkamise ja pideva segamisega administraatorite ja devopide vahel. Mingil hetkel seisis ettevõte silmitsi värskenduste tarnimise ja arendusmeeskonna suhtlemise probleemiga lõpliku infrastruktuuriga.
Võib-olla oli see siis, kui säravate silmadega onu tõusis mõne konverentsi laval püsti ja ütles: „Me teeme seda ja kutsume seda DevOpsiks. Need poisid lahendavad kõik teie probleemid” - ja hakkasid pärast DevOpsi tavade rakendamist rääkima, kui hea elu ettevõttes on.
Siiski ei piisa DevOpsi inseneri palkamisest, et kõik toimiks nii nagu peab. Ettevõte peab läbima täieliku DevOpsi ümberkujundamise, st meie DevOpsi roll ja võimalused peavad olema ka tootearenduse ja testimise meeskonna poolt selgelt mõistetavad. Meil on sellel teemal "imeline" lugu, mis illustreerib täielikult kogu jõhkrust, mis mõnes kohas toimub.
Olukord. DevOps peab juurutama versiooni tagasipööramise süsteemi, ilma et oleks vaja selle toimimist põhjalikult uurida. Oletame, et Kasutajate süsteemis on eesnime, perekonnanime ja parooli jaoks eraldi väljad. Välja tuleb toote uus versioon, kuid arendajate jaoks on "tagasivõtmine" lihtsalt võlukepp, mis parandab kõik, ja nad isegi ei tea, kuidas see töötab. Nii näiteks ühendasid arendajad järgmises paigas ees- ja perekonnanime väljad, rullisid selle tootmisse, kuid versioon on millegipärast aeglane. Mis toimub? Juhtkond tuleb devopsi juurde ja ütleb "Pull the switch!", See tähendab, palub tal naasta eelmisele versioonile. Mida devops teeb? See pöördub tagasi eelmisele versioonile, kuid kuna arendajad ei tahtnud aru saada, kuidas see tagasipööramine tehti, ei öelnud keegi devopsi meeskonnale, et andmebaasi tuleb ka tagasi keerata. Selle tulemusena jookseb meil kõik kokku ning aeglase veebilehe asemel näevad kasutajad “500” viga, kuna vana versioon ei tööta uue andmebaasi väljadega. Devops ei tea sellest. Arendajad vaikivad. Juhtkond hakkab närvid ja raha kaotama ning jätab varukoopiad meelde, pakkudes nende käest tagasi pöördumist, et "vähemalt midagi õnnestuks". Selle tulemusena kaotavad kasutajad teatud aja jooksul kõik oma andmed.
Pähklid lähevad muidugi devopsile, mis "ei teinud korralikku tagasipööramissüsteemi" ja kedagi ei huvita, et selle loo põder on arendajad.
Järeldus on lihtne: ilma tavalise lähenemiseta DevOpsile kui sellisele on sellest vähe kasu.
Peaasi, mida meeles pidada: DevOpsi insener ei ole mustkunstnik ja ilma kvaliteetse suhtluseta ja arendusega kahepoolse suhtlemiseta ei tule ta oma ülesannetega toime. Arendajaid ei saa jätta oma "probleemidega" üksi ega anda käsku "ära sega arendajatega, nende töö on kodeerida" ja siis loota, et kriitilisel hetkel töötab kõik nii, nagu peab. Nii see ei tööta.
Põhimõtteliselt on DevOps pädevus juhtimise ja tehnoloogia piiril. Pealegi pole kaugeltki ilmne, et selles kokteilis peaks olema rohkem tehnoloogiat kui juhtimist. Kui soovite tõesti luua kiiremaid ja tõhusamaid arendusprotsesse, peate usaldama oma devopsi meeskonda. Ta tunneb õigeid tööriistu, on sarnaseid projekte ellu viinud, teab, kuidas seda teha. Aidake teda, kuulake tema nõuandeid, ärge püüdke teda isoleerida mingisse autonoomsesse üksusesse. Kui administraatorid saavad iseseisvalt töötada, on devopid sel juhul kasutud; nad ei saa aidata teil paremaks saada, kui te ise seda abi vastu võtta ei taha.
Ja viimane asi: lõpetage infrastruktuurihaldurite solvamine. Neil on oma, äärmiselt oluline töörinne. Jah, administraatorist võib saada DevOpsi insener, kuid see peaks juhtuma inimese enda soovil, mitte surve all. Ja selles, et süsteemiadministraator tahab jääda süsteemiadministraatoriks, pole midagi halba – see on tema omaette elukutse ja tema õigus. Kui soovite läbida professionaalset ümberkujundamist, siis ei tohi kunagi unustada, et lisaks tehnoloogilistele oskustele peate arendama ka juhtimisoskusi. Tõenäoliselt on teie kui juhi enda teha kõik need inimesed kokku tuua ja õpetada neid samas keeles suhtlema.
Allikas: www.habr.com