Zrozumienie Monitorowania Obejmowanego (Observability)
Każda aplikacja czy też sklep stacjonarny bądź korporacyjne oprogramowanie dla klientów wytwarza w ułamkach sekundy dziesiątki tzw. logów, czyli poświadczeń swoich mikroakcji na serwerach w postaci plików tekstowych takich jak "Godzina 14:00 - Nawiązano połączenie dla IP" do "Godzina 14:02 Błąd numer 404 brak towaru bazy danych nr X". Klasyczne podejście zakłada, że do znalezienia zgubionych powiązań podczas awarii musimy "rzucić" kilku deweloperów z pensjami na pół nocy grzebania w serwerze w celu zlokalizowania odpowiedniego poświadczenia o czasie by napisać złą instrukcję do bazy.
W dzisiejszej informatyce jest to niemożliwe; posiadanie profesjonalnego środowiska IT oznacza posiadanie ciągłego "nasłuchu" na te maszyny przez wyspecjalizowanych menedżerów od chmur metryk np. logów błędów obciążenia wyrysowujących kolorowe wykresy pożarowe, gdzie zespół nie błądzi we mgle domniemając lecz w sekundy idzie do miejsca w serwerze po zablokowany ruch.
W czym to się sprawdza biznesowo najlepiej?
Wyobraźmy sobie Black Friday w ogromnej firmie sieciowej posiadającej własny sklep w internecie. Przez niesamowity przyrost odwiedzających w locie, zasoby fizycznego komputera tzw. stery dla użytkownika potrafią dotrzeć pod sufit "pamięci RAM" powodując lawinowy tzw. niedostępny tryb i w kilka kwadransów blokując wpływy uderzające na konta. Klient dzwoni dopiero jako ostatni ogniwo na linię, informując wściekle, że strona zawiesza pule autoryzacji transakcji na koszyku. Zbudowanie od początku solidnych wizualizacji połączonych z rygorystycznymi alertami do działów DevOps/Support rozwiązuje ten koszmar – system o godzinie wczesno rannej 8:00 wypuści w firmie automatyczny alarm awaryjny typu SMS predykcyjnie raportując, że przy takich zamówieniach pamięć maszyny załamie się około południa i wyda polecenie do zapasowego serwera, by podbarto mu więcej przestrzeni wyżej odcinając klientów i pracowników obsługi przed tymi rewelacjami z zewnątrz.
Największe korzyści dla stabilności środowiska firmy:
- Proaktywne a nie reaktywne zarządzanie przestojami - dział techniczny wie jako pierwszy, że coś właśnie ulega awarii, a nie ostatni z maili dzwoniących szefów i klientów; daje to ogromny bufor czasowy, do uratowania wizerunku firmy naprawiając dany pożar bezboleśnie i potajemnie zanim użytkownik wejdzie.
- Szybki czas diagnozy MTTR (Mean Time To Repair) - znalezienie przysłowiowej usterki od awantury przez e-mail, że bilet na pociąg nie chciał zostać wydrukowany na stacji "Wawa-Wschodnia", to proces karkołomny dla IT (czy padła stacja? czy bank? czy wydruk?) – agregując dzienniki (logi) do jednego podanego narzędzia za jednym wpisem o frazę "Bilet #0052" wiemy sekunda po sekundzie co uległo rozdarciu skracając od nowa setki prób przywrócenia poprawnej wersji kodu w dziale technicznym.
- Wyrysowanie wizualne KPI dla ścisłego biznesu i decydentów - te same techniki i serwerownie logów które informują i ułatwiają informatykom awarie, mogą wyświetlać eleganckie dashboardy o wielkości sprzedawanych towarów ze stref czy ilości dzwoniących klientów bezpośrednio w pokojach dyrektorów np. używając paneli operacyjnych obwieszczających ile zaoszczędzono lub ile operacji dzisiaj "straciło" koszyki przez ewentualne zatorowanie sieci np. kartowej B2B.