Nor dira DevOps?

Momentuz, hau da ia merkatuko posiziorik garestiena. "DevOps" ingeniarien inguruko zalaparta imajina daitekeen muga guztietatik kanpo dago, eta are okerragoa DevOpseko ingeniari seniorrekin.
Integrazio eta automatizazio saileko buru gisa lan egiten dut, asmatu ingeleseko deskodeketa - DevOps Manager. Nekez da ingelesezko transkripzioak gure eguneroko jarduerak islatzea, baina kasu honetan errusierazko bertsioa zehatzagoa da. Nire jardueraren izaera dela eta, naturala da nire taldeko etorkizuneko kideak elkarrizketatu behar ditudala, eta azken urtean, 50 pertsona inguru pasa dira nire artetik, eta kopuru bera moztu dute nire langileekin aurreproiektuan.

Oraindik lankideen bila gabiltza, DevOps etiketaren atzean ingeniari mota ezberdinen geruza oso handia baitago ezkutatzen.

Jarraian idatzitako guztia nire iritzi pertsonala da, ez duzu horrekin ados egon beharrik, baina onartzen dut gaiarekiko duzun jarrerari kolore pixka bat emango diola. Desegokian erortzeko arriskua egon arren, nire iritzia plazaratzen dut, lekua duela uste dudalako.

Enpresek ulertzen dute nortzuk diren DevOps-eko ingeniariak eta, baliabide bat azkar kontratatzeko, etiketa hau guztiongan zintzilikatzen dute. Egoera nahiko bitxia da, enpresak prest baitaude pertsona horiei ordainsari ez-errealistak ordaintzeko, kasu gehienetan haientzako tresna administratzaile bat jasoz.

Beraz, nor dira DevOps ingeniariak?

Has gaitezen bere agerpenaren historiatik - Garapen Operazioak talde txikietan elkarrekintza optimizatzeko beste urrats bat bezala agertu zen, produktuaren ekoizpenaren abiadura handitzeko, espero den ondorio gisa. Ideia garapen taldea sendotzea zen, produktuaren ingurunea kudeatzeko prozedurak eta planteamenduak ezagututa. Beste era batera esanda, garatzaileak ulertu eta jakin behar du bere produktua nola funtzionatzen duen baldintza jakin batzuetan, ulertu behar du nola zabaldu bere produktua, zein ezaugarri egokitu daitezkeen ingurunearen errendimendua hobetzeko. Beraz, denbora batez, DevOps ikuspegia zuten garatzaileak agertu ziren. DevOps-eko garatzaileek eraikitzeko eta ontziratzeko scriptak idatzi zituzten beren jarduerak eta ekoizpen ingurunearen errendimendua errazteko. Hala ere, soluzio-arkitekturaren konplexutasunak eta denboran zehar azpiegituren osagaien elkarrekiko eragina inguruneen errendimendua okertzen hasi ziren; errepikapen bakoitzean, osagai jakin batzuk gero eta sakonago ulertzea beharrezkoa zen, garatzailearen produktibitatea murriztuz, gehigarrien ondorioz. Zeregin zehatz baterako osagaiak eta sintonizazio sistemak ulertzeko kostuak. Garatzailearen kostua hazi egin zen, produktuaren kostua harekin batera, taldean garatzaile berrien eskakizunak jauzi handia egin zuen, garapen "izar"aren erantzukizunak ere estali behar baitzituzten eta, jakina, "izarrak" gutxiago bihurtu ziren. eta eskuragarri gutxiago. Aipatzekoa da, halaber, nire esperientziaren arabera, garatzaile gutxik interesa dutela sistema eragilearen nukleoaren paketeen prozesamenduaren berezitasunak, paketeen bideratze-arauak eta ostalariaren segurtasun-alderdiak. Urrats logikoa hau ezagutzen zuen administratzaile bat erakartzea eta hari antzeko ardurak esleitzea izan zen, eta horrek, bere esperientziari esker, adierazle berdinak lortzea ahalbidetu zuen "izar" garapenaren kostuarekin alderatuta. Horrelako administratzaileak talde batean jartzen ziren eta bere zeregin nagusia proba eta produkzio inguruneak kudeatzea zen, talde zehatz baten arauen arabera, talde zehatz horri baliabideak esleituta. Horrela agertu zen, hain zuzen ere, DevOps gehiengoaren buruan.

Partzialki edo guztiz, denboraren poderioz, sistema-administratzaile hauek garapenaren alorrean talde jakin honen beharrak ulertzen hasi ziren, garatzaileei eta probatzaileei bizitza erraztu, eguneratze bat nola zabaldu eta ostiralean gaua igaro behar ez izan. bulegoan, hedapen akatsak zuzenduz. Denbora pasa zen, eta orain "izarrak" garatzaileek zer nahi zuten ulertzen zuten sistema-administratzaileak ziren. Eragina murrizteko, kudeaketa-utilitateak sortzen hasi ziren; denek gogoratu zituzten OS maila isolatzeko metodo zahar eta fidagarriak, eta horri esker, segurtasun-baldintzak, sare-zatiaren kudeaketa eta ostalariaren konfigurazioa ahalik eta txikiagotu ziren. osoa eta, ondorioz, “izar” berrien eskakizunak murriztea.

Gauza "zoragarri" bat agertu da - docker. Zergatik zoragarria? Bai, chroot edo kartzela batean isolamendua sortzeak, baita OpenVZ ere, sistema eragilearen ezagutza ez hutsala eskatzen zuelako, aitzitik, erabilgarritasunak ostalari jakin batean aplikazio ingurune isolatu bat sortzea ahalbidetzen du barruan eta eskuarekin beharrezko guztiarekin. garapenaren eskuetan berriro, eta sistemaren administratzaileak ostalari bakarrarekin bakarrik kudeatu dezake, bere segurtasuna eta erabilgarritasun handia bermatuz, sinplifikazio logikoa. Baina aurrerapena ez da geldirik gelditzen eta sistemak gero eta konplexuagoak dira berriro, gero eta osagai gehiago daude, ostalari batek jada ez ditu sistemaren beharrak asetzen eta klusterrak eraikitzea beharrezkoa da, sistemaren administratzaileengana itzultzen ari gara berriro. sistema hauek eraikitzeko gai.

Zikloz ziklo, garapena eta/edo administrazioa errazten duten hainbat sistema agertzen dira, orkestrazio sistemak agertzen dira, prozesu estandarretik aldendu behar izan arte, erabiltzeko errazak direnak. Mikrozerbitzuen arkitektura ere agertu zen goian deskribatutako guztia sinplifikatzeko helburuarekin: harreman gutxiago, errazago kudeatzeko. Nire esperientziaren arabera, ez nuen guztiz mikrozerbitzuen arkitekturarik aurkitu, mikrozerbitzuen ehuneko 50etik 50era - 50era esango nuke, kutxa beltzak sartu zirela, prozesatua atera zela, beste 50ak monolito urratuak direla, zerbitzuak besteetatik bereizita lan egin ezinik. osagaiak. Horrek guztiak berriz ere murrizketak ezarri zituen garatzaileen zein administratzaileen ezagutza mailan.

Baliabide jakin baten adituen ezagutza mailan antzeko "swingek" jarraitzen dute gaur egun. Baina pixka bat aldentzen gara, nabarmendu beharreko puntu asko daude.

Eraikitzeko ingeniaria/Askatze ingeniaria

Softwarearen eraikuntza-prozesuak eta bertsioak estandarizatzeko baliabide gisa sortu ziren oso ingeniari espezializatuak. Agile hedatua ezartzeko prozesuan, eskaria izateari utzi ziola dirudi, baina hori oso urrun dago. Espezializazio hau softwarearen muntaia eta entrega estandarizatzeko baliabide gisa agertu zen industria eskalan, hau da. enpresaren produktu guztietarako teknika estandarrak erabiliz. DevOps-en etorrerarekin, garatzaileek beren funtzioak partzialki galdu zituzten, garatzaileak izan baitziren produktua entregatzeko prestatzen hasi zirenak, eta azpiegitura aldakorra eta kalitatea kontuan hartu gabe ahalik eta azkarren entregatzeko ikuspegia ikusita, denborarekin bihurtu ziren. aldaketen geldiunea, kalitate estandarrak betetzeak ezinbestean bidalketak moteltzen dituelako. Beraz, pixkanaka, Eraiki/Askatze ingeniarien funtzionalitatearen zati bat sistema-administratzaileen sorbaldetara migratu zen.

Ops oso desberdinak dira

Behin eta berriz mugitzen gara ardura ugari egoteak eta pertsonal kualifikaturik ezak espezializazio zorrotzera bultzatzen gaitu, euriaren ondoren perretxikoak bezala, hainbat Operazio agertzen dira:

• TechOps - enikey sistema-administratzaileak aka HelpDesk Engineer
• LiveOps - produkzio-inguruneez arduratzen diren sistema-administratzaileak
• CloudOps - Azure, AWS, GCP, etab. hodei publikoetan espezializatutako sistema-administratzaileak.
• PlatOps/InfraOps/SysOps - azpiegitura-sistemaren administratzaileak.
• NetOps - sareko administratzaileak
• SecOps - informazioaren segurtasunean espezializatutako sistema-administratzaileak - PCI betetzea, CIS betetzea, adabakia, etab.

DevOps garapen-zikloko prozesu guztiak bertatik bertara ulertzen dituen pertsona da (teorian) - garapena, probak, produktuaren arkitektura ulertzen, segurtasun-arriskuak ebaluatzeko gai da, ikuspegiak eta automatizazio-tresnak ezagutzen dituena, maila altu batean behintzat. mailak, honetaz gain, produktuen kaleratze-laguntza ere ulertzen du aurreko eta osteko prozesatzea. Eragiketen zein Garapenaren defendatzaile gisa jarduteko gai den pertsona, bi zutabe horien arteko lankidetza onuragarria ahalbidetzen duena. Taldeen lana planifikatzeko eta bezeroen itxaropenak kudeatzeko prozesuak ulertzen ditu.

Horrelako lan eta erantzukizunak egiteko, pertsona horrek garapen eta proba prozesuak ez ezik, produktuaren azpiegituraren kudeaketa eta baliabideen plangintza ere kudeatzeko bitartekoak izan behar ditu. DevOps-a ezin da kokatu ez IT-n, ez I+G-n, ezta PMO-n ere; arlo horietan guztietan eragina izan behar du - konpainiako zuzendari teknikoa, zuzendari teknikoa.

Egia al da zure enpresan? - Zalantza dut. Kasu gehienetan, hau IT edo I+G da.

Funts faltak eta hiru jarduera-esparru horietako batean gutxienez eragiteko gaitasunak arazoen pisua aldaketa horiek errazago aplikatzen diren tokira eramango du, esate baterako, kode "zikin"arekin lotuta kaleratzeetan murrizketa teknikoak aplikatzera, estatikoen arabera. analizatzaile-sistemak. Hau da, PMOk funtzionalitateak kaleratzeko epe zorrotza ezartzen duenean, I+G-k ezin du kalitate handiko emaitzarik eman epe horietan eta ahal den moduan ekoizten du, birfactorizazioa gerorako utziz, informatikarekin erlazionatutako DevOps-ek kaleratzea blokeatzen du bide teknikoen bidez. . Egoera aldatzeko aginterik ezak, langile arduratsuen kasuan, eragin ezin dutenarekiko hipererantzukizuna agertzea dakar, batez ere langile horiek akatsak ulertzen eta ikusten badituzte, eta horiek nola zuzendu - "Zoriontasuna ezjakintasuna da", eta, ondorioz, langile hauen kisketa eta galera.

DevOps baliabideen merkatua

Ikus ditzagun enpresa ezberdinetako DevOps postuetarako hainbat lanpostu huts.

Zurekin biltzeko prest gaude:

1. Zabbixen jabe zara eta Prometeo zer den badakizu;
2. Iptables;
3. BASH doktoregoa;
4. Ansible irakaslea;
5. Linux Guru;
6. Arazketa erabiltzen jakitea eta garatzaileekin batera aplikazioen arazoak aurkitzen (php/java/python);
7. Bideratzeak ez zaitu histeriko bihurtzen;
8. Arreta handia jarri sistemaren segurtasunari;
9. Egin babeskopiak "edozer eta dena" eta, gainera, "edozer eta dena" behar bezala leheneratu;
10. Badakizu sistema konfiguratzen ahalik eta gehien gutxienekotik ateratzeko moduan;
11. Konfiguratu erreplikazioa oheratu aurretik Postgres eta MySQL-en;
12. CI/CD konfiguratzea eta doitzea gosaria/bazkaria/afaria bezain beharrezkoa da zuretzat.
13. AWS-rekin esperientzia izatea;
14. Enpresarekin garatzeko prest;

Beraz:

• 1etik 6ra - sistemaren administratzailea
• 7 - Sare-administrazio txiki bat, sistemaren administratzailean ere sartzen dena, Erdi mailakoa
• 8 - segurtasun apur bat, derrigorrezkoa dena Erdi mailako sistemaren administratzaile batentzat
• 9-11 – Erdi Sistemako Administratzailea
• 12 — Esleitutako zereginen arabera, Erdi Sistemako Administratzailea edo Eraikitzeko Ingeniaria
• 13 - Birtualizazioa - Erdiko Sistema Administratzailea edo CloudOps izenekoa, ostalaritza gune jakin baten zerbitzuen ezagutza aurreratua, funtsak eraginkortasunez erabiltzeko eta mantentze-lanaren karga murrizteko.

Lanpostu hau laburbilduz, esan dezakegu Erdi/Senior Sistema Administratzailea nahikoa dela mutilentzat.

Bide batez, ez zenuke Linux/Windows-en administratzaileak oso banatu behar. Jakina, ulertzen dut bi mundu hauetako zerbitzuak eta sistemak desberdinak direla, baina guztien oinarria berdina da eta bere burua errespetatzen duen edozein administratzaile ezagutzen du bata eta bestea, eta ezaguna ez bada ere, egingo du. ez da zaila izango administratzaile eskudun batek hura ezagutzea.

Demagun beste lanpostu huts bat:

1. Karga handiko sistemak eraikitzen esperientzia;
2. Linux OS, sistema orokorraren softwarea eta web pilaren ezagutza bikaina (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Esperientzia birtualizazio sistemekin (KVM, VMWare, LXC/Docker);
4. Gidoi-lengoaietan trebetasuna;
5. Sare-protokolo-sareen funtzionamendu-printzipioak ulertzea;
6. Matxurak jasaten dituzten sistemak eraikitzeko printzipioak ulertzea;
7. Independentzia eta ekimena;

Ikus ditzagun:

• 1 – Sistemako goi-administratzailea
• 2 - Pila honetan jarritako esanahiaren arabera - Erdi/Senior Sistema Administratzailea
• 3 - Lan esperientziak, barne, esan nahi du - "Klusterrak ez zuen sortu, makina birtualak sortu eta kudeatu zituen, Docker ostalari bat zegoen, edukiontzietarako sarbidea ez zegoen erabilgarri" - Erdiko Sistemako Administratzailea
• 4 - Junior System Administrator - bai, oinarrizko automatizazio script-ak idazten ez dakien administratzailea, hizkuntza edozein dela ere, ez administratzailea - enikey.
• 5 - Erdiko Sistema Administratzailea
• 6 – Sistemako goi-administratzailea

Laburbilduz - Erdiko/Senior Sistema Administratzailea

Beste bat:

1. Devops esperientzia;
2. CI/CD prozesuak sortzeko produktu bat edo gehiago erabiltzen esperientzia. Gitlab CI abantaila izango da;
3. Edukiontziekin eta birtualizazioarekin lan egitea; Docker erabiltzen baduzu, ondo, baina k8s erabiltzen baduzu, bikaina!
4. Talde arin batean lan egiteko esperientzia;
5. Edozein programazio-lengoaia ezagutzea;

Ikus dezagun:

• 1 - Hmm... Zer esan nahi dute mutilek? =) Seguruenik beraiek ez dakite horren atzean zer ezkutatzen den
• 2 - Eraikuntza ingeniaria
• 3 - Erdiko Sistema Administratzailea
• 4 - Soft skill, oraingoz ez dugu kontuan hartuko, nahiz eta Agilea den modu egokian interpretatzen den beste gauza bat den.
• 5 - Ahozkoegia - gidoi-lengoaia edo konpilatua izan daiteke. Eskolan Pascal eta Basic idaztea egokituko zaien galdetzen diot? =)

3. puntuari buruzko ohar bat ere utzi nahiko nuke, sistemaren administratzaileak puntu hau zergatik jasotzen duen ulertzeko. Kubernetes orkestrazio bat besterik ez da, sareko kontrolatzaileei eta birtualizazio/isolatze ostalariei komando zuzenak komando pare batean biltzen dituen tresna bat eta haiekin komunikazioa abstraktua egiteko aukera ematen duena, hori da dena. Adibidez, har dezagun 'eraiki markoa' Make, zeina, bide batez, ez dudan markotzat hartzen. Bai, badakit Make nonahi bultzatzeko moda, non beharrezkoa den eta beharrezkoa ez den - Maven Make-n biltzea, adibidez, serio?
Funtsean, Make shellaren gaineko bilgarri bat besterik ez da, konpilazio, lotu eta konpilazio inguruneko komandoak sinplifikatzen ditu, k8s bezala.

Behin, OpenStack-en gainean bere lanean k8s erabiltzen zuen tipo bat elkarrizketatu nuen, eta bertan zerbitzuak nola zabaldu zituen hitz egin nuen, hala ere, OpenStack-i buruz galdetu nionean, kudeatu egin zen, baita sistemaren arabera planteatu ere. administratzaileak. Benetan uste al duzu OpenStack instalatu duen pertsona bat, bere atzean erabiltzen duen plataforma edozein dela ere, ez dela k8s erabiltzeko gai? =)
Eskatzaile hau ez da benetan DevOps bat, Sistema Administratzailea baizik eta, zehatzago esateko, Kubernetes Administratzailea.

Laburtu dezagun berriro ere - Erdiko/Senior Sistema Administratzailea nahikoa izango da haientzat.

Zenbat pisatu gramotan

Adierazitako lanpostu hutsetarako proposatutako soldaten tartea 90k-200k da
Orain Sistema Administratzaileen eta DevOps Ingeniarien diru sarien arteko paralelismoa egin nahiko nuke.

Printzipioz, gauzak sinplifikatzeko, lan-esperientzian oinarritutako kalifikazioak sakabanatu ditzakezu, hori zehatza ez den arren, baina artikuluaren helburuetarako nahikoa izango da.

Esperientzia bat:

1. 3 urte arte – Junior
2. 6 urte arte – Erdikoa
3. 6 baino gehiago – Senior

Langileak bilatzeko guneak eskaintzen ditu:
Sistema-administratzaileak:

1. Junior - 2 urte - 50k igurtzi.
2. Erdikoa - 5 urte - 70k igurtzi.
3. Senior - 11 urte - 100k igurtzi.

DevOps ingeniariak:

1. Junior - 2 urte - 100k igurtzi.
2. Erdikoa - 3 urte - 160k igurtzi.
3. Senior - 6 urte - 220k igurtzi.

"DevOps"-en esperientziaren arabera, gutxienez SDLCri nolabait eragiten zion esperientzia erabili zen.

Aurrekotik ondorioztatzen da, hain zuzen, enpresek ez dutela DevOps beharrik, eta, gainera, hasieran aurreikusitako kostuen ehuneko 50 gutxienez aurreztu ahal izango lukete Administratzaile bat kontratatuz; gainera, argiago definitu ditzakete bilatzen ari den pertsonaren erantzukizunak. eta bete beharra azkarrago. Ez dugu ahaztu behar, gainera, erantzukizunen banaketa argi batek langileen eskakizunak murriztea ahalbidetzen duela, baita taldean giro onuragarriago bat sortzea ere, gainjartzerik ez dagoenez. Lanpostuen gehiengo zabala utilitatez eta DevOps etiketaz beteta daude, baina ez daude DevOps ingeniari baten benetako eskakizunetan oinarritzen, tresna-administratzaile baten eskaerak soilik.

DevOps ingeniariak trebatzeko prozesua lan, utilitate zehatz batzuetara soilik mugatzen da, eta ez du prozesuen eta haien mendekotasunen ulermen orokorrik ematen. Zalantzarik gabe, ona da pertsona batek Terraform erabiliz AWS EKS inplementatu dezakeenean, kluster honetako Fluentd sidecar-arekin eta erregistro-sistemarako AWS ELK pilarekin batera 10 minututan, kontsolan komando bakarra erabiliz, baina ez badu ulertzen Erregistroak prozesatzeko printzipioa eta zertarako behar diren, ez badakizu nola bildu eta zerbitzuaren hondamenaren jarraipena egiten ez baduzu, enikey bera izango da utilitate batzuk nola erabiltzen dakiena.

Eskariak, ordea, eskaintza sortzen du, eta DevOps posizioaren merkatu oso berotua ikusten dugu, non eskakizunak ez datozela bat benetako rolarekin, baina sistema-administratzaileei gehiago irabazteko aukera ematen die.

Beraz, nor dira? DevOps edo sistemaren administratzaile zikorrak? =)

Nola jarraitu bizitzen?

Enpresaburuek eskakizunak zehatzago formulatu beharko lituzkete eta behar direnak zehazki bilatu behar dituzte, eta ez etiketak bota. Ez dakizu DevOps-ek zer egiten duen; kasu horretan, ez dituzu behar.

Langileak - Ikasi. Hobetu etengabe zure ezagutza, begiratu prozesuen irudi orokorra eta jarraitu zure helbururako bidea. Nahi duzuna bihur zaitezke, probatu besterik ez duzu egin behar.

Iturria: www.habr.com