Model CALMS

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 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.

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 i elastycznym. 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.

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. Przykładowo 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 planu rozwoju, nawet jeśli więcej w nim poprawek niż innowacji, ułatwia wypracowanie kompromisu i uzyskanie akceptacji ze strony interesariuszy.

Choć chcielibyśmy mieć magiczną różdżkę, która przekształci wszystkie zespoły w wydajne 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 odpowiedzialnych za eksploatację systemów informatycznych są warte podjętego wysiłku — efektami są większe zaufanie, szybsze wydawanie 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.

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.

Firma Atlassian opracowała Open DevOps dla zespołów szukających możliwości tworzenia łańcucha narzędzi zgodnego z ich oczekiwaniami z użyciem ulubionych narzędzi dzięki integracjom z produktami wiodących dostawców i aplikacjom ze sklepu Marketplace. Wypróbuj teraz.