Wyznacz bezpieczne granice samonaprawy

Przywracaj usługę w znanej sytuacji

Samonaprawa automatycznie wykrywa określoną awarię i próbuje wykonać zatwierdzone działanie odzyskiwania. Przykładami mogą być restart uszkodzonego procesu lub wymiana niesprawnej instancji. Działanie musi pasować do awarii i modelu stanu usługi.

Kubernetes może zastępować niesprawne instancje aplikacji i uzgadniać stan z deklaracją. Nie poprawia to błędnej logiki aplikacji ani każdej awarii pamięci masowej. Odzyskiwanie infrastruktury i poprawność oprogramowania wymagają różnych kontroli. Samonaprawa w Kubernetes.

Określ cel przed mechanizmem. Przywrócenie eksportu oznacza poprawne kończenie kwalifikujących się zadań. Działający kontener to tylko jeden z warunków wstępnych.

Oddziel trzy rodzaje zmian

Agent może zaproponować poprawkę po przywróceniu usługi. Propozycja jest nową zmianą oprogramowania. Nie może dziedziczyć nieograniczonych uprawnień od kontrolera odzyskiwania.

Kontroler nie może też edytować własnych kryteriów sukcesu, gdy kontrola nie przechodzi. Inaczej system może raportować poprawę bez poprawy usługi.

Zapisz politykę odzyskiwania przed jej włączeniem

Poniższa polityka jest fikcyjna. Liczby ilustrują wybory projektowe; nie są zalecanymi wartościami domyślnymi.

Użyj tożsamości z minimalnymi uprawnieniami. Zapisuj wersję polityki, dowód wyzwalacza, działanie, zasób i wynik. Zapewnij niezależny sposób wyłączenia kontrolera. Wyznacz człowieka odpowiedzialnego za odebranie eskalacji.

Testuj ścieżki błędów i udane odzyskiwanie

Ponowienie może powtórzyć skutek uboczny. Worker może zapisać plik i zatrzymać się przed potwierdzeniem zadania. Zweryfikuj idempotencję przed zezwoleniem na kolejne wykonanie. Zobacz przykład awarii cloud native.

Ponowienia mogą też zwiększyć przeciążenie zależności. Stosuj ograniczoną liczbę prób, limity czasu i odpowiednie opóźnienia. Unikaj zsynchronizowanych ponowień we wszystkich instancjach. AWS wyjaśnia, dlaczego narastające opóźnienia i losowe odchylenia pomagają ograniczyć ten efekt. Wytyczne dotyczące ponowień.

Sprawdź fikcyjną politykę w trzech przypadkach. Jeden zatrzymany worker powinien odzyskać sprawność. Awaria bazy danych powinna zablokować powtarzaną wymianę. Niepewny problem integralności powinien zatrzymać automatyzację i wymagać decyzji zespołu reagowania.

Sprawdź też brak telemetrii. Brak heartbeat może oznaczać awarię workera albo ścieżki zbierania danych. Kontroler potrzebuje dowodów wystarczających do działania, a nie wiary w wyjaśnienie AI.

Mierz, czy polityka pomaga

Rejestruj zweryfikowane przywrócenia, nieudane próby, eskalacje, powtórzoną pracę i czas wpływu na użytkowników. Porównaj je z poprzednim sposobem działania w podobnych warunkach.

Zachowaj podstawowy defekt jako zadanie inżynierskie. Wielokrotny restart procesu z wyciekiem pamięci może ograniczyć bieżące skutki, choć wyciek trwa. Przejdź do ciągłego doskonalenia, aby powiązać obserwację z trwałą poprawką.