Budowanie doskonałego zespołu DevOps: współpraca, kultura i kluczowe praktyki

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Skuteczny zespół DevOps potrzebuje czegoś więcej niż tylko narzędzi. Rozwija się dzięki kulturze współpracy, usprawnionym procesom i sprawczości programistów. W mojej rozmowie w formie pytań i odpowiedzi z Dylanem Etkinem, dyrektorem generalnym i współzałożycielem firmy Sleuth, omawiamy najważniejsze elementy budowania zespołu DevOps, który napędza transformację cyfrową.

Interview cover featuring Dylan Etkin discussing career success with DevOps teams Featured Image

DevOps wyłonił się jako kluczowa filozofia, która wypełnia lukę między tworzeniem oprogramowania a działaniami IT. Wykracza poza samo korzystanie z narzędzi DevOps. Skuteczny zespół DevOps nie tylko przyspiesza proces dostarczania, ale także zapewnia jakość i niezawodność. Jednak stworzenie takiego zespołu wymaga harmonijnego połączenia narzędzi, kultury, procesów, współpracy i wielu innych elementów. Jakie są kluczowe składniki doskonałego zespołu DevOps i jak organizacje mogą je zintegrować, aby osiągnąć optymalne rezultaty? W ramach tej serii mieliśmy przyjemność przeprowadzić wywiad z Dylanem Etkinem, współzałożycielem i dyrektorem generalnym firmy Sleuth.

Cześć, Dylan – czy możesz opowiedzieć nam o swojej dotychczasowej drodze? 

Swoją karierę rozpocząłem jako inżynier oprogramowania. Miałem szczęście dołączyć do małego startupu Atlassian jako jego dwudziesty pracownik. Spędziłem w Atlassian 10 lat, zdobywając ogromną wiedzę i obserwując rozwój organizacji z 20 do 1200 osób. Byłem jednym z pierwszych 3 inżynierów pracujących nad Jira, pierwszym architektem Jira oraz liderem zespołu inżynierskiego Bitbucket, rozwijając ten produkt z 40 tys. do 2 mln użytkowników. 

Odszedłem z Atlassian i dołączyłem do małego startupu Statuspage. Rok później Statuspage zostało przejęte przez Atlassian i znów znalazłem się na pokładzie macierzystej firmy. Po 3 latach kierowania tym zespołem w Atlassian postanowiłem rozpocząć działalność na własną rękę i założyłem Sleuth, aby przekształcić w produkt to, co zawsze było moją pasją: budowanie wydajnych zespołów inżynierskich.

Zawsze fascynowały mnie narzędzia dla programistów oraz pomaganie zespołom w efektywnej pracy i ciągłym doskonaleniu.

Komu przypisujesz zasługi za pomoc w osiągnięciu sukcesu?

Na swojej drodze otrzymałem pomoc od wielu osób. Im jestem starszy, tym bardziej zdaję sobie sprawę, jak wyjątkową sieć kontaktów udało mi się zbudować i jak chętnie wszyscy jej członkowie pomagają, gdy się ich o to poprosi.

Jedną z wyróżniających się osób jest John Kodumal, współzałożyciel i dyrektor techniczny LaunchDarkly. John i ja byliśmy na równorzędnych stanowiskach w Atlassian. Kiedy odszedł, aby założyć LaunchDarkly, zawsze otwarcie dzielił się swoimi doświadczeniami związanymi ze startupem.

Kiedy zacząłem motywować się do założenia Sleuth, wspierał mnie na każdym poziomie. Od wymiany pomysłów, przez otwarte rozmowy o tym, jak działać, aż po dołączenie do grona naszych pierwszych klientów — John zawsze pomagał mi na każdym etapie tej podróży. 

Czy możesz wskazać trzy mocne strony, umiejętności lub cechy, które pomogły ci dotrzeć do obecnego miejsca w karierze? Jak inni mogą aktywnie rozwijać te obszary?

  1. Wytrwałość. Umiejętności i inteligencja pozwolą ci zajść tylko do pewnego miejsca. Wielokrotne powracanie do problemu jest znacznie skuteczniejsze. Wytrwałość, nawet w obliczu wielu porażek, zdefiniowała mój sukces.
  2. Dbałość o szczegóły. To cecha, która zawsze przychodziła mi naturalnie. Jako inżynierowi pozwala mi ona skutecznie realizować stojące przede mną zadania. W środowisku startupowym ta umiejętność jest jeszcze ważniejsza. Prowadząc produkt od wizji do rzeczywistości, dbałość o szczegóły decyduje o tym, czy produkt będzie przeciętny, czy stanie się czymś, co użytkownicy pokochają.
  3. Delegowanie. Choć musisz w pełni odpowiadać za swoją firmę, startup bardzo szybko staje się ćwiczeniem polegającym na zatrudnianiu osób, które w wielu obszarach są mądrzejsze od ciebie, oraz na przekazywaniu im swoich „klocków”, aby mogły odnieść sukces i rozwijać firmę. 

Jakie umiejętności wciąż starasz się rozwijać?

Cały czas pracuję nad wieloma rzeczami — nigdy nie brakuje umiejętności, które można rozwijać. Obecnie szczególnie koncentruję się na sztuce wydobywania z ludzi tego, co najlepsze. Każdy jest inny, a stworzenie środowiska, w którym każda osoba może wykonywać swoją pracę najlepiej, jak potrafi, stanowi wyzwanie.

Porozmawiajmy o skutecznym zespole DevOps. Jakie kluczowe cele zespół DevOps może wyznaczyć sobie na drodze transformacji cyfrowej?

Zespoły DevOps mają uprawnienia i narzędzia, aby sprawnie przeprowadzać pracę od koncepcji do udanego wdrożenia na produkcji. Dlatego najważniejszym celem zespołu DevOps jest zbudowanie narzędzi, procesów i kultury, które pozwolą poszczególnym programistom szybko przeprowadzać pracę od koncepcji do udanego wdrożenia. 

Cele wspierające realizację najważniejszego celu to:

  • Możliwość definiowania pracy w małych partiach
  • W pełni zautomatyzowany potok CI/CD
  • Obserwowalność i środowiska przedprodukcyjne  pełniące funkcję zabezpieczenia, dzięki któremu programiści mogą z przekonaniem wdrażać zmiany na produkcji
  • Jasny proces postępowania w przypadku niepowodzenia zmian. Każdy wie, jak wykryć awarię i przywrócić system do działania
  • Poparcie ze strony reszty organizacji — kierowników projektu, marketingu, działu wsparcia, sprzedaży i kadry kierowniczej. Zespoły nie będą w stanie przeprowadzić transformacji DevOps bez wsparcia całej organizacji

Czy istnieją wyzwania lub typowe pułapki, które zespoły DevOps powinny brać pod uwagę?

Jest ich zbyt wiele, aby je wymienić. Jedną z wyróżniających się kwestii jest uświadomienie sobie, że praktykowanie DevOps oznacza przeniesienie większej odpowiedzialności na programistę. Nie dzieje się to bez kosztów i jeśli nie zainwestujesz w procesy oraz narzędzia, ryzykujesz zbudowanie systemu, który nie pozostawi programistom czasu na faktyczne wykonywanie pracy.

Ryzykujesz również stworzeniem środowiska, w którym programiści szybko się wypalą. Musisz pamiętać, że możliwości ludzi są ograniczone, dlatego należy uważnie rozważyć, jakie rozwiązania wdrażasz, aby wspierać programistów praktykujących DevOps.

W jaki sposób skuteczna współpraca i komunikacja między członkami zespołu mogą zwiększyć produktywność i przyczynić się do sukcesu zespołu DevOps oraz jakie praktyki mogą to ułatwić?

Komunikacja i współpraca są niezbędne do praktykowania DevOps. Do ważnych praktyk należą:

  • Korzystanie z systemu śledzenia zgłoszeń dla wszystkich prac oraz uwzględnianie tego kontekstu i informacji w commitach i przeglądach kodu
  • Przeglądy kodu z wykorzystaniem żądań ściągnięcia
  • Udostępnienie zespołowi rozwiązania do czatu w czasie rzeczywistym, takiego jak Slack
  • Powiadomienia o wdrożeniach przeznaczone dla całego zespołu w Slacku lub używanym przez zespół narzędziu ChatOps
  • Akceptowanie w Slacku zmian promowanych ze środowisk przedprodukcyjnych na produkcję
  • Indywidualne powiadomienia dla programistów, gdy ich zmiany zostaną wdrożone oraz gdy naruszą warunki niepowodzenia
  • Widoczność incydentów dla całego zespołu oraz okresów, w których należy wstrzymać wdrożenia
  • Prezentacje zespołu z udziałem kierowników produktu i innych interesariuszy
  • Codzienne spotkania synchronizacyjne

Jaką rolę odgrywa CI/CD w DevOps oraz jakie są najlepsze praktyki wdrażania potoków CI/CD, aby zapewnić płynny i niezawodny proces wydawania oprogramowania?

CI/CD jest prawdopodobnie najważniejszym elementem narzędziowym wspierającym zespół praktykujący DevOps. Idealnie byłoby, gdyby zespoły miały w pełni zautomatyzowany potok wdrożeniowy, który działa w rozsądnym czasie, dzięki czemu programiści nie muszą długo czekać i mogą przeprowadzać swoje zmiany aż do produkcji. Ważne jest, aby w ramach tego idealnego potoku uwzględnić CI i wykonywanie testów. Uruchamianie rozbudowanego zestawu testów dla zmian jako bramki przed wdrożeniem jest podstawowym zabezpieczeniem zapewniającym, że na produkcję trafią poprawne zmiany. 

Jeśli zespoły chcą wdrażać zmiany tylko raz w tygodniu, możliwe jest posiadanie potoku wdrożeniowego, który nie jest w pełni zautomatyzowany. Jeśli jednak zespół chce wdrażać zmiany co najmniej raz dziennie, pełna automatyzacja jest konieczna, a wdrożenie musi stać się zdarzeniem niezauważalnym.

W jaki sposób budowanie kultury i sposobu myślenia DevOps przyczynia się do ogólnego sukcesu zespołu DevOps oraz jakie strategie mogą stosować organizacje, aby promować tę kulturę wśród zespołów programistycznych i operacyjnych?

Dla programistów:

  • Cotygodniowe lub odbywające się co dwa tygodnie planowanie sprintu może pomóc określić wielkość zadań i wypracować w zespole porozumienie dotyczące tego, jak zadania zmieszczą się w tym przedziale czasowym
  • Zautomatyzowane CI dla gałęzi wydaniowej oraz widoczność wyników dla całego zespołu, aby pomóc mu utrzymać możliwość budowania wydania
  • Utrzymywanie w zespole roli „zakłóconej”, w przypadku której jasno określono, kto odpowiada za zapewnienie możliwości budowania gałęzi wydaniowej
  • Jednym z najlepszych mechanizmów umożliwiających dostarczanie nieukończonej pracy jest zastosowanie pewnej formy przełączników funkcji.
  • Skuteczne może być również wdrażanie każdego żądania ściągnięcia pojedynczo. Przyjęcie tego wzorca pozwala uwzględnić ocenę rozmiaru partii zmian podczas przeglądu kodu w ramach żądania ściągnięcia. Jeśli partia jest zbyt duża, inni członkowie zespołu mogą poprosić programistę o podzielenie zmiany na wiele żądań ściągnięcia.
  • Posiadanie wystarczającej liczby metryk i znajomość ich norm, aby móc zweryfikować wdrożenie
  • Rozumienie sposobu eskalowania problemów i wycofywania zmian w razie potrzeby
  • Posiadanie uprawnień do wdrażania własnych zmian we wszystkich utrzymywanych środowiskach oraz możliwość szybkiego wykonywania tego bez błędów

Dla kierowników produktu i projektantów:

  • Uwzględnienie kierownika produktu w procesie planowania, aby dać mu możliwość wyrażenia potrzeb klienta w ramach przyrostowych wdrożeń.
  • Wdrożenie przełączników funkcji, które pozwalają wdrożyć kod, ale nie udostępniać go jeszcze klientom. Pomaga to kierownikom produktu zachować potrzebną elastyczność, a jednocześnie pozwala programistom działać bez zwłoki.
  • Uzgodnienie mechanizmu przekazywania informacji zwrotnych i przeróbek, takiego jak zgłoszenie przypisane bezpośrednio do programisty. Jedną ze strategii rozwiązania problemu nieukończonej pracy jest przyjęcie przez zespół sześciotygodniowych cykli.

Dla menedżerów ds. inżynierii:

  • Wdrożenie procesów ułatwiających komunikację, takich jak cykliczne spotkania planistyczne, przeglądy kodu i cotygodniowe prezentacje.
  • Zobowiązanie do przeznaczania czasu zespołu inżynieryjnego na utrzymanie przechodzących kompilacji gałęzi wydaniowej. Utrzymywanie ciągłego przepływu kodu oznacza również inwestowanie w ten nowy system. Gdy zespół zidentyfikuje wąskie gardło, menedżer powinien umożliwić mu usunięcie tego problemu, np. naprawienie testów CI, których niestabilność przekracza 20%.
  • Wdrożenie narzędzi pomagających stale mierzyć metryki DORA

Dla kadry zarządzającej:

  • Przedstaw metryki Accelerate dotyczące swoich projektów i udostępnij je kadrze kierowniczej wraz z odpowiednim kontekstem.
  • Przedstaw czas dostępności swoich aplikacji lub jego odpowiednik.
  • Przekazuj zespołowi kierowniczemu te same ogólne informacje na temat dużych fragmentów funkcjonalności, które są wdrażane.
  • Jeśli jesteś członkiem kadry kierowniczej, pamiętaj, że zmiana wymaga czasu. Stanowczo wymagaj od swoich zespołów odpowiedzialności za realizację celów ogólnych, ale zachowaj elastyczność w kwestii sposobu ich osiągania. Ufaj, ale sprawdzaj.
  • Poświęć czas na wyjaśnienie swojej organizacji, w jaki sposób dostarczasz wartość klientom. Wyjaśnij, na czym polega dostarczanie przyrostowe, które elementy zostaną wydane jednocześnie w ramach dużego wdrożenia oraz w jaki sposób taki sposób pracy może pozwolić szybciej dostarczać wartość klientom.

Jakie są najważniejsze elementy skutecznego zespołu DevOps?

1 . Zespół współpracuje w kulturze nieobwiniania. 

Tworzenie oprogramowania to sport zespołowy. Incydenty i błędy są okazjami do nauki dla zespołów, a nie okazjami do obwiniania. Kultura nieobwiniania może wykraczać poza incydenty. Przy wyznaczaniu celów doskonalenia zespół może koncentrować się na poprawie rezultatów, zamiast obwiniać poszczególne osoby lub procesy za to, że sytuacja nie wygląda tak, jak powinna.

2 . Wdrożenia nie są wydarzeniami wymagającymi szczególnej uwagi.

Aby dostarczać małe przyrosty i szybko reagować na incydenty oraz opinie klientów, wdrożenie musi być łatwe i nie może wywoływać strachu ani niepokoju. Jeśli zespół nie ufa swoim wdrożeniom, trwają one zbyt długo lub obejmują ręczne czynności, będzie to prowadzić do obaw i wahania, co uniemożliwi zespołom wdrożenie DevOps.

3 . Programiści mają indywidualne uprawnienia do przeprowadzania zmian od koncepcji aż po niezawodne uruchomienie na produkcji. DevOps działa, gdy przenosisz odpowiedzialność za cały proces — od koncepcji do uruchomienia — w ręce programistów. Pozwala to zespołowi dzielić pracę na małe partie i szybko dostarczać klientowi wartość w małych przyrostach.

4 . Zespół ma mechanizmy zabezpieczające, takie jak obserwowalność i wskaźniki awarii, dzięki czemu może działać szybko i z pewnością siebie (to jedna z wielu zalet narzędzi do obserwowalności danych). Czasy podejścia „działaj szybko i psuj rzeczy” już minęły. Teraz trzeba działać szybko i niezawodnie. Aby to osiągnąć, musisz wdrożyć zautomatyzowane mechanizmy zabezpieczające.

5 . Cała organizacja popiera pracę w ramach przepływu DevOps.

Jakie pojawiające się trendy przewidujesz w obszarze DevOps, które w przyszłości mogą znacząco wpłynąć na strategie transformacji cyfrowej?

W tej chwili może się to wydawać oczywistą odpowiedzią, ale narzędzia AI już zmieniają sposób pracy programistów i z pewnością będą miały duży wpływ na praktykowanie DevOps w przyszłości. AI będzie co najmniej wykorzystywana do wykrywania i identyfikowania awarii w sposób, który nie jest dziś możliwy.

Jeśli spełni wszystkie swoje obietnice, całkowicie zastąpi skomplikowane potoki wdrażania i testowania, z których korzystamy obecnie.

Zapisz się do biuletynu The CTO Club, aby otrzymywać więcej informacji, podsumowań, sesji pytań i odpowiedzi oraz innych materiałów!

Katie Sanders
As a data-driven content strategist, editor, writer, and community steward, Katie helps technical leaders win at work. Her 15 years of experience in the tech space makes her well-rounded to provide technical audiences with first-hand operating wisdom so senior tech leaders can get clarity. Tech leaders want to learn from peers who’ve been there. Katie surfaces hard-won lessons that help leaders scale systems, teams, and strategy in the face of disruption. Katie is an Executive Editor at Black & White Zebra. She nurtures a large and diverse community of technical experts and writers, and she knows that a thriving community doesn't grow without thoughtfulness, advocacy, and intention. Interested in being reviewed? Find out more here.
Follow the author:

You may also like