Menu

Współpraca w DevOps

collaboration devops

Współpraca w DevOps:

Małe przyrosty dostaw w DevOps zostało szczegółowo wyjaśnione w naszym poprzednim samouczku.

Wiemy, że kluczową mantrą DevOps jest współpraca i stąd pojawiło się słowo DevOps.

Przeczytaj w całości => Szczegółowe samouczki DevOps

Współpraca polega na zjednoczeniu się jako jeden zespół w celu rozwiązania dowolnego problemu w programie, który utrudnia programowi skupienie się na kliencie i rozwiązywaniu go, uznając go za swój własny problem tak szybko, jak to możliwe, bez żadnej obwiniania.

przekonwertuj youtube na mp4 mac za darmo online

Współpraca w DevOps

Współpraca uczy wszystkich rozmawiać ze sobą, spotykać się twarzą w twarz, angażować się w spotkania, dyskusje, rozumieć swoje zadania, współzależność i przejrzystość w pracy oraz proaktywnie zapobiegać problemom.

WIDEO Część 2 Blok 5: Współpraca - 15 minut 36 sekund

Transkrypcja:

Termin „współpraca” jest wielokrotnie powtarzany w DevOps, a mantrą Devopsa jest współpraca. Zrozummy więc, co naprawdę oznacza „współpraca” w kontekście tworzenia oprogramowania i DevOps.

Według mnie, gdy tylko organizacja mówi, wdrażamy DevOps, automatycznie myślenie o współpracy, które jest związane z praktyką DevOps, pojawia się w głowach wszystkich i sprawia, że ​​są bardziej skoncentrowani i czujni na współpracę, a oni zaczynają czuć, że muszą współpracować . Na tym polega magia współpracy.

Dlatego inicjowanie współpracy DevOps od samego początku projektu jest bardzo istotne dla organizacji i zespołu. Mam na myśli zespół, członków zespołu programu.

Wyjaśnię kilka przypadków, w których widziałem Deva współpracującego z Ops, a Ops współpracującego z zespołem programistów, abyśmy wiedzieli, co właściwie oznacza współpraca w kontekście DevOps.

To jest reprezentacja pierwszej instancji.

Wystąpił przypadek, w którym wystąpił nieznany problem w skrypcie instalacyjnym lub skrypcie konfiguracyjnym, który zespół operacyjny napotkał wyzwanie podczas instalowania oprogramowania w określonej konfiguracji klastra w określonym obszarze geograficznym.

Rzucał jakiś nieznany błąd i był czystym problemem produkcyjnym, który nigdy nie wystąpił w środowisku deweloperskim, a zespół operacyjny naprawdę poświęcił wiele wysiłku, aby rozwiązać je samodzielnie, myśląc, że jest to coś związanego z konfiguracją i muszą rozwiązać to, co nie zostało rozwiązane przez dość długi czas.

Wtedy natychmiast do akcji wkroczył zespół deweloperski, nawet nie będąc zaproszonym do pomocy, chociaż strefa czasowa była inna, przejęła kontrolę nad zakładem produkcyjnym, wiesz, ogólnie rzecz biorąc, dostęp do produkcji nie będzie dostępny dla wszystkich, Ops po prostu podziela błąd szczegóły lub inne informacje potrzebne zespołowi do debugowania.

Ale ta sytuacja wymaga udzielenia dostępu jednemu z członków zespołu programistów, który poświęcił kilka godzin na analizę problemu na żywo i zapewnił natychmiastową pracę, dzięki czemu problem został szybko rozwiązany.

Jest to przypadek współpracy, w której zespół programistów dobrowolnie był właścicielem problemu i pomógł zespołowi operacyjnemu go rozwiązać. To czysty przykład współpracy.

Podobnie, pozwólcie, że pokażę to schematycznie, które narysowałem. Innym przykładem jest to, że po aktualizacji oprogramowania w określonej witrynie przez kilka dni wszystko działało całkiem nieźle, a nagle wydajność aplikacji zaczęła zwalniać.

jak pisać ręczne przypadki testowe

Użytkownicy końcowi zaczęli borykać się z poważnymi stratami transakcyjnymi z powodu tego spowolnienia. Zaczęło się pojawiać wiele telefonów ze skargami do przedstawicieli działu obsługi klienta, mam na myśli przedstawicieli obsługi klienta, a oni z kolei zaczęli kontaktować się z zespołem w tej sprawie.

W tym przypadku natychmiast połączyli się zarówno zespoły deweloperskie, jak i operacyjne, a dzięki informacjom i szczegółom telemetrycznym dostarczonym przez zespół Ops zespołowi programistów mogli zdebugować problem i stwierdzić, że wystąpił problem w aspekcie współdzielenia obciążenia i stąd występ był powolny.

Tak więc oba zespoły pracowały razem, aby rozwiązać problem i przywrócić normalne działanie w ciągu kilku godzin. Tak więc tutaj zarówno deweloper, jak i operatorzy razem wystąpili i podjęli współpracę w celu rozwiązania problemu, zamiast powiedzieć deweloperowi, że jego problem z operacjami i operatorzy myślą, że jest to problem dewelopera, a zespół programistów musi go sprawdzić i naprawić.

Jest to wyraźny przykład współpracy, w której każdy jest właścicielem problemów, zamiast grać w grę z obwinianiem, niezależnie od tego, czyja to sprawa, lub tracić czas na ustalenie, czyj to problem, pamiętając, że użytkownik końcowy cierpi i problem wymaga do naprawienia wkrótce.

Tak więc, ponownie tutaj, problem nie musi pochodzić tylko z produkcji, może to być dowolny prosty problem z wewnętrznym tworzeniem oprogramowania, tak prosty jak problem codzienny, problem projektowy, problem z architekturą, a nawet prosty problem z narzędziem.

Każdy problem związany z programem lub jakikolwiek problem, o którym zespół wie, że powoduje szkody dla klienta lub spowalnia program, musi należeć do wszystkich, zamiast izolować problem, że jest to problem programistyczny lub problem operacyjny lub problem z testowaniem, i przyczynić się do jak najszybszego rozwiązania tego problemu, to współpraca.

Tak więc współpraca w kontekście DevOps to połączenie rozwoju i operacji, aby jak najwcześniej rozwiązać problem, mając na uwadze klienta.

Współpraca to zarówno deweloper, jak i operatorzy, którzy są właścicielami tego, co dzieje się w czasie rzeczywistym, monitorowaniu i rejestrowaniu oraz sprawdzaniu wydajności, będąc na szczycie, aby rozwiązać problem, który występuje szczególnie w środowisku produkcyjnym w interesie użytkownika końcowego.

LUB po prostu mogę powiedzieć, że cały zespół, nieustannie pracujący razem nad rozwiązaniem problemu, aby osiągnąć cele programu, mając na uwadze skupienie się na kliencie, to współpraca. Powtarzam, nieustannie pracując razem, aby rozwiązać problemy, aby osiągnąć cele programu, mając na uwadze, że klient ma na uwadze współpracę.

Pojawia się wtedy pytanie, w jaki sposób rozwijamy tę współpracę i kiedy powinniśmy inicjować współpracę pomiędzy zespołem, który jest daleko od siebie?

Oczywiście wiemy, że zarówno deweloper, jak i operatorzy nie mogą znajdować się w tej samej lokalizacji. Zespół Ops musi znajdować się bliżej miejsca pracy lub centrów danych, a deweloper musi znajdować się bliżej centrum rozwoju oprogramowania. Jak więc osiągnąć stałą współpracę między oboma zespołami?

Przede wszystkim rozpoczęcie współpracy DevOps od samego początku projektu jest bardzo istotne dla organizacji i zespołu. Zespół, o którym mówię, to członkowie zespołu programu.

Przećwiczenie kilku z poniższych rzeczy pomogłoby w wypełnieniu luki między zespołem i pokonaniu ograniczeń związanych z wirtualnymi zespołami, a także pomoże w osiągnięciu współpracy.

Zobaczmy więc, które praktyki pomagają w nawiązaniu współpracy.

Zaangażuj rozwój we wszystkie stosowne spotkania i dyskusje zespołu operacyjnego i odwrotnie.

To nie tylko łączy ich, ale także pomaga w zrozumieniu każdego z ich obszaru pracy, ich codziennych problemów i tego, jak ich praca wpływa na siebie nawzajem, a także jakie są najważniejsze rzeczy, którymi każdy powinien się zająć, aby później uniknąć problemów i dlatego zbliża ich do siebie i za każdym razem inicjuje między sobą wygodną dyskusję.

Przed wprowadzeniem praktyki DevOps zespół deweloperów nigdy nie przejmował się dostarczaniem oprogramowania do operacji. Wiesz, że kiedyś byli ignorantami lub nigdy nie zawracali sobie głowy takimi rzeczami, jak infrastruktura, konfiguracje, ustawienia serwerów, konfiguracje sieci, monitorowanie występów na żywo itp.,

Kiedyś myśleli, że wszystkie te czynności są obowiązkiem zespołu operacyjnego, a zespół programistów nigdy o tym nie wiedział. Wcześniej dostawa dla zespołu programistów miała być dostarczana wyłącznie do zespołu operacyjnego, ale z praktyką DevOps dostarczanie środków do produkcji, a nie tylko do operacji.

Podobnie, operatorzy nigdy nie przejmowali się kodem, który tworzył zespół programistów. Każdy problem, z jakim napotykają podczas instalacji oprogramowania, problemy z funkcjonalnością lub wydajnością w produkcji, po prostu przekazywali pieniądze zespołowi programistów i prosząc ich o naprawienie i oddanie.

Tak więc wzajemna znajomość pracy i zrozumienie ich zadań oraz posiadanie wzajemnych problemów przez cały cykl pomaga zespołowi szybko rozwiązać problemy.

Ponieważ wiedzą, gdzie jest problem i co się dzieje w programie i co powoduje problem w produkcji, dzięki czemu mogą bezpośrednio go naprawić bez większych trudności.

Tak więc współpraca oznacza, że ​​zespół programistów musi zrozumieć infrastrukturę i konfigurację, a zespół operacyjny musi zajmować się kodem, jakością, dostarczaniem i terminami.

Zrozumienie zależności od siebie pomoże przyspieszyć pracę i dostarczyć ją na czas.

Podobnie jak podczas instalacji oprogramowania, zespół operacyjny jest zależny od zespołu programistów, który rozwiązuje wszelkie problemy związane z instalacją. Podobnie, podczas kodowania zespół programistów zależy od wielu warunków wstępnych, które zespół operacyjny musi spełnić podczas procesu kodowania.

Inne Przykład Czy zespół testowy jest zależny od zespołu operacyjnego, który dostarcza próbki danych na żywo z produkcji do testów. Szczegóły konfiguracji środowiska do skonfigurowania w środowisku programistycznym itp.

Tak więc oba zespoły muszą ze sobą współpracować i zrozumieć wzajemne zależności oraz dostarczać dane lub informacje na czas bez powodowania jakichkolwiek opóźnień, mając na uwadze czynnik strefy czasowej.

Zachowaj przejrzystość, stosując praktyki DevOps, takie jak kontrola źródła lub kontrola wersji, które umożliwiają zespołowi zrozumienie wszystkiego na temat programu i pomaga uniknąć wszelkich nieporozumień.

obsługuje pytania i odpowiedzi na rozmowę kwalifikacyjną

Jest to więc zasadniczo zachowanie przejrzystości w zespole.

Członkowie zespołu nie muszą polegać na żadnej osobie ani na jakiejś konkretnej informacji, powiedzmy, czy ktoś chce znać konfigurację skonfigurowaną w konkretnym węźle w klastrze, więc nie muszą czekać, aż zespół operacyjny się obudzi i podać im te szczegóły, zamiast tego mogą przejść do narzędzia kontroli wersji i pobrać te informacje i bezzwłocznie wykonać swoje zadanie.

Uczenie się od siebie nawzajem, zwłaszcza na błędach innych, jest największą cechą współpracy. Aby nie powtarzali błędów popełnionych już przez kogoś innego.

Tak więc rozwój to uczenie się na podstawie operacji, a operacje uczą się na podstawie rozwoju, niezależnie od tego, czy jest to nowa technologia, narzędzie, czy robienie czegoś w prostszy i lepszy sposób. Gdzie obaj są na tej samej stronie i dlatego współpracują ze sobą, ucząc się od siebie.

Operatorzy zawsze uważali, że zespół programistów jest bardzo powolny i nie może dostarczać na czas, teraz, gdy codziennie kontaktują się z zespołem programistów, rozumieją, co powoduje opóźnienie, czy to mniej jasności w wymagania, problem projektowy, problem z kodowaniem lub jakikolwiek inny problem z narzędziem.

Nawet oni angażują się i dostarczają cennych sugestii, które mogą poprawić.

Ponadto, w przypadku jakiegokolwiek problemu z produkcji lub z witryny deweloperskiej, DevOps wprowadza kulturę pierwszego rozwiązania problemu, a nie próby ustalenia, kto lub który zespół wprowadził ten problem. Dlatego wszyscy starają się skupić na rozwiązaniu problemu, zamiast tracić czas na ustalanie, kto spowodował problem.

Więc przestańcie obwiniać i uważać każdy problem za swój własny i wychodzić do przodu, aby rozwiązać go razem i wspierać problem, wspieranie się nawzajem w ich problemach to znowu współpraca.

Mogę więc powiedzieć, przestań obwiniać grę, obwinianie gier jest ponownie charakterystyczną cechą współpracy.

Kiedy wszyscy zaczynają myśleć w tym samym kierunku, z tym samym nastawieniem i pracując nad tymi samymi aspektami i praktykami, to znowu współpraca, tak jak za każdym razem, gdy opracowywana jest nowa funkcja, każdy myśli o tym, jak to przetestować, jak to wdrożyć, jak to monitorować, to współpraca.

Tak więc wspólne myślenie w zespole jest ponownie cechą charakterystyczną współpracy.

Zróbmy sobie teraz przerwę i zrozummy trochę więcej o współpracy w naszym następnym filmie.

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^