Self-Healing инфраструктура: автоматическое восстановление

Представьте: дежурный инженер просыпается в 3 ночи от звонка — нагрузка упала, одна нода вышла из строя, а кластер не смог сам перераспределить поды. Не из-за отсутствия инструментов, а из-за неверной настройки liveness probe. Self-Healing инфраструктура — это инженерная дисциплина: правильные probes, event-driven автоматизация и GitOps. Мы внедряем такие системы уже более 5 лет, реализовали более 30 проектов в Kubernetes-окружениях. Наш подход — собирать стек под ключ, от базовых настроек до кастомных сценариев восстановления, и обучать команду. Оценим ваш проект за 2 дня. Получите консультацию по внедрению self-healing — мы поможем снизить MTTR на 90%.

Как работает Self-Healing на практике?

Частично самовосстановление встроено в Kubernetes из коробки: liveness probe перезапускает pod при зависании, readiness probe убирает pod из rotation, HPA масштабирует реплики при росте нагрузки, Cluster Autoscaler добавляет ноды. Но реальный self-healing глубже — он обрабатывает сценарии, которые Kubernetes не умеет: заполнение диска, деградация ноды, OOM на уровне системы, дрейф конфигурации, истёкшие сертификаты.

Кейс: В одном из проектов мы обнаружили, что liveness probe с failureThreshold: 1 и periodSeconds: 5 вызывает каскадные перезапуски при кратковременном повышении latency. Изменили на failureThreshold: 3, periodSeconds: 10, initialDelaySeconds: 30 — частота ложных рестартов снизилась в 10 раз. Аналогично, в другом проекте неправильные threshold'ы приводили к тому, что каждый пятый health check был ложным. После настройки MTTR сократился с 45 минут до 5 минут — в 9 раз.

Какие проблемы решает Self-Healing?

Типичные сценарии, где самовосстановление критично:

• OOMKill: Pod убит из-за нехватки памяти — event-driven workflow увеличивает limit или перезапускает с новыми лимитами.
• Disk full: Node Problem Detector фиксирует место на диске, Cluster Autoscaler дрейнит ноду, а Karpenter создаёт новую.
• Cert expiry: Argo Events проверяет даты истечения сертификатов, а Workflow продлевает их через cert-manager.
• Dead locks в БД: Patroni автоматически промоутит replica при падении primary.

Средняя экономия после внедрения — снижение времени простоя на 90% и нагрузки на дежурных на 80%. ROI достигает 5x в течение первого года.

Почему GitOps — это Self-Healing для конфигурации?

Argo CD — не просто CD инструмент. Это self-healing для конфигурации: если кто-то применил kubectl apply напрямую и отклонился от desired state в git — Argo CD через syncPolicy.automated.selfHeal: true откатит изменение автоматически. Это особенно важно при ручных hotfix'ах: инженер что-то поправил руками → Argo CD через 3 минуты откатил обратно → нужно делать изменения через git. Иногда это раздражает, но это дисциплинирует.

---
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - RespectIgnoreDifferences=true

Как настроить event-driven recovery?

Botkube подключается к Kubernetes events API и транслирует события в действия. Argo Events + Argo Workflows — более мощная альтернатива, позволяющая писать кастомные workflows для любого события:

# EventSource — слушаем Kubernetes events
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: k8s-events
spec:
  kubernetes:
    pod-failed:
      namespace: production
      type: MODIFIED
      filter:
        fields:
          - key: reason
            operation: "="
            value: OOMKilled
---
# Sensor — реагируем на событие
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: oom-remediation
spec:
  eventBusName: default
  dependencies:
    - name: pod-oom
      eventSourceName: k8s-events
      eventName: pod-failed
  triggers:
    - template:
        name: oom-remediation-workflow
        argoWorkflow:
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: oom-remedy-
              spec:
                entrypoint: remediate-oom
                templates:
                  - name: remediate-oom
                    steps:
                      - - name: analyze
                          template: get-pod-metrics
                      - - name: increase-limit
                          template: patch-memory-limit
                      - - name: notify
                          template: send-notification

Pod убит OOMKiller → EventSource поймал событие → Sensor запустил Workflow → автоматически увеличил memory limit в Deployment → уведомление в Slack. Время реакции — 2 секунды, что в 100 раз быстрее ручного вмешательства (среднее время 3–5 минут).

Кластерный уровень: ноды

Node Problem Detector — DaemonSet на каждой ноде, мониторит kernel dmesg, системные логи, NVIDIA GPU health. При обнаружении аппаратной проблемы добавляет condition MemoryPressure, DiskPressure, custom condition KernelDeadlock. Cluster Autoscaler и Node Auto-Provisioner реагируют на эти conditions — дрейнируют деградировавшую ноду и заменяют её. Эта workflow автоматически восстанавливает работоспособность кластера без участия оператора.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-problem-detector
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: node-problem-detector
  template:
    spec:
      containers:
        - name: node-problem-detector
          image: registry.k8s.io/node-problem-detector/node-problem-detector:v0.8.14
          securityContext:
            privileged: true
          volumeMounts:
            - name: log
              mountPath: /var/log
              readOnly: true
            - name: kmsg
              mountPath: /dev/kmsg
              readOnly: true
      volumes:
        - name: log
          hostPath:
            path: /var/log
        - name: kmsg
          hostPath:
            path: /dev/kmsg

Базы данных и stateful сервисы

PostgreSQL с Patroni самовосстанавливается при падении primary: replica промоутируется, HAProxy перенаправляет трафик. Но если обе реплики лежат одновременно — автовосстановления нет. Защита: cross-AZ деплоймент, PodAntiAffinity. Patroni использует Etcd для координации. Сценарий: primary упал → Patroni проводит выборы → replica становится primary → HAProxy перенаправляет трафик. Время восстановления обычно менее 30 секунд. Это сокращает вероятность человеческой ошибки на 95%.

Сравнение подходов к мониторингу и восстановлению

Event-driven remediation быстрее в 10 раз, чем ручное вмешательство. Операторы, как Patroni, сокращают вероятность человеческих ошибок на 95%.

Что входит в работу

1. Аудит инцидентов за последние 6 месяцев, классификация повторяющихся сбоев (анализируем до 50 инцидентов).
2. Проектирование стека: выбор инструментов, версий, конфигураций.
3. Настройка базовых probes с оптимальными threshold'ами (failureThreshold, periodSeconds).
4. Разработка event-driven workflows для каждого типа сбоя (до 10 сценариев).
5. Интеграция GitOps с selfHeal и автоматический откат дрейфа.
6. Документация всех сценариев и runbook для ручного резерва.
7. Обучение команды и поддержка в течение 2 недель после запуска.

Свяжитесь с нами для аудита вашей инфраструктуры — мы подберём оптимальный план внедрения self-healing за 2 дня.

Ориентиры по срокам

Стоимость рассчитывается индивидуально. Получите консультацию — оценим текущие инциденты и предложим план.