Porównanie DevOps i ITIL — które z nich jest ważne dla Twojego zespołu?

1. DevOps może zastąpić ITIL

„Nie praktykujemy już ITIL — teraz stawiamy na DevOps”. Jeśli zajmujesz się technologią od dłuższego czasu, prawdopodobnie zdarzyło Ci się już usłyszeć to oświadczenie.

Problem w tym, że to po prostu nieprawda. Fakt, że zespoły IT mogą odejść od szkoleń ITIL i izolacji procesów, jednak wciąż potrzebują pewnych aspektów zarządzania usługami. Eksploatacja. Wsparcie. Zarządzanie. Szacowanie kosztów. To wszystko niezwykle ważne funkcje biznesowe, a DevOps nie dostarcza nam wytycznych dotyczących procesów w taki sposób, jak ITIL, więc istnieje duże prawdopodobieństwo, że nawet firmy, które obwieszczają wszem i wobec całkowite przejście na DevOps, i tak przestrzegają pewnych procesów lub zasad ITIL.

2. DevOps = ciągły rozwój, integracja i zautomatyzowane dostarczanie

Podejście DevOps zakłada co prawda ciągły rozwój, integrację oraz zautomatyzowane dostarczanie, jednak nie jest to wszystko, co ma do zaoferowania, i elementy te niekoniecznie stanowią trzon praktyki. Większa część kontekstu i etosu leżącego u podstaw DevOps sprowadza się po prostu do odejścia od starych podziałów i wspólnej pracy opartej na wzajemnym szacunku i kulturze, w której nie szuka się winnych.

Oto właśnie chodzi. O współpracę. Wspólne cele. Wzajemny szacunek. Żadnego szukania kozłów ofiarnych.

Takie podejście oparte na współpracy może doprowadzić do poprawy wszystkich wskaźników biznesowych, nawet jeśli Twój zespół nie wdrożył jeszcze w pełni zautomatyzowanego dostarczania ani ciągłego rozwoju.

3. ITIL/ITSM zawsze wiąże się z obszerną dokumentacją i uciążliwymi procesami, które spowalniają zespoły

Praktyka zna zdecydowanie zbyt wiele przypadków, w których ITIL zinterpretowano błędnie jako „reguły”, a nie wytyczne zapewniające pewną swobodę interpretacji.

Prawda jest taka, że ITIL będzie tym, czym uczyni go Twój zespół. Jeśli model wydaje się sztywny, jest to efekt wyboru, którego ktoś po drodze dokonał. A taki wybór można zmienić.

ITIL najlepiej potraktować jako punkt wyjścia do zrozumienia złożonych procesów IT, którymi większość firm musi zarządzać. To rodzaj mapy drogowej, przewodnika. Podejście to nie ma służyć jako jedyna słuszna droga. Ma ono zapewnić nam kontekst, jakiego potrzebujemy do podejmowania decyzji i możliwie najbardziej efektywnego oraz wydajnego kierowania naszymi zespołami IT.

Gdy postrzegamy ITIL jako zbiór reguł, zazwyczaj kończymy pogrzebani w stosach dokumentacji oraz biurokracji. Jeśli jednak potraktujemy ITIL jako wytyczne, podejście to może usprawnić nasze działania, zamiast je hamować.

4. ITIL/ITSM jest przeznaczone tylko dla dużych firm

Faktem jest, że duże firmy są liderami w zakresie ITIL. Nie oznacza to jednak, że małe firmy nie korzystają z tych wytycznych lub nie mogą z nich skorzystać. Firmy każdej wielkości muszą wiedzieć, w jaki sposób zarządzać zmianami, poważnymi incydentami oraz wiedzą w gąszczu innych podstawowych zadań związanych z prowadzeniem działalności, a ITIL stwarza do tego podstawy.

Ciekawe start-upy muszą w pewnym momencie zorganizować swoje zespoły IT. W przeciwnym razie nie będą w stanie skalować działalności. To samo dotyczy średnich firm. Nawet dwuosobowy, finansowany z własnych środków projekt aplikacji wymaga opracowania planu dyżurów domowych oraz strategii zarządzania incydentami. W przeciwnym razie pojedyncza awaria może na dobre wyeliminować produkt z rynku.

Przyspieszenie nowych wydań dzięki DevOps

Stosowane w DevOps podejście oparte na metodyce Agile przynosi korzyści z punktu widzenia tempa pracy oraz zarządzania ryzykiem, ponieważ małe, regularne wydania szybciej przechodzą przez proces programistyczny, a w razie incydentu łatwiej jest je wycofać i naprawić.

Mniejsza liczba kontaktów z centrum obsługi IT dzięki ITSM

Do najlepszych praktyk zarządzania wiedzą w ITSM należy tworzenie przez zespół IT dokumentacji w trakcie rozwiązywania problemów. Potencjalnie może to w dużym stopniu zmniejszyć obciążenie centrum obsługi dzięki udostępnieniu opcji samoobsługi dla klientów wewnętrznych i zewnętrznych.

Zapobieganie incydentom dzięki ITIL i DevOps

Połączenie sprawdzonych procesów zarządzania incydentami, jakie można znaleźć w ITIL, z właściwą dla DevOps koncentracją na automatyzacji procesów przeglądu, przeprowadzaniem analiz post-mortem bez wskazywania winnych oraz podejściem opartym na zasadzie „odpowiadasz za to, co tworzysz”, to gotowy przepis na zmniejszenie liczby incydentów i skrócenie czasu ich trwania.

Analiza przyczyn incydentów dzięki DevOps

Jedną z najcenniejszych rzeczy, jakie wnosi DevOps, jest kultura, w której nie szuka się winnych. Nie oznacza to, że inżynierowie nie biorą odpowiedzialności za błędy. Oznacza to natomiast, że mogą oni szczerze rozmawiać o tych błędach, prowadzić bardziej przejrzyste rozmowy na temat tego, co poszło źle, nie obawiając się przy tym o utratę pracy.

Dzięki tej zmianie kulturowej zespoły mogą szybciej dotrzeć do sedna incydentów i skoncentrować się na rzeczywistych poprawkach, zamiast wskazywania konkretnej osoby jako źródła problemu w łańcuchu zdarzeń, które doprowadziły do incydentu.

Ograniczenie nieporozumień w relacji z klientem dzięki ITIL

Umowy SLA (o gwarantowanym poziomie świadczenia usług) należą do najlepszych praktyk ITIL. Określają one zobowiązania, jakie podjęto lub jakich nie podjęto w odniesieniu do produktu lub w umowie z klientem, przez co pomagają ograniczyć nieporozumienia oraz skargi.

Optymalizacja procesów dzięki DevOps i ITIL

ITIL to prawdziwa Biblia procesów IT. Zasady te funkcjonują już od dawna i zdążyły dostosować się do nieustannie zmieniających się potrzeb branży.

Przy opracowywaniu własnych procesów nie trzeba odkrywać koła na nowo. ITIL stanowi sprawdzony punkt wyjścia.

A w obszarach, w których zastosowanie podejścia DevOps może przynieść korzyści — na przykład przez wdrożenie analiz post-mortem bez wskazywania winnych, automatyzacji oraz podejść w większym stopniu opartych na współpracy — procesy ITIL można zmodyfikować, aby sprawdzały się jeszcze lepiej.