ITIL®4 vs DevOps: podobieństwa i różnice 

Napięcie pomiędzy tymi, którzy preferują DevOps, a tymi, którzy wolą ITIL, często koncentruje się wokół tempa zmian w IT. Koncentruje się ono również wokół rady doradczej ds. zmiany (change advisory board, CAB), która często jest błędnie postrzegana, określana i wdrażana jako rada zatwierdzająca zmiany.

Istnieją oczywiście inne punkty sporne. Jeśli jednak przyjrzeć się im bezstronnie, można znaleźć wiele podobieństw między tymi podejściami, a także możliwość poprawy świadczenia usług przez organizację IT, operacji wsparcia i związanych z nimi wyników biznesowych.

ITIL 4: podstawowe pojęcia

Opublikowany po raz pierwszy w latach 80. XX wieku system ITIL jest określany jako "szeroko przyjęte wytyczne ITSM". Zmieniał się w drodze ewolucji i w 2019 roku ukazała się wersja TIL 4.

W porównaniu z poprzednimi wersjami ITIL 4 lepiej odzwierciedla  podejście do dostarczania i wspierania usług. Istotną zmianą jest podejście do doświadczeń klienta, strumieni wartości i transformacji cyfrowej, a także nowe sposoby pracy, takie jak Agile, Lean i DevOps.

ITIL to ramy zarządzania usługami oraz profesjonalny system certyfikacji, który wspiera organizacje i osoby prywatne w uzyskaniu optymalnej wartości z usług informatycznych i cyfrowych. Podczas gdy zarządzanie usługami jest zestawem wyspecjalizowanych zdolności organizacyjnych umożliwiających tworzenie wartości dla klientów w formie usług, ITSM to wykorzystanie zdolności zarządzania usługami w kontekście dostawcy usług IT.

Kluczowe zmiany w ITIL 4

Podczas, gdy poprzednie wersje ITIL były postrzegane jako skupiające się nadmiernie na procesach ITSM, ITIL 4 dostarcza 34 praktyki zarządzania, które zawierają wytyczne jak najlepiej osiągnąć pożądane wyniki i wartość. Praktyki te zawierają wytyczne dotyczące architektury, zmian organizacyjnych, projektów, siły roboczej i talentów, relacji z interesariuszami, ryzyka, analizy biznesowej, aktywów IT i innych.

Wspomniane 34 praktyki są częścią systemu wartości usług ITIL, przedstawionego na rysunku wraz z:

• łańcuchem wartości usług ITIL  (Service Value Chain)
• zasadami przewodnimi ITIL (Guiding Principles)
• zarządzaniem (Governance)
• ciągłym doskonaleniem (Continual improvement)

Co napędza DevOps?

Na pochodzenie DevOps (od połączenia słów development i operations) można spojrzeć z kilku perspektyw. Na przykład, od dawna panuje pogląd, że zespoły rozwoju (Dev) i operacji IT (Ops) pracują w silosach; zespół Dev przekazuje nowy kod zespołowi Ops, który następnie zmaga się z codziennym zarządzaniem nową lub zmienioną usługą IT. Kluczowym założeniem DevOps jest to, że dwa zespoły pracują nad tym samym wynikiem biznesowym, ale używają różnych celów i różnych miar wydajności i sukcesu. DevOps przeciwstawia się sposobowi pracy w silosach.

Innym przykładem problemu, który rozwiązuje DevOps, jest tradycyjne podejście kaskadowe, które nie pasuje do szybkiego tempa zmian wymaganego dziś przez firmy. Podejście kaskadowe może dostarczać zbyt mało, zbyt rzadko i zbyt późno. Ponadto, jest to podejście obarczone wysokim ryzykiem, które może zagrozić działalności biznesowej i wynikom. DevOps powstał jako rozwiązanie tych i innych problemów związanych z rozwojem i dostarczaniem technologii.

Podstawowe pojęcia DevOps 

Jak definiujemy DevOps? DevOps to kultura organizacyjna, której celem jest usprawnienie przepływu wartości do klientów. DevOps koncentruje się na kulturze, automatyzacji, Lean, pomiarach i współdzieleniu (culture, automation, Lean, measurement, sharing - CALMS).

DevOps to podejście do rozwoju i dostarczania technologii, składające się z zestawu norm kulturowych, zasad, praktyk technicznych i narzędzi.

Chociaż korzystanie z rozwiązań chmurowych i automatyzacja są często uważane za kluczowe czynniki sprzyjające DevOps, to kultura jest najważniejszym czynnikiem wpływającym na jej skuteczne wykorzystanie. Christopher Little wyraża to w zwięzły sposób: DevOps nie jest o automatyzacji, tak jak astronomia nie jest o teleskopach. ¹

Jednak musimy zdawać sobie sprawę, że astronomia opiera się na wykorzystaniu teleskopów. Automatyzacja pozwala na wykonanie większej ilości pracy i umożliwia wykwalifikowanym specjalistom skupienie się na tworzeniu wartości dodanej działań.

The DevOps Handbook wyjaśnia jak DevOps przynosi korzyści organizacjom:

Wyobraź sobie świat, w którym właściciele produktu, Development, QA, IT Operations i InfoSec pracują razem, nie tylko po to, aby sobie pomagać, ale także po to, aby zapewnić sukces całej organizacji. Pracując nad wspólnym celem, umożliwiają szybki przepływ zaplanowanych prac do produkcji (np. wykonując dziesiątki, setki, a nawet tysiące wdrożeń kodu dziennie), jednocześnie osiągając światowej klasy stabilność, niezawodność, dostępność i bezpieczeństwo. ²

Korzyści płynące z DevOps

DevOps przynosi korzyści zarówno zespołom deweloperów jak i operacji. Niemniej jednak, biznes w znacznym stopniu korzysta z przyjęcia DevOps, co może skutkować następującymi ulepszeniami:

• wyższa jakość produktów i usług
• zwiększona wydajność i obniżone koszty
• szybszy czas wprowadzania na rynek nowych funkcjonalności i produktów lub usług z optymalizacją wartości biznesowej i ryzyka
• zwiększenie przewagi konkurencyjnej
• większa satysfakcja i utrzymanie klientów

Przyjęcie DevOps poprawia wydajność IT, prowadząc do większej szybkości i lepszego dopasowania do potrzeb klienta. Raport State of DevOps 2019 pokazuje, że możliwa jest optymalizacja pod kątem stabilności bez poświęcania szybkości. ³ 

Mówi on również, że gdy elitarna grupa (firmy osiągające najlepsze wyniki, 20 proc. próby badawczej) jest porównywana z firmami osiągającymi najniższe wyniki (firmy osiągające najniższe wyniki, 12 proc.  próby badawczej), to mają one:

• 208 razy częstsze wdrażanie kodu
• 106 razy szybszy czas realizacji od zobowiązania do wdrożenia
• 2604 razy szybszy czas powrotu do normalności po incydentach
• 7 razy niższy wskaźnik niepowodzeń zmian

Jak ITIL 4 i DevOps są do siebie dopasowane?

W przypadku DevOps i ITIL nie musi to być sytuacja typu: jedno albo drugie. ITIL i DevOps różnią się od siebie, szczególnie dlatego, że DevOps nie jest zbiorem najlepszych praktyk jak ITIL. Jednak zarówno DevOps jak i ITIL to filozofie, sposoby myślenia organizacji i zestawy zasad, których celem jest ciągłe zwiększanie wartości.

Podręcznik The DevOps Handbook⁴ obalił wiele mitów dotyczących DevOps, takich jak:

• DevOps jest tylko dla start-upów
• DevOps oznacza eliminację operacji IT lub NoOps
• DevOps jest niekompatybilny z ITIL
  
  

W odpowiedzi na ostatni z mitów The DevOps Handbook stwierdza, że:

Praktyki DevOps można uczynić kompatybilnymi z procesem ITIL. Jednakże, aby wspierać krótszy czas realizacji i większą częstotliwość wdrożeń związanych z DevOps, wiele obszarów procesów ITIL staje się w pełni zautomatyzowanych, co rozwiązuje wiele problemów związanych z procesami zarządzania konfiguracją i wydaniami. A ponieważ DevOps wymaga szybkiego wykrywania i odzyskiwania w przypadku wystąpienia incydentów, dyscypliny ITIL dotyczące projektowania usług, zarządzania incydentami i problemami pozostają tak samo istotne jak zawsze.⁵

ITIL w wersji 4 przyjął wiele sposobów myślenia i pracy DevOps, co jest widoczne w siedmiu zasadach przewodnich ITIL, w tym:

• Focus on value: wyraźne nakładanie się ITIL 4 i DevOps w odniesieniu do wartości dla klienta
• Progress iteratively with feedback: ciągła analiza informacji zwrotnych dotyczących usług IT na każdym etapie cyklu życia.
• Think and work holistically: podejście end-to-end do cyklu życia usług oraz integracja praktyk zarządzania produktem i usługami
• Optimize and automate: zachęcanie do szerokiej automatyzacji łańcucha wartości usług

Obecny stan DevOps i ITSM

A zatem, gdzie dziś jesteśmy? Krótka odpowiedź brzmi: wciąż jest wiele do zrobienia. W badaniu Future of ITSM 2019⁶ tylko 6 proc. respondentów  z próby profesjonalistów ITSM, stwierdziło, że personel ITSM był w pełni zaangażowany w działania DevOps w ich firmie. Oznacza  to spadek z 13 proc. w 2017 roku. Częściowe zaangażowanie również spadło z 40 proc. do 27 proc. pomiędzy badaniami z 2017 i 2019 roku.

Patrząc w przyszłość, sytuacja wygląda nieco lepiej. Na pytanie Jaki poziom zaangażowania specjalistów ITSM w działania DevOps przewidują państwo na rok 2021? opcja brak zaangażowania lub bliski braku zaangażowania spadła z 38 proc. do 18 proc. (Patrz tabela poniżej).

Jaki poziom zaangażowania pracowników ITSM w działania
DevOps przewidują Państwo na rok 2021? ⁷

Jeśli chodzi o odpowiedź, dlaczego specjaliści ITSM nie byli tak zaangażowani w DevOps, może to być mieszanka czynników np. braku zaproszenia do uczestnictwa i braku chęci uczestnictwa. Jednak statystyki raportu State of DevOps 2019 dowodzą, że specjaliści ITSM nie mogą już dłużej ignorować istnienia DevOps. Raport potwierdza bowiem, że DevOps usprawnia rozwój i dostarczanie technologii, przynosząc tym samym korzyści dla łańcucha wartości IT.

Zamiast tego nadszedł czas, aby specjaliści ITSM i DevOps traktowali DevOps i ITSM jako podejścia uzupełniające się, które mogą przynieść lepsze wyniki biznesowe dzięki lepszym usługom IT. Należy przyjąć najlepsze z obu podejść, aby znaleźć i wykorzystać jeden sposób pracy we dzielonych wspólnie obszarach. Powinien to być sposób pracy skoncentrowany na produktach i usługach, wartości biznesowej i wynikach oraz ciągłym doskonaleniu.

Wytyczne dotyczące integracji DevOps i ITIL

Zastanawiając się nad statystykami związanymi z obecnym poziomem zaangażowania profesjonalistów ITSM w DevOps, można wskazać kilka sposobów, w jaki mogliby oni bardziej zaangażować się w działania DevOps w swojej organizacji:

• Przestań czekać na zaproszenie: bądź proaktywny, zaangażuj się. Nadszedł czas, aby Dev i Ops zjednoczyły się w DevOps. Rezygnacja z tego kroku będzie miała negatywny wpływ na Twoją organizację i jej rosnącą zależność od technologii.
  
  
• Spójrz na swoje obecne praktyki ITIL przez pryzmat DevOps: zidentyfikuj, co do nich pasuje, a co nie. Gdzie występuje duplikacja wysiłków lub potencjalne konflikty? Ponadto, zidentyfikuj obszary w których lepsza współpraca pomoże zarówno deweloperom jak i operacjom. DevOps i ITSM są komplementarne, więc zdecyduj co musi się zmienić, aby ludzie mogli pracować wspólnie.
  
  
• Upewnij się, że zespoły używają wspólnych metryk: ze względu na silos deweloperów i operacji często istnieje rozbieżny zestaw metryk stosowanych przez każdy zespół. W takich scenariuszach trudno jest zespołom współpracować, prawdopodobnie pozostawiając przynajmniej jeden z nich w sprzeczności z potrzebami i oczekiwaniami biznesu.

Przykłady integracji DevOps i ITIL

Istnieje wiele sposobów w jaki DevOps i ITIL mogą się wzajemnie uzupełniać i wspierać w poprawie wyników biznesowych.

Oto przykłady:

• Włączenie wsparcia operacyjnego na wczesnym etapie. Usunięcie barier organizacyjnych pomiędzy działem deweloperów i operacji zwiększy poziom komunikacji, współpracy i odpowiedzialności. W konsekwencji, deweloperzy mogą w większym stopniu skupić się na tym jak usługi wsparcia i zasoby będą musiały się zmienić.
  
  
• Poprawa projektowania usług. Nie chodzi tylko o lepszą współpracę; chodzi o pokazanie ludziom, co mogą osiągnąć i wnieść. Chodzi o wartość, którą mogą współtworzyć. Wymaga to przezwyciężenia ustalonych procesów, aby zobaczyć wyniki biznesowe i związane z nimi strumienie wartości. Z nowymi lub zmienionymi usługami ujętymi w kontekście całego ekosystemu usług i wsparcia, a nie w izolacji.
  
  
• Tworzenie odpowiednich dla biznesu możliwości zmiany i wydawania: jak już wspomnieliśmy w odniesieniu do CAB, procesy ITIL dotyczące zmiany i wydania od dawna sprawiają zespołom deweloperów problemy. Jest to głównie spowodowane biurokracją i opóźnieniami. Z drugiej strony, działy operacyjne mogą postrzegać praktyki DevOps jako zaniedbujące kontrolę zmian na rzecz zwiększonej szybkości. Jednak ten pogląd na DevOps jest bezpodstawny, gdy technologia jest używana do ciągłego sprawdzania błędów do automatyzacji wydania, aby zwiększyć zarówno pewność jak i szybkość. Nadszedł czas, aby specjaliści ITSM zaczęli stosować ciągłą integrację, dostarczanie i wdrażanie (continuous integration, continuous delivery, continuous deployment) tam, gdzie to możliwe. Stan metryk DevOps jest dowodem na ten i inne sukcesy DevOps.

Podsumowanie

ITIL i DevOps nie są niekompatybilne. Chociaż się różnią, istnieje możliwość wykorzystania ich jako podejść komplementarnych. Na przykład, siedem zasad przewodnich ITIL uzupełnia DevOps, ponieważ oba podejścia koncentrują się na wartości dla klienta, zachęcają do automatyzacji łańcucha wartości usług i mają podejście end-to-end do cyklu życia usług, a także integrują praktyki zarządzania produktem i usługami.

The DevOps Handbook wyjaśnia niektóre z założeń dotyczących domniemanej niekompatybilności tych dwóch podejść. Stwierdza on, że wiele procesów ITIL może zostać zautomatyzowanych, aby wspierać krótsze czasy realizacji związane z DevOps. Co więcej, specjaliści ITSM i DevOps powoli zaczynają zdawać sobie sprawę, że najlepsze aspekty ITIL i DevOps mogą zostać wdrożone w celu uzyskania lepszych wyników. Niemniej jednak, specjaliści ITSM muszą być proaktywni i zaangażować się w DevOps, aby skorzystać z tego, co ITIL i DevOps oferują najlepszego.

Przypisy