Sprawdzone przykłady dla IncidentRelay v2.3.1, sprawdzone . Poniższe nazwy, identyfikatory i czasy mają charakter ilustracyjny; Sprawdź je we wdrożeniu testowym przed użyciem poświadczeń produkcyjnych.
Przykład biznesowy · Konfiguracja · Przykład praktyczny · Kontrola akceptacji · Ograniczenia i tryby awarii
Przykład biznesowy: jedna nocna kopia zapasowa nigdy się nie kończy
Przykładowy scenariusz, a nie studium przypadku klienta. Poniższe dane to sugestie dotyczące pilotażu, a nie zmierzone oszczędności lub stwierdzenie, że IR obejmuje każdy panel raportowania.
Sytuacja i ryzyko. Firma tworzy kopię zapasową swojej bazy danych zamówień na dwóch serwerach przed rozpoczęciem dnia roboczego. Jedno zadanie zatrzymuje się cicho; drugiemu się to udaje. Pojedynczy wspólny sygnał sukcesu zakryłby tę lukę. Ryzyko biznesowe polega na odkryciu starego lub brakującego punktu przywracania tylko wtedy, gdy konieczne jest jego przywrócenie.
Przepływ pracy w środowisku IR. Określ termin zakończenia i śledź każdy oczekiwany serwer osobno. Host wysyła sygnał pulsu dopiero po zakończeniu sprawdzania zadania i powodzenia. Brakujące zakończenie powoduje utworzenie zaległego alertu kierowanego do obiektu odpowiadającego platformy z zapasową ścieżką eskalacji. Inżynier sprawdza lub ponownie uruchamia zadanie i zapisuje wynik.
Korzyści operacyjne do sprawdzenia. Zamień cichą awarię zaplanowanego zadania w zadanie własne przed następną zmianą biznesową. Ten sam wzorzec może dotyczyć zaplanowanego eksportu lub zadania wsadowego, pod warunkiem, że sygnał jego zakończenia rzeczywiście oznacza sukces.
Co mierzyć. Śledź niedotrzymane terminy na serwer, czas od terminu do potwierdzenia i wiek ostatniej zweryfikowanej kopii zapasowej. Zachowaj wyniki weryfikacji kopii zapasowych i wyników przywracania w systemie kopii zapasowych lub raporcie operacyjnym; nie wnioskuj ich na podstawie zielonego bicia serca.
Granica. Uderzenie serca potwierdza, że dotarł sygnał, a nie, że można przywrócić dane. Nie gwarantuje punktu odzyskiwania ani czasu odzyskiwania. Testuj przywracanie niezależnie i monitoruj sam IR spoza tej samej domeny awarii.
Traktuj system przywoławczy jako usługę, którą obsługujesz
Rozważmy zespół zajmujący się platformą, który jest właścicielem klastra produkcyjnego i conocnych kopii zapasowych baz danych. Chce, aby IR znajdował się w pobliżu stosu monitorowania, ale to także czyni zespół odpowiedzialnym za system, który go budzi. Nazwij właściciela usługi internetowej, harmonogramu, bazy danych, wpisów tajnych i procedury odzyskiwania.
Podczas konfiguracji Docker wydania usługi internetowe i program planujący działają oddzielnie. Po wykonaniu instrukcji wdrażania w środowisku testowym przejrzyj je na stronie sprawdzania wersji:
docker compose ps
docker compose logs --tail=50 incidentrelay
docker compose logs --tail=50 incidentrelay-schedulerProces sieciowy akceptuje przychodzące alerty; harmonogram obsługuje przypomnienia, eskalacje i zadania okresowe. Nie uruchamiaj harmonogramu w każdym procesie internetowym. Działająca strona logowania nie dowodzi, że eskalacja czasowa jest uruchomiona.
Wykryj brakującą kopię zapasową na jednym hoście
Utwórz puls o zaplanowanej realizacji, wysyłany codziennie o godzinie 03:00 czasu UTC, dołączony do trasy, której źródłem jest heartbeat. Włącz śledzenie instancji; w przypadku floty stałej użyj statycznych oczekiwanych instancji, takich jak db-1 i db-2. Dołącz rotację platformy lub zasady i kanały testowe.
Po zakończeniu tworzenia kopii zapasowej hosta i sprawdzeniu powodzenia wyślij tę treść do POST /api/heartbeats/ping/HEARTBEAT_TOKEN z typem zawartości JSON. Użyj tajnego adresu URL tego pulsu, a nie tokena trasy ani tokena administracyjnego API.
{
"status": "completed",
"instance": "db-1",
"payload": {
"job": "nightly-database-backup"
}
}Wyślij odrębną wartość instancji z każdego hosta. Bez śledzenia instancji pomyślne polecenie ping z jednego serwera może ukryć brakującą kopię zapasową innego serwera. Nie wysyłaj bezwarunkowego sygnału ping o powodzeniu z programu obsługi czyszczenia powłoki po nieudanym zadaniu. Redaguj tajne adresy URL pingów z dzienników proxy i zadań.
Błąd testu, nie tylko podczas uruchamiania
- Wyślij polecenie ping do obu oczekiwanych instancji, a następnie celowo pomiń jedną w krótkim harmonogramie testów. Oczekuj zaległego alertu dla tej instancji, dopóki sprawna instancja pozostanie OK.
- Wznów brakującą instancję. Jeśli włączone jest automatyczne rozwiązywanie, sprawdź, czy zaległy alert został rozwiązany bez rozwiązywania awarii innej instancji.
- Zatrzymaj harmonogram tylko we wdrożeniu testowym. Obserwuj wpływ na pracę czasową i udowodnij, że niezależny monitor to zauważa; następnie przywróć go i sprawdź przetwarzanie.
- Przywróć bazę danych, konfigurację i wymagane klucze tajne w izolowanym środowisku z zablokowanymi powiadomieniami wychodzącymi. Przed zezwoleniem na dostawę przejrzyj stare grupy wyzwalania, aby ćwiczenie przywracania nie mogło wywołać stron odpowiadających za produkcję.
Ping zakończony sukcesem nie jest testem przywracania
Bicie serca wykrywa brakujące sygnały; nie są to aktywne sondy HTTP/TCP i nie mogą udowodnić, że kopia zapasowa jest użyteczna. IR nie może również wiarygodnie powiadomić Cię o całkowitej awarii. Zachowaj zewnętrzną kontrolę dostępności i oddzielną ścieżkę kontaktu poza tą samą domeną awarii.
Self-hosting nie usuwa zależności od czatu, poczty e-mail, głosu ani sieci. Zdecyduj, która baza danych i model wdrożenia odpowiadają obciążeniu, przypnij testowaną wersję i przetestuj aktualizacje i wycofywanie zmian. Te przykłady nie ustanawiają wysokiej dostępności ani gwarancji przepustowości.
Ustaw opcję przechowywania celowo: rozwiązana historia alertów jest domyślnie przechowywana przez czas nieokreślony. Czyszczenie może również usunąć powiązane komentarze i zapisy dostaw, ale niekoniecznie zmniejsza plik bazy danych. Przechowywanie nie zastępuje tworzenia kopii zapasowych.