Menu

Spolupráca v DevOps

collaboration devops

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Spolupráca v DevOps:

Malé prírastky dodávok v DevOps bol podrobne vysvetlený v našom predchádzajúcom návode.

Vieme, že kľúčovou mantrou DevOps je spolupráca, a preto prišlo slovo DevOps.

Prečítať => Hĺbkové výukové programy

Spolupráca je spojiť sa ako jeden tím zameraný na riešenie akýchkoľvek problémov v programe, čo bráni zameraniu zákazníka na cieľ zameraného na program a vyriešiť ich tak, že ich čo najrýchlejšie vlastníte ako svoj vlastný problém bez akejkoľvek hry na vinníka.

Spolupráca v DevOps

Spolupráca učí všetkých hovoriť medzi sebou, stretávať sa navzájom tvárou v tvár, vzájomne sa zapájať do svojich stretnutí, diskusií, porozumieť si vzájomným úlohám, závislosti a mať transparentnosť v práci a proaktívne pracovať na predchádzaní problémom.

VIDEO Časť 2 Blok 5: Spolupráca - 15 minút 36 sekúnd

Prepis:

Termín kolaborácia sa v DevOps opakuje znova a znova a Devopsova mantra je spolupráca. Poďme teda pochopiť, čo „spolupráca“ v skutočnosti znamená v kontexte vývoja softvéru a DevOps.

Podľa mňa, akonáhle organizácia povie, implementujeme DevOps, myslenie na spoluprácu, ktoré je spojené s praxou devops, sa automaticky spustí v mysli každého a urobí ho viac zameraným a všímavým na spoluprácu a začnú mať pocit, že musia spolupracovať . To je kúzlo spolupráce.

Pre organizáciu a tím je teda veľmi dôležité iniciovať spoluprácu DevOps hneď od začiatku projektu. Tým myslím tímových členov programu.

Vysvetlím niekoľko prípadov, keď som videl spoluprácu Dev s Ops a operáciu s tímom dev, aby sme vedeli, čo vlastne znamená spolupráca v kontexte DevOps.

Toto je znázornenie príkladu jedného.

Vyskytla sa inštancia, že v inštalačnom skripte alebo konfiguračnom skripte bol neznámy problém, ktorý operačný tím nachádzal výzvu pri inštalácii softvéru na konkrétnu zostavu klastra v konkrétnej geografii.

Hádzalo to nejakou neznámou chybou a bol to čistý výrobný problém, ktorý sa v vývojovom prostredí nikdy nevyskytol, a operačný tím skutočne vynaložil veľa úsilia, aby ich sám vyriešil tým, že si myslel, že to súvisí s nastavením, a je potrebné ich vyriešiť to sa dosť dlho nevyriešilo.

Potom sa okamžite zapojil tím Dev, bez toho, aby bol vyzvaný na pomoc, hoci časové pásmo bolo iné, prevzalo kontrolu nad výrobným miestom, viete, že prístup k výrobe nebude mať pravdepodobne každý, Ops iba zdieľa chybu podrobnosti alebo akékoľvek ďalšie informácie, ktoré tím potrebuje na účely ladenia.

Ale táto situácia sa vyžaduje kvôli sprístupneniu jedného z členov vývojového tímu, ktorý venoval niekoľko hodín analýze problému naživo a poskytoval okamžité riešenie, a preto bol problém rýchlo vyriešený.

Toto je príklad spolupráce, keď tím vývojárov dobrovoľne vlastnil problém a pomohol tímu ops ho vyriešiť. Toto je číra inštancia spolupráce.

Podobne mi dovoľte, aby som to iný príklad ukázal schematicky, čo som nakreslil. Ďalším príkladom je, že po aktualizácii softvéru na konkrétnom webe niekoľko dní fungovali veci úplne v poriadku, zrazu sa výkon aplikácie začal spomaľovať.

Koncoví používatelia začali v dôsledku tohto spomalenia čeliť veľkým transakčným stratám. Veľa sťažností začalo prichádzať na zástupcov zákazníckych služieb, myslím tým, na zástupcov zákazníckych služieb a tí zase začali s tímom v tejto záležitosti nadviazať kontakt.

V tomto prípade sa okamžite spojil tím Dev aj Ops a s informáciami a podrobnosťami telemetrie poskytnutými tímom Ops tímu vývojárov mohli problém ladiť a zistiť, že v aspekte zdieľania zaťaženia nastal nejaký problém a preto bol výkon pomalý.

Oba tímy teda spolupracovali na odstránení problému a návrate k normálu do niekoľkých hodín. Takže tu sa Dev a Ops spoločne prihlásili a spolupracovali na riešení problému namiesto toho, aby Dev povedal svoj Ops problém a Ops si myslel, že je to Devov problém a vývojový tím sa ho musí pozrieť a napraviť.

Toto je jasná inštancia spolupráce, pri ktorej problémy vlastní každý, a nie hrať hru za vinu, bez ohľadu na to, o aký problém ide, alebo strácať čas zisťovaním, o aký problém ide, pričom treba mať na pamäti, že konečný užívateľ trpí a problém potrebuje čoskoro sa opraví.

Takže ani tu nemusí ísť o problém iba z výroby, môže to byť akýkoľvek jednoduchý problém s vývojom interného softvéru, taký jednoduchý ako každodenný problém, problém s dizajnom alebo problém s architektúrou, alebo dokonca jednoduchý otázka nástroja.

Akýkoľvek problém súvisiaci s programom alebo problém, o ktorom tím vie, že spôsobuje zákazníkovi škodu alebo spomaľuje program, musí vlastniť každý namiesto toho, aby izoloval problém, že ide o vývojový alebo prevádzkový problém alebo problém s testovaním, a prispievať k tomu, aby sa to čo najrýchlejšie riešilo, je spolupráca.

Spolupráca v kontexte DevOps teda znamená, že vývoj a operácie sa spájajú a spolupracujú na čo najskoršom vyriešení problému, pričom treba pamätať na zameranie zákazníka.

Spolupráca spočíva v tom, že spoločnosť Dev aj Ops vlastnia dianie v reálnom čase, pričom sú na vrchole monitorovanie a protokolovanie a kontrola výkonu, aby sa vyriešil problém, ktorý sa vyskytuje najmä pri výrobe, v záujme koncového používateľa.

ALEBO jednoducho, môžem povedať, že celý tím, ktorý neustále spolupracuje na riešení problému s cieľom dosiahnuť programové ciele, pričom treba mať na pamäti zameranie zákazníka, je spolupráca. Opakujem, neustále spolupracovať na riešení problémov s cieľom dosiahnuť programové ciele a mať na pamäti zameranie zákazníka je spolupráca.

Potom sa naskytne otázka, ako túto spoluprácu rozvinieme a kedy je potrebné zahájiť spoluprácu medzi tímom, ktorý sedí na míle ďaleko od seba?

Je zrejmé, že vieme, že tak Dev, ako aj Ops nemôžu spolu lokalizovať. Tím Ops musí byť bližšie k pracovnému miestu alebo dátovým centrám a vývojár musí byť bližšie k vývojovému centru softvéru. Ako teda dosiahneme neustálu spoluprácu medzi oboma tímami?

Pre organizáciu a tím je v prvom rade nevyhnutné zahájiť spoluprácu s DevOps hneď od začiatku projektu. Tím, ktorý tu mám na mysli, sú členovia tímu programu.

Precvičenie niekoľkých nasledujúcich vecí by pomohlo prekonať priepasť medzi tímom a prekonať prekážky spojené s virtuálnymi tímami, ako aj dosiahnuť spoluprácu.

Pozrime sa teda, ktoré sú tie postupy, ktoré pomáhajú pri dosahovaní spolupráce.

Zapojte vývoj do všetkých relevantných stretnutí a diskusií prevádzkového tímu a naopak.

To ich nielen spája, ale pomáha to pochopiť každú ich pracovnú oblasť, ich každodenné problémy a to, ako sa ich práca navzájom ovplyvňuje, a aké sú kritické veci, o ktoré by sa mal každý starať, aby sa problémom neskôr vyhli a preto ich zbližuje a iniciuje medzi sebou vždy pohodlnú diskusiu.

Pred zavedením praxe DevOps sa tím vývojárov nikdy nestaral o dodanie softvéru do Operácií. Viete, že boli nevedomí alebo sa nikdy neobťažovali napríklad infraštruktúrou, konfiguráciami, nastaveniami serverov, sieťovými konfiguráciami, sledovaním živých vystúpení atď.,

Kedysi si mysleli, že všetky tieto činnosti sú zodpovednosťou operačného tímu a tím vývojárov o nich nikdy nevedel. Predtým dodávkou pre vývojový tím mala byť dodávka samotnému operačnému tímu, ale s praxou DevOps dodávka znamená do výroby, nielen do prevádzky.

Podobne sa operačné systémy nikdy nestarali o kód, ktorý vývojový tím produkoval. Akýkoľvek problém, s ktorým sa stretnú počas problémov s inštaláciou softvéru, funkčnosťou alebo výkonom vo výrobe, jednoducho odovzdali dolár vývojovému tímu a požiadali ich o opravu a vrátenie.

Takže znalosť vzájomnej práce a porozumenie ich úloh a vlastnenie problémov ostatných počas celého cyklu pomáha tímu rýchlo ich vyriešiť.

Pretože vedia, kde je problém a čo sa v programe deje a čo spôsobuje problém vo výrobe, a preto ho môžu bez väčších ťažkostí priamo vyriešiť.

Spolupráca teda znamená, že vývojový tím musí rozumieť infraštruktúre a konfigurácii a prevádzkový tím sa musí starať o kód, kvalitu, dodávku a časové harmonogramy.

Pochopenie vzájomnej závislosti pomôže urýchliť prácu a dodať ju včas.

Rovnako ako pri inštalácii softvéru, operačný tím závisí od vývojového tímu pri riešení akýchkoľvek problémov týkajúcich sa inštalácie. Podobne, zatiaľ čo pri kódovaní vývojový tím závisí od mnohých predpokladov, ktoré existuje v priamom prenose, aby ich operačný tím mohol zabezpečiť počas procesu kódovania.

Ďalší Príklad je testovací tím závisí od operačného tímu, aby poskytol živé vzorky z výroby na testovanie. Podrobnosti o konfigurácii prostredia, ktoré sa majú nastaviť vo vývojovom prostredí atď.

Tím musí teda navzájom spolupracovať, porozumieť vzájomnej závislosti a poskytnúť údaje alebo informácie včas bez toho, aby spôsobil oneskorenie, a to tak, že bude pamätať na faktor časového pásma.

Zachovajte transparentnosť prijatím postupov DevOps, ako je napríklad riadenie zdrojov alebo verzií, ktoré umožňujú tímu pochopiť všetko o programe a pomáhajú predchádzať nedorozumeniam.

Týmto sa v podstate udržuje transparentnosť v tíme.

Členovia tímu nemusia byť závislí od žiadneho jednotlivca ani od konkrétnej informácie, aby povedali, či chce niekto poznať konfiguráciu nastavenú na konkrétnom uzle v klastri, takže nemusí čakať na prebudenie operačného tímu a poskytnúť im tieto podrobnosti, skôr môžu ísť do nástroja na správu verzií a načítať tieto informácie a môžu svoju úlohu bezodkladne dokončiť.

otázky a odpovede na pohovor s kódom java

Učenie sa od seba navzájom, najmä od chyby druhých, je najväčšou vlastnosťou spolupráce. Aby už neopakovali chyby, ktoré urobil niekto iný.

Takže vývoj sa učí z prevádzky a operácie sa učí z vývoja, či už ide o novú technológiu, nástroj alebo niečo robí jednoduchším a lepším spôsobom. Ak sú obaja na jednej stránke, a preto navzájom spolupracujú tým, že sa navzájom učia.

Operácie vždy pociťovali, že vývojársky tím je veľmi pomalý a nemôžu dodať včas. Teraz, keď interagujú s vývojovým tímom každý deň, rozumejú tomu, čo spôsobuje oneskorenie, nech už je to menej jasné požiadavky, problém s dizajnom, problém s kódovaním alebo akýkoľvek iný problém s nástrojmi.

Dokonca aj oni prispievajú a poskytujú svoje cenné návrhy na zlepšenie.

Tiež v prípade akýchkoľvek problémov z výroby alebo z vývojového miesta zavádza DevOps kultúru prvého riešenia problému, než sa snaží zistiť, kto alebo ktorý tím zaviedol tento problém. A tak sa každý snaží skôr zamerať na vyriešenie problému ako na stratu času zisťovaním, kto problém spôsobil.

Takže, prestaňte obviňovať každého z nich a považovať ich za svoj vlastný a prichádzať k ich spoločnému riešeniu a podpore problému, vzájomná podpora počas ich problémov je opäť spolupráca.

Môžem teda povedať, prestať hre dávať vinu, hranie viny je opäť charakteristikou spolupráce.

Keď každý začne uvažovať bežne rovnakým smerom, rovnakým myslením a prácou na rovnakých aspektoch a postupoch, bude to opäť spolupráca, ako keď sa vyvinie nejaká nová funkcia, každý premýšľa, ako to otestovať, ako to nasadiť, ako to monitorovať, je spolupráca.

Takže, keď myslíme bežne, v tíme je opäť charakteristika spolupráce.

Poďme si teraz oddýchnuť a v ďalšom videu sa dozvieme viac o spolupráci.

Výukový program PREV | NEXT Tutorial

Odporúčané čítanie

^