Menu

Samenwerking in DevOps

collaboration devops

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Samenwerking in DevOps:

Kleine hoeveelheden leveringen in DevOps werd in onze vorige tutorial in detail uitgelegd.

We weten dat de belangrijkste mantra van DevOps samenwerking is en daarom is het woord DevOps gearriveerd.

Doorlezen => Diepgaande DevOps-zelfstudies

Samenwerking is om als een enkel team samen te komen om elk probleem in het programma aan te pakken, wat de doelgerichte klantfocus van het programma belemmert en ze op te lossen door ze zo snel mogelijk als hun eigen probleem te beschouwen, zonder enige schuld.

Samenwerking in DevOps

Samenwerking leert iedereen om met elkaar te praten, elkaar persoonlijk te ontmoeten, elkaar te betrekken bij hun vergaderingen, discussies, elkaars taken te begrijpen, afhankelijkheid en transparantie in het werk te hebben en proactief te werken om de problemen te voorkomen.

VIDEO Deel 2 Blok 5: Samenwerking - 15 minuten 36 seconden

Vertaling:

De term samenwerking wordt keer op keer herhaald in DevOps en de Devops mantra is samenwerking. Laten we dus eens begrijpen wat ‘samenwerking’ echt betekent in de context van softwareontwikkeling en DevOps.

Volgens mij, zodra een organisatie zegt dat we DevOps implementeren, begint automatisch het denken aan samenwerking dat aan devops-praktijk is verbonden bij iedereen op gang en maakt ze meer gefocust en alert op samenwerking en krijgen ze het gevoel dat ze moeten samenwerken . Dat is de magie van samenwerking.

Het initiëren van DevOps-samenwerking vanaf het begin van het project is dus zeer essentieel voor de organisatie en het team. Het team bedoel ik, teamleden van het programma.

Ik ga een paar voorbeelden uitleggen waarin ik heb gezien dat Dev samenwerkte met Ops en ops samenwerkte met het ontwikkelteam, zodat we weten wat samenwerken eigenlijk betekent in de DevOps-context.

beste manier om youtube-audio te downloaden

Dit is de weergave van instantie één.

Er was een geval dat er een onbekend probleem was in het installatiescript of configuratiescript dat het ops-team een ​​uitdaging vond bij het installeren van de software op een bepaalde set-up van een cluster in een bepaalde geografie.

Het veroorzaakte een onbekende fout en was een puur productieprobleem, dat nooit voorkwam in de ontwikkelomgeving en het operatieteam heeft echt veel moeite gedaan om ze zelf op te lossen, denkend dat het iets is dat verband houdt met de set-up en dat ze het moeten oplossen het, dat lange tijd niet werd opgelost.

Toen kwam het Dev-team onmiddellijk binnen zonder zelfs maar te worden uitgenodigd om te helpen, hoewel de tijdzone anders was, het nam de controle over de productiesite over, je weet dat over het algemeen niet iedereen toegang tot de productie zal krijgen, Ops deelt gewoon de fout details of andere informatie die het team nodig heeft voor foutopsporing.

Maar deze situatie is nodig om toegang te geven aan een van de dev-teamleden, die toegewijd enkele uren heeft besteed aan het analyseren van het probleem live en onmiddellijk werk heeft geleverd en daarom werd het probleem snel opgelost.

Dit is het voorbeeld van de samenwerking waarbij het ontwikkelteam vrijwillig eigenaar was van het probleem en het ops-team hielp het op te lossen. Dit is een puur voorbeeld van samenwerking.

Evenzo, een ander voorbeeld, laat me dat schematisch laten zien, dat ik heb getekend. Een ander voorbeeld is dat de zaken behoorlijk goed werkten na de software-upgrade op een bepaalde site gedurende een paar dagen, en plotseling begonnen de prestaties van de applicatie te vertragen.

Eindgebruikers kregen te maken met ernstige transactieverliezen als gevolg van deze vertraging. Er kwamen veel klachtenoproepen naar CSR's, ik bedoel, vertegenwoordigers van de klantenservice en zij begonnen op hun beurt met het team over de kwestie te praten.

Op dit moment kwamen zowel het Dev- als het Ops-team onmiddellijk samen, en met de informatie en de telemetriegegevens die het Ops-team aan het dev-team had verstrekt, konden ze het probleem opsporen en vaststellen dat er een probleem was met het aspect loadsharing en vandaar dat de uitvoering traag was.

Dus beide teams werkten samen om het probleem op te lossen en binnen een paar uur weer normaal te maken. Dus hier kwamen zowel de Dev als de Ops samen naar voren en werkten ze samen om het probleem op te lossen in plaats van dat de Dev zijn Ops-probleem zei en Ops dacht dat het het probleem van Dev is en dat het ontwikkelteam het moet bekijken en oplossen.

Dit is het duidelijke voorbeeld van samenwerking waarbij iedereen de eigenaar is van de problemen, in plaats van het schuldspel te spelen, ongeacht wiens probleem het is of tijd te verspillen om uit te zoeken wiens probleem het is, rekening houdend met het feit dat de eindgebruiker lijdt en het probleem nodig heeft binnenkort worden opgelost.

Dus, nogmaals, het probleem hoeft niet alleen van de productie te zijn, het kan elk eenvoudig intern softwareontwikkelingsprobleem zijn, zo simpel als het dagelijkse probleem, of een ontwerpprobleem, of een architectuurprobleem, of zelfs een eenvoudig probleem. tool probleem.

Elk probleem met het programma of elk probleem waarvan het team weet dat het schade toebrengt aan de klant of het programma vertraagt, moet het eigendom zijn van iedereen, in plaats van het probleem te isoleren dat het een ontwikkelingsprobleem of operationeel probleem of testprobleem is, en bijdragen om het zo snel mogelijk aangepakt te krijgen, is een samenwerking.

Samenwerking in de DevOps-context betekent dus dat ontwikkeling en operaties samenkomen en samenwerken om het probleem zo vroeg mogelijk op te lossen, rekening houdend met de klantgerichtheid.

Samenwerking is zowel voor Dev als voor Ops het eigendom van wat er live gebeurt, waarbij monitoring en logging en prestatiecontrole bovenaan staan ​​om het probleem op te lossen dat vooral in de productie optreedt in het belang van de eindgebruiker.

OF simpelweg kan ik zeggen dat het hele team, dat constant samenwerkt om het probleem op te lossen om de programmadoelstellingen te bereiken, klantgerichtheid in gedachten de samenwerking is. Ik herhaal, voortdurend samenwerken om de problemen op te lossen om de programmadoelstellingen te bereiken, waarbij de klantgerichtheid in gedachten is samenwerking.

Dan rijst de vraag, hoe ontwikkelen we deze samenwerking en wanneer moeten we de samenwerking op gang brengen tussen het team dat mijlenver van elkaar zit ??

Het is duidelijk dat we weten dat zowel de Dev als de Ops niet samen kunnen worden gelokaliseerd. Ops-team moet dichter bij de werklocatie of datacenters zijn, en de ontwikkelaar moet dichter bij het softwareontwikkelingscentrum zijn. Dus, hoe bereiken we de constante samenwerking tussen beide teams ??

Allereerst is het initiëren van DevOps-samenwerking vanaf het begin van het project zeer essentieel voor de organisatie en het team. Het team dat ik hier bedoel, zijn de teamleden van het programma.

Het oefenen van een aantal van de volgende dingen zou helpen om de kloof tussen het team te overbruggen, de beperkingen van virtuele teams te overwinnen en de samenwerking tot stand te brengen.

Laten we dus eens kijken welke praktijken helpen bij het bereiken van de samenwerking.

Betrek Development bij alle relevante vergaderingen en discussies van het Operations-team en vice versa.

Dit brengt hen niet alleen samen, maar helpt ook bij het begrijpen van elk van hun werkgebieden, hun dagelijkse problemen en hoe hun werk elkaar beïnvloedt, en wat zijn de kritieke dingen die iedereen zou moeten regelen om de problemen later en brengt hen daarom dichter bij elkaar en initieert elke keer een comfortabele discussie onder elkaar.

Vóór de introductie van de DevOps-praktijk gaf het ontwikkelteam nooit iets om het leveren van de software aan Operations. Je weet dat ze vroeger onwetend waren of zich nooit druk maakten over zaken als infrastructuur, configuraties, serverconfiguraties, netwerkconfiguraties, het monitoren van live optredens enz.,

apps waarmee je YouTube-video's kunt downloaden

Vroeger dachten ze dat al deze activiteiten de verantwoordelijkheden waren van het Operations-team en het dev-team wist er nooit van. Eerder was de levering voor het ontwikkelteam bedoeld als levering aan het Operations-team alleen, maar met de DevOps-praktijk waren de leveringsmiddelen voor de productie en niet alleen voor de operaties.

Evenzo gaven ops nooit om de code die het ontwikkelteam produceerde. Elk probleem dat ze tegenkwamen tijdens de software-installatie, functionaliteits- of prestatieproblemen in de productie, schoven gewoon de cent door aan het ontwikkelingsteam en vroegen hen om het op te lossen en terug te geven.

Door elkaars werk te kennen en hun taak te begrijpen en elkaars probleem tijdens de cyclus te beheersen, kan het team de problemen snel oplossen.

Omdat ze weten waar het probleem is en wat er in het programma gebeurt en wat het probleem in de productie veroorzaakt, en ze het dus zonder veel moeite direct kunnen oplossen.

Samenwerking betekent dus dat het ontwikkelteam de infrastructuur en de configuratie moet begrijpen en het operationele team zich moet bekommeren om de code, kwaliteit, levering en tijdlijnen.

Inzicht in de onderlinge afhankelijkheid zal helpen om het werk te versnellen en op tijd af te leveren.

Net als tijdens de software-installatie is het operationele team afhankelijk van een ontwikkelingsteam om eventuele problemen met de installatie op te lossen. Evenzo hangt het ontwikkelingsteam tijdens het coderen af ​​van een groot aantal voorwaarden die live bestaan ​​voor het operationele team om tijdens het coderingsproces zorg te dragen.

Een ander Voorbeeld is het testteam afhankelijk van het operationele team om live voorbeeldgegevens van de productie te leveren voor testen. Omgevingsconfiguratiedetails die moeten worden ingesteld in de ontwikkelomgeving enz.

Dus beide teams moeten met elkaar samenwerken en de afhankelijkheid van elkaar begrijpen en de gegevens of informatie op tijd verstrekken zonder enige vertraging te veroorzaken door rekening te houden met de tijdzonefactor.

Behoud transparantie door de DevOps-praktijken zoals bronbeheer of versiebeheer toe te passen, waardoor het team alles over het programma begrijpt en misverstanden worden voorkomen.

Dit is dus in feite het handhaven van de transparantie binnen het team.

Teamleden hoeven niet afhankelijk te zijn van een persoon of een bepaald stuk informatie, bijvoorbeeld als iemand de configuratie wil weten die is ingesteld op een bepaald knooppunt in het cluster, zodat ze niet hoeven te wachten tot het operationele team wakker wordt en geef deze details aan hen, in plaats daarvan kunnen ze naar de tool voor versiebeheer gaan en deze informatie ophalen en hun taak zonder enige vertraging voltooien.

Van elkaar leren, vooral van de fout van de anderen, zijn de grootste kenmerken van samenwerking. Zodat ze deze fouten van iemand anders niet herhalen.

Ontwikkeling is dus leren van de operatie en operaties is leren van de ontwikkeling, of het nu gaat om een ​​nieuwe technologie, tool of om iets eenvoudiger en beter te doen. Waar ze allebei op dezelfde pagina staan ​​en dus met elkaar samenwerken door van elkaar te leren.

Operaties hadden altijd het gevoel dat het ontwikkelteam erg traag is en dat ze niet op tijd kunnen leveren, nu ze dagelijks met het ontwikkelingsteam communiceren, begrijpen ze wat de vertraging veroorzaakt, zij het minder duidelijkheid in de vereisten, ontwerpprobleem, coderingsprobleem of enig ander gereedschapsprobleem.

Zelfs zij doen mee en geven hun waardevolle suggesties om te verbeteren.

Bovendien introduceert DevOps in het geval van een probleem van de productie of van de ontwikkelsite een cultuur waarin het probleem eerst wordt opgelost in plaats van uit te zoeken wie of welk team dit probleem heeft geïntroduceerd. En dus probeert iedereen zich te concentreren op het oplossen van het probleem in plaats van tijd te verspillen door uit te zoeken wie het probleem heeft veroorzaakt.

Dus stop met de schuld te geven en elk probleem als zijn eigen probleem te beschouwen en naar voren te komen om ze samen op te lossen en het probleem te ondersteunen, elkaar ondersteunen tijdens hun problemen is weer een samenwerking.

Dus, ik kan zeggen, stop met het beschuldigen van spel, het geven van schuld aan gaming is opnieuw een kenmerk van samenwerking.

Wanneer iedereen gezamenlijk in dezelfde richting gaat denken, dezelfde mindset en werken aan dezelfde aspecten en praktijken is weer een samenwerking zoals telkens wanneer een nieuwe functie wordt ontwikkeld, iedereen denkt na over hoe dit te testen, hoe dit te implementeren, hoe dit te monitoren, is een samenwerking.

Het gemeenschappelijk denken binnen het team is dus weer een kenmerk van de samenwerking.

Laten we nu een pauze nemen en in onze volgende video weinig meer over samenwerking begrijpen.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^