Wat is er nodig voor een IT-bedrijf om succesvol te zijn in 2019? Docenten op conferenties en meetups zeggen veel luide woorden die voor normale mensen niet altijd begrijpelijk zijn. De strijd om implementatietijd, microservices, het verlaten van de monoliet, DevOps-transformatie en nog veel, veel meer. Als we verbale schoonheid achterwege laten en direct en in het Russisch spreken, komt het allemaal neer op een simpele stelling: maak een product van hoge kwaliteit en doe het met comfort voor het team.
Dit laatste is van cruciaal belang geworden. Het bedrijfsleven is eindelijk tot de conclusie gekomen dat een comfortabel ontwikkelingsproces de productiviteit verhoogt, en als alles wordt opgespoord en als een klok werkt, het ook enige manoeuvreerruimte geeft in kritieke situaties. Er was eens een slimme persoon die ter wille van deze manoeuvre back-ups bedacht, maar de industrie ontwikkelt zich en we kwamen bij DevOps-ingenieurs terecht - mensen die het proces van interactie tussen ontwikkeling en externe infrastructuur omzetten in iets adequaats en niet gerelateerd aan het sjamanisme.
Dit hele “modulaire” verhaal is prachtig, maar... Het gebeurde zo dat sommige beheerders abrupt DevOps werden genoemd, en dat van DevOps-ingenieurs zelf op zijn minst de vaardigheden van telepathie en helderziendheid moesten worden vereist.
Voordat we het hebben over moderne problemen bij het leveren van infrastructuur, moeten we eerst definiëren wat we met deze term bedoelen. Op dit moment heeft de situatie zich zodanig ontwikkeld dat we de dualiteit van dit concept hebben bereikt: infrastructuur kan voorwaardelijk extern en voorwaardelijk intern zijn.
Met externe infrastructuur bedoelen we alles wat de functionaliteit garandeert van de dienst of het product dat het team ontwikkelt. Dit zijn applicatie- of websiteservers, hosting en andere diensten die de functionaliteit van het product garanderen.
De interne infrastructuur omvat diensten en apparatuur die worden gebruikt door het ontwikkelteam zelf en door andere medewerkers, waarvan er meestal veel zijn. Dit zijn interne servers van codeopslagsystemen, een lokaal geïmplementeerde taakbeheerder en alles, alles, alles wat bestaat binnen het bedrijfsintranet.
Wat doet een systeembeheerder in een bedrijf? Naast het beheerswerk van dit zeer zakelijke intranet, draagt het vaak ook de last van economische zorgen om de bruikbaarheid van kantoorapparatuur te garanderen. De beheerder is dezelfde man die snel een nieuwe systeemeenheid of een reservelaptop, klaar voor gebruik, uit de bijkeuken sleept, een nieuw toetsenbord uitdeelt en op handen en voeten door de kantoren kruipt, terwijl hij de Ethernet-kabel uitrekt. Een beheerder is een lokale eigenaar en heerser van niet alleen interne en externe servers, maar ook een bedrijfsleider. Ja, sommige beheerders kunnen alleen op systeemvlak werken, zonder hardware. Ze moeten worden onderverdeeld in een aparte subklasse van ‘infrastructuursysteembeheerders’. En sommige zijn gespecialiseerd in het onderhoud van uitsluitend kantoorapparatuur; als het bedrijf meer dan honderd mensen telt, houdt het werk gelukkig nooit op. Maar geen van beiden zijn devops.
Wie zijn DevOps? Devops zijn jongens die praten over de interactie van softwareontwikkeling met externe infrastructuur. Om preciezer te zijn, moderne devops zijn veel dieper betrokken bij de ontwikkelings- en implementatieprocessen dan beheerders die simpelweg updates naar ftp uploadden ooit betrokken waren. Een van de belangrijkste taken van een DevOps-ingenieur is nu het zorgen voor een comfortabel en effectief gestructureerd interactieproces tussen ontwikkelingsteams en productinfrastructuur. Het zijn deze mensen die verantwoordelijk zijn voor het implementeren van rollback- en implementatiesystemen; het zijn deze mensen die ontwikkelaars een deel van de last ontlasten en zich zoveel mogelijk concentreren op hun uiterst belangrijke taak. Tegelijkertijd zullen devops nooit een nieuwe kabel aanleggen of een nieuwe laptop uit de achterkamer uitgeven (c) KO
Wat is het addertje onder het gras?
Op de vraag “Wie is DevOps?” de helft van de werkers in het veld begint zoiets te antwoorden als “Nou, kortom, dit is de beheerder die …...” en verder in de tekst. Ja, er was eens, toen het beroep van DevOps-ingenieur net opkwam bij de meest getalenteerde beheerders op het gebied van serviceonderhoud, de verschillen daartussen niet voor iedereen duidelijk. Maar nu de functies van devops en admin in het team radicaal anders zijn geworden, is het onaanvaardbaar om ze met elkaar te verwarren, of zelfs maar gelijk te stellen.
Maar wat betekent dit voor het bedrijfsleven?
Huren, het draait er allemaal om.
U opent een vacature voor “Systeembeheerder”, en de eisen die daar worden vermeld zijn “interactie met ontwikkeling en klanten”, “CI/CD-leveringssysteem”, “onderhoud van de servers en apparatuur van het bedrijf”, “beheer van interne systemen” en dergelijke op; je begrijpt dat de werkgever onzin praat. Het addertje onder het gras is dat in plaats van “Systeembeheerder” de titel van de vacature “DevOps Engineer” zou moeten zijn, en als deze titel wordt gewijzigd, valt alles op zijn plaats.
Maar welke indruk krijg je als je zo’n vacature leest? Dat het bedrijf op zoek is naar een multimachine-operator die zowel een versiecontrole- als monitoringsysteem inzet en met zijn tanden in de twister knijpt...
Maar om de mate van drugsverslaving op de arbeidsmarkt niet te vergroten, volstaat het om vacatures bij de juiste naam te noemen en duidelijk te begrijpen dat een DevOps-ingenieur en een systeembeheerder twee verschillende entiteiten zijn. Maar de onstuitbare wens van sommige werkgevers om een kandidaat een zo breed mogelijke lijst met vereisten te presenteren, leidt ertoe dat ‘klassieke’ systeembeheerders niet langer begrijpen wat er om hen heen gebeurt. Wat, het beroep verandert en ze lopen achter op de tijd?
Nee nee en nog een keer nee. Infrastructuurbeheerders, die de interne servers van het bedrijf zullen beheren, of L2/L3-ondersteuningsposities zullen bekleden en andere werknemers zullen helpen, zijn niet weggegaan en zullen niet weggaan.
Kunnen deze specialisten DevOps-ingenieurs worden? Natuurlijk kunnen ze dat. In feite is dit een gerelateerde omgeving die vaardigheden op het gebied van systeembeheer vereist, maar daarnaast komt het werken met monitoring-, leveringssystemen en, in het algemeen, nauwe interactie met het ontwikkelings- en testteam erbij.
Nog een DevOps-probleem
In feite is alles niet beperkt tot alleen het aannemen van personeel en de voortdurende verwarring tussen beheerders en ontwikkelaars. Op een gegeven moment werd het bedrijf geconfronteerd met het probleem van het leveren van updates en de interactie van het ontwikkelingsteam met de uiteindelijke infrastructuur.
Misschien was het toen een oom met sprankelende ogen op het podium van een conferentie opstond en zei: 'Wij doen dit en noemen het DevOps. Deze jongens zullen al je problemen oplossen” - en begonnen te vertellen hoe goed het leven is in het bedrijf na de implementatie van DevOps-praktijken.
Het is echter niet voldoende om een DevOps-engineer in te huren om alles naar behoren te laten werken. Het bedrijf moet een volledige DevOps-transformatie ondergaan, dat wil zeggen dat de rol en mogelijkheden van onze DevOps ook duidelijk moeten worden begrepen aan de kant van het productontwikkelings- en testteam. We hebben een “prachtig” verhaal over dit onderwerp dat alle wreedheden die op sommige plaatsen plaatsvinden volledig illustreert.
Situatie. DevOps is nodig om een versie-rollback-systeem te implementeren zonder echt te verdiepen in hoe het zal werken. Laten we aannemen dat er binnen het Gebruikerssysteem aparte velden zijn voor voornaam, achternaam en wachtwoord. Er komt een nieuwe versie van het product uit, maar voor ontwikkelaars is een “rollback” slechts een toverstaf die alles oplost, en ze weten niet eens hoe het werkt. Dus in de volgende patch combineerden de ontwikkelaars bijvoorbeeld de voor- en achternaamvelden en rolden deze uit in productie, maar de versie is om de een of andere reden traag. Wat is er gaande? Het management komt naar devops en zegt “Trek aan de schakelaar!”, dat wil zeggen, vraagt hem terug te gaan naar de vorige versie. Wat doen devops? Het keert terug naar de vorige versie, maar omdat de ontwikkelaars niet wilden weten hoe deze terugdraaiing werd uitgevoerd, vertelde niemand het devops-team dat de database ook moest worden teruggedraaid. Als gevolg hiervan crasht bij ons alles en in plaats van een trage website zien gebruikers een “500”-foutmelding, omdat de oude versie niet werkt met de velden van de nieuwe database. Devops weet hier niets van. De ontwikkelaars zwijgen. Het management begint de zenuwen en het geld te verliezen en herinnert zich de back-ups en biedt aan om hiervan terug te komen, zodat ‘tenminste iets zal werken’. Als gevolg hiervan verliezen gebruikers in de loop van de tijd al hun gegevens.
De noten gaan natuurlijk naar devops, die “geen goed rollback-systeem hebben gemaakt”, en het kan niemand iets schelen dat de elanden in dit verhaal ontwikkelaars zijn.
De conclusie is simpel: zonder een normale benadering van DevOps als zodanig heeft het weinig nut.
Het belangrijkste om te onthouden: een DevOps-ingenieur is geen goochelaar, en zonder kwaliteitscommunicatie en tweerichtingsinteractie met ontwikkeling zal hij zijn taken niet aankunnen. Ontwikkelaars kunnen niet alleen worden gelaten met hun ‘problemen’ of het commando krijgen ‘bemoei je niet met de ontwikkelaars, het is hun taak om te coderen’, en dan hopen dat op een kritiek moment alles zal werken zoals het zou moeten werken. Dat is niet hoe het werkt.
In wezen is DevOps een competentie op de grens tussen management en technologie. Bovendien is het verre van vanzelfsprekend dat er in deze cocktail meer technologie dan management zou moeten zitten. Als je echt snellere en efficiëntere ontwikkelingsprocessen wilt bouwen, moet je vertrouwen op je devops-team. Hij kent de juiste tools, hij heeft soortgelijke projecten geïmplementeerd, hij weet hoe hij het moet doen. Help hem, luister naar zijn advies, probeer hem niet te isoleren in een soort autonome eenheid. Als admins zelfstandig kunnen werken, dan zijn devops in dit geval nutteloos; ze zullen je niet kunnen helpen beter te worden als je deze hulp zelf niet wilt accepteren.
En nog een laatste ding: stop met het beledigen van infrastructuurbeheerders. Ze hebben hun eigen, uiterst belangrijke front van werk. Ja, een beheerder kan DevOps engineer worden, maar dit moet gebeuren op verzoek van de persoon zelf, en niet onder druk. En er is niets mis met het feit dat een systeembeheerder systeembeheerder wil blijven - dit is zijn aparte beroep en zijn recht. Als je een professionele transformatie wilt ondergaan, mag je nooit vergeten dat je niet alleen technologische vaardigheden zult moeten opbouwen, maar ook managementvaardigheden. Hoogstwaarschijnlijk zal het aan jou als leider zijn om al deze mensen bij elkaar te brengen en hen te leren communiceren in dezelfde taal.
Bron: www.habr.com