Zarządzaj incydentem od wykrycia do przywrócenia usługi

Ogłoś incydent na podstawie jego wpływu

Incydent to zdarzenie, które zakłóca, pogarsza lub zagraża usłudze na tyle, że wymaga skoordynowanej reakcji. Organizacja określa poziomy powagi i zasady eskalacji. Stosuj je na podstawie wpływu na użytkowników, zagrożonych danych, czasu trwania i zasięgu.

Nie czekaj na pełne wyjaśnienie przyczyny źródłowej przed wezwaniem pomocy. Jasny opis zaobserwowanego wpływu wystarcza do rozpoczęcia koordynacji. Odróżniaj podejrzenie dotyczące bezpieczeństwa od potwierdzonego wniosku.

Przygotuj ścieżkę reagowania przed wydaniem. Zapewnij dostępność kontaktów, procedur dostępu, runbooków i kanałów komunikacji, gdy główna usługa nie działa. Przećwicz tę ścieżkę na fikcyjnym incydencie.

Przypisz odpowiedzialności przed wprowadzaniem kolidujących zmian

Koordynacja incydentu ustala priorytety i zarządza decyzjami. Zespół techniczny analizuje problem i ogranicza skutki. Komunikacja informuje osoby dotknięte zdarzeniem. Google SRE opisuje te zadania jako odrębne role. Małe zespoły mogą łączyć role, ale nadal muszą wykonać całą pracę. Reagowanie na incydenty.

Prowadź jedną wspólną oś czasu. Zapisuj czas, obserwację, działanie, wykonawcę i wynik. Oddzielaj fakty od hipotez. Używaj wspólnej strefy czasowej i oznaczaj niewiarygodne znaczniki czasu.

Przejdź przez fikcyjny incydent

Wszystkie poniższe godziny są w UTC. Organizacja wyznacza koordynatora incydentu, gdy awaria eksportu dotyka wielu klientów.

Przydatny pierwszy komunikat określa dotkniętą funkcję, znany zasięg, podjęte ograniczenia i czas następnej aktualizacji. Nie obiecuje terminu naprawy bez dowodów. Nie umieszczaj rekordów klientów we wspólnym komunikacie.

O 09:10 charakter incydentu się zmienia. Przywrócenie poprawnych eksportów już nie wystarcza. Zespół musi ocenić możliwe ujawnienie, kontrolować dostęp, zabezpieczyć dowody i włączyć właściwych decydentów.

Ograniczaj skutki bez utraty kontroli

Stosuj przetestowane runbooki tam, gdzie pasują. Sprawdź warunki wstępne przed rollbackiem, failoverem lub zmianą danych uwierzytelniających. Poprzednia wersja aplikacji może nie obsługiwać bieżącego schematu bazy danych. Regionalny failover może przenieść te same uszkodzone dane.

Pozwól asystentowi AI porządkować dowody po usunięciu wrażliwych danych lub porównywać hipotezy w zatwierdzonych granicach. Osoby reagujące muszą sprawdzić jego wnioski. Logi i zgłoszenia są niezaufanym wejściem, a nie upoważnieniem do wykonania ich treści.

Dostęp awaryjny powinien mieć zatwierdzony cel, ograniczony czas i zapis audytowy. Pilność nie sprawia, że komenda zaproponowana przez agenta jest poprawna.

Osobno zamknij przywrócenie usługi i działania następcze

Przed ogłoszeniem przywrócenia usługi sprawdź proces użytkownika, integralność danych, granice dostępu i aktualność monitoringu. Zapisz pozostałe ograniczenia. Utrzymuj otwartą analizę bezpieczeństwa, jeśli jej pytania pozostają nierozwiązane.

Następnie zbadaj warunki, które umożliwiły incydent. Przypisz konkretne działania następcze z właścicielem i kryteriami weryfikacji. Przegląd bez szukania winnych dąży do trafnego wyjaśnienia i użytecznych zmian. Nie usuwa odpowiedzialności za wykonanie tych zmian. Praktyka postmortem.

Przejdź do operacji bezpieczeństwa i zamykania pętli informacji zwrotnej.