Pierwsze stabilne wydanie IncidentRelay, systemu do organizacji dyżurów i routingu powiadomień

Po pięciu miesiącach prac rozwojowych opublikowano wydanie projektu IncidentRelay 1.1, rozwijającego otwarty system do organizacji dyżurów, routingu powiadomień i zarządzania incydentami, uruchamianego na własnym serwerze (self-hosted). IncidentRelay 1.1 oznaczono jako pierwsze stabilne wydanie (gałąź 1.0 miała status wersji beta). Projekt jest skierowany do zespołów SRE, DevOps i infrastrukturalnych, które potrzebują lokalnie rozwijanej alternatywy dla usług SaaS do zarządzania dyżurami (on-call management), aplikacji polityk eskalacji i reagowania na incydenty. Kod projektu napisano w Pythonie i udostępniono na licencji MIT.

IncidentRelay przyjmuje zdarzenia z systemów monitorujących, łączy je z usługą, zespołem i rotacją, a następnie dostarcza powiadomienia odpowiedzialnym dyżurnym lub zespołom. W systemie wprowadzono harmonogramy dyżurów, rotacje, nadpisania zmian, potwierdzenie odbioru incydentu, stany ACK/Resolve, przypomnienia, eskalacje, tymczasowe zastępstwa dyżurnych, określanie czasu planowanych prac oraz tłumienie hałaśliwych alertów.

Główną zaletą projektu jest pełna kontrola nad infrastrukturą i logiką routingu. IncidentRelay uruchamia się w swoim środowisku, działa z własną bazą danych i pozwala wyraźnie rozdzielić przychodzące trasy, zespoły, rotacje i kanały dostarczania. Tokeny przychodzące należą do tras, a nie do kanałów, przez co łatwiej zrozumieć, które zewnętrzne źródło ma prawo wysyłać zdarzenia do konkretnego zespołu.

W IncidentRelay obsługiwane są zdarzenia z Prometheus Alertmanager, Grafana Alerting, Zabbix, Sentry, LibreNMS, RMON, AWS SNS/CloudWatch i dowolnych webhooków. Do wysyłania powiadomień przewidziano kanały takie jak Mattermost, Slack, Telegram, Discord, Microsoft Teams, e-mail, webhooki, powiadomienia push w przeglądarkach/PWA oraz dostawcy głosowych połączeń. W Mattermost i Telegram powiadomienia mogą zawierać działania do potwierdzenia i rozwiązania problemu, co pozwala na obsługę incydentu bez przechodzenia do oddzielnego interfejsu.

Projekt można uruchomić za pomocą Docker Compose, pakietu RPM dla dystrybucji podobnych do Red Hat, ręcznie przez systemd, a także w Kubernetes z użyciem Helm chart. Dla małych instalacji można używać SQLite, natomiast dla systemów roboczych i wyższych obciążeń zaleca się PostgreSQL.

W nowej wersji wprowadzono następujące zmiany:

  • Wprowadzono wielopoziomowe rotacje dyżurów z ograniczeniami czasowymi, priorytetami warstw i uwzględnieniem zastępstw czasowych;
  • Dostępny jest kalendarz dyżurów, subskrypcje CalDAV i ICS dla zewnętrznych kalendarzy;
  • Wdrożono polityki eskalacji incydentów z wielostopniowymi łańcuchami podnoszenia poziomu;
  • Dodano grupy powiadomień, grupowanie zdarzeń, opóźnione powiadomienia oraz ręczne łączenie powiązanych alertów;
  • Dostępne są okna do planowania prac oraz „ciche” alerty;
  • Dodano możliwość dodawania komentarzy do alertów;
  • Wprowadzono priorytety incydentów (P1-P5) oraz automatyczne podnoszenie priorytetu w zależności od ważności;
  • Wdrożono katalog usług, zależności usług, SLI/SLO, historię wpływu na pracę systemów (Service Impact History) oraz usługi biznesowe (Business Services);
  • Dostępny jest Explain Trace do analizy trasowania: dlaczego alert trafił lub nie trafił do zespołu, został zgrupowany, stłumiony lub wysłany do konkretnego kanału;
  • Dodano kontrole (Heartbeat/dead-man-switch) dla watchdog, backup, ETL i innych zadań, gdzie problemem jest brak oczekiwanego sygnału.



Źródło: opennet.ru
Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster