Kwa sasa, hii ni karibu nafasi ya gharama kubwa zaidi kwenye soko. Mzozo kuhusu wahandisi wa "DevOps" ni zaidi ya mipaka yoyote inayowezekana, na mbaya zaidi na wahandisi Waandamizi wa DevOps.
Ninafanya kazi kama mkuu wa idara ya ujumuishaji na otomatiki, nadhani usimbuaji wa Kiingereza - Meneja wa DevOps. Haiwezekani kwamba nakala ya Kiingereza inaonyesha shughuli zetu za kila siku, lakini toleo la Kirusi katika kesi hii ni sahihi zaidi. Kwa sababu ya aina ya shughuli yangu, ni kawaida kwamba ninahitaji kuwahoji washiriki wa siku zijazo wa timu yangu, na katika mwaka uliopita, takriban watu 50 walinipitia, na idadi sawa wamekatwa kwenye skrini ya mapema na wafanyikazi wangu.
Bado tunatafuta wenzetu, kwa sababu nyuma ya lebo ya DevOps kuna safu kubwa sana ya aina tofauti za wahandisi wanaojificha.
Kila kitu kilichoandikwa hapa chini ni maoni yangu ya kibinafsi, si lazima kukubaliana nayo, lakini ninakubali kwamba itaongeza rangi fulani kwa mtazamo wako kwa mada. Licha ya hatari ya kukosa upendeleo, ninachapisha maoni yangu kwa sababu ninaamini kuwa ina mahali pa kuwa.
Makampuni yana uelewa tofauti kuhusu wahandisi wa DevOps ni nani na, kwa ajili ya kuajiri rasilimali haraka, hutegemea lebo hii kwa kila mtu. Hali hiyo ni ya kushangaza sana, kwani kampuni ziko tayari kulipa malipo yasiyo ya kweli kwa watu hawa, kupokea, katika hali nyingi, msimamizi wa zana kwao.
Kwa hivyo wahandisi wa DevOps ni akina nani?
Wacha tuanze na historia ya kuonekana kwake - Operesheni za Maendeleo zilionekana kama hatua nyingine kuelekea kuboresha mwingiliano katika timu ndogo ili kuongeza kasi ya uzalishaji wa bidhaa, kama matokeo yanayotarajiwa. Wazo lilikuwa ni kuimarisha timu ya maendeleo kwa ujuzi wa taratibu na mbinu katika kusimamia mazingira ya bidhaa. Kwa maneno mengine, msanidi lazima aelewe na ajue jinsi bidhaa yake inavyofanya kazi katika hali fulani, lazima aelewe jinsi ya kupeleka bidhaa yake, ni sifa gani za mazingira zinaweza kubadilishwa ili kuboresha utendaji. Kwa hiyo, kwa muda fulani, watengenezaji wenye mbinu ya DevOps walionekana. Wasanidi wa DevOps waliandika hati za kujenga na kufunga ili kurahisisha shughuli zao na utendakazi wa mazingira ya uzalishaji. Walakini, ugumu wa usanifu wa suluhisho na ushawishi wa pande zote wa vifaa vya miundombinu kwa wakati ulianza kuzorota kwa utendaji wa mazingira; kwa kila marudio, uelewa wa kina zaidi wa vipengele fulani ulihitajika, kupunguza tija ya msanidi programu kutokana na ziada. gharama za kuelewa vipengele na mifumo ya kurekebisha kwa kazi maalum. Gharama ya msanidi programu ilikua, gharama ya bidhaa pamoja nayo, mahitaji ya watengenezaji wapya kwenye timu yaliruka sana, kwa sababu walihitaji pia kufunika majukumu ya "nyota" ya maendeleo na, kwa kawaida, "nyota" zilipungua. na chini inapatikana. Inafaa pia kuzingatia kuwa, katika uzoefu wangu, watengenezaji wachache wanavutiwa na maelezo mahususi ya usindikaji wa pakiti na kernel ya mfumo wa uendeshaji, sheria za uelekezaji wa pakiti, na vipengele vya usalama vya mwenyeji. Hatua ya kimantiki ilikuwa kuvutia msimamizi ambaye anafahamu hili na kumpa majukumu sawa, ambayo, kwa shukrani kwa uzoefu wake, ilifanya iwezekanavyo kufikia viashiria sawa kwa gharama ya chini ikilinganishwa na gharama ya maendeleo ya "nyota". Wasimamizi kama hao waliwekwa katika timu, na kazi yake kuu ilikuwa kusimamia mazingira ya mtihani na uzalishaji, kulingana na sheria za timu maalum, na rasilimali zilizotengwa kwa timu hii. Hivi ndivyo, kwa kweli, DevOps ilionekana katika akili za wengi.
Kwa kiasi au kabisa, baada ya muda, wasimamizi hawa wa mfumo walianza kuelewa mahitaji ya timu hii maalum katika uwanja wa maendeleo, jinsi ya kurahisisha maisha kwa watengenezaji na wanaojaribu, jinsi ya kusambaza sasisho na sio lazima kukaa usiku kucha siku ya Ijumaa. ofisi, kurekebisha makosa ya kupeleka. Muda ulipita, na sasa "nyota" walikuwa wasimamizi wa mfumo ambao walielewa kile watengenezaji walitaka. Ili kupunguza athari, huduma za usimamizi zilianza kuja; kila mtu alikumbuka mbinu za zamani na za kuaminika za kutenga kiwango cha OS, ambayo ilifanya iwezekanavyo kupunguza mahitaji ya usalama, usimamizi wa sehemu ya mtandao, na usanidi wa mwenyeji kama nzima na, kwa sababu hiyo, kupunguza mahitaji ya "nyota" mpya.
Jambo la "ajabu" limeonekana - docker. Kwa nini ajabu? Ndio, kwa sababu tu kuunda kutengwa katika chroot au jela, na vile vile OpenVZ, ilihitaji maarifa yasiyo ya maana ya OS, kwa upande mwingine, matumizi hukuruhusu kuunda mazingira ya pekee ya programu kwa mwenyeji fulani na kila kitu muhimu ndani na mkono. juu ya hatamu za maendeleo tena, na msimamizi wa mfumo anaweza tu kusimamia na mwenyeji mmoja tu, kuhakikisha usalama wake na upatikanaji wa juu - kurahisisha mantiki. Lakini maendeleo hayasimami na mifumo inazidi kuwa ngumu zaidi na zaidi, kuna sehemu zaidi na zaidi, mwenyeji mmoja haikidhi mahitaji ya mfumo na inahitajika kujenga vikundi, tunarudi tena kwa wasimamizi wa mfumo ambao uwezo wa kujenga mifumo hii.
Mzunguko baada ya mzunguko, mifumo mbalimbali inaonekana ambayo hurahisisha maendeleo na / au utawala, mifumo ya orchestration inaonekana, ambayo, mpaka unahitaji kuacha mchakato wa kawaida, ni rahisi kutumia. Usanifu wa Microservice pia ulionekana kwa lengo la kurahisisha kila kitu kilichoelezwa hapo juu - mahusiano machache, rahisi kusimamia. Kwa uzoefu wangu, sikupata usanifu wa huduma ndogo kabisa, ningesema asilimia 50 hadi 50 - 50 ya microservices, masanduku nyeusi, yaliingia, yakatoka kusindika, 50 nyingine ni monolith iliyopasuka, huduma haziwezi kufanya kazi tofauti na nyingine. vipengele. Yote hii tena iliweka vikwazo kwa kiwango cha ujuzi wa watengenezaji na wasimamizi.
"Swings" sawa katika kiwango cha ujuzi wa mtaalam wa rasilimali fulani huendelea hadi leo. Lakini tunapunguza kidogo, kuna vidokezo vingi vinavyostahili kuangaziwa.
Kujenga Mhandisi/Kutolewa Mhandisi
Wahandisi waliobobea sana ambao waliibuka kama njia ya kusawazisha michakato ya uundaji wa programu na matoleo. Katika mchakato wa kuanzisha Agile iliyoenea, inaweza kuonekana kuwa waliacha kuwa katika mahitaji, lakini hii ni mbali na kesi hiyo. Utaalamu huu ulionekana kama njia ya kusawazisha mkusanyiko na utoaji wa programu kwa kiwango cha viwanda, i.e. kutumia mbinu za kawaida kwa bidhaa zote za kampuni. Pamoja na ujio wa DevOps, watengenezaji walipoteza kazi zao kwa sehemu, kwani ni watengenezaji ambao walianza kuandaa bidhaa kwa ajili ya utoaji, na kutokana na mabadiliko ya miundombinu na mbinu ya kutoa haraka iwezekanavyo bila kuzingatia ubora, baada ya muda waligeuka kuwa. kizuizi cha mabadiliko, kwa kuwa kufuata viwango vya ubora kunapunguza kasi ya uwasilishaji. Kwa hivyo, hatua kwa hatua, sehemu ya utendakazi wa wahandisi wa Kujenga/Kutolewa ilihamia kwenye mabega ya wasimamizi wa mfumo.
Ops ni tofauti sana
Tunasonga mbele na tena uwepo wa anuwai kubwa ya majukumu na ukosefu wa wafanyikazi waliohitimu hutusukuma kuelekea utaalam madhubuti, kama uyoga baada ya mvua, Operesheni mbali mbali zinaonekana:
- TechOps - wasimamizi wa mfumo wa enikey aka HelpDesk Engineer
- LiveOps - wasimamizi wa mfumo huwajibika kimsingi kwa mazingira ya uzalishaji
- CloudOps - wasimamizi wa mfumo waliobobea katika mawingu ya umma Azure, AWS, GCP, nk.
- PlatOps/InfraOps/SysOps - wasimamizi wa mfumo wa miundombinu.
- NetOps - wasimamizi wa mtandao
- SecOps - wasimamizi wa mfumo waliobobea katika usalama wa habari - kufuata PCI, kufuata CIS, kuweka, nk.
DevOps ni (kwa nadharia) mtu ambaye anaelewa kwanza michakato yote ya mzunguko wa maendeleo - ukuzaji, upimaji, anaelewa usanifu wa bidhaa, anaweza kutathmini hatari za usalama, anafahamu mbinu na zana za otomatiki, angalau kwa kiwango cha juu. ngazi, pamoja na hii, pia inaelewa usaidizi wa utoaji wa bidhaa kabla na baada ya usindikaji. Mtu anayeweza kufanya kazi kama mtetezi wa Uendeshaji na Maendeleo, ambayo inaruhusu ushirikiano mzuri kati ya nguzo hizi mbili. Inaelewa michakato ya kupanga kazi na timu na kudhibiti matarajio ya wateja.
Kufanya aina hii ya kazi na majukumu, mtu huyu lazima awe na njia za kusimamia sio tu michakato ya maendeleo na kupima, lakini pia usimamizi wa miundombinu ya bidhaa, pamoja na mipango ya rasilimali. DevOps katika ufahamu huu haiwezi kupatikana katika IT, au katika R&D, au hata katika PMO; lazima iwe na ushawishi katika maeneo haya yote - mkurugenzi wa kiufundi wa kampuni, Afisa Mkuu wa Ufundi.
Je, hii ni kweli katika kampuni yako? - Nina shaka. Katika hali nyingi, hii ni IT au R&D.
Ukosefu wa fedha na uwezo wa kushawishi angalau moja ya maeneo haya matatu ya shughuli kutahamisha uzito wa matatizo kuelekea mahali ambapo mabadiliko haya ni rahisi kutumika, kama vile utumiaji wa vikwazo vya kiufundi kwa matoleo yanayohusiana na kanuni "chafu" kulingana na tuli. mifumo ya analyzer. Hiyo ni, wakati PMO inapoweka makataa madhubuti ya kutolewa kwa utendakazi, R&D haiwezi kutoa matokeo ya ubora wa juu ndani ya tarehe hizi za mwisho na kuyazalisha kadri inavyoweza, na kuacha kurekebishwa kwa baadaye, DevOps zinazohusiana na IT huzuia kutolewa kwa njia za kiufundi. . Ukosefu wa mamlaka ya kubadilisha hali hiyo, kwa upande wa wafanyikazi wanaowajibika, husababisha udhihirisho wa uwajibikaji mkubwa kwa kile wasichoweza kushawishi, haswa ikiwa wafanyikazi hawa wanaelewa na kuona makosa, na jinsi ya kuyarekebisha - "Furaha ni ujinga", na kama matokeo ya uchovu na hasara ya wafanyikazi hawa.
Soko la rasilimali za DevOps
Wacha tuangalie nafasi kadhaa za nafasi za DevOps kutoka kwa kampuni tofauti.
Tuko tayari kukutana nawe ikiwa:
- Unamiliki Zabbix na unajua Prometheus ni nini;
- Iptables;
- Mwanafunzi wa PhD wa BASH;
- Profesa Ansible;
- Linux Guru;
- Jua jinsi ya kutumia utatuzi na upate shida za programu pamoja na watengenezaji (php/java/python);
- Uelekezaji haukufanyi kuwa na wasiwasi;
- Kuzingatia sana usalama wa mfumo;
- Hifadhi nakala ya "chochote na kila kitu", na pia urejeshe kwa mafanikio hii "chochote na kila kitu";
- Unajua jinsi ya kusanidi mfumo kwa njia ya kupata kiwango cha juu kutoka kwa kiwango cha chini;
- Weka replication kabla ya kwenda kulala kwenye Postgres na MySQL;
- Kuweka na kurekebisha CI/CD ni muhimu kwako kama kifungua kinywa/chakula cha mchana/chakula cha jioni.
- Kuwa na uzoefu na AWS;
- Tayari kuendeleza na kampuni;
Hivyo:
- kutoka 1 hadi 6 - msimamizi wa mfumo
- 7 - utawala mdogo wa mtandao, ambao pia unafaa kwa msimamizi wa mfumo, ngazi ya Kati
- 8 - usalama mdogo, ambayo ni lazima kwa msimamizi wa mfumo wa ngazi ya Kati
- 9-11 - Msimamizi wa Mfumo wa Kati
- 12 - Kulingana na kazi ulizopewa, ama Msimamizi wa Mfumo wa Kati au Mhandisi wa Kujenga
- 13 - Virtualization - Msimamizi wa Mfumo wa Kati, au kinachojulikana kama CloudOps, ujuzi wa juu wa huduma za tovuti maalum ya mwenyeji, kwa matumizi bora ya fedha na kupunguza mzigo kwenye matengenezo.
Kwa muhtasari wa nafasi hii, tunaweza kusema kwamba Msimamizi wa Mfumo wa Kati/Mwandamizi anatosha kwa wavulana.
Kwa njia, hupaswi kugawanya sana wasimamizi kwenye Linux / Windows. Kwa kweli, ninaelewa kuwa huduma na mifumo ya ulimwengu huu mbili ni tofauti, lakini msingi wa wote ni sawa na msimamizi yeyote anayejiheshimu anafahamiana na mmoja na mwingine, na hata kama hajui, itawezekana. isiwe vigumu kwa msimamizi anayefaa kuifahamu.
Wacha tuangalie nafasi nyingine:
- Uzoefu katika kujenga mifumo ya mzigo mkubwa;
- Ujuzi bora wa Linux OS, programu ya mfumo wa jumla na stack ya mtandao (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Uzoefu na mifumo ya virtualization (KVM, VMWare, LXC/Docker);
- Ustadi katika lugha za uandishi;
- Uelewa wa kanuni za uendeshaji wa mitandao ya itifaki ya mtandao;
- Kuelewa kanuni za kujenga mifumo inayostahimili makosa;
- Uhuru na mpango;
Hebu tuangalie:
- 1 - Msimamizi Mkuu wa Mfumo
- 2 - Kulingana na maana iliyowekwa kwenye safu hii - Msimamizi wa Mfumo wa Kati / Mwandamizi
- 3 - Uzoefu wa kazi, ikiwa ni pamoja na, unaweza kumaanisha - "Kundi halikuinua, lakini liliunda na kudhibiti mashine pepe, kulikuwa na mpangishi mmoja wa Docker, ufikiaji wa makontena haukupatikana" - Msimamizi wa Mfumo wa Kati
- 4 - Msimamizi wa Mfumo wa Kijana - ndio, msimamizi ambaye hajui jinsi ya kuandika maandishi ya msingi ya otomatiki, bila kujali lugha, sio msimamizi - enikey.
- 5 - Msimamizi wa Mfumo wa Kati
- 6 - Msimamizi Mkuu wa Mfumo
Kwa muhtasari - Msimamizi wa Mfumo wa Kati / Mwandamizi
Mwingine:
- uzoefu wa Devops;
- Uzoefu wa kutumia bidhaa moja au zaidi kuunda michakato ya CI/CD. Gitlab CI itakuwa faida;
- Kufanya kazi na vyombo na virtualization; Ikiwa ulitumia docker, nzuri, lakini ikiwa ulitumia k8s, nzuri!
- Uzoefu wa kufanya kazi katika timu ya agile;
- Ujuzi wa lugha yoyote ya programu;
Hebu tuone:
- 1 - Hmm... Wanamaanisha nini? =) Uwezekano mkubwa wao wenyewe hawajui ni nini kilichofichwa nyuma yake
- 2 - Mhandisi wa Kujenga
- 3 - Msimamizi wa Mfumo wa Kati
- 4 - Ustadi laini, hatutazingatia kwa sasa, ingawa Agile ni jambo lingine ambalo linatafsiriwa kwa njia rahisi.
- 5 - Kitenzi kikali sana - inaweza kuwa lugha ya hati au iliyokusanywa. Ninajiuliza ikiwa kuandika kwa Pascal na Msingi shuleni kutawafaa? =)
Ningependa pia kuacha dokezo kuhusu hatua ya 3 ili kuimarisha uelewa wa kwa nini hatua hii inafunikwa na msimamizi wa mfumo. Kubernetes ni orchestration tu, chombo ambacho hujumuisha amri za moja kwa moja kwa viendeshaji vya mtandao na uboreshaji/wapangishi wa kujitenga katika amri kadhaa na hukuruhusu kufanya mawasiliano nao kuwa ya kufikirika, ndivyo tu. Kwa mfano, hebu tuchukue 'mfumo wa kujenga' Tengeneza, ambayo, kwa njia, sizingatii mfumo. Ndiyo, najua kuhusu mtindo wa kusukuma Fanya popote, ambapo ni muhimu na haihitajiki - kuifunga Maven katika Make, kwa mfano, kwa uzito?
Kimsingi, Tengeneza ni kifuniko tu juu ya ganda, kurahisisha utungaji, uunganisho, na amri za mazingira za ujumuishaji, kama k8s.
Wakati mmoja, nilihoji mtu ambaye alitumia k8s katika kazi yake juu ya OpenStack, na alizungumza juu ya jinsi alivyopeleka huduma juu yake, hata hivyo, nilipouliza kuhusu OpenStack, ikawa kwamba ilisimamiwa, na pia kukuzwa na mfumo. wasimamizi. Unafikiria kweli kuwa mtu ambaye amesakinisha OpenStack, bila kujali ni jukwaa gani analotumia nyuma yake, hawezi kutumia k8s? =)
Mwombaji huyu kwa kweli si DevOps, lakini Msimamizi wa Mfumo na, kuwa sahihi zaidi, Msimamizi wa Kubernetes.
Wacha tufanye muhtasari tena - Msimamizi wa Mfumo wa Kati/Mwandamizi atawatosha.
Ni kiasi gani cha kupima kwa gramu
Aina mbalimbali za mishahara inayopendekezwa kwa nafasi zilizoainishwa ni 90k-200k
Sasa ningependa kuchora ulinganifu kati ya zawadi za pesa za Wasimamizi wa Mfumo na Wahandisi wa DevOps.
Kimsingi, ili kurahisisha mambo, unaweza kutawanya darasa kulingana na uzoefu wa kazi, ingawa hii haitakuwa sawa, lakini kwa madhumuni ya kifungu itakuwa ya kutosha.
Uzoefu:
- hadi miaka 3 - Junior
- hadi miaka 6 - Kati
- zaidi ya 6 - Mwandamizi
Tovuti ya utafutaji ya mfanyakazi inatoa:
Wasimamizi wa Mfumo:
- Junior - miaka 2 - 50k kusugua.
- Kati - miaka 5 - 70k kusugua.
- Mwandamizi - miaka 11 - 100k kusugua.
Wahandisi wa DevOps:
- Junior - miaka 2 - 100k kusugua.
- Kati - miaka 3 - 160k kusugua.
- Mwandamizi - miaka 6 - 220k kusugua.
Kulingana na uzoefu wa "DevOps", uzoefu ulitumiwa ambao angalau kwa namna fulani uliathiri SDLC.
Kutoka hapo juu inafuata kwamba kwa kweli makampuni hayahitaji DevOps, na pia kwamba wanaweza kuokoa angalau asilimia 50 ya gharama zilizopangwa hapo awali kwa kuajiri Msimamizi; zaidi ya hayo, wanaweza kufafanua kwa uwazi zaidi majukumu ya mtu wanayemtafuta. na kujaza hitaji haraka. Hatupaswi pia kusahau kuwa mgawanyiko wazi wa majukumu huturuhusu kupunguza mahitaji ya wafanyikazi, na pia kuunda hali nzuri zaidi katika timu, kwa sababu ya kutokuwepo kwa mwingiliano. Idadi kubwa ya nafasi zilizoachwa wazi zimejaa huduma na lebo za DevOps, lakini hazitokani na mahitaji halisi ya Mhandisi wa DevOps, maombi ya msimamizi wa zana pekee.
Mchakato wa kutoa mafunzo kwa wahandisi wa DevOps pia ni mdogo tu kwa seti ya kazi maalum, huduma, na haitoi uelewa wa jumla wa michakato na utegemezi wao. Hakika ni vizuri wakati mtu anaweza kupeleka AWS EKS kwa kutumia Terraform, kwa kushirikiana na kando ya Fluentd kwenye nguzo hii na safu ya AWS ELK ya mfumo wa ukataji miti katika dakika 10, kwa kutumia amri moja tu kwenye koni, lakini ikiwa haelewi kanuni ya usindikaji yenyewe magogo na nini zinahitajika kwa ajili yake, ikiwa hujui jinsi ya kukusanya metrics juu yao na kufuatilia uharibifu wa huduma, basi itakuwa bado enikey sawa ambaye anajua jinsi ya kutumia baadhi ya huduma.
Mahitaji, hata hivyo, hutengeneza usambazaji, na tunaona soko lenye joto kupita kiasi kwa nafasi ya DevOps, ambapo mahitaji hayalingani na jukumu halisi, lakini huruhusu tu wasimamizi wa mfumo kuchuma zaidi.
Kwa hiyo ni akina nani? DevOps au wasimamizi wa mfumo wenye pupa? =)
Jinsi ya kuendelea kuishi?
Waajiri wanapaswa kuunda mahitaji kwa usahihi zaidi na kutafuta wale ambao wanahitajika, na sio kutupa lebo. Hujui DevOps hufanya - huzihitaji katika hali hiyo.
Wafanyakazi - Jifunze. Boresha maarifa yako kila wakati, angalia picha ya jumla ya michakato na ufuatilie njia ya kufikia lengo lako. Unaweza kuwa mtu yeyote unayetaka, lazima ujaribu.
Chanzo: mapenzi.com