Spis treści
- Dlaczego powiadomienia push zawodzą przy krytycznych usługach
- Jak działają alerty telefoniczne w Echobell
- Konfiguracja alertów telefonicznych w narzędziu monitorującym
- Wykorzystanie istniejącego testu kondycji
- Co umieścić w alercie
- Wybór właściwego poziomu pilności
- Skalowanie na wiele usług
- Prawdziwa korzyść
- Powiązane materiały
Problemem nie jest to, że Twoje API pada o trzeciej nad ranem. Problemem jest to, że dowiadujesz się o tym o dziewiątej, gdy użytkownicy zalali już skrzynkę wsparcia.
Większość narzędzi monitorujących świetnie wykrywa awarie. Fatalnie natomiast pilnuje, żeby ktoś rzeczywiście zobaczył alert we właściwym momencie. Standardowe powiadomienie push leży na zablokowanym ekranie, dopóki ktoś przypadkiem nie sięgnie po telefon. Wiadomość na Slacku przepada w kanale, w który nocą nikt nie zagląda. E-mail zostaje nieprzeczytany do poniedziałkowego poranka.
Alerty telefoniczne zmieniają to równanie. Gdy test kondycji API zawiedzie, Twój telefon naprawdę dzwoni — tak samo jak przy każdej innej pilnej sprawie. Odbierasz, słyszysz, co jest nie tak, i możesz od razu zabrać się za naprawę, zamiast wiele godzin później.
Dlaczego powiadomienia push zawodzą przy krytycznych usługach
Przeciętny smartfon odbiera od 50 do 100 powiadomień push dziennie. Twój alert o awarii API konkuruje z aktualizacjami aplikacji, powiadomieniami z mediów społecznościowych, alertami informacyjnymi i wszystkim innym na urządzeniu. Gdy wszystko jest pilne, nic nie sprawia wrażenia pilnego.
Powstaje przez to niebezpieczny schemat:
- Narzędzie monitorujące wykrywa, że API zwraca błędy 500
- Wysyła powiadomienie push na Twój telefon
- Telefon leży na biurku ekranem do dołu, z włączonym trybem Skupienia
- Alert czeka tam po cichu, aż ktoś go zauważy — wiele godzin później
W przypadku niekrytycznego mikroserwisu takie opóźnienie jest irytujące. W przypadku API płatności, usługi uwierzytelniania albo backendu głównego produktu kosztuje realne pieniądze i zaufanie.
Jak działają alerty telefoniczne w Echobell
Echobell dostarcza powiadomienia na trzech poziomach pilności:
- Standardowe (Active): zwykłe powiadomienie push
- Czasowo krytyczne: przebijają się przez tryb Skupienia w iOS, ale nie dzwonią
- Połączenie: telefon dzwoni jak przy zwykłej rozmowie
Przy awariach API, które dotykają użytkowników, właściwy jest poziom połączenia. Odzwierciedla to, jak reagujesz na każdy inny pilny telefon — odbierasz, bo aparat dzwoni.
Konfiguracja jest prosta:
- Utwórz kanał w Echobell
- Ustaw typ powiadomień na połączenie
- Podłącz swoje narzędzie monitorujące przez webhook
- Gdy test kondycji zawiedzie, Echobell zadzwoni na Twój telefon
Konfiguracja alertów telefonicznych w narzędziu monitorującym
Większość platform monitorujących potrafi wysłać webhook, gdy test się nie powiedzie. Oto jak to podpiąć.
Wykorzystanie istniejącego testu kondycji
Jeśli masz już endpoint zdrowia (na przykład /health albo /status), ustaw monitor tak, aby sprawdzał go w regularnych odstępach. Gdy odpowiedź nie ma kodu 200, uruchamiany jest webhook.
Echobell przyjmuje payloady webhooka z tytułem i treścią:
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"title": "API DOWN: payment-service",
"body": "Health check failed - 500 error at 03:42 UTC",
"notificationType": "calling",
"externalLink": "https://your-dashboard.example.com/incidents/123"
}'To pole notificationType: calling sprawia, że telefon zaczyna dzwonić.
Co umieścić w alercie
Treść alertu ma dać się ogarnąć wzrokiem. Odbierając telefon o trzeciej nad ranem, musisz zrozumieć problem natychmiast:
- Nazwa usługi — które API albo mikroserwis zawiodły
- Rodzaj błędu — timeout, 5xx, odrzucone połączenie
- Znacznik czasu — kiedy zaczęła się awaria
- Odnośnik — gdzie od razu szukać przyczyny
To nie miejsce na rozwlekłe komunikaty. Chodzi o natychmiastowy kontekst, żebyś mógł zdecydować, czy budzić się na dobre, czy tylko potwierdzić alert i spać dalej.
Wybór właściwego poziomu pilności
Nie każda awaria API wymaga telefonu. Alerty w formie połączenia stosuj przy:
- Usługach płatności i rozliczeń
- Endpointach uwierzytelniania i logowania
- Głównych API produktu, z których użytkownicy korzystają bezpośrednio
- Usługach, od których zależą inne krytyczne systemy
Powiadomień czasowo krytycznych używaj przy:
- Usługach drugorzędnych, ważnych, ale niedecydujących o przychodzie
- Środowiskach deweloperskich i staging
- Sygnałach ostrzegawczych (podwyższony odsetek błędów, który nie jest jeszcze pełną awarią)
Standardowych powiadomień używaj przy:
- Niekrytycznych zadaniach w tle
- Informacyjnych metrykach, które nie wymagają działania
Takie stopniowanie utrzymuje Cię w gotowości, nie wywołując zmęczenia alertami.
Skalowanie na wiele usług
Jeśli utrzymujesz więcej niż jedno API, utwórz osobne kanały dla każdej usługi lub grupy usług:
production-payment-api— poziom połączeniaproduction-user-api— poziom połączeniaproduction-analytics-api— czasowo krytycznystaging-all— czasowo krytyczny
Dzięki temu dostroisz pilność do konkretnej usługi. API płatności zasługuje na telefon; potok analityczny raczej nie.
Prawdziwa korzyść
Wartość alertów telefonicznych nie tkwi w samym dzwonieniu, tylko w zmianie zachowań, którą wywołują:
- Naprawiasz problemy szybciej, bo dowiadujesz się o nich od razu
- Śpisz spokojniej, wiedząc, że jeśli coś się zepsuje, naprawdę zostaniesz obudzony
- Twoi użytkownicy krócej odczuwają awarię, bo reagujesz w minutach zamiast w godzinach
Przy krytycznych usługach właśnie o tę różnicę chodzi.