Op dit moment is dit misschien wel de duurste positie op de markt. De hype rond 'DevOps' ingenieurs overstijgt alle denkbare grenzen, en dan vooral met Senior DevOps ingenieurs.
Ik werk als leidinggevende van de afdeling integratie en automatisering, raad de Engelse afkorting eens — DevOps Manager. Weerspiegelt die Engelse afkorting onze dagelijkse werkzaamheden? Waarschijnlijk niet, maar de Russische variant is in dit geval nauwkeuriger. Gezien mijn functie is het natuurlijk nodig dat ik toekomstige teamleden interview en in het afgelopen jaar heb ik ongeveer 50 mensen gesproken, en nog eens zoveel zijn afgevallen in de voorselectie met mijn medewerkers.
We zijn nog steeds op zoek naar collega's, omdat er achter het label DevOps een zeer grote laag van verschillende soorten ingenieurs schuilgaat.
Wat hieronder staat is mijn persoonlijke mening, jullie zijn niet verplicht om het ermee eens te zijn, maar ik vermoed dat het een nieuw perspectief op het onderwerp kan bieden. Ondanks het risico om in de ongenade te vallen, publiceer ik mijn mening omdat ik vind dat deze een plek verdient.
Bedrijven hebben verschillende visies op wie DevOps ingenieurs zijn en voor het snel inhuren van middelen hangen ze dit label aan iedereen. De situatie is behoorlijk vreemd, aangezien bedrijven bereid zijn om onrealistische beloningen aan deze mensen te betalen, terwijl ze meestal gewoon een tooladministrator voor hun geld krijgen.
Maar wie zijn eigenlijk DevOps ingenieurs?
Laten we beginnen met de geschiedenis van zijn ontstaan — Development Operations kwam voort uit een extra stap naar optimalisatie van de samenwerking binnen kleine teams om de snelheid van productontwikkeling te verhogen, als een verwacht gevolg. Het idee was om het ontwikkelingsteam te versterken met kennis over processen en benaderingen in het beheer van de productomgeving. Met andere woorden, een ontwikkelaar moet begrijpen en weten hoe zijn product functioneert onder verschillende omstandigheden, moet weten hoe hij zijn product moet implementeren en welke kenmerken van de omgeving geoptimaliseerd moeten worden om de prestaties te verbeteren. Zo ontstonden er in de loop van de tijd ontwikkelaars met een DevOps-aanpak. DevOps-ontwikkelaars schreven bouw- en verpakkingsscripts om hun werkzaamheden en de werking van de productieomgeving te vereenvoudigen. Echter, de complexiteit van de architectuur van oplossingen en de wederzijdse invloed van de infrastructuurcomponenten begonnen na verloop van tijd de werkprestaties van de omgevingen te verslechteren, waarbij elke iteratie steeds diepgaander begrip van bepaalde componenten vereiste, wat de productiviteit van de ontwikkelaar verminderde door de extra inspanningen die nodig waren om de componenten en het afstemmen van systemen op specifieke taken te begrijpen. De kosten van een ontwikkelaar stegen, de kosten van het product samen met hem, terwijl de eisen aan nieuwe ontwikkelaars in het team stegen; zij moesten ook de verantwoordelijkheden van de 'ster' van de ontwikkeling dekken, en uiteraard werden 'sterren' steeds moeilijker bereikbaar. Het is ook vermeldenswaard dat, naar mijn ervaring, weinigen van de ontwikkelaars geïnteresseerd zijn in de specificiteit van hoe pakketten door de kernel van het besturingssysteem worden behandeld, de regels voor pakketrouting, en de aspecten van hostbeveiliging. Een logische stap was om een beheerder aan te stellen, die bekend was met deze zaken, en dergelijke verantwoordelijkheden aan hem toe te vertrouwen, wat, dankzij zijn ervaring, toeliet om dezelfde prestaties te behalen tegen lagere kosten in vergelijking met de kosten van een 'ster' van de ontwikkeling. Dergelijke beheerders werden in het team geplaatst en hun belangrijkste taak was het beheer van test- en productieomgevingen, volgens de regels van het specifieke team, met middelen die specifiek voor dit team waren toegewezen. Zo kwamen DevOps in de meeste gevallen tot stand.
Gedeeltelijk of volledig, na verloop van tijd begonnen systeembeheerders de behoeften van dit specifieke ontwikkelingsteam te begrijpen, om het leven van ontwikkelaars en testers te vergemakkelijken, hoe een update uit te rollen zonder op een vrijdagavond in het kantoor te moeten blijven om deploymentfouten te verhelpen. De tijd verstreek; nu werden systeembeheerders de 'sterren' die begrepen wat ontwikkelaars willen. Om de impact te minimaliseren, begonnen beheertools op te duiken, en iedereen herinnerde zich de oude en betrouwbare methodes voor OS-isolatie, die hielpen om de beveiligingsvereisten, netwerkbeheer en de configuratie van de host als geheel te minimaliseren en, als gevolg daarvan, de vereisten voor de nieuwe 'sterren' te verlagen.
Er kwam een 'geweldig' iets op de markt — docker. Waarom geweldig? Simpelweg omdat het creëren van isolatie in chroot of jail, net als OpenVZ, niet-triviale kennis van het besturingssysteem vereiste, terwijl de tool nu in staat is om eenvoudig een geïsoleerde applicatieomgeving op een bepaalde host aan te maken met alles wat nodig is, en de macht weer terug te geven aan de ontwikkelaars, terwijl de systeembeheerder zich alleen hoefde bezig te houden met één host, zijn veiligheid en hoge beschikbaarheid waarborgend — een logische vereenvoudiging. Maar de vooruitgang staat niet stil en systemen worden opnieuw steeds complexer, met meer en meer componenten; één host voldoet niet langer aan de systeembehoeften en het is noodzakelijk om clusters op te bouwen. We keren weer terug naar systeembeheerders die in staat zijn om deze systemen op te bouwen.
Cyclisch, verschijnen er verschillende systemen die de ontwikkeling en/of administratie vergemakkelijken; er verschijnen orchestration systemen die, zolang er niet van het standaardproces wordt afgeweken, eenvoudig te gebruiken zijn. Microservicesarchitectuur is ook ontstaan met het doel alles hierboven beschreven te vereenvoudigen — minder onderlinge afhankelijkheden, eenvoudiger te beheren. In mijn ervaring heb ik niet de volledige microservicesarchitectuur meegemaakt; ik zou zeggen 50-50 — 50 procent microservices, zwarte dozen, wat erin kwam werd verwerkt, en de andere 50 — een gescheurde monolith, diensten die niet afzonderlijk van andere componenten konden functioneren. Dit legt opnieuw beperkingen op aan het kennisniveau van zowel ontwikkelaars als beheerders.
Dergelijke 'schommelingen' van expertiseniveaus van een bepaalde bron duren nog steeds voort. Maar we zijn even afgeleid, er zijn verschillende punten die het waard zijn om belicht te worden.
Build Engineer/Release Engineer
Zeer gespecialiseerde ingenieurs die zijn ontstaan als een middel om de processen van softwarebouw en -releases te standaardiseren. Tijdens de invoering van de massale Agile-methodologie leken ze niet meer gevraagd te worden, maar dat is verre van waar. Deze specialisatie is ontstaan om specifiek de bouw en levering van software op grote schaal te standaardiseren, d.w.z. door gebruik te maken van standaardtechnieken voor alle producten van het bedrijf. Met de opkomst van DevOps hebben ontwikkelaars gedeeltelijk functies verloren, omdat juist ontwikkelaars het product voorbereiden voor levering, en gezien de veranderende infrastructuur en de benadering van zo snel mogelijke leveringen, ongeacht de kwaliteit, zijn ze in de loop der tijd precies het obstakel voor veranderingen geworden, omdat het volgen van kwaliteitsnormen onvermijdelijk de leveringen vertraagt. Zo is geleidelijk een deel van de functionaliteit van Build/Release-ingenieurs verschoven naar de schouders van systeembeheerders.
Ops'ies zo verschillend
We gaan verder en opnieuw duwen een breed scala aan verantwoordelijkheden en een gebrek aan gekwalificeerd personeel ons naar strikte specialisatie, als paddestoelen na de regen, verschijnen verschillende Operations:
- TechOps — systeembeheerders aka HelpDesk Engineer
- LiveOps — systeembeheerders die voornamelijk verantwoordelijk zijn voor productieve omgevingen
- CloudOps — systeembeheerders die zich specialiseren in openbare 'clouds' zoals Azure, AWS, GCP, enz.
- PlatOps/InfraOps/SysOps — systeembeheerders van infrastructuur.
- NetOps — netwerkbeheerders
- SecOps — systeembeheerders die zich specialiseren in informatiebeveiliging — PCI-compliance, CIS-compliance, patching, enz.
DevOps — (in theorie) een persoon die vanuit ervaring alle fasen van de ontwikkelingscyclus begrijpt — ontwikkeling, testen, en de architectuur van het product kent, in staat is om veiligheidsrisico's te beoordelen, bekend is met automatiseringsmethoden en -middelen, op zijn minst op een hoog niveau, en ook begrijpen kan wat de ondersteuning vóór en na de release van een product inhoudt. Een persoon die kan optreden als een pleitbezorger van zowel Operations als Development, wat de basis legt voor een gunstige samenwerking tussen deze twee pijlers. Iemand die de processen van teamwerkplanning en het beheren van klantverwachtingen begrijpt.
Om dit soort werkzaamheden en verantwoordelijkheden uit te voeren, moet deze persoon over middelen beschikken die niet alleen de processen van ontwikkeling en testen beheren, maar ook de infrastructuur van het product en de planning van middelen. DevOps in deze context kan zich niet beperken tot IT, R&D of zelfs PMO; hij moet invloed uitoefenen in al deze gebieden — de technisch directeur van het bedrijf, Chief Technical Officer.
Is dat ook het geval in uw bedrijf? — Ik betwijfel het. In de meeste gevallen behoren ze tot IT of R&D.
Een gebrek aan middelen en invloed op zelfs één van deze drie werkgebieden zal de focus verschuiven naar de plaats waar deze veranderingen het gemakkelijkst kunnen worden toegepast, zoals het opleggen van technische beperkingen aan releases vanwege 'rommelige' code volgens de gegevens van statische analysetools. Dit gebeurt wanneer PMO een strikte deadline stelt voor de levering van functionaliteit, R&D niet in staat is om een kwalitatief resultaat binnen deze termijn te leveren en het levert wat het kan, met refactoren voor later, DevOps die tot IT behoort, blokkeert de release met technische middelen. Een gebrek aan mandaat om de situatie te veranderen leidt, in het geval van verantwoordelijke medewerkers, tot hyperverantwoordelijkheid voor zaken waar ze geen invloed op kunnen uitoefenen, vooral als deze medewerkers de fouten begrijpen en zien en weten hoe ze die kunnen verhelpen — 'Geluk is onwetendheid', wat op zijn beurt leidt tot burn-out en het verlies van deze medewerkers.
De DevOps-bronmarkten
Laten we eens kijken naar enkele vacatures voor de positie van DevOps van verschillende bedrijven.
We zijn bereid om met u af te spreken als u:
- Zabbix beheerst en weet wat Prometheus is;
- Iptables;
- Aspiran BASH;
- Professor Ansible;
- Guru Linux;
- Kun je debuggen en samen met ontwikkelaars problemen in applicaties (php/java/python) opsporen;
- Routing veroorzaakt bij jou geen paniek;
- Je besteedt aanzienlijke aandacht aan systeembeveiliging;
- Je maakt back-ups van 'alles en nog wat', en herstelt dit 'alles en nog wat' succesvol;
- Je weet het systeem zo in te stellen dat je het maximale uit het minimale haalt;
- Je stelt replicaties in voordat je naar bed gaat op Postgres en MySQL;
- CI/CD-configuratie en -correctie is voor jou zo noodzakelijk als ontbijt/lunch/diner.
- Je hebt ervaring met AWS;
- Je bent bereid om samen met het bedrijf te groeien;
Dus:
- van 1 tot 6 - systeemadministator
- 7 - een beetje netwerktechnisch beheer, wat ook past binnen de rol van een Middle systeemadministrator
- 8 - een beetje beveiliging, wat noodzakelijk is voor een systeemadministrator op het niveau van Middle
- 9-11 - Middle Systeemadministrator
- 12 - Afhankelijk van de gestelde taken ofwel Middle Systeemadministrator ofwel Build Engineer
- 13 - Virtualisatie - Middle Systeemadministrator, ofwel de zogenaamde CloudOps, uitgebreide kennis specifiek van diensten van het desbetreffende hosting platform, voor een effectieve besteding van middelen en het verminderen van de belasting van onderhoud
Samenvattend kan worden gezegd dat voor deze vacature een Middle/Senior Systeemadministrator voldoende is.
Overigens, het is niet nodig om beheerders sterk te scheiden in Linux/Windows. Ik begrijp natuurlijk dat de diensten en systemen van deze twee werelden verschillen, maar de basis is voor allemaal hetzelfde en elke zichzelf respecterende beheerder is bekend met zowel het een als het ander, en zelfs als niet bekend, zal het voor een competente administrator geen moeite zijn om dit te leren.
Laten we een andere vacature bekijken:
- Ervaring met het bouwen van systemen met hoge belasting;
- Uitstekende kennis van besturingssystemen Linux, algemene systeemsoftware en webstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Ervaring met virtualisatiesystemen (KVM, VMWare, LXC/Docker);
- Beheersing van script-talen;
- Begrip van de werking van netwerken en netwerprotocollen;
- Begrip van de principes van het opbouwen van fouttolerante systemen;
- Zelfstandigheid en initiatief;
Laten we bekijken:
- 1 - Senior Systeemadministrator
- 2 - Afhankelijk van de betekenis die in deze stack wordt geïnvesteerd - Middle/Senior Systeemadministrator
- 3 - Werkervaring kan ook betekenen - 'Cluster heb ik niet opgezet, maar heb virtuele machines aangemaakt en beheerd, had één Docker-host, toegang tot containers geregeld' - Middle Systeemadministrator
- 4 — Junior System Administrator — ja, een admin die niet in staat is om elementaire automatiseringsscripts te schrijven, ongeacht de taal, is geen admin — gewoon een computergebruiker.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Samenvattend — Middle/Senior System Administrator
Nog een:
- Ervaring met devops;
- Ervaring met het gebruik van een of meerdere producten voor het opzetten van CI/CD-processen. Gitlab CI heeft een voordeel;
- Werk met containers en virtualisatie; Als je Docker hebt gebruikt – goed, en als je k8s hebt gebruikt – geweldig!
- Ervaring in een agile team;
- Kennis van een programmeertaal;
Laten we kijken:
- 1 — Hmm... Wat bedoelen ze ermee? =) Waarschijnlijk weten ze zelf niet wat daarop slaat.
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Soft skills, daar zullen we voorlopig niet op ingaan, hoewel Agile weer iets is dat op verschillende manieren wordt geïnterpreteerd, afhankelijk van wat het beste uitkomt.
- 5 — Te vaag — dit kan een scripttaal zijn of een gecompileerde taal. Interessant, zou het ze bevallen als ik op school met Pascal en Basic schreef? =)
Ik wil ook een opmerking maken over punt 3, ter verduidelijking waarom dit punt door een systeembeheerder wordt gedekt. Kubernetes is slechts een orkestratie, een tool die directe commando's naar netwerken en virtualisatie/isolatiedrivers omzet in een paar commando's en het mogelijk maakt om abstracter met hen te communiceren, dat is alles. Neem bijvoorbeeld het 'build framework' Make, waarvan ik, terzijde, niet denk dat het echt een framework is. Ja, ik weet van de trend om Make overal te gebruiken, waar het nodig is en waar het niet nodig is — het verpakken van Maven in Make bijvoorbeeld, serieus?
In wezen is Make gewoon een wrapper bovenop shell, die juist de commando's voor compilatie, linkage en compilatie-omgeving vereenvoudigt, net als k8s.
Eens, interviewde ik een jongen die k8s in zijn werk bovenop OpenStack gebruikte, en hij vertelde me hoe hij services ermee uitrolde, maar toen ik specifiek naar OpenStack vroeg, bleek dat dit werd beheerd en eveneens werd opgebouwd door systeembeheerders. Denk je echt dat iemand die OpenStack opzet, ongeacht welke platform hij erachter gebruikt, niet in staat is om k8s te gebruiken? =)
Deze sollicitant is in werkelijkheid geen DevOps, maar gewoon een systeembeheerder, en om het precies te zeggen, een Kubernetes Administrator.
We sommen opnieuw samen — Middle/Senior System Administrator zal voor hen voldoende zijn.
Hoeveel moet je in grammen wegen?
Het aanbod van salarissen voor de genoemde vacatures ligt tussen de 90k-200k
Laten we nu een vergelijking maken tussen de financiële beloningen van Systeembeheerders en DevOps Engineers.
In principe kan voor de eenvoud de ervaring in niveaus worden ingedeeld, hoewel dit niet exact zal zijn, is het voldoende voor de doeleinden van dit artikel.
Ervaring:
- tot 3 jaar — Junior
- tot 6 jaar — Middle
- meer dan 6 jaar — Senior
De website voor het zoeken naar werknemers biedt aan:
Systeembeheerders:
- Junior — 2 jaar — 50k RUB.
- Middle — 5 jaar — 70k RUB.
- Senior — 11 jaar — 100k RUB.
DevOps Engineers:
- Junior — 2 jaar — 100k RUB.
- Middle — 3 jaar — 160k RUB.
- Senior — 6 jaar — 220k RUB.
Voor de ervaring van DevOps’ers werd rekening gehouden met elke ervaring die enigszins met SDLC te maken had.
Hieruit volgt dat bedrijven eigenlijk geen DevOps’ers nodig hebben, en dat ze minstens 50 procent van de oorspronkelijk geplande uitgaven hadden kunnen besparen door gewoon een Systeembeheerder in te huren. Bovendien zouden ze de verantwoordelijkheden van de gezochte persoon duidelijker hebben kunnen definiëren en sneller aan de behoefte hebben kunnen voldoen. We moeten ook niet vergeten dat een duidelijke scheiding van verantwoordelijkheden de vereisten voor personeel kan verlagen en een gunstigere sfeer in het team kan creëren, vanwege het ontbreken van overlappingen. In de meeste vacatures staan utility- en DevOps-labels echter vermeld, zonder dat ze werkelijk vereisten voor een DevOps Engineer bevatten, maar alleen verzoeken naar een toolbeheerder.
Het opleidingsproces van DevOps-engineers is ook beperkt tot een set specifieke taken en utilities en biedt geen algemeen begrip van processen en hun afhankelijkheden. Het is natuurlijk goed als iemand met Terraform AWS EKS kan implementeren, samen met een Fluentd sidecar in deze cluster en een AWS ELK-stack voor het loggingsysteem in 10 minuten, met slechts één commando in de console, maar als hij het principe van logverwerking niet begrijpt en waarvoor deze nodig zijn, en niet weet hoe hij metrics daarvan moet verzamelen en de degradatie van de service moet volgen, dan is hij nog steeds diegene die alleen een aantal utilities kan gebruiken.
Vraag creëert echter aanbod, en we zien een extreem oververhitte markt voor de positie van DevOps, waar de eisen niet overeenkomen met de werkelijke rol, maar alleen systeembeheerders in staat stellen meer te verdienen.
Dus wie zijn ze? DevOps’ers of hebzuchtige systeembeheerders? =)
Hoe nu verder?
Werkgevers - verduidelijk de vereisten en zoek specifiek naar degenen die nodig zijn, in plaats van te micromanageren met labels. Als je niet weet wat DevOps doen, heb je ze in dat geval niet nodig.
Werknemers - Blijf leren. Verbeter voortdurend je kennis, kijk naar het totaalbeeld van de processen en volg de weg naar je doel. Je kunt worden wie je wilt, je moet alleen je best doen.
Bron: habr.com
