06 lis 2025·8 min
Jak zbudować aplikację webową do śledzenia incydentów i postmortemów
Praktyczny plan budowy aplikacji webowej do śledzenia incydentów i postmortemów — od workflow przez model danych po UX i metryki.
Praktyczny plan budowy aplikacji webowej do śledzenia incydentów i postmortemów — od workflow przez model danych po UX i metryki.
Zanim naszkicujesz ekrany lub wybierzesz bazę danych, uzgodnij, co zespół rozumie przez aplikację do śledzenia incydentów — i co ma osiągać „zarządzanie postmortemami”. Zespoły często używają tych samych słów inaczej: dla jednego zespołu incydent to każde zgłoszenie klienta; dla innego to tylko awaria Sev-1 z eskalacją on-call.
Zapisz krótką definicję odpowiadającą na:
Ta definicja napędza twój workflow reagowania na incydenty i zapobiega temu, żeby aplikacja stała się zbyt rygorystyczna (nikt jej nie używa) lub zbyt luźna (dane nie są spójne).
Zdecyduj, czym jest postmortem w twojej organizacji: lekka notatka dla każdego incydentu, czy pełne RCA tylko dla zdarzeń wysokiej wagi. Wyraźnie określ, czy celem jest nauka, zgodność, redukcja powtarzalnych incydentów, czy wszystko naraz.
Przydatna zasada: jeśli oczekujesz, że postmortem doprowadzi do zmian, narzędzie musi wspierać śledzenie action items, a nie tylko przechowywanie dokumentów.
Większość zespołów buduje taką aplikację, żeby naprawić kilka powtarzających się bolączek:
Trzymaj listę zwięzłą. Każda funkcja, którą dodajesz, powinna mapować się przynajmniej do jednego z tych problemów.
Wybierz kilka metryk, które możesz mierzyć automatycznie z modelu danych aplikacji:
To stanowi twoje metryki operacyjne i „definicję ukończenia” dla pierwszego wydania.
Ta sama aplikacja obsługuje różne role w operacjach on-call:
Jeżeli zaprojektujesz pod wszystkich od razu, zbudujesz zagracone UI. Zamiast tego wybierz głównego użytkownika dla v1 — i upewnij się, że pozostali mogą dostać to, czego potrzebują, przez dostosowane widoki, dashboardy i uprawnienia później.
Jasny workflow zapobiega dwóm powszechnym błędom: incydentom, które zamarzają, bo nikt nie wie „co dalej”, i incydentom, które wyglądają na „zamknięte”, ale nie generują nauki. Zacznij od odwzorowania cyklu życia end-to-end, a potem przypnij role i uprawnienia do każdego kroku.
Większość zespołów podąża prostą ścieżką: wykrycie → triage → złagodzenie → rozwiązanie → nauka. Twoja aplikacja powinna to odzwierciedlać kilkoma przewidywalnymi krokami, a nie niekończącym się menu opcji.
Zdefiniuj, co „zrobione” oznacza na każdym etapie. Np. złagodzenie może znaczyć, że wpływ na klienta został zatrzymany, nawet jeśli przyczyna nie jest jeszcze znana.
Utrzymuj role jawne, żeby ludzie mogli działać bez czekania na spotkania:
Twoje UI powinno pokazywać „aktualnego właściciela”, a workflow powinien wspierać delegowanie (przypisywanie, dodawanie responderów, rotację commendera).
Wybierz wymagane stany i dozwolone przejścia, np. Investigating → Mitigated → Resolved. Dodaj zabezpieczenia:
Oddziel aktualizacje wewnętrzne (szybkie, taktyczne, mogą być niechlujne) od aktualizacji dla interesariuszy (jasne, z datą i godziną, opracowane). Zbuduj dwa strumienie aktualizacji z różnymi szablonami, widocznością i zasadami zatwierdzania — często tylko commander publikuje komunikaty dla interesariuszy.
Dobre narzędzie do incydentów wydaje się „proste” w UI, ponieważ model danych pod spodem jest spójny. Zanim zbudujesz ekrany, zdecyduj, jakie obiekty istnieją, jak się łączą i co musi być historycznie dokładne.
Zacznij od niewielkiego zestawu obiektów pierwszej klasy:
Większość relacji to one-to-many:
Używaj stabilnych identyfikatorów (UUID) dla incydentów i zdarzeń. Ludzie nadal potrzebują przyjaznego klucza jak INC-2025-0042, który możesz generować z sekwencji.
Zamodeluj je wcześnie, aby móc filtrować, wyszukiwać i raportować:
Dane incydentów są wrażliwe i często przeglądane później. Traktuj edycje jako dane — nie nadpisuj:
Taka struktura ułatwia późniejsze funkcje — wyszukiwanie, metryki i uprawnienia — bez konieczności przebudowy.
Kiedy coś psuje się, zadaniem aplikacji jest zmniejszyć ilość pisania i zwiększyć jasność. Ta sekcja opisuje „ścieżkę zapisu”: jak ludzie tworzą incydent, aktualizują go i rekonstruują później, co się wydarzyło.
Utrzymaj formularz krótki — tak aby dało się go wypełnić podczas rozwiązywania problemu. Dobry zestaw domyślnych wymaganych pól to:
Wszystko inne powinno być opcjonalne podczas tworzenia (wpływ, linki do ticketów, podejrzana przyczyna). Użyj inteligentnych domyślnych: ustaw start time na „teraz”, wstępnie wybierz on-call team użytkownika i zaoferuj jednoprzeciśnięciowe „Utwórz i otwórz pokój incydentu”.
UI aktualizacji powinno być zoptymalizowane pod częste, małe zmiany. Zapewnij kompaktowy panel aktualizacji z:
Uczyń aktualizacje dopisywalnymi: każda aktualizacja staje się wpisem z czasem, a nie nadpisuje poprzedniego tekstu.
Zbuduj oś czasu mieszającą:
To tworzy wiarygodną narrację bez zmuszania ludzi do pamiętania o zapisie każdego kliknięcia.
Podczas awarii wiele aktualizacji odbywa się z telefonu. Priorytetyzuj szybki, niskofrakcyjny ekran: duże cele dotykowe, jedna przewijana strona, szkice offline i jednoprzeciśnięciowe akcje jak „Opublikuj aktualizację” i „Kopiuj link do incydentu”.
Severity to „szybki wybierak” reagowania: mówi ludziom, jak pilnie działać, jak szeroko komunikować i jakie kompromisy są akceptowalne.
Unikaj nieprecyzyjnych etykiet typu „wysoki/średni/niski”. Spraw, by każdy poziom severity mapował do jasnych oczekiwań operacyjnych — zwłaszcza czasu reakcji i częstotliwości komunikacji.
Na przykład:
Wyświetlaj te zasady w UI tam, gdzie wybiera się severity, żeby responderzy nie musieli szukać dokumentacji.
Checklisty zmniejszają obciążenie poznawcze w stresie. Trzymaj je krótkie, wykonawcze i powiązane z rolami.
Użyteczny wzorzec to kilka sekcji:
Oznaczaj elementy checklisty czasem i autorem — niech staną się częścią rekordu incydentu.
Incydenty rzadko żyją w jednym narzędziu. Aplikacja powinna pozwalać responderom dołączać linki do:
Preferuj „typowane” linki (np. Runbook, Ticket) tak, aby dało się je później filtrować.
Jeśli organizacja śledzi cele niezawodności, dodaj lekkie pola jak SLO affected (tak/nie), szacowany burn error budget i ryzyko naruszenia SLA. Trzymaj je opcjonalnymi — ale łatwymi do wypełnienia podczas lub tuż po incydencie, gdy szczegóły są najświeższe.
Dobry postmortem jest łatwy do rozpoczęcia, trudny do zapomnienia i spójny między zespołami. Najprościej osiągnąć to przez domyślny szablon (z minimalną liczbą wymaganych pól) i autoprefill z rekordu incydentu, żeby ludzie myśleli, a nie przepisywali.
Wbudowany szablon powinien równoważyć strukturę i elastyczność:
Zrób pole „Root cause” opcjonalnym na początku, jeśli chcesz szybszej publikacji, ale wymagaj go przed finalnym zatwierdzeniem.
Postmortem nie powinien być osobnym dokumentem latającym gdzieś. Gdy postmortem jest tworzony, automatycznie dołącz:
Użyj tego do wstępnego wypełnienia sekcji postmortemu. Np. blok „Wpływ” może zacząć się od czasów start/stop i bieżącego severity, a „Co zrobiliśmy” może być wypełnione wpisami z osi czasu.
Dodaj lekki workflow, aby postmortemy nie ugrzęzły:
Na każdym kroku rejestruj notatki decyzyjne: co zmieniono, dlaczego i kto zatwierdził. To zapobiega „cichym edycjom” i ułatwia audyt i przeglądy naukowe.
Jeśli chcesz utrzymać UI proste, traktuj przeglądy jak komentarze z jasnymi rezultatami (Zatwierdź / Poproś o zmiany) i przechowuj końcowe zatwierdzenie jako niezmienny zapis.
Dla zespołów, które tego potrzebują, powiąż stan „Published” z workflowem aktualizacji statusu (zobacz /blog/integrations-status-updates) bez ręcznego kopiowania treści.
Postmortemy redukują przyszłe incydenty tylko wtedy, gdy prace naprawcze faktycznie się wykonają. Traktuj action items jako obiekty pierwszej klasy w aplikacji — nie akapit na końcu dokumentu.
Każdy action item powinien mieć spójne pola, aby można go było śledzić i mierzyć:
Dodaj drobną, użyteczną metadanych: tagi (np. „monitoring”, „dokumentacja”), komponent/usługa i pole „utworzone z” (ID incydentu i ID postmortemu).
Nie zamykaj action items wewnątrz jednej strony postmortemu. Zapewnij:
To zmienia follow-upy w kolejkę operacyjną, a nie rozproszone notatki.
Część zadań się powtarza (kwartalne game dayy, przeglądy runbooków). Wspieraj szablon cykliczny, który generuje nowe pozycje według harmonogramu, przy zachowaniu możliwości śledzenia każdej wystąpienia indywidualnie.
Jeśli zespoły już używają innego narzędzia do zarządzania zadaniami, pozwól, by action item zawierał odniesienie zewnętrzne (link i ID), zachowując twoją aplikację jako źródło powiązań incydentu i weryfikacji.
Zbuduj lekkie przypomnienia: powiadamiaj właścicieli przed terminem, oznaczaj przeterminowane pozycje dla lidera zespołu i pokaż wzorce chronicznych opóźnień w raportach. Trzymaj reguły konfigurowalne, by zespoły mogły dopasować je do swoich realiów on-call.
Incydenty i postmortemy często zawierają wrażliwe informacje — identyfikatory klientów, wewnętrzne IP, ustalenia bezpieczeństwa lub problemy z dostawcami. Jasne reguły dostępu utrzymują narzędzie użyteczne do współpracy, nie zamieniając go w źródło wycieków danych.
Zacznij od małego, zrozumiałego zestawu ról:
Jeśli masz wiele zespołów, rozważ scope’owanie ról po usłudze/zespołach (np. „Payments Editors”) zamiast szerokich globalnych uprawnień.
Skategoryzuj treści wcześniej, zanim ludzie przyzwyczają się do złych praktyk:
Praktyczny wzorzec to oznaczanie sekcji jako Internal lub Shareable i egzekwowanie tego przy eksportach i publikacjach. Incydenty związane z bezpieczeństwem mogą wymagać oddzielnego typu z ostrzejszymi domyślnymi ustawieniami.
Dla każdej zmiany w incydentach i postmortemach zapisuj: kto zmienił, co zmienił i kiedy. Uwzględniaj edycje severity, znaczników czasu, wpływu i ostatecznych zatwierdzeń. Zrób logi audytu przeszukiwalnymi i nieedytowalnymi.
Wspieraj silne uwierzytelnianie: email + MFA lub magic link, i dodaj SSO (SAML/OIDC), jeśli użytkownicy tego oczekują. Używaj krótkotrwałych sesji, bezpiecznych ciasteczek, ochrony przed CSRF i automatycznego unieważniania sesji przy zmianach ról.
Dla dodatkowych kwestii rolloutowych zobacz /blog/testing-rollout-continuous-improvement.
Gdy incydent jest aktywny, ludzie skanują — nie czytają. UX powinien sprawić, że bieżący stan będzie oczywisty w kilka sekund, a responderzy będą mogli zagłębić się w szczegóły bez zagubienia.
Zacznij od trzech ekranów, które obejmują większość przepływów:
Prosta zasada: strona szczegółów powinna odpowiadać na „Co się teraz dzieje?” na górze i „Jak tu doszliśmy?” poniżej.
Incydenty szybko się kumulują, więc zapewnij szybkie i wyrozumiałe odkrywanie:
Oferuj zapisane widoki typu Moje otwarte incydenty lub Sev-1 w tym tygodniu, aby inżynier on-call nie musiał odtwarzać filtrów co zmianę.
Używaj spójnych, bezpiecznych dla kolorów badge w całej aplikacji (unikaj subtelnych odcieni, które są trudne do rozróżnienia pod presją). Utrzymaj tę samą słownictwo statusów wszędzie: na liście, w nagłówku szczegółów i w eventach osi czasu.
W skrócie, responderzy powinni od razu widzieć:
Priorytetyzuj skanowalność:
Projektuj z myślą o najgorszym momencie: jeśli ktoś jest niewyspany i korzysta z telefonu, UI i tak powinno prowadzić do właściwej akcji szybko.
Integracje zamieniają tracker incydentów z „miejsca do pisania notatek” w system, w którym zespół faktycznie prowadzi incydenty. Zacznij od listy systemów, które musisz podłączyć: monitoring/observability (PagerDuty/Opsgenie, Datadog, CloudWatch), czat (Slack/Teams), email, ticketing (Jira/ServiceNow) i status page.
Większość zespołów kończy z mieszanką:
Alerty są głośne, ponawiane i często przychodzą nie w kolejności. Zdefiniuj stabilny idempotency key dla zdarzenia dostawcy (np. provider + alert_id + occurrence_id) i przechowuj go z unikalnym ograniczeniem. Dla deduplikacji ustal reguły typu „ta sama usługa + ten sam sygnatur w ciągu 15 minut” powinny dopisać się do istniejącego incydentu zamiast tworzyć nowy.
Bądź jawny, co twoja aplikacja przejmuje, a co pozostaje w narzędziu źródłowym:
Gdy integracja zawiedzie, degraduj łagodnie: kolejkowanie prób, wyświetl ostrzeżenie na incydencie („publikacja na Slack opóźniona”) i zawsze pozwalaj operatorom działać ręcznie.
Traktuj aktualizacje statusu jako wynik pierwszej klasy: strukturalna akcja „Update” w UI powinna móc opublikować do czatu, dopisać do osi czasu incydentu i opcjonalnie zsynchronizować się ze stroną statusu — bez każdorazowego przepisywania tej samej wiadomości przez respondera.
Twoje narzędzie do incydentów to system „na czas awarii”, więc faworyzuj prostotę i niezawodność nad nowością. Najlepszy stack to zwykle taki, który zespół potrafi zbudować, debugować i obsługiwać o 2 w nocy z pewnością.
Zacznij od tego, co inżynierowie już wdrażają. Popularny framework webowy (Rails, Django, Laravel, Spring, Express/Nest, ASP.NET) to zwykle bezpieczniejszy wybór niż nowy framework znany tylko jednej osobie.
Do przechowywania danych relacyjna baza (PostgreSQL/MySQL) dobrze pasuje do rekordów incydentów: incidents, updates, participants, action items i postmortems korzystają z transakcji i jasnych relacji. Dodaj Redis tylko, jeśli naprawdę potrzebujesz cache’u, kolejek lub ephemeral locks.
Hosting może być tak prosty, jak zarządzana platforma (Render/Fly/Heroku-like) lub twój istniejący cloud (AWS/GCP/Azure). Preferuj zarządzane bazy i backupy, jeśli to możliwe.
Aktywne incydenty lepiej wyglądają z real-time, ale nie zawsze potrzebujesz websocketów od dnia pierwszego.
Praktyczne podejście: zaprojektuj API/wydarzenia tak, abyś mógł zacząć od pollingu i potem dokładać websockety bez przepisywania UI.
Jeśli ta aplikacja zawiedzie podczas incydentu, sama stanie się incydentem. Dodaj:
Traktuj to jak system produkcyjny:
Jeśli chcesz zweryfikować workflow i ekrany przed inwestycją w pełny build, podejście vibe-coding może się sprawdzić: użyj narzędzia takiego jak Koder.ai do wygenerowania działającego prototypu z szczegółowej specyfikacji w czacie, a potem iteruj z responderami podczas tabletop exercises. Ponieważ Koder.ai potrafi wygenerować rzeczywiste frontendy React z backendem Go + PostgreSQL (i wspiera eksport źródeł), możesz potraktować wczesne wersje jako „wyrzucalne prototypy” lub punkt startowy do utwardzenia — bez utraty wniosków z symulacji.
Zacznij od zapisania konkretnej definicji, na którą zgadza się organizacja:
Ta definicja powinna mapować się bezpośrednio na stany workflow i wymagane pola, dzięki czemu dane pozostaną spójne, a jednocześnie formularz nie stanie się uciążliwy.
Traktuj postmortemy jako workflow, nie tylko dokument:
Jeśli oczekujesz zmian, potrzebujesz śledzenia zadań i przypomnień — nie wystarczy samo przechowywanie dokumentów.
Praktyczny zestaw funkcji v1 to:
Pomiń zaawansowaną automatyzację, dopóki te przepływy nie działają płynnie pod presją.
Użyj niewielkiej liczby przewidywalnych etapów zgodnych z realnym sposobem pracy zespołów:
Zdefiniuj „zakończenie” dla każdego etapu, a potem dodaj zabezpieczenia:
To zapobiega blokowaniu incydentów i podnosi jakość późniejszej analizy.
Modeluj kilka jasnych ról i powiąż je z uprawnieniami:
Uczyń aktualnego właściciela/commendera jednoznacznie widocznym w UI i pozwól na delegowanie (przypisz ponownie, rotuj commendera).
Utrzymaj model danych mały, ale uporządkowany:
Użyj stabilnych identyfikatorów (UUID) plus przyjazny klucz dla ludzi (np. INC-2025-0042). Traktuj edycje jako historię z created_at/created_by i audytem zmian.
Oddziel strumienie i stosuj różne zasady widoczności:
Zaimplementuj różne szablony/widoczności i przechowuj oba rodzaje w rekordzie incydentu, żeby rekonstruować decyzje bez wycieku wrażliwych informacji.
Zdefiniuj poziomy severity z jasnymi oczekiwaniami (pilność reakcji i częstotliwość komunikacji). Na przykład:
Wyświetlaj zasady w UI tam, gdzie wybiera się severity, aby responderzy nie musieli szukać dokumentacji podczas awarii.
Traktuj action items jako ustrukturyzowane rekordy, a nie blok tekstu:
Następnie zapewnij globalne widoki (przeterminowane, na ten tydzień, wg właściciela/usługi) i lekkie przypomnienia/escalacje, aby zadania nie ginęły po przeglądzie.
Użyj kluczy idempotencyjnych specyficznych dla dostawcy i reguł deduplikacji:
provider + alert_id + occurrence_idZawsze pozostaw opcję ręcznego powiązania, gdy API lub integracje zawodzą.