Close

Znaczenie struktury zespołów w DevOps

Każdy zespół wymaga odmiennej struktury, zależnie od szerszego kontekstu firmy.

Shana Vu

Marketing produktów, DevOps


Przygotowując zespół programistyczny do wdrożenia DevOps, warto zrozumieć, że różne zespoły wymagają odmiennych struktur, w zależności od szerszego kontekstu firmy i jej chęci do zmiany.

Wzrost popularności zespołów DevOps


Czy w Twojej firmie jest zespół DevOps? Jest spora szansa, że tak. W naszej ankiecie dotyczącej trendów DevOps ustaliliśmy, że ponad dwie trzecie ankietowanych organizacji posiada zespół lub osobę, która w pewnym stopniu pełni funkcje „DevOps”.

W miarę jak model DevOps staje się coraz bardziej rozpowszechniony, często słyszymy, że zespoły programistyczne stają się teraz zespołami DevOps. Jednak samo dodanie nowych narzędzi lub nazwanie zespołu „DevOps” nie wystarczy, aby w pełni wykorzystać korzyści płynące z praktyk DevOps.

Bez dokładnego zrozumienia metodyki DevOps i sposobu jej prawidłowego wdrożenia transformacja DevOps zwykle ogranicza się do reorganizacji lub wprowadzenia najnowszych narzędzi. Prawidłowe wdrożenie DevOps pociąga za sobą zmianę kulturową, w ramach której zespoły zyskują nowe struktury, nowe zasady zarządzania i określone narzędzia technologiczne.

Typy struktur zespołów DevOps

Określenie struktury zespołu DevOps, jaka ma zostać wdrożona, zależy od wielu rzeczy, w tym od liczby produktów, nad którymi pracuje organizacja, przywództwa technicznego oraz od tego, czy zespoły programistyczne i operacyjne mają możliwość synchronizacji procesów.


Determining which DevOps team structure to implement depends on numerous things, including the number of products an organization works on, technical leadership, and if development and operations teams have the capability to align processes.

poznaj rozwiązanie

Narzędzia DevOps dla całego zespołu

materiały pokrewne

Dowiedz się więcej o zaletach DevOps

Ważne jest, aby zrozumieć, że nie każdy zespół ma te same cele lub będzie korzystać z tych samych praktyk i narzędzi. Nawet ukształtowanie składu zespołu nie powinno być ustandaryzowane. Każdy zespół wymaga odmiennej struktury, w zależności od szerszego kontekstu firmy i jej chęci do zmiany. W dwóch różnych firmach „zespół DevOps” może oznaczać coś zupełnie innego.

Aby czerpać korzyści z DevOps — takie jak szybszy czas wprowadzania na rynek, wyższa częstotliwość wdrażania, lepsza kultura zespołowa oraz zwiększona współpraca między zespołami i działami — ważne jest zrozumienie roli, jaką odgrywają poszczególne zespoły. Faktem jest jednak, że w wielu organizacjach funkcjonuje wiele nazw zespołów, a zespoły mają wiele ról (np. zespół infrastrukturalny zajmuje się zarówno wyborem, jak i utrzymaniem narzędzi). Ten brak spójności sprawia, że kierownictwu trudno jest zwizualizować pełny krajobraz organizacyjny i odpowiedzieć na ważne pytania takie jak: Czy dysponujemy odpowiednimi zespołami? Czy w pewnych obszarach są luki, których nie wypełnia żaden zespół? Czy zespoły wydają się mieć zapewnioną niezbędną równowagę między autonomią a wsparciem ze strony innych zespołów?

Doskonała praca ludzi z Team Topologies stanowi punkt wyjścia do tego, jak Atlassian postrzega różne zespoły DevOps. Należy pamiętać, że poniższe struktury zespołów przybierają różne formy w zależności od wielkości i dojrzałości firmy. Często najlepszym wyjściem jest połączenie więcej niż jednej struktury zespołu lub przekształcenie jednej struktury w inną.

Współpraca działów programistycznych i operacyjnych

Wiele osób postrzega DevOps jako po prostu bliską i spójną współpracę działów programistycznych i operacyjnych. Rzeczywiście jest to podstawa DevOps i jako taka ma wyraźne zalety, dotyczące m.in. możliwości szybszego i bardziej niezawodnego tworzenia, testowania i wysyłania oprogramowania przez zespoły programistyczne.

Kluczem do skuteczności takiej struktury zespołu jest to, aby programiści rozumieli, pod jaką presją znajdują się zespoły operacyjne, aby utrzymać czas pracy bez przestojów i zminimalizować konieczność rozwiązywania problemów. Równie ważne jest, aby zespoły operacyjne rozumiały dążenie zespołów programistycznych do skrócenia czasu wdrożenia i czasu wprowadzania na rynek.

Programowanie i operacje razem

Ta struktura zakłada, że działy programistyczne i operacyjne funkcjonują razem i działają w jednym zespole — tworząc zjednoczony front o wspólnych celach. Struktury te, nazywane czasami „NoOps”, są powszechne w firmach technologicznych oferujących jeden podstawowy produkt cyfrowy, takich jak Facebook czy Netflix. Rozwiązanie to może nawet przybrać formułę „programujesz — utrzymujesz”, gdzie te same osoby piszą i obsługują aplikacje.

DevOps/SRE

Ta struktura, spopularyzowana przez Google, działa w ten sposób, że zespół programistyczny przekazuje produkt do zespołu Site Reliability Engineering (SRE), który go utrzymuje. W tym modelu zespoły programistyczne przekazują zespołowi SRE dzienniki i inne artefakty, aby wykazać, że ich oprogramowanie spełnia odpowiednie standardy, aby mogło zostać objęte wsparciem SRE. Zespoły programistyczne i SRE współpracują nad kryteriami operacyjnymi, a zespoły SRE mogą zwrócić się do programistów o ulepszenie kodu przed wdrożeniem wersji produkcyjnej.

Operacje jako platforma

W tej strukturze zespół w zespole programistycznym pełni rolę źródła wiedzy dla wszystkich operacji i odpowiada za większość interakcji z zespołem ds. infrastruktury jako usługi (IaaS). Ta struktura zespołu bazuje na aplikacjach uruchamianych w chmurze publicznej, ponieważ zespół IaaS tworzy skalowalne, wirtualne usługi używane przez zespół programistyczny.

DevOps jako podmiot zewnętrzny

DevOps jako podmiot zewnętrzny to strukura, w której firmy korzystają z usług konsultanta DevOps lub zespołu DevOps przez ograniczony czas, aby pomóc zespołom programistycznym i operacyjnym przejść do dwóch pierwszych wymienionych struktur zespołu (współpraca działów programistycznych i operacyjnych oraz programowanie i operacje razem).

Istnieje wiele sposobów na wdrożenie DevOps, ale są też liczne metody, których należy unikać. Zespoły i liderzy DevOps powinni uważać na negatywne wzorce, które charakteryzują się silosami, brakiem komunikacji i niesłusznym przedkładaniem narzędzi nad komunikację.

Roles and responsibilities on DevOps teams


Niezależnie od struktury zespołu we wszystkich dobrze funkcjonujących zespołach wdrażających DevOps powinna zachodzić regularna wymiana wiedzy i doświadczenia między programistami i administratorami, zarówno w ramach regularnych spotkań, jak i współpracy osób w różnych zespołach, i/lub zatrudniania członków zespołów na obu funkcjach. Dobrze funkcjonujący zespół charakteryzuje się cechami, które są zaletami DevOps, takimi jak: szybszy czas wprowadzania na rynek, lepszy czas wdrażania, wyższa częstotliwość wdrażania, wyższa jakość wyników, lepsza kultura zespołowa oraz zwiększona współpraca między zespołami i działami.

W skład zespołów DevOps wchodzą zazwyczaj osoby posiadające umiejętności zarówno w zakresie programowania, jak i operacji. Niektórzy członkowie zespołu mogą być lepsi w pisaniu kodu, podczas gdy inni mogą mieć wyższe kwalifikacje, jeśli chodzi o obsługę i zarządzanie infrastrukturą. Jednak w dużych firmach każdy aspekt DevOps — począwszy od CI/CD, przez IaaS, aż po automatyzację — może być przypisany do konkretnego stanowiska. Możliwości zaczynają się od menedżera wydań, który koordynuje i zarządza aplikacjami od programowania po produkcję, a kończą na architektach automatyzacji, którzy utrzymują i automatyzują pipeline CI/CD zespołu.

A więc co trzeba zrobić, aby dołączyć do zespołu DevOps? Wymagania te ewoluują dzięki nowym technologiom i technikom, ale cechy dobrego zespołu DevOps są niezmienne. Solidne umiejętności techniczne, dobra komunikacja, umiejętność pracy w zespole i zdolność do adaptacji to jedne z podstawowych cech dobrego praktyka DevOps. Ich kombinacja jest prawdopodobnie ważniejsza niż encyklopedyczna znajomość Kubernetes czy Git. Ale nie zaszkodzi mieć wszystkie te atuty!

Kolejnym warunkiem sukcesu jest lider gotowy do szerzenia DevOps w zespole, współpracujących zespołach i całej organizacji. Nie musi być ktoś to o tytule „menadżera”; wystarczy każdy, komu zależy na przekonaniu sceptycznych członków zespołu do tego, by zacząć zmniejszać dystans między własnym zespołem a zespołem zewnętrznym, niezależnie od tego, czy są to programiści, administratorzy czy zespół platformowy.

Software to support your team


Chociaż o kształcie łańcucha narzędzi DevOps decyduje faktyczna praca wykonywana codziennie przez zespół, potrzebne będzie oprogramowanie, aby połączyć i koordynować pracę między zespołem a resztą organizacji. Jira to potężne narzędzie, które pozwala na planowanie, śledzenie i zarządzanie projektami tworzenia oprogramowania, przy jednoczesnym informowaniu kolegów z zespołu i całej organizacji na temat stanu prac.

Aplikacje takie jak Zoom, Slack i Microsoft Teams są także niezbędne, aby zespoły mogły szybko i sprawnie komunikować się ze sobą, zwłaszcza w warunkach pracy zdalnej. Dawniej programista mógł podejść do zespołu operacyjnego, aby zapytać o status incydentu. Teraz taką bezpośrednią wymianę informacji umożliwiają aplikacje do komunikacji wirtualnej.

Należy jednak pamiętać, że oprogramowanie, które pozwala zespołom pracować razem, jest środkiem, a nie celem. Jeśli organizacja chce wykorzystać pełny potencjał DevOps — dotyczący przejrzystości, zaufania i autonomii — potrzebuje zespołów, a nie tylko narzędzi.

Shana Vu
Shana Vu

Shana is a product marketer passionate about DevOps and what it means for teams of all shapes and sizes. She loves understanding the challenges software teams face, and building content solutions that help address those challenges. If she's not at work, she's likely wandering the aisles of her local Trader Joes, strolling around Golden Gate, or grabbing a beer with friends.


Udostępnij ten artykuł
Następny temat

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Warsztaty symulacyjne

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up