Niezawodność

Niezawodność, na którą platforma alertowa musi zasłużyć

Cały sens narzędzia do alertowania to przetrwać najgorsze minuty roku. Oto co robi WardenPoint, żeby być na nie gotowy: nadmiarowość kanałów, przewidywalne ponowne próby, łańcuchy świadome potwierdzeń i log audytu, który da się przeczytać.

Cel uptime
99.99%
Mediana opóźnienia
~20ms
Kanałów na krok
3+

Alert, który przetrwa zły dzień

  1. +0s
    Odbiór API — Przyjęty; UUID przydzielony
  2. +1s
    Telegram — Wiadomość głosowa wysłana
  3. +10s
    Rezerwa głosowa — Telegram nieosiągalny · wykonano połączenie PSTN
  4. +14s
    Dyżurny — DTMF 1 · łańcuch anulowany

Cztery filary

Jak utrzymujemy alert przy życiu

Cztery kwestie niezawodności, które platforma alertująca musi rozwiązać. Każdy filar wymienia to, co jest wpięte w kod dzisiaj, a nie to, co mamy nadzieję wypuścić.

01 · Nadmiarowość kanałów

Wiele kanałów na krok

Każdy krok eskalacji może odpalić równolegle więcej niż jeden kanał. Jeśli Telegram nie działa, telefon i tak zadzwoni. Jeśli oba zawiodą, jako rezerwa skonfigurowany jest SMS.

  • Tablice kanałów na krok — odpalaj wiele równolegle
  • Kanał rezerwowy dla każdego kanału — gdy Telegram padnie, jego rolę przejmie SMS
  • Rotacja operatorów dla głosu i SMS — żadna pojedyncza awaria nie zatrzymuje wysyłki
  • Stan kanału śledzony w logu audytu dla każdej wysyłki

02 · Polityka ponawiania

Przewidywalne, ograniczone ponowne próby

Najpierw ponawiamy próbę na tym samym kanale, ale nigdy w nieskończoność. Odstępy między próbami są jawne; po wyczerpaniu prób idziemy do następnego kanału.

  • Konfigurowalna liczba prób dla każdego kanału (domyślnie 3 dla głosu, 2 dla Telegrama)
  • Wykładnicze lub liniowe opóźnienie (backoff) dla każdego kanału
  • Idempotencja po (api_key, idempotency_key) — duplikaty zwijają się w jedną wysyłkę
  • Twardy limit dla całego łańcucha — żaden alert nie zadzwoni w nieskończoność

03 · Świadomość potwierdzeń

Łańcuch zatrzymuje się, gdy ktoś weźmie alert na siebie

Potwierdzenie z dowolnego kanału, który dostał alert, anuluje resztę łańcucha. Log audytu zapisuje, kto i kiedy potwierdził.

  • Potwierdzenie przyciskiem w Telegramie, odpowiedzią SMS, DTMF, kliknięciem w e-mailu lub w dashboardzie
  • Resolved-hook ze źródła monitoringu anuluje łańcuch automatycznie
  • Czyste ponowne wysłanie, gdy dyżurny przekaże incydent w trakcie
  • Brak zalegających prób po potwierdzeniu — gwarantowany przez anulowanie kolejki

04 · Dziennik audytu

Strukturalny, przeszukiwalny, eksportowalny

Każda wysyłka, potwierdzenie, eskalacja i rozwiązanie zapisuje linię JSON. Schemat jest stabilny; stare pola zostają, nowe są dodawane bez łamania parserów.

  • JSON Lines dziennik audytu dla każdej firmy
  • Stabilny schemat z polami notification_uuid, channel, status, actor, ip i request_id
  • Eksport CSV dla grupy odbiorców na potrzeby przeglądów SLA
  • Powiązany z logami aplikacji przez request_id

Polityka ponawiania

Co ponawiamy i kiedy przestajemy

Ponowne próby powinny być przewidywalne. Określ liczbę prób, backoff i rezerwowy kanał dla każdego kanału. WardenPoint dostarcza sensowne wartości domyślne, a płatne plany pozwalają je nadpisać.

  • Połączenia głosowe ponawiamy do 3 razy z wykładniczym backoffem, potem przechodzimy na głos w Telegramie
  • Telegram ponawia 2 razy z liniowym backoffem, potem przechodzi na SMS
  • SMS ponawia 2 razy z rotacją dostawców; błąd 5xx operatora przełącza na kolejnego
  • E-mail ponawiamy przy tymczasowych błędach SMTP 4xx; trwałe błędy 5xx kończą próbę, łańcuch idzie dalej
  • Każda decyzja o ponowieniu trafia do logu audytu — ścieżkę da się odtworzyć
config/escalation.phpPHP
# config/escalation.php — retry policy
'retry' => [
'voice_call' => [
'attempts' => 3,
'backoff' => 'exponential',
'fallback_channel' => 'telegram_voice',
],
'telegram_voice' => [
'attempts' => 2,
'backoff' => 'linear',
'fallback_channel' => 'sms',
],
],

Uczciwe liczby

Liczby, do których się stosujemy

Cel dostępności
99.99%

Wewnętrzne SLO publicznego API i warstwy dyspozytorskiej. /status pokazuje rzeczywistą wartość kroczącą.

Mediana opóźnienia API
~20ms

Zmierzona mediana (P50) na publicznym API. Po stronie operatora dochodzi 2–10 s na głos/SMS.

Kanałów na krok
3+

Każdy krok może odpalić dowolną kombinację z ośmiu kanałów równolegle. Bez sztucznego limitu.

Twardy limit ponawiania
Na łańcuch

Łańcuch nie może przekroczyć skonfigurowanego łącznego czasu trwania. Nie dzwonimy w nieskończoność — z założenia.

Wbudowany status

Umieść nasz status na swoim pulpicie

Pokaż stan operacyjny WardenPoint na wewnętrznym wiki, portalu statusowym lub w stopce strony. Jeden tag, bez klucza API, bez procesu budowania — odznaka aktualizuje się co minutę i przechodzi w stan «Operacyjny», gdy odbiorcy nie mogą połączyć się z naszym API.

Pigułkowa odznaka

Podgląd na żywo

Operational
<!-- Pill badge -->
<script
src="https://status.wardenpoint.com/status-embed.js"
data-format="badge"
data-theme="light"
defer></script>

Karta

Podgląd na żywo

Operational99.99% uptime · 90dView status →
<!-- Card with uptime -->
<div id="wp-status"></div>
<script
src="https://status.wardenpoint.com/status-embed.js"
data-target="#wp-status"
data-format="card"
data-theme="auto"
defer></script>
Opcje
data-target — selektor CSS dla elementu kontenera. Opcjonalne; domyślnie renderowane w linii.
 
data-theme — light · dark · auto (podąża za preferowanym schematem kolorów czytelnika).
 
data-format — badge (jedna linia) lub card (z 90-dniową niezawodnością).

FAQ niezawodności

Najczęstsze pytania o niezawodność

99,99% dla publicznego API i warstwy dyspozytorskiej. Strona stanu pokazuje rzeczywistą wartość kroczącą z osi czasu 90 dni.
Plan darmowy

Sprawdź deklarowaną niezawodność własnym testem

Dodaj odbiorcę, ubij Telegrama na telefonie dyżurnego i patrz, jak odpala się rezerwa. Linia w logu audytu opowiada całą historię.

  • Plan darmowy
  • Log audytu dla każdej wysyłki
  • Wbudowana rotacja operatorów