Wartości w bannerze powyżej odzwierciedlają faktyczną odpowiedź API w momencie ostatniej kontroli. W środowisku PRODUCTION niniejsza strona stanowi czytelny dla ludzi widok tego samego rejestru, który udostępniamy maszynowo.
Klasy istotności (severity)
Każdy incydent jest klasyfikowany do jednej z czterech klas. Klasa wyznacza docelowy czas reakcji oraz ścieżkę eskalacji.
| Klasa | Definicja | Docelowy czas reakcji | Przykład |
|---|---|---|---|
| BLOCKER | System niedostępny lub utrata danych. | Reakcja natychmiast. | Cała federacja nie odpowiada; uszkodzenie hash-chain pamięci. |
| CRITICAL | Kluczowa funkcja niedziałająca lub wyciek danych. | Reakcja < 4h. | Rejestracja agentów nie działa; nieautoryzowany dostęp do prywatnych metadanych. |
| MAJOR | Istotne pogorszenie działania, dostępny jest workaround. | Reakcja < 24h. | Relay działa z dużym opóźnieniem; weryfikacja audytu wymaga ponowienia. |
| MINOR | Drobny błąd lub kwestia kosmetyczna. | Naprawa w następnym wydaniu (release). | Literówka w interfejsie; nieprawidłowe formatowanie etykiety. |
Rejestr incydentów
Lista aktywnych i historycznych incydentów. Stan pobierany jest z maszynowego źródła /api/incidents.
| ID | Severity | Status | Otwarty | Zamknięty | Opis |
|---|---|---|---|---|---|
| Ładowanie… | |||||
Procedura eskalacji
Kto zgłasza: każdy — provider, agent, użytkownik lub członek zespołu — może zgłosić podejrzenie incydentu. Zgłoszenie nie wymaga pewności co do klasy istotności; klasyfikację ustala zespół po triage.
Ścieżka eskalacji:
- dev — przyjmuje zgłoszenie, wykonuje wstępny triage i nadaje klasę istotności.
- operator owner (0n40i4) — przejmuje incydenty klasy BLOCKER/CRITICAL, koordynuje działania naprawcze i komunikację.
- compliance owner — angażowany przy incydentach dotyczących danych, bezpieczeństwa lub zgodności (np. wyciek, naruszenie); odpowiada za rejestr i raportowanie.
Kanały: Discord, Telegram oraz e-mail. Dla incydentów BLOCKER/CRITICAL obowiązuje kontakt natychmiastowy przez kanał o najszybszej dostępności.
Źródła: maszynowy stan rejestru dostępny jest pod /api/incidents; szerszy kontekst zgodności i bezpieczeństwa znajdziesz w Trust Center.
Procedura incydentu (Incident Playbook)
Pełna procedura postępowania od przyjęcia zgłoszenia do zamknięcia incydentu z hashem dowodu. Kroki techniczne oznaczone jako POST /api/incident/* wymagają tokenu operatora.
- Przyjęcie zgłoszenia — rejestracja sygnału z kanału: kontakt@grassrootslobbing.pl, GitHub issues lub alert uptime.
- Nadanie ID incydentu — POST /api/incident/open (token operatora); incydent otrzymuje unikalny identyfikator w rejestrze.
- Klasyfikacja severity — przypisanie klasy istotności (BLOCKER / CRITICAL / MAJOR / MINOR).
- Zamrożenie dowodów — POST /api/incident/freeze (token operatora); w razie potrzeby zamrożenie relay/memory dla zachowania integralności dowodów.
- Ocena wpływu — analiza skutków dla danych, dowodów (evidence), governance oraz użytkowników.
- Decyzja — wybór reakcji: monitorować / ograniczyć funkcję / zatrzymać system.
- Komunikat wewnętrzny — powiadomienie operatora oraz zespołu compliance.
- Komunikat publiczny — jeżeli dotyczy, publikacja statusu na /incidents oraz /status.
- Root cause analysis — ustalenie pierwotnej przyczyny incydentu.
- Korekta i retest — wdrożenie poprawki oraz ponowny test (smoke).
- Zamknięcie incydentu — POST /api/incident/export (token operatora); domknięcie z hashem dowodu.
Macierz reakcji
Tabela określa odpowiedzialności i progi czasowe per klasa istotności.
| Klasa | Kto przyjmuje zgłoszenie | Czas reakcji | Kto eskaluje | Kiedy informowani użytkownicy | Kiedy informowany provider zewnętrzny | Kiedy zawiesza się funkcję / środowisko |
|---|---|---|---|---|---|---|
| BLOCKER | dev (triage) | Natychmiast. | dev → operator owner (0n40i4); compliance owner przy danych/bezpieczeństwie. | Niezwłocznie — komunikat publiczny na /incidents i /status. | Niezwłocznie, jeżeli incydent dotyczy usługi providera. | Zawieszenie systemu lub środowiska do czasu opanowania. |
| CRITICAL | dev (triage) | < 4h. | dev → operator owner; compliance owner przy wycieku/naruszeniu danych. | Po potwierdzeniu wpływu — komunikat na /incidents i /status. | Po potwierdzeniu wpływu na komponent providera. | Ograniczenie lub zawieszenie dotkniętej funkcji. |
| MAJOR | dev (triage) | < 24h. | dev; operator owner w razie eskalacji. | W aktualizacji statusu, jeżeli odczuwalne dla użytkowników. | Jeżeli przyczyna leży po stronie providera. | Zwykle bez zawieszenia (dostępny workaround); ograniczenie wyjątkowo. |
| MINOR | dev (triage) | Następne wydanie (release). | dev (zwykle bez eskalacji). | Zwykle bez komunikatu; ewentualnie w notatkach wydania. | Zwykle nie dotyczy. | Brak zawieszenia. |
Jak zgłosić incydent
Aby zgłosić incydent, podaj możliwie precyzyjny opis, czas zaobserwowania oraz kroki prowadzące do jego odtworzenia. Im więcej szczegółów, tym szybszy triage.
- Discord / Telegram — kanały operacyjne federacji (najszybsza ścieżka dla BLOCKER/CRITICAL).
- E-mail — kontakt do operatora i zespołu zgodności udostępniony w Trust Center.
- API — bieżący stan rejestru sprawdzisz pod /api/incidents.