CapordiaOpisać wpływ, zanim zaproponujesz przyczynę
Podaj jedno obserwowalne zdanie: niektóre prace nie generują już wyników, autoryzowany dostęp jest odrzucany lub eksportu nie można już odczytać. Określ dotknięty zakres i to, co nadal działa. „Serwer jest zepsuty” szybko staje się zbyt szerokim wnioskiem, gdy zawodzi tylko jedna ścieżka wyjściowa. Policz wyniki zaakceptowane, niekompletne i nierozpoczęte, używając wykluczających się kategorii.
Wyznacz osobę odpowiedzialną za koordynację i osobę uprawnioną do interwencji. Przewodnik zarządzania incydentami Google SRE rozróżnia koordynację od operacji i komunikacji. W małym zespole jedna osoba może pełnić kilka ról, ale każdy musi wiedzieć, kto decyduje. Ustal wewnętrzny termin następnej aktualizacji; ta organizacja nie tworzy żadnego gwarantowanego czasu odpowiedzi dostawcy.
Zachować chronologię, która oddziela fakty
Odnotuj ostatnią znaną poprawną sytuację, pierwszy objaw i zmiany, które nastąpiły pomiędzy nimi. Podaj strefę czasową i źródło każdej godziny: dziennik, bezpośrednia obserwacja lub wspomnienie do potwierdzenia. Data skopiowana ze zrzutu ekranu niekoniecznie ma ten sam układ odniesienia co dziennik aplikacji. Jeśli brakuje granicy, zachowaj przedział niepewności, zamiast wymyślać dokładną minutę.
Dla każdego działania zapisz autora, zakres, cel i wynik. „Wykonano restart” jest niekompletne bez wiedzy, którego procesu dotyczył i czy objaw się zmienił. Trzymaj oddzielnie obserwację, hipotezę i decyzję. To rozdzielenie pozwoli odtworzyć, co naprawdę pomogło, i zapobiegnie próbom jednoczesnego stosowania niezgodnych środków przez kilka osób.
Przykład fikcyjny: częściowy eksport, a nie udowodniona awaria GPU
W fikcyjnej komórce „Cartes du rivage” trzeba dostarczyć dwadzieścia dokumentów. Czternaście wyników zostało otwartych i zaakceptowanych, cztery zadania zgłaszają odmowę zapisu, a dwa wciąż czekają na uruchomienie. Sześć wyników nie jest więc jeszcze gotowych do dostarczenia, ale błędem byłoby ogłaszać, że dwadzieścia wyników przepadło. Ten przykład nie opisuje żadnego rzeczywistego incydentu ani serwera Capordia.
Poniższa chronologia prowadzi do wniosku, że należy zlecić ukierunkowane sprawdzenie ścieżki wyjściowej. Nie dowodzi jeszcze przyczyny: bliska w czasie zmiana może być związana z objawem, nie wyjaśniając go. Zespół zachowuje czternaście zaakceptowanych wyników i wstrzymuje jedynie nowe zgłoszenia, których to dotyczy. Godziny są fikcyjne i należą do tej samej strefy czasowej, wybranej, aby uniknąć niejednoznaczności w odczycie.
| Godzina | Zarejestrowane zdarzenie | Dopuszczalna interpretacja |
|---|---|---|
| 9:40 | Ostatni wynik otwarty pomyślnie | Znana granica działania |
| 9:42 | Zmieniona lokalizacja wyjściowa | Zmiana do zbadania |
| 9:43 | Zarejestrowana pierwsza odmowa zapisu | Zaobserwowany początek objawu |
| 9:48 | Wstrzymane nowe zgłoszenia, których to dotyczy | Działanie ograniczające skutki |
| 10:05 | Ta sama odmowa przy małym fikcyjnym pliku | Mniejsza reprodukcja, przyczyna do potwierdzenia |
Zredukować reprodukcję bez zacierania usterki
Szukaj najmniejszego wejścia, które zachowuje objaw i tę samą istotną ścieżkę: typ pliku, lokalizację wyjściową, tożsamość techniczną lub ustawienie. Zastąp treść biznesową danymi syntetycznymi, gdy tylko jest to możliwe. Jeśli podmiana sprawi, że błąd zniknie, udokumentuj to ograniczenie. Nie przedstawiaj jako wiernej reprodukcji uproszczonego polecenia, które nie przechodzi już przez podejrzaną część.
Działaj metodą weryfikowalnych hipotez. Rozdział o rozwiązywaniu problemów Google SRE zaleca testy pozwalające rozstrzygnąć między przyczynami i przypomina, że instrumentacja lub próby mogą wpływać na system. Notuj więc wynik negatywny równie starannie jak sukces. Unikaj wielokrotnego ponawiania przetwarzania, które publikuje wyniki lub pogarsza stan pamięci masowej; osoba odpowiedzialna najpierw ustala zakres dozwolonego testu.
Przygotować czytelne i oczyszczone dowody
Dokumentacja przekazania zawiera użyteczne wersje, minimalną procedurę, godziny, dokładny komunikat błędu oraz wyciąg z dziennika wokół objawu. Dodaj identyfikator zadania i numer sprawy, której to dotyczy, gdy ułatwia to powiązanie. Pomiń pozostałą część dzienników, jeśli nikt nie potrzebuje jej do zrozumienia sytuacji. Przechowuj oryginały w dozwolonym zakresie zespołu.
OWASP przypomina, że dzienniki nie mogą ujawniać między innymi haseł, tokenów dostępu ani kluczy. Przejrzyj też ścieżki, nazwy plików i argumenty, które mogą zdradzać projekt. Stosuj spójne zamienniki, takie jak PROJEKT_A, zachowując zarazem strukturę niezbędną do diagnozy. Oczyszczony dowód powinien informować, co zostało usunięte; nie może zmieniać rozstrzygającego komunikatu błędu ani usuwać istotnego warunku.
Sformułować wniosek o eskalację, który pozwala działać
Rozpocznij wniosek od wpływu i precyzyjnego pytania: zbadać odmowę dostępu, potwierdzić właściwość alokacji lub pomóc zlokalizować powtarzalną rozbieżność. Dołącz chronologię i oczyszczoną reprodukcję. Wskaż podjęte już działania, te, które niczego nie zmieniły, oraz operacje, których należy unikać. Odbiorca musi móc wiedzieć, czego się od niego oczekuje, bez przeszukiwania zbioru nieopatrzonych komentarzem zrzutów.
W przykładzie wniosek może brzmieć: „Nowo używana ścieżka wyjściowa odmawia zapisu w tożsamości przetwarzania; proszę o zbadanie uprawnień obowiązujących dla tej ścieżki. Czternaście wyników pozostaje zatwierdzonych; cztery zadania zgłosiły odmowę zapisu, a odmowę tę odtworzono na fikcyjnym wejściu.” Ten tekst nie oskarża GPU ani operatora. Przedstawia to, co jest znane, i pozostawia przyczynę otwartą do czasu jej zbadania.
Sprawdzić zwrot przed zamknięciem
Błąd, który już się nie powtarza, nie zawsze wystarcza. Sprawdź pełny wynik z tą samą tożsamością, tymi samymi decydującymi warunkami i zweryfikowanym miejscem docelowym. Następnie skontroluj objęte elementy: czy zaakceptowane już wyniki zostały zachowane, czy częściowe wyniki są odizolowane, a pozostałe zadania prawidłowo zidentyfikowane? Osoba odpowiedzialna za wyniki musi potwierdzić użyteczne wznowienie, odrębnie od powodzenia technicznego polecenia.
Migracja to zorganizowana zmiana przed przeniesieniem pracy; incydent zaczyna się od nieoczekiwanego odchylenia. Jeśli jego rozwiązanie wymaga przeniesienia danych lub wznowienia przerwanego przetwarzania, użyj wtedy istniejącego dossier migracji dla tej operacji. Chronologia incydentu zachowuje powód tej decyzji; nie przepisuje metody przełączenia ani rejestru partii.
Zachować użyteczny wniosek, nawet jeśli przyczyna pozostaje otwarta
Zakończ z finalnym wpływem, wynikiem weryfikacji, przyczyną wykazaną lub wciąż nieznaną oraz podjętymi działaniami. Obejście może przywrócić wynik bez rozwiązania problemu źródłowego: powiedz to jasno i wskaż osobę odpowiedzialną za jego monitorowanie. Brak dowodu nie może stać się „brakiem incydentu”; podobieństwo do dawnego przypadku nie może stać się pewną przyczyną.
Końcowa weryfikacja musi pozwolić innej osobie odróżnić to, co zaobserwowano, od tego, co wypróbowano i co pozostaje do sprawdzenia. Służy ona ulepszeniu procedury, kontroli lub komunikatu błędu, a nie tworzeniu opowieści bez niepewności. Żadna liczba zrzutów ekranu, objętość dziennika czy poziom pilności nie zastąpi tej jakości przekazu.
Pytania przed decyzją
Czy trzeba czekać na poznanie przyczyny, aby zgłosić incydent?
Nie. Zgłoś weryfikowalny wpływ i znany zakres, a następnie wyraźnie oddziel hipotezy. Chronologia i ukierunkowana reprodukcja często pozwalają pomóc, zanim przyczyna zostanie wykazana. Wskaż też działania już podjęte w celu ograniczenia wpływu.
Czy mogę wysłać wszystkie swoje dzienniki, aby zaoszczędzić czas?
Najpierw przygotuj użyteczne fragmenty i zweryfikuj je. Pełne dzienniki mogą zawierać sekrety i dane projektu, nie pomagając w diagnozie. Zachowaj oryginały w autoryzowanym miejscu i wyjaśnij zamiany dokonane w przesłanej wersji.
Kiedy uznać dossier za zamknięte?
Po kontroli oczekiwanego wyniku i wyraźnej decyzji osoby odpowiedzialnej. Odróżnij potwierdzoną naprawę od tymczasowego obejścia. Zamknięcie może zachować nieznaną przyczynę, pod warunkiem wskazania ograniczeń, przeprowadzonej kontroli i działań pozostających otwartymi.