Kiuj estas DevOps?

Nuntempe ĉi tio estas preskaŭ la plej multekosta pozicio sur la merkato. La tumulto ĉirkaŭ "DevOps" inĝenieroj estas preter ĉiuj imageblaj limoj, kaj eĉ pli malbona kun Senior DevOps-inĝenieroj.
Mi laboras kiel estro de la fako pri integriĝo kaj aŭtomatigo, divenas la anglan malkodigon - DevOps Manager. Estas neverŝajne, ke la angla transskribo reflektas niajn ĉiutagajn agadojn, sed la rusa versio en ĉi tiu kazo estas pli preciza. Pro la naturo de mia agado, estas nature, ke mi bezonas intervjui estontajn membrojn de mia teamo, kaj dum la pasinta jaro, ĉirkaŭ 50 homoj trapasis min, kaj la sama nombro estis fortranĉita sur antaŭekrano kun miaj dungitoj.

Ni daŭre serĉas kolegojn, ĉar malantaŭ la etikedo DevOps estas tre granda tavolo de malsamaj specoj de inĝenieroj kaŝantaj.

Ĉio ĉi-sube skribita estas mia persona opinio, vi ne devas konsenti kun ĝi, sed mi konfesas, ke ĝi aldonos iom da koloro al via sinteno al la temo. Malgraŭ la risko de malfavoro, mi publikigas mian opinion ĉar mi kredas, ke ĝi havas lokon por esti.

Firmaoj havas malsamajn komprenojn pri kiuj DevOps-inĝenieroj estas kaj, pro rapide dungi rimedon, ili pendigas ĉi tiun etikedon sur ĉiuj. La situacio estas sufiĉe stranga, ĉar kompanioj pretas pagi nerealismajn rekompencojn al ĉi tiuj homoj, ricevante, plejofte, administranton de ilo por ili.

Do kiuj estas DevOps-inĝenieroj?

Ni komencu kun la historio de ĝia apero - Evoluaj Operacioj aperis kiel alia paŝo al optimumigo de interago en malgrandaj teamoj por pliigi la rapidecon de produktoproduktado, kiel atendata konsekvenco. La ideo estis plifortigi la evoluteamon kun scio pri proceduroj kaj aliroj en administrado de la produktomedio. Alivorte, la programisto devas kompreni kaj scii kiel sia produkto funkcias en certaj kondiĉoj, devas kompreni kiel disfaldi sian produkton, kiajn trajtojn de la medio povas ĝustigi por plibonigi rendimenton. Do dum iom da tempo aperis programistoj kun DevOps-aliro. DevOps-programistoj skribis konstruajn kaj enpakajn manuskriptojn por simpligi siajn agadojn kaj la agadon de la produktadmedio. Tamen, la komplekseco de la solva arkitekturo kaj la reciproka influo de infrastrukturaj komponentoj dum tempo komencis plimalbonigi la agadon de la medioj; kun ĉiu ripeto, ĉiam pli profunda kompreno de certaj komponentoj estis postulata, reduktante la produktivecon de la ellaboranto pro la kroma. kostoj de komprenado de la komponentoj kaj agordaj sistemoj por specifa tasko. . La propra kosto de la programisto kreskis, la kosto de la produkto kune kun ĝi, la postuloj por novaj programistoj en la teamo saltis akre, ĉar ili ankaŭ devis kovri la respondecojn de la disvolviĝo "stelo" kaj, nature, la "steloj" malpliiĝis. kaj malpli disponebla. Indas ankaŭ rimarki, ke, laŭ mia sperto, malmultaj programistoj interesiĝas pri la specifaĵoj de paka pretigo per la operaciuma kerno, pakaĵetaj reguloj kaj gastigaj sekurecaj aspektoj. La logika paŝo estis altiri administranton, kiu konas ĉi tion kaj atribui al li similajn respondecojn, kio, danke al lia sperto, ebligis atingi la samajn indikilojn je pli malalta kosto kompare kun la kosto de "stela" evoluo. Tiaj administrantoj estis metitaj en teamon kaj lia ĉefa tasko estis administri testajn kaj produktadmediojn, laŭ la reguloj de specifa teamo, kun rimedoj asignitaj al ĉi tiu aparta teamo. Jen kiel, fakte, DevOps aperis en la mensoj de la plimulto.

Parte aŭ tute, kun la tempo, ĉi tiuj sistemaj administrantoj komencis kompreni la bezonojn de ĉi tiu aparta teamo en la kampo de disvolviĝo, kiel faciligi la vivon al programistoj kaj testistoj, kiel fari ĝisdatigon kaj ne devi tranokti vendrede en la oficejo, korektante disfaldajn erarojn. La tempo pasis, kaj nun la "steluloj" estis sistemaj administrantoj, kiuj komprenis, kion deziris programistoj. Por minimumigi la efikon, administraj utilecoj komencis aperi; ĉiuj memoris la malnovajn kaj fidindajn metodojn de izolado de la OS-nivelo, kiuj ebligis minimumigi la postulojn por sekureco, administrado de la retoparto kaj la gastiga agordo kiel agordo. tuta kaj, kiel rezulto, redukti la postulojn por novaj "steloj".

Aperis "mirinda" afero - docker. Kial mirinda? Jes, nur ĉar krei izolitecon en chroot aŭ malliberejo, same kiel OpenVZ, postulis ne-trivialan scion pri la OS, kontraŭe, la utileco permesas simple krei izolitan aplikaĵan medion sur certa gastiganto kun ĉio necesa interne kaj mano. denove super la kondukiloj de evoluo, kaj la administranto de la sistemo povas administri nur per nur unu gastiganto, certigante ĝian sekurecon kaj altan haveblecon - logika simpligo. Sed progreso ne haltas kaj sistemoj denove fariĝas pli kaj pli kompleksaj, estas pli kaj pli da komponantoj, unu gastiganto ne plu kontentigas la bezonojn de la sistemo kaj necesas konstrui aretojn, ni denove revenas al sistemaj administrantoj, kiuj estas. kapabla konstrui ĉi tiujn sistemojn.

Ciklo post ciklo, aperas diversaj sistemoj, kiuj simpligas evoluon kaj/aŭ administradon, aperas orkestradsistemoj, kiuj, ĝis oni bezonas devii de la norma procezo, estas facile uzeblaj. Mikroserva arkitekturo ankaŭ aperis kun la celo simpligi ĉion supre priskribitan - malpli da rilatoj, pli facile administrebla. Laŭ mia sperto, mi ne trovis tute mikroservan arkitekturon, mi dirus 50 ĝis 50 - 50 procentoj de mikroservoj, nigraj skatoloj, eniris, eliris procesitaj, la aliaj 50 estas ŝirita monolito, servoj nekapablaj funkcii aparte de aliaj. komponantoj. Ĉio ĉi denove trudis limigojn sur la nivelo de scio de kaj programistoj kaj administrantoj.

Similaj "svingoj" en la nivelo de sperta scio pri aparta rimedo daŭras ĝis hodiaŭ. Sed ni iom malproksimiĝas, estas multaj punktoj, kiuj estas atentindaj.

Konstrua Inĝeniero/Release Engineer

Tre specialiĝintaj inĝenieroj, kiuj aperis kiel rimedo por normigi programajn konstruprocezojn kaj eldonojn. En la procezo de enkonduko de ĝeneraligita Agile, ŝajnus, ke ili ĉesis esti postulataj, sed ĉi tio estas malproksima de la kazo. Tiu ĉi specialiĝo aperis kiel rimedo por normigi la muntadon kaj liveron de programaro sur industria skalo, t.e. uzante normajn teknikojn por ĉiuj kompanioj produktoj. Kun la apero de DevOps, programistoj parte perdis siajn funkciojn, ĉar estis la programistoj kiuj komencis prepari la produkton por liveraĵo, kaj pro la ŝanĝiĝanta infrastrukturo kaj la aliro al livero kiel eble plej rapide sen konsidero de kvalito, kun la tempo ili fariĝis. halto de ŝanĝoj, ĉar aliĝo al kvalitnormoj neeviteble malrapidigas liveraĵojn. Do, iom post iom, parto de la funkcieco de Build/Release-inĝenieroj migris al la ŝultroj de sistemaj administrantoj.

Ops estas tiel malsamaj

Ni pluiras kaj denove la ĉeesto de granda gamo de respondecoj kaj la manko de kvalifikita dungitaro puŝas nin al strikta specialiĝo, kiel fungoj post pluvo, diversaj Operacioj aperas:

• TechOps - enikey-sistemaj administrantoj alinome HelpDesk Engineer
• LiveOps - sistemadministrantoj ĉefe respondecaj pri produktadmedioj
• CloudOps - sistemaj administrantoj specialigitaj pri publikaj nuboj Azure, AWS, GCP, ktp.
• PlatOps/InfraOps/SysOps - infrastrukturaj sistemadministrantoj.
• NetOps - retaj administrantoj
• SecOps - sistemadministrantoj specialiĝantaj pri informa sekureco - PCI-konformeco, CIS-konformeco, flikado, ktp.

DevOps estas (teorie) homo, kiu komprenas unuamane ĉiujn procezojn de la disvolva ciklo - disvolviĝo, testado, komprenas la arkitekturon de la produkto, kapablas taksi sekurecajn riskojn, konas alirojn kaj aŭtomatigajn ilojn, almenaŭ je alta. nivelo, krom tio, ankaŭ komprenas antaŭ- kaj post-prilaborado.produkta liberigo subteno. Persono kapabla agi kiel aktivulo por kaj Operacioj kaj Disvolviĝo, kio permesas favoran kunlaboron inter ĉi tiuj du kolonoj. Komprenas la procezojn de planado de laboro de teamoj kaj administrado de klientaj atendoj.

Por plenumi ĉi tiun tipon de laboro kaj respondecoj, ĉi tiu persono devas havi la rimedojn por administri ne nur la evoluajn kaj testajn procezojn, sed ankaŭ la administradon de la produkta infrastrukturo, kaj ankaŭ la planadon de rimedoj. DevOps en ĉi tiu kompreno ne povas troviĝi nek en IT, nek en R&D, aŭ eĉ en la PMO; ĝi devas havi influon en ĉiuj ĉi tiuj areoj - la teknika direktoro de la firmao, Ĉefa Teknikisto.

Ĉu tio veras en via kompanio? - Mi dubas. Plejofte, ĉi tio estas aŭ IT aŭ R&D.

Manko de financo kaj kapablo influi almenaŭ unu el ĉi tiuj tri agadkampoj ŝanĝos la pezon de problemoj al kie ĉi tiuj ŝanĝoj estas pli facile aplikigeblaj, kiel la aplikado de teknikaj limigoj pri eldonoj lige kun "malpura" kodo laŭ statika. analiziloj. Tio estas, kiam la PMO fiksas striktan templimon por la liberigo de funkcieco, R&D ne povas produkti altkvalitan rezulton ene de ĉi tiuj limdatoj kaj produktas ĝin kiel eble plej bone, lasante refactoring por poste, DevOps rilata al IT blokas la liberigon per teknikaj rimedoj. . Manko de aŭtoritato ŝanĝi la situacion, en la kazo de respondecaj dungitoj, kondukas al la manifestiĝo de hiper-respondeco pri tio, kion ili ne povas influi, precipe se ĉi tiuj dungitoj komprenas kaj vidas erarojn, kaj kiel korekti ilin - "Feliĉo estas nescio", kaj kiel konsekvenco al elĉerpiĝo kaj perdo de ĉi tiuj dungitoj.

DevOps-merkato de rimedoj

Ni rigardu plurajn vakantaĵojn por DevOps-pozicioj de malsamaj kompanioj.

Ni pretas renkonti vin se vi:

1. Vi posedas Zabbix kaj scias kio estas Prometeo;
2. Iptables;
3. BASH PhD Studento;
4. Profesoro Ansible;
5. Linuksa Guruo;
6. Sciu kiel uzi sencimigon kaj trovi aplikajn problemojn kune kun programistoj (php/java/python);
7. Envojigo ne igas vin histeria;
8. Atentu gravan atenton al sistema sekureco;
9. Rezervu "ion kaj ĉion", kaj ankaŭ sukcese restarigi ĉi tiun "ion kaj ĉion";
10. Vi scias kiel agordi la sistemon tiel ke eltiri la maksimumon el la minimumo;
11. Agordu reproduktadon antaŭ enlitiĝo sur Postgres kaj MySQL;
12. Agordo kaj alĝustigo de CI/KD estas tiel necesa por vi kiel matenmanĝo/tagmanĝo/vespermanĝo.
13. Havu sperton kun AWS;
14. Preta por disvolvi kun la kompanio;

Do:

• de 1 ĝis 6 - sistemadministranto
• 7 - malgranda administrado de reto, kiu ankaŭ taŭgas en la administranto de la sistemo, Meznivelo
• 8 - iom da sekureco, kiu estas deviga por Meznivela sistemadministranto
• 9-11 - Meza Sistemadministranto
• 12 — Depende de la asignitaj taskoj, ĉu Meza Sistemadministranto aŭ Konstrua Inĝeniero
• 13 - Virtualigo - Meza Sistemadministranto, aŭ la tielnomita CloudOps, altnivela scio pri la servoj de specifa gastiga retejo, por la efika uzo de financoj kaj reduktado de la ŝarĝo pri bontenado

Resumante ĉi tiun vakanton, ni povas diri, ke Meza/Alta Sistema Administranto sufiĉas por la uloj.

Cetere, vi ne forte dividu administrantojn en Linukso/Vindozo. Kompreneble, mi komprenas, ke la servoj kaj sistemoj de ĉi tiuj du mondoj estas malsamaj, sed la bazo por ĉiuj estas la sama kaj ĉiu sinrespekta administranto konas kaj unu kaj la alian, kaj eĉ se li ne estas konata, ĝi estos konata. ne estos malfacile por kompetenta administranto konatiĝi kun ĝi.

Ni konsideru alian vakanton:

1. Sperto en konstruado de altŝarĝaj sistemoj;
2. Bonega scio pri Linux OS, ĝenerala sistema programaro kaj interreta stako (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Sperto kun virtualigaj sistemoj (KVM, VMWare, LXC/Docker);
4. Scipovo en skriptlingvoj;
5. Kompreno de la funkciaj principoj de retaj protokolaj retoj;
6. Kompreno de la principoj de konstruado de misfunkciaj sistemoj;
7. Sendependeco kaj iniciato;

Ni rigardu:

• 1 - Altranga Sistemadministranto
• 2 - Depende de la signifo metita en ĉi tiun stakon - Meza/Alta Sistemadministranto
• 3 - Labora sperto, inkluzive, povas signifi - "La areto ne levis, sed kreis kaj administris virtualajn maŝinojn, estis unu Docker-gastiganto, aliro al ujoj ne estis disponebla" - Meza Sistemadministranto
• 4 - Junior System Administrator - jes, administranto, kiu ne scias kiel verki bazajn aŭtomatigajn skriptojn, sendepende de la lingvo, ne administranto - enikey.
• 5 - Meza Sistemadministranto
• 6 - Altranga Sistemadministranto

Por resumi - Meza/Alta Sistemadministranto

Alia:

1. Devops-sperto;
2. Sperto en uzado de unu aŭ pluraj produktoj por krei CI/KD-procezojn. Gitlab CI estos avantaĝo;
3. Laborante kun ujoj kaj virtualigo; Se vi uzis docker, bone, sed se vi uzis k8s, bonege!
4. Sperto laboranta en lerta teamo;
5. Kono de iu ajn programlingvo;

Ni vidu:

• 1 - Hmm... Kion signifas la uloj? =) Plej verŝajne ili mem ne scias, kio kaŝiĝas malantaŭ ĝi
• 2 - Konstrua Inĝeniero
• 3 - Meza Sistemadministranto
• 4 - Mola lerteco, ni ne konsideros ĝin nuntempe, kvankam Agile estas alia afero, kiu estas interpretata en maniero oportuna.
• 5 - Tro vorta - ĝi povus esti skriptlingvo aŭ kompilita. Mi scivolas, ĉu skribi en Pascal kaj Basic en la lernejo konvenos al ili? =)

Mi ankaŭ ŝatus lasi noton pri punkto 3 por plifortigi la komprenon pri kial ĉi tiu punkto estas kovrita de la sistemadministranto. Kubernetes estas nur orkestrado, ilo, kiu envolvas rektajn komandojn al retaj ŝoforoj kaj virtualigaj/izolaj gastigantoj en kelkaj komandoj kaj permesas vin abstrakti komunikadon kun ili, jen ĉio. Ekzemple, ni prenu 'konstrui kadron' Faru, kiun, cetere, mi ne konsideras kadron. Jes, mi scias pri la modo de ŝovi Maken ie ajn, kie ĝi estas necesa kaj ne necesa - envolvi Maven en Make, ekzemple, serioze?
Esence, Make estas nur envolvaĵo super la ŝelo, simpligante la kompilajn, ligojn kaj kompilajn mediokomandojn, same kiel k8s.

Unufoje, mi intervjuis ulon, kiu uzis k8s en sia laboro aldone al OpenStack, kaj li parolis pri kiel li deplojis servojn sur ĝi, tamen, kiam mi demandis pri OpenStack, montriĝis, ke ĝi estas administrita, kaj ankaŭ levita de sistemo. administrantoj. Ĉu vi vere pensas, ke homo, kiu instalis OpenStack, sendepende de kia platformo li uzas malantaŭ li, ne kapablas uzi k8s? =)
Ĉi tiu kandidato fakte ne estas DevOps, sed Sistemadministranto kaj, por esti pli precize, Kubernetes Administranto.

Ni resumu denove - Meza/Alta Sistemadministranto sufiĉos por ili.

Kiom pezi en gramoj

La gamo de proponitaj salajroj por la indikitaj vakantaĵoj estas 90k-200k
Nun mi ŝatus fari paralelon inter la monaj rekompencoj de Sistemadministrantoj kaj DevOps-Inĝenieroj.

Principe, por simpligi aferojn, vi povas disigi la notojn laŭ labora sperto, kvankam ĉi tio ne estos ĝusta, sed por la celoj de la artikolo sufiĉos.

Sperto:

1. ĝis 3 jaroj - Junior
2. ĝis 6 jaroj – Meza
3. pli ol 6 – Senior

La serĉejo de dungitoj ofertas:
Sistemadministrantoj:

1. Junulo - 2 jaroj - 50k rub.
2. Meza - 5 jaroj - 70k rub.
3. Maljunulo - 11 jaroj - 100k rub.

DevOps-Inĝenieroj:

1. Junulo - 2 jaroj - 100k rub.
2. Meza - 3 jaroj - 160k rub.
3. Maljunulo - 6 jaroj - 220k rub.

Laŭ la sperto de "DevOps", oni uzis sperton, kiu almenaŭ iel influis la SDLC.

El la supre sekvas, ke fakte kompanioj ne bezonas DevOps, kaj ankaŭ ke ili povus ŝpari almenaŭ 50 procentojn de la komence planitaj kostoj dungante Administranton; krome, ili povus pli klare difini la respondecojn de la persono, kiun ili serĉas. kaj plenigu la bezonon pli rapide. Ni ankaŭ ne forgesu, ke klara divido de respondecoj permesas al ni redukti la postulojn por dungitaro, kaj ankaŭ krei pli favoran etoson en la teamo, pro la foresto de interkovroj. La granda plimulto de vakantaĵoj estas plenaj de utilecoj kaj DevOps-etikedoj, sed ili ne baziĝas sur realaj postuloj por DevOps-Inĝeniero, nur petoj por iladministranto.

La procezo de trejnado de DevOps-inĝenieroj ankaŭ estas limigita nur al aro de specifaj verkoj, utilecoj, kaj ne provizas ĝeneralan komprenon pri la procezoj kaj iliaj dependecoj. Certe estas bone, kiam homo povas disfaldi AWS EKS uzante Terraform, kune kun la Fluentd kromĉaro en ĉi tiu areto kaj la AWS ELK-stako por la registra sistemo en 10 minutoj, uzante nur unu komandon en la konzolo, sed se li ne komprenas la principo de prilaborado de mem protokoloj kaj por kio ili bezonas, se vi ne scias kiel kolekti metrikojn pri ili kaj spuri la degradadon de la servo, tiam ĝi ankoraŭ estos la sama enikey kiu scias kiel uzi iujn utilecojn.

Postulo tamen kreas provizon, kaj ni vidas ekstreme varmigitan merkaton por la pozicio DevOps, kie la postuloj ne respondas al la reala rolo, sed nur permesas al administrantoj de sistemoj gajni pli.

Kiuj do ili estas? DevOps aŭ avidaj sistemadministrantoj? =)

Kiel daŭre vivi?

Dungantoj devus formuli postulojn pli precize kaj serĉi ĝuste tiujn, kiuj estas bezonataj, kaj ne ĵeti ĉirkaŭe etikedojn. Vi ne scias, kion faras DevOps - vi ne bezonas ilin en tiu kazo.

Laboristoj - Lernu. Konstante plibonigu viajn sciojn, rigardu la ĝeneralan bildon de procezoj kaj spuru la vojon al via celo. Vi povas fariĝi kiu ajn vi volas, vi nur devas provi.

fonto: www.habr.com