Fleet Coordinator: как отслеживать дрейф систем без публикации внутренней топологии

Минимальная модель Fleet Coordinator

• Expected state: versioned registry описывает допустимые роли, сервисные зависимости и ожидаемое состояние без публикации чувствительной сетевой топологии.
• Observed state: read-only probes собирают свежие признаки доступности, версии, process/service identity и health, причём отсутствие данных должно давать UNKNOWN, а не ложный PASS.
• Reconciliation: детерминированные правила сравнивают expected/observed state и создают drift records с evidence timestamp и source identity.
• Authority: обнаружение дрейфа не является разрешением автоматически менять runtime. Repair/remediation требует отдельного policy gate и audit receipt.
• Audit: история наблюдений должна сохранять причину, evidence и supersession, не превращая публичный сайт в карту внутренних систем.

Какие классы дрейфа полезно отслеживать

Практический taxonomy может включать version/config drift, missing service, unexpected process, stale registry, unreachable dependency, authority mismatch, failed health probe и orphaned state. Названия категорий должны описывать проблему, а не раскрывать конкретный сервер, порт или внутренний deployment path.

Для каждой записи полезно хранить минимум: observed_at, source/probe identity, expected fingerprint, observed fingerprint, severity, confidence, owner и remediation state.

Public/private boundary

• Публичный материал не должен перечислять реальные или исторические IP-адреса, private host aliases и host-to-service mapping без отдельной причины публикации.
• Не следует публиковать scheduler task names, точные cadences, внутренние state filenames, localhost/admin endpoints или environment-variable names, если они не являются частью публичного API contract.
• Документация не должна утверждать, что исторический host, service или automation сейчас работает. Для current-runtime claim нужен отдельный fresh readback.
• Имя переменной окружения само по себе не является секретом, но его удаление из публичного текста уменьшает лишнюю operational reconnaissance surface.

Fail-closed reconciliation

Если probe отсутствует, registry конфликтует или source freshness истекла, coordinator должен фиксировать неопределённость и эскалировать review, а не автоматически объявлять систему исправной. Автоматическое восстановление допустимо только внутри заранее ограниченного и проверенного remediation contract.

Эта страница описывает архитектурный паттерн. Она не доказывает наличие конкретного fleet, scheduler, API, сервера, dashboard или production automation.

Допустимая область использования

Используйте материал как checklist для внутреннего reconciliation service: сформировать registry schema, freshness rules, drift taxonomy, read-only probes, evidence log и отдельный remediation authority gate. Конкретная topology должна храниться в защищённом operational source, а не в публичном guide.

Эта страница не является разрешением на изменение серверов, firewall, scheduler, credentials, deployment, DNS или runtime state.