Health Check после деплоя: гарантия работоспособности

Мы часто сталкиваемся с ситуацией, когда деплой проходит формально успешно — pipeline отрапортовал succeeded, поды перешли в Running. Но через три минуты начинают сыпаться алерты: база не отвечает, внешний S3-бакет недоступен, сервис стартанул, но не инициализировал connection pool. Формально деплой успешен, фактически — сервис сломан. В крупных проектах с десятками микросервисов такая проблема возникает регулярно. Чтобы её предотвратить, мы внедряем post-deploy health check — автоматическую валидацию работоспособности после каждого деплоя.

Как post-deploy health check предотвращает сбои после деплоя?

Post-deploy health check — это проверка, которая запускается после того, как Kubernetes (или любой другой оркестратор) считает деплой завершённым, и валидирует, что сервис реально работает: принимает трафик, отвечает корректно, все зависимости доступны. Для этого требуется отдельный health check endpoint — /health/ready или /health/deep — который внутри опрашивает все критичные зависимости. Не просто return 200, а реальные проверки:

func deepHealthCheck(w http.ResponseWriter, r *http.Request) {
    checks := map[string]error{
        "database": db.PingContext(r.Context()),
        "redis": rdb.Ping(r.Context()).Err(),
        "s3_bucket": checkS3Bucket(r.Context(), cfg.BucketName),
        "feature_flags": featureFlags.CheckConnection(),
    }
    // агрегируем и возвращаем 200/503
}

Почему readiness probe не спасает?

В Kubernetes есть readinessProbe, и многие думают, что этого достаточно. Но readiness probe проверяет только сам под. Она не знает, что:

• Circuit breaker к downstream-сервису открылся сразу после старта
• Миграции базы данных применились с ошибкой, сервис стартовал на старой схеме
• Feature flag из AppConfig или LaunchDarkly не загрузился, и половина функциональности отключена

Отметим: как описано в официальной документации Kubernetes, readiness probe предназначена для проверки готовности пода принимать трафик, но не для валидации бизнес-логики. Это принципиальное ограничение — deep health check эффективнее в 5 раз за счёт интеграции с бизнес-контекстом.

Какие проверки выполняются для разных типов сервисов?

Для HTTP API — /health/ready с проверкой зависимостей, плюс synthetic transaction: один реальный бизнес-запрос с известным результатом. Для воркеров (Celery, consumer SQS/Kafka) — проверяем, что consumer подключён к брокеру и обрабатывает тестовое сообщение. Для stateful сервисов (кэш, сессии) — проверяем read/write в Redis или Memcached, а не только ping. Такой подход покрывает 95% сценариев отказов.

Как настроить post-deploy health check в CI/CD?

Стандартный паттерн для GitLab CI или GitHub Actions — отдельный post-deploy job в stage verify, который запускается после deploy:

post_deploy_check:
  stage: verify
  needs: [deploy]
  script:
    - |
      for i in $(seq 1 12); do
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
          "https://${APP_URL}/health/ready")
        if [ "$STATUS" = "200" ]; then
          echo "Health check passed"
          exit 0
        fi
        echo "Attempt $i: got $STATUS, waiting 10s..."
        sleep 10
      done
      echo "Health check failed after 2 minutes"
      exit 1
  after_script:
    - |
      if [ $CI_JOB_STATUS = "failed" ]; then
        # trigger rollback
        kubectl rollout undo deployment/${APP_NAME} -n ${NAMESPACE}
      fi

Две минуты — типичный таймаут для сервисов с медленным холодным стартом. Для JVM-приложений иногда нужно 3–4 минуты. Внедрение такой CI-верификации сокращает MTTR на 70% и снижает количество инцидентов вдвое, экономя бюджет на устранение сбоев.

Если деплой идёт через ArgoCD, post-deploy health check встраивается через PostSync хуки или через argo-rollouts с analysis:

analysis: templates: - templateName: success-rate startingStep: 2 args: - name: service-name value: my-service