Hivi majuzi, matangazo kama haya yamejaa mtandao. Licha ya mshahara wa kupendeza, mtu hawezi kujizuia kuwa na aibu kwamba uzushi wa mwitu umeandikwa ndani. Mara ya kwanza inachukuliwa kuwa "DevOps" na "mhandisi" zinaweza kuunganishwa kwa neno moja, na kisha kuna orodha ya mahitaji ya nasibu, ambayo baadhi yake yanakiliwa wazi kutoka kwa nafasi ya sysadmin.
Katika chapisho hili ningependa kuzungumza kidogo kuhusu jinsi tulivyofikia hatua hii ya maisha, DevOps ni nini hasa na nini cha kufanya nayo sasa.
Nafasi kama hizo zinaweza kuhukumiwa kwa kila njia, lakini ukweli unabaki: kuna mengi yao, na hii ndio jinsi soko linafanya kazi kwa sasa. Tulifanya mkutano wa ibada na kutangaza waziwazi: " - sio kwa wahandisi wa DevOps." Hili litaonekana kuwa la ajabu na la kihuni kwa wengi: kwa nini watu wanaofanya tukio la kibiashara kabisa wanaenda kinyume na soko. Sasa tutaelezea kila kitu.
Kuhusu utamaduni na taratibu
Wacha tuanze na ukweli kwamba DevOps sio taaluma ya uhandisi. Yote ilianza na ukweli kwamba mgawanyiko wa kihistoria wa majukumu haufanyi kazi kwa ubora wa bidhaa. Wakati waandaaji wa programu tu, lakini hawataki kusikia chochote kuhusu majaribio, programu imejaa mende. Wakati wasimamizi hawajali jinsi au kwa nini programu imeandikwa, usaidizi hubadilika kuwa kuzimu.
Kwa mfano, kuelezea tofauti kati ya msimamizi wa mfumo na mbinu ya SRE kwa usimamizi wa huduma . Masomo ya kuvutia yamefanywa ndani - ni wazi kuwa wasanidi bora kwa namna fulani wanaweza kupeleka mabadiliko mapya kwenye uzalishaji haraka zaidi ya mara moja kwa saa. Wanajaribu kwa mikono yao si zaidi ya 10% (hii inaweza kuonekana kutoka ) Je, wanafanyaje hili? "Excel au kufa" kinasema moja ya vichwa vya ripoti. Kwa mjadala wa kina wa takwimu hizi katika muktadha wa majaribio, unaweza kurejelea noti kuu ya Baruch Sadogursky. katika mkutano wetu mwingine, Heisenbug.
"Wakati hakuna makubaliano kati ya wandugu,
Mambo hayatawaendea vyema,
Na hakuna kitakachotoka humo, ila adhabu tu.
Hapo zamani za kale Swan, Crayfish na Pike ... "
Je, unadhani ni sehemu gani ya watayarishaji programu wa wavuti inaelewa hali ambazo maombi yao yanatumiwa katika utayarishaji? Ni wangapi kati yao wataenda kwa wasimamizi na kujaribu kujua nini kitatokea ikiwa hifadhidata itaanguka? Na ni nani kati yao atakwenda kwa wanaojaribu na kuwauliza wafundishe jinsi ya kuandika vipimo kwa usahihi? Na pia kuna walinzi, wasimamizi wa bidhaa, na kundi la watu wengine.
Wazo la jumla la DevOps ni kuunda ushirikiano kati ya majukumu na idara. Kwanza kabisa, hii haipatikani na programu fulani iliyosanidiwa kwa ujanja, lakini kwa mazoezi ya mawasiliano. DevOps inahusu utamaduni, mazoea, mbinu na michakato. Hakuna taaluma ya uhandisi inayoweza kujibu maswali haya.
Mduara mbaya
Nidhamu ya "devops engineering" ilitoka wapi wakati huo? Tuna toleo! Mawazo ya DevOps yalikuwa mazuri—mazuri sana hivi kwamba wakawa wahasiriwa wa mafanikio yao wenyewe. Baadhi ya waajiri na wasafirishaji haramu wa binadamu, ambao wana mazingira yao wenyewe, walianza kuzunguka mada hii nzima.
Fikiria: jana ulikuwa ukifanya shawarma huko Khimki, na leo wewe tayari ni mtu mkubwa, mwajiri mkuu. Kuna mchakato mzima wa kutafuta na kuchagua wagombea, kila kitu si rahisi, unahitaji kuelewa. Hebu tuseme mkuu wa idara anasema: pata mtaalamu katika X. Tunatoa neno "mhandisi" kwa X, na tumemaliza. Je, unahitaji Linux? Kweli, huyu ni mhandisi wa Linux, ikiwa unataka DevOps, basi mhandisi wa DevOps. Nafasi haijumuishi tu jina, lakini pia maandishi fulani lazima yaingizwe ndani. Njia rahisi ni kuingiza seti ya maneno muhimu kutoka kwa Google, kulingana na mawazo yako. DevOps ina maneno mawili - "Dev" na "Ops", ambayo ina maana kwamba tunahitaji gundi maneno muhimu yanayohusiana na wasanidi programu na wasimamizi yote kwenye rundo moja. Hivi ndivyo nafasi zinavyoonekana kuhusu ustadi katika lugha 42 za programu na miaka 20 ya kutumia Kubernetes na Swarm kwa wakati mmoja. Mchoro wa kufanya kazi.
Hivi ndivyo picha isiyo na maana na isiyo na huruma ya shujaa fulani wa "devops" imechukua mizizi katika mawazo ya watu, ambao watasanidi kila mtu kupeleka kwa Jenkins, na furaha itakuja. Lo, ikiwa kila kitu kingekuwa rahisi sana. "Na hivi ndivyo unavyoweza kuwasaka wasimamizi wa mfumo," anafikiria HR, "ni neno la mtindo, maneno muhimu ni sawa, wanapaswa kuchukua chambo."
Mahitaji hutengeneza usambazaji, na nafasi hizi zote za takataka zimejazwa na idadi ya wendawazimu ya wasimamizi wa mfumo ambao waligundua: unaweza kufanya kila kitu sawa na hapo awali, lakini pata mara kadhaa zaidi kwa kujiita "devops." Kama vile ulivyosanidi seva kupitia SSH kwa mikono moja kwa wakati, utaendelea kuzisanidi, lakini sasa hii inadaiwa ni mazoezi ya devops. Hii ni aina fulani ya matukio changamano, ambayo kwa kiasi fulani yanahusishwa na kutothaminiwa kwa wasimamizi wa kawaida na hype karibu na DevOps, lakini kwa ujumla, kilichotokea, kilifanyika.
Kwa hivyo tuna ugavi na mahitaji. Mduara mbaya unaojilisha. Hili ndilo tunalopigania (ikiwa ni pamoja na kuunda mkutano wa DevoOops).
Bila shaka, kando na wasimamizi wa mfumo ambao wamejipa jina la "devops," kuna washiriki wengine - kwa mfano, SRE za kitaaluma au watengenezaji wa Miundombinu kama-Code.
Watu hufanya nini katika DevOps (kweli)
Kwa hivyo unataka kusonga mbele katika kujifunza na kutumia mazoea ya DevOps. Lakini jinsi ya kufanya hivyo, katika mwelekeo gani wa kuangalia? Kwa wazi, hupaswi kutegemea kwa upofu maneno muhimu maarufu.
Ikiwa kuna kazi, mtu anapaswa kuifanya. Tayari tumegundua kuwa hawa sio "wahandisi wa devops", basi ni akina nani? Inaonekana kuwa sahihi zaidi kuunda hii sio kwa suala la nafasi, lakini kwa suala la maeneo maalum ya kazi.
Kwanza, unaweza kushughulikia moyo wa DevOps—michakato na utamaduni. Utamaduni ni biashara ya polepole na ngumu, na ingawa kwa jadi ni jukumu la wasimamizi, kila mtu anahusika kwa njia moja au nyingine, kutoka kwa waandaaji wa programu hadi wasimamizi. Miezi michache iliyopita Tim Lister :
"Utamaduni umedhamiriwa na maadili ya msingi ya shirika. Kawaida watu hawatambui hili, lakini baada ya kufanya kazi katika kushauriana kwa miaka mingi, tumezoea kuiona. Unaingia kwenye kampuni na ndani ya dakika chache unaanza kuhisi kinachoendelea. Tunaita hii "ladha". Wakati mwingine harufu hii ni nzuri sana. Wakati mwingine husababisha kichefuchefu. (...) Huwezi kubadilisha utamaduni hadi maadili na imani nyuma ya vitendo maalum zieleweke. Tabia ni rahisi kutazama, lakini kutafuta imani ni ngumu. DevOps ni mfano mzuri tu wa jinsi mambo yanavyozidi kuwa magumu zaidi.
Pia kuna sehemu ya kiufundi ya suala hilo, bila shaka. Ikiwa nambari yako mpya itajaribiwa baada ya mwezi, lakini itatolewa mwaka mmoja baadaye, na haiwezekani kuharakisha yote, unaweza usiishi kulingana na mazoea mazuri. Mazoea mazuri yanaungwa mkono na zana nzuri. Kwa mfano, ukiwa na wazo la Miundombinu-kama-Msimbo akilini, unaweza kutumia chochote kutoka kwa AWS CloudFormation na Terraform hadi Chef-Ansible-Puppet. Unahitaji kujua na kuweza kufanya haya yote, na hii tayari ni nidhamu ya uhandisi. Ni muhimu sio kuchanganya sababu na athari: kwanza unafanya kazi kulingana na kanuni za SRE na kisha tu kutekeleza kanuni hizi kwa namna ya ufumbuzi maalum wa kiufundi. Wakati huo huo, SRE ni mbinu ya kina sana ambayo haikuambii jinsi ya kuanzisha Jenkins, lakini kuhusu kanuni tano za msingi:
- Kuboresha mawasiliano kati ya majukumu na idara
- Kukubali makosa kama sehemu muhimu ya kazi
- Kufanya mabadiliko hatua kwa hatua
- Kutumia zana na otomatiki zingine
- Kupima kila kitu ambacho kinaweza kupimwa
Hii sio tu seti fulani ya taarifa, lakini maalum . Kwa mfano, kwenye njia ya kukubali makosa, utahitaji kuelewa hatari, kupima upatikanaji na kutopatikana kwa huduma kwa kutumia kitu kama SLI () na SLO (), jifunze kuandika postmortems na kufanya kuandika kwao sio ya kutisha.
Katika nidhamu ya SRE, matumizi ya zana ni sehemu moja tu ya mafanikio, ingawa ni muhimu. Tunahitaji daima kuendeleza kiufundi, kuangalia kile kinachotokea duniani na jinsi gani kinaweza kutumika katika kazi yetu.
Kwa upande wake, ufumbuzi wa Cloud Native sasa umekuwa maarufu sana. Kama inavyofafanuliwa na Cloud Native Computing Foundation leo, teknolojia za Cloud Native huwezesha mashirika kuunda na kuendesha programu zinazoweza kusambazwa katika mazingira ya kisasa, kama vile mawingu ya umma, ya faragha na ya mseto. Mifano ni pamoja na kontena, meshes za huduma, huduma ndogo, miundombinu isiyoweza kubadilika, na API za kutangaza. Mbinu hizi zote huruhusu mifumo iliyounganishwa kwa urahisi kubaki nyororo, inayoweza kudhibitiwa, na inayoonekana sana. Uendeshaji mzuri wa kiotomatiki huruhusu wahandisi kufanya mabadiliko makubwa mara kwa mara na kwa matokeo yanayotabirika bila kuifanya kuwa kazi ngumu. Haya yote yanaungwa mkono na rundo la zana zinazojulikana kama vile Docker na Kubernetes.
Ufafanuzi huu badala ngumu na mpana ni kwa sababu ya ukweli kwamba eneo hilo pia ni ngumu sana. Kwa upande mmoja, inasemekana kwamba mabadiliko mapya kwenye mfumo huu yanapaswa kuongezwa kwa urahisi kabisa. Kwa upande mwingine, kujua jinsi ya kuunda aina ya mazingira ya kontena ambayo huduma zilizounganishwa kwa uhuru huishi kwenye miundombinu iliyoainishwa na programu na hutolewa huko kwa kutumia CI/CD inayoendelea, na kujenga mazoea ya DevOps karibu na haya yote - yote haya yanahitaji zaidi. kuliko mtu kula mbwa.
Nini cha kufanya na haya yote
Kila mtu anatatua matatizo haya kwa njia yake mwenyewe: kwa mfano, unaweza kuchapisha nafasi za kawaida ili kuvunja mzunguko mbaya. Unaweza kufahamu maneno kama vile DevOps na Cloud Native yanamaanisha nini na uyatumie kwa usahihi na kwa uhakika. Unaweza kuendeleza katika DevOps na kuonyesha mbinu sahihi kwa mfano wako.
Tunafanya mkutano , ambayo hutoa fursa ya kuzama zaidi katika mambo ambayo tumezungumza hivi punde. Kuna vikundi kadhaa vya ripoti kwa hii:
- Taratibu na utamaduni;
- Uhandisi wa Kuegemea wa Tovuti;
- Wingu Native;
Jinsi ya kuchagua mahali pa kwenda? Kuna jambo la hila hapa. Kwa upande mmoja, DevOps inahusu mwingiliano, na tunataka uhudhurie mawasilisho kutoka kwa vizuizi tofauti. Kwa upande mwingine, ikiwa wewe ni meneja wa maendeleo ambaye alikuja kwenye mkutano ili kuzingatia kazi moja maalum, basi hakuna mtu anayekuwekea kikomo - ni wazi, hii itakuwa kizuizi kuhusu michakato na utamaduni. Usisahau kwamba utakuwa na rekodi baada ya mkutano (baada ya kujaza fomu ya maoni), ili uweze kutazama mawasilisho yasiyo muhimu wakati wowote baadaye.
Kwa wazi, katika mkutano yenyewe huwezi kwenda kwenye nyimbo tatu mara moja, kwa hiyo tunapanga programu kwa njia ambayo kila wakati yanayopangwa ina mada kwa kila ladha.
Kilichobaki ni kuelewa nini cha kufanya ikiwa wewe ni mhandisi wa DevOps! Kwanza, jaribu kuamua ni nini hasa unafanya. Kawaida wanapenda kuita neno hili:
- Watengenezaji wanaofanya kazi kwenye miundombinu. Vikundi vya ripoti kuhusu SRE na Cloud Native vinakufaa zaidi.
- Wasimamizi wa mfumo. Ni ngumu zaidi hapa. DevOops haihusu usimamizi wa mfumo. Kwa bahati nzuri, kuna mengi ya mikutano bora, vitabu, makala, video kwenye mtandao, nk juu ya mada ya utawala wa mfumo. Kwa upande mwingine, ikiwa una nia ya kujiendeleza katika suala la kuelewa utamaduni na taratibu, kujifunza kuhusu teknolojia za wingu na maelezo ya maisha na Cloud Native, basi tungependa kukuona! Fikiria kuhusu hili: unafanya utawala, na kisha utafanya nini? Ili kuepuka ghafla kujikuta katika hali mbaya, unapaswa kujifunza sasa.
Kuna chaguo jingine: unaendelea na unaendelea kudai kuwa wewe ni haswa mhandisi wa DevOps na hakuna kitu kingine chochote, chochote kile. Kisha inabidi tukukatishe tamaa, DevOops si mkutano wa wahandisi wa DevOps!
Telezesha kutoka mjini Munich
DevOops 2020 Moscow itafanyika Aprili 29-30 huko Moscow, tikiti tayari zinapatikana. .
Vinginevyo, unaweza hadi Februari 8. Tafadhali kumbuka kuwa unapojaza fomu, lazima uchague hadhira lengwa ambayo itafaidika zaidi na ripoti yako (kuna mshangao umezikwa ndani ya orodha).
Chanzo: mapenzi.com