Meny

Samarbete i DevOps

collaboration devops

Prova Vårt Instrument För Att Eliminera Problem

Samarbete i DevOps:

Små inkrement av leveranser i DevOps förklarades i detalj i vår tidigare handledning.

Vi vet att nyckelmantrat för DevOps är samarbete och därmed ordet DevOps anlände.

Läs igenom => Djupgående DevOps-handledning

Samarbete är att samlas som ett enda team för att ta itu med alla problem i programmet, vilket hindrar kundens fokus i programmet och löser dem genom att äga dem som sitt eget problem så snabbt som möjligt, utan något skuldspel.

Samarbete i DevOps

Samarbete lär alla att prata med varandra, träffa varandra ansikte mot ansikte, involvera varandra i sina möten, diskussioner, förstå varandras uppgifter, beroende och ha transparens i arbetet och arbeta proaktivt för att förhindra problemen.

VIDEO Del 2 Block 5: Samarbete - 15 minuter och 36 sekunder

Transkript:

Termen samarbete upprepas om och om igen i DevOps och Devops mantra är samarbete. Så låt oss förstå vad ”samarbete” egentligen betyder i mjukvaruutveckling och DevOps-sammanhang.

Så snart en organisation säger, implementerar vi DevOps enligt mig, automatiskt börjar tanken på samarbete som är knuten till devops övning i allas hjärna och gör dem mer fokuserade och alerta för samarbete och de börjar känna att de behöver samarbeta . Det är magin i samarbete.

Så att initiera DevOps-samarbete från början av projektet är mycket viktigt för organisationen och teamet. Teamet menar jag, teammedlemmar i programmet.

Jag kommer att förklara ett par tillfällen där jag har sett Dev samarbeta med Ops och ops samarbeta med dev-teamet så att vi vet vad som faktiskt samarbetar betyder i DevOps-sammanhanget.

Detta är representationen av exempel ett.

Det fanns en förekomst av att det fanns något okänt problem i installationsskriptet eller konfigurationsskriptet där ops-teamet hittade en utmaning med att installera programvaran på en viss uppsättning av ett kluster i en viss geografi.

Det kastade ett okänt fel och var ett rent produktionsproblem, som aldrig inträffade i utvecklingsmiljön och driftsteamet spenderade verkligen mycket på att själva lösa dem och trodde att det är något relaterat till uppställningen, och de måste lösa det, som inte lösts ganska länge.

Omedelbart slog Dev-teamet in utan att ens bli inbjuden att hjälpa till, även om tidszonen var annorlunda tog den kontrollen över produktionsplatsen, du vet generellt att tillgång till produktionen inte kommer att ges till alla, Ops delar bara felet detaljer eller annan information som teamet behöver för felsökningsändamål.

Men den här situationen krävs för att ge tillgång till en av teammedlemmarna, som dedikerat några timmar på att analysera frågan live och tillhandahållit omedelbart arbete och därmed löstes problemet snabbt.

Detta är fallet av samarbetet där dev-teamet frivilligt ägde problemet och hjälpte ops-teamet att lösa det. Detta är en ren instans av samarbete.

På samma sätt, en annan instans, låt mig visa det schematiskt, vilket jag har ritat. En annan instans är att saker och ting fungerade ganska bra efter programuppgraderingen på en viss webbplats i några dagar, plötsligt började programmets prestanda sakta ner.

Slutanvändare började möta allvarliga transaktionsförluster på grund av denna avmattning. Många klagomålssamtal började komma till CSR: s, jag menar, kundtjänstrepresentanter och de började i sin tur följa upp teamet i frågan.

Vid detta tillfälle samlades omedelbart både Dev- och Ops-teamet, och med informationen och telemetridetaljerna som Ops-teamet gav dev-teamet kunde de felsöka problemet och identifiera att det fanns något problem i lastdelningsaspekten och därför var prestationen långsam.

Så, båda lagen arbetade tillsammans för att lösa problemet och återställa till normalitet inom några timmar. Så här kom både Dev och Ops tillsammans fram och samarbetade tillsammans för att lösa problemet istället för att Dev sa sitt Ops-problem och Ops tänkte att det är Devs problem och dev-teamet måste titta på och fixa det.

Detta är den tydliga instansen av samarbete där alla äger frågorna, istället för att spela skuldspelet, oavsett vems problem det är eller slösa tid med att ta reda på vem det är, med tanke på att slutanvändaren lider och frågan behöver ska fixas snart.

Återigen här behöver frågan inte bara vara från produktionen, det kan vara något enkelt internt programvaruutvecklingsproblem, så enkelt som det dagliga problemet, eller en designproblem, eller ett arkitekturproblem eller till och med ett enkelt verktygsproblem.

Alla problem relaterade till programmet eller något problem som teamet vet att, orsakar skada på kunden eller saktar ner programmet måste ägas av alla, istället för att isolera problemet att det är utvecklingsproblem eller driftsproblem eller testproblem, och bidra till att ta itu med det så snabbt som möjligt, är ett samarbete.

Så samarbete i DevOps-sammanhang är utveckling och verksamhet som samlas och arbetar tillsammans för att lösa problemet så tidigt som möjligt, med tanke på kundfokus.

Samarbete är både Dev och Ops som äger vad som händer i live, övervakning och loggning och prestandakontroll är på topp för att lösa problemet som uppstår särskilt i produktionen i slutanvändarens intresse.

ELLER helt enkelt kan jag säga att hela teamet, som hela tiden arbetar tillsammans för att lösa problemet för att uppnå programmålen, med tanke på kundfokus i åtanke är samarbetet. Jag upprepar att arbeta kontinuerligt tillsammans för att lösa problemen för att uppnå programmålen med att hålla kundfokus i åtanke är samarbete.

Då uppstår en fråga, hur utvecklar vi detta samarbete och när behöver vi inleda samarbetet mellan teamet, som sitter mil från varandra ??

Självklart vet vi att både Dev och Ops inte kan samlokalisera. Ops-teamet måste vara närmare arbetsplatsen eller datacenter och utvecklaren måste vara närmare programvaruutvecklingscentret. Så, hur uppnår vi det ständiga samarbetet mellan båda lagen ??

Först och främst att initiera DevOps-samarbete från början av projektet är mycket viktigt för organisationen och teamet. Teamet jag menar här är teamets medlemmar i programmet.

Att öva på några av följande saker skulle hjälpa till att överbrygga klyftan mellan teamet och övervinna begränsningen av virtuella team och hjälper till att uppnå samarbetet.

Så, låt oss se vilka metoder som hjälper till att uppnå samarbetet.

hur man öppnar apk på android

Involvera utveckling i alla relevanta möten och diskussioner i driftsteamet och vice versa.

Detta förenar dem inte bara utan hjälper också till att förstå var och en av deras arbetsområde, deras dagliga problem och hur deras arbete påverkar varandra, och vad är de kritiska sakerna som var och en bör ta hand om för att undvika problemen senare och därmed för dem närmare och inleder en bekväm diskussion mellan varandra varje gång.

Innan introduktionen av DevOps-praxis brukade dev-teamet aldrig bry sig om att leverera programvaran till Operations. Du vet att de brukade vara okunniga eller aldrig bry sig om saker som infrastruktur, konfigurationer, serverinställningar, nätverkskonfigurationer, övervakning av liveföreställningar etc.,

De brukade tro att alla dessa aktiviteter var Operations-teamets ansvar och dev-teamet brukade aldrig veta om det. Tidigare innebar leveransen för utvecklingsteamet att vara leverans till Operations-teamet ensam, men med DevOps-praxis betyder leverans till produktionen och inte bara till verksamheten.

På samma sätt brukade ops aldrig bry sig om koden som utvecklingsteamet producerade. Alla problem som de möter under programinstallationen, funktionalitets- eller prestandaproblem i produktionen, de brukade helt enkelt skicka pengar till utvecklingsteamet och be dem att fixa och ge tillbaka det.

Så att känna varandras arbete och förstå deras uppgift och äga varandras problem under hela cykeln hjälper teamet att lösa problemen snabbt.

Eftersom de vet var problemet är och vad som händer i programmet och vad som orsakar problemet i produktionen och därmed direkt kan fixa det utan stora svårigheter.

Så samarbete innebär att utvecklingsteamet behöver förstå infrastruktur och konfiguration och driftsteamet behöver bry sig om kod, kvalitet, leverans och tidslinjer.

Att förstå beroendet av varandra hjälper till att påskynda arbetet och leverera det i tid.

Precis som under programvaruinstallationen är driftsteamet beroende av ett utvecklingsteam för att lösa alla problem relaterade till installationen. På samma sätt beror utvecklingsgruppen på kodning av många förutsättningar som finns live för att driftsteamet ska kunna ta hand om kodningsprocessen.

Annan Exempel är testteamet beroende av driftsteamet för att tillhandahålla live-data från produktionen för testning. Miljökonfigurationsdetaljer som ska ställas in i utvecklingsmiljön etc.

Så både teamet måste samarbeta med varandra och förstå beroendet av varandra och tillhandahålla informationen eller informationen i tid utan att orsaka någon försening genom att tänka på tidszonfaktorn.

Behåll transparens genom att använda DevOps-metoder som källkontroll eller versionskontroll som gör det möjligt för teamet att förstå allt om programmet och hjälper till att undvika missförstånd.

Så detta är i grunden att bibehålla transparensen i teamet.

Teammedlemmar behöver inte behöva vara beroende av någon individ eller någon viss informationsstycke om någon vill veta konfigurationen som är inställd på en viss nod i klustret, så de behöver inte vänta på att operationsteamet vaknar och ge dessa uppgifter till dem, snarare kan de gå till versionskontrollverktyget och hämta denna information och kan slutföra sin uppgift utan dröjsmål.

Att lära av varandra, särskilt från andra misstag, är de största egenskaperna hos samarbete. Så att de inte upprepar dessa misstag som redan gjorts av någon annan.

Så, utveckling är att lära av verksamheten och verksamheten är att lära av utvecklingen, vare sig det är en ny teknik, ett verktyg eller att göra något på ett enklare och bättre sätt. Där båda ligger på samma sida och därmed samarbetar de med varandra genom att lära av varandra.

Verksamheten brukade alltid känna att dev-teamet är mycket långsamt och att de inte kan leverera i tid, nu när de interagerar med utvecklingsteamet dagligen, förstår de vad som orsakar förseningen, vare sig det är mindre tydligt i krav, designproblem, kodningsproblem eller något annat verktygsproblem.

Även de slår in och ger sina värdefulla förslag att förbättra.

Vid eventuella problem, antingen från produktionen eller från utvecklingswebbplatsen, introducerar DevOps en kultur för att först lösa problemet än att försöka ta reda på vem eller vilket team som har introducerat det här problemet. Och så försöker alla fokusera på att åtgärda problemet snarare än att slösa bort tid på att ta reda på vem som orsakade problemet.

Så sluta skylla och betrakta varandras problem som sitt eget och komma fram för att lösa dem tillsammans och stödja problem, att stödja varandra under deras utgåvor är återigen ett samarbete.

Så jag kan säga, sluta skylla på spel, skylla på spel är en karaktäristik av samarbete igen.

När alla börjar tänka vanligt i samma riktning, är samma tänkesätt och arbetar med samma aspekter och metoder igen ett samarbete som när någon ny funktion utvecklas, alla tänker på hur man testar detta, hur man distribuerar detta, hur man övervakar detta, är ett samarbete.

Så, att tänka vanligt, är inom teamet återigen ett kännetecken för samarbetet.

Låt oss ta en paus nu och förstå lite mer om samarbete i vår nästa video.

PREV-handledning | NÄSTA självstudie

Rekommenderad läsning

^