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