Ustalamy prace planowe, okna serwisowe i uzgodnione wyłączenia, które nie powinny zaniżać wyniku SLA. Dzięki temu raporty odróżniają realne awarie od zaplanowanych przerw technicznych.

Po zbudowaniu modelu uruchamiamy bieżący pomiar dostępności, raportowanie SLA i dashboardy. Testujemy zachowanie modelu, korygujemy reguły, progi oraz fałszywe alarmy, aż monitoring zacznie dawać wiarygodny obraz działania usług.

Ustalamy, które komponenty są krytyczne, które powodują degradację, a które mają mniejszy wpływ na wynik SLA. Uwzględniamy redundancję, zależności i reguły propagacji statusu, żeby model lepiej odzwierciedlał realny wpływ awarii na biznes.

Określamy, które problemy techniczne wpływają na konkretną usługę. Konfigurujemy znaczniki, warunki usług i reguły dopasowania zdarzeń, żeby przypadkowe lub niepowiązane alerty nie obniżały błędnie dostępności usługi.

Uzgadniamy, co mierzymy, jaki poziom jakości jest oczekiwany i jak raportujemy dostępność. Porządkujemy różnicę między SLI, SLO i SLA, żeby raport nie był tylko procentem, ale wynikiem ustalonych zasad pomiaru.

Tworzymy strukturę usług nadrzędnych i podrzędnych, powiązania z problemami technicznymi oraz logikę reprezentującą usługę biznesową w Zabbix. To pierwszy techniczny model usługi, który można dalej testować i rozwijać.

Rozkładamy wybrane usługi na komponenty techniczne: aplikacje, serwery, bazy danych, API, urządzenia, sieć, integracje i dostawców. Dzięki temu powstaje mapa zależności pokazująca, co faktycznie wpływa na działanie usługi.

Wspólnie z IT i biznesem wskazujemy usługi, aplikacje, procesy lub obszary działalności, które są istotne dla organizacji. Ustalamy, co oznacza, że dana usługa działa, jest zdegradowana albo niedostępna.

Sprawdzamy, czy środowisko Zabbix jest gotowe do budowy monitoringu usług i SLA. Jeśli masz już Zabbixa, oceniamy konfigurację, zakres danych, tagowanie, szablony, dashboardy i gotowość do modelowania usług. Jeśli nie masz środowiska, możemy zacząć od jego wdrożenia według standardów Aplitt.