Op dit moment is dit vrijwel de duurste positie op de markt. De ophef rond “DevOps”-ingenieurs overstijgt alle denkbare grenzen, en nog erger bij Senior DevOps-ingenieurs.
Ik werk als hoofd van de afdeling integratie en automatisering, denk aan de Engelse decodering - DevOps Manager. Het is onwaarschijnlijk dat het Engelse transcript onze dagelijkse activiteiten weerspiegelt, maar de Russische versie is in dit geval nauwkeuriger. Vanwege de aard van mijn activiteit is het normaal dat ik toekomstige leden van mijn team moet interviewen, en het afgelopen jaar zijn er ongeveer 50 mensen via mij gepasseerd, en hetzelfde aantal is op de prescreening met mijn medewerkers uitgeschakeld.
We zijn nog steeds op zoek naar collega’s, want achter het DevOps-label schuilt een hele grote laag van verschillende soorten engineers.
Alles wat hieronder staat is mijn persoonlijke mening, je hoeft het er niet mee eens te zijn, maar ik geef toe dat het wat kleur zal toevoegen aan je houding ten opzichte van het onderwerp. Ondanks het risico uit de gratie te raken, publiceer ik mijn mening omdat ik geloof dat deze een plek heeft.
Bedrijven hebben verschillende opvattingen over wie DevOps-ingenieurs zijn en om snel een resource in dienst te kunnen nemen, hangen ze dit label aan iedereen op. De situatie is nogal vreemd, aangezien bedrijven bereid zijn om onrealistische vergoedingen aan deze mensen te betalen, waarbij ze in de meeste gevallen een toolbeheerder voor hen ontvangen.
Dus wie zijn DevOps-ingenieurs?
Laten we beginnen met de geschiedenis van zijn verschijning - Development Operations verscheen als een nieuwe stap in de richting van het optimaliseren van de interactie in kleine teams om de snelheid van de productproductie te verhogen, als een verwacht gevolg. Het idee was om het ontwikkelteam te versterken met kennis van procedures en benaderingen bij het beheren van de productomgeving. Met andere woorden: de ontwikkelaar moet begrijpen en weten hoe zijn product onder bepaalde omstandigheden werkt, hij moet begrijpen hoe hij zijn product moet inzetten, welke kenmerken van de omgeving kunnen worden aangepast om de prestaties te verbeteren. Dus er verschenen een tijdje ontwikkelaars met een DevOps-aanpak. DevOps-ontwikkelaars schreven build- en package-scripts om hun activiteiten en de prestaties van de productieomgeving te vereenvoudigen. De complexiteit van de oplossingsarchitectuur en de wederzijdse invloed van infrastructuurcomponenten begonnen in de loop van de tijd echter de prestaties van de omgevingen te verslechteren; bij elke iteratie was een steeds dieper inzicht in bepaalde componenten vereist, waardoor de productiviteit van de ontwikkelaar daalde vanwege de extra kosten voor het begrijpen van de componenten en afstemmingssystemen voor een specifieke taak. De eigen kosten van de ontwikkelaar groeiden, de kosten van het product daarmee, de vereisten voor nieuwe ontwikkelaars in het team stegen sterk, omdat ze ook de verantwoordelijkheden van de ontwikkelingsster moesten dekken, en natuurlijk werden de "sterren" minder en minder beschikbaar. Het is ook vermeldenswaard dat, naar mijn ervaring, weinig ontwikkelaars geïnteresseerd zijn in de specifieke kenmerken van pakketverwerking door de kernel van het besturingssysteem, pakketrouteringsregels en host-beveiligingsaspecten. De logische stap was om een beheerder aan te trekken die hiermee bekend is en hem soortgelijke verantwoordelijkheden toe te wijzen, wat het dankzij zijn ervaring mogelijk maakte om dezelfde indicatoren te bereiken tegen lagere kosten vergeleken met de kosten van een “ster” -ontwikkeling. Dergelijke beheerders werden in een team geplaatst en zijn hoofdtaak was het beheren van test- en productieomgevingen, volgens de regels van een specifiek team, waarbij de middelen aan dit specifieke team werden toegewezen. Dit is hoe DevOps in feite in de hoofden van de meerderheid verscheen.
Gedeeltelijk of volledig begonnen deze systeembeheerders in de loop van de tijd de behoeften van dit specifieke team op het gebied van ontwikkeling te begrijpen, hoe ze het leven gemakkelijker konden maken voor ontwikkelaars en testers, hoe ze een update konden uitrollen en niet op vrijdag moesten overnachten in op kantoor, waarbij implementatiefouten worden gecorrigeerd. De tijd verstreek en nu waren de “sterren” systeembeheerders die begrepen wat ontwikkelaars wilden. Om de impact te minimaliseren begonnen er beheerhulpprogramma's te verschijnen; iedereen herinnerde zich de oude en betrouwbare methoden voor het isoleren van het besturingssysteemniveau, waardoor het mogelijk werd de vereisten voor beveiliging, beheer van het netwerkgedeelte en de hostconfiguratie als een minimum te minimaliseren. geheel en als gevolg daarvan de vereisten voor nieuwe “sterren” verminderen.
Er is een "wonderbaarlijk" ding verschenen: havenarbeider. Waarom geweldig? Ja, alleen omdat het creëren van isolatie in een chroot of jail, evenals OpenVZ, niet-triviale kennis van het besturingssysteem vereist. Met het hulpprogramma kun je daarentegen eenvoudig een geïsoleerde applicatieomgeving op een bepaalde host creëren met alles wat nodig is binnen handbereik weer over de teugels van de ontwikkeling, en de systeembeheerder kan het slechts met slechts één host beheren, waardoor de veiligheid en hoge beschikbaarheid ervan worden gegarandeerd - een logische vereenvoudiging. Maar de vooruitgang staat niet stil en systemen worden weer steeds complexer, er komen steeds meer componenten bij, één host voldoet niet meer aan de eisen van het systeem en er moeten clusters gebouwd worden, we keren weer terug naar systeembeheerders die dat wel zijn deze systemen kunnen bouwen.
Cyclus na cyclus verschijnen er verschillende systemen die de ontwikkeling en/of het beheer vereenvoudigen, er verschijnen orkestratiesystemen die, totdat je moet afwijken van het standaardproces, eenvoudig te gebruiken zijn. Er verscheen ook microservice-architectuur met als doel alles wat hierboven is beschreven te vereenvoudigen: minder relaties, gemakkelijker te beheren. In mijn ervaring heb ik geen volledig microservice-architectuur gevonden, ik zou zeggen dat 50 tot 50 - 50 procent van de microservices, zwarte dozen, binnenkwam en verwerkt naar buiten kwam, de andere 50 zijn een verscheurde monoliet, services die niet los van andere kunnen werken componenten. Dit alles legde opnieuw beperkingen op aan het kennisniveau van zowel ontwikkelaars als beheerders.
Soortgelijke ‘schommelingen’ in het niveau van de deskundige kennis van een bepaalde hulpbron blijven tot op de dag van vandaag bestaan. Maar we dwalen een beetje af, er zijn veel punten die de moeite waard zijn om te benadrukken.
Bouwingenieur/Releaseingenieur
Zeer zeer gespecialiseerde ingenieurs die naar voren kwamen als een middel om software-bouwprocessen en -releases te standaardiseren. Tijdens het proces van de wijdverspreide introductie van Agile lijkt het erop dat er niet langer vraag naar is, maar dit is verre van het geval. Deze specialisatie verscheen als een middel om de assemblage en levering van software op industriële schaal te standaardiseren. gebruik van standaardtechnieken voor alle bedrijfsproducten. Met de komst van DevOps verloren ontwikkelaars gedeeltelijk hun functies, omdat het de ontwikkelaars waren die het product begonnen voor te bereiden voor levering, en gezien de veranderende infrastructuur en de aanpak om zo snel mogelijk te leveren, zonder rekening te houden met de kwaliteit, in de loop van de tijd een stop voor veranderingen, omdat het naleven van kwaliteitsnormen onvermijdelijk de leveringen vertraagt. Geleidelijk verplaatste een deel van de functionaliteit van Build/Release-ingenieurs zich dus naar de schouders van systeembeheerders.
Operaties zijn zo verschillend
We gaan verder en opnieuw dwingt de aanwezigheid van een groot aantal verantwoordelijkheden en het gebrek aan gekwalificeerd personeel ons tot strikte specialisatie, zoals paddenstoelen na de regen verschijnen er verschillende operaties:
- TechOps - enikey systeembeheerders oftewel HelpDesk Engineer
- LiveOps - systeembeheerders die primair verantwoordelijk zijn voor productieomgevingen
- CloudOps - systeembeheerders gespecialiseerd in openbare clouds Azure, AWS, GCP, enz.
- PlatOps/InfraOps/SysOps - infrastructuursysteembeheerders.
- NetOps - netwerkbeheerders
- SecOps - systeembeheerders gespecialiseerd in informatiebeveiliging - PCI-compliance, CIS-compliance, patching, etc.
DevOps is (in theorie) een persoon die uit de eerste hand alle processen van de ontwikkelingscyclus begrijpt - ontwikkelen, testen, de productarchitectuur begrijpt, beveiligingsrisico's kan inschatten, bekend is met benaderingen en automatiseringstools, tenminste op een hoog niveau. niveau begrijpt daarnaast ook de pre- en post-processing van productrelease-ondersteuning. Een persoon die in staat is om op te treden als pleitbezorger voor zowel Operatie als Ontwikkeling, wat een gunstige samenwerking tussen deze twee pijlers mogelijk maakt. Begrijpt de processen van het plannen van werk door teams en het beheren van klantverwachtingen.
Om dit soort werk en verantwoordelijkheden uit te voeren, moet deze persoon over de middelen beschikken om niet alleen de ontwikkelings- en testprocessen te beheren, maar ook het beheer van de productinfrastructuur en de resourceplanning. In dit opzicht kan DevOps niet in de IT, in R&D of zelfs in het PMO worden gelokaliseerd; het moet invloed hebben op al deze gebieden: de technisch directeur van het bedrijf, de Chief Technical Officer.
Is dit binnen uw bedrijf het geval? - Ik betwijfel. In de meeste gevallen is dit IT of R&D.
Gebrek aan middelen en het vermogen om invloed uit te oefenen op ten minste één van deze drie activiteitengebieden zal het gewicht van de problemen verschuiven naar gebieden waar deze veranderingen gemakkelijker kunnen worden toegepast, zoals de toepassing van technische beperkingen op releases in verband met ‘vuile’ code volgens statische codes. analysesystemen. Dat wil zeggen, wanneer de PMO een strikte deadline stelt voor het vrijgeven van functionaliteit, kan R&D binnen deze deadlines geen kwalitatief hoogstaand resultaat opleveren en dit zo goed mogelijk produceren, refactoring voor later achterlatend, DevOps met betrekking tot IT blokkeert de vrijgave met technische middelen . Gebrek aan autoriteit om de situatie te veranderen, in het geval van verantwoordelijke werknemers, leidt tot de manifestatie van hyperverantwoordelijkheid voor datgene waar ze geen invloed op kunnen uitoefenen, vooral als deze werknemers fouten begrijpen en zien, en hoe ze deze kunnen corrigeren - "Geluk is onwetendheid", en als gevolg daarvan burn-out en verlies van deze werknemers.
DevOps-bronnenmarkt
Laten we eens kijken naar verschillende vacatures voor DevOps-posities van verschillende bedrijven.
Wij staan klaar om u te ontmoeten als u:
- Je bezit Zabbix en weet wat Prometheus is;
- Iptables;
- BASH PhD-student;
- Professor Ansible;
- Linux-goeroe;
- Weten hoe je debugging kunt gebruiken en samen met ontwikkelaars applicatieproblemen kunt opsporen (php/java/python);
- Routing maakt je niet hysterisch;
- Besteed veel aandacht aan systeembeveiliging;
- Maak een back-up van “van alles en nog wat”, en herstel ook dit “van alles en nog wat” met succes;
- Je weet het systeem zo te configureren dat je het maximale uit het minimum haalt;
- Replicatie instellen voordat u naar bed gaat op Postgres en MySQL;
- Het instellen en aanpassen van CI/CD is voor u net zo noodzakelijk als ontbijt/lunch/diner.
- Ervaring hebt met AWS;
- Klaar om mee te ontwikkelen met het bedrijf;
Dus:
- van 1 tot 6 - systeembeheerder
- 7 - een beetje netwerkbeheer, dat ook past bij de systeembeheerder, middenniveau
- 8 - een beetje beveiliging, wat verplicht is voor een systeembeheerder op middenniveau
- 9-11 – Middelste systeembeheerder
- 12 — Afhankelijk van de toegewezen taken, middensysteembeheerder of bouwingenieur
- 13 - Virtualisatie - Middle System Administrator, of de zogenaamde CloudOps, geavanceerde kennis van de diensten van een specifieke hostingsite, voor een efficiënt gebruik van fondsen en het verminderen van de onderhoudslast
Als we deze vacature samenvatten, kunnen we zeggen dat Middle/Senior System Administrator genoeg is voor de jongens.
Overigens moet je beheerders op Linux/Windows niet sterk verdelen. Natuurlijk begrijp ik dat de diensten en systemen van deze twee werelden verschillend zijn, maar de basis voor alles is hetzelfde en elke zichzelf respecterende beheerder is bekend met het een en het ander, en zelfs als hij er niet bekend mee is, zal hij dat wel doen. Het zal voor een competente beheerder niet moeilijk zijn om ermee vertrouwd te raken.
Laten we een andere vacature overwegen:
- Ervaring met het bouwen van hooglastsystemen;
- Uitstekende kennis van Linux OS, algemene systeemsoftware en webstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Ervaring met virtualisatiesystemen (KVM, VMWare, LXC/Docker);
- Vaardigheid in scripttalen;
- Inzicht in de werkingsprincipes van netwerkprotocolnetwerken;
- Inzicht in de principes van het bouwen van fouttolerante systemen;
- Onafhankelijkheid en initiatief;
Laten we eens kijken naar:
- 1 – Senior systeembeheerder
- 2 - Afhankelijk van de betekenis die in deze stapel wordt gestopt - Midden/Senior systeembeheerder
- 3 - Werkervaring, inclusief, kan betekenen: "Het cluster heeft geen virtuele machines gegenereerd, maar gemaakt en beheerd, er was één Docker-host, toegang tot containers was niet beschikbaar" - Midden-systeembeheerder
- 4 - Junior Systeembeheerder - ja, een beheerder die niet weet hoe hij basisautomatiseringsscripts moet schrijven, ongeacht de taal, geen beheerder - enikey.
- 5 - Middelste systeembeheerder
- 6 – Senior systeembeheerder
Samenvattend: midden/senior systeembeheerder
Nog een:
- Devops-ervaring;
- Ervaring met het gebruik van een of meer producten om CI/CD-processen te creëren. Gitlab CI zal een voordeel zijn;
- Werken met containers en virtualisatie; Als je docker hebt gebruikt, goed, maar als je k8s hebt gebruikt, geweldig!
- Ervaring met het werken in een agile team;
- Kennis van elke programmeertaal;
We zullen zien:
- 1 - Hmm... Wat bedoelen de jongens? =) Hoogstwaarschijnlijk weten ze zelf niet wat erachter verborgen zit
- 2 - Bouwingenieur
- 3 - Middelste systeembeheerder
- 4 - Soft skills, daar zullen we voorlopig niet over nadenken, hoewel Agile iets anders is dat op een handige manier wordt geïnterpreteerd.
- 5 - Te uitgebreid - het kan een scripttaal zijn of een gecompileerde taal. Ik vraag me af of het schrijven in Pascal en Basic op school bij hen past? =)
Ik zou ook graag een opmerking willen achterlaten over punt 3, om het begrip te versterken waarom dit punt door de systeembeheerder wordt behandeld. Kubernetes is slechts een orkestratie, een tool die directe opdrachten naar netwerkstuurprogramma's en virtualisatie-/isolatiehosts in een paar opdrachten verpakt en je in staat stelt de communicatie ermee abstract te maken, meer niet. Laten we bijvoorbeeld 'framework bouwen' Make nemen, wat ik overigens niet als een raamwerk beschouw. Ja, ik ken de mode om Make overal te duwen, waar het nodig en niet nodig is - Maven in Make verpakken bijvoorbeeld serieus?
In wezen is Make slechts een omhulsel over de shell, waardoor de commando's voor het compileren, koppelen en compileren van de omgeving worden vereenvoudigd, net als k8s.
Ik heb eens een man geïnterviewd die k8s gebruikte in zijn werk bovenop OpenStack, en hij vertelde hoe hij er services op implementeerde. Toen ik echter naar OpenStack vroeg, bleek dat het werd beheerd en ook door het systeem werd gegenereerd. beheerders. Denk je echt dat iemand die OpenStack heeft geïnstalleerd, ongeacht welk platform hij achter zich gebruikt, k8s niet kan gebruiken? =)
Deze aanvrager is eigenlijk geen DevOps, maar een Systeembeheerder en, om preciezer te zijn, een Kubernetes-beheerder.
Laten we het nog eens samenvatten: een midden/senior systeembeheerder is voor hen voldoende.
Hoeveel te wegen in gram
Het bereik van de voorgestelde salarissen voor de aangegeven vacatures bedraagt 90k-200k
Nu zou ik een parallel willen trekken tussen de geldelijke beloningen van systeembeheerders en DevOps-ingenieurs.
Om de zaken te vereenvoudigen, kun je in principe de cijfers verspreiden op basis van werkervaring, hoewel dit niet exact zal zijn, maar voor de doeleinden van het artikel zal het voldoende zijn.
Een ervaring:
- tot 3 jaar – Junior
- tot 6 jaar – Midden
- meer dan 6 – Senioren
De werknemerszoeksite biedt:
Systeembeheerders:
- Junior - 2 jaar - 50k wrijven.
- Midden - 5 jaar - 70k wrijven.
- Senior - 11 jaar - 100k wrijven.
DevOps-ingenieurs:
- Junior - 2 jaar - 100k wrijven.
- Midden - 3 jaar - 160k wrijven.
- Senior - 6 jaar - 220k wrijven.
Volgens de ervaring van “DevOps” werd er gebruik gemaakt van ervaringen die op zijn minst op de een of andere manier de SDLC beïnvloedden.
Uit het bovenstaande volgt dat bedrijven in feite geen DevOps nodig hebben, en ook dat ze minstens 50 procent van de aanvankelijk geplande kosten zouden kunnen besparen door een beheerder in te huren; bovendien zouden ze de verantwoordelijkheden van de persoon die ze zoeken duidelijker kunnen omschrijven. en sneller in de behoefte voorzien. We mogen ook niet vergeten dat een duidelijke verdeling van verantwoordelijkheden ons in staat stelt de eisen aan personeel te verminderen en een gunstiger sfeer in het team te creëren, vanwege het ontbreken van overlappingen. De overgrote meerderheid van de vacatures staat vol met nutsvoorzieningen en DevOps-labels, maar deze zijn niet gebaseerd op daadwerkelijke vereisten voor een DevOps Engineer, maar alleen op verzoeken voor een toolbeheerder.
Het proces van het trainen van DevOps-ingenieurs is ook alleen beperkt tot een reeks specifieke werkzaamheden en hulpprogramma's, en biedt geen algemeen inzicht in de processen en hun afhankelijkheden. Het is zeker goed als iemand AWS EKS kan inzetten met behulp van Terraform, in combinatie met de Fluentd zijspan in dit cluster en de AWS ELK-stack voor het logsysteem in 10 minuten, met slechts één commando in de console, maar als hij de principe van het zelf verwerken van logboeken en waarvoor ze nodig zijn, als je niet weet hoe je er statistieken over moet verzamelen en de verslechtering van de service kunt volgen, dan zal het nog steeds dezelfde enikey zijn die weet hoe hij sommige hulpprogramma's moet gebruiken.
De vraag creëert echter aanbod en we zien een extreem oververhitte markt voor de DevOps-positie, waar de vereisten niet overeenkomen met de daadwerkelijke rol, maar systeembeheerders alleen maar meer laten verdienen.
Dus wie zijn zij? DevOps of hebzuchtige systeembeheerders? =)
Hoe verder te leven?
Werkgevers moeten de eisen nauwkeuriger formuleren en zoeken naar precies die eisen die nodig zijn, en niet met etiketten rondgooien. Je weet niet wat DevOps doet, dan heb je ze niet nodig.
Werknemers - Leer. Verbeter voortdurend uw kennis, bekijk het totaalbeeld van processen en volg het pad naar uw doel. Je kunt worden wie je wilt, je moet het gewoon proberen.
Bron: www.habr.com