Wapi kwenda na ujuzi huu, nini cha kufanya katika mradi na kiasi gani cha kupata, nini cha kusema na kuuliza katika mahojiano - anasema Alexander Titov, mshirika mkuu wa Express 42 na mwandishi. .
Habari! Ingawa neno DevOps limekuwepo tangu 2009, bado hakuna makubaliano katika jumuiya ya Kirusi. Pengine umegundua kuwa wengine huchukulia DevOps kuwa maalum, wengine huichukulia kama falsafa, na wengine huchukulia neno hili kuwa seti ya teknolojia. Tayari nimefanya mara nyingi na kuhusu maendeleo ya mwelekeo huu, kwa hiyo sitaingia kwa undani katika makala hii. Wacha niseme tu kwamba kwa Express 42 tunajumuisha yafuatayo ndani yake:
DevOps ni mbinu mahususi, utamaduni wa kuunda bidhaa ya kidijitali, wakati wataalamu wote kwenye timu wanashiriki katika uzalishaji.
Katika maendeleo ya kawaida ya ushirika, kila kitu kinakwenda kwa mlolongo: programu, kupima na kisha tu uendeshaji, na kasi ya mchakato huu kutoka kwa wazo hadi uzalishaji ni miezi 3. Hili ni tatizo la kimataifa kwa bidhaa za digital, kwa sababu haiwezekani kupokea haraka maoni kutoka kwa wateja.
Katika DevOps, zana na mbinu zimeundwa ili kuhakikisha kwamba michakato ya maendeleo, majaribio na uendeshaji inaendeshwa kwa wakati mmoja.
Nini kinafuata kutokana na mbinu hii?
- Huwezi kuajiri "mhandisi" fulani ambaye atakuja na kutatua matatizo yote na uzalishaji. Timu nzima lazima itumie mbinu.
- DevOps SI aina inayofuata ya sysadmin ya kupandisha daraja hadi. "Mhandisi wa DevOps" inasikika sawa na "msanidi wa Agile."
- Ikiwa timu inatumia Kubernetes, Ansible, Prometheus, Mesosphere na Docker, hii haimaanishi kuwa mazoezi ya DevOps yametekelezwa huko.
Maisha baada ya DevOps hayatawahi kuwa sawa
Mbinu ya DevOps ni, kwanza kabisa, njia tofauti ya kufikiri, mtazamo wa maendeleo kwa ujumla na nafasi ya mtu katika mchakato. Tuligawanya kozi yetu ya mtandaoni katika vizuizi 2:
1. Kujiamulia
Kwanza, tunachunguza kwa undani kiini cha mbinu ya DevOps, na wanafunzi hugundua majukumu mapya katika timu, angalia ni ipi inayojibu zaidi, na kuamua wenyewe ni mwelekeo gani wa kuendeleza.
2. Zana na mazoea
Wanafunzi wanamiliki teknolojia mahususi kutoka kwa mtazamo wa mbinu ya DevOps.
Zana za DevOps zinaweza kutumika katika mbinu ya DevOps na katika ukuzaji wa kitamaduni. Mfano dhahiri zaidi itakuwa kutumia zana ya usimamizi wa usanidi inayowezekana. Iliundwa na kubuniwa kutekeleza mazoezi ya DevOps "Miundombinu kama Kanuni", ambayo ina maana kwamba hali tofauti za mfumo zinaelezwa, kutoka kwa mipangilio ya mfumo wa uendeshaji hadi programu ya programu. Ufafanuzi umegawanywa katika tabaka na hukuruhusu kudhibiti usanidi tata, unaobadilika kila wakati. Lakini wahandisi mara nyingi hutumia Ansible kama njia ya kuendesha hati za bash kwenye mashine nyingi. Hii sio mbaya au nzuri, lakini unahitaji kuelewa kuwa uwepo wa Ansible hauhakikishi uwepo wa DevOps katika kampuni.
Tuko kwenye mchakato Utakuwa umezama katika mchakato wa kuendeleza maombi sawa na Reddit maarufu, kuanzia na toleo lake la monolithic, kusonga hatua kwa hatua kwa microservices. Hatua kwa hatua tutamiliki zana mpya: Git, Ansible, Gitlab na kumaliza na Kubernetes na Prometheus.
Kwa upande wa mazoea, tutafuata mbinu za njia tatu zilizofafanuliwa katika DevOps Handbook - mazoea ya uwasilishaji endelevu, mazoea ya kutoa maoni, na kiini cha kozi nzima ni mazoezi ya kuendelea kujifunza pamoja na mfumo wako.
Ujuzi huu unawapa nini kila mmoja wa wataalam?
Kwa wasimamizi wa mfumo
Mazoezi yatakuwezesha kuondokana na utawala kuelekea kuunda bomba la uwasilishaji endelevu na jukwaa la miundombinu la utoaji wa programu. Jambo ni kwamba anaunda bidhaa - jukwaa la miundombinu kwa watengenezaji ambalo huwasaidia kusukuma mabadiliko yao kwa uzalishaji haraka.
Hapo awali, wasimamizi wa mfumo walikuwa ngome ya mwisho, baada ya hapo kila kitu kinakwenda katika uzalishaji. Na kimsingi walikuwa wakijishughulisha na uzima moto unaoendelea - kwa kuzingatia ambayo ni ngumu sana kuangazia mahitaji ya biashara, fikiria juu ya bidhaa na faida kwa mtumiaji.
Shukrani kwa mbinu ya DevOps, mawazo yanabadilika. Msimamizi wa mfumo anaelewa jinsi ya kutafsiri usanidi kuwa msimbo, ni mazoea gani yapo kwa hili.
Hii ni muhimu kwa sababu makampuni yanazidi kutambua kwamba hawana haja ya automatiska kila kitu, i.e. katika kile ambacho wasimamizi wa mfumo wa shule ya zamani walizoea kufanya, ambao pamoja na hii waliwasiliana kidogo na hawakuarifu timu kuhusu mabadiliko yote yaliyofanywa. Sasa timu zinatafuta wale ambao watakuwa watengenezaji wa bidhaa ya ndani ya miundombinu na kusaidia kuchanganya michakato iliyotenganishwa kuwa moja.
Kwa watengenezaji
Msanidi programu huacha kufikiria tu katika algorithms. Anapata ujuzi wa kufanya kazi na miundombinu, ujuzi wa ufahamu wa usanifu wa mazingira. Msanidi programu kama huyo anaelewa jinsi programu inavyofanya kazi, jinsi inavyopitia bomba la uwasilishaji unaoendelea, jinsi ya kuifuatilia, jinsi ya kuisajili ili kumfaidi mteja. Matokeo yake, ujuzi huu wote unakuwezesha kuandika msimbo unaofaa.
Kwa wanaojaribu
Upimaji kwa muda mrefu umekuwa ukihamia katika hali ya kiotomatiki; sote tunasema kwamba majaribio mengi hayapaswi kufanywa, lakini yameandikwa :) Kujaribio huwa sehemu ya bomba zima la utoaji wa bidhaa yako. Mjaribu hahitaji tu kujifunza jinsi ya kuandika msimbo, lakini pia kuelewa jinsi ya kuiunganisha katika mifumo endelevu ya uwasilishaji, jinsi ya kupokea maoni kutoka kwa msimbo katika hatua zote za uwasilishaji, na jinsi ya kuboresha majaribio kila wakati ili kugundua makosa kama vile. mapema iwezekanavyo.
Hivyo zinageuka kuwa hatua zote tatu hutokea kwa wakati mmoja. Kwa mfano, inaweza kuonekana kama hii:
Msanidi programu huandika msimbo, huiandikia mara moja majaribio, na kuelezea chombo cha docker kwa msimbo ambao unapaswa kuendeshwa. Pia inaelezea mara moja ufuatiliaji ambao utafuatilia uendeshaji wa huduma hii katika uzalishaji, na hufanya yote haya.
Wakati ujumuishaji unaoendelea unapoanza, michakato huendesha wakati huo huo. Huduma huanza na imeundwa. Wakati huo huo, chombo cha docker huanza na inakaguliwa kuwa kinaendelea. Wakati huo huo, taarifa zote huenda kwenye mfumo wa ukataji miti. Na kadhalika katika kila hatua ya maendeleo - inageuka kuwa kazi ya pamoja ya wasimamizi wa mfumo, watengenezaji na wajaribu.
Nilisoma DevOps, nini baadaye?
Kama unavyojua, mmoja kwenye uwanja sio shujaa. Ikiwa kampuni yako haitumii njia hii, ujuzi uliopatikana utalala bila kazi. Na baada ya kufahamiana na mbinu za DevOps, uwezekano mkubwa hautataka kuwa cog katika maendeleo ya ushirika. Kunaweza kuwa na ubaguzi mmoja: wewe ni msimamizi wa mfumo kwenye timu na unaweza kuunda upya michakato yote kwa njia mpya. Inafaa kuongeza hapa kuwa kuna kampuni nyingi zinazotumia njia hii, na haziathiriwi na kufuli na zinatafuta wataalamu. Kwa sababu DevOps inahusu kuunda bidhaa za mtandaoni.
Na sasa kuhusu mambo mazuri: umilisi wa mbinu na zana za DevOps ni takriban +30% kwa thamani yako kwenye soko la ajira. Mishahara huanza kutoka rubles elfu 140, lakini imedhamiriwa, kwa kawaida, na utaalam wako kuu na utendaji.
Unaweza kuangalia nafasi zilizoachwa wazi "zinazoelekezwa kwa miundombinu", ambapo kuna majaribio ya otomatiki, uundaji wa programu za huduma ndogo kwa kutumia teknolojia ya wingu, nafasi za wahandisi wa miundombinu na marejeleo ya kila aina ya DevOps. Kumbuka tu kwamba kila kampuni ina maana tofauti na ufafanuzi huu - soma maelezo kwa makini.
Wakati wa uzinduzi wa kozi yetu, ufahamu ulinijia - watu wengi baada ya kozi wanaanguka kwenye mtego wa mhandisi wa DevOps. Wanapata nafasi iliyo na jina lililotajwa hapo juu, wanapokea ofa nzuri, kisha wanakuja kazini na kutambua kwamba watalazimika kudumisha hati ya bash ya kurasa tatu katika Jenkins. Ziko wapi Kubernetes, ChatOps, matoleo ya canary na hayo yote? Lakini hakuna chochote, kwa sababu kampuni haiitaji DevOps kama mbinu, lakini hutumia uvumbuzi wa kibinafsi.
Hii ni sababu ya kujua kwa dhati kutoka kwa kampuni jinsi mchakato wa uwasilishaji wa programu unavyofanya kazi, safu ya teknolojia na ni majukumu gani utafanya.
Ikiwa mwajiri anajibu maswali yako kwa uwazi, kana kwamba kutoka kwa kitabu, bila maelezo, basi uwezekano mkubwa hakuna mchakato wa DevOps katika kampuni bado, lakini hii sio sababu ya kukataa, kusoma kampuni na bidhaa zake, iwe ziko mkondoni. huduma ambazo kampuni inajiendeleza yenyewe, maombi ya simu , mawazo ya bidhaa.
Ikiwa ndio, basi fafanua ikiwa utalazimika kufanya kazi moja kwa moja na mifumo hii au kama kuna uwezekano wa kusogea kwa mlalo kwa timu za huduma hizi huku ukionyesha matokeo mazuri katika mazoea ya DevOps. Ikiwa ndio, basi inafaa kwenda na kuwa hai na muhimu, na ukimaliza kozi yetu, mwisho huo umehakikishiwa.
Ni muhimu kutambua kwamba wataalamu wa Devops hupata thamani ya kweli wakiwa na uzoefu tu katika ukuzaji/usimamizi/jaribio. Hapo ndipo maarifa hayatakuwa ya kufikirika, lakini yataboresha mtaalamu (kwa kila maana). Kwa hivyo, wazo la "kujifunza DevOps kutoka mwanzo" ni sawa na kujifunza "kutumia lensi kutoka mwanzo" ikiwa haujawahi kushikilia kamera mikononi mwako au kuelekeza risasi. Ili kukusaidia kuamua ikiwa kozi hiyo inakufaa, tumefanya jaribio la kuingia ambalo litaangalia kiwango chako cha maarifa cha kutosha.
Nadhani moja ya mbinu - kwamba wakati wa mafunzo kila mwanafunzi anaamua mwenyewe katika mwelekeo gani anataka kukuza. Mara nyingi tunaona mabadiliko wakati msanidi anakuwa mhandisi wa miundombinu, na msimamizi anagundua kuwa anapenda kuandika msimbo - kisha anasoma zaidi lugha na kuiongezea na ujuzi uliopatikana wa DevOps. Kwa hivyo, tunawakaribisha haswa wale wanaohisi kuwa taaluma yao imekwama katika njia panda. Kozi itaanza Mei 28, lakini unaweza kujiunga wiki 2 baada ya kuanza kwa madarasa. Unaweza kutazama programu na kuchukua mtihani . Tukutane OTUS!
Chanzo: mapenzi.com