Close

Czym jest kultura DevOps?

Jak kultura DevOps pomaga w większym ukierunkowaniu ludzi, procesów i narzędzi na klientów.

Portret Toma Halla
Tom Hall

Specjalista i praktyk DevOps


Współpraca

DevOps to podejście do zmian organizacyjnych zgodne z metodyką Agile, którego zadaniem jest przezwyciężenie tradycyjnych podziałów między zespołami i ustanowienie nowych procesów, które ułatwiają współpracę. Choć narzędzia i praktyki Agile są niezbędnym elementem DevOps, nie są one wystarczające, aby czerpać pełne korzyści płynące z DevOps. Bez właściwego myślenia, rytuałów i kultury trudno jest wykorzystał pełny potencjał DevOps.

Ludzie i kultura to najważniejsze czynniki dla pomyślnego wdrożenia implementacji DevOps.
- Ankieta nt. trendów dotyczących DevOps Atlassian 2020

Czym jest kultura DevOps?


W swej istocie kultura DevOps wymaga ściślejszej współpracy i wspólnej odpowiedzialności za produkty, które tworzą i utrzymują programiści i pracownicy operacyjni. Pomaga ona w większym ukierunkowaniu ludzi, procesów i narzędzi na klientów.

Polega ona na tym, że multidyscyplinarne zespoły biorą odpowiedzialność za cały cykl życia produktu. Zespoły DevOps pracują autonomicznie i stosują kulturę, przepływy pracy i zestaw narzędzi programistycznych, które podnoszą znaczenie wymagań operacyjnych do tego samego poziomu co w przypadku architektury, projektowania i programowania. Koncepcja, zgodnie z którą programiści tworzący produkt również go obsługują, zbliża programistów do użytkownika dzięki lepszemu zrozumieniu wymagań i potrzeb użytkowników. Dzięki większemu zaangażowaniu zespołów operacyjnych w proces programowania mogą one dodawać wymagania dotyczące konserwacji i potrzeby klientów w celu uzyskania lepszego produktu.

Centralnym założeniem kultury DevOps jest zwiększona przejrzystość, komunikacja i współpraca między zespołami, które zwyczajowo pracowały w „silosach”. Istnieją jednak także pewne zmiany kulturowe, które są niezbędne, aby zbliżyć te zespoły do siebie. DevOps to zmiana kultury organizacyjnej, która kładzie nacisk na ciągłe uczenie się i doskonalenie, zwłaszcza poprzez autonomię zespołów, szybkie informacje zwrotne, wysoką empatię i zaufanie oraz współpracę między zespołami.

Logo Mindful thinking
materiały pokrewne

Nastaw się na potrzeby klienta

Logo Trophy
materiały pokrewne

Dowiedz się więcej o zaletach DevOps

DevOps oznacza wspólne obowiązki. Programiści i pracownicy operacyjni powinni dzielić się odpowiedzialnością za sukces lub porażkę produktu. Programiści nie mają ograniczać się do tworzenia kodu i przekazywania produktu zespołowi operacyjnemu — oczekuje się, że będą dzielić się odpowiedzialnością za nadzorowanie produktu przez cały okres jego życia, stosując podejście „odpowiadasz za to, co tworzysz”. Do ich obowiązków należy testowanie i obsługa oprogramowania oraz współpraca z działem kontroli jakości i operacyjnym. Jeśli rozumieją wyzwania stojące przed działem operacyjnym, są bardziej skłonni do upraszczania wdrażania i konserwacji. I analogicznie, jeśli pracownicy operacyjni rozumieją cele biznesowe systemu, mogą współpracować z programistami w celu określenia potrzeb operacyjnych i stosowania narzędzi do automatyzacji.

Autonomiczne zespoły to kolejny ważny aspekt DevOps. Aby zespoły programistyczne i operacyjne mogły skutecznie współpracować ze sobą, muszą podejmować decyzje i wdrażać zmiany bez uciążliwego i długiego procesu zatwierdzania. Polega to na budowaniu zaufania wobec innych zespołów i tworzeniu środowiska, w którym pracownicy nie obawiają się popełnienia błędu. Zespoły te powinny dysponować odpowiednimi procesami i narzędziami, aby podejmować decyzje szybciej i łatwiej, dla każdego poziomu ryzyka dla klienta.

Na przykład typowy przepływ prac programistycznych może wymagać zaangażowania kilku współpracowników w różnych zespołach w celu wdrożenia zmian kodu. Programista dokonuje zmiany w kodzie i przekazuje go do repozytorium kontroli źródła, inżynier ds. kompilacji tworzy i wdraża kod w środowisku testowym, właściciel produktu aktualizuje stan pracy w narzędziu do śledzenia zgłoszeń itd. Autonomiczny zespół skorzysta z narzędzi automatyzujących te procesy, tak aby przekazywanie nowego kodu uruchamiało tworzenie i wdrażanie nowej funkcji w środowisku testowym, a narzędzie do śledzenia zgłoszeń było aktualizowane automatycznie.

Na przykład przeszkodą dla pracy zespołu mogą być wymagania, takie jak otwarcie zgłoszenia w osobnym zespole operacyjnym w celu wprowadzenia banalnej zmiany w infrastrukturze, takiej jak nowy wpis DNS. Zadanie, które powinno zająć kilka sekund, trwa wiele dni lub tygodni. Autonomiczny zespół ma możliwość samodzielnego wdrożenia takich zmian, czy to dzięki temu, że w zespole jest osoba, która ma odpowiednie umiejętności i doświadczenie, czy też dzięki posiadaniu dostępu do narzędzi samoobsługi.

Kultura zespołu DevOps zyskuje na szybkich informacjach zwrotnych, które mogą pomóc w ciągłym doskonaleniu zjednoczonego zespołu programistyczno-operacyjnego. W środowisku, w którym zespoły programistyczne i operacyjne znajdują się w izolowanych „silosach”, informacje zwrotne dotyczące wydajności i stabilności oprogramowania w produkcji często potrzebują dużo czasu, zanim dotrą do zespołu programistycznego, a często w ogóle do niego nie docierają. Dzięki DevOps programiści otrzymują szybkie informacje zwrotne, których potrzebują do szybkiej iteracji i ulepszania kodu aplikacji, co wymaga współpracy między pracownikami operacyjnymi przy projektowaniu i wdrażaniu strategii monitorowania aplikacji i raportowania. Na przykład każde wystarczająco funkcjonalne narzędzie do ciągłej integracji umożliwia zautomatyzowane tworzenie i testowanie nowych partii kodu i dostarcza programistom natychmiastowych informacji zwrotnych na temat jakości ich kodu.

Automatyzacja jest niezbędnym elementem kultury DevOps, ponieważ umożliwia płynną współpracę i zwolnienie zasobów. Automatyzacja i integracja procesów zachodzących między zespołami programistów a zespołami IT, dzięki czemu mogą oni kompilować, testować i wydawać oprogramowanie w sposób szybszy i bardziej niezawodny.

Jakie są zalety kultury DevOps?


Najbardziej oczywistą i znaczącą zaletą kultury DevOps są lepsze, częste i wysokiej jakości wydania oprogramowania. Oznaczają one zarówno większą wydajność firmy, jak i zadowolenie pracowników.

Jak można przeczytać w publikacji „Accelerate: Building and Scaling High Performing Technology Organizations”, kultura DevOps sprzyja wysokiemu poziomowi zaufania i współpracy, skutkuje podejmowaniem decyzji o wyższej jakości, a nawet wyższym poziomem satysfakcji z pracy.

Wdrożenie kultury DevOps jest kluczem do budowy wysokowydajnej organizacji inżynierskiej bez narażania na szwank zadowolenia pracowników. To rozwiązanie korzystne dla wszystkich zainteresowanych. Dla inżyniera nie ma nic lepszego niż uczucie związane z możliwością częstego i łatwego wdrażania i uruchamiania stabilnego, wydajnego oprogramowania, które sprawia, że jego użytkownicy są zadowoleni, podczas gdy szefów firmy niewątpliwie ucieszą lepsze wyniki biznesowe.

Jakie wyzwania się z tym wiążą?


Pełne wdrożenie kultury DevOps zwykle wymaga od pracowników i zespołów wprowadzenia znaczących zmian w sposobie działania i dlatego oznacza konieczność przekonania kierownictwa najwyższego szczebla.

Wysiłek oddolny może być, i często jest, ważnym punktem wyjścia do uzyskania poparcia na poziomie kadry kierowniczej dla transformacji DevOps. Często najbardziej przekonującym argumentem przemawiającym za szerszym wdrożeniem DevOps jest zastosowanie go w odniesieniu do kilku osób lub małych zespołów, które zaczną odnosić sukcesy.

Wysoki poziom autonomii i zaufania, które są typowe dla kultury DevOps, może być trudny do utrzymania, jeśli istnieje konflikt między dowolną z zaangażowanych osób lub zespołów. Im bardziej rozbudowane były zespoły przed podjęciem próby wdrożenia DevOps, tym trudniej będzie budować współpracę.

Zmiana jest trudna. Nawet w środowiskach, w których istnieje wysoki poziom harmonii między osobami i zespołami, jeśli korzyści płynące ze zmian nie są wyraźnie wyartykułowane i zrozumiałe, to zwiększanie akceptacji i gotowości do wdrożenia może sprawiać trudności.

Zrozumiałe jest, że organizacje o silnym nastawieniu technicznym często natychmiast sięgają po narzędzia i technologie, aby rozwiązywać wyzwania biznesowe. Faktycznie, istnieją narzędzia i technologie, które mogą pomóc Twojej organizacji przejść do DevOps, jednak zmiana narzędzi i technologii bez zmiany kultury oznacza tylko podmienienie fasady bez rozwiązania problemu słabości fundamentów i jako taka bywa nazywana „kultem cargo DevOps”.

Kwestie do uwzględnienia podczas przejścia na kulturę DevOps


Otwarta komunikacja

Jednym z najbardziej podstawowych wyzwań, na jakie ma odpowiadać DevOps, jest odseparowanie wiedzy, doświadczenia i pracy w różnych jednostkach organizacyjnych. Gdy programiści, którzy piszą kod, i administratorzy systemów, którzy go wdrażają i utrzymują, nie komunikują się ze sobą, prawdopodobnym skutkiem jest brak efektywności.

Zdolność do popełniania błędów

Wiele organizacji, zespołów i osób wywiera niezwykłą presję na siebie samych i siebie nawzajem, aby za wszelką cenę nie popełniać błędów. Jeśli błąd nie wchodzi w grę, pracownik lub zespół raczej nie podejmie próby zastosowania nowatorskiego podejścia do rozwiązania problemu lub opracowania innowacyjnych funkcji.

Ten sposób myślenia znajduje odzwierciedlenie w dawnej obsesji dotyczącej mierzenia „średniego czas między awariami” (MTBF) oraz „średniego czasu odzyskania” (MTTR). MTBF używa narzędzi, takich jak „analiza głównej przyczyny”, aby zidentyfikować źródło awarii i próbować zapobiec ich ponownemu wystąpieniu. MTTR odzwierciedla spojrzenie na aplikacje jako złożone systemy, które są w stanie zawieść w nieprzewidywalny sposób, i gdy do tego dojdzie, koncentruje się na szybkim odzyskiwaniu.

„Retrospektywność bez dociekania winy” jest powszechną cechą kultury DevOps. Wyniki można poprawić, gdy zespół spotyka się na zakończenie sprintu lub projektu, aby omówić, co poszło dobrze i co można poprawić, w otwartym i bezpiecznym otoczeniu.

Spoglądanie na błędy bez dociekania winy jest tak skuteczne między innymi dlatego, że pozwala przyznać, iż błędy się zdarzają, a jednocześnie zarówno ludzie, jak i organizacje są zdolne do uczenia się, wzrostu i poprawy.
- „Effective DevOps”, Jennifer Davis i Katherine Daniels

Nowy zestaw procesów

Rozwijanie kultury DevOps wymaga wypracowania nowego podejścia do starych problemów. DevOps pociąga za sobą zmianę procesu polegającego na tym, że programiści pisząc kod aplikacji i „przerzucają go przez mur” do zespołu operacyjnego, który wdraża i obsługuje aplikację. Podejście DevOps oznacza współpracę programistów i pracowników operacyjnych przez cały cykl życia projektu.

Ciągła integracja i ciągłe dostarczanie (CI/CD) są powszechnie uważane za niezbędne elementy kultury DevOps. Trzeci proces, ciągłe wdrażanie, jest stosowany i propagowany przez tak duże organizacje, jak Netflix, ale nie powszechny (ani wymagany) w większości mniejszych firm. Dzieje się tak dlatego, że ciągłe wdrażanie nowych funkcji w środowisku produkcyjnym wymaga dużej pewności, że nowy kod został dokładnie przetestowany i można go bezpiecznie wdrożyć (np. pod przełącznikiem funkcji). Tak więc, o ile organizacja nie wdraża wiele razy dziennie, inwestowanie w procesy wspierające to podejście może nie być warte wysiłku.

W większości przypadków wykorzystanie jakieś formy „tworzenia oprogramowania opartego o gałąź główną” znacznie upraszcza działania związane z CI/CD. W tym modelu zespół zadowala się długotrwałymi gałęziami funkcji i wykonuje częste commity do gałęzi głównej kodu.

Ważnym komponentem tworzenia oprogramowania opartego o gałąź główną są kompleksowe zautomatyzowane testy: jednostka, integracja i regresja. Pomaga to zadbać o to, by wszystkie nowe commity do gałęzi głównej zostały dokładnie sprawdzone po przeniesieniu do repozytorium.

Ciągła integracja to praktyka automatyzacji integracji tworzonych przez różne osoby zmian kodu w projekcie tworzenia oprogramowania. Wykracza ona poza zespoły programistyczne i obejmuje resztę organizacji. Na przykład zespoły produktowe koordynują, kiedy sekwencyjnie uruchamiać funkcje i poprawki oraz którzy członkowie zespołu będą za nie odpowiedzialni.

Ciągłe dostarczanie jest metodologią organizacyjną, która łączy zespoły inżynieryjne i inne, takie jak zespoły projektowe, produktowe i marketingowe, w celu dostarczenia produktu. Środowiska niestosujące modelu CD zachęcają do „przerzucania produktu przez mur”, co polega na tym, że programiści przerzucają odpowiedzialność za wrażenia użytkownika na zespół QA. Oznacza to, że gałąź główna repozytorium jest przez cały czas w stanie „nadającym się do wdrożenia”.

Ciągłe wdrażanie umożliwia automatyczne wdrożenie zmian kodu w produkcji po ich wprowadzeniu, czy to ukrytych za flagą funkcji, wdrożonych u niewielkiego odsetka klientów i/lub łatwo wycofywanych. Zapewnia to zespołom większą elastyczność reagowania na zmieniające się uwarunkowania rynkowe i wymagania klientów, ponieważ mogą one reagować na opinie klientów oraz szybko wdrożyć i sprawdzać poprawność nowych funkcji. Mogą też łatwo wycofywać funkcje, dzięki czemu mniejszym problemem jest zepsucie kompilacji.

Flaga funkcji, przełącznik funkcji lub ciemne wdrożenie to typowe sposoby pozwalające zadbać o to, aby nowe funkcje aplikacji nie były widoczne ani nie działały po wdrożeniu w środowisku produkcyjnym, ale aby można je było włączyć przy minimalnym wysiłku. Strategia ta umożliwia ciągłe wdrażanie, ponieważ wiąże się z bardzo małym ryzykiem negatywnego wpływu na użytkowników. Powszechne jest również ograniczenie funkcji do podzbioru bazy użytkowników poprzez podzielenie ich według lokalizacji geograficznej lub uruchomienie oddzielnych instancji serwera i wydanie funkcji tylko na jednym serwerze, który jest dostępny dla użytkowników.

Zaktualizowany łańcuch narzędzi

Większość zespołów programistycznych korzysta z jakiegoś rodzaju narzędzi do kontroli wersji, śledzenia zgłoszeń i monitorowania aplikacji. Wszystkie one są ważnymi narzędziami wspierającymi kulturę DevOps, ale być może najważniejszym dodatkiem do tradycyjnego zestawu narzędzi jest oprogramowanie wspierające CI/CD. Dzięki zautomatyzowanemu przepływowi pracy, który wymaga zatwierdzenia, testowania i wdrażania, jest to naprawdę jedyny sposób na uzyskanie szybkich informacji zwrotnych wymaganych przez kulturę DevOps.

DevOps — zmiana kulturowa, która przynosi efekty


Programiści od dziesięcioleci dążą do dostarczania oprogramowania częściej, przy mniejszym wysiłku i ograniczonej liczbie błędów. Teraz wreszcie powstały narzędzia i praktyki, które to umożliwiają.

Według wyników badania Atlassian organizacje praktykujące DevOps twierdzą, że dostarczają produkty o wyższej jakości (61%), ze zwiększoną częstotliwością wdrażania i szybszym czasem wprowadzania na rynek (49%). Korzyści odnoszą zresztą nie tylko organizacje — praktycy deklarują, że nauczyli się nowych umiejętności (78%) lub otrzymali podwyżkę (48%).

Rozwijanie kultury DevOps nie jest proste, ale nagroda w postaci w zwiększonej satysfakcji programistów, menedżerów i klientów jest warta wysiłku.

Chcesz ulepszyć kulturę DevOps? Zacznij od monitorowania wydajności zespołu pomocy technicznej. Ponadto możesz ćwiczyć komunikowanie się, współpracę i burze mózgów ze współpracownikami dzięki 4 najlepszym grom do tworzenia kultury DevOps.

Tom Hall
Tom Hall

Tom Hall jest zwolennikiem i praktykiem DevOps, zagorzałym czytelnikiem i pianistą amatorem.
Na przestrzeni ostatnich 20 lat zdobył certyfikaty firm Novell, EMC, VMware i AWS. Pomagał w organizacji DevOpsDays w Atlancie w 2016 roku oraz w Austin w stanie Teksas w późniejszych latach.


Udostępnij ten artykuł

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