Je, inachukua nini kwa kampuni ya IT kufanikiwa katika 2019? Wahadhiri kwenye makongamano na mikutano husema maneno mengi ya sauti ambayo si mara zote yanaeleweka kwa watu wa kawaida. Mapambano ya wakati wa kupeleka, huduma ndogo, kuachwa kwa monolith, mabadiliko ya DevOps na mengi zaidi. Ikiwa tunatupa uzuri wa maneno na kuzungumza moja kwa moja na kwa Kirusi, basi yote inakuja kwenye nadharia rahisi: fanya bidhaa ya ubora wa juu, na uifanye kwa faraja kwa timu.
Mwisho umekuwa muhimu sana. Biashara hatimaye imefikia hitimisho kwamba mchakato mzuri wa ukuzaji huongeza tija, na ikiwa kila kitu kitatatuliwa na kufanya kazi kama saa, pia inatoa nafasi ya ujanja katika hali mbaya. Hapo zamani za kale, kwa ajili ya ujanja huu, mtu fulani mwenye akili timamu alikuja na chelezo, lakini tasnia inaendelea, na tulikuja kwa wahandisi wa DevOps - watu ambao hugeuza mchakato wa mwingiliano kati ya maendeleo na miundombinu ya nje kuwa kitu cha kutosha na. haihusiani na shamanism.
Hadithi hii yote ya "msimu" ni ya ajabu, lakini ... Ilifanyika kwamba baadhi ya wasimamizi waliitwa kwa ghafla DevOps, na wahandisi wa DevOps wenyewe walianza kuhitajika kuwa na angalau ujuzi wa telepathy na clairvoyance.
Kabla ya kuzungumzia matatizo ya kisasa ya kutoa miundombinu, hebu tufafanue tunamaanisha nini kwa neno hili. Kwa sasa, hali imekua kwa njia ambayo tumefikia uwili wa dhana hii: miundombinu inaweza kuwa ya nje na ya ndani ya masharti.
Kwa miundombinu ya nje tunamaanisha kila kitu ambacho kinahakikisha utendakazi wa huduma au bidhaa ambayo timu inatengeneza. Hizi ni seva za programu au tovuti, upangishaji na huduma zingine zinazohakikisha utendakazi wa bidhaa.
Miundombinu ya ndani inajumuisha huduma na vifaa ambavyo vinatumiwa na timu ya maendeleo yenyewe na wafanyikazi wengine, ambao kawaida huwa wengi. Hizi ni seva za ndani za mifumo ya uhifadhi wa msimbo, msimamizi wa kazi aliyewekwa ndani na kila kitu, kila kitu, kila kitu kilichopo ndani ya intraneti ya shirika.
Msimamizi wa mfumo hufanya nini katika kampuni? Mbali na kazi ya kusimamia intraneti hii ya ushirika, mara nyingi hubeba mzigo wa maswala ya kiuchumi ili kuhakikisha utendakazi wa vifaa vya ofisi. Msimamizi ni yule yule ambaye ataburuta kwa haraka kitengo kipya cha mfumo au kompyuta ya mkononi ya ziada tayari kwa matumizi kutoka kwenye chumba cha nyuma, atatoa kibodi safi na kutambaa kwa miguu minne kupitia ofisi, akinyoosha kebo ya Ethaneti. Msimamizi ni mmiliki wa ndani na mtawala wa seva za ndani na nje tu, bali pia mtendaji wa biashara. Ndiyo, baadhi ya wasimamizi wanaweza kufanya kazi tu katika mfumo wa ndege, bila vifaa. Wanapaswa kugawanywa katika kitengo tofauti cha "wasimamizi wa mfumo wa miundombinu." Na wengine wamebobea katika kuhudumia vifaa vya ofisi pekee; kwa bahati nzuri, ikiwa kampuni ina zaidi ya watu mia moja, kazi haina mwisho. Lakini hakuna hata mmoja wao ambaye ni waabudu.
DevOps ni nani? Devops ni watu wanaozungumza juu ya mwingiliano wa ukuzaji wa programu na miundombinu ya nje. Kwa usahihi zaidi, wahudumu wa kisasa wanahusika katika mchakato wa ukuzaji na usambazaji kwa undani zaidi kuliko wasimamizi ambao walipakia masasisho kwa ftp waliwahi kuhusika. Mojawapo ya kazi kuu za mhandisi wa DevOps sasa ni kuhakikisha mchakato mzuri na ulioandaliwa vyema wa mwingiliano kati ya timu za maendeleo na miundombinu ya bidhaa. Ni watu hawa ambao wana jukumu la kupeleka mifumo ya kurejesha na kusambaza; ni watu hawa ambao huchukua baadhi ya mzigo kutoka kwa wasanidi programu na kuzingatia iwezekanavyo kwenye kazi yao muhimu sana. Wakati huo huo, devops haitawahi kuendesha kebo mpya au kutoa kompyuta ndogo kutoka chumba cha nyuma (c) KO
Nini samaki?
Kwa swali "DevOps ni nani?" nusu ya wafanyikazi kwenye uwanja huanza kujibu kitu kama "Kweli, kwa kifupi, huyu ndiye msimamizi ambaye ..." na zaidi katika maandishi. Ndio, mara moja, wakati taaluma ya mhandisi wa DevOps ilikuwa inajitokeza tu kutoka kwa wasimamizi wenye vipaji zaidi katika suala la matengenezo ya huduma, tofauti kati yao hazikuwa wazi kwa kila mtu. Lakini sasa, wakati kazi za devops na admin kwenye timu zimekuwa tofauti sana, haikubaliki kuwachanganya na kila mmoja, au hata kuwalinganisha.
Lakini hii ina maana gani kwa biashara?
Kuajiri, yote ni juu yake.
Unafungua nafasi ya "Msimamizi wa Mfumo", na mahitaji yaliyoorodheshwa hapo ni "maingiliano na maendeleo na wateja", "mfumo wa utoaji wa CI/CD", "utunzaji wa seva na vifaa vya kampuni", "usimamizi wa mifumo ya ndani" na kadhalika. juu; unaelewa kuwa mwajiri anaongea upuuzi. Kukamata ni kwamba badala ya "Msimamizi wa Mfumo" kichwa cha nafasi kinapaswa kuwa "DevOps Engineer", na ikiwa kichwa hiki kinabadilishwa, basi kila kitu kinaanguka.
Walakini, mtu hupata maoni gani anaposoma nafasi kama hiyo? Kwamba kampuni inatafuta opereta wa mashine nyingi ambaye atatumia mfumo wa udhibiti wa toleo na ufuatiliaji na atapunguza twister kwa meno yake...
Lakini ili sio kuongeza kiwango cha madawa ya kulevya katika soko la ajira, inatosha kuita nafasi za kazi kwa majina yao sahihi na kuelewa wazi kwamba mhandisi wa DevOps na msimamizi wa mfumo ni vyombo viwili tofauti. Lakini hamu isiyoweza kuzuilika ya waajiri wengine kuwasilisha orodha pana zaidi ya mahitaji kwa mgombea inaongoza kwa ukweli kwamba wasimamizi wa mfumo wa "classic" huacha kuelewa kinachotokea karibu nao. Je, taaluma inabadilika na wako nyuma ya wakati?
Hapana hapana na mara nyingine tena hapana. Wasimamizi wa miundombinu ambao watasimamia seva za ndani za kampuni, au kuchukua nafasi za usaidizi wa L2/L3 na kusaidia wafanyikazi wengine, hawajaondoka na hawataondoka.
Je, wataalamu hawa wanaweza kuwa wahandisi wa DevOps? Bila shaka wanaweza. Kwa kweli, hii ni mazingira yanayohusiana ambayo yanahitaji ujuzi wa utawala wa mfumo, lakini pamoja na hili, kazi na ufuatiliaji, mifumo ya utoaji na, kwa ujumla, ushirikiano wa karibu na timu ya maendeleo na kupima huongezwa.
Tatizo lingine la DevOps
Kwa kweli, kila kitu sio tu kwa kuajiri na kuchanganyikiwa mara kwa mara kati ya wasimamizi na washiriki. Wakati fulani, biashara ilikabiliwa na tatizo la kutoa sasisho na mwingiliano wa timu ya maendeleo na miundombinu ya mwisho.
Labda ilikuwa wakati mjomba mwenye macho ya kumeta alisimama kwenye jukwaa la mkutano fulani na kusema, βTunafanya hivi na kuiita DevOps. Watu hawa watasuluhisha shida zako zote" - na wakaanza kuelezea jinsi maisha yalivyo katika kampuni baada ya kutekeleza mazoea ya DevOps.
Walakini, haitoshi kuajiri mhandisi wa DevOps kufanya kila kitu kifanye kazi inavyopaswa. Ni lazima kampuni ifanyie mabadiliko kamili ya DevOps, yaani, jukumu na uwezo wa DevOps zetu lazima pia zieleweke wazi kwa upande wa timu ya ukuzaji na majaribio ya bidhaa. Tuna hadithi "ya kustaajabisha" juu ya mada hii ambayo inaonyesha kikamilifu ukatili wote unaofanyika katika maeneo fulani.
Hali. DevOps inahitajika kupeleka mfumo wa kurejesha toleo bila kutafakari jinsi utakavyofanya kazi. Wacha tufikirie kuwa ndani ya mfumo wa Watumiaji kuna sehemu tofauti za jina la kwanza, jina la mwisho na nywila. Toleo jipya la bidhaa linatoka, lakini kwa watengenezaji, "kurudisha nyuma" ni wand ya uchawi tu ambayo itarekebisha kila kitu, na hata hawajui jinsi inavyofanya kazi. Kwa hiyo, kwa mfano, katika kiraka kilichofuata watengenezaji waliunganisha mashamba ya jina la kwanza na la mwisho, waliiingiza kwenye uzalishaji, lakini toleo ni polepole kwa sababu fulani. Nini kinaendelea? Usimamizi huja kwa washiriki na kusema "Vuta swichi!", Hiyo ni, unamuuliza arudishe kwenye toleo la awali. Je, devops hufanya nini? Inarudi kwenye toleo la awali, lakini kwa kuwa watengenezaji hawakutaka kujua jinsi urejeshaji huu ulifanyika, hakuna mtu aliyeiambia timu ya devops kwamba hifadhidata pia ilihitaji kurejeshwa. Matokeo yake, kila kitu kinaanguka kwa ajili yetu, na badala ya tovuti ya polepole, watumiaji wanaona kosa la "500", kwa sababu toleo la zamani haifanyi kazi na mashamba ya database mpya. Devops hajui kuhusu hili. Watengenezaji wako kimya. Wasimamizi huanza kupoteza mishipa na pesa zao na wanakumbuka nakala rudufu, wakijitolea kurudisha nyuma kutoka kwao ili "angalau kitu kifanye kazi." Kwa hivyo, watumiaji hupoteza data zao zote kwa muda.
Karanga, bila shaka, huenda kwa devops, ambayo "haikufanya mfumo sahihi wa kurejesha," na hakuna mtu anayejali kwamba moose katika hadithi hii ni watengenezaji.
Hitimisho ni rahisi: bila mbinu ya kawaida ya DevOps kama vile, ni ya matumizi kidogo.
Jambo kuu kukumbuka: mhandisi wa DevOps si mchawi, na bila mawasiliano ya ubora na mwingiliano wa njia mbili na maendeleo, hawezi kukabiliana na kazi zake. Devs hawawezi kuachwa peke yao na "matatizo" yao au kupewa amri "usiingiliane na watengenezaji, kazi yao ni kuweka msimbo," na kisha kutumaini kuwa katika wakati muhimu kila kitu kitafanya kazi inavyopaswa. Sivyo inavyofanya kazi.
Kimsingi, DevOps ni uwezo kwenye mpaka kati ya usimamizi na teknolojia. Zaidi ya hayo, ni mbali na dhahiri kwamba kunapaswa kuwa na teknolojia zaidi kuliko usimamizi katika jogoo hili. Iwapo kweli unataka kuunda michakato ya maendeleo ya haraka na yenye ufanisi zaidi, ni lazima uamini timu yako ya devops. Anajua zana zinazofaa, ametekeleza miradi kama hiyo, anajua jinsi ya kuifanya. Msaidie, sikiliza ushauri wake, usijaribu kumtenga katika aina fulani ya kitengo cha uhuru. Ikiwa wasimamizi wanaweza kufanya kazi peke yao, basi devops haina maana katika kesi hii; hawataweza kukusaidia kuwa bora ikiwa wewe mwenyewe hutaki kukubali msaada huu.
Na jambo la mwisho: kuacha kuwaudhi wasimamizi wa miundombinu. Wana yao wenyewe, muhimu sana mbele ya kazi. Ndio, msimamizi anaweza kuwa mhandisi wa DevOps, lakini hii inapaswa kutokea kwa ombi la mtu mwenyewe, na sio chini ya shinikizo. Na hakuna kitu kibaya na ukweli kwamba msimamizi wa mfumo anataka kubaki msimamizi wa mfumo - hii ni taaluma yake tofauti na haki yake. Ikiwa unataka kufanya mabadiliko ya kitaalam, basi usisahau kamwe kuwa itabidi ujenge sio ujuzi wa kiteknolojia tu, bali pia ule wa usimamizi. Uwezekano mkubwa zaidi, itakuwa juu yako kama kiongozi kuwaleta watu hawa wote pamoja na kuwafundisha kuwasiliana kwa lugha moja.
Chanzo: mapenzi.com