Tuliwahi kutoa mfumo wa kielektroniki wa usimamizi wa hati kwa mteja katika kituo kimoja. Na kisha kwa kitu kingine. Na moja zaidi. Na ya nne, na ya tano. Tulichukuliwa sana hivi kwamba tulifikia vitu 10 vilivyogawanywa. Ilibadilika kwa nguvu ... haswa tulipofikia kuwasilisha mabadiliko. Kama sehemu ya uwasilishaji kwa mzunguko wa uzalishaji, hali 5 za mfumo wa majaribio hatimaye zilihitaji masaa 10 na wafanyikazi 6-7. Gharama kama hizo zilitulazimisha kusafirisha bidhaa mara chache iwezekanavyo. Baada ya miaka mitatu ya operesheni, hatukuweza kustahimili na tukaamua kuongeza mradi kwa udogo wa DevOps.
Sasa upimaji wote unafanyika kwa saa 3, na watu 3 wanashiriki ndani yake: mhandisi na wapimaji wawili. Maboresho yanaonyeshwa wazi kwa idadi na kusababisha kupunguzwa kwa TTM inayopendwa sana. Katika uzoefu wetu, kuna wateja wengi zaidi ambao wanaweza kufaidika na DevOps kuliko wale wanaojua kuihusu. Kwa hiyo, ili kuleta DevOps karibu na watu, tumeanzisha mjenzi rahisi, ambayo tutazungumzia kwa undani zaidi katika chapisho hili.
Sasa hebu tuambie kwa undani zaidi. Kampuni moja ya nishati inapeleka mfumo wa usimamizi wa hati za kiufundi katika vituo 10 vikubwa. Si rahisi kuabiri miradi ya kiwango hiki bila DevOps, kwa sababu sehemu kubwa ya kazi ya mikono inachelewesha kazi sana na pia inapunguza ubora - kazi zote za mikono zimejaa hitilafu. Kwa upande mwingine, kuna miradi ambapo kuna ufungaji mmoja tu, lakini kila kitu kinahitaji kufanya kazi moja kwa moja, mara kwa mara na bila kushindwa - kwa mfano, mifumo ya mtiririko wa hati sawa katika mashirika makubwa ya monolithic. Vinginevyo, mtu atafanya mipangilio kwa mikono, kusahau kuhusu maagizo ya kupeleka - na kwa sababu hiyo, katika uzalishaji mipangilio itapotea na kila kitu kitaanguka.
Kawaida tunafanya kazi na mteja kupitia mkataba, na katika kesi hii masilahi yetu hutofautiana kidogo. Mteja anaangalia mradi madhubuti ndani ya bajeti na maelezo ya kiufundi. Inaweza kuwa vigumu kumuelezea manufaa ya mazoea mbalimbali ya DevOps ambayo hayajajumuishwa katika vipimo vya kiufundi. Je, ikiwa ana nia ya matoleo ya haraka na thamani ya biashara iliyoongezwa, au katika kujenga bomba la otomatiki?
Ole, wakati wa kufanya kazi na gharama iliyoidhinishwa awali, riba hii haipatikani kila wakati. Katika mazoezi yetu, kulikuwa na kesi wakati tulilazimika kuchukua maendeleo ya mkandarasi asiye na uaminifu na asiyejali. Ilikuwa mbaya: hakukuwa na misimbo ya chanzo iliyosasishwa, msingi wa msimbo wa mfumo huo ulikuwa tofauti kwenye usakinishaji tofauti, hati hazikuwepo na ubora wa kutisha kwa kiasi. Bila shaka, mteja hakuwa na udhibiti wa msimbo wa chanzo, mkusanyiko, matoleo, nk.
Hadi sasa, si kila mtu anajua kuhusu DevOps, lakini mara tu tunapozungumzia juu ya faida zake, kuhusu uokoaji wa rasilimali halisi, macho ya wateja wote huangaza. Kwa hivyo idadi ya maombi ambayo ni pamoja na DevOps inaongezeka kwa wakati. Hapa, ili kuzungumza kwa urahisi lugha moja na wateja, tunahitaji kuunganisha kwa haraka matatizo ya biashara na mbinu za DevOps ambazo zitasaidia kujenga bomba linalofaa la maendeleo.
Kwa hiyo, tuna seti ya matatizo kwa upande mmoja, tuna ujuzi wa DevOps, mazoezi na zana kwa upande mwingine. Kwa nini usishiriki uzoefu na kila mtu?
Kuunda mjenzi wa DevOps
Agile ina manifesto yake. ITIL ina mbinu yake mwenyewe. DevOps haina bahati - bado haijapata violezo na viwango. Ingawa kuamua ukomavu wa makampuni kulingana na tathmini ya maendeleo yao na mazoea ya uendeshaji.
Kwa bahati nzuri, kampuni inayojulikana ya Gartner mnamo 2014 na kuchanganua mazoea muhimu ya DevOps na uhusiano kati yao. Kulingana na hili, nilitoa infographic:
Tuliichukua kama msingi wetu . Kila moja ya maeneo manne ina seti ya zana - tulizikusanya kwenye hifadhidata, tukagundua zile maarufu zaidi, alama za ujumuishaji zilizotambuliwa na njia zinazofaa za uboreshaji. Kwa jumla iligeuka 36 mazoea na zana 115, robo ambayo ni programu huria au programu huria. Ifuatayo, tutazungumza juu ya kile tumefanikiwa katika kila eneo na, kama mfano, juu ya jinsi hii ilitekelezwa katika mradi wa kuunda usimamizi wa hati ya kiufundi, ambayo tulianza chapisho.
Mchakato
Katika mradi wa sifa mbaya wa EDMS, mfumo wa usimamizi wa nyaraka za kiufundi uliwekwa kulingana na mpango huo katika kila moja ya vitu 10. Ufungaji ni pamoja na seva 4: seva ya hifadhidata, seva ya programu, indexing ya maandishi kamili na usimamizi wa yaliyomo. Katika ufungaji, hufanya kazi ndani ya node moja na iko kwenye kituo cha data kwenye vituo. Vitu vyote vinatofautiana kidogo katika miundombinu, lakini hii haiingilii na mwingiliano wa kimataifa.
Kwanza, kulingana na mazoea ya DevOps, tuliweka miundombinu kiotomatiki ndani ya nchi, kisha tukaleta utoaji kwenye mzunguko wa majaribio, na kisha kwa bidhaa ya mteja. Kila mchakato ulifanyika hatua kwa hatua. Mipangilio ya mazingira imewekwa katika mfumo wa msimbo wa chanzo, kwa kuzingatia ambayo kit cha usambazaji kinaundwa kwa uppdatering wa moja kwa moja. Katika kesi ya mabadiliko ya usanidi, wahandisi wanahitaji tu kufanya mabadiliko sahihi kwenye mfumo wa udhibiti wa toleo - na kisha sasisho la moja kwa moja litafanyika bila matatizo.
Shukrani kwa mbinu hii, mchakato wa kupima umerahisishwa sana. Hapo awali, mradi ulikuwa na wajaribu ambao hawakufanya chochote isipokuwa kusasisha stendi kwa mikono. Sasa wanakuja tu, wanaona kwamba kila kitu kinafanya kazi na kufanya mambo muhimu zaidi. Kila sasisho hujaribiwa kiotomatiki - kutoka kiwango cha uso hadi uwekaji otomatiki wa hali ya biashara. Matokeo yanachapishwa kama ripoti tofauti katika TestRail.
ΠΡΠ»ΡΡΡΡΠ°
Majaribio ya kuendelea yanaelezewa vyema kupitia mfano wa muundo wa jaribio. Kujaribu mfumo ambao haupo bado ni kazi ya ubunifu. Wakati wa kuandika mpango wa mtihani, unahitaji kuelewa jinsi ya kupima kwa usahihi na ni matawi gani ya kufuata. Na pia kupata usawa kati ya muda na bajeti ili kuamua idadi bora ya hundi. Ni muhimu kuchagua hasa vipimo muhimu, fikiria jinsi mtumiaji atakavyoingiliana na mfumo, kuzingatia mazingira na mambo iwezekanavyo ya nje. Haiwezekani kufanya bila majaribio ya kuendelea.
Sasa kuhusu utamaduni wa mwingiliano. Hapo awali, kulikuwa na pande mbili zinazopingana - wahandisi na watengenezaji. Watengenezaji walisema: "Hatujali jinsi itazinduliwa. Nyinyi ni wahandisi, mna akili, hakikisha kwamba inafanya kazi bila kushindwa". Wahandisi walijibu: βNyie watengenezaji ni wazembe sana. Hebu tuwe waangalifu zaidi, na tutacheza matoleo yako mara chache zaidi. Kwa sababu kila wakati unatupa msimbo unaovuja, si wazi kwetu jinsi ya kuingiliana.. Hili ni suala la mwingiliano wa kitamaduni ambalo limeundwa tofauti na mtazamo wa DevOps. Hapa, wahandisi na watengenezaji wote ni sehemu ya timu moja ambayo inalenga kubadilisha mara kwa mara, lakini wakati huo huo programu ya kuaminika.
Ndani ya timu moja, wataalamu wameazimia kusaidiana. Kama ilivyokuwa hapo awali? Kwa mfano, baadhi ya maelekezo nene ya kupeleka yalikuwa yanatayarishwa, kuhusu kurasa 50. Mhandisi aliisoma, hakuelewa kitu, akalaani na kumwomba msanidi saa tatu asubuhi kutoa maoni. Msanidi programu alitoa maoni na pia alilaani - mwishowe, hakuna mtu aliyefurahi. Zaidi ya hayo, kwa kawaida, kulikuwa na makosa fulani, kwa sababu huwezi kukumbuka kila kitu katika maagizo. Na sasa mhandisi, pamoja na msanidi programu, anaandika hati ya upelekaji wa kiotomatiki wa miundombinu ya programu ya programu. Na wanasemezana kivitendo kwa lugha moja.
Watu
Saizi ya timu imedhamiriwa na wigo wa sasisho. Timu inaajiriwa wakati wa kuunda utoaji; inajumuisha wale wanaovutiwa kutoka kwa timu ya jumla ya mradi. Kisha mpango wa sasisho unaandikwa na wale wanaohusika na kila hatua, na timu inaripoti jinsi inavyoendelea. Washiriki wote wa timu wanaweza kubadilishana. Kama sehemu ya timu, pia tuna msanidi programu mbadala, lakini karibu kamwe halazimiki kuunganishwa.
Teknolojia
Katika mchoro wa teknolojia, vidokezo vichache vinaonyeshwa, lakini chini yao kuna rundo la teknolojia - unaweza kuchapisha kitabu kizima na maelezo yao. Kwa hivyo tutaangazia ya kuvutia zaidi.
Miundombinu kama Kanuni
Sasa, pengine, dhana hii haitashangaza mtu yeyote, lakini hapo awali maelezo ya miundombinu yaliacha kuhitajika. , mazingira ya majaribio yalikuwa ya kipekee, yalithaminiwa na kuthaminiwa, chembe za vumbi zilipeperushwa kutoka kwao.
Siku hizi hakuna anayeogopa kufanya majaribio. Kuna picha za msingi za mashine za kawaida, kuna matukio yaliyotengenezwa tayari kwa mazingira ya kupeleka. Violezo na hati zote huhifadhiwa katika mfumo wa udhibiti wa toleo na husasishwa mara moja. Hapo awali, wakati ilikuwa ni lazima kutoa mfuko kwa kusimama, pengo la usanidi lilionekana. Sasa unahitaji tu kuongeza mstari kwenye msimbo wa chanzo.
Mbali na hati za miundombinu na mabomba, mbinu ya Hati kama Kanuni pia hutumiwa kwa uhifadhi. Shukrani kwa hili, ni rahisi kuunganisha watu wapya kwenye mradi huo, kuwatambulisha kwenye mfumo kulingana na kazi zilizoelezwa, kwa mfano, katika mpango wa mtihani, na pia kutumia tena kesi za mtihani.
Utoaji na ufuatiliaji unaoendelea
kuhusu DevOps, tulizungumza kuhusu jinsi tulivyochagua zana za kutekeleza utoaji na ufuatiliaji unaoendelea. Mara nyingi hakuna haja ya kuandika tena chochote - inatosha kutumia maandishi yaliyoandikwa hapo awali, kwa usahihi kujenga ushirikiano kati ya vipengele na kuunda console ya kawaida ya usimamizi. Na taratibu zote zinaweza kuzinduliwa kwa kutumia kifungo kimoja au ratiba.
Kwa Kiingereza kuna dhana tofauti, Utoaji Unaoendelea na Usambazaji Unaoendelea. Wote wawili wanaweza kutafsiriwa kama "utoaji wa kuendelea", lakini kwa kweli kuna tofauti kidogo kati yao. Katika mradi wetu kwa mtiririko wa hati ya kiufundi ya kampuni ya nishati iliyosambazwa, badala yake, Utoaji hutumiwa - wakati ufungaji kwa ajili ya uzalishaji hutokea kwa amri. Katika Uwekaji, ufungaji hutokea moja kwa moja. Utoaji Unaoendelea katika mradi huu kwa ujumla umekuwa sehemu ya kati ya DevOps.
Kwa ujumla, kwa kukusanya vigezo fulani, unaweza kuelewa wazi kwa nini mazoea ya DevOps ni muhimu. Na ufikishe hili kwa wasimamizi, ambao wanapenda sana nambari. Jumla ya idadi ya uzinduzi, wakati wa utekelezaji wa hatua za hati, sehemu ya uzinduzi uliofaulu - yote haya huathiri moja kwa moja wakati anaopenda kila mtu wa soko, ambayo ni, wakati kutoka kwa ahadi hadi mfumo wa kudhibiti toleo hadi kutolewa kwa toleo kwenye mazingira ya uzalishaji. Kwa utekelezaji wa zana muhimu, wahandisi hupokea viashiria vya thamani kwa barua, na meneja wa mradi huona kwenye dashibodi. Kwa njia hii unaweza kutathmini mara moja faida za zana mpya. Na unaweza kuzijaribu kwenye miundombinu yako ukitumia mbuni wa DevOps.
Nani atahitaji yetu ?
Hebu tusijifanye: kwa mwanzo, akawa na manufaa kwetu. Kama tulivyokwisha sema, unahitaji kuzungumza lugha moja na mteja, na kwa msaada wa mbuni wa DevOps tunaweza kuchora haraka msingi wa mazungumzo kama haya. Wataalamu wa biashara wataweza kujitathmini wenyewe kile wanachohitaji na hivyo kuendeleza kwa kasi zaidi. Tulijaribu kufanya mbunifu kwa maelezo zaidi iwezekanavyo, na kuongeza rundo la maelezo ili mtumiaji yeyote aelewe kile anachochagua.
Muundo wa mbuni hukuruhusu kuzingatia maendeleo yaliyopo ya kampuni katika michakato ya ujenzi na otomatiki. Hakuna haja ya kubomoa kila kitu na kuijenga tena ikiwa unaweza kuchagua tu suluhisho zinazounganishwa vizuri na michakato iliyopo na ambayo inaweza kujaza mapengo tu.
Labda maendeleo yako tayari yamehamia kiwango cha juu na chombo chetu kitaonekana pia "cha nahodha". Lakini tunaona kuwa ni muhimu kwetu na tunatumai kuwa itakuwa na manufaa kwa baadhi ya wasomaji. Tunakukumbusha kwa mbuni - ikiwa kuna chochote, unapokea mchoro mara baada ya kuingiza data ya awali. Tutashukuru kwa maoni yako na nyongeza.
Chanzo: mapenzi.com