Menu

Samarbejde i DevOps

collaboration devops

Prøv Vores Instrument Til At Fjerne Problemer

Samarbejde i DevOps:

Små inkrement af leverancer i DevOps blev forklaret detaljeret i vores tidligere tutorial.

Vi ved, at nøglemantraet i DevOps er samarbejde, og derfor ankom ordet DevOps.

Læs igennem => Dybdegående DevOps-vejledninger

Samarbejde er at komme sammen som et enkelt team for at løse ethvert problem i programmet, hvilket forhindrer programmålet kundefokus i tankerne og løse dem ved at eje dem som deres eget problem så hurtigt som muligt uden noget skyldspil.

Samarbejde i DevOps

Samarbejde lærer alle at tale med hinanden, møde hinanden ansigt til ansigt, involvere hinanden i deres møder, diskussioner, forstå hinandens opgaver, afhængighed og have gennemsigtighed i arbejdet og arbejde proaktivt for at forhindre problemerne.

VIDEO Del 2 Blok 5: Samarbejde - 15 minutter og 36 sekunder

Udskrift:

Udtrykket samarbejde gentages igen og igen i DevOps, og Devops-mantraet er samarbejde. Så lad os forstå, hvad 'samarbejde' virkelig betyder i softwareudvikling og DevOps-sammenhæng.

Så snart en organisation siger, implementerer vi DevOps ifølge mig, automatisk tænker samarbejdet, der er knyttet til devops praksis, starter i alles sind og gør dem mere fokuserede og opmærksomme på samarbejde, og de begynder at føle, at de har brug for at samarbejde . Det er magien ved samarbejde.

Så det er meget vigtigt for organisationen og teamet at starte DevOps-samarbejde lige fra starten af ​​projektet. Det hold, jeg mener, holdets medlemmer af programmet.

Jeg vil forklare et par tilfælde, hvor jeg har set Dev samarbejde med Ops og ops samarbejde med dev-teamet, så vi ved, hvad der faktisk samarbejder betyder i DevOps-sammenhængen.

standard gateway er ikke tilgængelig windows 8

Dette er repræsentationen af ​​eksempel 1.

Der var et tilfælde, at der var et ukendt problem i installationsskriptet eller konfigurationsscriptet, som ops-teamet fandt en udfordring med at installere softwaren på et bestemt sæt af en klynge i en bestemt geografi.

Det smed en ukendt fejl og var et rent produktionsproblem, der aldrig opstod i udviklingsmiljøet, og driftsteamet brugte virkelig en stor indsats i at løse dem selv og troede, at det er noget relateret til opsætningen, og de skal løse det, som ikke blev løst i lang tid.

Derefter slog Dev-teamet ind uden engang at blive inviteret til at hjælpe, selvom tidszonen var anderledes, tog den kontrollen over produktionsstedet, du ved generelt, at adgang til produktionen ikke vil blive givet til alle, Ops deler bare fejlen detaljer eller andre oplysninger, som teamet har brug for til fejlfindingsformål.

Men denne situation kaldes for at give adgang til en af ​​teammedlemmet, der dedikeret brugte få timer på at analysere problemet live og leverede øjeblikkelig arbejde rundt, og derfor blev problemet løst hurtigt.

Dette er forekomsten af ​​samarbejdet, hvor dev-teamet frivilligt ejede problemet og hjalp ops-teamet med at løse det. Dette er en ren forekomst af samarbejde.

Tilsvarende, en anden forekomst, lad mig vise det diagrammatisk, som jeg har tegnet. En anden forekomst er, at tingene fungerede ret fint efter softwareopgraderingen på et bestemt sted i et par dage, pludselig begyndte applikationens ydeevne at bremse.

Slutbrugere begyndte at blive udsat for alvorlige transaktionstab på grund af denne afmatning. Mange klageopkald begyndte at komme til CSR'er, jeg mener kundeservicemedarbejdere, og de begyndte igen at følge op på teamet om problemet.

I dette tilfælde kom straks både Dev- og Ops-teamet sammen, og med de oplysninger og telemetridetaljer, der blev leveret af Ops-teamet til dev-teamet, kunne de fejle problemet og identificere, at der var noget problem i belastningsdelingsaspektet derfor var præstationen langsom.

Så begge hold arbejdede sammen om at løse problemet og bringe det tilbage til normalitet inden for få timer. Så her kom både Dev og Ops sammen frem og samarbejdede om at løse problemet i stedet for Dev, der sagde sit Ops-problem, og Ops tænkte, at det er Devs problem, og dev-teamet skal se på og rette det.

Dette er den klare forekomst af samarbejde, hvor alle ejer problemerne i stedet for at spille skyldspelet, uanset hvis problem det er eller spilder tid på at finde ud af, hvem det er problem, idet man husker, at slutbrugeren lider, og problemet har brug for skal løses snart.

Så igen her behøver problemet ikke kun at være fra produktionen, det kan være ethvert simpelt internt softwareudviklingsproblem, så simpelt som det daglige problem eller et designproblem eller et arkitektproblem eller endda et simpelt værktøjsproblem.

Ethvert problem relateret til programmet eller ethvert problem, som teamet ved, forårsager skade på kunden eller bremser programmet, skal ejes af alle i stedet for at isolere problemet, at det er udviklingsproblem eller driftsproblem eller testproblem, og bidrage til at få det behandlet så hurtigt som muligt, er et samarbejde.

Så, samarbejde i DevOps-sammenhæng er udvikling og operationer, der kommer sammen og arbejder sammen for at løse problemet så tidligt som muligt, idet man holder kundefokus i tankerne.

Samarbejde er både Dev og Ops at eje om, hvad der sker i live, overvågning og logning og præstationskontrol er øverst for at løse det problem, der opstår især i produktionen i slutbrugerens interesse.

ELLER simpelthen kan jeg sige, at hele teamet arbejder konstant sammen for at løse problemet for at nå programmålene og holde kundefokus i tankerne er samarbejdet. Jeg gentager, at vi konstant arbejder sammen for at løse problemerne for at nå programmålene med at holde kundens fokus i tankerne er samarbejde.

Derefter opstår et spørgsmål, hvordan udvikler vi dette samarbejde, og hvornår har vi brug for at indlede samarbejdet mellem holdet, der sidder miles væk fra hinanden ??

Vi ved selvfølgelig, at både Dev og Ops ikke kan samlokalisere. Ops-teamet skal være tættere på arbejdssiden eller datacentre, og udvikleren skal være tættere på softwareudviklingscentret. Så hvordan opnår vi det konstante samarbejde mellem begge hold ??

Først og fremmest at starte DevOps-samarbejde lige fra starten af ​​projektet er meget vigtigt for organisationen og teamet. Det hold, jeg mener her, er teamets medlemmer af programmet.

Øvelse af et par af følgende ting vil hjælpe med at bygge bro mellem holdet og overvinde begrænsningen af ​​virtuelle teams og hjælper med at opnå samarbejdet.

Så lad os se, hvilke fremgangsmåder der hjælper med at opnå samarbejdet.

Involver udvikling i alle relevante møder og diskussioner i operationsteamet og omvendt.

Dette bringer dem ikke kun sammen, men hjælper også med at forstå hvert af deres arbejdsområder, deres daglige problemer, og hvordan deres arbejde påvirker hinanden, og hvad er de kritiske ting, som hver enkelt skal tage sig af for at undgå problemerne senere og bringer dem derfor tættere på og indleder en behagelig diskussion mellem hinanden hver gang.

Før introduktionen af ​​DevOps-praksis plejede dev-teamet aldrig at bekymre sig noget om at levere softwaren til Operations. Du ved, de plejede at være uvidende eller aldrig gider med ting som infrastruktur, konfigurationer, serveropsætninger, netværkskonfigurationer, overvågning af live forestillinger osv.,

De plejede at tro, at alle disse aktiviteter var Operations-teamets ansvar, og dev-teamet vidste aldrig noget om det. Tidligere var levering til udviklingsteam meningen at være levering til Operations-teamet alene, men med DevOps-praksis betyder levering til produktion og ikke kun til operationer.

Tilsvarende brugte ops aldrig noget om den kode, som udviklingsteamet producerede. Ethvert problem, de står over for under installation af software, funktionalitet eller ydeevne i produktionen, brugte de simpelthen pengene til udviklingsteamet og bede dem om at rette og give det tilbage.

Så ved at kende hinandens arbejde og forstå deres opgave og eje hinandens problem gennem hele cyklussen hjælper teamet med at løse problemerne hurtigt.

Fordi de ved, hvor problemet er, og hvad der sker i programmet, og hvad der forårsager problemet i produktionen og dermed kan gå direkte og rette det uden store problemer.

Så samarbejde betyder, at udviklingsteamet skal forstå infrastruktur og konfiguration, og driftsteamet skal bekymre sig om kode, kvalitet, levering og tidslinjer.

At forstå afhængigheden af ​​hinanden vil hjælpe med at fremskynde arbejdet og levere det til tiden.

Ligesom under softwareinstallation afhænger driftsteamet af et udviklingsteam for at løse eventuelle problemer i forbindelse med installationen. På samme måde afhænger udviklingen af ​​kodning af en række forudsætninger, der eksisterer live, for at operationsteamet kan sørge for at tage sig af dem under kodningsprocessen.

En anden Eksempel er testteamet afhænger af driftsteamet for at levere eksempeldata fra produktionen til test. Oplysninger om miljøkonfiguration, der skal konfigureres i udviklingsmiljøet osv.

Så begge hold har brug for at samarbejde med hinanden og forstå afhængigheden af ​​hinanden og give dataene eller oplysningerne til tiden uden at forårsage nogen forsinkelse ved at huske på tidszonefaktoren.

Oprethold gennemsigtighed ved at vedtage DevOps-praksis som kildekontrol eller versionskontrol, der gør det muligt for teamet at forstå alt om programmet og hjælper med at undgå misforståelser.

Så dette opretholder dybest set gennemsigtigheden i teamet.

Teammedlemmer behøver ikke at være afhængige af nogen person eller noget bestemt stykke information, hvis nogen vil kende konfigurationen, der er konfigureret på en bestemt node i klyngen, så de behøver ikke at vente på, at operationsteamet vågner op og give dem disse detaljer, snarere kan de gå til versionskontrolværktøjet og hente disse oplysninger og kan fuldføre deres opgave uden nogen forsinkelse.

At lære af hinanden især fra de andres fejl er de største karakteristika ved samarbejde. Så de ikke gentager disse fejl, som en anden allerede har gjort.

Så udvikling er at lære af operationen, og operationer er at lære af udviklingen, det være sig en ny teknologi, et værktøj eller at gøre noget på en enklere og bedre måde. Hvor i begge er på samme side, og derfor samarbejder de med hinanden ved at lære af hinanden.

Operationer plejede altid at føle, at dev-teamet er meget langsomt, og at de ikke kan levere til tiden, nu når de interagerer med udviklingsteamet dagligt, forstår de, hvad der forårsager forsinkelsen, det være sig mindre klarhed i krav, designproblem, kodningsproblem eller ethvert andet værktøjsproblem.

Selv de kaster sig ind og giver deres værdifulde forslag til forbedring.

I tilfælde af et problem enten fra produktionen eller fra udviklingswebstedet introducerer DevOps en kultur for først at løse problemet end at prøve at finde ud af, hvem eller hvilket team der har introduceret dette problem. Og så prøver alle at fokusere på at løse problemet i stedet for at spilde tid på at finde ud af, hvem der forårsagede problemet.

Så hold op med at bebrejde og betragt hver enkelt sag som deres egen og kom frem for at løse dem sammen og understøttende problem. At støtte hinanden under deres problemer er igen et samarbejde.

Så jeg kan sige, stop med at skyde skylden på spil, skyldspil er igen et kendetegn for samarbejde.

Når alle begynder at tænke almindeligt i samme retning, er samme tankegang og arbejde med de samme aspekter og praksis igen et samarbejde som når der udvikles en ny funktion, alle tænker på, hvordan man tester dette, hvordan man implementerer dette, hvordan man overvåger dette, er et samarbejde.

Så det at tænke almindeligt er inden for holdet igen et kendetegn for samarbejdet.

Lad os tage en pause nu og forstå lidt mere om samarbejde i vores næste video.

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^