De moment, aquesta és gairebé la posició més cara del mercat. L'enrenou al voltant dels enginyers "DevOps" està més enllà de tots els límits imaginables, i encara pitjor amb els enginyers sèniors de DevOps.
Treballo com a cap del departament d'integració i automatització, suposo que la descodificació en anglès - DevOps Manager. És poc probable que la transcripció en anglès reflecteixi les nostres activitats diàries, però la versió russa en aquest cas és més precisa. A causa de la naturalesa de la meva activitat, és natural que hagi d'entrevistar futurs membres del meu equip, i durant l'últim any han passat per mi unes 50 persones, i el mateix nombre s'han tallat a la prescreen amb els meus empleats.
Encara estem buscant companys, perquè darrere de l'etiqueta DevOps s'amaga una capa molt gran de diferents tipus d'enginyers.
Tot el que s'escriu a continuació és la meva opinió personal, no cal que hi estiguis d'acord, però admeto que aportarà una mica de color a la teva actitud davant el tema. Tot i el risc de caure en desgràcia, publico la meva opinió perquè crec que té un lloc on estar.
Les empreses tenen diferents coneixements sobre qui són els enginyers de DevOps i, per tal de contractar ràpidament un recurs, pengen aquesta etiqueta a tothom. La situació és força estranya, ja que les empreses estan disposades a pagar remuneracions poc realistes a aquestes persones, rebent, en la majoria dels casos, un administrador d'eines per a elles.
Aleshores, qui són els enginyers de DevOps?
Comencem amb la història de la seva aparició: les Operacions de Desenvolupament van aparèixer com un pas més cap a l'optimització de la interacció en petits equips per augmentar la velocitat de producció del producte, com a conseqüència esperada. La idea era reforçar l'equip de desenvolupament amb coneixements de procediments i enfocaments en la gestió de l'entorn del producte. És a dir, el desenvolupador ha d'entendre i saber com funciona el seu producte en determinades condicions, ha d'entendre com desplegar el seu producte, quines característiques de l'entorn es poden ajustar per millorar el rendiment. Així, durant un temps, van aparèixer desenvolupadors amb un enfocament DevOps. Els desenvolupadors de DevOps van escriure scripts de compilació i empaquetat per simplificar les seves activitats i el rendiment de l'entorn de producció. No obstant això, la complexitat de l'arquitectura de la solució i la influència mútua dels components de la infraestructura al llarg del temps van començar a deteriorar el rendiment dels entorns; amb cada iteració, es requeria una comprensió cada cop més profunda de determinats components, reduint la productivitat del desenvolupador a causa de l'aportació addicional. costos de comprensió dels components i sistemes d'afinació per a una tasca específica. El propi cost del desenvolupador va créixer, el cost del producte juntament amb ell, els requisits per als nous desenvolupadors de l'equip van saltar bruscament, perquè també havien de cobrir les responsabilitats de l'"estrella" de desenvolupament i, naturalment, les "estrelles" es van reduir. i menys disponibles. També val la pena assenyalar que, segons la meva experiència, pocs desenvolupadors estan interessats en els aspectes específics del processament de paquets pel nucli del sistema operatiu, les regles d'encaminament de paquets i els aspectes de seguretat de l'amfitrió. El pas lògic va ser atraure un administrador familiaritzat amb això i assignar-li responsabilitats similars, cosa que, gràcies a la seva experiència, va permetre aconseguir els mateixos indicadors a un cost més baix en comparació amb el cost d'un desenvolupament "estrella". Aquests administradors estaven col·locats en un equip i la seva tasca principal era gestionar els entorns de prova i producció, d'acord amb les normes d'un equip concret, amb recursos destinats a aquest equip en concret. Així és com, de fet, DevOps va aparèixer a la ment de la majoria.
Parcial o completament, amb el pas del temps, aquests administradors de sistemes van començar a entendre les necessitats d'aquest equip en concret en l'àmbit del desenvolupament, com facilitar la vida als desenvolupadors i provadors, com llançar una actualització i no haver de passar la nit el divendres a l'oficina, corregint errors de desplegament. Va passar el temps, i ara les "estrelles" eren administradors del sistema que entenien què volien els desenvolupadors. Per minimitzar l'impacte, van començar a sorgir utilitats de gestió; tothom va recordar els mètodes antics i fiables d'aïllar el nivell del sistema operatiu, que van permetre minimitzar els requisits de seguretat, gestió de la part de la xarxa i la configuració de l'amfitrió com a tot i, com a resultat, reduir els requisits de noves "estrelles".
Ha aparegut una cosa "meravellosa": Docker. Per què meravellós? Sí, només perquè la creació d'aïllament en un chroot o una presó, així com OpenVZ, requeria un coneixement no trivial del sistema operatiu, en canvi, la utilitat us permet crear simplement un entorn d'aplicació aïllat en un host determinat amb tot el necessari a l'interior i a la mà. torna a passar a les regnes del desenvolupament, i l'administrador del sistema només pot gestionar amb un sol amfitrió, garantint la seva seguretat i alta disponibilitat, una simplificació lògica. Però el progrés no s'atura i els sistemes tornen a ser cada cop més complexos, cada cop hi ha més components, un host ja no satisfà les necessitats del sistema i cal construir clústers, tornem als administradors de sistemes que estan capaços de construir aquests sistemes.
Cicle rere cicle apareixen diversos sistemes que simplifiquen el desenvolupament i/o l'administració, apareixen sistemes d'orquestració que, fins que cal desviar-se del procés estàndard, són fàcils d'utilitzar. També va aparèixer l'arquitectura de microserveis amb l'objectiu de simplificar tot allò descrit anteriorment: menys relacions, més fàcil de gestionar. Segons la meva experiència, no vaig trobar una arquitectura de microserveis completament, diria que entre el 50 i el 50-50 per cent dels microserveis, les caixes negres, van entrar, van sortir processats, els altres 50 són un monòlit trencat, els serveis no poden funcionar per separat dels altres. components. Tot això va tornar a imposar restriccions al nivell de coneixement tant dels desenvolupadors com dels administradors.
Els "oscil·lacions" similars en el nivell de coneixement expert d'un recurs concret continuen fins avui. Però divaguem una mica, hi ha molts punts que val la pena destacar.
Enginyer de construcció/Enginyer de llançament
Enginyers molt especialitzats que van sorgir com un mitjà per estandarditzar els processos de creació de programari i llançaments. En el procés d'introducció de l'Àgil generalitzat, sembla que van deixar de ser demandats, però això està lluny de ser així. Aquesta especialització va aparèixer com un mitjà per normalitzar el muntatge i el lliurament de programari a escala industrial, és a dir. utilitzant tècniques estàndard per a tots els productes de l'empresa. Amb l'arribada de DevOps, els desenvolupadors van perdre parcialment les seves funcions, ja que van ser els desenvolupadors els que van començar a preparar el producte per al lliurament i, atesa la infraestructura canviant i l'enfocament de lliurament el més ràpid possible sense tenir en compte la qualitat, amb el temps es van convertir en un fre dels canvis, ja que el compliment dels estàndards de qualitat frena inevitablement els lliuraments. Així, a poc a poc, part de la funcionalitat dels enginyers de compilació/alliberament es va migrar a les espatlles dels administradors del sistema.
Les operacions són molt diferents
Seguim i de nou la presència d'un ampli ventall de responsabilitats i la manca de personal qualificat ens empeny cap a una especialització estricta, com els bolets després de la pluja, apareixen diferents Operacions:
- TechOps: administradors de sistemes enikey també coneguts com HelpDesk Engineer
- LiveOps: administradors del sistema responsables principalment dels entorns de producció
- CloudOps: administradors de sistemes especialitzats en núvols públics Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps: administradors de sistemes d'infraestructura.
- NetOps: administradors de xarxa
- SecOps: administradors de sistemes especialitzats en seguretat de la informació: compliment PCI, compliment CIS, pegats, etc.
DevOps és (en teoria) una persona que entén de primera mà tots els processos del cicle de desenvolupament: desenvolupament, prova, entén l'arquitectura del producte, és capaç d'avaluar els riscos de seguretat, està familiaritzat amb els enfocaments i les eines d'automatització, almenys a un alt nivell. nivell, a més d'això, també entén el suport de llançament del producte pre i postprocessament. Una persona capaç d'actuar com a defensor tant d'Operacions com de Desenvolupament, que permeti una col·laboració favorable entre aquests dos pilars. Comprèn els processos de planificació del treball dels equips i de gestió de les expectatives dels clients.
Per realitzar aquest tipus de treballs i responsabilitats, aquesta persona ha de tenir els mitjans per gestionar no només els processos de desenvolupament i proves, sinó també la gestió de la infraestructura del producte, així com la planificació dels recursos. En aquest sentit, els DevOps no es poden localitzar ni en TI, ni en R+D, ni tan sols en el PMO; ha d'influir en totes aquestes àrees: el director tècnic de l'empresa, el director tècnic.
És cert a la vostra empresa? - Ho dubto. En la majoria dels casos, això és TI o R+D.
La manca de fons i la capacitat d'influir en almenys una d'aquestes tres àrees d'activitat canviarà el pes dels problemes cap a on aquests canvis són més fàcils d'aplicar, com ara l'aplicació de restriccions tècniques a les versions en relació amb el codi "brut" segons l'estàtica. sistemes analitzadors. És a dir, quan el PMO estableix un termini estricte per al llançament de la funcionalitat, R+D no pot produir un resultat de gran qualitat dins d'aquests terminis i el produeix el millor possible, deixant la refactorització per a més endavant, DevOps relacionat amb TI bloqueja el llançament per mitjans tècnics. . La manca d'autoritat per canviar la situació, en el cas dels empleats responsables, porta a la manifestació d'una hiperresponsabilitat pel que no poden influir, especialment si aquests empleats entenen i veuen errors, i com corregir-los: "La felicitat és la ignorància", i com a conseqüència de l'esgotament i pèrdua d'aquests empleats.
Mercat de recursos DevOps
Vegem diverses vacants per a llocs de DevOps de diferents empreses.
Estem preparats per reunir-nos amb vostè si:
- Ets propietari de Zabbix i saps què és Prometeu;
- Iptables;
- Estudiant de doctorat BASH;
- professor Ansible;
- Linux Guru;
- Saber utilitzar la depuració i trobar problemes d'aplicacions juntament amb els desenvolupadors (php/java/python);
- L'encaminament no et fa histèric;
- Presteu molta atenció a la seguretat del sistema;
- Fes una còpia de seguretat de "tot i tot" i també restaura amb èxit aquest "tot i tot";
- Saps configurar el sistema de manera que tregui el màxim del mínim;
- Configureu la replicació abans d'anar a dormir a Postgres i MySQL;
- Configurar i ajustar CI/CD és tan necessari com l'esmorzar, el dinar o el sopar.
- Tenir experiència amb AWS;
- Preparat per desenvolupar-se amb l'empresa;
Per tant:
- de l'1 al 6: administrador del sistema
- 7 - una petita administració de xarxa, que també s'adapta a l'administrador del sistema, nivell mitjà
- 8 - una mica de seguretat, que és obligatori per a un administrador del sistema de nivell mitjà
- 9-11 - Administrador del sistema mitjà
- 12 — Segons les tasques assignades, ja sigui Administrador del sistema mitjà o Enginyer de construcció
- 13 - Virtualització - Administrador del sistema mitjà, o l'anomenat CloudOps, coneixement avançat dels serveis d'un lloc d'allotjament específic, per a l'ús eficient dels fons i reduir la càrrega de manteniment.
Resumint aquesta vacant, podem dir que l'administrador del sistema mitjà/sènior és suficient per als nois.
Per cert, no hauríeu de dividir fortament els administradors a Linux/Windows. Per descomptat, entenc que els serveis i els sistemes d'aquests dos mons són diferents, però la base per a tots és la mateixa i qualsevol administrador que es precie està familiaritzat tant amb l'un com amb l'altre, i fins i tot si no està familiaritzat, ho farà. no serà difícil per a un administrador competent familiaritzar-s'hi.
Considerem una altra vacant:
- Experiència en la construcció de sistemes d'alta càrrega;
- Excel·lent coneixement del sistema operatiu Linux, programari general del sistema i pila web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experiència amb sistemes de virtualització (KVM, VMWare, LXC/Docker);
- Competència en llenguatges de guió;
- Comprensió dels principis de funcionament de les xarxes de protocol de xarxa;
- Comprensió dels principis de construcció de sistemes tolerants a fallades;
- Independència i iniciativa;
Vegem-ho:
- 1 – Administrador sènior de sistemes
- 2 - Depenent del significat posat a aquesta pila - Administrador del sistema mitjà/sènior
- 3 - L'experiència laboral, inclosa, pot significar: "El clúster no va generar, però va crear i gestionar màquines virtuals, hi havia un amfitrió Docker, l'accés als contenidors no estava disponible" - Administrador del sistema mitjà
- 4 - Administrador del sistema junior: sí, un administrador que no sap escriure scripts d'automatització bàsics, independentment de l'idioma, no un administrador - enikey.
- 5 - Administrador mitjà del sistema
- 6 – Administrador sènior de sistemes
En resum - Administrador del sistema mitjà/sènior
Un altre:
- experiència Devops;
- Experiència en l'ús d'un o més productes per crear processos CI/CD. Gitlab CI serà un avantatge;
- Treball amb contenidors i virtualització; Si vas fer servir Docker, bé, però si vas fer servir k8s, genial!
- Experiència treballant en equip àgil;
- Coneixement de qualsevol llenguatge de programació;
Vegem:
- 1 - Hmm... Què volen dir els nois? =) El més probable és que ells mateixos no sàpiguen què s'amaga darrere
- 2 - Enginyer d'edificació
- 3 - Administrador mitjà del sistema
- 4 - Soft skill, de moment no ho tindrem en compte, encara que Agile és una altra cosa que s'interpreta d'una manera convenient.
- 5 - Massa detallat: podria ser un llenguatge de script o compilat. Em pregunto si escriure en Pascal i Basic a l'escola els agradarà? =)
També m'agradaria deixar una nota sobre el punt 3 per enfortir la comprensió de per què aquest punt està cobert per l'administrador del sistema. Kubernetes és només una orquestració, una eina que inclou ordres directes als controladors de xarxa i als amfitrions de virtualització/aïllament en un parell d'ordres i us permet fer que la comunicació amb elles sigui abstracta, això és tot. Per exemple, prenem 'build framework' Make, que, per cert, no considero un marc. Sí, sé sobre la moda d'empènyer Make a qualsevol lloc, on sigui necessari i no necessari: embolicar Maven a Make, per exemple, seriosament?
Bàsicament, Make és només un embolcall sobre l'intèrpret d'ordres, que simplifica les ordres de compilació, enllaç i entorn de compilació, igual que k8s.
Una vegada, vaig entrevistar un noi que utilitzava k8s en el seu treball a sobre d'OpenStack, i va parlar de com hi va desplegar els serveis, però, quan vaig preguntar sobre OpenStack, va resultar que s'administrava, així com el plantejava el sistema. administradors. Realment creus que una persona que ha instal·lat OpenStack, independentment de quina plataforma utilitzi darrere seu, no pot utilitzar k8s? =)
En realitat, aquest sol·licitant no és un DevOps, sinó un administrador del sistema i, per ser més precisos, un administrador de Kubernetes.
Resumim una vegada més: l'administrador del sistema mitjà/sènior serà suficient per a ells.
Quant pesar en grams
El rang de salaris proposats per a les vacants indicades és de 90-200
Ara m'agradaria fer un paral·lelisme entre les recompenses monetàries dels administradors de sistemes i dels enginyers de DevOps.
En principi, per simplificar les coses, podeu dispersar les qualificacions en funció de l'experiència laboral, tot i que això no serà exacte, però als efectes de l'article n'hi haurà prou.
Una experiència:
- fins a 3 anys – Júnior
- fins a 6 anys – Mitjà
- més de 6 – Sènior
El lloc de cerca d'empleats ofereix:
Administradors del sistema:
- Júnior - 2 anys - 50k fregar.
- Mitjà - 5 anys - 70k fregament.
- Sènior - 11 anys - 100k fregar.
Enginyers de DevOps:
- Júnior - 2 anys - 100k fregar.
- Mitjà - 3 anys - 160k fregament.
- Sènior - 6 anys - 220k fregar.
Segons l'experiència de "DevOps", es va utilitzar una experiència que almenys d'alguna manera va afectar el SDLC.
De l'anterior es dedueix que de fet les empreses no necessiten DevOps, i també que podrien estalviar almenys un 50 per cent dels costos inicialment previstos contractant un Administrador; a més, podrien definir més clarament les responsabilitats de la persona que busquen. i omplir la necessitat més ràpidament. Tampoc no hem d'oblidar que una clara divisió de responsabilitats ens permet reduir els requeriments de personal, així com crear un ambient més favorable a l'equip, per l'absència de solapaments. La gran majoria de les vacants estan plenes d'utilitats i etiquetes de DevOps, però no es basen en els requisits reals d'un enginyer de DevOps, només les sol·licituds d'un administrador d'eines.
El procés de formació dels enginyers de DevOps també es limita només a un conjunt d'obres específiques, utilitats i no proporciona una comprensió general dels processos i les seves dependències. Sens dubte, és bo quan una persona pot desplegar AWS EKS mitjançant Terraform, juntament amb el sidecar Fluentd d'aquest clúster i la pila AWS ELK per al sistema de registre en 10 minuts, utilitzant només una ordre a la consola, però si no entén el principi de processar els mateixos registres i per a què són necessaris, si no sabeu com recollir mètriques i fer un seguiment de la degradació del servei, encara serà el mateix enikey que sap com utilitzar algunes utilitats.
La demanda, però, crea oferta i veiem un mercat extremadament sobreescalfat per a la posició de DevOps, on els requisits no es corresponen amb el paper real, sinó que només permeten que els administradors del sistema guanyin més.
Aleshores, qui són? DevOps o administradors de sistemes cobdiciosos? =)
Com seguir vivint?
Els empresaris haurien de formular els requisits amb més precisió i buscar exactament els que es necessiten, i no llençar les etiquetes. No saps què fan DevOps; en aquest cas, no els necessites.
Treballadors - Aprendre. Millora constantment els teus coneixements, mira la imatge general dels processos i segueix el camí cap al teu objectiu. Pots arribar a ser qui vulguis, només ho has d'intentar.
Font: www.habr.com