Self-healing to zdolność systemu do samodzielnego wykrywania, że coś się zepsuło, i naprawiania tego bez budzenia człowieka o trzeciej w nocy. Zamiast czekać, aż ktoś zauważy padniętą usługę i ręcznie ją podniesie, system sam pilnuje swojego stanu: porównuje stan rzeczywisty z tym, jak powinno być (tzw. desired state), i kiedy wykryje rozbieżność — działa. Restartuje proces, ubija zawieszony kontener, przekierowuje ruch z chorej instancji na zdrową. Klucz to automatyzacja reakcji, nie samego monitoringu.
Jak to działa
Większość mechanizmów self-healing opiera się na pętli kontrolnej: obserwuj → porównaj → koryguj. System ma zdefiniowany stan docelowy (np. „mają działać 3 repliki tej aplikacji”) i nieustannie sprawdza, czy rzeczywistość się zgadza. Jeśli jedna replika padnie, kontroler od razu uruchamia nową. Do wykrywania awarii służą najczęściej health checki — drobne zapytania typu „żyjesz? gotowy na ruch?”, które system wysyła do każdej instancji.
Self-healing załatwia więc głównie awarie przejściowe i pojedyncze: zawieszony proces, wyciek pamięci kończący się OOM, padnięty serwer. To nie magia naprawiająca błąd w kodzie — system po prostu przywraca znany dobry stan.
Przykład z praktyki
Najbardziej kanoniczny przykład to Kubernetes. Definiujesz livenessProbe i readinessProbe w manifeście poda. Jeśli liveness probe kilka razy z rzędu zwróci błąd, kubelet uznaje kontener za martwego i go restartuje. Jeśli padnie cały pod, jego ReplicaSet widzi, że zamiast 3 replik są 2, i automatycznie tworzy brakującą.
Stan zobaczysz tak:
kubectl get pods— w kolumnieRESTARTSrośnie licznik, gdy pod sam się odradza,kubectl describe pod nazwa— w eventach zobaczysz, dlaczego nastąpił restart.
Podobnie działają AWS Auto Scaling Group (zabija i odtwarza niezdrowe EC2) czy systemd z dyrektywą Restart=on-failure dla pojedynczego serwisu na zwykłej maszynie.
Częste błędy i mity
- „Self-healing naprawi mój bug.” Nie. Jeśli aplikacja crashuje przez błąd w kodzie, restart tylko zapętli CrashLoopBackOff — pod pada, wstaje, pada, w kółko.
- Źle ustawione probe’y. Za agresywny liveness probe ubija zdrowe kontenery, które po prostu wolniej startują. Daj im
initialDelaySecondsalbo użyj startup probe. - Mylenie self-healing z high availability. Samonaprawa zmniejsza czas niedostępności, ale nie znaczy „zero downtime”. Między awarią a naprawą zwykle jest przerwa.
Pojęcia powiązane: desired state, control loop / reconciliation, liveness i readiness probes, Kubernetes, auto scaling, high availability, fault tolerance, observability.