Swali "jinsi ya kutekeleza devops" imekuwa karibu kwa miaka mingi, lakini hakuna vifaa vingi vyema. Wakati mwingine huwa mwathirika wa matangazo kutoka kwa washauri wasio-smart ambao wanahitaji kuuza wakati wao, bila kujali jinsi gani. Wakati mwingine haya ni maneno yasiyoeleweka, ya jumla sana juu ya jinsi meli za mashirika makubwa hulima anga za ulimwengu. Swali linatokea: hii inatuhusu nini? Mwandishi mpendwa, unaweza kuunda mawazo yako kwa uwazi katika orodha?
Yote hii inatokana na ukweli kwamba sio mazoezi mengi ya kweli na uelewa wa matokeo ya mabadiliko ya utamaduni wa kampuni umekusanya. Mabadiliko katika utamaduni ni mambo ya muda mrefu, matokeo ambayo hayataonekana kwa wiki au mwezi. Tunahitaji mtu mwenye umri wa kutosha kuona jinsi makampuni yamejengwa na kushindwa kwa miaka mingi.
John Willis - mmoja wa baba wa DevOps. John ana uzoefu wa miongo kadhaa kufanya kazi na idadi kubwa ya makampuni. Hivi majuzi, John alianza kugundua mifumo maalum ambayo hufanyika wakati wa kufanya kazi na kila mmoja wao. Kwa kutumia archetypes hizi, John huongoza makampuni kwenye njia ya kweli ya mabadiliko ya DevOps. Soma zaidi kuhusu archetypes hizi katika tafsiri ya ripoti yake kutoka kwa mkutano wa DevOops 2018.
Kuhusu mzungumzaji:
Zaidi ya miaka 35 katika usimamizi wa IT, walishiriki katika uundaji wa mtangulizi wa OpenCloud huko Canonical, walishiriki katika kuanza 10, mbili ambazo ziliuzwa kwa Dell na Docker. Kwa sasa yeye ni Makamu wa Rais wa DevOps na Digital Practices katika SJ Technologies.
Ifuatayo ni hadithi kutoka kwa mtazamo wa Yohana.
Jina langu ni John Willis na mahali rahisi zaidi kunipata ni kwenye Twitter, . Nina lakabu sawa kwenye Gmail na GitHub. A unaweza kupata rekodi za video za ripoti zangu na mawasilisho kwao.
Nina mikutano mingi na CIO za makampuni mbalimbali makubwa. Mara nyingi sana wanalalamika kwamba hawaelewi DevOps ni nini, na kila mtu anayejaribu kuwaelezea anazungumzia kitu tofauti. Malalamiko mengine ya kawaida ni kwamba DevOps haifanyi kazi, ingawa inaonekana kuwa wakurugenzi wanafanya kila kitu kama walivyofafanuliwa. Tunazungumza juu ya kampuni kubwa ambazo zina zaidi ya miaka mia moja. Baada ya kuzungumza nao, nilifikia hitimisho kwamba kwa matatizo mengi, sio teknolojia ya juu ambayo inafaa zaidi, lakini ufumbuzi wa chini wa teknolojia. Kwa wiki kadhaa nilizungumza na watu kutoka idara mbalimbali. Unachokiona kwenye picha ya kwanza kabisa kwenye chapisho ni mradi wangu wa mwisho, hivi ndivyo chumba kilivyoonekana baada ya siku tatu za kazi.
DevOps ni nini?
Hakika, ukiuliza watu 10 tofauti, watatoa majibu 10 tofauti. Lakini hapa kuna jambo la kufurahisha: majibu yote kumi haya yatakuwa sahihi. Hakuna jibu lisilo sahihi hapa. Nilikuwa ndani kabisa ya DevOps, kwa takriban miaka 10, na nilikuwa Mmarekani wa kwanza kwenye DevOpsDay ya kwanza. Sitasema kuwa mimi ni mwerevu kuliko kila mtu anayehusika katika DevOps, lakini hakuna mtu yeyote ambaye ametumia juhudi nyingi juu yake. Ninaamini kuwa DevOps hutokea wakati mtaji na teknolojia hukutana. Mara nyingi tunasahau juu ya hali ya kibinadamu, ingawa tunazungumza mengi juu ya kila aina ya tamaduni.
Sasa tuna data nyingi, miaka mitano ya utafiti wa kitaaluma, upimaji wa nadharia kwa kiwango cha viwanda. Kile ambacho tafiti hizi hutuambia ni kwamba ukichanganya baadhi ya mifumo ya kitabia katika utamaduni wa shirika, unaweza kufikia kasi ya 2000x. Uongezaji kasi huu unalinganishwa na uboreshaji sawa wa uthabiti. Hiki ni kipimo cha kiasi cha manufaa ambayo DevOps inaweza kuleta kwa kampuni yoyote. Miaka michache iliyopita, nilikuwa nikizungumza kuhusu DevOps kwa Mkurugenzi Mtendaji wa kampuni ya Fortune 5000. Nilipokuwa nikijiandaa kwa uwasilishaji, nilikuwa na wasiwasi sana kwa sababu nilipaswa kufupisha uzoefu wangu wa miaka katika dakika 5.
Mwishoni nilitoa yafuatayo Ufafanuzi wa DevOps: Ni seti ya mazoea na mifumo inayowezesha mabadiliko ya mtaji wa watu kuwa mtaji wa shirika wenye utendaji wa juu. Mfano ni jinsi Toyota ilivyofanya kazi kwa miaka 50 au 60 iliyopita.
(Hapo awali, michoro kama hii haitolewi kama nyenzo za kumbukumbu, lakini kama vielelezo. Maudhui yao yatatofautiana kwa kila kampuni mpya. Hata hivyo, picha inaweza kutazamwa tofauti na kupanuliwa.
Moja ya mazoea yenye mafanikio zaidi ni thamani ya ramani ya mkondo. Vitabu vingi vyema vimeandikwa kuhusu hili, vilivyofanikiwa zaidi ni vya Karen Martin. Lakini zaidi ya mwaka uliopita, nimekuja kumalizia kwamba hata mbinu hii ni ya juu sana. Hakika ina faida nyingi na nimeitumia sana. Lakini Mkurugenzi Mtendaji anapokuuliza kwa nini kampuni yake haiwezi kubadili reli mpya, ni mapema mno kuzungumza kuhusu ramani ya mtiririko wa thamani. Kuna maswali mengi zaidi ya msingi ambayo lazima kwanza yajibiwe.
Nadhani kosa la wenzangu wengi ni kwamba wanaipa kampuni mwongozo wa pointi tano kisha wanarudi miezi sita baadaye na kuona kilichotokea. Hata mpango mzuri kama ramani ya mtiririko wa thamani una, wacha tuseme, maeneo yasiyoonekana. Baada ya mamia ya mahojiano na wakurugenzi wa makampuni mbalimbali, nimeunda muundo fulani ambao unatuwezesha kugawanya tatizo katika vipengele vyake, na sasa tutajadili kila moja ya vipengele hivi kwa utaratibu. Kabla ya kutumia ufumbuzi wowote wa kiteknolojia, ninatumia muundo huu, na kwa sababu hiyo, kuta zangu zote zimefunikwa na michoro. Hivi majuzi nilikuwa nikifanya kazi na mfuko wa pamoja na niliishia na miradi kama hiyo 100-150.
Utamaduni mbaya hula mbinu nzuri za kifungua kinywa
Wazo kuu ni hili: hakuna kiasi cha Lean, Agile, SAFE na DevOps kitasaidia ikiwa utamaduni wa shirika yenyewe ni mbaya. Ni kama kupiga mbizi hadi kilindini bila vifaa vya kuteleza au kufanya kazi bila x-ray. Kwa maneno mengine, kufafanua Drucker na Deming: utamaduni mbaya wa shirika utameza mfumo wowote mzuri bila kuisonga.
Ili kutatua tatizo hili kuu, unahitaji kuchukua hatua zifuatazo:
- Fanya Kazi Zote Zionekane: unahitaji kufanya kazi yote ionekane. Sio kwa maana kwamba lazima ionyeshwe kwenye skrini fulani, lakini kwa maana kwamba lazima ionekane.
- Mifumo ya Usimamizi wa Kazi iliyojumuishwa: mifumo ya usimamizi inahitaji kuunganishwa. Katika tatizo la ujuzi wa "kikabila" na ujuzi wa taasisi, katika kesi 9 kati ya 10 vikwazo ni watu. Katika kitabu tatizo lilikuwa kwa mtu mmoja, Brent, ambaye alisababisha mradi huo kuwa nyuma kwa muda wa miaka mitatu. Na mimi huingia kwenye "Brents" hizi kila mahali. Ili kutatua vikwazo hivi, ninatumia vitu viwili vinavyofuata kwenye orodha yetu.
- Nadharia ya Mbinu za Vikwazo: nadharia ya vikwazo.
- Udukuzi wa ushirikiano: hacks za ushirikiano.
- Toyota Kata (): Sitazungumza mengi kuhusu Toyota Kata. Ikiwa nia, kwenye github yangu karibu kila moja ya mada hizi.
- Shirika Linaloelekeza Soko: shirika lenye mwelekeo wa soko.
- Wakaguzi wa Shift-kushoto: ukaguzi katika hatua za mwanzo za mzunguko.
Ninaanza kufanya kazi na shirika kwa urahisi sana: Ninaenda kwa kampuni na kuzungumza na wafanyikazi. Kama unaweza kuona, hakuna teknolojia ya juu. Unachohitaji ni kitu cha kuandika. Ninakusanya timu kadhaa katika chumba kimoja na kuchambua kile wanachoniambia kutoka kwa mtazamo wa archetypes yangu 7. Na kisha ninawapa alama wenyewe na kuwauliza waandike ubaoni kila kitu ambacho wamesema kwa sauti hadi sasa. Kawaida katika aina hizi za mikutano kuna mtu mmoja ambaye anaandika kila kitu, na bora anaweza kuandika 10% ya majadiliano. Kwa njia yangu, takwimu hii inaweza kuinuliwa hadi karibu 40%.
(Mchoro huu unaweza kutazamwa tofauti )
Mtazamo wangu unatokana na kazi ya William Schneider. ) Mbinu hiyo inategemea wazo kwamba shirika lolote linaweza kugawanywa katika viwanja vinne. Mpango huu kwangu kwa kawaida ni matokeo ya kufanya kazi na mamia ya miradi mingine ambayo hutokea wakati wa kuchanganua shirika. Tuseme tuna shirika lenye kiwango cha juu cha udhibiti, lakini kwa uwezo mdogo. Hili ni chaguo lisilofaa sana: wakati kila mtu anapiga mstari, lakini hakuna anayejua la kufanya.
Chaguo bora zaidi ni moja yenye kiwango cha juu cha udhibiti na uwezo. Ikiwa kampuni kama hiyo ina faida, basi labda hauitaji DevOps. Inavutia zaidi kufanya kazi na kampuni ambayo ina kiwango cha juu cha udhibiti, uwezo mdogo na ushirikiano, lakini wakati huo huo kiwango cha juu cha utamaduni (kilimo). Hii ina maana kwamba kampuni ina watu wengi ambao wanapenda kufanya kazi huko na mauzo ya kazi ni ndogo.
(Mchoro huu unaweza kutazamwa tofauti )
Inaonekana kwangu kuwa njia zilizo na miongozo migumu huishia kupata njia ya kufikia ukweli. Katika ramani ya mtiririko wa thamani haswa, kuna sheria nyingi kuhusu jinsi habari inapaswa kupangwa. Katika hatua za mwanzo za kazi, ambazo ninazungumzia sasa, hakuna mtu anayehitaji sheria hizi. Ikiwa mtu aliye na alama mikononi mwake anaelezea hali halisi katika kampuni kwenye ubao, hii ndiyo njia bora ya kuelewa hali ya mambo. Taarifa kama hizo hazifiki kwa wakurugenzi. Kwa wakati huu, ni ujinga kumkatisha mtu na kusema kwamba alichora aina fulani ya mshale vibaya. Katika hatua hii, ni bora kutumia sheria rahisi, kwa mfano: uondoaji wa ngazi nyingi unaweza kuundwa kwa kutumia alama za rangi nyingi.
Narudia, hakuna teknolojia ya juu. Alama nyeusi inaonyesha ukweli halisi wa jinsi kila kitu kinavyofanya kazi. Kwa alama nyekundu, watu huweka alama kile wasichopenda kuhusu hali ya sasa ya mambo. Ni muhimu waandike haya, sio mimi. Ninapoenda kwa CIO baada ya mkutano, sitoi orodha ya mambo 10 ambayo yanahitaji kurekebishwa. Ninajitahidi kutafuta miunganisho kati ya kile watu katika kampuni wanasema na mifumo iliyopo iliyothibitishwa. Hatimaye, alama ya bluu inapendekeza ufumbuzi iwezekanavyo kwa tatizo.
(Mchoro huu unaweza kutazamwa tofauti )
Mfano wa mbinu hii sasa umeonyeshwa hapo juu. Mwanzoni mwa mwaka huu nilifanya kazi na benki moja. Watu wa usalama huko walikuwa wameshawishika kwamba hawapaswi kuja kubuni na ukaguzi wa mahitaji.
(Mchoro huu unaweza kutazamwa tofauti )
Na kisha tulizungumza na watu kutoka idara zingine na ikawa kwamba karibu miaka 8 iliyopita, watengenezaji wa programu waliwafuta wafanyikazi wa usalama kwa sababu walikuwa wakipunguza kazi. Na kisha ikageuka kuwa marufuku, ambayo ilichukuliwa kuwa ya kawaida. Ingawa kwa kweli hakukuwa na marufuku.
Mkutano wetu uliendelea kwa njia ya kutatanisha sana: kwa takriban saa tatu, timu tano tofauti hazikuweza kunieleza kilichokuwa kikiendelea kati ya kanuni na mkutano. Na hii inaweza kuonekana kuwa jambo rahisi zaidi. Washauri wengi wa DevOps wanadhania kwamba kila mtu tayari anajua hili.
Kisha mtu anayesimamia utawala wa IT, ambaye alikuwa kimya kwa saa nne, ghafla aliishi tulipofika kwenye mada yake, na akatuchukua kwa muda mrefu sana. Mwishoni nilimuuliza anafikiria nini kuhusu mkutano huo, na sitasahau jibu lake kamwe. Alisema: "Nilikuwa nikifikiri kwamba benki yetu ilikuwa na njia mbili tu za kusambaza programu, lakini sasa najua kuwa kuna tano kati ya hizo, na hata sikuzijua tatu."
(Mchoro huu unaweza kutazamwa tofauti )
Mkutano wa mwisho katika benki hii ulikuwa na timu ya programu ya uwekezaji. Ilikuwa pamoja naye kwamba iliibuka kuwa kuandika michoro na alama kwenye karatasi ni bora kuliko kwenye ubao, na bora zaidi kuliko kwenye ubao mahiri.
Picha unazoziona ni jinsi chumba cha mikutano cha hoteli kilivyoonekana katika siku ya nne ya mkutano wetu. Na tulitumia miradi hii kutafuta mifumo, ambayo ni, archetypes.
Kwa hiyo, ninauliza maswali ya wafanyakazi, wanaandika majibu na alama za rangi tatu (nyeusi, nyekundu na bluu). Ninachambua majibu yao kwa archetypes. Sasa hebu tujadili archetypes zote kwa utaratibu.
1. Fanya Kazi Zote Ionekane: Fanya kazi ionekane
Kampuni nyingi ninazofanya nazo kazi zina asilimia kubwa sana ya kazi zisizojulikana. Kwa mfano, hii ni wakati mfanyakazi mmoja anakuja kwa mwingine na anauliza tu kufanya kitu. Katika mashirika makubwa, kunaweza kuwa na 60% ya kazi isiyopangwa. Na hadi 40% ya kazi haijaandikwa kwa njia yoyote. Kama ingekuwa Boeing, nisingepanda ndege yao tena maishani mwangu. Ikiwa nusu tu ya kazi imeandikwa, basi haijulikani ikiwa kazi hii inafanywa kwa usahihi au la. Njia zingine zote zinageuka kuwa hazina maana - hakuna maana katika kujaribu kugeuza kitu chochote, kwa sababu 50% inayojulikana inaweza kuwa sehemu ya kazi zaidi na ya wazi, automatisering ambayo haitatoa matokeo mazuri, na mbaya zaidi. mambo ni katika nusu isiyoonekana. Kwa kukosekana kwa nyaraka, haiwezekani kupata kila aina ya hacks na kazi iliyofichwa, sio kupata vikwazo, wale "Brents" ambao tayari nimezungumza. Kuna kitabu kizuri sana cha Dominica DeGrandis . Anafichua tano tofauti "uvujaji wa wakati" (wezi wa wakati):
- Kazi Nyingi Sana Katika Mchakato (WIP)
- Vitegemezi visivyojulikana
- Kazi Isiyopangwa
- Vipaumbele vinavyokinzana
- Kazi Iliyopuuzwa
Huu ni uchambuzi wa thamani sana na kitabu ni nzuri, lakini ushauri huu wote hauna maana ikiwa ni 50% tu ya data inaonekana. Mbinu zilizopendekezwa na Dominika zinaweza kutumika ikiwa usahihi wa zaidi ya 90% utapatikana. Ninazungumza juu ya hali ambapo bosi humpa msaidizi kazi ya dakika 15, lakini inachukua siku tatu; lakini bosi hajui kabisa kuwa huyu wa chini anategemewa na watu wengine wanne au watano.
Mradi wa Phoenix ni hadithi nzuri kuhusu mradi ambao ulikuwa umechelewa kwa miaka mitatu. Mmoja wa wahusika anakabiliwa na kufukuzwa kwa sababu ya hii, na anakutana na mhusika mwingine ambaye anawasilishwa kama aina ya Socrates. Anasaidia kujua ni nini kilienda vibaya. Inatokea kwamba kampuni ina msimamizi wa mfumo mmoja, ambaye jina lake ni Brent, na kazi zote kwa namna fulani hupitia kwake. Katika moja ya mikutano, mmoja wa wasaidizi anaulizwa: kwa nini kila kazi ya nusu saa inachukua wiki? Jibu ni uwasilishaji uliorahisishwa sana wa nadharia ya foleni na sheria ya Kidogo, na katika uwasilishaji huu inabadilika kuwa kwa umiliki wa 90%, kila saa ya kazi inachukua masaa 9. Kila kazi inahitaji kutumwa kwa watu wengine saba, ili saa hiyo iwe masaa 63, 7 mara 9. Ninachosema ni kwamba ili kutumia Sheria ya Kidogo au nadharia yoyote ngumu ya foleni, unahitaji angalau kuwa na data.
Kwa hivyo ninapozungumza juu ya mwonekano, simaanishi kuwa kila kitu kiko kwenye skrini, lakini kwamba angalau una data. Wanapofanya hivyo, mara nyingi hugeuka kuwa kuna kiasi kikubwa sana cha kazi isiyopangwa ambayo kwa namna fulani inatumwa kwa Brent wakati hakuna haja yake. Na Brent ni mtu mzuri, hatakataa, lakini haambii mtu yeyote jinsi anavyofanya kazi yake.
Kazi inapoonekana, data inaweza kuainishwa vizuri (hivyo ndivyo Dominique anafanya kwenye picha), uondoaji wa uvujaji wa mara tano unaweza kutumika, na otomatiki inaweza kutumika.
2. Kuunganisha Mifumo ya Usimamizi wa Kazi: Usimamizi wa Kazi
Archetypes ninazozungumzia ni aina ya piramidi. Ikiwa ya kwanza imefanywa kwa usahihi, basi ya pili tayari ni aina ya kuongeza. Nyingi kati ya hizi hazifanyi kazi kwa wanaoanza, zinahitaji kukumbukwa kwa makampuni makubwa kama Fortune 5000. Kampuni ya mwisho niliyoifanyia kazi ilikuwa na mifumo 10 ya kukatia tiketi. Timu moja ilikuwa na Remedy, nyingine iliandika aina fulani ya mfumo wake, ya tatu ilitumia Jira, na nyingine ilifanya kazi kwa barua pepe. Tatizo sawa linatokea ikiwa kampuni ina mabomba 30 tofauti, lakini sina muda wa kujadili kesi hizo zote.
Mimi hujadiliana na watu jinsi tikiti zinaundwa, nini kitatokea kwao baadaye, na jinsi zinavyoepukwa. Jambo la kufurahisha zaidi ni kwamba watu kwenye mikutano yetu huzungumza kwa unyoofu. Niliuliza ni watu wangapi waliweka "matokeo madogo / yasiyo na athari" kwenye tikiti ambazo zinapaswa kupewa "athari kubwa". Ilibadilika kuwa karibu kila mtu hufanya hivi. Sijishughulishi na kushutumu na kujaribu kwa kila njia iwezekanavyo kutotambua watu. Wanapokiri kitu kwangu kwa dhati, mimi simpe mtu huyo. Lakini wakati karibu kila mtu anapita kwenye mfumo, inamaanisha kuwa usalama wote kimsingi ni mavazi ya dirisha. Kwa hiyo, hakuna hitimisho linaweza kutolewa kutoka kwa data ya mfumo huu.
Ili kutatua tatizo la tikiti, unahitaji kuchagua mfumo mmoja kuu. Ikiwa unatumia Jira, iweke Jira. Ikiwa kuna njia mbadala, basi iwe pekee. Jambo la msingi ni kwamba tikiti zinapaswa kutazamwa kama hatua nyingine katika mchakato wa ukuzaji. Kila kitendo lazima kiwe na tikiti, ambayo lazima itiririke kupitia utendakazi wa ukuzaji. Tikiti hutumwa kwa timu, ambayo huzichapisha kwenye ubao wa hadithi na kisha kuwajibikia.
Hii inatumika kwa idara zote, ikiwa ni pamoja na miundombinu na uendeshaji. Katika kesi hii, inawezekana kuunda angalau wazo fulani linalowezekana la hali ya mambo. Mara tu mchakato huu unapoanzishwa, ghafla inakuwa rahisi kutambua ni nani anayewajibika kwa kila programu. Kwa sababu sasa tunapokea si 50%, lakini 98% ya huduma mpya. Ikiwa mchakato huu wa msingi utafanya kazi, basi usahihi unaboresha katika mfumo wote.
Bomba la huduma
Hii inatumika tena kwa mashirika makubwa. Ikiwa wewe ni kampuni mpya katika uwanja mpya, kunja mikono yako na ufanye kazi na Travis CI au CircleCI yako. Linapokuja suala la kampuni za Fortune 5000, kisa fulani kilichotokea katika benki nilikofanya kazi. Google walikuja kwao na walionyeshwa michoro ya mifumo ya zamani ya IBM. Vijana kutoka Google waliuliza kwa kuchanganyikiwa - msimbo wa chanzo wa hii uko wapi? Lakini hakuna msimbo wa chanzo, hata GUI. Huu ndio ukweli ambao mashirika makubwa yanapaswa kushughulika nao: rekodi za benki za miaka 40 kwenye mfumo mkuu wa zamani. Mmoja wa wateja wangu hutumia kontena za Kubernetes zilizo na muundo wa Circuit Breaker, pamoja na Tumbili wa Chaos, zote kwa programu ya KeyBank. Lakini vyombo hivi hatimaye vinaunganishwa na programu ya COBOL.
Vijana kutoka Google walikuwa na uhakika kabisa kwamba wangeweza kutatua matatizo yote ya mteja wangu, na kisha wakaanza kuuliza maswali: ni nini datapipe ya IBM? Wanaambiwa: hii ni kiunganishi. Je, inaunganishwa na nini? Kwa mfumo wa Sperry. Na hiyo ni nini? Nakadhalika. Kwa mtazamo wa kwanza inaonekana: ni aina gani ya DevOps inaweza kuwa? Lakini kwa kweli, inawezekana. Kuna mifumo ya uwasilishaji ambayo hukuruhusu kukabidhi mtiririko wa kazi kwa timu za uwasilishaji.
3. Nadharia ya Vikwazo: Nadharia ya Vikwazo
Hebu tuendelee kwenye archetype ya tatu: ujuzi wa taasisi / "kikabila". Kama sheria, katika shirika lolote kuna watu kadhaa ambao wanajua kila kitu na kusimamia kila kitu. Hawa ndio ambao wamekuwa katika shirika kwa muda mrefu zaidi na ambao wanajua suluhisho zote.
Wakati hii inakuja kwenye mchoro, mimi huzunguka watu kama hao na alama: kwa mfano, zinageuka kuwa Lou fulani yuko kwenye mikutano yote. Na ni wazi kwangu: hii ni Brent ya ndani. Wakati CIO anachagua kati yangu mwenye T-shirt na sneakers na yule jamaa wa IBM aliyevaa suti, mimi huchaguliwa kwa sababu ninaweza kumwambia mkurugenzi mambo ambayo mtu mwingine hatamwambia na kwamba mkurugenzi asingependa kusikia. . Ninawaambia kwamba kikwazo katika kampuni yao ni mtu anayeitwa Fred na mtu anayeitwa Lou. Kikwazo hiki kinahitaji kufunguliwa, ujuzi wao unahitaji kupatikana kutoka kwao kwa njia moja au nyingine.
Ili kutatua aina hii ya shida, naweza, kwa mfano, kupendekeza kutumia Slack. Mkurugenzi mwenye busara atauliza - kwa nini? Kwa kawaida, katika hali hiyo, washauri wa DevOps hujibu: kwa sababu kila mtu anafanya hivyo. Ikiwa mkurugenzi ni mwenye busara sana, atasema: basi nini. Na hapa ndipo mazungumzo yanaisha. Na jibu langu kwa hili ni: kwa sababu kuna vikwazo vinne katika kampuni, Fred, Lou, Susie na Jane. Ili kuasisi maarifa yao, mtu lazima kwanza atambulishe Slack. Wiki zako zote ni upuuzi mtupu kwa sababu hakuna anayejua kuhusu kuwepo kwao. Ikiwa timu ya wahandisi inahusika katika ukuzaji wa mbele na nyuma na kila mtu anahitaji kujua kwamba anaweza kuwasiliana na timu ya maendeleo ya mwisho au timu ya miundombinu na maswali. Hapo ndipo Lou au Fred pengine watakuwa na wakati wa kujiunga na wiki. Na kisha katika Slack mtu anaweza kuuliza kwa nini, tuseme, hatua ya 5 haifanyi kazi. Kisha Lou au Fred watasahihisha maagizo kwenye wiki. Ikiwa utaanzisha mchakato huu, basi mambo mengi yataanguka peke yao.
Hili ndilo jambo langu kuu: ili kupendekeza teknolojia yoyote ya juu, lazima kwanza uweke msingi kwao kwa utaratibu, na hii inaweza kufanyika kwa ufumbuzi wa chini wa teknolojia iliyoelezwa hapo juu. Ikiwa unapoanza na teknolojia za juu na usieleze kwa nini zinahitajika, basi, kama sheria, hii haimalizi vizuri. Mmoja wa wateja wetu anatumia Azure ML, suluhisho la bei nafuu sana na rahisi. Takriban 30% ya maswali yao yalijibiwa na mashine ya kujifunzia yenyewe. Na jambo hili liliandikwa na waendeshaji ambao hawakuhusika katika sayansi ya data, takwimu au hisabati. Hii ni muhimu. Gharama ya suluhisho kama hilo ni ndogo.
4. Udukuzi wa ushirikiano: Udukuzi wa ushirikiano
Archetype ya nne ni haja ya kupambana na kutengwa. Watu wengi tayari wanajua hili: kutengwa huzaa uadui. Ikiwa kila idara iko kwenye sakafu yake, na watu hawaingiliani kwa njia yoyote, isipokuwa kwenye lifti, basi uadui kati yao hutokea kwa urahisi sana. Lakini ikiwa, kinyume chake, watu wako katika chumba kimoja na kila mmoja, yeye huondoka mara moja. Mtu anapotoa shtaka la jumla, kwa mfano, kiolesura kama hicho kamwe hakifanyi kazi, hakuna kitu rahisi kufafanua mashtaka kama haya. Watayarishaji wa programu ambao waliandika kiolesura wanahitaji tu kuanza kuuliza maswali maalum, na hivi karibuni itakuwa wazi kuwa, kwa mfano, mtumiaji alikuwa akitumia zana vibaya.
Kuna njia nyingi za kushinda kutengwa. Wakati fulani niliombwa kushauriana na benki moja huko Australia, lakini nilikataa kufanya hivyo kwa sababu nina watoto wawili na mke. Nilichoweza kufanya ili kuwasaidia ilikuwa kupendekeza usimulizi wa hadithi wa picha. Hili ni jambo ambalo limethibitishwa kufanya kazi. Njia nyingine ya kuvutia ni mikutano ya kahawa konda. Katika shirika kubwa, hii ni chaguo bora kwa kusambaza maarifa. Kwa kuongeza, unaweza kufanya devopsdays za ndani, hackathons, na kadhalika.
5. Kufundisha Kata
Kama nilivyoonya hapo mwanzo, sitazungumza kuhusu hili leo. Ikiwa una nia, unaweza kuangalia .
Pia kuna mazungumzo mazuri juu ya mada hii kutoka kwa Mike Rother:
6. Mwelekeo wa Soko: shirika lenye mwelekeo wa soko
Kuna matatizo tofauti hapa. Kwa mfano, "I" watu, "T" watu na "E" watu. "Mimi" watu ni wale wanaofanya jambo moja tu. Kwa kawaida zipo katika mashirika yenye idara zilizotengwa. "T" ni wakati mtu ni mzuri katika jambo moja lakini pia ni mzuri katika mambo mengine. "E" au hata "kuchana" ni wakati mtu ana ujuzi mwingi.
Sheria ya Conway inafanya kazi hapa (), ambayo kwa fomu iliyorahisishwa zaidi inaweza kusemwa kama ifuatavyo: ikiwa timu tatu zinafanya kazi kwenye mkusanyaji, basi matokeo yatakuwa mkusanyaji wa sehemu tatu. Kwa hiyo, ikiwa kuna kiwango cha juu cha kutengwa ndani ya shirika, basi hata Kubernetes, Mvunjaji wa Mzunguko, upanuzi wa API na mambo mengine ya dhana katika shirika hili yatapangwa kwa njia sawa na shirika yenyewe. Madhubuti kulingana na Conway na licha ya nyinyi vijana wajinga.
Suluhisho la tatizo hili limeelezwa mara nyingi. Kuna, kwa mfano, archetypes ya shirika ilivyoelezwa na Fernando Fernandez. Usanifu huo wenye matatizo ambao nimezungumzia tu, kwa kutengwa, ni usanifu unaozingatia kazi. Aina ya pili ni mbaya zaidi, usanifu wa matrix, fujo la wengine wawili. Ya tatu ni kile kinachoonekana katika startups nyingi, na makampuni makubwa pia yanajaribu kufanana na aina hii. Ni shirika lenye mwelekeo wa soko. Hapa tunaboresha ili kufikia jibu la haraka zaidi kwa maombi ya wateja. Hii wakati mwingine huitwa shirika la gorofa.
Watu wengi huelezea muundo huu kwa njia tofauti, napenda maneno jenga/endesha timu, huko Amazon wanaiita timu mbili za pizza. Katika muundo huu, watu wa aina zote za "I" wameunganishwa karibu na huduma moja, na hatua kwa hatua wanakuwa karibu na aina ya "T", na ikiwa usimamizi sahihi umewekwa, wanaweza hata kuwa "E". Upinzani wa kwanza hapa ni kwamba muundo kama huo una vitu visivyo vya lazima. Kwa nini unahitaji mtu anayejaribu katika kila idara ikiwa unaweza kuwa na idara maalum ya wanaojaribu? Ambayo ninajibu: gharama za ziada katika kesi hii ni bei ya shirika zima kuwa aina ya "E" katika siku zijazo. Katika muundo huu, tester hujifunza hatua kwa hatua kuhusu mitandao, usanifu, kubuni, nk. Kwa hiyo, kila mshiriki katika shirika anafahamu kikamilifu kila kitu kinachotokea katika shirika. Ikiwa unataka kujua jinsi mpango huu unavyofanya kazi katika tasnia, soma .
7. Wakaguzi wa Shift-kushoto: ukaguzi mapema katika mzunguko. Kuzingatia sheria za usalama kwenye onyesho
Huu ndio wakati matendo yako hayafaulu mtihani wa harufu, kwa kusema. Watu wanaokufanyia kazi sio wajinga. Ikiwa, kama katika mfano hapo juu, waliweka athari ndogo / hakuna kila mahali, hii ilidumu miaka mitatu, na hakuna mtu aliyeona chochote, basi kila mtu anajua vizuri kwamba mfumo haufanyi kazi. Au mfano mwingine - bodi ya ushauri wa mabadiliko, ambapo ripoti zinahitajika kuwasilishwa kila, sema, Jumatano. Kuna kikundi cha watu wanaofanya kazi huko (sio kulipwa vizuri sana, kwa njia) ambao, kwa nadharia, wanapaswa kujua jinsi mfumo kwa ujumla unavyofanya kazi. Na katika kipindi cha miaka mitano iliyopita, pengine umegundua kuwa mifumo yetu ni tata sana. Na watu watano au sita wanapaswa kufanya uamuzi kuhusu mabadiliko ambayo hawakuyafanya na ambayo hawajui lolote kuyahusu.
Bila shaka, mbinu hii haifanyi kazi. Lazima niachane na mambo kama haya kwa sababu watu hawa hawalindi mfumo. Uamuzi lazima ufanywe na timu yenyewe, kwa sababu timu lazima iwajibike. Vinginevyo, hali ya kitendawili inatokea wakati meneja ambaye hajawahi kuandika msimbo maishani mwake anamwambia mpangaji wa programu ichukue muda gani kuandika msimbo. Kampuni moja niliyofanya kazi nayo ilikuwa na bodi 7 tofauti zilizokagua kila mabadiliko, ikijumuisha bodi ya usanifu, bodi ya bidhaa, n.k. Kulikuwa na muda wa kusubiri wa lazima, ingawa mfanyakazi mmoja aliniambia kwamba katika miaka kumi ya kazi, hakuna mtu aliyewahi kukataa mabadiliko yaliyofanywa na mtu huyu katika kipindi hiki cha lazima.
Wakaguzi wanahitaji kualikwa kujiunga nasi, na sio kuwaondoa. Waambie kwamba unaandika vyombo vya binary visivyoweza kubadilika ambavyo, kama vitafaulu majaribio yote, vinabaki kuwa visivyobadilika milele. Waambie kwamba una bomba kama msimbo na ueleze maana yake. Waonyeshe mpango ufuatao: mfumo wa jozi usioweza kubadilika wa kusoma tu katika chombo ambacho hupita majaribio yote ya kuathiriwa; na kisha sio tu hakuna mtu anayegusa, hawana hata kugusa mfumo unaojenga bomba, kwa vile pia huundwa kwa nguvu. Nina wateja, Capital One, ambao wanatumia Vault kuunda kitu kama blockchain. Mkaguzi haitaji kuonyesha "mapishi" kutoka kwa Chef; inatosha kuonyesha blockchain, ambayo ni wazi kile kilichotokea kwa tikiti ya Jira katika uzalishaji na ni nani anayehusika nayo.
Kulingana na , iliyoundwa mwaka wa 2018 na Sonatype, kulikuwa na maombi bilioni 2017 ya upakuaji wa OSS mwaka wa 87.
Hasara iliyopatikana kutokana na udhaifu ni kubwa. Zaidi ya hayo, takwimu unazoona hapo juu hazijumuishi gharama za fursa. DevSecOps ni nini kwa kifupi? Acha niseme mara moja kwamba sipendi kuzungumza juu ya jinsi jina hili limefanikiwa. Jambo ni kwamba kwa kuwa DevOps imefanikiwa sana, tunapaswa kujaribu kuongeza usalama kwenye bomba hilo.
Mfano wa mlolongo huu:
Hili sio pendekezo kwa bidhaa maalum, ingawa ninazipenda zote. Nilizitaja kama mfano ili kuonyesha kuwa DevOps, ambayo hapo awali iliegemea mtazamo wa shirika katika tasnia, inakuruhusu kugeuza otomatiki kila hatua ya kazi kwenye bidhaa.
Na hakuna sababu kwa nini hatukuweza kuchukua mbinu sawa kwa usalama.
Jumla ya
Kama hitimisho, nitatoa vidokezo kwa DevSecOps. Unahitaji kujumuisha wakaguzi katika mchakato wa kuunda mifumo yako na kutumia wakati kuwaelimisha. Unahitaji kushirikiana na wakaguzi. Ifuatayo, unahitaji kupigana vita kali kabisa dhidi ya chanya za uwongo. Hata ukiwa na zana ghali zaidi ya kuchanganua uwezekano wa kuathiriwa, unaweza kuishia kuunda tabia mbaya sana miongoni mwa wasanidi programu wako ikiwa hujui uwiano wako wa mawimbi kati ya kelele ni nini. Wasanidi programu watalemewa na matukio na watayafuta tu. Iwapo ulisikia kuhusu hadithi ya Equifax, hicho ndicho kilichotokea huko, ambapo kiwango cha juu zaidi cha tahadhari kilipuuzwa. Kwa kuongezea, udhaifu unahitaji kuelezewa kwa njia ambayo inaweka wazi jinsi unavyoathiri biashara. Kwa mfano, unaweza kusema kuwa huu ni udhaifu sawa na katika hadithi ya Equifax. Athari za kiusalama zinapaswa kushughulikiwa sawa na masuala mengine ya programu, yaani, zinapaswa kujumuishwa katika mchakato wa jumla wa DevOps. Unahitaji kufanya kazi nao kupitia Jira, Kanban, nk. Waendelezaji hawapaswi kufikiri kwamba mtu mwingine atafanya hivyo - kinyume chake, kila mtu anapaswa kufanya hivyo. Hatimaye, unahitaji kutumia nishati katika mafunzo ya watu.
Viungo muhimu
Hapa kuna mazungumzo machache kutoka kwa mkutano wa DevoOops ambayo unaweza kupata muhimu:
- Sergey Berdnikov, Artyom Kalichkin - Hadithi ya mafanikio, au "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps kwa kiwango: janga la Uigiriki katika vitendo vitatu (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Angalia ndani DevoOops 2020 Moscow - pia kuna mambo mengi ya kuvutia huko.
Chanzo: mapenzi.com