Monitoring bywa tylko słowem w umowie
Zdanie o monitoringu pojawia się w prawie każdej ofercie na obsługę IT. Samo w sobie nie znaczy nic. Można mieć narzędzie, które co minutę sprawdza, czy serwery odpowiadają na ping, i nazywać to monitoringiem. Można mieć wykresy, na które nikt nie patrzy. Można mieć alerty, które wpadają na skrzynkę, gdzie leży ich już tysiąc.
Różnica między posiadaniem monitoringu a wiedzą o tym, co się dzieje, sprowadza się do trzech rzeczy. Czy obserwowane jest to, co realnie się psuje. Czy odchylenie od normy trafia do konkretnej osoby. Czy ktoś raz w miesiącu siada i mówi, co z tego wynika.
Jest prosty test. Zapytajcie swojego dostawcę, ile razy w ostatnim kwartale monitoring wyłapał problem, zanim ktokolwiek z pracowników go zgłosił. Konkretna odpowiedź oznacza, że narzędzie pracuje. Odpowiedź ogólna zwykle oznacza, że monitoring służy do potwierdzania awarii, a nie do ich wyprzedzania.
To nie jest zarzut wobec dostawców. Monitoring jest tą częścią umowy, która najłatwiej zostaje na poziomie deklaracji, bo nikt jej nie sprawdza, dopóki wszystko działa. Warto sprawdzić wcześniej.
Co naprawdę trzeba obserwować
Lista nie jest długa i nie jest żadną tajemnicą. Warto ją mieć pod ręką, bo bardzo szybko pokazuje, czego w danej umowie brakuje:
- dostępność, czyli czy usługa odpowiada. Nie tylko czy serwer odpowiada na ping, ale czy działa to, z czego korzystają ludzie: strona, baza danych, poczta, udział plikowy, system sprzedaży
- wysycenie łączy. Łącze, które w godzinach pracy chodzi na granicy przepustowości, formalnie działa, ale wszystko na nim zwalnia i nikt nie umie powiedzieć dlaczego
- czasy odpowiedzi węzłów sieci. Rosnące opóźnienia i gubione pakiety pojawiają się zwykle na długo przed awarią, na której ktoś w końcu utknie
- miejsce na dyskach. Zapełniony dysk zatrzymuje bazę danych, kolejkę poczty albo kopię zapasową, a jest to najłatwiejsza do przewidzenia awaria w całym IT
- obciążenie procesora i pamięci, obserwowane jako trend, nie jako pojedynczy odczyt. Serwer, który od trzech miesięcy pełznie w górę, w końcu dojedzie do sufitu
- stan kopii zapasowych. Nie samo potwierdzenie, że zadanie się wykonało, ale czy objęło to, co miało objąć, ile trwało i czy zmieściło się w oknie
- błędy w logach systemów i urządzeń. Nie wszystkie, tylko wybrane wzorce, bo inaczej nikt tego nie przeczyta ani razu
- wygasające certyfikaty. To awaria z ustaloną z góry datą, więc nie ma żadnego powodu, żeby kogokolwiek zaskakiwała
Do tego dochodzą rzeczy specyficzne dla konkretnej firmy. Stan zasilaczy awaryjnych, temperatura w szafie, kolejki w systemie magazynowym, czas odpowiedzi jednej aplikacji, na której stoi cała praca działu. Dostawca, który zna wasze środowisko, sam o to zapyta. Jeżeli nie zapytał, monitoring jest prawdopodobnie ustawiony z szablonu.
Certyfikaty wygasają coraz częściej
Wygasający certyfikat to najbardziej przewidywalna awaria w firmowym IT i jednocześnie jedna z najczęstszych. Skutek jest natychmiastowy i widoczny dla klientów: ostrzeżenie w przeglądarce, przerwana integracja między systemami, aplikacja na telefonie, która przestaje się łączyć z serwerem.
Ten temat właśnie stał się trudniejszy. CA/Browser Forum przyjęło w kwietniu 2025 roku harmonogram skracania maksymalnego okresu ważności publicznych certyfikatów TLS. Do 14 marca 2026 roku było to 398 dni. Od 15 marca 2026 roku obowiązuje 200 dni, od 15 marca 2027 roku będzie to 100 dni, a od 15 marca 2029 roku 47 dni. Skraca się też okres, w którym można ponownie wykorzystać wcześniejszą weryfikację domeny, docelowo do 10 dni.
Praktycznie znaczy to jedno. Certyfikat, który wymieniało się raz w roku przy okazji innych prac, trzeba będzie wymieniać kilka razy w roku, a za kilka lat niemal co miesiąc. Lista w arkuszu i przypomnienie w kalendarzu przestają wystarczać, bo pomyłka zdarzy się przy którymś z kolei terminie.
Pytanie do dostawcy jest więc bardzo konkretne. Skąd wiecie, kiedy wygasa każdy z naszych certyfikatów, ile dni wcześniej dostajemy o tym informację i czy odnawianie jest zautomatyzowane. Jeżeli odpowiedź brzmi, że ktoś to pamięta, to nie jest odpowiedź.
Alert i raport to dwie różne rzeczy
Alert dotyczy teraz. Ma powiedzieć jednej osobie, że coś się dzieje, i to na tyle wcześnie, żeby dało się zareagować przed skutkiem. Alert bez adresata nie jest alertem, tylko wpisem w historii.
Raport dotyczy trendu. Ma pokazać, co działo się przez miesiąc, co się pogarsza i co warto zrobić, zanim zamieni się w awarię. Raport nie służy do udowadniania, że wszystko było dobrze. Służy do podejmowania decyzji o pieniądzach: czy trzeba dołożyć dysków, czy zwiększyć przepustowość łącza, czy wymienić przełącznik, który gubi pakiety.
Mieszanie tych dwóch rzeczy jest typowym błędem. Zestawienie wszystkich alertów z miesiąca nie jest raportem, tylko wydrukiem. Z drugiej strony raport, w którym każdy wskaźnik świeci na zielono, a użytkownicy przez trzy tygodnie narzekali na wolną pracę, nie opisuje tej firmy, tylko wybrane wykresy.
Bez progu i bez adresata alert jest tylko wykresem
Monitoring zaczyna działać w momencie, w którym ktoś ustali progi. Nie ogólnie, że dysk się zapełnia, ale konkretnie: przy jakiej wartości pojawia się ostrzeżenie, przy jakiej alarm i jak długo stan musi się utrzymać, żeby powiadomienie wyszło. Bez tego ostatniego warunku jedna chwilowa szpilka obudzi kogoś w nocy bez powodu.
Druga rzecz to adresat. Alert powinien mieć po drugiej stronie jedną osobę albo jeden dyżur, kanał dopasowany do wagi sprawy i ustaloną ścieżkę na wypadek, gdy nikt nie odpowiada. Powiadomienia mogą iść mailem, SMS-em albo na czat zespołu, zależnie od tego, jak pilna jest sprawa i o której godzinie się dzieje. Rzecz w tym, żeby ten podział był ustalony wcześniej, a nie wybierany w trakcie awarii.
Trzecia rzecz to higiena. Alert, który wyskakuje codziennie i nic nie znaczy, po dwóch tygodniach przestaje być czytany, a razem z nim przestają być czytane wszystkie pozostałe. Dlatego progi trzeba korygować, a powiadomienia, które nie prowadzą do żadnego działania, po prostu usuwać. To normalna część utrzymania, nie dowód na to, że monitoring był źle zrobiony.
Jeżeli w umowie nie ma ani progów, ani adresata, monitoring jest wykresem. Ładnym, ale nikogo nie obudzi.
Jak wygląda uczciwy raport miesięczny
Uczciwy raport da się przeczytać w kilka minut i wynika z niego, co zrobić. Nie musi być długi. Musi zawierać rzeczy, których nie widać z bieżącej korespondencji:
- co się zdarzyło: zgłoszenia i awarie, kiedy przyszły, kiedy ktoś się nimi zajął, kiedy zostały zamknięte
- ile problemów wyłapał monitoring przed zgłoszeniem od użytkownika, bo to jedyna miara, która pokazuje, czy monitoring realnie pracuje
- trendy pojemności: dyski, łącza, pamięć, z prostym wnioskiem, kiedy skończy się zapas
- stan kopii zapasowych, razem z informacją, czy w tym okresie wykonano próbne odtworzenie danych i czym się skończyło
- co zmieniło się w infrastrukturze, kto to zlecił i kiedy
- otwarte ryzyka i rekomendacje z uzasadnieniem, a nie sama lista rzeczy do kupienia
Raport, w którym nie ma ani jednej rzeczy, która poszła nie tak, warto czytać ze szczególną uwagą. W żadnej infrastrukturze nie ma miesiąca bez potknięcia. Dostawca, który opisuje je sam, jest wygodniejszy w pracy niż taki, u którego wszystko wychodzi dopiero przy dużej awarii.
Osobno warto ustalić, czy raport przychodzi z automatu, czy ktoś go czyta przed wysłaniem. Automat wysyła co miesiąc to samo. Człowiek dopisuje jedno zdanie o tym, co go zaniepokoiło, i to zdanie zwykle kosztuje mniej niż awaria, przed którą ostrzega.
Pytania, które warto zadać dostawcy
To najkrótsza droga do sprawdzenia, jak jest u was. Żadne z tych pytań nie jest złośliwe i na każde da się odpowiedzieć w kilku zdaniach:
- co dokładnie jest monitorowane. Poproście o listę urządzeń i usług, nie o zapewnienie
- jakie są progi ostrzeżenia i alarmu dla dysków, łączy, procesora i pamięci
- kto dostaje alert w środku nocy i w weekend, i co się dzieje, gdy ta osoba nie odpowie
- czy dyżur poza godzinami pracy jest zapisany w umowie, czy jest kwestią dobrej woli
- gdzie fizycznie działa monitoring i czyje są zbierane dane
- co zostaje u nas, jeżeli zmienimy dostawcę: konfiguracja, historia, dostęp do danych
- jak długo trzymane są metryki i logi, bo bez historii nie ma żadnego trendu
- czy możemy dostać podglądowy dostęp do pulpitu z bieżącym stanem
- czy kopie zapasowe są sprawdzane próbnym odtworzeniem i jak często
- czy możemy zobaczyć przykładowy raport miesięczny, choćby z zasłoniętymi danymi innego klienta
Ostatnie pytanie jest zwykle najbardziej wymowne. Dostawca, który raportuje regularnie, ma taki dokument pod ręką i pokaże go bez przygotowań. Jeżeli przykładowy raport trzeba dopiero przygotować, to znaczy, że dotąd nie powstawał.
Jak podchodzimy do tego u siebie
Monitoring prowadzimy z Elastic Stack, na infrastrukturze klienta. Dane z urządzeń sieciowych zbiera Logstash, korzystając z SNMP i sysloga, a z serwerów i systemów przychodzą przez Filebeat, Winlogbeat i Metricbeat. Alerty idą mailem, SMS-em albo na czat, zależnie od wagi sprawy. W tym modelu obsługujemy kilka tysięcy urządzeń.
Rozwiązanie po stronie klienta wybraliśmy świadomie. Dane zostają w firmie, progi ustawiamy pod konkretne środowisko, a widok operacyjny składamy tak, żeby w kilkadziesiąt sekund dawał odpowiedź na pytanie, co jest teraz nie tak. Zakres wsparcia, w tym dyżur całodobowy, ustalamy w umowie, bo to warunek, który powinien być zapisany, a nie domyślny. Kolejność zgłoszeń wynika z tego, co najbardziej blokuje pracę.
Jeżeli chcecie po prostu sprawdzić, co dziś jest u was obserwowane, a co nie, wystarczy przejść listę pytań z tego wpisu ze swoim obecnym dostawcą. Z odpowiedzi zwykle wychodzi bardzo klarowny obraz. Jeżeli wyjdzie z niej więcej luk niż spokoju, chętnie usiądziemy do tego razem.