Если поставщик спортивных данных деградирует: регламент частичного отказа

Поставщик может ломаться не целиком

Один вид спорта идёт нормально, другой отстаёт; prematch жив, live последовательность рвётся. Поэтому health должен иметь сегменты: provider + sport + feed type, а не один зелёный кружок на весь интеграционный канал.

Состояние влияет на политику выдачи

Data plane продолжает принимать всё валидное. Control plane оценивает lag, sequence gaps и parse/mapping errors. При деградации продукт применяет политику: для части данных разрешён stale-read с меткой, для live-рынков безопаснее forced suspend.

Автопереключение не всегда безопасно

Второй provider может иметь другую identity/mapping семантику. Мгновенно смешать источники по одному market опаснее, чем временно скрыть рынок. Автоматизация допустима там, где identity и reconciliation заранее проверены.

Регламент действий описывает действия и границы

Оператор видит затронутые сегменты, текущий lag, последнюю успешную sequence и доступный fallback. Действия — suspend segment, переключить приоритет для разрешённых сущностей, запустить reconciliation. Каждое действие логируется как изменение control state.

Нестабильное состояние

Порог без hysteresis может каждые секунды включать и выключать рынок. Health evaluator использует отдельные условия enter/exit degraded и минимальное время стабильности перед возвратом.

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

Runbook должен отвечать на вопросы дежурного без созвона с автором системы: что считается деградацией, какие сегменты затронуты, какой режим продукта безопасен, кто принимает решение о переключении и по каким признакам можно возвращаться в нормальный режим. Формулировки вроде «проверить провайдера» слишком общие и только тратят время.

Особенно важно описать частичный отказ. Если задержка касается одной лиги или типа данных, глобальное переключение поставщика может создать больше проблем, чем локальный suspend. Поэтому health лучше считать по сегментам и связывать с конкретной политикой выдачи.

• Привязать каждый шаг runbook к измеримому сигналу.
• Определить blast radius до автоматического failover.
• После восстановления проверять backlog и свежесть, а не только статус connection=green.

Регламент действий должен отвечать, что увидит пользователь

Фраза «provider unhealthy» бесполезна без продуктового действия. Для live-score допустимо временно показать stale с отметкой времени; для денежного market правильнее suspend; для части статистики можно скрыть только конкретный блок. Эти решения заранее связываются с сегментом и типом данных.

Автоматический failover также нельзя считать бесплатным. Второй provider может использовать другую identity или семантику состояния, поэтому переключение проходит через ту же нормализацию и mapping, что обычный ingest. EventNormalizer остаётся границей, а UI не узнаёт, какой источник активен.

После восстановления полезно держать короткое окно наблюдения: сравнить freshness, reconciliation errors и долю сегментов, которые действительно вернулись в live. Green health-check ещё не означает, что продукт уже согласован.

После восстановления — не просто нормальное состояние

Нужен reconciliation diff: состояние после восстановления сравнивается с authoritative snapshot. Только затем снимается forced suspend и health возвращается в норму. Это закрывает хвост пропущенных событий.