Monitoruj funkcję widoczną dla użytkownika, dodaj wystarczające dowody z zasobów i aplikacji, aby ją diagnozować, i wywołuj powiadomienia tylko dla warunków wymagających terminowego działania człowieka. Połącz każdy alert z właścicielem, pierwszym krokiem i eskalacją. Podczas incydentu koordynuj łagodzenie, chroń dowody i weryfikuj odtwarzanie przez rzeczywistą ścieżkę użytkownika.
Zacznij od funkcji, która ma znaczenie
Serwer odpowiadający na ping nie dowodzi, że jego aplikacja działa. Wybierz reprezentatywną, nieszkodliwą ścieżkę użytkownika, na przykład pobranie publicznej strony lub dostęp do kontrolowanego punktu końcowego testowego. Zdefiniuj, jak wygląda sukces, i unikaj syntetycznych kontroli, które przy każdym uruchomieniu tworzą prawdziwe zamówienia, publikują treści lub wysyłają powiadomienia klientom.
Monitoruj z odpowiedniej perspektywy zewnętrznej, a także wewnątrz aplikacji. Obserwacja zewnętrzna może ujawnić problemy z dostępem lub routingiem, których serwer nie widzi. Pomiary wewnętrzne mogą wyjaśnić, dlaczego ścieżka użytkownika zawiodła. Utrzymuj oba widoki powiązane z funkcją, zamiast zbierać duży pulpit tylko dlatego, że każda metryka jest dostępna.
Wybierz sygnały o wartości diagnostycznej
Wytyczne Google SRE wskazują opóźnienie, ruch, błędy i nasycenie jako użyteczne sygnały dla systemów użytkowych. Użyj ich do opisu zachowania: czasu odpowiedzi, wolumenu żądań, nieudanych żądań i presji na ograniczone zasoby. Wybierz pomiary odpowiednie dla aplikacji, zamiast zakładać, że jedna definicja metryki działa dla witryny, usługi transferu i procesu działającego w tle.
Rozdziel zachowanie udanych i nieudanych żądań tam, gdzie ma to znaczenie, i analizuj wyniki wolnego ogona, a nie tylko średnie. Dodaj presję pamięci, miejsce na dysku, głębokość kolejki lub limity specyficzne dla aplikacji, gdy wyjaśniają usługę. Wysoki odczyt CPU może być normalny podczas użytecznej pracy wsadowej; efekt widoczny dla użytkownika decyduje o tym, czy potrzebne jest natychmiastowe działanie.
Nadaj każdemu alertowi działanie i właściciela
Alert powinien określać dotkniętą funkcję, zaobserwowany warunek i użyteczną pierwszą kontrolę. Przypisz właściciela i ścieżkę eskalacji przed wdrożeniem. Rozróżnij warunki wymagające szybkiej interwencji od pozycji odpowiednich do zaplanowanego przeglądu. Powtarzające się powiadomienia o niskiej wartości uczą operatorów ignorowania systemu i utrudniają rozpoznanie ważnych sygnałów.
Użyj krótkiego przeglądu alertów, aby usunąć niejednoznaczność. Ta przykładowa tabela opisuje potencjalne decyzje dotyczące monitorowania, a nie zakres wsparcia SwissOctet ani zobowiązanie dotyczące dostępności. Progi należy przetestować względem rzeczywistej linii bazowej aplikacji. Uwzględnij warunek odzyskania, aby operator wiedział, kiedy alert został wyczyszczony i co jeszcze wymaga weryfikacji.
| Zaobserwowany warunek | Użyteczna reakcja | Kontekst do uwzględnienia |
|---|---|---|
| Reprezentatywna ścieżka użytkownika kończy się niepowodzeniem | Oceń wpływ i złagodź | Dotknięty punkt końcowy, czas trwania i ostatnia zmiana |
| Dysk zbliża się do zaplanowanego limitu | Przejrzyj wzrost i retencję | Wolumen, tempo wzrostu i bezpieczny zapas |
| Weryfikacja kopii zapasowej kończy się niepowodzeniem | Chroń ścieżkę odzyskiwania | Zadanie, ostatni użyteczny punkt i błąd |
| Opóźnienie rośnie podczas wydania | Sprawdź lub wycofaj zmianę | Linia bazowa, czas wydania i dotknięte żądania |
Przygotuj niewielką strukturę postępowania w incydencie
Proces reagowania powinien być zrozumiały pod presją. Wyznacz koordynatora, osobę zajmującą się pracą techniczną i osobę odpowiedzialną za aktualizacje, gdy incydent jest wystarczająco duży, aby wymagać odrębnych ról. Mały projekt może łączyć role, ale nadal korzysta z jednego jasnego punktu decyzyjnego. Uzgodnij kanał komunikacji, zanim usługa zawiedzie.
Materiały Google dotyczące reagowania na incydenty podkreślają koordynację i podejście skupione najpierw na łagodzeniu skutków. Zastosuj to w skali odpowiedniej dla projektu: ustal wpływ, wybierz bezpieczne działania i unikaj sytuacji, w której kilku operatorów wprowadza sprzeczne zmiany. Zapisuj os czasu i decyzje. Szukanie doskonałego wyjaśnienia nie powinno opóźniać bezpiecznego środka, który przywraca dotkniętą funkcję.
Przejdź przez konkretny przypadek degradacji
Wyobraź sobie witrynę, która po wydaniu staje się wolna. Zewnętrzna kontrola pokazuje wydłużony czas ukończenia, a pomiary wewnętrzne pokazują błędy aplikacji i rosnącą pracę bazy danych. Koordynator ogłasza ograniczony incydent, zabezpiecza dowody i przydziela jednej osobie porównanie wydania z linią bazową. Inna osoba przygotowuje przetestowaną ścieżkę wycofania, zamiast wprowadzać niepowiązane zmiany w infrastrukturze.
Jeśli wycofanie jest bezpieczne dla stanu danych aplikacji, użyj go i obserwuj wynik. Jeśli nie jest bezpieczne, wybierz węższe łagodzenie wspierane przez plan operacyjny. Udokumentuj, co się zmieniło i kiedy. Większy VPS lub port może być wart rozważenia później, ale natychmiastowa decyzja powinna odnosić się do dowodów, a nie zakładać, że przyczyną jest rozmiar infrastruktury.
Chroń dowody i zweryfikuj odtwarzanie
Dzienniki operacyjne i notatki o incydentach mogą zawierać adresy, identyfikatory i informacje o klientach. Zbierz to, czego potrzebuje dochodzenie, ogranicz dostęp i nie umieszczaj poświadczeń ani prywatnych tokenów zamówień w udostępnianych raportach. W przypadku podejrzenia incydentu bezpieczeństwa zabezpiecz odpowiednie dowody i postępuj zgodnie z polityką reagowania projektu, zamiast niszczyć informacje przez pośpieszne porządki.
Wytyczne NIST dotyczące reagowania na incydenty umieszczają reagowanie w szerszym zarządzaniu ryzykiem cyberbezpieczeństwa. Odzyskiwanie obejmuje sprawdzenie zamierzonej funkcji i rozwiązanie warunku, który umożliwił incydent. Przetestuj ścieżkę użytkownika, przejrzyj zachowanie zasobów i sprawdź pracę w tle przed zakończeniem reagowania. Sam wyczyszczony alert lub ponownie uruchomiony proces może nie dowodzić pełnego powrotu do użytecznej usługi.
Zamień incydent w mierzalną poprawę
Napisz krótki przegląd wpływu, osu czasu, warunków współprzyczynowych i podjętych działań. Skup się na zmianach, które można zweryfikować: ulepsz kontrolę, popraw uprawnienie, przećwicz wycofanie lub dodaj brakującą zależność odzyskiwania. Przypisz właścicieli i kryteria ukończenia. Unikaj długiej listy niejasnych zamiarów, których nikt później nie potwierdzi jako zrealizowanych.
Podczas wdrażania na SwissOctet zaplanuj monitorowanie i reagowanie jako część działania aplikacji, oddzielnie od wybranej infrastruktury i wszelkich potwierdzonych ustaleń dotyczących zarządzania. Katalog nie ustanawia obsadzonego zespołu reagowania na incydenty ani ciągłych godzin wsparcia. Zdecyduj, kto otrzymuje alerty, kto może działać i co obejmują rzeczywiste warunki usługi, zanim zaczniesz polegać na środowisku produkcyjnym.
Twoja praktyczna lista kontrolna.
- Monitoruj nieszkodliwą, reprezentatywną ścieżkę użytkownika.
- Wybierz sygnały, które wyjaśniają zachowanie aplikacji.
- Nadaj alertom działanie, właściciela i warunek odzyskania.
- Uzgodnij koordynację i eskalację przed incydentem.
- Chroń dowody i zweryfikuj pełne odzyskanie.
- Przypisz testowalne ulepszenia po przeglądzie.
Szczegóły, które mają znaczenie.
Czy monitorowanie czasu działania serwera jest wystarczające?+
Nie. Osiągalna maszyna może hostować zepsutą aplikację. Monitoruj funkcję, od której zależą użytkownicy, i dodaj dowody dotyczące zasobów, aby diagnozować awarie.
Czy każdy próg metryki powinien natychmiast powiadamiać kogoś?+
Nie. Zarezerwuj pilne przerwania dla działań wymagających terminowej uwagi. Skieruj zadania o niższym priorytecie do procesu przeglądu z jasnym właścicielem.
Kiedy incydent jest zakończony?+
Po zweryfikowaniu dotkniętej funkcji i odpowiedniej pracy w tle, obsłużeniu natychmiastowych ryzyk i zapisaniu działań następczych. Sam restart procesu jest niewystarczający.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- Google SRE: Monitorowanie systemów rozproszonych sre.google
- Google SRE Workbook: Reagowanie na incydenty sre.google
- NIST SP 800-61 Rev. 3: Reagowanie na incydenty csrc.nist.gov
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.