Je, ni vigumu kufahamu jambo kuu unapozungumza kuhusu DevOps? Tumekusanya kwa ajili yako mlinganisho wazi, uundaji wa kushangaza na ushauri kutoka kwa wataalam ambao utasaidia hata wasio wataalamu kupata uhakika. Mwishowe, bonasi ni DevOps za wafanyikazi wa Red Hat.
Neno DevOps lilianzishwa miaka 10 iliyopita na limetoka kwenye hashtag ya Twitter hadi kwenye harakati za kitamaduni zenye nguvu katika ulimwengu wa TEHAMA, falsafa ya kweli ambayo inawahimiza wasanidi programu kufanya mambo kwa haraka, kufanya majaribio, na kuendelea mbele. DevOps imeunganishwa kwa njia isiyoweza kutenganishwa na dhana ya mabadiliko ya kidijitali. Lakini kama inavyotokea mara kwa mara kwa istilahi za TEHAMA, katika kipindi cha miaka kumi iliyopita DevOps imepata ufafanuzi, tafsiri na dhana potofu kujihusu.
Kwa hiyo, mara nyingi unaweza kusikia maswali kuhusu DevOps kama, ni sawa na agile? Au hii ni mbinu maalum? Au ni kisawe kingine cha neno “ushirikiano”?
DevOps inajumuisha dhana nyingi tofauti (uwasilishaji endelevu, ujumuishaji unaoendelea, uwekaji kiotomatiki, n.k.), kwa hivyo kuweka chini kile kilicho muhimu kunaweza kuwa changamoto, haswa unapokuwa na shauku kuhusu mada. Hata hivyo, ujuzi huu ni muhimu sana, bila kujali kama unajaribu kuwasilisha mawazo yako kwa wakuu wako au kumwambia tu mtu kutoka kwa familia yako au marafiki kuhusu kazi yako. Kwa hiyo, hebu tuweke kando nuances ya istilahi ya DevOps kwa sasa na kuzingatia picha kubwa.
DevOps ni nini: 6 Ufafanuzi na Analogies
Tuliwaomba wataalamu kueleza kiini cha DevOps kwa urahisi na kwa ufupi iwezekanavyo ili thamani yake iwe wazi kwa wasomaji wenye kiwango chochote cha ujuzi wa kiufundi. Kulingana na matokeo ya mazungumzo haya, tumechagua mlinganisho wa kuvutia zaidi na uundaji wa kuvutia zaidi ambao utakusaidia kuunda hadithi yako kuhusu DevOps.
1. DevOps ni harakati ya kitamaduni
"DevOps ni vuguvugu la kitamaduni ambalo pande zote mbili (watengenezaji programu na wataalamu wa uendeshaji wa mfumo wa TEHAMA) wanatambua kuwa programu haileti manufaa halisi hadi mtu aanze kuitumia: wateja, wateja, wafanyakazi, sio uhakika," anasema Eveline Oehrlich, mtafiti mkuu. mchambuzi katika Taasisi ya DevOps. "Kwa hivyo, pande zote mbili kwa pamoja zinahakikisha uwasilishaji wa haraka na wa hali ya juu wa programu."
2. DevOps inahusu kuwawezesha wasanidi programu.
"DevOps huwapa wasanidi programu uwezo wa kumiliki programu, kuziendesha, na kudhibiti uwasilishaji kutoka mwanzo hadi mwisho."
"Kwa kawaida, DevOps inazungumzwa kama njia ya kuharakisha uwasilishaji wa maombi kwa uzalishaji kwa kujenga na kutekeleza michakato ya kiotomatiki," anasema Jai Schniepp, mkurugenzi wa majukwaa ya DevOps katika kampuni ya bima ya Liberty Mutual. "Lakini kwangu ni jambo la msingi zaidi." DevOps huwapa wasanidi programu uwezo wa kumiliki programu au vipande mahususi vya programu, kuziendesha, na kudhibiti uwasilishaji wao kuanzia mwanzo hadi mwisho. DevOps huondoa mkanganyiko wa uwajibikaji na huongoza kila mtu anayehusika katika kuunda miundombinu ya kiotomatiki, inayoendeshwa na wasanidi programu.
3. DevOps inahusu ushirikiano katika kuunda na kuwasilisha maombi.
"Kwa ufupi, DevOps ni mbinu ya utengenezaji na utoaji wa programu ambapo kila mtu hufanya kazi pamoja," anasema Gur Staf, rais na mkuu wa otomatiki wa biashara ya dijiti katika BMC.
4. DevOps ni bomba
"Mkusanyiko wa conveyor unawezekana tu ikiwa sehemu zote zitalingana."
"Ningelinganisha DevOps na mstari wa mkutano wa gari," anaendelea Gur Staff. - Wazo ni kuunda na kutengeneza sehemu zote mapema ili ziweze kuunganishwa bila marekebisho ya mtu binafsi. Mkutano wa conveyor unawezekana tu ikiwa sehemu zote zinafaa pamoja. Wale wanaounda na kujenga injini lazima wazingatie jinsi ya kuiweka kwenye mwili au sura. Wale wanaofanya breki lazima wafikirie juu ya magurudumu, na kadhalika. Vile vile inapaswa kuwa kweli na programu.
Msanidi programu anayeunda mantiki ya biashara au kiolesura cha mtumiaji lazima afikirie kuhusu hifadhidata inayohifadhi taarifa za wateja, hatua za usalama za kulinda data ya mtumiaji, na jinsi yote haya yatakavyofanya kazi huduma itakapoanza kutoa hadhira kubwa, labda hata ya mamilioni ya dola. ."
"Kuwafanya watu kushirikiana na kufikiria juu ya sehemu za kazi ambazo wengine wanafanya, badala ya kuzingatia tu kazi zao wenyewe, ndio kikwazo kikuu kushinda. Ikiwa unaweza kufanya hivi, una nafasi nzuri ya mabadiliko ya kidijitali,” anaongeza Gur Staff.
5. DevOps ni mchanganyiko sahihi wa watu, michakato na otomatiki
Jayne Groll, mkurugenzi mtendaji wa Taasisi ya DevOps, alitoa mlinganisho mzuri kuelezea DevOps. Kwa maneno yake, "DevOps ni kama kichocheo kilicho na aina tatu kuu za viungo: watu, mchakato na otomatiki. Viungo hivi vingi vinaweza kuchukuliwa kutoka kwa maeneo mengine na vyanzo: Lean, Agile, SRE, CI / CD, ITIL, uongozi, utamaduni, zana. Siri ya DevOps, kama kichocheo chochote kizuri, ni jinsi ya kupata idadi sahihi na mchanganyiko wa viungo hivi ili kuongeza kasi na ufanisi wa kuunda na kutoa programu.
6. DevOps ni wakati watayarishaji programu hufanya kazi kama timu ya Mfumo 1
"Mbio hazipangwa kuanzia mwanzo hadi mwisho, lakini kinyume chake, kutoka mwisho hadi mwanzo."
"Ninapozungumza juu ya nini cha kutarajia kutoka kwa mpango wa DevOps, ninatumia mfano wa timu ya mbio za NASCAR au Mfumo 1," anasema Chris Short, meneja mkuu wa uuzaji wa jukwaa la wingu katika Red Hat na mchapishaji wa jarida la DevOps'ish. - Kiongozi wa timu kama hiyo ana lengo moja: kuchukua nafasi ya juu kabisa mwishoni mwa mbio, akizingatia rasilimali zinazopatikana kwa timu na changamoto zilizoipata. Katika kesi hii, mbio imepangwa sio kutoka mwanzo hadi mwisho, lakini kinyume chake, kutoka mwisho hadi mwanzo. Kwanza, lengo la kutamani limewekwa, na kisha njia za kufikia hilo zimedhamiriwa. Kisha zinagawanywa katika kazi ndogo na kukabidhiwa kwa washiriki wa timu.
"Timu hutumia wiki nzima kabla ya mbio kukamilisha kituo cha shimo. Anafanya mazoezi ya nguvu na Cardio ili kukaa sawa kwa siku ngumu ya mbio. Mazoezi ya kufanya kazi pamoja ili kutatua matatizo yoyote ambayo yanaweza kutokea wakati wa mbio. Vile vile, timu ya ukuzaji inapaswa kufunza ustadi wa kutoa matoleo mapya mara kwa mara. Ikiwa una ujuzi huo na mfumo wa usalama unaofanya kazi vizuri, uzinduzi wa matoleo mapya katika uzalishaji pia hutokea mara nyingi zaidi. Kwa mtazamo huu wa ulimwengu, kasi iliyoongezeka inamaanisha usalama ulioongezeka,” anasema Short.
“Si juu ya kufanya ‘jambo lililo sawa,’” Short aongeza, “ni juu ya kuondoa mambo mengi iwezekanavyo ambayo yanazuia matokeo yanayotarajiwa. Shirikiana na ubadilishe kulingana na maoni unayopokea kwa wakati halisi. Kuwa tayari kwa hitilafu na ujitahidi kuboresha ubora ili kupunguza athari zake kwenye maendeleo kuelekea lengo lako. Hiki ndicho kinachotungoja katika ulimwengu wa DevOps.”
Jinsi ya kuongeza DevOps: Vidokezo 10 kutoka kwa wataalam
Ni kwamba DevOps na DevOps nyingi ni vitu tofauti kabisa. Tutakuambia jinsi ya kuondokana na vikwazo kwenye njia kutoka kwa kwanza hadi ya pili.
Kwa mashirika mengi, safari ya DevOps huanza kwa urahisi na kwa kupendeza. Timu ndogo za shauku huundwa, michakato ya zamani inabadilishwa na mpya, na mafanikio ya kwanza sio muda mrefu kuja.
Ole, hii ni glitz ya uwongo, udanganyifu wa maendeleo, anasema Ben Grinnell, mkurugenzi mkuu na mkuu wa dijiti katika kampuni ya ushauri ya North Highland. Ushindi wa mapema hakika unatia moyo, lakini hausaidii kufikia lengo kuu la kupitishwa kwa DevOps kote shirika.
Ni rahisi kuona kwamba matokeo yake ni utamaduni wa mgawanyiko kati ya "sisi" na "wao".
"Mara nyingi, mashirika huzindua miradi hii ya upainia ikifikiri kuwa itafungua njia kwa DevOps ya kawaida, bila kuzingatia kama wengine wataweza au tayari kufuata njia hiyo," anaelezea Ben Grinnell. - Timu za kutekeleza miradi kama hii kwa kawaida huajiriwa kutoka kwa "Varangi" wanaojiamini ambao tayari wamefanya kitu kama hicho katika maeneo mengine, lakini ni wapya kwa shirika lako. Wakati huo huo, wanahimizwa kuvunja na kuharibu sheria ambazo zinabaki kumfunga kila mtu mwingine. Ni rahisi kuona kwamba matokeo ni utamaduni wa "sisi" na "wao" ambao unazuia uhamisho wa ujuzi na ujuzi."
"Na shida hii ya kitamaduni ni moja tu ya sababu ambazo DevOps ni ngumu kuongeza. Timu za DevOps zinakabiliwa na changamoto za kiufundi zilizoongezeka ambazo ni kawaida kwa kampuni zinazokua haraka za IT-kwanza, "alisema Steve Newman, mwanzilishi na mwenyekiti wa Scalyr.
"Katika ulimwengu wa kisasa, huduma hubadilika mara tu hitaji linapotokea. Ni vyema kutekeleza mara kwa mara na kutekeleza vipengele vipya, lakini kuratibu mchakato huu na kuondoa matatizo yanayotokea ni maumivu ya kichwa halisi, anaongeza Steve Newman. - Katika mashirika yanayokua kwa kasi sana, wahandisi kwenye timu zinazofanya kazi mbalimbali hujitahidi kudumisha mwonekano katika mabadiliko na athari za kiwango cha utegemezi zinazoibua. Isitoshe, wahandisi hawafurahii wanaponyimwa fursa hii na, kwa sababu hiyo, inakuwa vigumu kwao kuelewa kiini cha matatizo yanayotokea.”
Jinsi ya kushinda changamoto hizi zilizoelezwa hapo juu na kuhamia kwenye upitishaji wa wingi wa DevOps katika shirika kubwa? Wataalamu wanahimiza uvumilivu, hata kama lengo lako kuu ni kuharakisha mzunguko wako wa ukuzaji wa programu na michakato ya biashara.
1. Kumbuka kwamba mabadiliko ya utamaduni huchukua muda.
Jayne Groll, Mkurugenzi Mtendaji, Taasisi ya DevOps: "Kwa maoni yangu, upanuzi wa DevOps unapaswa kuwa wa kuongezeka na wa kurudia kama maendeleo ya haraka (na kugusa kwa usawa utamaduni). Agile na DevOps zinasisitiza timu ndogo. Lakini kadiri timu hizi zinavyokua kwa idadi na muunganisho, tunaishia na watu wengi zaidi kutumia njia mpya za kufanya kazi, na matokeo yake kuna mabadiliko makubwa ya kitamaduni.
2. Tumia muda wa kutosha kupanga na kuchagua jukwaa
Eran Kinsbruner, Mwinjilisti Kiongozi wa Kiufundi huko Perfecto: "Ili kuongeza kazi, timu za DevOps lazima kwanza zijifunze kuchanganya michakato ya kitamaduni, zana, na ujuzi, na kisha kulea na kuleta utulivu kwa kila awamu ya kibinafsi ya DevOps. Yote huanza na upangaji makini wa hadithi za watumiaji na mitiririko ya thamani, ikifuatiwa na kuandika programu na udhibiti wa toleo kwa kutumia ukuzaji wa msingi wa shina au mbinu zingine zinazofaa zaidi kwa matawi na kuunganisha msimbo.
"Kisha inakuja hatua ya ujumuishaji na majaribio, ambapo jukwaa linaloweza kuongezeka la otomatiki tayari linahitajika. Hapa ndipo ni muhimu kwa timu za DevOps kuchagua jukwaa sahihi linalolingana na kiwango chao cha ujuzi na malengo ya mwisho ya mradi.
Awamu inayofuata ni kupelekwa kwa uzalishaji na hii inapaswa kuwa ya kiotomatiki kikamilifu kwa kutumia zana za orchestration na kontena. Ni muhimu kuwa na mazingira yaliyoboreshwa katika hatua zote za DevOps (simulizi ya utayarishaji, mazingira ya QA, na mazingira halisi ya uzalishaji) na kila wakati utumie data ya hivi punde tu kwa majaribio ili kupata hitimisho linalofaa. Lazima uchanganuzi ziwe mahiri na zenye uwezo wa kuchakata data kubwa na maoni ya haraka na yanayotekelezeka."
3. Ondoa hatia nje ya wajibu.
Gordon Haff, Mwinjilisti wa RedHat: "Kuunda mfumo na mazingira ambayo huruhusu na kuhimiza majaribio huruhusu kile kinachojulikana kama kutofaulu katika ukuzaji wa programu ya kisasa. Hii haimaanishi kuwa hakuna mtu mwingine anayewajibika kwa kushindwa. Kwa kweli, kutambua ni nani anayehusika inakuwa rahisi zaidi, kwa kuwa “kuwajibika” hakumaanishi tena “kusababisha ajali.” Hiyo ni, kiini cha uwajibikaji hubadilika kwa ubora. Mambo manne huwa muhimu: kiwango cha usumbufu, mbinu, michakato ya uzalishaji na motisha. (Unaweza kusoma zaidi kuhusu mambo haya katika makala ya Gordon Huff "Masomo ya DevOps: vipengele 4 vya majaribio ya afya.")
4. Futa njia mbele
Ben Grinnell, mkurugenzi mkuu na mkuu wa dijiti katika shirika la ushauri North Highland: "Ili kufikia kiwango, ninapendekeza kuzindua programu ya "kusafisha njia" pamoja na miradi ya upainia. Lengo la mpango huu ni kusafisha takataka ambazo waanzilishi wa DevOps huacha, kama sheria zilizopitwa na wakati na mambo kama hayo, ili njia ya kusonga mbele ibaki wazi.
"Wape watu usaidizi wa shirika na kasi kupitia mawasiliano ambayo yanapita zaidi ya kikundi cha waanzilishi kwa kusherehekea sana mafanikio ya njia mpya za kufanya kazi. Kocha watu ambao wanahusika katika wimbi linalofuata la miradi ya DevOps na wana wasiwasi kuhusu kutumia DevOps kwa mara ya kwanza. Na kumbuka kwamba watu hawa ni tofauti sana na mapainia.”
5. Democratize zana
Steve Newman, mwanzilishi na mwenyekiti wa Scalyr: "Zana hazipaswi kufichwa kutoka kwa watu, na zinapaswa kuwa rahisi kujifunza kwa mtu yeyote aliye tayari kuweka wakati. Ikiwa uwezo wa kuuliza kumbukumbu umezuiwa kwa watu watatu "walioidhinishwa" kutumia zana, utakuwa na idadi ya juu zaidi ya watu watatu ili kushughulikia tatizo hilo, hata kama una mazingira makubwa sana ya kompyuta. Kwa maneno mengine, kuna tatizo hapa ambalo linaweza kusababisha madhara makubwa (ya kibiashara).”
6. Unda hali bora kwa kazi ya timu
Tom Clark, mkuu wa Jukwaa la Kawaida huko ITV: "Unaweza kufanya chochote, lakini sio kila kitu mara moja. Kwa hivyo weka malengo makubwa, anza kidogo, na usonge mbele kwa kurudia haraka. Baada ya muda, utasitawisha sifa ya kufanya mambo, hivyo wengine watataka kutumia mbinu zako pia. Na usijali kuhusu kuunda timu yenye ufanisi. Badala yake, wape watu mazingira bora ya kufanya kazi na ufanisi utafuata.
7. Usisahau kuhusu Sheria ya Conway na bodi za Kanban
Logan Daigle, Mkurugenzi wa Utoaji Programu na Mkakati wa DevOps katika CollabNetVersionOne: “Ni muhimu kuelewa matokeo ya Sheria ya Conway. Katika tafsiri yangu huru, sheria hii inasema kwamba bidhaa tunazounda na taratibu tunazotumia kufanya hivyo, ikiwa ni pamoja na DevOps, zinageuka kuwa zimeundwa kwa njia sawa na shirika letu.
"Ikiwa kuna silo nyingi katika shirika, na udhibiti unabadilika mara nyingi wakati wa kupanga, kujenga na kutoa programu, athari ya kuongeza itakuwa sifuri au ya muda mfupi. Ikiwa shirika litaunda timu zinazofanya kazi mbalimbali karibu na bidhaa zinazofadhiliwa kwa kuzingatia soko, basi nafasi za kufaulu huongezeka sana.
"Kipengele kingine muhimu cha kuongeza ukubwa ni kuonyesha kazi zote zinazoendelea (WIP, workinprogress) kwenye bodi za Kanban. Shirika linapokuwa na mahali ambapo watu wanaweza kuona mambo haya, linahimiza sana ushirikiano, jambo ambalo lina matokeo chanya katika kuongeza kiwango.”
8. Tafuta makovu ya zamani
Manuel Pais, mshauri wa DevOps na mwandishi mwenza wa Topologi za Timu: "Kuchukua mazoea ya DevOps zaidi ya Dev na Ops yenyewe na kujaribu kuyatumia kwa vitendaji vingine sio njia bora. Hii hakika itakuwa na athari fulani (kwa mfano, kwa kudhibiti kiotomatiki kwa mikono), lakini mengi zaidi yanaweza kupatikana ikiwa tutaanza kwa kuelewa michakato ya uwasilishaji na maoni."
"Ikiwa kuna makovu ya zamani katika mfumo wa IT wa shirika - taratibu na njia za usimamizi ambazo zilitekelezwa kama matokeo ya matukio ya zamani, lakini zimepoteza umuhimu wake (kutokana na mabadiliko ya bidhaa, teknolojia au michakato) - basi hakika zinahitaji kuondolewa. au kusuluhishwa, badala ya kuorodhesha michakato isiyofaa au isiyo ya lazima.
9. Usizalishe chaguo za DevOps
Anthony Edwards, Mkurugenzi wa Uendeshaji katika Eggplant: "DevOps ni neno lisiloeleweka sana, kwa hivyo kila timu huishia na toleo lake la DevOps. Na hakuna kitu kibaya zaidi wakati shirika lina ghafla aina 20 za DevOps ambazo haziendani vizuri sana. Haiwezekani kwa kila moja ya timu tatu za maendeleo kuwa na kiolesura chao, maalum kati ya maendeleo na usimamizi wa bidhaa. Wala bidhaa hazipaswi kuwa na matarajio yao ya kipekee ya kushughulikia maoni zinapohamishiwa kwenye kiigaji cha uzalishaji. Vinginevyo, hautaweza kuongeza kiwango cha DevOps."
10. Hubiri thamani ya biashara ya DevOps
Steve Newman, mwanzilishi na mwenyekiti wa Scalyr: "Fanya kazi kutambua thamani ya DevOps. Jifunze na ujisikie huru kuzungumza juu ya faida za kile unachofanya. DevOps ni njia nzuri ya kuokoa muda na pesa (fikiria tu: muda mdogo wa kupumzika, muda mfupi wa wastani wa kurejesha), na timu za DevOps lazima zisisitize bila kuchoka (na kuhubiri) umuhimu wa mipango hii kwa mafanikio ya biashara. Kwa njia hii unaweza kupanua mduara wa wafuasi na kuongeza ushawishi wa DevOps katika shirika.
BONUS
Cha DevOps zetu wenyewe zitawasili Septemba 13 - ndiyo, Red Hat, kama mtengenezaji wa programu, ana timu na mazoezi yake ya DevOps.
Mhandisi wetu Mark Birger, ambaye hutengeneza huduma za otomatiki za ndani kwa vikundi vingine kote katika shirika, atasimulia hadithi yake mwenyewe kwa Kirusi safi - jinsi timu ya Red Hat DevOps ilivyohamisha programu kutoka kwa mazingira ya mtandaoni ya Hat Virtualization inayodhibitiwa na Ansible hadi kwenye umbizo la chombo kamili kwenye jukwaa la OpenShift.
Lakini sio hivyo tu:
Mara tu mashirika yamehamisha mzigo wa kazi kwenye kontena, mbinu za kawaida za ufuatiliaji wa programu zinaweza zisifanye kazi. Katika mazungumzo ya pili tutaelezea msukumo wetu wa kubadilisha njia ya kuweka kumbukumbu na kuonyesha mwendelezo wa njia iliyotupeleka kwenye njia za kisasa za ukataji miti na ufuatiliaji.
Chanzo: mapenzi.com