Ufafanuzi wa DevOps ni ngumu sana, kwa hivyo tunapaswa kuanza majadiliano juu yake tena kila wakati. Kuna machapisho elfu moja juu ya mada hii kuhusu Habre pekee. Lakini ikiwa unasoma hii, labda unajua DevOps ni nini. Kwa sababu mimi si. Habari Jina langu ni Alexander Titov (@), na tutazungumza tu kuhusu DevOps na nitashiriki uzoefu wangu.
Nimekuwa nikifikiria kwa muda mrefu kuhusu jinsi ya kufanya hadithi yangu iwe ya manufaa, kwa hivyo kutakuwa na maswali mengi hapa - yale ambayo ninajiuliza na yale ambayo ninawauliza wateja wa kampuni yetu. Kwa kujibu maswali haya, uelewa unakuwa bora. Nitakuambia kwa nini DevOps inahitajika kutoka kwa mtazamo wangu, ni nini, tena, kutoka kwa mtazamo wangu, na jinsi ya kuelewa kuwa unaelekea DevOps tena kutoka kwa mtazamo wangu. Hoja ya mwisho itakuwa kupitia maswali. Kwa kuzijibu mwenyewe, unaweza kuelewa kama kampuni yako inaelekea kwenye DevOps au kama kuna matatizo kwa namna fulani.
Wakati mmoja nilikuwa nikiendesha mawimbi ya muunganisho na ununuzi. Kwanza, nilifanya kazi kwa kampuni ndogo inayoitwa Qik, kisha ikanunuliwa na kampuni kubwa kidogo inayoitwa Skype, ambayo ilinunuliwa na kampuni kubwa kidogo inayoitwa Microsoft. Wakati huo, nilianza kuona jinsi wazo la DevOps lilikuwa likibadilika katika makampuni ya ukubwa tofauti. Baada ya hapo, nilipata nia ya kuangalia DevOps kutoka kwa mtazamo wa soko, na wenzangu na mimi tulianzisha kampuni ya Express 42. Kwa miaka 6 sasa tumekuwa tukihamia kwenye mawimbi ya soko.
Miongoni mwa mambo mengine, mimi ni mmoja wa waandaaji wa jumuiya ya DevOps Moscow na mratibu wa DevOps-Days 2017, lakini sikuandaa 2018. Express 42 inafanya kazi na makampuni mengi. Tunakuza DevOps huko, tazama jinsi inavyofanyika, fanya hitimisho, uchanganue, tuambie kila mtu hitimisho letu, na kuwafunza watu katika mazoezi ya DevOps. Kwa ujumla, tunafanya tuwezavyo ili kuongeza uzoefu na ujuzi wetu katika suala hili.
Kwa nini DevOps
Swali la kwanza ambalo linasumbua kila mtu na daima ni - kwa nini? Watu wengi wanafikiri kwamba DevOps ni otomatiki tu au kitu sawa ambacho kila kampuni tayari ilikuwa nayo.
- Tulikuwa na Ushirikiano Unaoendelea - hii inamaanisha tayari tulikuwa na DevOps, na kwa nini vitu hivi vyote vinahitajika? Wanaburudika nje ya nchi, lakini wanatuzuia kufanya kazi!
Zaidi ya miaka 9 ya maendeleo ya jamii na mbinu, tayari imekuwa wazi kuwa hii bado sio pambo la uuzaji, lakini bado haijulikani kabisa kwa nini inahitajika. Kama zana na mchakato wowote, DevOps ina malengo mahususi ambayo hatimaye hufikia.
Yote hii ni kutokana na ukweli kwamba dunia inabadilika. Anaondoka kutoka kwa mbinu ya biashara, wakati makampuni yanaenda moja kwa moja kuelekea ndoto, kama vile classic yetu ya St.
Kimsingi, kila kitu katika IT kinapaswa kujengwa kulingana na njia hii. Hapa IT inatumiwa pekee kugeuza michakato.
Otomatiki haibadiliki mara nyingi, kwa sababu wakati kampuni inapita chini ya njia iliyokanyagwa vizuri, kuna nini cha kubadilisha? Inafanya kazi - usiiguse. Sasa mbinu ulimwenguni zinabadilika, na ile inayoitwa Agile inapendekeza kwamba sehemu ya mwisho B haionekani mara moja.
Wakati kampuni inapitia soko, inafanya kazi na mteja, inachunguza soko mara kwa mara na kubadilisha hatua ya mwisho B. Zaidi ya hayo, mara nyingi kampuni inabadilisha mwelekeo wake, inafanikiwa zaidi mwisho, kwa sababu inachagua soko zaidi. niches.
Mkakati huo unaonyeshwa na kampuni ya kuvutia ambayo nilijifunza hivi karibuni. One Box Shave ni huduma ya uwasilishaji wa usajili wa nyembe na vifaa vya kunyoa kwenye sanduku. Wanajua jinsi ya kubinafsisha "sanduku" lao kwa wateja tofauti. Hii inafanywa na programu fulani, ambayo kisha hutuma agizo kwa kiwanda cha Kikorea kinachozalisha bidhaa.
Bidhaa hii ilinunuliwa na Unilever kwa $1 bilioni. Sasa inashindana na Gillette na imeondoa sehemu kubwa ya watumiaji katika soko la Amerika. One Box Shave sema:
- 4 vile? Je, uko makini? Kwa nini unahitaji hii - haina kuboresha ubora wa kunyoa. Cream iliyochaguliwa maalum, harufu nzuri na wembe wa hali ya juu na vile viwili hutatua matatizo mengi zaidi kuliko vile vile 4 Gillette za kijinga! Tutafika 10 hivi karibuni?
Hivi ndivyo ulimwengu unavyobadilika. Unilever wanadai kuwa wana mfumo mzuri wa IT unaokuruhusu kufanya hivi. Mwishowe inaonekana kama dhana Muda hadi soko, ambayo hakuna mtu aliyezungumza tayari.
Hatua ya Muda hadi soko sio mara ngapi tunapeleka. Unaweza kusambaza mara nyingi, lakini mizunguko ya kutolewa itakuwa ndefu. Ikiwa mizunguko ya kutolewa kwa miezi mitatu imewekwa juu ya kila mmoja, ikizibadilisha kwa wiki, zinageuka kuwa kampuni inaonekana kupeleka mara moja kwa wiki. Na kutoka kwa wazo hadi utekelezaji wa mwisho inachukua miezi 3.
Muda hadi soko ni kuhusu kupunguza muda kutoka kwa wazo hadi utekelezaji wa mwisho.
Katika kesi hii, programu inaingiliana na soko. Hivi ndivyo tovuti ya One Box Shave inavyoingiliana na mteja. Hawana wauzaji - tovuti tu ambapo wageni bonyeza na kuacha matakwa. Ipasavyo, kitu kipya lazima kiwekwe kila wakati kwenye wavuti na kusasishwa kulingana na matakwa. Kwa mfano, huko Korea Kusini wananyoa tofauti kuliko Urusi, na wanapenda harufu isiyo ya pine, lakini, kwa mfano, ya karoti na vanilla.
Kwa kuwa ni muhimu kubadili haraka maudhui ya tovuti, maendeleo ya programu hubadilika sana. Kupitia programu lazima tujue mteja anataka nini. Hapo awali, tulijifunza hili kupitia baadhi ya njia za mzunguko, kwa mfano, kupitia usimamizi wa biashara. Kisha tulitengeneza, kuweka mahitaji katika mfumo wa IT, na kila kitu kilikuwa kizuri. Sasa ni tofauti - programu imeundwa na kila mtu anayehusika katika mchakato, ikiwa ni pamoja na wahandisi, kwa sababu kupitia vipimo vya kiufundi wanajifunza jinsi soko linavyofanya kazi na pia kushiriki maarifa yao na biashara.
Kwa mfano, huko Qik tulijifunza ghafla kuwa watu walipenda sana kupakia orodha za anwani kwenye seva, na walitupa programu. Hapo awali hatukufikiria juu yake. Katika kampuni ya kawaida, kila mtu angeamua kuwa hii ni mdudu, kwani spec haikusema kwamba inapaswa kufanya kazi vizuri na ilitekelezwa kwa ujumla kwa goti, wangezima kipengele na kusema: "Hakuna mtu anayehitaji hii, jambo la muhimu zaidi ni kwamba utendaji kazi mkuu.β . Na kampuni ya teknolojia inaona hii kama fursa na huanza kubadilisha programu kwa mujibu wa hili.
Mnamo 1968, kijana mwenye maono, Melvin Conway, alitunga wazo lifuatalo.
Shirika linalounda mfumo linabanwa na muundo unaoiga muundo wa mawasiliano wa shirika hilo.
Kwa undani zaidi, ili kuzalisha mifumo ya aina tofauti, lazima pia uwe na muundo wa mawasiliano ndani ya kampuni ya aina tofauti. Ikiwa muundo wako wa mawasiliano ni wa juu-hierarkia, basi hii haitakuwezesha kuunda mifumo ambayo inaweza kutoa kiashiria cha juu sana cha Muda hadi Soko.
Soma mtu anaweza . Ni muhimu kuelewa utamaduni au falsafa ya DevOps kwa sababu kitu pekee ambacho kimsingi hubadilika katika DevOps ni muundo wa mawasiliano kati ya timu.
Kutoka kwa mtazamo wa mchakato, kabla ya DevOps, hatua zote: uchanganuzi, maendeleo, upimaji, uendeshaji, zilikuwa za mstari.
Kwa upande wa DevOps, michakato hii yote hutokea wakati huo huo.
Muda hadi soko ndiyo njia pekee inaweza kufanyika. Kwa watu ambao walifanya kazi katika mchakato wa zamani, hii inaonekana kwa kiasi fulani cosmic, na kwa ujumla hivyo-hivyo.
Kwa hivyo kwa nini unahitaji DevOps?
Kwa maendeleo ya bidhaa za kidijitali. Ikiwa kampuni yako haina bidhaa ya dijiti, DevOps haihitajiki - ni muhimu sana.
DevOps inashinda vizuizi vya kasi vya utengenezaji wa programu mfululizo. Ndani yake taratibu zote hutokea wakati huo huo.
Ugumu unaongezeka. Wakati wainjilisti wa DevOps wanakuambia kuwa itarahisisha kwako kutoa programu, huu ni upuuzi.
Ukiwa na DevOps, mambo yatakuwa magumu zaidi.
Katika mkutano kwenye stendi ya Avito, unaweza kuona jinsi ilivyokuwa kupeleka kontena ya Docker - kazi isiyowezekana. Utata unakuwa mkubwa; lazima ubadilishe mipira mingi kwa wakati mmoja.
DevOps hubadilisha kabisa mchakato na shirika katika kampuni - kwa usahihi zaidi, sio DevOps inayobadilika, lakini bidhaa ya dijiti. Ili kuja kwenye DevOps, bado unahitaji kubadilisha kabisa mchakato huu.
Maswali kwa mtaalamu
Una nini? Maswali ambayo unaweza kujiuliza wakati unafanya kazi katika kampuni na kukuza kama mtaalamu.
Je, una mkakati wa kuunda bidhaa ya kidijitali? Ikiwa iko, tayari ni nzuri. Hii inamaanisha kuwa kampuni yako inaelekea kwenye DevOps.
Je, kampuni yako tayari inaunda bidhaa ya kidijitali? Hii inamaanisha kuwa unaweza kupanda kiwango kingine cha juu na kufanya mambo ya kuvutia zaidi - tena kutoka kwa mtazamo wa DevOps. Ninazungumza tu kutoka kwa mtazamo huu.
Je, kampuni yako ni mojawapo ya viongozi wa soko katika niche ya bidhaa za dijiti? Spotify, Yandex, Uber ni kampuni ambazo ziko kwenye kilele cha maendeleo ya kiteknolojia sasa.
Jiulize maswali haya, na ikiwa majibu yote ni hapana, basi labda hupaswi kufanya DevOps kwenye kampuni hii. Ikiwa mada ya DevOps inakuvutia sana, labda ... unapaswa kuhamia kampuni nyingine? Ikiwa kampuni yako inataka kuingia kwenye DevOps, lakini ukajibu "Hapana" kwa maswali yote, basi ni kama kifaru huyo mrembo ambaye hatabadilika kamwe.
Shirika
Kama nilivyosema, kulingana na Sheria ya Conway, shirika la kampuni linabadilika. Nitaanza na kile kinachozuia DevOps kupenya ndani ya kampuni kutoka kwa mtazamo wa shirika.
Tatizo la "visima"
Neno la Kiingereza "Silo" limetafsiriwa hapa kwa Kirusi kama "vizuri". Suala la tatizo hili ni kwamba hakuna kubadilishana habari kati ya timu. Kila timu inachunguza kwa kina utaalam wake, bila kuunda ramani ya kawaida ya kusogeza.
Kwa njia fulani hii inanikumbusha mtu ambaye amewasili tu huko Moscow na bado hajui jinsi ya kuzunguka ramani ya metro. Muscovites kawaida wanajua eneo lao vizuri, na kote Moscow wanaweza kusafiri kwa kutumia ramani ya metro. Unapokuja Moscow kwa mara ya kwanza, huna ujuzi huu, na umechanganyikiwa tu.
DevOps inapendekeza kupitia wakati huu wa kuchanganyikiwa na idara zote zifanye kazi pamoja ili kuunda ramani ya mwingiliano ya pamoja.
Mambo mawili yanazuia hili.
Matokeo ya mfumo wa usimamizi wa shirika. Imejengwa katika "visima" tofauti vya kihierarkia. Kwa mfano, kuna KPIs fulani katika kampuni zinazounga mkono mfumo huu. Kwa upande mwingine, akili za mtu ambaye ni vigumu kwenda zaidi ya mipaka ya ujuzi wao na kuzunguka mfumo mzima kupata njia. Ni wasiwasi tu. Fikiria kuwa uko kwenye uwanja wa ndege wa Bangkok - hautapata njia yako haraka. DevOps pia ni vigumu kuabiri, na ndiyo maana watu wanasema unahitaji kupata mwongozo ili kufika huko.
Lakini jambo muhimu zaidi ni kwamba shida ya "visima" kwa mhandisi ambaye amejaa roho ya DevOps, amesoma Fowler na kundi la vitabu vingine, inaonyeshwa kwa ukweli kwamba. "visima" havikuruhusu kufanya mambo "dhahiri".. Mara nyingi tunakusanyika baada ya DevOps Moscow, kuzungumza na kila mmoja, na watu wanalalamika:
- Tulitaka tu kuzindua CI, lakini ikawa kwamba usimamizi haukuhitaji.
Hii hutokea hasa kwa sababu CI ΠΈ Mchakato wa Utoaji unaoendelea wako kwenye mpaka wa mitihani mingi. Kwa urahisi bila kushinda shida ya "visima" katika kiwango cha shirika, hautaweza kusonga mbele, haijalishi unafanya nini na haijalishi ni huzuni gani.
Kila mshiriki katika mchakato katika kampuni: watengenezaji wa nyuma na wa mbele, upimaji, DBA, operesheni, mtandao, huchimba kwa mwelekeo wao wenyewe, na hakuna mtu aliye na ramani ya kawaida isipokuwa meneja, ambaye kwa namna fulani anawafuatilia na kuwasimamia kwa kutumia "kugawanya. na kushindaβ mbinu.
Watu wanapigania baadhi ya nyota au bendera, kila mtu anachimba utaalamu wake.
Matokeo yake, wakati kazi inatokea ya kuunganisha haya yote pamoja na kujenga bomba la kawaida, na hakuna tena haja ya kupigana kwa nyota na bendera, swali linatokea - nini cha kufanya hata hivyo? Tunahitaji kufikia makubaliano kwa namna fulani, lakini hakuna mtu aliyetufundisha jinsi ya kufanya hivyo shuleni. Tumefundishwa tangu shuleni: darasa la nane - wow! - ikilinganishwa na darasa la saba! Ni sawa hapa.
Je, ni sawa katika kampuni yako?
Ili kuangalia hili, unaweza kujiuliza maswali yafuatayo.
Je, timu hutumia zana za kawaida na kuchangia mabadiliko kwenye zana hizo za kawaida?
Ni mara ngapi timu hujipanga upyaβbaadhi ya wataalamu kutoka timu moja huhamia timu nyingine? Ni katika mazingira ya DevOps kwamba hii inakuwa ya kawaida, kwa sababu wakati mwingine mtu hawezi kuelewa ni nini eneo lingine la utaalam linafanya. Anahamia idara nyingine, anafanya kazi huko kwa wiki mbili ili kujitengenezea ramani ya mwelekeo na mwingiliano na idara hii.
Je, inawezekana kuunda kamati ya mabadiliko na kubadilisha mambo? Au inahitaji mkono wenye nguvu wa usimamizi na mwelekeo wa juu zaidi? Hivi majuzi niliandika kwenye Facebook jinsi benki moja isiyojulikana inatekeleza zana kwa njia ya maagizo: tunaandika amri, tunatekeleza kwa mwaka, na kuona kinachotokea. Hii, bila shaka, ni ndefu na ya kusikitisha.
Je, kuna umuhimu gani kwa wasimamizi kupokea mafanikio ya kibinafsi bila kuzingatia mafanikio ya kampuni?
Ikiwa utajijibu maswali haya mwenyewe, itakuwa wazi ikiwa una shida kama hiyo katika kampuni yako.
Miundombinu kama kanuni
Baada ya tatizo hili kupitishwa, mazoezi ya kwanza muhimu, bila ambayo ni vigumu kuendeleza zaidi katika DevOps, ni miundombinu kama kanuni.
Mara nyingi, miundombinu kama kanuni hugunduliwa kama ifuatavyo:
- Wacha tubadilishe kila kitu kwa bash, tujifunike na hati ili wasimamizi wawe na kazi ndogo ya mikono!
Lakini hiyo si kweli.
Miundombinu kama msimbo inamaanisha kuwa unaelezea mfumo wa TEHAMA unaofanya nao kazi kwa njia ya msimbo ili kuelewa hali yake kila wakati.
Pamoja na timu zingine, unaunda ramani katika mfumo wa msimbo ambao kila mtu anaweza kuelewa na anaweza kuelekeza na kusogeza. Haijalishi inafanywa nini - Mpishi, Asiyeweza, Chumvi, au kutumia faili za YAML katika Kubernetes - hakuna tofauti.
Katika mkutano huo, mfanyakazi mwenza kutoka 2GIS alielezea jinsi walivyotengeneza vitu vyao vya ndani kwa Kubernetes, ambayo inaelezea muundo wa mifumo ya mtu binafsi. Ili kuelezea mifumo 500, walihitaji zana tofauti ambayo hutoa maelezo haya. Wakati kuna maelezo haya, kila mtu anaweza kuangalia na kila mmoja, kufuatilia mabadiliko, jinsi ya kuibadilisha na kuiboresha, ni nini kinakosekana.
Kubali, hati za bash za kibinafsi kawaida hazitoi ufahamu huu. Katika moja ya kampuni ambapo nilifanya kazi, kulikuwa na hata jina la hati ya "andika tu" - wakati hati imeandikwa, lakini haiwezekani tena kuisoma. Nadhani hii inajulikana kwako pia.
Miundombinu kama kanuni kanuni inayoelezea hali ya sasa ya miundombinu. Timu nyingi za bidhaa, miundombinu na huduma hufanya kazi pamoja kwenye msimbo huu, na muhimu zaidi, zote zinahitaji kuelewa jinsi kanuni hii inavyofanya kazi.
Kanuni hudumishwa kulingana na kanuni bora za kanuni: maendeleo ya pamoja, mapitio ya kanuni, XP-programming, kupima, maombi ya kuvuta, CI kwa miundombinu ya kanuni - yote haya yanafaa na yanaweza kutumika.
Kanuni inakuwa lugha ya kawaida kwa wahandisi wote.
Kubadilisha miundombinu katika kanuni haichukui muda mwingi. Ndiyo, msimbo wa miundombinu unaweza pia kuwa na deni la kiufundi. Kawaida timu hukutana nayo mwaka mmoja na nusu baada ya kuanza kutekeleza "miundombinu kama kanuni" kwa njia ya rundo la maandishi au hata Ansible, ambayo huandika kama msimbo wa tambi, na pia hutupa maandishi ya bash kwenye mchanganyiko!
Ni muhimu: Ikiwa bado haujajaribu vitu hivi, kumbuka hilo Ansible sio bash! Soma nyaraka kwa uangalifu, soma wanachoandika juu yake.
Miundombinu kama kanuni ni mgawanyo wa msimbo wa miundombinu katika tabaka tofauti.
Katika kampuni yetu, tunatofautisha tabaka 3 za msingi, ambazo ni wazi sana na rahisi, lakini kunaweza kuwa na zaidi yao. Unaweza kuangalia msimbo wako wa miundombinu na uambie ikiwa una hali hii au la. Ikiwa hakuna tabaka zilizoangaziwa, basi unahitaji kuchukua muda na urekebishe kidogo.
safu ya msingi - hii ndio jinsi OS, backups na vitu vingine vya kiwango cha chini vinasanidiwa, kwa mfano, jinsi Kubernetes inavyowekwa kwenye kiwango cha msingi.
Kiwango cha huduma - hizi ndizo huduma unazotoa kwa msanidi programu: ukataji miti kama huduma, ufuatiliaji kama huduma, hifadhidata kama huduma, mizani kama huduma, foleni kama huduma, Utoaji Unaoendelea kama huduma - rundo la huduma ambazo timu binafsi inaweza kuleta maendeleo. Haya yote yanahitaji kuelezewa katika moduli tofauti katika mfumo wako wa usimamizi wa usanidi.
Safu ambayo maombi hufanywa na inaeleza jinsi zitakavyojitokeza juu ya tabaka mbili zilizopita.
Maswali ya kudhibiti
Je, kampuni yako ina hazina ya pamoja ya miundombinu? Je, unasimamia deni la kiufundi katika miundombinu yako? Je, unatumia mazoea ya maendeleo katika hazina ya miundombinu? Je, miundombinu yako imegawanywa katika tabaka? Unaweza kuangalia mchoro wa Base-service-APP. Je, ni vigumu kufanya mabadiliko?
Ikiwa umepata uzoefu kwamba ilichukua siku na nusu kufanya mabadiliko, hii inamaanisha kuwa una deni la kiufundi na unahitaji kufanya kazi nayo. Umejikwaa na deni la kiufundi katika nambari yako ya miundombinu. Nakumbuka hadithi nyingi kama hizo wakati, ili kubadilisha CCTL, unahitaji kuandika tena nusu ya nambari ya miundombinu, kwa sababu ubunifu na hamu ya kubinafsisha kila kitu kilisababisha ukweli kwamba kila kitu kimeharibiwa kila mahali, vijiti vyote vimeondolewa, na. inahitajika kurekebisha tena.
Utoaji Unaoendelea
Hebu tulinganishe debit na mkopo. Kwanza inakuja maelezo ya miundombinu, ambayo inaweza kuwa ya msingi kabisa. Sio lazima ueleze kila kitu kwa undani, lakini maelezo fulani ya msingi yanahitajika ili uweze kufanya kazi nayo. Vinginevyo, haijulikani nini cha kufanya na utoaji unaoendelea. Mazoea haya yote hujitokeza kwa wakati mmoja unapokuja kwenye DevOps, lakini huanza na kuelewa ulicho nacho na jinsi ya kukidhibiti. Haya ndiyo mazoezi ya miundombinu kama kanuni.
Inapobainika kuwa unayo na jinsi ya kuidhibiti, unaanza kufikiria jinsi ya kutuma msimbo wa msanidi programu kwa toleo la umma haraka iwezekanavyo. Namaanisha pamoja na msanidi programu - tunakumbuka juu ya shida ya "visima", ambayo ni, sio watu binafsi wanaokuja na hii, lakini timu.
Wakati tuko pamoja Vanya Evtukhovich aliona kitabu cha kwanza Jez Humble na vikundi vya waandishi "Utoaji unaoendelea", ambayo ilitolewa mwaka wa 2009, tulifikiri kwa muda mrefu kuhusu jinsi ya kutafsiri kichwa chake kwa Kirusi. Walitaka kutafsiri kama "Toa kila wakati", lakini, kwa bahati mbaya, ilitafsiriwa kama "Utoaji unaoendelea". Inaonekana kwangu kwamba kuna kitu Kirusi katika jina letu, na shinikizo.
Njia za kutoa kila wakati
Msimbo ulio katika hazina ya bidhaa unaweza kupakuliwa kila wakati hadi kwa uzalishaji. Hawezi kupunguzwa, lakini yuko tayari kila wakati. Ipasavyo, kila wakati unaandika nambari na hisia ngumu-kuelezea ya wasiwasi fulani chini ya mkia wako. Mara nyingi inaonekana unapotoa msimbo wa miundombinu. Hisia hii ya wasiwasi fulani inapaswa kuwepo - inasababisha michakato ya ubongo ambayo inakuwezesha kuandika msimbo tofauti kidogo. Hii inapaswa kurekodiwa katika sheria ndani ya maendeleo.
Ili uwasilishe mara kwa mara, unahitaji umbizo la vizalia vya programu linalotumika kwenye jukwaa la miundombinu. Ikiwa unatupa "taka ya maisha" ya muundo tofauti kwenye jukwaa la miundombinu, basi inakuwa umoja, ni vigumu kudumisha, na tatizo la deni la kiufundi hutokea. Muundo wa vizalia vya programu unahitaji kupangiliwa - hii pia ni kazi ya pamoja: sote tunahitaji kukusanyika, kuchanja akili zetu na kuja na umbizo hili.
Vizalia vya programu vinaboreshwa kila mara na hubadilika kuendana na mazingira ya uzalishaji kadri kinavyosogea kwenye bomba la uwasilishaji. Vizalia vya programu vinaposogezwa kwenye bomba, mara kwa mara hukutana na baadhi ya mambo ambayo ni magumu kwake, ambayo ni sawa na yale ambayo vizalia vya programu unavyoweka katika uzalishaji hukutana nazo. Ikiwa katika maendeleo ya classical hii inafanywa na msimamizi wa mfumo ambaye anafanya usambazaji, basi katika mchakato wa DevOps hii hutokea wakati wote: hapa walijaribu na vipimo vingine, hapa waliitupa kwenye nguzo ya Kubernetes, ambayo inafanana zaidi au chini. kwa uzalishaji, basi ghafla walianza kupima mzigo.
Hii ni ukumbusho wa mchezo wa Pac-Man - vizalia vya programu hupitia aina fulani ya hadithi. Wakati huo huo, ni muhimu kudhibiti ikiwa msimbo unapitia hadithi na kama inahusiana kwa njia fulani na toleo lako la utayarishaji. Hadithi kutoka kwa uzalishaji zinaweza kuburutwa kwenye mchakato wa Utoaji Unaoendelea: ilikuwa hivi wakati kitu kilipoanguka, sasa hebu tupange tu hali hii ndani ya mfumo. Kila wakati msimbo utapitia hali hii pia, na hutakumbana na tatizo hili wakati ujao. Utajua kulihusu mapema zaidi kuliko linavyomfikia mteja wako.
Mikakati tofauti ya kupeleka. Kwa mfano, unatumia majaribio ya AB au matumizi ya canary ili kujaribu msimbo kwa njia tofauti kwa wateja tofauti, kupata maelezo kuhusu jinsi msimbo huo unavyofanya kazi, na mapema zaidi kuliko unapotolewa kwa watumiaji milioni 100.
"Toa mara kwa mara" inaonekana kama hii.
Mchakato wa uwasilishaji wa Dev, CI, Test, PreProd, Prod si mazingira tofauti, hizi ni hatua au vituo vilivyo na pesa zisizoshika moto ambapo vizalia vya programu yako hupita.
Ikiwa una nambari ya miundombinu inayoelezewa kama APP ya Huduma ya Msingi basi inasaidia usisahau maandishi yote, na uyaandike kama msimbo wa vizalia hivi, kukuza vizalia vya programu na ubadilishe unapoenda.
Maswali ya kujipima
Muda kutoka kwa maelezo ya kipengele hadi kutolewa katika toleo la umma katika 95% ya matukio ni chini ya wiki? Je, ubora wa vizalia vya programu huboreka katika kila hatua ya bomba? Je, kuna hadithi ambayo inapitia? Je, unatumia mikakati tofauti ya kupeleka?
Ikiwa majibu yote ni ndio, basi wewe ni mzuri sana! Andika majibu yako katika maoni - nitafurahi).
Maoni
Hili ndilo zoezi gumu kuliko zote. Katika mkutano wa DevOpsConf, mfanyakazi mwenza kutoka Infobip, akizungumza juu yake, alichanganyikiwa kidogo katika maneno yake, kwa sababu hii ni kweli mazoezi magumu sana kuhusu ukweli kwamba unahitaji kufuatilia kila kitu!
Kwa mfano, muda mrefu uliopita, nilipofanya kazi huko Qik na tuligundua kwamba tulihitaji kufuatilia kila kitu. Tulifanya hivi, na sasa tuna vipengee 150 katika Zabbix, ambavyo vinafuatiliwa kila mara. Ilikuwa ya kutisha, mkurugenzi wa kiufundi aligeuza kidole chake kwenye hekalu lake:
- Guys, kwa nini unabaka seva na kitu kisicho wazi?
Lakini basi tukio lilitokea ambalo lilionyesha kuwa huu ni mkakati mzuri sana.
Moja ya huduma ilianza kuharibika kila wakati. Hapo awali, haikuanguka, ambayo inavutia, msimbo haukuongezwa hapo, kwa sababu ilikuwa broker ya msingi, ambayo haikuwa na utendaji wa biashara - ilituma tu ujumbe kati ya huduma za kibinafsi. Huduma haikubadilika kwa miezi 4, na ghafla ilianza kuanguka na kosa la "Segmentation error".
Tulishangaa, tukafungua chati zetu katika Zabbix, na ikawa kwamba wiki moja na nusu iliyopita, tabia ya maombi katika huduma ya API ambayo broker hii anatumia ilibadilika sana. Kisha tuliona kwamba mzunguko wa kutuma aina fulani ya ujumbe ulikuwa umebadilika. Baadaye tuligundua kuwa hawa walikuwa wateja wa android. Tuliuliza:
- Guys, nini kilikupata wiki moja na nusu iliyopita?
Kujibu, tulisikia hadithi ya kupendeza kuhusu jinsi walivyounda upya UI. Haiwezekani kwamba mtu yeyote atasema mara moja kwamba alibadilisha maktaba ya HTTP. Kwa wateja wa Android, ni kama kubadilisha sabuni bafuni - hawakumbuki. Kwa hivyo, baada ya dakika 40 za mazungumzo, tuligundua kuwa walikuwa wamebadilisha maktaba ya HTTP, na saa zake za msingi zilikuwa zimebadilika. Hii ilisababisha tabia ya trafiki kwenye seva ya API kubadilika, ambayo ilisababisha hali iliyosababisha mbio ndani ya wakala, na ilianza kuanguka.
Bila ufuatiliaji wa kina kwa ujumla haiwezekani kufungua hii. Ikiwa shirika bado lina shida ya "visima", wakati kila mtu anatupa pesa kwa kila mmoja, hii inaweza kuishi kwa miaka. Unaanzisha tena seva kwa sababu haiwezekani kutatua shida. Unapofuatilia, kufuatilia, kufuatilia matukio yote uliyo nayo, na kutumia ufuatiliaji kama upimaji - andika msimbo na uonyeshe mara moja jinsi ya kuifuatilia, pia katika mfumo wa nambari (tayari tunayo miundombinu kama nambari), kila kitu kinakuwa wazi jinsi kwenye kiganja. Hata matatizo hayo magumu yanafuatiliwa kwa urahisi.
Kusanya taarifa zote kuhusu kile kinachotokea kwa vizalia vya programu katika kila hatua ya mchakato wa uwasilishaji - si katika uzalishaji.
Pakia ufuatiliaji kwa CI, na baadhi ya mambo ya msingi tayari yataonekana hapo. Baadaye utaziona kwenye Test, PredProd, na majaribio ya upakiaji. Kusanya taarifa katika hatua zote, si tu metriki, takwimu, lakini pia kumbukumbu: jinsi maombi yalivyotolewa, matatizo - kukusanya kila kitu.
Vinginevyo itakuwa vigumu kuitambua. Tayari nilisema kuwa DevOps ni ngumu zaidi. Ili kukabiliana na utata huu, unahitaji kuwa na uchambuzi wa kawaida.
Maswali ya kujidhibiti
Je, ufuatiliaji wako na ukataji miti ni zana ya ukuzaji kwako? Wakati wa kuandika msimbo, je, watengenezaji wako, ikiwa ni pamoja na wewe, hufikiria jinsi ya kuifuatilia?
Je, unasikia kuhusu matatizo kutoka kwa wateja? Je, unamwelewa mteja vizuri zaidi kutokana na ufuatiliaji na ukataji miti? Je, unaelewa mfumo vizuri zaidi kutokana na ufuatiliaji na ukataji miti? Je, unabadilisha mfumo kwa sababu tu uliona kwamba mwenendo katika mfumo unakua na unaelewa kuwa katika wiki nyingine 3 kila kitu kitakufa?
Mara tu ukiwa na sehemu hizi tatu, unaweza kufikiria ni aina gani ya jukwaa la miundombinu ulilonalo katika kampuni yako.
Jukwaa la miundombinu
Jambo sio kwamba ni seti ya zana tofauti ambazo kila kampuni inayo.
Hoja ya jukwaa la miundombinu ni kwamba timu zote zitumie zana hizi na kuziendeleza pamoja.
Ni wazi kwamba kuna timu tofauti ambazo zinawajibika kwa maendeleo ya vipande vya mtu binafsi vya jukwaa la miundombinu. Lakini wakati huo huo, kila mhandisi ana jukumu la ukuzaji, utendakazi na ukuzaji wa jukwaa la miundombinu. Katika ngazi ya ndani inakuwa chombo cha kawaida.
Timu zote hutengeneza jukwaa la miundombinu na kulichukulia kwa uangalifu kama IDE yao wenyewe. Katika IDE yako unasakinisha programu-jalizi tofauti ili kufanya kila kitu kiwe kizuri na cha haraka, na kusanidi hotkeys. Unapofungua Msimbo wa Sublime, Atom au Visual Studio, hitilafu za msimbo zinamiminika na unagundua kuwa haiwezekani kufanya kazi hata kidogo, mara moja unahisi huzuni na unakimbia kurekebisha IDE yako.
Tibu jukwaa lako la miundombinu vivyo hivyo. Ikiwa unaelewa kuwa kuna shida nayo, acha ombi ikiwa huwezi kulirekebisha mwenyewe. Ikiwa kuna kitu rahisi, hariri mwenyewe, tuma ombi la kuvuta, wavulana wataizingatia na kuiongeza. Hii ni mbinu tofauti kidogo ya zana za uhandisi katika kichwa cha msanidi programu.
Jukwaa la miundombinu huhakikisha uhamishaji wa vizalia vya programu kutoka kwa ukuzaji hadi kwa mteja na uboreshaji wa ubora unaoendelea. IP imepangwa kwa seti ya hadithi zinazotokea kwa msimbo katika uzalishaji. Kwa miaka mingi ya maendeleo, kuna hadithi nyingi hizi, baadhi yao ni za kipekee na zinahusiana na wewe pekee - haziwezi kuwekwa kwenye Google.
Katika hatua hii, jukwaa la miundombinu inakuwa faida yako ya ushindani, kwa sababu ina kitu kilichojengwa ndani yake ambacho hakipo kwenye chombo cha mshindani. Kadiri IP yako inavyokuwa ndani zaidi, ndivyo faida yako ya ushindani inavyoongezeka katika suala la Muda hadi soko. Inaonekana hapa tatizo la kufuli kwa muuzaji: Unaweza kuchukua jukwaa la mtu mwingine, lakini kwa kutumia uzoefu wa mtu mwingine, hutaelewa jinsi inavyofaa kwako. Ndiyo, si kila kampuni inaweza kujenga jukwaa kama Amazon. Huu ni mstari mgumu ambapo uzoefu wa kampuni ni muhimu kwa nafasi yake kwenye soko, na huwezi kutumia kufuli kwa muuzaji huko. Hii pia ni muhimu kufikiria.
Mpango
Huu ni mchoro wa msingi wa jukwaa la miundombinu ambalo litakusaidia kusanidi taratibu na taratibu zote katika kampuni ya DevOps.
Hebu tuangalie linajumuisha nini.
Mfumo wa uandaaji wa rasilimali, ambayo hutoa CPU, kumbukumbu, diski kwa programu na huduma zingine. Juu ya hii - huduma za kiwango cha chini: ufuatiliaji, ukataji miti, Injini ya CI/CD, hifadhi ya vizalia vya programu, miundombinu kama msimbo wa mfumo.
Huduma za kiwango cha juu: hifadhidata kama huduma, foleni kama huduma, Salio la Pakia kama huduma, kubadilisha ukubwa wa picha kama huduma, Kiwanda cha Data Kubwa kama huduma. Juu ya hii - bomba ambalo hutoa nambari iliyobadilishwa kila wakati kwa mteja wako.
Unapokea taarifa kuhusu jinsi programu yako inavyofanya kazi kwa mteja, ibadilishe, toa msimbo huu tena, kupokea taarifa - na kwa hivyo unakuza kila mara jukwaa la miundombinu na programu yako.
Katika mchoro, bomba la utoaji lina hatua nyingi. Lakini huu ni mchoro wa kimkakati ambao umetolewa kama mfano - hakuna haja ya kurudia moja baada ya nyingine. Hatua huingiliana na huduma kana kwamba ni hudumaβkila tofali la jukwaa hubeba hadithi yake: jinsi rasilimali zinavyogawiwa, jinsi programu inavyozinduliwa, inafanya kazi kwa kutumia rasilimali, inafuatiliwa na mabadiliko.
Ni muhimu kuelewa kwamba kila sehemu ya jukwaa hubeba hadithi, na ujiulize ni hadithi gani ambayo matofali haya hubeba, labda inapaswa kutupwa na kubadilishwa na huduma ya tatu. Kwa mfano, inawezekana kufunga Okmeter badala ya matofali? Labda wavulana tayari wameendeleza utaalam huu zaidi kuliko sisi. Lakini labda sio - labda tuna utaalamu wa kipekee, tunahitaji kusakinisha Prometheus na kuiendeleza zaidi.
Uundaji wa jukwaa
Huu ni mchakato mgumu wa mawasiliano. Unapokuwa na mazoea ya kimsingi, unaanza mawasiliano kati ya wahandisi na wataalamu tofauti ambao huendeleza mahitaji na viwango, na kuzibadilisha kila mara kwa zana na mbinu tofauti. Utamaduni tulio nao katika DevOps ni muhimu hapa.
Kwa utamaduni kila kitu ni rahisi sana - ni kuhusu ushirikiano na mawasiliano, yaani, tamaa ya kufanya kazi katika uwanja wa kawaida na kila mmoja, tamaa ya kutumia chombo kimoja pamoja. Hakuna sayansi ya roketi hapa - kila kitu ni rahisi sana, banal. Kwa mfano, sote tunaishi kwenye mlango na kuiweka safi - kiwango kama hicho cha kitamaduni.
Una nini?
Tena, maswali unaweza kujiuliza.
Je, jukwaa la miundombinu limejitolea? Nani anawajibika kwa maendeleo yake? Je, unaelewa faida za ushindani za jukwaa lako la miundombinu?
Unahitaji kujiuliza mara kwa mara maswali haya. Ikiwa kitu kinaweza kuhamishiwa kwa huduma za mtu wa tatu, inapaswa kuhamishwa; ikiwa huduma ya mtu wa tatu huanza kuzuia harakati zako, basi unahitaji kujenga mfumo ndani yako.
Kwa hivyo, DevOps...
... huu ni mfumo mgumu, lazima uwe na:
- Bidhaa ya kidijitali.
- Moduli za biashara zinazounda bidhaa hii ya kidijitali.
- Timu za bidhaa zinazoandika msimbo.
- Mbinu za Uwasilishaji Endelevu.
- Majukwaa kama huduma.
- Miundombinu kama huduma.
- Miundombinu kama kanuni.
- Taratibu tofauti za kudumisha kutegemewa, zilizojumuishwa katika DevOps.
- Mazoezi ya maoni ambayo yanaelezea yote.
Unaweza kutumia mchoro huu, ukionyesha ndani yake kile ambacho tayari unacho katika kampuni yako kwa namna fulani: imetengenezwa au bado inahitaji kuendelezwa.
Itaisha baada ya wiki kadhaa . kama sehemu ya RIT++. Njoo kwenye mkutano, ambapo utapata ripoti nyingi nzuri kuhusu utoaji unaoendelea, miundombinu kama msimbo na mabadiliko ya DevOps. , tarehe ya mwisho ya bei ni Mei 20
Chanzo: mapenzi.com