Wat is er nodig voor het succes van een IT-bedrijf in 2019? Sprekers op conferenties en meetups gebruiken veel grote en niet altijd begrijpelijke woorden voor gewone mensen. Strijd om implementatietijd, microservices, afzien van monolithen, DevOps-transformatie en nog veel meer. Als we de mooie woorden terzijde schuiven en recht voor de raap spreken, dan komt het neer op Ć©Ć©n eenvoudig punt: maak een kwalitatief product en zorg ervoor dat je dit comfortabel doet voor het team.
Dit is de laatste tijd cruciaal geworden. Het bedrijfsleven is eindelijk tot de conclusie gekomen dat een comfortabel ontwikkelingsproces de productiviteit verhoogt, en als alles soepel verloopt en als een goed geoliede machine werkt, biedt dit ook enige ruimte voor manoeuvre in kritieke situaties. Eens werd dit manoeuvre bedacht door een slimme persoon, maar de industrie evolueert en we zijn aangekomen bij DevOps-engineers - mensen die het proces van samenwerking tussen ontwikkeling en externe infrastructuur in iets adequaats en niet verbonden met sjamanisme omzetten.
Dit hele verhaal over 'per module' is prachtig, maar... Het gebeurde dat een deel van de systeembeheerders plotseling als DevOps werd bestempeld, terwijl er van de echte DevOps-engineers ten minste telepathische en helderziende vaardigheden werden geƫist.
Voordat we het over moderne problemen van infrastructuurbeveiliging hebben, laten we eerst definiƫren wat we met deze term bedoelen. Tegenwoordig is de situatie zodanig dat we op de dualiteit van dit begrip zijn beland: infrastructuur kan voorwaardelijk extern en voorwaardelijk intern zijn.
Met externe infrastructuur bedoelen we alles wat de werking van de service of het product dat het team ontwikkelt, ondersteunt. Dit zijn applicatie- of website-servers, hosting en andere diensten die de werking van het product ondersteunen.
Interne infrastructuur omvat de diensten en apparatuur die het ontwikkelingsteam en andere medewerkers gebruiken, waarvan er ook meestal nogal wat zijn. Dit zijn interne servers voor codeopslag, lokaal uitgerolde taakbeheerders en alles wat bestaat binnen het bedrijfsintranet.
Wat doet een systeembeheerder in een bedrijf? Naast het beheer van het bedrijfsintranet rust er vaak een zware last van praktische zaken op hem, zoals het waarborgen van de werking van kantoorapparatuur. De admin is diegene die snel een nieuwe computer of een kant-en-klaar reserve-laptop uit het magazijn haalt, een nieuw toetsenbord verstrekt en op handen en knieƫn door de kantoren kruipt om een Ethernet-kabel aan te leggen. De admin is de lokale baas en heerser, niet alleen over interne en externe servers, maar ook over de praktische zaken. Ja, sommige beheerders werken alleen op systeemniveau, zonder hardware. Zij verdienen een aparte vermelding als "infrastructuursysteembeheerder". Anderen zijn gespecialiseerd in het onderhoud van uitsluitend kantoorapparatuur; gelukkig, als het bedrijf meer dan honderd mensen telt, is er altijd werk. Toch zijn geen van beiden devops.
Wie zijn DevOps dan? DevOps zijn de mensen die zich bezighouden met de interactie tussen softwareontwikkeling en externe infrastructuur. Modernere devops zijn veel dieper betrokken bij de ontwikkelings- en deployprocessen dan ooit systeembeheerders waren, die simpelweg updates naar ftp uploaden. Een van de belangrijkste taken van een DevOps-engineer tegenwoordig is het waarborgen van een comfortabele en efficiƫnt opgebouwde interactie tussen de ontwikkelteams en de productinfrastructuur. Deze mensen zijn verantwoordelijk voor het implementeren van rollback- en deploysystemen en verlichten een deel van de last voor ontwikkelaars, zodat ze zich maximaal kunnen concentreren op hun uiterst belangrijke taken. Ondertussen zal een devops nooit een nieuwe kabel aanleggen of een nieuwe laptop uitdelen uit het magazijn (c) KO
Wat is het addertje onder het gras?
Wanneer je de vraag "Wie is DevOps?" stelt, begint de helft van de mensen in de sector te antwoorden met iets als: "Nou, dat is een soort van beheerder die..." en ga zo maar door. Ja, lang geleden, toen het beroep van DevOps-engineer net uit de meest getalenteerde beheerders op het gebied van servicebeheer voortkwam, waren de verschillen tussen hen niet voor iedereen duidelijk. Maar nu, nu de functies van DevOps en beheerders in het team radicaal zijn gaan verschillen, is het onaanvaardbaar om hen met elkaar te verwarren of zelfs gelijk te stellen.
Maar wat betekent dit voor het bedrijfsleven?
Het draait allemaal om de aanwerving.
Je opent een vacature "Systeembeheerder", en daar staan eisen zoals "samenwerking met ontwikkeling en opdrachtgevers", "CI/CD-leveringssysteem", "ondersteuning van servers en bedrijfsapparatuur", "beheersing van interne systemen" en verder; je begrijpt dat de werkgever iets onzinnigs zegt. Het probleem is dat in de titel van de vacature in plaats van "Systeembeheerder" "DevOps-engineer" zou moeten staan, en als je die titel verandert, dan valt alles op zijn plaats.
Wat voor indruk ontstaat er echter bij het lezen van zo'n vacature? Dat het bedrijf op zoek is naar een multitasker die zowel het versiebeheersysteem als het monitoring-systeem kan opzetten, en de server met zijn tanden kan omhelzen...
En toch, om de dosis onzin op de arbeidsmarkt niet te verhogen, is het voldoende om vacatures bij hun naam te noemen en duidelijk te begrijpen dat een DevOps-engineer en een systeembeheerder twee verschillende entiteiten zijn. Alleen de onstuitbare wens van sommige werkgevers om een zo breed mogelijk eisenpakket aan kandidaten te stellen, leidt ertoe dat "klassieke" systeembeheerders niet meer begrijpen wat er om hen heen gebeurt. Wat, is het beroep aan het muteren en zijn zij achtergebleven?
Nee, nee en nogmaals nee. Infrastructuurbeheerders, die de interne servers van het bedrijf besturen of posities in L2/L3-ondersteuning bekleden en andere medewerkers helpen, zijn niet verdwenen en zijn ook niet van plan dat te doen.
Kunnen deze specialisten DevOps-engineers worden? Natuurlijk kunnen ze dat. In feite is het een verwante omgeving die vaardigheden in systeemadministratie vereist, maar daarnaast is er ook werk met monitoring, leveringssystemen en, in het algemeen, een nauwe samenwerking met het ontwikkelings- en testteam.
Een ander probleem van DevOps
In werkelijkheid beperkt het probleem zich niet alleen tot het aannemen van personeel en de voortdurende verwarring tussen beheerders en DevOps'ers. Op een bepaald moment stond het bedrijf voor het probleem van het leveren van updates en de samenwerking tussen het ontwikkelteam en de eindinfrastructuur.
Misschien was dit het moment waarop een oom met vurige ogen het podium van een conferentie betrad en zei: "En wij doen het zo en noemen dit DevOps. Deze jongens lossen al uw problemen op" ā en begon te vertellen hoe goed het leven in het bedrijf is na de implementatie van DevOps-praktijken.
Echter, het is niet genoeg om een DevOps-engineer aan te nemen om alles "zoals het hoort" te laten werken. Het bedrijf moet een volledige DevOps-transformatie ondergaan, dat wil zeggen dat de rol en mogelijkheden van onze DevOps'er duidelijk erkend moeten worden aan de kant van het ontwikkelings- en testteam van het product. We hebben een "prachtig" verhaal over dit onderwerp, dat de soms heftige gang van zaken goed illustreert.
Situatie. Van de devops wordt gevraagd om een versie-herstel systeem op te zetten, zonder er echt in te duiken hoe het zal functioneren. Stel dat binnen het systeem Users ā dit aparte velden zijn voor naam, achternaam en wachtwoord. Er komt een nieuwe versie van het product, maar voor de ontwikkelaars is 'herstellen' gewoon een toverstokje dat alles fikst, en ze hebben geen idee hoe het werkt. Neem bijvoorbeeld aan dat de ontwikkelaars in een recente patch de naam- en achternaamvelden hebben samengevoegd, dit in productie hebben gebracht, en de versie om een of andere reden traag is. Wat gebeurt er? Het management komt naar de devops en zegt 'Trek de schakelaar!', wat betekent dat ze hem vragen terug te gaan naar de vorige versie. Wat doet de devops? Hij gaat terug naar de vorige versie, maar omdat de ontwikkelaars niet wilden begrijpen hoe deze terugkeer werkt, heeft niemand de devops verteld dat de database ook teruggezet moest worden. Uiteindelijke leidt dit ertoe dat alles in elkaar stort, en gebruikers in plaats van een trage website een foutmelding '500' zien, omdat de oude versie niet werkt met de velden van de nieuwe database. De devops is zich daar niet van bewust. De ontwikkelaars zwijgen. Het management begint zijn gemoed te verliezen en verliest geld en herinnert zich de back-ups, en stelt voor om daarmee terug te gaan om 'al is het maar iets te laten werken'. Als gevolg daarvan verliezen gebruikers al hun gegevens over een bepaalde periode.
Natuurlijk krijgt de devops de gevolgen te horen, en wordt geklaagd dat hij 'geen goed herstel systeem heeft gemaakt', terwijl niemand zich druk maakt om het feit dat de ontwikkelaars de echte schuldigen zijn in dit verhaal.
De conclusie is simpel: zonder een goede benadering van DevOps is het nut ervan niet zo groot.
Het belangrijkste om te onthouden is: een DevOps engineer is geen tovenaar, en zonder kwalitatieve communicatie en tweezijdige interactie met de ontwikkeling zal hij niet in staat zijn zijn taken te vervullen. Devops kunnen niet alleen gelaten worden met hun 'problemen' of de opdracht krijgen 'meng je niet in de zaken van de ontwikkelaars, zij coderen', en daarna verwachten dat alles op het kritieke moment goed zal werken. Zo werkt het niet.
In wezen is DevOps een competentie op de grens tussen management en technologie. Het is bovendien lang niet vanzelfsprekend dat er in deze cocktail van technologieƫn meer technologie dan management zou moeten zijn. Als je echt snellere en efficiƫntere ontwikkelingsprocessen wilt opbouwen, moet je je DevOps-specialist vertrouwen. Hij kent de juiste tools, heeft soortgelijke projecten uitgevoerd en weet hoe het moet. Helpen jullie hem, luister naar zijn adviezen, probeer hem niet te isoleren in een autonoom onderdeel. Als systeembeheerders zelfstandig kunnen werken, zijn DevOps-specialisten in dat geval nutteloos; zij kunnen je niet helpen beter te worden als je zelf deze hulp niet wilt accepteren.
En tot slot: stop met het beledigen van infrastructuurbeheerders. Zij hebben hun eigen, uiterst belangrijke front van werkzaamheden. Ja, een beheerder kan DevOps-engineer worden, maar dat moet gebeuren op wens van de persoon zelf, niet gedwongen. En er is niets mis mee als een systeembeheerder systeembeheerder wil blijven ā het is zijn aparte beroep en zijn recht. Als er echter de wens is om een professionele transformatie te ondergaan, moet je zeker niet vergeten dat er niet alleen technologische vaardigheden vergroot moeten worden, maar ook managementvaardigheden. Al deze mensen samenbrengen en leren communiceren in dezelfde taal zal hoogstwaarschijnlijk jouw taak als leidinggevende zijn.
Bron: habr.com
