Prod-Readiness Probe
Gate готовности прода для deploy-class задач — read-only проверка симметрии test↔prod runner, блокирующая предложение merge и архивирование, пока прод не верифицирован. Гибрид: детерминированно при наличии контракта проекта, иначе чек-лист агента.
Обзор
Prod-Readiness Probe — блокирующий gate для deploy-class задач, то есть работ, затрагивающих deploy-поверхность (systemd-юниты, sudoers, CI-cutover, шаблоны .env-deploy). Срабатывает на двух стадиях: /dr-qa Layer 4g (до того как pipeline может предложить merge) и /dr-archive Step 0.4 (до того как задачу можно заархивировать).
Зачем это нужно
Deploy- или cutover-изменение может пройти все проверки на тестовом раннере и упасть на первой же продакшен-команде — классический случай: на проде sudoers не содержит NOPASSWD-правил, которые на тестовом раннере уже есть. Раньше pipeline предлагал смерджить и заархивировать такое изменение, ни разу не проверив, симметричен ли продакшен-раннер тестовому. Этот gate заставляет проверку: фреймворк прогнозирует последствия на проде и подтверждает готовность до того, как рекомендует merge, и отказывается архивировать задачу, чей продакшен-rollout неполон или не верифицирован.
Что проверяется
- Симметрия sudoers — каждое NOPASSWD-правило, нужное деплою, есть на проде ровно как на тесте.
- Паритет PATH — PATH deploy/service-пользователя на проде совпадает с тестом.
- Слушающие порты — порты сервиса свободны (или заняты ожидаемым юнитом) на проде.
- Systemd-юниты — требуемые юниты существуют и enabled / running.
- Версии рантаймов — node / redis / прочие удовлетворяют заявленному порогу.
Словарь вердиктов
SKIP (не deploy-class), PASS (симметрия подтверждена), FAIL (найдена асимметрия — запретить merge / archive), BLOCKED (probe не смог отработать и нет подтверждения оператора — запретить merge / archive). BLOCKED никогда не превращается в PASS автоматически на недостижимом хосте; молчание — не успех.
Гибридное исполнение
Если проект завёл опциональный контракт datarim/deploy-readiness.yml (проверяемый отдельным shell-валидатором), probe выполняет детерминированное трёхстороннее сравнение — факт тестового раннера vs факт прод-раннера vs заявленное. Если контракта нет — probe откатывается к чек-лист-расследованию агентом по тем же пунктам. Ядро фреймворка остаётся stack-agnostic; проект-специфичные данные живут только в опциональном контракте.
Прод — hard-gated
Любое действие probe — read-only: sudo -l, systemctl status, ss, redis-cli info server, node --version. Probe — сенсор, не актуатор: никаких записей, рестартов, правок sudoers. Найдя пробел, он прогнозирует последствия и сообщает; устранение — явное действие оператора.
Загружается
/dr-qa Layer 4g и /dr-archive Step 0.4, только на deploy-class задачах.