Wat neem dit vir 'n IT-maatskappy om suksesvol te wees in 2019? Dosente by konferensies en ontmoetings sê baie harde woorde wat nie altyd vir normale mense verstaanbaar is nie. Die stryd om ontplooiingstyd, mikrodienste, die verlating van die monoliet, DevOps-transformasie en nog baie, baie meer. As ons verbale skoonheid weggooi en direk en in Russies praat, dan kom dit alles neer op 'n eenvoudige tesis: maak 'n produk van hoë gehalte en doen dit met gemak vir die span.
Laasgenoemde het krities belangrik geword. Besigheid het uiteindelik tot die gevolgtrekking gekom dat 'n gemaklike ontwikkelingsproses produktiwiteit verhoog, en as alles ontfout is en soos 'n horlosie werk, gee dit ook 'n mate van beweegruimte in kritieke situasies. Eens op 'n tyd, ter wille van hierdie maneuver, het 'n sekere slim persoon met rugsteun vorendag gekom, maar die bedryf is besig om te ontwikkel, en ons het na DevOps-ingenieurs gekom - mense wat die proses van interaksie tussen ontwikkeling en eksterne infrastruktuur omskep in iets voldoende en nie verband hou met sjamanisme nie.
Hierdie hele "modulêre" storie is wonderlik, maar... Dit het so gebeur dat sommige van die admins skielik DevOps gedoop is, en daar begin van DevOps-ingenieurs self verwag word om ten minste die vaardighede van telepatie en heldersiendheid te hê.
Voordat ons praat oor moderne probleme met die verskaffing van infrastruktuur, laat ons definieer wat ons met hierdie term bedoel. Op die huidige oomblik het die situasie so ontwikkel dat ons die dualiteit van hierdie konsep bereik het: infrastruktuur kan voorwaardelik ekstern en voorwaardelik intern wees.
Met eksterne infrastruktuur bedoel ons alles wat die funksionaliteit verseker van die diens of produk wat die span ontwikkel. Dit is toepassings- of webwerfbedieners, hosting en ander dienste wat die funksionaliteit van die produk verseker.
Die interne infrastruktuur sluit dienste en toerusting in wat deur die ontwikkelingspan self en ander werknemers, van wie daar gewoonlik baie is, gebruik word. Dit is interne bedieners van kodebergingstelsels, 'n plaaslik ontplooide taakbestuurder en alles, alles, alles wat binne die korporatiewe intranet bestaan.
Wat doen 'n stelseladministrateur in 'n maatskappy? Benewens die werk om hierdie einste korporatiewe intranet te administreer, dra dit dikwels die las van ekonomiese bekommernisse om die werkbaarheid van kantoortoerusting te verseker. Die admin is dieselfde ou wat vinnig 'n nuwe stelsel-eenheid of 'n spaarskootrekenaar gereed vir gebruik uit die agterkamer sal sleep, 'n vars sleutelbord sal uitdeel en hande-viervoet deur die kantore kruip en die Ethernet-kabel rek. 'n Administrateur is 'n plaaslike eienaar en heerser van nie net interne en eksterne bedieners nie, maar ook 'n sakebestuurder. Ja, sommige administrateurs kan net in die stelselvlak werk, sonder hardeware. Hulle moet geskei word in 'n aparte subklas van "infrastruktuurstelseladministrateurs." En sommige spesialiseer in die diens van uitsluitlik kantoortoerusting; gelukkig, as die maatskappy meer as honderd mense het, eindig die werk nooit. Maar nie een van hulle is devops nie.
Wie is DevOps? Devops is ouens wat praat oor die interaksie van sagteware-ontwikkeling met eksterne infrastruktuur. Meer presies, moderne devops is betrokke by die ontwikkeling en ontplooiingsprosesse baie dieper as wat admins wat bloot opdaterings na ftp opgelaai het, ooit betrokke was. Een van die sleuteltake van 'n DevOps-ingenieur is nou om 'n gemaklike en effektief gestruktureerde proses van interaksie tussen ontwikkelingspanne en produkinfrastruktuur te verseker. Dit is hierdie mense wat verantwoordelik is vir die ontplooiing van terugrol- en ontplooiingstelsels; dit is hierdie mense wat van die las van ontwikkelaars afhaal en soveel as moontlik op hul uiters belangrike taak konsentreer. Terselfdertyd sal devops nooit 'n nuwe kabel laat loop of 'n nuwe skootrekenaar uit die agterkamer uitreik nie (c) KO
Wat is die vangs?
Op die vraag "Wie is DevOps?" die helfte van die werkers in die veld begin iets soos “Wel, kortom, dit is die admin wat ...” en verder in die teks antwoord. Ja, eens op 'n tyd, toe die beroep van DevOps-ingenieur pas by die mees talentvolle administrateurs ontstaan het in terme van diensinstandhouding, was die verskille tussen hulle nie vir almal duidelik nie. Maar nou, wanneer die funksies van devops en admin in die span radikaal verskil het, is dit onaanvaarbaar om hulle met mekaar te verwar, of selfs gelyk te stel.
Maar wat beteken dit vir besigheid?
Verhuring, dit gaan alles daaroor.
Jy maak 'n vakature oop vir "Stelseladministrateur", en die vereistes wat daar gelys word, is "interaksie met ontwikkeling en kliënte", "CI/CD afleweringstelsel", "instandhouding van die maatskappy se bedieners en toerusting", "administrasie van interne stelsels" ensovoorts aan; jy verstaan dat die werkgewer nonsens praat. Die vangplek is dat in plaas van "Stelseladministrateur" die vakaturetitel "DevOps Engineer" moet wees, en as hierdie titel verander word, dan val alles in plek.
Watter indruk kry mens egter wanneer jy so 'n vakature lees? Dat die maatskappy op soek is na 'n multi-masjien operateur wat beide 'n weergawebeheer en moniteringstelsel sal ontplooi en die twister met sy tande sal druk...
Maar om nie die graad van dwelmverslawing in die arbeidsmark te verhoog nie, is dit genoeg om vakatures op hul eie name te noem en duidelik te verstaan dat 'n DevOps-ingenieur en 'n stelseladministrateur twee verskillende entiteite is. Maar die onbedwingbare begeerte van sommige werkgewers om die wydste moontlike lys van vereistes aan 'n kandidaat voor te lê, lei daartoe dat "klassieke" stelseladministrateurs ophou om te verstaan wat rondom hulle gebeur. Wat, die beroep is besig om te muteer en hulle is agter die tyd?
Nee nee en nog een keer nee. Infrastruktuuradministrateurs wat die maatskappy se interne bedieners sal bestuur, of L2/L3-ondersteuningsposisies sal beklee en ander werknemers sal help, het nie weggegaan nie en gaan nie weggaan nie.
Kan hierdie spesialiste DevOps-ingenieurs word? Natuurlik kan hulle. Trouens, dit is 'n verwante omgewing wat stelseladministrasievaardighede vereis, maar hierbenewens word werk met monitering, afleweringstelsels en in die algemeen noue interaksie met die ontwikkeling- en toetsspan bygevoeg.
Nog 'n DevOps-probleem
Trouens, alles is nie beperk tot net huur en konstante verwarring tussen admins en devops nie. Op 'n stadium het die besigheid te kampe gehad met die probleem om opdaterings en interaksie van die ontwikkelingspan met die finale infrastruktuur te lewer.
Miskien was dit toe ’n oom met sprankelende oë op die verhoog van een of ander konferensie opgestaan en gesê het: “Ons doen dit en noem dit DevOps. Hierdie ouens sal al jou probleme oplos” - en begin vertel hoe goeie lewe in die maatskappy is nadat hulle DevOps-praktyke geïmplementeer het.
Dit is egter nie genoeg om 'n DevOps-ingenieur te huur om alles te laat werk soos dit moet nie. Die maatskappy moet 'n volledige DevOps-transformasie ondergaan, dit wil sê, die rol en vermoëns van ons DevOps moet ook duidelik verstaan word aan die kant van die produkontwikkeling- en toetsspan. Ons het 'n "wonderlike" storie oor hierdie onderwerp wat al die brutaliteit wat op sommige plekke gebeur, volledig illustreer.
Situasie. DevOps is nodig om 'n weergawe-terugrolstelsel te implementeer sonder om regtig te delf na hoe dit sal werk. Kom ons neem aan dat daar binne die Gebruikersstelsel afsonderlike velde vir voornaam, van en wagwoord is. 'n Nuwe weergawe van die produk kom uit, maar vir ontwikkelaars is 'n "terugrol" net 'n towerstaf wat alles sal regmaak, en hulle weet nie eers hoe dit werk nie. So, byvoorbeeld, in die volgende pleister het die ontwikkelaars die eerste- en achternaamvelde gekombineer, dit in produksie uitgerol, maar die weergawe is om een of ander rede stadig. Wat is besig om te gebeur? Bestuur kom devops en sê "Pull the switch!", dit wil sê, vra hom om terug te rol na die vorige weergawe. Wat doen devops? Dit rol terug na die vorige weergawe, maar aangesien die ontwikkelaars nie wou uitvind hoe hierdie terugrol gedoen is nie, het niemand aan die devops-span gesê dat die databasis ook teruggerol moet word nie. As gevolg hiervan stort alles vir ons ineen, en in plaas van 'n stadige webwerf, sien gebruikers 'n "500"-fout, want die ou weergawe werk nie met die velde van die nuwe databasis nie. Devops weet nie hiervan nie. Die ontwikkelaars is stil. Die bestuur begin hul senuwees en geld verloor en onthou die rugsteun, en bied aan om van hulle terug te rol sodat "iets ten minste sal werk." As gevolg hiervan verloor gebruikers al hul data oor 'n tydperk.
Die neute gaan natuurlik na devops, wat "nie 'n behoorlike terugrolstelsel gemaak het nie," en niemand gee om dat die eland in hierdie storie ontwikkelaars is nie.
Die gevolgtrekking is eenvoudig: sonder 'n normale benadering tot DevOps as sodanig, is dit van min nut.
Die belangrikste ding om te onthou: 'n DevOps-ingenieur is nie 'n towenaar nie, en sonder kwaliteit kommunikasie en tweerigting-interaksie met ontwikkeling, sal hy nie sy take hanteer nie. Ontwikkelaars kan nie alleen gelaat word met hul "probleme" of die opdrag gegee word "moenie met die ontwikkelaars bemoei nie, hulle werk is om te kodeer," en dan hoop dat alles op 'n kritieke oomblik sal werk soos dit moet. Dis nie hoe dit werk nie.
In wese is DevOps 'n bevoegdheid op die grens tussen bestuur en tegnologie. Boonop is dit ver van voor die hand liggend dat daar meer tegnologie as bestuur in hierdie skemerkelkie moet wees. As jy werklik vinniger en doeltreffender ontwikkelingsprosesse wil bou, moet jy jou devops-span vertrou. Hy ken die regte gereedskap, hy het soortgelyke projekte geïmplementeer, hy weet hoe om dit te doen. Help hom, luister na sy raad, moenie probeer om hom in een of ander outonome eenheid te isoleer nie. As admins op hul eie kan werk, dan is devops nutteloos in hierdie geval; hulle sal jou nie kan help om beter te word as jy self nie hierdie hulp wil aanvaar nie.
En 'n laaste ding: hou op om infrastruktuuradministrateurs aanstoot te gee. Hulle het hul eie, uiters belangrike front van werk. Ja, 'n administrateur kan 'n DevOps-ingenieur word, maar dit moet op versoek van die persoon self gebeur, en nie onder druk nie. En daar is niks verkeerd daarmee dat 'n stelseladministrateur 'n stelseladministrateur wil bly nie - dit is sy aparte beroep en sy reg. As jy 'n professionele transformasie wil ondergaan, moet jy nooit vergeet dat jy nie net tegnologiese vaardighede nie, maar ook bestuursvaardighede sal moet opbou. Dit sal waarskynlik aan jou as leier wees om al hierdie mense bymekaar te bring en hulle te leer om in dieselfde taal te kommunikeer.
Bron: will.com