W dwóch poprzednich publikacjach (część 1 i część 2) opisałem osiem praktyk, które według mnie należałoby wdrożyć w pierwszej kolejności. Mogłoby się wydawać, że już mamy dużo i radzimy sobie w większości sytuacji. Tak jednak nie jest bo nadal jesteśmy na początku podróży z ITIL i najlepszymi praktykami.

W części drugiej pisałem o praktyce umożliwiania zmian, która jest kluczowym narzędziem kontroli wprowadzania zmiana na środowisko produkcyjne.

Sama jednak praktyka umożliwiania zmian, nie zapewni „wdrożenia” zmian jeżeli nie  wykorzystamy praktyki zarządzania wdrożeniem (Deployment management) i zarządzania wydaniem (Release management).

Te trzy praktyki są bardzo mocno ze sobą powiązane i zależą od siebie w takiej kolejności: umożliwianie zmian, zarządzanie wdrożeniem, zarządzanie wydaniem. Nie można wdrożyć rozwiązania incydentu, dodać nowego wniosku o usługę, przeprowadzić zmiany bez wskazanych dwóch praktyk.

Zarządzaniem wdrożeniem

Celem praktyki zarządzania wdrożeniem jest przenoszenie nowych lub zmienionych komponentów w środowisk produkcyjnych.

Przenoszenie nie musi oznaczać, że komponenty są dostępne dla użytkowników. To zależy czy podejdziemy to tego zagadnienia tradycyjnie czyli waterfall’owo czy zwinnie czyli agile’owo.

W podejściu tradycyjnym wdrożenie jest równoznaczne z udostępnieniem do użytku. Jeżeli instaluję jakiś komponent, usługę na produkcji, to po zakończeniu instalacji jest on dostępny dla użytkowników i mogą go używać.

Przy podejściu zwinnym wdrożenia, czyli przenoszenie różnych komponentów do środowiska produkcyjnego, może się odbywać w różnych momentach czasowych i po takim przeniesieniu, z komponentów tych nie może korzystać użytkownik. Musi nastąpić drugi krok, w ramach praktyki zarządzania wydaniem, kiedy wszystkie zmiany, zostaną zebrane w jedno wydanie i udostępnione użytkownikom do użytku.

Jeżeli chcemy wdrażać dużo zmian w krótkim czasie, możemy wykorzystać podejście ciągła integracja, ciągłe dostarczanie i ciągłe wdrażanie (continous integration, continous delivery, continous deployment – CI/CD). Takie podejście wymaga automatyzacji i wykorzystania wielu narzędzi, które będą wykonywać aktywności z potoku CI/CD zamiast człowieka.

Zarządzanie wydaniem

Celem praktyki zarządzania wydaniem, jest udostępnianie nowych lub zmienionych komponentów do użytku.

W większości przypadków, wydanie zbiera wiele zmian, wdrożeń, które są udostępnianie użytkownikom aby mogli z nich korzystać.

W ramach praktyki mamy harmonogram wydań, który jest narzędziem dokumentowania udostępnianych wydań oraz służy do komunikacji pomiędzy dostawcą usług a użytkownikiem. Może też być narzędziem negocjacji kiedy dane wydanie ma zostać udostępnione użytkownikom.

Co ciekawe harmonogramem wydań zarządza praktyka umożliwiania zmian a nie praktyka zarządzania wydaniami, dlatego taka jest silna relacja pomiędzy tymi praktykami.

Wydania mogą być udostępnianie metodą push lub pull. W metodzie push to dostawca usług decyduje, że nowa wersja komponentu (oprogramowanie, infrastruktura, dokumentacja) jest udostępniania jednocześnie wszystkim użytkownikom i muszą oni korzystać z nowej wersji, bo poprzednia została usunięta. W środowisku produkcyjnym funkcjonuje tylko jedna wersja danego komponentu.

W metodzie pull dostawca usług udostępnia nową wersję komponentu ale to użytkownik decyduje czy korzysta z nowej czy nadal używa poprzedniej. Użytkowni ma większą swobodę w wyborze konkretnej wersji. To jednak sprawia, że w środowisku produkcyjnym mamy więcej niżę jedną wersję komponentu, którym musimy zarządzać, jako dostawca usług.

Monitorowanie i zarządzanie zdarzeniami

Jednym z dwóch głównych źródeł incydentów, oprócz użytkowników, jest monitorowanie i zarządzania zdarzeniami. Jednym słowem praktykę zarządzania incydentami, wspiera w bardzo dużym zakresie praktyka monitorowania i zarządzania zdarzeniami. Zresztą nie tylko w tym zakresie o czym za chwilę.

Celem praktyki jest systematyczne obserwowanie usług i komponentów usług oraz rejestrowanie i raportowanie wybranych zmian stanu zidentyfikowanych jako zdarzenia.

Mówiąc najprościej monitorujemy elementy konfiguracji aby jak najwcześniej wykrywać zdarzenia, które mogą negatywnie wpływać na działanie usług. Im wcześniej wykryjemy zdarzenie i podejmiemy odpowiednie działania tym będzie mniejszy negatywny wpływ na użytkowników oraz możemy zapobiec wystąpieniu incydentów. Jest to działanie proaktywne, które zmniejsza nam prawdopodobieństwo występowania incydentów.

Monitorowanie i zarządzanie zdarzeniami powinno obejmować swoim zakresem całą organizację i wszystkie narzędzia monitorowania, które są wykorzystywane. Samo ustalenie zakresu monitorowania może już być wyzwaniem, szczególnie że najróżniejszych miar i metryk mamy setki a nawet tysiące.

Co jest ważne? Jakie miary monitorować? Jakie wartości progowe ustawić? Jak często wysyłać powiadomienia? Jakie działania podejmować w przypadku wystąpienia zdarzeń? Każda organizacja musi zmierzyć z tymi pytaniami aby nie zgubić ważnych zdarzeń w szumie informacyjnym.

Monitorowanie pozwala nam również śledzić postęp obsługi incydentów oraz potwierdzać skuteczność ich rozwiązania, niezależnie od potwierdzenia od użytkownika.

 

Im dalej w las tym więcej drzew dlatego będę kontynuował ten temat w kolejnym artykule, bo jak widać wcale nie jest łatwo wybrać, która praktyka powinna być wdrożona wcześniej a która później.