Растущая микросервисная архитектура легко теряет из виду, у каких сервисов вообще настроен healthcheck. Проблема не абстрактная — отсутствие healthcheck напрямую бьёт по надёжности condition: service_healthy у зависимых сервисов.
Что реально происходит без healthcheck у зависимости
services:
app:
depends_on:
db:
condition: service_healthy
db:
image: postgres:18
# healthcheck отсутствуетУказание condition: service_healthy для сервиса без настроенного healthcheck — это не ошибка конфигурации, которую Docker Compose поймает заранее, а тихая логическая проблема: без healthcheck Compose не может определить состояние healthy, и поведение зависит от конкретной версии инструмента, не всегда предсказуемо для автора файла.
Почему один файл не даёт полной картины
| Ситуация | Риск |
|---|---|
| Один сервис проекта без healthcheck | Локальный риск для конкретной цепочки depends_on |
| Десяток compose-файлов разных команд без единого стандарта | Системный риск — никто не знает реальное покрытие организации |
Практика периодического аудита покрытия
Разумно проверять покрытие healthcheck не разово, а регулярно — при добавлении новых сервисов в организации легко забыть про healthcheck для одного из них, особенно если это внутренний вспомогательный сервис, а не основное приложение.
Как проверить сразу весь парк файлов
Открывать каждый compose-файл организации по отдельности и искать глазами секцию healthcheck долго. Compose Healthcheck Coverage Auditor сканирует сразу несколько файлов и показывает конкретный список сервисов без покрытия.
Итоговый чеклист
Условие service_healthy для зависимости без настроенного healthcheck — тихая логическая проблема, а не явная ошибка конфигурации.
Покрытие healthcheck стоит проверять на уровне всего парка файлов организации, а не одного проекта — риск системный, а не локальный.
Периодический аудит покрытия эффективнее разовой проверки при добавлении новых сервисов.