Onlangs hebben dergelijke advertenties het internet overspoeld. Ondanks het aangename salaris kan men niet anders dan zich schamen dat er wilde ketterij in staat geschreven. In eerste instantie wordt aangenomen dat ‘DevOps’ en ‘ingenieur’ op de een of andere manier in één woord kunnen worden samengevoegd, en dan volgt er een willekeurige lijst met vereisten, waarvan sommige duidelijk zijn overgenomen uit de vacature voor systeembeheerder.
In dit bericht wil ik graag iets vertellen over hoe we op dit punt in het leven zijn gekomen, wat DevOps werkelijk is en wat we er nu mee kunnen doen.
Dergelijke vacatures kunnen op alle mogelijke manieren worden veroordeeld, maar het feit blijft: er zijn er veel, en zo werkt de markt momenteel. We hielden een devops-conferentie en verklaarden openlijk: “ - niet voor DevOps-ingenieurs." Hier zullen velen het vreemd en wild vinden: waarom mensen die een volledig commercieel evenement organiseren, tegen de markt ingaan. Nu zullen we alles uitleggen.
Over cultuur en processen
Laten we beginnen met het feit dat DevOps geen technische discipline is. Het begon allemaal met het feit dat de historisch vastgestelde rolverdeling niet werkt voor de kwaliteit van producten. Wanneer programmeurs alleen maar programmeren, maar niets willen horen over testen, zit de software vol met bugs. Als het beheerders niet uitmaakt hoe of waarom de software is geschreven, verandert de ondersteuning in een hel.
Bijvoorbeeld het beschrijven van het verschil tussen een systeembeheerder en een SRE-aanpak van servicemanagement . Binnen zijn er interessante onderzoeken uitgevoerd – het is duidelijk dat de beste ontwikkelaars er op de een of andere manier in slagen om sneller dan één keer per uur nieuwe wijzigingen in de productie door te voeren. Ze testen met hun handen niet meer dan 10% (dit is te zien aan ). Hoe doen ze dit? “Excel or die” luidt een van de kopteksten van het rapport. Voor een gedetailleerde bespreking van deze statistieken in de context van testen kunt u verwijzen naar de keynote van Baruch Sadogursky op onze andere conferentie, Heisenbug.
“Als er geen overeenstemming is tussen kameraden,
Hun zaken zullen niet goed gaan,
En er komt niets uit, alleen meel.
Er was eens een zwaan, een rivierkreeft en een snoek..."
Welk deel van de webprogrammeurs begrijpt volgens u echt de omstandigheden waaronder hun applicaties in de productie worden gebruikt? Hoeveel van hen zullen naar de beheerders gaan en proberen uit te zoeken wat er zal gebeuren als de database crasht? En wie van hen zal naar de testers gaan en hen vragen hen te leren hoe ze tests correct kunnen schrijven? En er zijn ook bewakers, productmanagers en een heleboel andere mensen.
Het algemene idee van DevOps is het creëren van samenwerking tussen rollen en afdelingen. Allereerst wordt dit niet bereikt door slim geconfigureerde software, maar door de praktijk van communicatie. DevOps gaat over cultuur, praktijken, methodologie en processen. Er is geen technisch specialisme dat deze vragen kan beantwoorden.
Vicieuze cirkel
Waar kwam de discipline ‘devops engineering’ toen vandaan? Wij hebben een versie! DevOps-ideeën waren goed, zo goed dat ze het slachtoffer werden van hun eigen succes. Enkele louche rekruteurs en mensenhandelaars, die hun eigen sfeer hebben, begonnen zich rond dit hele onderwerp te wervelen.
Stel je voor: gisteren maakte je shoarma in Khimki, en vandaag ben je al een grote man, een senior recruiter. Er is een heel proces van zoeken en selecteren van kandidaten, alles is niet eenvoudig, je moet het begrijpen. Laten we zeggen dat het hoofd van een afdeling zegt: zoek een specialist in X. We kennen X het woord ‘ingenieur’ toe, en we zijn klaar. Linux nodig? Nou, dit is absoluut een Linux-ingenieur, als je DevOps wilt, dan een DevOps-ingenieur. De vacature bestaat niet alleen uit een titel, maar er moet ook wat tekst in worden ingevoerd. De eenvoudigste manier is om een reeks trefwoorden van Google in te voeren, afhankelijk van uw verbeelding. DevOps bestaat uit twee woorden: 'Dev' en 'Ops', wat betekent dat we trefwoorden met betrekking tot ontwikkelaars en beheerders op één stapel moeten samenvoegen. Zo verschijnen er vacatures over beheersing van 42 programmeertalen en 20 jaar gebruik van Kubernetes en Swarm tegelijk. Werkend diagram.
Dit is hoe het betekenisloze en genadeloze beeld van een bepaalde ‘devops’-superheld wortel heeft geschoten in de hoofden van mensen, die iedereen zullen configureren om bij Jenkins in te zetten, en geluk zal komen. O, was alles maar zo eenvoudig. “En zo kun je ook systeembeheerders opsporen”, denkt HR, “het is een modieus woord, de trefwoorden zijn hetzelfde, ze moeten het aas pakken.”
Vraag creëert aanbod, en al deze rommelvacatures zijn opgevuld door een waanzinnig aantal systeembeheerders die zich realiseerden: je kunt alles hetzelfde doen als voorheen, maar meerdere malen meer krijgen door jezelf ‘devops’ te noemen. Net zoals je servers één voor één handmatig via SSH hebt geconfigureerd, zul je ze blijven configureren, maar nu is dit vermoedelijk een devops-praktijk. Dit is een soort complex fenomeen, deels gerelateerd aan de onderschatting van klassieke beheerders en de hype rond DevOps, maar over het algemeen gebeurde wat er gebeurde.
We hebben dus vraag en aanbod. Een vicieuze cirkel die zichzelf voedt. Dit is waar we tegen vechten (onder meer door de DevOops-conferentie op te zetten).
Naast de systeembeheerders die zichzelf de naam 'devops' hebben gegeven, zijn er natuurlijk nog andere deelnemers, bijvoorbeeld professionele SRE's of Infrastructure-as-Code-ontwikkelaars.
Wat mensen doen in DevOps (echt)
Je wilt dus vooruit komen in het leren en toepassen van DevOps-praktijken. Maar hoe doe je dit, in welke richting moet je kijken? Uiteraard moet u niet blindelings vertrouwen op populaire zoekwoorden.
Als er werk is, moet iemand het doen. We zijn er al achter gekomen dat dit geen “devops engineers” zijn, wie dan wel? Het lijkt juister om dit niet in termen van functies te formuleren, maar in termen van specifieke werkgebieden.
Ten eerste kun je de kern van DevOps aanpakken: processen en cultuur. Cultuur is een langzame en moeilijke aangelegenheid, en hoewel het traditioneel de verantwoordelijkheid van managers is, is iedereen er op de een of andere manier bij betrokken, van programmeurs tot beheerders. Een paar maanden geleden Tim Lister :
“Cultuur wordt bepaald door de kernwaarden van de organisatie. Normaal gesproken merken mensen dit niet, maar omdat we al jaren in de consultancy werken, zijn we eraan gewend om het op te merken. Je stapt een bedrijf binnen en letterlijk binnen een paar minuten begin je te voelen wat er gebeurt. Wij noemen dit ‘smaak’. Soms is deze geur echt lekker. Soms veroorzaakt het misselijkheid. (...) Je kunt een cultuur niet veranderen totdat de waarden en overtuigingen achter specifieke acties worden begrepen. Gedrag is gemakkelijk waar te nemen, maar het zoeken naar overtuigingen is moeilijk. DevOps is slechts een mooi voorbeeld van hoe zaken steeds complexer worden.”
Er zit uiteraard ook een technisch aspect aan de kwestie. Als uw nieuwe code binnen een maand wordt getest, maar pas een jaar later wordt vrijgegeven, en het fysiek onmogelijk is om alles te versnellen, voldoet u mogelijk niet aan de goede praktijken. Goede praktijken worden ondersteund door goede instrumenten. Met het idee van Infrastructure-as-Code in gedachten kun je bijvoorbeeld alles gebruiken, van AWS CloudFormation en Terraform tot Chef-Ansible-Puppet. Je moet dit allemaal weten en kunnen, en dit is al een behoorlijk technische discipline. Het is belangrijk om oorzaak niet met gevolg te verwarren: je werkt eerst volgens de principes van SRE en pas daarna implementeer je deze principes in de vorm van enkele specifieke technische oplossingen. Tegelijkertijd is SRE een zeer veelomvattende methodiek die je niet vertelt hoe je Jenkins moet opzetten, maar over vijf basisprincipes:
- Verbeterde communicatie tussen rollen en afdelingen
- Het accepteren van fouten als een integraal onderdeel van het werk
- Veranderingen geleidelijk doorvoeren
- Met behulp van tooling en andere automatisering
- Alles meten wat meetbaar is
Dit is niet zomaar een reeks uitspraken, maar een specifieke . Op weg naar het accepteren van fouten moet u bijvoorbeeld de risico's begrijpen, de beschikbaarheid en onbeschikbaarheid van services meten met behulp van zoiets als SLI () en SLO (), leer postmortems schrijven en zorg ervoor dat het schrijven ervan niet eng is.
In de SRE-discipline is het gebruik van tools slechts een onderdeel van succes, zij het wel een belangrijk onderdeel. We moeten ons technisch voortdurend blijven ontwikkelen, kijken naar wat er in de wereld gebeurt en hoe dit in ons werk kan worden toegepast.
Op hun beurt zijn Cloud Native-oplossingen nu erg populair geworden. Zoals vandaag gedefinieerd door de Cloud Native Computing Foundation, stellen Cloud Native-technologieën organisaties in staat schaalbare applicaties te ontwikkelen en uit te voeren in de dynamische omgevingen van vandaag, zoals publieke, private en hybride clouds. Voorbeelden hiervan zijn containers, servicemeshes, microservices, onveranderlijke infrastructuur en declaratieve API's. Al deze technieken zorgen ervoor dat losjes gekoppelde systemen elastisch, beheersbaar en goed waarneembaar blijven. Goede automatisering stelt ingenieurs in staat regelmatig en met voorspelbare resultaten grote veranderingen door te voeren, zonder dat dit een hele klus wordt. Dit alles wordt ondersteund door een stapel bekende tools als Docker en Kubernetes.
Deze nogal ingewikkelde en brede definitie is te wijten aan het feit dat het gebied ook behoorlijk complex is. Aan de ene kant wordt betoogd dat nieuwe wijzigingen aan dit systeem vrij eenvoudig moeten worden toegevoegd. Aan de andere kant, om erachter te komen hoe je een soort containeromgeving kunt creëren waarin losjes gekoppelde services op een softwaregedefinieerde infrastructuur leven en daar worden geleverd met behulp van continue CI/CD, en om DevOps-praktijken hieromheen te bouwen - dit alles vereist meer dan eet men de hond.
Wat te doen met dit alles
Iedereen lost deze problemen op zijn eigen manier op: je kunt bijvoorbeeld gewone vacatures publiceren om de vicieuze cirkel te doorbreken. Je kunt erachter komen wat woorden als DevOps en Cloud Native betekenen en deze correct en to the point gebruiken. Je kunt ontwikkelen in DevOps en de juiste aanpak demonstreren aan de hand van jouw voorbeeld.
We houden een conferentie , wat de mogelijkheid biedt om dieper in te gaan op de dingen waar we het zojuist over hadden. Hiervoor zijn verschillende groepen rapporten:
- Processen en cultuur;
- Sitebetrouwbaarheidstechniek;
- Cloud-native;
Hoe kies je waar je heen gaat? Er is hier sprake van een subtiel punt. Aan de ene kant gaat DevOps over interactie en willen we heel graag dat je presentaties uit verschillende blokken bijwoont. Aan de andere kant, als je een ontwikkelingsmanager bent die naar de conferentie kwam om zich op één specifieke taak te concentreren, dan beperkt niemand je - uiteraard zal dit een blokkade zijn op het gebied van processen en cultuur. Vergeet niet dat u na de conferentie (na het invullen van het feedbackformulier) opnames krijgt, zodat u later altijd de minder belangrijke presentaties kunt bekijken.
Uiteraard kun je op de conferentie zelf niet op drie sporen tegelijk gaan, daarom richten we het programma zo in dat elk tijdslot voor ieder wat wils heeft.
Het enige dat overblijft is om te begrijpen wat u moet doen als u een DevOps-ingenieur bent! Probeer eerst vast te stellen wat je eigenlijk doet. Meestal noemen ze dit woord graag:
- Ontwikkelaars die werken aan infrastructuur. De groepen rapporten over SRE en Cloud Native zijn voor u het meest geschikt.
- Systeembeheerders. Het is hier ingewikkelder. DevOops gaat niet over systeembeheer. Gelukkig zijn er veel uitstekende conferenties, boeken, artikelen, video's op internet, enz. over het onderwerp systeembeheer. Aan de andere kant, als je geïnteresseerd bent om jezelf te ontwikkelen op het gebied van het begrijpen van cultuur en processen, het leren over cloudtechnologieën en de details van het leven met Cloud Native, dan zien we je graag! Denk hier eens over na: u doet de administratie, en wat gaat u dan doen? Om te voorkomen dat u plotseling in een onaangename situatie terechtkomt, moet u dit nu leren.
Er is nog een andere optie: je volhardt en blijft beweren dat je dat wel bent specifiek een DevOps-ingenieur en niets anders, wat dat ook betekent. Dan moeten we je teleurstellen, DevOops is geen conferentie voor DevOps engineers!
Schuif van in München
DevOops 2020 Moskou wordt gehouden op 29-30 april in Moskou, tickets zijn al beschikbaar .
Bovendien kunt u tot 8 februari. Houd er rekening mee dat u bij het invullen van het formulier de doelgroep moet selecteren die het meeste profijt zal hebben van uw rapport (er zit een verrassing verborgen in de lijst).
Bron: www.habr.com