1. Zarządzanie BusinessOperations Jak tworzyć zespoły DevOps w swojej organizacji

Emily Freeman

DevOps nie ma idealnej struktury organizacyjnej. Jak wszystko w technice, „właściwa” odpowiedź na temat struktury firmy zależy od twojej wyjątkowej sytuacji: twojego obecnego zespołu, twoich planów rozwoju, wielkości zespołu, dostępnych umiejętności, twojego produktu i tak dalej.

Pierwszą misją powinno być dostosowanie wizji zespołu DevOps. Dopiero po usunięciu nisko wiszącego owocu oczywistego tarcia między ludźmi możesz zacząć przestawiać zespoły. Nawet wtedy pozwól na pewną elastyczność.

Jeśli podchodzisz do reorganizacji z otwartością i elastycznością, wysyłasz wiadomość, że chcesz słuchać i dajesz zespołowi autonomię - podstawową zasadę DevOps.

Być może masz już programistę Python lub Go, który jest pasjonatem i ciekawi zarządzania infrastrukturą i konfiguracją. Być może ta osoba może zmienić rolę w nowej organizacji na bardziej skoncentrowaną na operacjach. Postaw się w bucie tej osoby. Czy nie byłbyś lojalny wobec organizacji, która podjęła na Ciebie ryzyko? Czy nie byłbyś podekscytowany ciężką pracą? I to podniecenie jest zaraźliwe.

Tutaj dowiesz się, jak wyrównać zespoły, które już masz na miejscu, poświęcić zespół na praktyki DevOps i tworzyć zespoły wielofunkcyjne - wszystkie podejścia, z których możesz wybrać ukierunkowanie swoich zespołów na DevOps.

Możesz wybrać jedno podejście i pozwolić mu ewoluować stamtąd. Nie uważaj, że ta decyzja jest trwała i niemożliwa do poruszenia. DevOps koncentruje się na szybkiej iteracji i ciągłym doskonaleniu, i to jest główna zaleta tej metodologii. Ta filozofia dotyczy również zespołów.

Wyrównanie zespołów funkcjonalnych dla DevOps

Dzięki takiemu podejściu tworzysz silną współpracę między tradycyjnymi zespołami programistycznymi i operacyjnymi. Zespoły mają nadal funkcjonalny charakter - jeden koncentruje się na operacjach, a drugi na kodzie. Ale ich zachęty są dostosowane. Będą rosnąć, aby sobie nawzajem ufać i będą pracować, gdy dwa zespoły będą się łączyć.

Dla mniejszych organizacji inżynieryjnych dopasowanie zespołów funkcjonalnych jest dobrym wyborem. Nawet jako pierwszy krok to wyrównanie może wzmocnić pozytywne zmiany, których dokonałeś do tej pory. Zazwyczaj wyrównanie rozpoczyna się od poświęcenia czasu na zbudowanie relacji. Upewnij się, że każda osoba w obu zespołach nie tylko rozumie intelektualnie rolę i ograniczenia drugiego zespołu, ale także wczuwa się w punkty bólu.

W przypadku tego podejścia dobrym pomysłem jest promowanie polityki „Budujesz ją, wspierasz”. Ta zasada oznacza, że ​​wszyscy - zarówno programiści, jak i operatorzy - uczestniczą w rotacji na wezwanie.

Ten udział pozwala programistom zrozumieć frustrację związaną z dzwonieniem w środku nocy i zmaganiem się, podczas gdy mgliste oczy i brak kofeiny w celu usunięcia błędu, który wpływa na klientów. Ludzie z operacji zaczynają też ufać zaangażowaniu deweloperów w ich pracę. Nawet ta niewielka zmiana buduje niezwykłe zaufanie.

Uwaga: jeśli programiści ciężko walczą z dyżurami, w Twojej organizacji występuje większy problem. Odpowiedź ta nie jest niczym niezwykłym, ponieważ dyżury są bardzo różne od ich codziennych obowiązków. Odepchnięcie często pochodzi z miejsca dyskomfortu i strachu. Możesz pomóc złagodzić tę reakcję, zwracając uwagę na fakt, że Twoi programiści mogą nie wiedzieć, co zrobić za pierwszym razem, gdy są na dyżurze.

Mogą nie być zaznajomieni z infrastrukturą i jest w porządku. Zachęć ich do eskalacji incydentu i wezwania kogoś z większym doświadczeniem. Na koniec utwórz element Runbook ze wspólnymi alertami i działaniami, które należy podjąć. Zapewnienie tego zasobu pomoże uspokoić strach, dopóki nie zaczną się rozmyślać.

Inną taktyką, która pomaga pobudzić współpracę do stworzenia bardziej spójnego zespołu DevOps, jest wprowadzenie dnia shadowingu, w którym każdy zespół „handluje” kolegą. Handlowany po prostu rzuca cień na kogoś innego w zespole, siada przy biurku (lub w okolicy) i pomaga w codziennych obowiązkach. Mogą pomagać w pracy, omawiać problemy jako zespół (programowanie w parach) i dowiedzieć się więcej o systemie z innego punktu widzenia. Ten styl nauczania nie jest nakazowy.

Zamiast tego wzbudza ciekawość i buduje zaufanie. Koledzy powinni swobodnie zadawać pytania - nawet „głupie” - i swobodnie się uczyć. Nie ma żadnych oczekiwań dotyczących wydajności. Czas należy poświęcić na wzajemne poznanie się i docenienie pracy. Każda wydajność produkcyjna jest bonusem!

W tym podejściu do wyrównania oba zespoły muszą być absolutnie zaangażowane w procesy planowania, architektury i rozwoju. Muszą dzielić się obowiązkami i odpowiedzialnością przez cały cykl rozwojowy.

Dedykowanie zespołu DevOps

Dedykowany zespół DevOps jest bardziej ewolucją Administratora Sys niż prawdziwym zespołem DevOps. Jest to zespół operacyjny z mieszanką zestawów umiejętności. Być może niektórzy inżynierowie są zaznajomieni z zarządzaniem konfiguracją, inni IaC (infrastruktura jako kod), a być może inni są ekspertami w zakresie kontenerów lub infrastruktury natywnej w chmurze lub CI / CD (ciągła integracja i ciągłe dostarczanie / rozwój).

Jeśli uważasz, że umieszczenie grupy ludzi w oficjalnym zespole wystarczy, aby rozbić silosy, jesteś w błędzie. Ludzie są bardziej złożeni niż arkusze kalkulacyjne. Hierarchia nic nie znaczy, jeśli twoje silosy weszły w fazę, w której są niezdrowe i plemienne. W toksycznych kulturach może pojawić się styl przywództwa siłaczy, po którym prawie zawsze podążają ludzie. Jeśli widzisz to we własnym zespole, masz do zrobienia.

Chociaż każde podejście może działać w Twoim zespole, to podejście dedykowane zespołowi jest tym, które powinieneś przemyśleć najbardziej. Największą wadą oddanego zespołu DevOps jest to, że z łatwością staje się on kontynuacją tradycyjnych zespołów inżynieryjnych, nie uznając potrzeby wyrównywania zespołów, zmniejszania silosów i usuwania tarcia. Ryzyko związane z utrzymaniem tarcia (lub wytworzeniem większej ilości) jest wysokie w tym podejściu. Postępuj ostrożnie, aby upewnić się, że wybierasz tę organizację zespołu z konkretnego powodu.

Zaletą tego podejścia DevOps jest posiadanie dedykowanego zespołu zajmującego się poważnymi zmianami lub dostosowaniami infrastruktury. Jeśli masz problemy z operacjami, które spowalniają wdrażanie lub powodują problemy z niezawodnością witryny, może to być dobre podejście - nawet tymczasowe.

Dedykowany zespół, jeśli planujesz przenieść starszą aplikację do chmury. Ale zamiast nazywać ten zespół zespołem DevOps, możesz spróbować nazwać go zespołem ds. Automatyzacji.

Ta dedykowana grupa inżynierów może całkowicie skoncentrować się na zapewnieniu prawidłowej infrastruktury i narzędzi automatyzacji. Następnie możesz mieć pewność, że Twoja aplikacja wyląduje w chmurze bez większych zakłóceń. Takie podejście jest jednak tymczasowe. Jeśli utrzymujesz zespół zbyt długo w izolacji, ryzykujesz zejście po śliskim zboczu od szybkiego wzrostu do wbudowanego silosu.

Tworzenie wielofunkcyjnych zespołów produktowych dla DevOps

Zespół wielofunkcyjny to zespół skupiony wokół jednego produktu. Zamiast mieć oddzielne zespoły ds. Programowania, interfejsu użytkownika i doświadczenia użytkownika (UI / UX), zapewniania jakości (QA) i operacji, łączysz osoby z każdego z tych zespołów.

Zespół wielofunkcyjny działa najlepiej w średnich i dużych organizacjach. Potrzebujesz wystarczającej liczby programistów i pracowników do obsadzenia stanowisk każdego zespołu produktu. Każdy zespół wielofunkcyjny wygląda nieco inaczej.

Dobrze jest mieć co najmniej jedną osobę operacyjną na zespół. Nie proś osoby obsługującej o podział obowiązków między dwa zespoły. Ten scenariusz jest dla nich niesprawiedliwy i szybko spowoduje tarcie między dwoma zespołami produktów. Daj swoim inżynierom przywilej bycia w stanie skoncentrować się i zagłębić w swoją pracę.

Jeśli Twoja organizacja jest wciąż niewielka lub w fazie początkowej, możesz myśleć o całej organizacji inżynierskiej jako o zespole wielofunkcyjnym. Zachowaj mały i skupiony. Kiedy zaczniesz zbliżać się do 10–12 osób, zacznij myśleć o tym, jak możesz zreorganizować inżynierów.

Poniższy obraz pokazuje, jak mogłyby wyglądać Twoje zespoły wielofunkcyjne. Należy jednak pamiętać, że ich skład różni się w zależności od zespołu i organizacji. Niektóre produkty koncentrują się na projektowaniu, co oznacza, że ​​w każdym zespole może znajdować się wielu projektantów. Inne produkty to produkty techniczne przeznaczone dla inżynierów, którzy nie dbają o estetykę. Zespoły zajmujące się tego rodzaju produktem mogą mieć jednego projektanta - lub nie mieć go wcale.

Zespół produktowy DevOps

Jeśli Twoja organizacja jest wystarczająco duża, z pewnością możesz utworzyć wiele zespołów, używając różnych pomysłów i podejść DevOps. Pamiętaj, że Twoja organizacja jest wyjątkowa. Czuć się upoważnionym do podejmowania decyzji na podstawie bieżących okoliczności i dostosowywania się od tego momentu. Oto niektóre możliwe kombinacje różnych typów zespołów produktowych.

  • Starszy zespół produktu: Project Manager (PM), Front-end Developer, Back-end Developer, Back-end Developer, Site Reliability Engineer (SRE), Automation Engineer, QA Tester Zespół ds. Transformacji w chmurze: SRE, SRE, inżynier operacyjny, inżynier automatyki, programista back-end Zespół MVP: PM, projektant, inżynier UX, programista front-end, programista backend, inżynier operacyjny

Minusem zespołu ds. Produktów wielofunkcyjnych jest to, że inżynierowie tracą koleżeństwo inżynierów z tymi samymi umiejętnościami i pasjami. Ważnym aspektem satysfakcji z pracy jest posiadanie grupy podobnie myślących osób, z którymi możesz się spotkać i od której możesz się uczyć. Sprawdź rozwiązanie tego problemu poniżej.

Jak pokazano poniżej, możesz dać swoim inżynierom poświęcony czas na pracę z plemionami. Możesz zrobić coś tak hojnego, jak płacenie za lunch raz w tygodniu, aby mogli się spotkać i porozmawiać. Lub możesz zapewnić 10–20 procent czasu pracy, aby mogli oni pracować nad projektami jako plemię. Tak czy inaczej, potrzebujesz inżynierów, aby zachować ostrość.

Plemiona dzielą się wiedzą branżową, przekazują solidne informacje zwrotne i wspierają rozwój kariery. Zapewnij swoim inżynierom czas na naukę od ludzi, z którymi dzielą się wykształceniem, doświadczeniem i celami. Tym razem zapewnia bezpieczne miejsce, w którym mogą się zrelaksować i poczuć jak w domu.

Plemiona DevOps

Żadna ilość idealnego finansowania nie pokona niedociągnięć złej kultury organizacyjnej. Ale jeśli do tej pory zwróciłeś uwagę i poczyniłeś odpowiednie kroki, następnym krokiem jest utworzenie zespołów, które wzmacniają kulturowe ideały, które już wprowadziłeś.