De laatste tijd zijn zulke advertenties overal op internet verschenen. Ondanks het aantrekkelijke salaris, is het zorgwekkend dat er binnenin onzin staat geschreven. Het begint met de veronderstelling dat "DevOps" en "ingenieur" op de een of andere manier aan elkaar kunnen worden geplakt in Ć©Ć©n woord, en vervolgens volgt een willekeurige lijst van vereisten, waarvan een deel duidelijk is gekopieerd uit een vacature voor systeembeheerder.
In deze post willen we het een beetje hebben over hoe we zo ver zijn gekomen, wat DevOps eigenlijk is en wat we er nu mee moeten doen.
Zulke vacatures kunnen op verschillende manieren worden afgekeurd, maar het feit blijft: ze zijn er in overvloed, en zo werkt de markt op dit moment. We hebben een DevOps-conferentie georganiseerd en zeggen openlijk: " ā niet voor DevOps-ingenieurs". Dit zal voor velen vreemd en absurd lijken: waarom zouden mensen een volledig commercieel evenement organiseren terwijl ze tegen de markt ingaan? We leggen alles nu uit.
Over cultuur en processen
Laten we beginnen met het feit dat DevOps geen ingenieursdiscipline is. Het begon allemaal omdat de historisch gegroeide rolverdeling niet werkt voor de kwaliteit van producten. Wanneer programmeurs alleen maar programmeren en verder niets willen weten over testen, raakt de software vol met bugs. Wanneer systeembeheerders zich niks aantrekken van hoe en waarom de software is geschreven, wordt de ondersteuning een hel.
Bijvoorbeeld, de beschrijving van het verschil tussen de systeembeheerder- en SRE-aanpak van service management Er zijn interessante onderzoeken gedaan in het kader van waaruit blijkt dat de beste ontwikkelaars op de een of andere manier snel nieuwe veranderingen in productie kunnen implementeren, sneller dan eens per uur. Ze testen handmatig niet meer dan 10% (dit is te zien aan de Hoe slagen zij hierin? "Excel or die" ā zegt een van de koppen in het rapport. Voor een gedetailleerde bespreking van deze statistieken met betrekking tot testen, kunt u terecht bij de keynote van Baruch Sadogursky op een andere conferentie van ons, Heisenbug.
"Wanneer er geen overeenstemming is onder kameraden,
Zal hun zaak niet verder komen,
En zal er niet uit voortkomen, alleen maar moeite.
Eens was er een Zwaan, een Krab en een Voorn..."
Wat denkt u, welk deel van de webontwikkelaars begrijpt echt onder welke omstandigheden hun applicaties in productie draaien? Hoeveel van hen gaat naar de beheerders en probeert te begrijpen wat er gebeurt als de database uitvalt? En wie van hen gaat naar de testers en vraagt hoe ze goed tests kunnen schrijven? En dan zijn er nog de beveiligingsspecialisten, productmanagers en nog een heleboel andere mensen.
De algemene idee van DevOps is om de samenwerking tussen rollen en afdelingen te verbeteren. Dit wordt in de eerste plaats niet bereikt door een of andere slim ingestelde software, maar door communicatietraining. DevOps is een kwestie van cultuur, praktijk, methodologie en processen. Er bestaat geen engineering beroep dat deze vragen beantwoordt.
De vicieuze cirkel
Waar kwam de discipline ādevops-engineeringā vandaan? Wij hebben een theorie! De ideeĆ«n van DevOps bleken zo goed te zijn dat ze slachtoffer zijn geworden van hun eigen succes. Rond dit onderwerp zijn er dubieuze recruiters en mensenhandelaren opgekomen, die hun eigen sfeer hebben.
Stel je voor: gisteren sprintte je in Chimki met shawarma, en vandaag ben je al een grote speler, een senior recruiter. Er is een compleet proces van het zoeken en selecteren van kandidaten, het is allemaal niet eenvoudig. Stel dat de afdelingshoofd zegt: vind een specialist in X. We voegen het woord 'engineer' toe aan X, en het is klaar. Heb je Linux nodig? Nou, dat is zeker een Linux-engineer. Wil je DevOps? Dan is het een DevOps-engineer. Een vacature bestaat niet alleen uit een titel, maar er moet ook wat tekst in. Het makkelijkste is om een set sleutelwoorden van Google in te voegen, afhankelijk van ieders fantasie. DevOps bestaat uit twee woorden - 'Dev' en 'Ops', dus we moeten sleutelwoorden combineren die betrekking hebben op ontwikkelaars en beheerders, alles in Ć©Ć©n stapel. Zo verschijnen er vacatures die vereisen dat je 42 programmeertalen beheerst en 20 jaar ervaring met Kubernetes en Swarm tegelijkertijd hebt. Een werkende manier.
Zo heeft er in de hoofden van mensen een zinloos en meedogenloos beeld van een soort superheld āDevOpsā wortel geschoten, die voor iedereen de deployment op Jenkins kan instellen, en dan zal het geluk komen. Och, als het maar zo eenvoudig was. "Je kunt ook systeembeheerders werven, denkt de HR, het woord is trendy, de sleutelwoorden zijn hetzelfde, ze moeten wel vissen."
Vraag en aanbod creĆ«ren elkaar, en op al deze vage vacatures is er een enorme toestroom van systeembeheerders gekomen die hebben doorgekregen: je kunt precies hetzelfde doen als voorheen, maar veel meer verdienen door jezelf āDevOps engineerā te noemen. Hoe je servers eerder handmatig via SSH instelde, zo blijf je dat nu doen, maar nu wordt dit zogenaamd āDevOps-praktijkā genoemd. Dit is een complex fenomeen, gedeeltelijk gerelateerd aan de onderwaardering van klassieke systeembeheerders en de hype rondom DevOps, maar overall ā wat gebeurd is, is gebeurd.
Dus, we hebben vraag en aanbod. Een vicieuze cirkel die zichzelf in stand houdt. Hiertegen voeren we strijd (onder andere door de DevOops-conferentie te organiseren).
Zeker, naast de systeembeheerders die zichzelf āDevOpsā noemen, zijn er ook andere deelnemers ā zoals professionele SRE's of Infrastructure-as-Code ontwikkelaars.
Waar mensen zich eigenlijk mee bezighouden in DevOps
Dus je wilt verder komen in het leren en toepassen van DevOps-praktijken. Maar hoe doe je dat, waar moet je kijken? Het is duidelijk dat je niet blindelings de populaire zoekwoorden moet volgen.
Als er werk is, moet iemand dat doen. We hebben al vastgesteld dat het niet de āDevOps ingenieursā zijn, dus wie is het dan? Het lijkt beter om dit niet in termen van functies te formuleren, maar in termen van specifieke werkgebieden.
Ten eerste kun je je bezighouden met het hart van DevOps ā processen en cultuur. Cultuur is geen snel of gemakkelijk iets, en hoewel dit traditioneel de verantwoordelijkheid van leidinggevenden is, spelen iedereen, van programmeurs tot systeembeheerders, op de een of andere manier een rol hierin. Een paar maanden geleden zei Tim Lister :
āCultuur wordt gevormd door de belangrijkste waarden van een organisatie. Gewoonlijk merken mensen dit niet op, maar wij, die jarenlang in de consultancy hebben gewerkt, zijn eraan gewend dit te merken. Je komt een bedrijf binnen en binnen enkele minuten begin je te voelen wat er aan de hand is. We noemen dit de āsfeerā. Soms is deze sfeer echt goed. Soms veroorzaakt het misselijkheid. (ā¦) Je kunt de cultuur niet veranderen voordat de waarden en overtuigingen die ten grondslag liggen aan specifieke handelingen zijn erkend. Gedrag is gemakkelijk te observeren, maar overtuigingen zoeken is moeilijk. DevOps is precies een uitstekend voorbeeld van hoe alles complexer en complexer wordt.ā
Er is natuurlijk ook een technische kant aan de vraag. Als je nieuwe code een maand voor testen binnenkomt, maar deze pas na een jaar in de release terechtkomt, en je kunt dit proces fysiek niet versnellen - dan kun je de beste praktijken misschien nooit bereiken. Goede praktijken worden ondersteund door goede tools. Door het idee van Infrastructure-as-Code in gedachten te houden, kun je alles gebruiken, van AWS CloudFormation en Terraform tot Chef-Ansible-Puppet. Het is belangrijk om dit allemaal te weten en te kunnen; dit vereist al een behoorlijke engineeringdiscipline. Verwissel oorzaak en gevolg niet: eerst werk je volgens de principes van SRE en pas daarna pas je deze principes toe in de vorm van specifieke technische oplossingen. SRE is een zeer complexe methodologie die niet alleen vertelt hoe je Jenkins configureert, maar die vijf belangrijke principes behandelt:
- Verbeteren van de samenwerking tussen rollen en afdelingen
- Het accepteren van fouten als een onmiskenbaar deel van het werk
- Stapsgewijze implementatie van veranderingen
- Gebruik van tooling en andere automatisering
- Alles meten wat gemeten kan worden
Dit is niet slechts een verzameling uitspraken, maar een concrete . Bijvoorbeeld, op de weg naar het accepteren van fouten moet er nagedacht worden over risico's, de beschikbaarheid en onbeschikbaarheid van diensten gemeten worden met behulp van iets als SLI () en SLO (), leren postmortems te schrijven en ervoor zorgen dat het niet eng is om ze te schrijven.
In de discipline SRE is het gebruik van tools slechts Ć©Ć©n aspect van succes, maar een niet onbelangrijk aspect. We moeten voortdurend technisch ontwikkelen en kijken naar wat er in de wereld gebeurt en hoe dit in ons werk kan worden toegepast.
Cloud Native-oplossingen zijn momenteel zeer populair. Volgens het moderne begrip van de Cloud Native Computing Foundation stellen Cloud Native-technologieƫn organisaties in staat om schaalbare applicaties te ontwikkelen en te draaien in moderne, dynamische omgevingen zoals publieke, private en hybride cloudomgevingen. Voorbeelden hiervan zijn containers, service meshes, microservices, onveranderlijke infrastructuren en declaratieve API's. Al deze technieken zorgen ervoor dat losgekoppelde systemen elastisch, beheersbaar en goed observeerbaar blijven. Goede automatisering stelt ingenieurs in staat om grote veranderingen vaak door te voeren met voorspelbare resultaten, zonder dat dit een ondraaglijke klus wordt. Dit alles wordt ondersteund door een stack van bekende tools zoals Docker en Kubernetes.
Deze complexe en uitgebreide definitie is afkomstig uit een ingewikkeld vakgebied. Aan de ene kant wordt beweerd dat nieuwe wijzigingen in dit systeem relatief eenvoudig moeten kunnen worden toegevoegd. Aan de andere kant moet je begrijpen hoe je een container-gebaseerde omgeving creĆ«ert waarin losgekoppelde services op een software-gedefinieerde infrastructuur leven en daar met behulp van continue CI/CD worden geleverd, en hoe je DevOps-praktijken om deze hele aanpak heen opzet ā waarbij ervaring op dit gebied cruciaal is.
Wat moeten we met dit alles doen?
Iedereen heeft zijn eigen aanpak voor deze problemen: je kunt bijvoorbeeld reguliere vacatures plaatsen om de cirkel te doorbreken. Het is ook belangrijk om te begrijpen wat termen als DevOps en Cloud Native betekenen en deze correct en betekenisvol te gebruiken. Je kunt je verder ontwikkelen in DevOps en door je eigen voorbeeld de juiste benaderingen demonstreren.
Wij organiseren een conferentie , die de mogelijkheid biedt om dieper in te gaan op de onderwerpen waar we het zojuist over hadden. Hiervoor zijn er verschillende groepen presentaties:
- Processen en cultuur;
- Site Reliability Engineering;
- Cloud Native;
Hoe kies je waar te gaan? Hier is een subtiel punt. Enerzijds gaat DevOps over samenwerking, en we hopen echt dat je naar lezingen uit verschillende blokken gaat. Aan de andere kant, als je een ontwikkelingsleider bent die naar de conferentie is gekomen om zich op Ć©Ć©n specifieke taak te concentreren, dan beperkt niemand je ā het zal duidelijk een blok zijn over processen en cultuur. Vergeet niet dat je na de conferentie toegang hebt tot de opnames (na het invullen van het feedbackformulier), zodat je altijd later naar minder belangrijke lezingen kunt kijken.
Het is duidelijk dat je op de conferentie niet tegelijkertijd naar drie tracks kunt gaan, daarom stellen we het programma zo samen dat er in elke tijdslot onderwerpen zijn voor ieders smaak.
Het enige dat je nu nog moet begrijpen, is wat te doen als je een DevOps-engineer bent! Probeer eerst te bepalen wat je eigenlijk doet. Meestal wordt dit woord gebruikt voor:
- Ontwikkelaars die zich bezighouden met infrastructuur. Voor jou zullen groepen lezingen over SRE en Cloud Native het meest geschikt zijn.
- Systeembeheerders. Dit is ingewikkelder. DevOops gaat niet over systeemadministratie. Gelukkig zijn er veel geweldige conferenties, boeken, artikelen, video's op internet, enzovoort over systeemadministratie. Aan de andere kant, als je geĆÆnteresseerd bent in het begrijpen van cultuur en processen, het bestuderen van cloudtechnologieĆ«n en details van het leven met Cloud Native, dan zijn we blij je te zien! Denk hier eens over na: je werkt als administrator, maar wat ga je daarna doen? Om niet onverwacht in een onplezierige situatie te belanden, is het verstandig om nu al te leren.
Er is nog een andere optie: je houdt vol en blijft beweren dat je precies een DevOps-engineer bent en niets anders, wat dat ook betekent. Dan moeten we je teleurstellen, DevOops is een conferentie die niet voor DevOps-engineers is!
Dia uit in MĆ¼nchen
DevOops 2020 Moskou vindt plaats op 29-30 april in Moskou, tickets zijn nu al beschikbaar .
Bovendien kun je tot 8 februari. Houd er rekening mee dat je bij het invullen van het formulier de doelgroep moet selecteren die het meeste voordeel uit jouw lezing zal halen (er is een verrassing verstopt in de lijst).
Bron: habr.com
