Podczas konferencji Business Sync Hub Kamil Ousta (Cloudware) i Sebastian Luks (Polkomtel) pokazali, że pytanie
„Ile kosztowała ostatnia godzina awarii?”
nie jest tylko ciekawostką dla zarządu. To test dojrzałości IT. Jeśli organizacja nie potrafi na nie odpowiedzieć, płaci „ukryty podatek” za niewidoczność – w postaci stresu, eskalacji, niepotrzebnych dyskusji, utraconych przychodów i nadszarpniętej reputacji.
Od kontrolek do radaru
Kamil porównał klasyczny monitoring do kontrolek w kokpicie. Lampka sygnalizuje, że coś jest nie tak – ale żeby bezpiecznie dolecieć, pilot potrzebuje radaru, który pokazuje pełny obraz sytuacji i pozwala reagować wcześniej.
W IT takim radarem jest real-time observability: nie tylko wykresy i alerty, ale spójny wgląd w to, co dzieje się w systemach zanim awaria stanie się incydentem biznesowym.
W tradycyjnym podejściu często to użytkownik lub biznes jako pierwszy zauważa problem. Zespół IT dopiero wtedy zaczyna przeglądać metryki, logi i wykresy, szukać korelacji i składać historię zdarzeń. Czas płynie, presja rośnie, a najtrudniejsze pytanie brzmi:
„Ile nas to kosztuje?” – finansowo i operacyjnie.
Brak odpowiedzi to sygnał, że brakuje nie tylko narzędzi, ale też właściwego sposobu myślenia o widoczności.
Koszt niewidoczności: finansowy, reputacyjny i operacyjny.
W praktyce koszt niewidoczności zawsze rozlewa się na trzy obszary:
- Finansowy – koszt przestoju, praca zespołów w trybie awaryjnym, utracone przychody.
- Reputacyjny – spadek zaufania, eskalacje, pogorszenie doświadczenia użytkownika.
- Operacyjny – chaos decyzyjny, war roomy, gaszenie pożarów zamiast kontroli sytuacji.
To właśnie dlatego „koszt godziny awarii” nie jest liczbą „dla CFO”, tylko wskaźnikiem, czy IT potrafi tłumaczyć incydenty na język biznesu.
Jak to wyglądało przed observability – doświadczenie Polkomtela
Sebastian Luks opowiedział, jak monitoring aplikacji krytycznych wyglądał w Polkomtelu przed wdrożeniem IBM Instana. Organizacja przez lata korzystała z wielu narzędzi: BMC Patrol, Zabbix, różne „czujki”, automatyzacje, testy Selenium, systemy klasy MAITA czy Art Central.
Każde z nich spełniało swoją funkcję, ale:
- brakowało jednego miejsca, które wcześniej sygnalizowałoby, że coś zaczyna iść w złą stronę,
- analiza problemu wymagała wiedzy, „gdzie patrzeć” i jak czytać dane po fakcie,
- często dopiero zgłoszenie z biznesu lub od użytkownika końcowego uruchamiało lawinę działań.
Doświadczony administrator potrafił po incydencie powiedzieć, co poszło źle – ale to zawsze było „po”, a nie „przed”.
Monitoring vs. observability – różnica, która zmienia rozmowę z biznesem
Kamil zaproponował prosty podział:
- Monitoring odpowiada na pytanie: „co się zepsuło?”,
- Observability dodaje: „dlaczego się zepsuło i jaki ma to wpływ na biznes?”.
Aby to osiągnąć, observability opiera się na trzech filarach:
- Metryki – liczby opisujące zachowanie systemów (czasy odpowiedzi, błędy, CPU, pamięć).
- Logi – „dziennik pokładowy” z komunikatami i wyjątkami.
- Traces (trasy transakcji) – pełna ścieżka transakcji przez komponenty, aż do miejsca, gdzie proces zaczyna się psuć.
Połączenie metryk, logów i traces pozwala nie tylko wykryć problem, ale też szybko odpowiedzieć na pytania kluczowe dla biznesu: które transakcje są opóźnione, jaki SLA jest zagrożony, jaki proces biznesowy realnie stoi.
Jak Polkomtel wdrażał Instanę: ludzie, nie tylko narzędzie
Sebastian opisał wdrożenie Instany jako proces, który wykracza daleko poza instalację oprogramowania. Organizacja pracuje w modelu celów strategicznych (OKR, BHAG), a jednym z kluczowych celów jest stabilność i bezawaryjność systemów. Observability stało się narzędziem wspierającym realizację tego celu.
Trzy filary wdrożenia:
Pokrycie systemów krytycznych
W strukturze Polkomtela funkcjonują centra kompetencyjne, z których każde odpowiada za kilka kluczowych systemów. Celem było, by w każdym centrum przynajmniej dwa systemy krytyczne zostały objęte observability w Instanie – tak, aby widoczność stała się standardem, a nie wyjątkiem.
Liderzy wiedzy w zespołach
W każdym centrum kompetencyjnym wytypowano co najmniej dwie osoby, które potrafią świadomie korzystać z Instany, analizować dane i wyciągać wnioski. To oni stali się „rozsadnikami” wiedzy, pomagając zespołom przejść z klasycznego monitoringu do codziennej pracy z observability.
Mierzenie efektów
Kolejny etap, już w toku, to mierzenie, jak observability pomaga:
- szybciej diagnozować i rozwiązywać problemy,
- wykrywać zdarzenia w trakcie, a nie po fakcie,
- realnie skracać czas przestojów (MTTR) i poprawiać jakość usług.
Najtrudniejsza okazała się zmiana mentalności: przejście od sporadycznego „zaglądania do narzędzia” do traktowania go jako stałego elementu pracy – z powiadomieniami, smart alertami i analizą trendów.
Observability jako łącznik IT i biznesu: trzy filary bezpieczeństwa
Kamil podkreślił, że prawdziwa wartość observability ujawnia się wtedy, gdy wspiera trzy filary bezpieczeństwa biznesu:
- Techniczny – szybka diagnoza, krótszy czas naprawy, mniej „ślepego” szukania przyczyny.
- Biznesowy – jasne zrozumienie wpływu incydentu na użytkowników, SLA i procesy biznesowe.
- Finansowy/Operacyjny – decyzje w czasie rzeczywistym, zanim incydent przerodzi się w kryzys i koszt przestoju zacznie rosnąć.
Dzięki temu odpowiedź na pytanie „ile kosztuje godzina awarii?” przestaje być intuicją. Staje się liczbą, którą IT może spokojnie przedstawić zarządowi – a, monitoring zmienia się z roli „syreny alarmowej” w narzędzie do zarządzania biznesem w czasie rzeczywistym.
Czy Twoje IT ma już radar?
Na koniec Kamil zadał uczestnikom proste pytanie:
Czy Wasze IT ma już własny radar, czy wciąż lecicie tylko na kontrolkach?
Jeśli w kryzysie to użytkownicy lub biznes jako pierwsi informują o problemach, a odpowiedź na pytanie o koszt awarii wymaga tygodni zbierania danych, to znak, że warto pomyśleć o kolejnym kroku: real-time observability, które łączy ludzi, procesy i technologię w jedną spójną „mapę lotu” dla biznesu.
