Close

Model CALMS

Oceń swoje umiejętności i mierz postępy w zakresie wdrażania DevOps.

Ian Buchanan

Główny inżynier ds. rozwiązań


CALMS to model oceny zdolności firmy do wdrażania procesów DevOps, a także sposób pomiaru postępów w transformacji DevOps. Akronim ten został ukuty przez Jeza Humble'a, współautora publikacji „DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji”, i oznacza Culture, Automation, Lean, Measurement oraz Sharing.

Kultura

DevOps to nie tylko proces czy inne podejście do programowania — to zmiana kultury. Podstawowym elementem kultury DevOps jest współpraca.

Żadna liczba narzędzi i automatyzacji nie pomoże, jeśli programiści i informatycy/administratorzy nie będą ze sobą współpracować. DevOps nie rozwiązuje problemów z narzędziami. Rozwiązuje problemy natury ludzkiej.

Pomyśl o metodyce DevOps jako o rozwinięciu Agile — różnica polega na tym, że DevOps w sposób domyślny uwzględnia operacje. Krokiem we właściwą stronę będzie utworzenie zespołów ukierunkowanych na produkt zamiast zespołów pełniących konkretne funkcje. Uwzględnij w zespole programistów, specjalistów ds. zapewniania jakości, kierowników produktu, projektantów, administratorów, kierowników projektu oraz osoby posiadające wszelkie inne umiejętności potrzebne w długofalowym projekcie. Zamiast tworzyć jeden zespół, który ma zajmować się wszystkim, lub zatrudniać „specjalistów DevOps”, lepiej jest tworzyć zespoły, które zajmują się konkretnymi produktami i które mogą ze sobą sprawnie współpracować.

Niewiele jest rzeczy, które wpływają na współpracę równie korzystnie, jak wspólny cel i plan jego osiągnięcia. W niektórych firmach nagłe przekształcenie zespołów na model ukierunkowany na konkretny produkt to zbyt duża i zbyt szybka zmiana. Warto więc osiągać cel mniejszymi krokami. Zespoły programistyczne mogą (i powinny) zapraszać wybranych administratorów, aby dołączali do sesji planowania sprintów, codziennych spotkań zespołu i demonstracji sprintów. Zespoły operacyjne mogą natomiast zapraszać na swoje spotkania kluczowych programistów. To zwinny i naturalny sposób, aby być na bieżąco z pracą, pomysłami i problemami kolegów.

materiały pokrewne

Dowiedz się więcej o zaletach DevOps

materiały pokrewne

Tworzenie kultury DevOps

Wyzwania, a nawet sytuacje awaryjne stanowią doskonały test kultury DevOps. Czy programiści, administratorzy i specjaliści wsparcia klienta zbierają się razem i rozwiązują problem jako zespół? Czy analiza post-mortem incydentów faktycznie koncentruje się na ograniczeniu skutków kolejnego incydentu, a nie szukaniu winnych? Jeśli odpowiedź brzmi „tak”, to znak, że Twoja organizacja rzeczywiście funkcjonuje zgodnie z kulturą DevOps.

W firmach, które osiągają największe sukcesy, wszystkie działy współpracują ze sobą w duchu kultury DevOps, która funkcjonuje na wszystkich poziomach schematu organizacji. Przy stosowaniu tego podejścia na tak dużą skalę termin „DevOps” jest często zbyt wąski, a tym samym zasadniczo zbędny. Takie firmy mają otwarte kanały komunikacyjne i regularnie się porozumiewają. Zakładają, że zespół programistyczny odpowiada za zadowolenie klienta w równym stopniu, co kierownictwo produktu. Mają świadomość, że DevOps to nie zadanie dla jednego zespołu. To zadanie dla wszystkich.


Automatyzacja

Automatyzacja pozwala wyeliminować konieczność wykonywania powtarzalnych zadań ręcznie, ułatwia wdrażanie powtarzalnych procedur i pozwala tworzyć niezawodne systemy.

Automatyzacja kompilacji, testowania, wdrażania i aprowizacji to typowy punkt wyjścia dla zespołów, które jeszcze nie korzystają z takich rozwiązań. No i cóż może skłaniać programistów, testerów i administratorów do współpracy bardziej niż tworzenie systemów, które przyniosą korzyść wszystkim?

Zespoły, które dopiero rozpoczynają swoją przygodę z automatyzacją, zaczynają zazwyczaj od ciągłego dostarczania: praktyki polegającej na przepuszczaniu każdej zmiany kodu przez szereg zautomatyzowanych testów, często wspomaganych przez infrastrukturę osadzoną w chmurze, a następnie pakowaniu kompilacji i kierowaniu ich do kolejnych środowisk z wykorzystaniem zautomatyzowanych wdrożeń.

Dlaczego? Komputery wykonują testy bardziej rygorystycznie i wiarygodnie od ludzi. Testy te pozwalają szybciej wykrywać błędy i wady zabezpieczeń. Automatyczne wdrożenia z kolei wysyłają do informatyków/administratorów powiadomienia o przejściach między środowiskami na serwerze, co pozwala ograniczyć niespodzianki na etapie udostępniania nowego wydania.

Innym ważnym wkładem DevOps jest „konfiguracja jako kod”. Programiści starają się tworzyć modułowe aplikacje złożone z wielu elementów, ponieważ są one bardziej niezawodne i łatwiejsze w utrzymaniu. To samo podejście można rozszerzyć na infrastrukturę używaną do hostowania tych aplikacji, niezależnie od tego, czy jest ona osadzona w chmurze, czy w wewnętrznej sieci klienta.

„Konfiguracja jako kod” i „ciągłe dostarczanie” to nie jedyne rodzaje automatyzacji spotykane w świecie DevOps, jednak warto zwrócić na nie szczególną uwagę, ponieważ pomagają przełamać barierę między programistami a administratorami. A gdy metodyka DevOps wykorzystuje zautomatyzowane wdrożenia do wysyłania dokładnie przetestowanego kodu do środowisk o identycznej aprowizacji, hasło „a u mnie działa” przestaje mieć jakiekolwiek znaczenie.


Metodyka Lean

Gdy słyszymy hasło „Lean” w kontekście oprogramowania, zazwyczaj przychodzi nam na myśl eliminowanie działań o małej wartości i szybkie przechodzenie dalej — bycie dynamicznym, zwinnym. Jeszcze bardziej istotne w kontekście DevOps są koncepcje ciągłego doskonalenia i uczenia się na błędach — które stanowią podstawę eksperymentalnego myślenia.

Przyjmując nastawienie DevOps, staramy się wszędzie dostrzegać możliwości ciągłego rozwoju. Niektóre z nich są oczywiste, takie jak regularne analizy retrospektywne umożliwiające usprawnianie procesów zespołu. Inne są bardziej subtelne, jak testowanie różnych podejść do wdrażania nowych użytkowników produktu według modelu A/B.

To metodyce Agile zawdzięczamy fakt, że ciągłe usprawnianie stało się tak popularną ideą. Podmioty, które jako pierwsze przyjęły metodykę Agile, stanowią dowód na to, że prosty produkt trafiający w ręce klientów już dzisiaj jest cenniejszy niż idealny produkt w rękach klientów za pół roku. Jeśli produkt będzie stale ulepszany, klienci nie odejdą.

I wiesz co? Nie da się uniknąć porażek. Więc równie dobrze możesz przygotować swój zespół, aby je akceptował, naprawiał błędy i uczył się na ich podstawie (czasami taką postawę nazywa się „antywrażliwością”). W Atlassian uważamy, że jeśli raz na jakiś czas nie odniesiesz jakiejś porażki, to znaczy, że za mało się starasz.

W kontekście DevOps porażka nie jest zbrodnią, za którą ponosi się karę. Zespoły biorą pod uwagę, że w pewnym momencie coś pójdzie nie tak, więc są przygotowane na szybkie wykrycie problemu i niezwłoczny powrót do normalnego trybu pracy. Analizy post-mortem skupiają się na miejscach, w których procedury się nie sprawdziły, oraz na sposobach ich doskonalenia, a nie na tym, który członek zespołu coś zawalił w kodzie. Dlaczego? Ponieważ ciągłe doskonalenie i porażka idą w parze.


Pomiar

Trudno stwierdzić, czy działania mające na celu ciągłe doskonalenie rzeczywiście cokolwiek doskonalą, jeśli nie dysponuje się danymi. Na szczęście istnieje wiele narzędzi oraz technologii służących do pomiaru wyników, na przykład tego, ile czasu użytkownicy spędzają w Waszym produkcie, czy dany wpis na blogu wygenerował jakąkolwiek sprzedaż, bądź jak często w rejestrach pojawiają się alerty krytyczne.

Choć da się zmierzyć praktycznie każdą rzecz, nie oznacza to, że trzeba (lub powinno się) mierzyć wszystko. Weź przykład z programowania według modelu Agile i zacznij od podstaw:

  • Jak dużo czasu upłynęło od zaprogramowania do wdrożenia?
  • Jak często zdarzają się powracające błędy czy awarie?
  • Jak długo trwa przywrócenie systemu po awarii?
  • Ile osób obecnie korzysta z produktu?
  • Ilu użytkowników przybyło/ubyło w tym tygodniu?

Mając solidne podstawy, łatwiej uchwycić mniej oczywiste wskaźniki dotyczące użycia konkretnych funkcji, ścieżek postępowania klientów czy umów SLA. Otrzymywane informacje przydają się przy tworzeniu harmonogramów i wyznaczaniu kolejnych ważnych kroków.

Te wszystkie cenne dane pomogą członkom Twojego zespołu w podejmowaniu decyzji, jednak jeszcze cenniejsze staną się one po udostępnieniu innym zespołom, szczególnie tym pracującym w ramach innych działów. Na przykład dział marketingu chce wiedzieć o nowych, atrakcyjnych funkcjach, które może sprzedać. Jednak w międzyczasie zauważasz znaczny odpływ klientów, ponieważ produkt nie spisuje się tak, jak powinien, z uwagi na dług techniczny. Udostępnienie danych dotyczących użytkowników na poparcie harmonogramu, nawet jeśli więcej w nim poprawek niż innowacji, ułatwia wypracowanie kompromisu i otrzymanie akceptacji ze strony interesariuszy.


Udostępnianie

Odwieczne tarcia między zespołami programistów i administratorów w dużej mierze wynikają z braku płaszczyzny porozumienia. Wierzymy, że dzielenie się odpowiedzialnością i sukcesami w znaczący sposób przyczynia się do zniwelowania tego podziału. Programiści zdobędą aprobatę, gdy tylko pomogą administratorom dźwigać jeden z ich największych ciężarów: pager (w dzisiejszych czasach to raczej przenośnia). DevOps w dużej mierze opiera się na założeniu, że osoby, które tworzą aplikację, powinny być jednocześnie zaangażowane w jej wydawanie i utrzymywanie.

Z tej koncepcji wywodzi się zasada „programujesz — utrzymujesz”, która sprzyja praktycznemu podejściu w wielu różnych zespołach. Nie oznacza to, że po prostu zatrudniasz programistów i oczekujesz, że będą również doskonałymi administratorami. To oznacza, że programiści i administratorzy współpracują na każdym etapie cyklu życia aplikacji. Ponadto badania pokazują, że w przypadku kodu i produktów recenzja współpracownika jako jedyna skutkuje lepszymi dostawami i wydajnością, i to do tego stopnia, że recenzja zewnętrzna okazuje się równie nieskuteczna co nieprzeprowadzanie żadnej weryfikacji.

W zespołach działających zgodnie z zasadami DevOps często ma miejsce rotacja ról. Programiści usuwają problemy wychwycone przez użytkowników końcowych, a jednocześnie rozwiązują problemy produkcyjne. Takie osoby reagują na pilne zgłoszenia klientów, w razie potrzeby tworzą poprawki i rozpracowują backlog z wadami zgłaszanymi przez klientów. „Programista od pomocy technicznej” ma szansę dowiedzieć się wiele na temat sposobu, w jaki użytkownicy rzeczywiście korzystają z aplikacji. Ponadto wysoka dostępność programistów dla członków zespołu administracyjnego sprzyja budowaniu relacji opartych na wzajemnym szacunku i zaufaniu.

Choć chcielibyśmy mieć magiczną różdżkę, która przekształci wszystkie zespoły w skuteczne zespoły DevOps, transformacje DevOps wymagają połączenia różnych praktyk, filozofii kulturowych i narzędzi. Ale jak już zaznaczyliśmy, korzyści płynące z wyeliminowania izolacji zespołów programistycznych i operacyjnych są warte podjętego wysiłku — efektem jest większe zaufanie, szybsze tworzenie nowych wersji oprogramowania, bardziej niezawodne wdrożenia i lepsza wymiana informacji zwrotnych między zespołami i klientami.

Wdrożenie kultury DevOps nie jest łatwym zadaniem. Jednak z odpowiednim nastawieniem, wysiłkiem i narzędziami organizacja może przejść transformację DevOps, która przyniesie jej znaczące korzyści.

Ian Buchanan
Ian Buchanan

Ian Buchanan is a Principal Solutions Engineer for DevOps at Atlassian where he focuses on the emerging DevOps community and the application of Jira, Bitbucket, and Bamboo for better continuous integration and continuous delivery. While Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of lean and agile practices in large enterprises.

During his career, he has successfully managed enterprise software development tools in all phases of their lifecycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality, and improved customer satisfaction. He has built multi-national agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming, and domain-specific languages.


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