Wat duorret it foar in IT-bedriuw om suksesfol te wêzen yn 2019? Docenten op konferinsjes en meetups sizze in soad lûde wurden dy't net altyd fersteanber binne foar normale minsken. De striid foar ynsettiid, mikrotsjinsten, it ferlitten fan 'e monolit, DevOps-transformaasje en folle, folle mear. As wy ferbale skientme fersmite en direkt en yn it Russysk prate, dan komt it allegear del op in ienfâldige proefskrift: meitsje in heechweardich produkt, en doch it mei treast foar it team.
Dat lêste is kritysk wichtich wurden. Bedriuw is úteinlik kommen ta de konklúzje dat in noflik ûntwikkeling proses fergruttet de produktiviteit, en as alles wurdt debuggen en wurket as in klok, it jout ek wat romte foar manoeuvre yn krityske situaasjes. Eartiids, om 'e wille fan dizze manoeuvre, kaam in bepaalde tûke persoan mei backups, mar de yndustry is ûntwikkele, en wy kamen by DevOps-yngenieurs - minsken dy't it proses fan ynteraksje tusken ûntwikkeling en eksterne ynfrastruktuer feroarje yn wat adekwaat en net relatearre oan sjamanisme.
Dit hiele "modulêre" ferhaal is prachtich, mar ... It barde sa dat guon fan 'e admins abrupt DevOps waarden neamd, en DevOps-yngenieurs sels begûnen te wêzen ferplichte om op syn minst de feardichheden fan telepathy en heldervoyânsje te hawwen.
Foardat wy prate oer moderne problemen fan it leverjen fan ynfrastruktuer, litte wy definiearje wat wy bedoele mei dizze term. Op it hjoeddeiske momint is de situaasje sa ûntwikkele dat wy de dualiteit fan dit konsept berikt hawwe: ynfrastruktuer kin betingst ekstern en betingst yntern wêze.
Mei eksterne ynfrastruktuer bedoele wy alles dat soarget foar de funksjonaliteit fan 'e tsjinst of produkt dat it team ûntwikkelet. Dit binne applikaasje- of websideservers, hosting en oare tsjinsten dy't de funksjonaliteit fan it produkt garandearje.
De ynterne ynfrastruktuer omfettet tsjinsten en apparatuer dy't brûkt wurde troch it ûntwikkelteam sels en oare meiwurkers, wêrfan d'r meastentiids in protte binne. Dit binne ynterne servers fan koade-opslachsystemen, in lokaal ynsette taakbehearder en alles, alles, alles wat bestiet binnen it bedriuwsintranet.
Wat docht in systeembehearder yn in bedriuw? Neist it wurk fan it administrearjen fan dit tige bedriuwsintranet, draacht it faaks de lêst fan ekonomyske soargen om de wurkberens fan kantoarapparatuer te garandearjen. De admin is deselde man dy't fluch in nije systeemienheid of in reservelaptop klear foar gebrûk út 'e efterkeamer sil slepe, in nij toetseboerd útjaan en op alle fjouweren troch de kantoaren krûpe, de Ethernet-kabel útrekkenje. In behearder is in lokale eigner en hearsker fan net allinich ynterne en eksterne servers, mar ek in bedriuwsfierder. Ja, guon behearders kinne allinnich wurkje yn it systeem fleantúch, sûnder hardware. Se moatte wurde skieden yn in aparte subklasse fan "ynfrastruktuersysteembehearders." En guon binne spesjalisearre yn it betsjinjen fan allinich kantoarapparatuer; gelokkich, as it bedriuw mear as hûndert minsken hat, einiget it wurk noait. Mar gjin fan beide binne devops.
Wa binne DevOps? Devops binne jonges dy't prate oer de ynteraksje fan softwareûntwikkeling mei eksterne ynfrastruktuer. Mear krekter binne moderne devops belutsen by de ûntwikkeling en ynsetprosessen folle djipper dan admins dy't gewoan updates uploaden nei ftp wiene ea belutsen. Ien fan 'e wichtichste taken fan in DevOps-yngenieur is no om in noflik en effektyf strukturearre proses fan ynteraksje tusken ûntwikkelingsteams en produktynfrastruktuer te garandearjen. It binne dizze minsken dy't ferantwurdlik binne foar it ynsetten fan rollback- en ynsetsystemen; it binne dizze minsken dy't wat fan 'e lêst fan ûntwikkelders nimme en har safolle mooglik konsintrearje op har ekstreem wichtige taak. Tagelyk sil devops noait in nije kabel útfiere of in nije laptop út 'e efterkeamer útjaan (c) KO
Wat is it fangen?
Op de fraach "Wa is DevOps?" de helte fan de arbeiders op it fjild begjint soksawat te beantwurdzjen as "No, koartsein, dit is de admin dy't ..." en fierder yn 'e tekst. Ja, eartiids, doe't it berop fan DevOps-yngenieur krekt ûntstie út 'e meast talintfolle behearders yn termen fan ûnderhâld fan tsjinsten, wiene de ferskillen tusken har net foar elkenien dúdlik. Mar no, doe't de funksjes fan devops en admin yn it team radikaal oars wurden binne, is it ûnakseptabel om se mei elkoar te betize, of sels te fergelykjen.
Mar wat betsjut dit foar bedriuw?
Ynhieren, it giet der om.
Jo iepenje in fakatuere foar "Systeembehearder", en de easken dy't dêr binne neamd binne "ynteraksje mei ûntwikkeling en klanten", "CI / CD-leveringssysteem", "ûnderhâld fan 'e tsjinners en apparatuer fan it bedriuw", "bestjoer fan ynterne systemen" en sa op; jo begripe dat de wurkjouwer ûnsin praat. It fangen is dat ynstee fan "Systeembehearder" de fakatueretitel "DevOps Engineer" moat wêze, en as dizze titel feroare wurdt, dan falt alles op syn plak.
Hokker yndruk krijt men lykwols by it lêzen fan sa'n fakatuere? Dat it bedriuw op syk is nei in mearmasine-operator dy't sawol in ferzjekontrôle as in monitoaringsysteem ynsette sil en de twister mei de tosken knipt...
Mar om de mjitte fan drugsferslaving op 'e arbeidsmerk net te fergrutsjen, is it genôch om fakatueres op har eigen namme te neamen en dúdlik te begripen dat in DevOps-yngenieur en in systeembehearder twa ferskillende entiteiten binne. Mar de unrepressible winsk fan guon wurkjouwers te presintearjen de breedste mooglike list fan easken oan in kandidaat liedt ta it feit dat "klassike" systeem behearders ophâlde te begripen wat der bart om harren hinne. Wat, it berop mutearret en se binne efter de tiden?
Nee nee en noch ien kear nee. Ynfrastruktuerbehearders dy't de ynterne tsjinners fan it bedriuw sille beheare, of L2 / L3-stipeposysjes sille besette en oare meiwurkers helpe, binne net fuortgien en sille net fuortgean.
Kinne dizze spesjalisten DevOps-yngenieurs wurde? Fansels kinne se. Yn feite, dit is in besibbe omjouwing dy't fereasket systeem administraasje feardichheden, mar neist dit, wurkje mei monitoring, levering systemen en, yn it algemien, nauwe ynteraksje mei de ûntwikkeling en test team wurdt tafoege.
In oar DevOps-probleem
Yn feite is alles net beheind ta gewoan ynhieren en konstante betizing tusken admins en devops. Op in stuit waard it bedriuw konfrontearre mei it probleem fan it leverjen fan updates en ynteraksje fan it ûntwikkelteam mei de definitive ynfrastruktuer.
Miskien wie it doe't in omke mei fonkeljende eagen op it poadium fan in konferinsje stie en sei: "Wy dogge dit en neame it DevOps. Dizze jonges sille al jo problemen oplosse" - en begon te fertellen hoe goed it libben yn it bedriuw is nei it ymplementearjen fan DevOps-praktiken.
It is lykwols net genôch om in DevOps-yngenieur te hieren om alles te meitsjen sa't it moat wurkje. It bedriuw moat in folsleine DevOps-transformaasje ûndergean, dat is, de rol en mooglikheden fan ús DevOps moatte ek dúdlik wurde begrepen oan 'e kant fan it produktûntwikkelings- en testteam. Wy hawwe in "prachtige" ferhaal oer dit ûnderwerp dat folslein yllustrearret alle brutaliteit dy't bart op guon plakken.
Sitewaasje. DevOps is ferplichte om in ferzje rollback-systeem yn te setten sûnder echt te ferdjipjen yn hoe't it sil wurkje. Litte wy oannimme dat binnen it brûkerssysteem d'r aparte fjilden binne foar foarnamme, efternamme en wachtwurd. In nije ferzje fan it produkt komt út, mar foar ûntwikkelders is in "rollback" gewoan in toverstok dat alles sil reparearje, en se witte net iens hoe't it wurket. Sa, bygelyks, yn 'e folgjende patch kombinearren de ûntwikkelders de foar- en efternammefjilden, rôle it út yn produksje, mar de ferzje is om ien of oare reden stadich. Wat bart der? Management komt te devops en seit "Pull the switch!", dat wol sizze, freget him te rôlje werom nei de foarige ferzje. Wat docht devops? It rôlet werom nei de foarige ferzje, mar om't de ûntwikkelders net útfine woene hoe't dizze rollback dien wie, fertelde gjinien it devops-team dat de databank ek weromdraaid wurde moast. As gefolch, alles crashes foar ús, en ynstee fan in trage webside, brûkers sjogge in "500" flater, omdat de âlde ferzje net wurket mei de fjilden fan de nije databank. Devops wit hjir net fan. De ûntwikkelders binne stil. It management begjint har senuwen en jild te ferliezen en ûnthâldt de backups, en biedt oan om fan har werom te rollen, sadat "teminsten wat sil wurkje." As gefolch ferlieze brûkers al har gegevens oer in perioade fan tiid.
De nuten geane fansels nei devops, dy't "gjin juste rollback-systeem makken", en gjinien makket it út dat de moosen yn dit ferhaal ûntwikkelders binne.
De konklúzje is ienfâldich: sûnder in normale oanpak fan DevOps as sadanich is it fan lyts nut.
It wichtichste ding om te ûnthâlden: in DevOps-yngenieur is gjin tsjoender, en sûnder kwaliteitskommunikaasje en twa-wei ynteraksje mei ûntwikkeling sil hy syn taken net omgean. Devs kinne net allinnich wurde litten mei harren "problemen" of jûn it kommando "net bemuoie mei de ûntwikkelders, harren taak is te koade," en dan hoopje dat op in kritysk momint alles sil wurkje sa't it moat. Sa wurket it net.
Yn essinsje is DevOps in kompetinsje op 'e grins tusken behear en technology. Boppedat is it lang net foar de hân dat der mear technology as behear yn dizze cocktail sitte moat. As jo wirklik rapper en effisjinter ûntwikkelingsprosessen wolle bouwe, moatte jo jo devops-team fertrouwe. Hy wit it goede ark, hy hat ferlykbere projekten útfierd, hy wit hoe't it moat. Help him, harkje nei syn advys, besykje him net te isolearjen yn in soarte fan autonome ienheid. As admins op har eigen kinne wurkje, dan binne devops yn dit gefal nutteloos; se kinne jo net helpe om better te wurden as jo sels dizze help net akseptearje wolle.
En ien lêste ding: stopje mei misledigjende ynfrastruktuerbehearders. Se hawwe har eigen, ekstreem wichtige front fan wurk. Ja, in behearder kin in DevOps-yngenieur wurde, mar dit moat barre op fersyk fan de persoan sels, en net ûnder druk. En der is neat mis mei it feit dat in systeembehearder in systeembehearder bliuwe wol - dat is syn aparte berop en syn rjocht. As jo in profesjonele transformaasje wolle ûndergean, dan moatte jo noait ferjitte dat jo net allinich technologyske feardigens moatte opbouwe, mar ek managementfeardigens. Meast wierskynlik sil it oan jo as lieder wêze om al dizze minsken byinoar te bringen en te learen om yn deselde taal te kommunisearjen.
Boarne: www.habr.com