Meni

Sodelovanje v DevOpsu

collaboration devops

Preizkusite Naš Instrument Za Odpravo Težav

Sodelovanje v DevOps:

Majhni koraki dostave v DevOps je bilo podrobno razloženo v naši prejšnji vadnici.

Vemo, da je ključna mantra DevOps sodelovanje in zato je prišla beseda DevOps.

Preberite => Vadnice za poglobljene programe za razvijanje

Sodelovanje naj bi se združilo v enotno skupino za reševanje kakršnih koli težav v programu, kar ovira osredotočenost strank na vratarja programa in jih reši tako, da jih v najkrajšem možnem času prevzame kot lastno težavo, brez kakršne koli krivde.

Sodelovanje v DevOps

Sodelovanje vse uči, da se med seboj pogovarjajo, se srečujejo iz oči v oči, se vključujejo v svoje sestanke, razprave, razumejo naloge, odvisnost in imajo preglednost pri delu in delujejo proaktivno, da preprečijo težave.

sintaksa java vs c ++

VIDEO Del 2, blok 5: Sodelovanje - 15 minut 36 sekund

Prepis:

Izraz kolaboracija se vedno znova ponavlja v DevOpsu, mantra Devops pa je kolaboracija. Torej, razumejmo, kaj v resnici pomeni 'sodelovanje' v razvoju programske opreme in kontekstu DevOps.

Po mojem mnenju takoj, ko organizacija reče, uvedemo DevOps, samodejno razmišljanje o sodelovanju, ki je vezano na prakso devopa, se začne v mislih vseh in jih naredi bolj osredotočene in pozorne na sodelovanje ter začnejo čutiti, da morajo sodelovati . To je čarobnost sodelovanja.

Tako je začetek sodelovanja DevOps že na začetku projekta zelo pomemben za organizacijo in ekipo. Mislim ekipa, člani ekipe programa.

Razložil bom nekaj primerov, ko sem videl, da Dev sodeluje z Opsom in ops, ki sodelujejo z ekipo za razvijalce, da bomo vedeli, kaj dejansko pomeni sodelovanje v kontekstu DevOps.

To je predstavitev primerka ena.

Obstajal je primer, da je bila v namestitvenem skriptu ali konfiguracijskem skriptu neka neznana težava, da je ekipa ops našla izziv pri namestitvi programske opreme na določeno postavitev grozda v določeni geografiji.

To je vrglo neko neznano napako in je bil čisti produkcijski problem, ki se v razvojnem okolju ni nikoli zgodil, operativna skupina pa je res porabila veliko truda, da bi jih rešila sama, misleč, da gre za nekaj, kar je povezano s postavitvijo, in jo morajo rešiti to, ki se že dolgo ni rešilo.

Nato se je ekipa razvijalcev takoj oglasila, ne da bi jo sploh povabili na pomoč, čeprav je bil časovni pas drugačen, prevzel je nadzor nad proizvodnim mestom, saj veste, da na splošno dostop do produkcije ne bo omogočen vsem, Ops pa samo deli napako podrobnosti ali katere koli druge informacije, ki jih ekipa potrebuje za odpravljanje napak.

Toda v tej situaciji je treba omogočiti dostop enemu od članov razvojne ekipe, ki je predano nekaj ur analiziral težavo v živo in zagotovil takojšnje delo, zato je bila težava hitro rešena.

To je primer sodelovanja, ko je ekipa razvijalcev prostovoljno imela težavo in pomagala operativni skupini, da jo je rešila. To je čisti primer sodelovanja.

Podobno, še en primer, naj to shematsko pokažem, kar sem narisal. Drug primer je, da so stvari po nadgradnji programske opreme na določenem mestu nekaj dni delovale precej dobro, kar naenkrat se je delovanje aplikacije začelo upočasnjevati.

Končni uporabniki so se zaradi te upočasnitve začeli soočati z velikimi transakcijskimi izgubami. Veliko pritožb je začelo prihajati do predstavnikov družbene odgovornosti, mislim, na predstavnike služb za stranke, ki so nato začeli spremljati skupino glede tega vprašanja.

V tem primeru sta se takoj združili tako ekipa razvijalcev kot tudi operacijski sistem Ops in z informacijami in podrobnostmi o telemetriji, ki jih je ekipa ekipe Ops posredovala ekipi za razvijalce, lahko odpravijo težavo in ugotovijo, da je pri razdelitvi obremenitve nekaj težav zato je bila predstava počasna.

Torej sta obe ekipi skupaj odpravili težavo in jo v nekaj urah vrnili v normalno stanje. Torej, tu sta se skupaj razvila Dev in Ops, ki sta skupaj rešila težavo, namesto da bi Dev rekel svoj problem Ops in Ops mislil, da gre za Devov problem, zato ga mora ekipa za razvijanje rešiti in odpraviti.

To je očiten primer sodelovanja, kjer so vsi lastniki težav, namesto da bi igrali igro krivde, ne glede na to, katere izdaje gre, ali pa zapravljamo čas, da bi ugotovili, za katero težavo gre, ob upoštevanju, da končni uporabnik trpi in težava potrebuje kmalu popraviti.

Torej tudi tu vprašanje ni nujno samo iz produkcije, lahko gre za katero koli preprosto interno težavo z razvojem programske opreme, tako preprosto, kot je vsakodnevna težava, težava z oblikovanjem ali arhitektura ali celo preprosta vprašanje orodja.

Vsaka težava, povezana s programom, ali kakršna koli težava, za katero ekipa ve, da povzroča škodo kupcu ali upočasnjuje program, mora biti v lasti vseh, namesto da bi izolirali težavo, da gre za razvojni problem ali težavo z operacijo ali težavo s testiranjem, in prispevati k čim hitrejšemu reševanju, je sodelovanje.

Torej, sodelovanje v kontekstu DevOps je razvoj in delovanje, ki se povezujeta in sodelujeta pri čimprejšnjem reševanju problema, pri čemer se upošteva osredotočenost na kupca.

Sodelovanje ima tako Dev kot Ops lastnik dogajanja v živo, spremljanje in beleženje ter preverjanje učinkovitosti, ki sta na vrhu, da bi rešili težavo, ki se pojavlja predvsem v proizvodnji v interesu končnega uporabnika.

ALI preprosto, lahko rečem, da celotna ekipa, ki nenehno sodeluje pri reševanju problema za dosego programskih ciljev, ob upoštevanju pozornosti strank, predstavlja sodelovanje. Ponavljam, nenehno skupno reševanje problemov za dosego programskih ciljev, pri čemer je pozornost usmerjena na kupca, je sodelovanje.

Potem se pojavi vprašanje, kako naj razvijemo to sodelovanje in kdaj moramo začeti sodelovanje med ekipo, ki sedi milje drug od drugega ??

Očitno vemo, da tako Dev kot Ops ne moreta locirati. Ekipa Ops mora biti bližje delujočemu spletnemu mestu ali podatkovnim centrom, razvijalec pa bližje centru za razvoj programske opreme. Torej, kako doseči stalno sodelovanje med obema ekipama ??

Prvič, začetek sodelovanja DevOps že na začetku projekta je zelo pomemben za organizacijo in ekipo. Tu mislim na ekipo, ki je članica programa.

Vadba nekaj naslednjih stvari bi pomagala premostiti vrzel med ekipo in premagati omejitve virtualnih ekip ter pomaga pri doseganju sodelovanja.

Torej, poglejmo, katere so tiste prakse, ki pomagajo pri doseganju sodelovanja.

Vključite razvoj na vsa ustrezna srečanja in razprave operativne skupine in obratno.

s čim odpreti json datoteke

To jih ne samo združuje, temveč tudi pomaga razumeti vsako njihovo delovno področje, njihove vsakodnevne težave in kako njihovo delo vpliva drug na drugega ter katere so ključne stvari, za katere bi moral vsak skrbeti, da bi se kasneje izognil težavam in zato jih zbliža in vsakič sproži prijetno razpravo med seboj.

Pred uvedbo prakse DevOps ekipa razvijalcev ni nikoli skrbela za dostavo programske opreme operacijam. Veste, da so bili včasih nevedni ali se nikoli niso trudili glede stvari, kot so infrastruktura, konfiguracije, nastavitve strežnikov, omrežne konfiguracije, spremljanje nastopov v živo itd.,

Včasih so mislili, da so vse te dejavnosti v pristojnosti operativne ekipe in da skupina za razvoj ni nikoli vedela za to. Prej je bila dobava za razvojno ekipo namenjena dostavi samo operativni skupini, toda s prakso DevOps dostava pomeni proizvodnjo in ne le operacijam.

Podobno tudi operacijski sistem nikoli ni skrbel za kodo, ki jo je razvijala razvojna skupina. Vsako težavo, s katero se soočajo med težavami pri namestitvi programske opreme, funkcionalnosti ali zmogljivosti v proizvodnji, so preprosto prenesli denar na razvojno skupino in jih prosili, da jo popravijo in vrnejo.

Poznavanje dela drug drugega in razumevanje njihove naloge ter posedovanje težav med seboj skozi celoten cikel pomaga ekipi, da hitro reši težave.

Ker vedo, kje je težava in kaj se dogaja v programu in kaj povzroča težavo v proizvodnji, zato jo lahko brez večjih težav neposredno odpravijo.

Torej sodelovanje pomeni, da mora razvojna skupina razumeti infrastrukturo in konfiguracijo, operativna ekipa pa se mora truditi glede kode, kakovosti, dobave in časovnih okvirov.

Razumevanje odvisnosti drug od drugega bo pomagalo pospešiti delo in ga pravočasno dostaviti.

Tako kot med namestitvijo programske opreme je tudi operacijska skupina odvisna od razvojne skupine, da reši kakršna koli vprašanja, povezana z namestitvijo. Podobno je med kodiranjem razvojna skupina odvisna od številnih predpogojev, ki obstajajo v živo, da operacijska skupina poskrbi za skrb med postopkom kodiranja.

Še eno Primer je preskusna skupina odvisna od operativne skupine, ki za preskušanje zagotovi vzorčne podatke v živo iz proizvodnje. Podrobnosti o konfiguraciji okolja, ki jih je treba nastaviti v razvojnem okolju itd.

Torej morata obe ekipi medsebojno sodelovati in razumeti medsebojno odvisnost ter pravočasno zagotoviti podatke ali informacije, ne da bi povzročali kakršne koli zamude, pri tem pa upoštevali dejavnik časovnega pasu.

Ohranite preglednost s sprejetjem praks DevOps, kot je nadzor virov ali nadzor različic, ki skupini omogoča razumevanje vsega o programu in pomaga pri izogibanju nesporazumom.

To v bistvu ohranja preglednost znotraj ekipe.

Članom ekipe ni treba biti odvisni od posameznika ali katerega koli določenega podatka, če nekdo želi vedeti konfiguracijo, nastavljeno na določenem vozlišču v gruči, zato jim ni treba čakati, da se operativna ekipa zbudi in jim posredujte te podrobnosti, namesto tega lahko obiščejo orodje za nadzor različic in pridobijo te informacije ter lahko svojo nalogo brez odlašanja opravijo.

Največja značilnost sodelovanja je, če se učimo drug od drugega, predvsem pri napakah drugih. Da ne bi ponovili teh napak, ki jih je že storil nekdo drug.

najboljše slušalke za navidezno resničnost za xbox one

Torej, razvoj se uči iz operacije, operacije pa se učijo iz razvoja, pa naj gre za novo tehnologijo, orodje ali nekaj, kar počne na preprostejši in boljši način. Kjer sta oba na isti strani in zato sodelujeta med seboj tako, da se učita drug od drugega.

V operacijah se je vedno čutilo, da je ekipa razvijalcev zelo počasna in ne more doseči časa, zdaj, ko vsakodnevno sodelujejo z razvojno skupino, razumejo, kaj povzroča zamudo, pa naj bo to manj jasna zahteve, problem oblikovanja, problem kodiranja ali kateri koli drug problem z orodjem.

Tudi oni se postavljajo in ponujajo svoje dragocene predloge za izboljšanje.

Prav tako v primeru kakršne koli težave bodisi iz produkcije bodisi z mesta za razvoj DevOps uvede kulturo, da najprej odpravi težavo, kot da poskuša ugotoviti, kdo ali katera ekipa je to težavo uvedla. In tako se vsi poskušajo osredotočiti na odpravljanje težave, namesto da bi zapravljali čas, da bi ugotovili, kdo je povzročil težavo.

Torej, nehajte obtoževati in obravnavati vsako vprašanje kot svojo in se oglasite, da jih skupaj rešite in podprite problem, medsebojno podpiranje med njihovimi težavami je spet sodelovanje.

Torej, lahko rečem, nehajte kriviti igro, obtoževanje iger na srečo je značilnost ponovnega sodelovanja.

Ko vsi začnejo razmišljati pogosto v isto smer, isto miselnost in delati na istih vidikih in praksah, je to spet sodelovanje, kakršno je, kadar se razvije kakšna nova funkcija, ko vsi razmišljajo, kako to preizkusiti, kako to uporabiti, kako to spremljati, je sodelovanje.

Torej, skupno razmišljanje znotraj ekipe je znova značilnost sodelovanja.

Zdaj si oddahnimo in malo več o sodelovanju bomo razumeli v naslednjem videu.

PREV Vadnica | NASLEDNJA Vadnica

Priporočeno branje

^