Vad krävs för att ett IT-företag ska bli framgångsrikt 2019? Föreläsare på konferenser och möten säger många högljudda ord som inte alltid är begripliga för normala människor. Kampen om driftsättningstid, mikrotjänster, övergivande av monoliten, DevOps-transformation och mycket, mycket mer. Om vi kastar bort verbal skönhet och talar direkt och på ryska, kommer allt till en enkel tes: gör en högkvalitativ produkt och gör det med komfort för teamet.
Det senare har blivit kritiskt viktigt. Business har äntligen kommit fram till att en bekväm utvecklingsprocess ökar produktiviteten, och om allt är felsökt och fungerar som en klocka ger det också ett visst manöverutrymme i kritiska situationer. En gång i tiden, för den här manöverns skull, kom en viss smart person på säkerhetskopior, men branschen utvecklas, och vi kom till DevOps-ingenjörer - människor som förvandlar interaktionsprocessen mellan utveckling och extern infrastruktur till något adekvat och inte relaterat till shamanism.
Hela den här "modulära" historien är underbar, men... Det hände sig att några av administratörerna plötsligt döptes till DevOps, och DevOps-ingenjörerna själva började krävas för att åtminstone ha färdigheter i telepati och klärvoajans.
Innan vi pratar om moderna problem med att tillhandahålla infrastruktur, låt oss definiera vad vi menar med denna term. För närvarande har situationen utvecklats på ett sådant sätt att vi har nått dualiteten av detta koncept: infrastruktur kan vara villkorligt extern och villkorligt intern.
Med extern infrastruktur menar vi allt som säkerställer funktionaliteten hos den tjänst eller produkt som teamet utvecklar. Dessa är applikations- eller webbplatsservrar, hosting och andra tjänster som säkerställer produktens funktionalitet.
Den interna infrastrukturen omfattar tjänster och utrustning som används av utvecklingsteamet självt och andra anställda, som det vanligtvis är många av. Dessa är interna servrar för kodlagringssystem, en lokalt utplacerad uppgiftshanterare och allt, allt, allt som finns inom företagets intranät.
Vad gör en systemadministratör på ett företag? Utöver arbetet med att administrera just detta företags intranät, bär det ofta bördan av ekonomiska problem att säkerställa att kontorsutrustningen fungerar. Administratören är samma kille som snabbt kommer att dra en ny systemenhet eller en extra bärbar dator redo att användas från det bakre rummet, ge ut ett nytt tangentbord och krypa på alla fyra genom kontoren och sträcka ut Ethernet-kabeln. En administratör är en lokal ägare och härskare över inte bara interna och externa servrar, utan också en företagsledare. Ja, vissa administratörer kan bara arbeta i systemplanet, utan hårdvara. De bör separeras i en separat underklass av "infrastruktursystemadministratörer." Och vissa är specialiserade på att serva uteslutande kontorsutrustning, lyckligtvis, om företaget har fler än hundra personer, tar arbetet aldrig slut. Men ingen av dem är devops.
Vilka är DevOps? Devops är killar som pratar om samspelet mellan mjukvaruutveckling och extern infrastruktur. Mer exakt är moderna devops involverade i utvecklings- och distributionsprocesserna mycket djupare än administratörer som helt enkelt laddade upp uppdateringar till ftp någonsin var involverade. En av nyckeluppgifterna för en DevOps-ingenjör nu är att säkerställa en bekväm och effektivt strukturerad process av interaktion mellan utvecklingsteam och produktinfrastruktur. Det är dessa personer som är ansvariga för att distribuera återställnings- och distributionssystem, det är dessa människor som tar en del av bördan från utvecklarna och koncentrerar sig så mycket som möjligt på sin extremt viktiga uppgift. Samtidigt kommer devops aldrig att dra en ny kabel eller ge ut en ny bärbar dator från det bakre rummet (c) KO
Vad är haken?
På frågan "Vem är DevOps?" hälften av arbetarna på fältet börjar svara något i stil med "Tja, kort sagt, det här är administratören som ..." och längre fram i texten. Ja, en gång i tiden, när yrket som DevOps-ingenjör precis kom från de mest begåvade administratörerna när det gäller underhåll av tjänster, var skillnaderna mellan dem inte uppenbara för alla. Men nu, när funktionerna för devops och admin i teamet har blivit radikalt annorlunda, är det oacceptabelt att förväxla dem med varandra, eller till och med likställa dem.
Men vad betyder detta för företagen?
Att anställa, allt handlar om det.
Du öppnar en ledig tjänst för ”Systemadministratör”, och kraven som anges där är ”interaktion med utveckling och kunder”, ”CI/CD leveranssystem”, ”underhåll av företagets servrar och utrustning”, ”administration av interna system” osv. på; du förstår att arbetsgivaren pratar dumheter. Haken är att istället för "Systemadministratör" ska den lediga tjänstens titel vara "DevOps Engineer", och om denna titel ändras faller allt på plats.
Men vilket intryck får man när man läser en sådan ledig tjänst? Att företaget letar efter en multimaskinsoperatör som ska installera både versionskontroll och övervakningssystem och som ska klämma ihop vridaren med tänderna...
Men för att inte öka graden av drogberoende på arbetsmarknaden räcker det med att kalla lediga jobb vid sina rätta namn och tydligt förstå att en DevOps-ingenjör och en systemadministratör är två olika enheter. Men vissa arbetsgivares obevekliga önskan att presentera en bredast möjliga lista med krav för en kandidat leder till att "klassiska" systemadministratörer slutar förstå vad som händer runt dem. Vadå, yrket muterar och de ligger efter i tiden?
Nej nej och en gång till nej. Infrastrukturadministratörer som kommer att hantera företagets interna servrar, eller ockupera L2/L3 supporttjänster och hjälpa andra anställda, har inte gått bort och kommer inte att försvinna.
Kan dessa specialister bli DevOps-ingenjörer? Klart de kan. I själva verket är detta en relaterad miljö som kräver kompetens inom systemadministration, men utöver detta tillkommer arbete med övervakning, leveranssystem och generellt sett nära interaktion med utvecklings- och testteamet.
Ännu ett DevOps-problem
Faktum är att allt inte är begränsat till att bara anställa och konstant förvirring mellan administratörer och devops. Vid något tillfälle ställdes verksamheten inför problemet med att leverera uppdateringar och interaktion mellan utvecklingsteamet och den slutliga infrastrukturen.
Kanske var det när en farbror med gnistrande ögon reste sig på scenen på någon konferens och sa: "Vi gör det här och kallar det DevOps. Dessa killar kommer att lösa alla dina problem” - och började berätta hur bra livet är i företaget efter att ha implementerat DevOps-praxis.
Det räcker dock inte att anlita en DevOps-ingenjör för att få allt att fungera som det ska. Företaget måste genomgå en fullständig DevOps-transformation, det vill säga att rollen och kapaciteten hos våra DevOps också måste förstås tydligt på sidan av produktutvecklings- och testteamet. Vi har en "underbar" historia om detta ämne som till fullo illustrerar all brutalitet som händer på vissa ställen.
Situation. DevOps krävs för att distribuera ett versionsåterställningssystem utan att riktigt fördjupa sig i hur det kommer att fungera. Låt oss anta att det inom användarsystemet finns separata fält för förnamn, efternamn och lösenord. En ny version av produkten kommer ut, men för utvecklare är en "återställning" bara en trollstav som fixar allt, och de vet inte ens hur det fungerar. Så, till exempel, i nästa patch kombinerade utvecklarna för- och efternamnsfälten, rullade ut det i produktion, men versionen är långsam av någon anledning. Vad händer? Management kommer till devops och säger "Pull the switch!", det vill säga ber honom att rulla tillbaka till den tidigare versionen. Vad gör devops? Det rullar tillbaka till den tidigare versionen, men eftersom utvecklarna inte ville ta reda på hur denna återställning gjordes, sa ingen till devops-teamet att databasen också behövde rullas tillbaka. Som ett resultat kraschar allt för oss, och istället för en långsam webbplats ser användarna ett "500"-fel, eftersom den gamla versionen inte fungerar med fälten i den nya databasen. Devops känner inte till detta. Utvecklarna är tysta. Ledningen börjar förlora sina nerver och pengar och kommer ihåg säkerhetskopiorna och erbjuder sig att rulla tillbaka från dem så att "åtminstone något kommer att fungera." Som ett resultat förlorar användarna all sin data under en tidsperiod.
Nötterna går naturligtvis till devops, som "inte gjorde ett ordentligt återställningssystem", och ingen bryr sig om att älgarna i den här historien är utvecklare.
Slutsatsen är enkel: utan ett normalt förhållningssätt till DevOps som sådant är det till liten nytta.
Det viktigaste att komma ihåg: en DevOps-ingenjör är inte en magiker, och utan kvalitetskommunikation och tvåvägsinteraktion med utveckling kommer han inte att klara av sina uppgifter. Utvecklare kan inte lämnas ensamma med sina "problem" eller få kommandot "blanda dig inte med utvecklarna, deras jobb är att koda" och sedan hoppas att allt i ett kritiskt ögonblick kommer att fungera som det ska. Det är inte så det fungerar.
I grund och botten är DevOps en kompetens på gränsen mellan management och teknik. Dessutom är det långt ifrån självklart att det borde finnas mer teknik än management i denna cocktail. Om du verkligen vill bygga snabbare och mer effektiva utvecklingsprocesser måste du lita på ditt devops-team. Han kan de rätta verktygen, han har genomfört liknande projekt, han vet hur man gör det. Hjälp honom, lyssna på hans råd, försök inte isolera honom till någon sorts autonom enhet. Om administratörer kan arbeta på egen hand är devops värdelösa i det här fallet, de kommer inte att kunna hjälpa dig att bli bättre om du själv inte vill acceptera denna hjälp.
Och en sista sak: sluta kränka infrastrukturadministratörer. De har sin egen, extremt viktiga arbetsfront. Ja, en administratör kan bli DevOps-ingenjör, men detta bör ske på begäran av personen själv och inte under press. Och det är inget fel med att en systemadministratör vill förbli systemadministratör – det är hans separata yrke och hans rättighet. Om du vill genomgå en professionell förvandling får du aldrig glömma att du måste bygga upp inte bara tekniska färdigheter utan även ledningsförmåga. Med största sannolikhet kommer det att vara upp till dig som ledare att samla alla dessa människor och lära dem att kommunicera på samma språk.
Källa: will.com