01
Один экран для ежедневного контроля системы
Обычный бизнес-отчёт показывает продажи, посещения и загрузку. Операционная диагностика отвечает на другой вопрос: можно ли доверять данным прямо сейчас. ProGym отдельно проверяет tenant database, Redis, миграции, фоновые очереди и ключевые продуктовые контуры клуба. Руководитель платформы открывает карточку организации и видит общий статус, время проверки и сигналы, которым требуется внимание.
Экран находится в отдельном ProGym Control Plane. Доступ получают владельцы платформы и назначенные операторы через защищённую superadmin-сессию. Список клубов ограничен брендом ProGym, действия журналируются в Taska Core, а обычный сотрудник клуба не получает доступ к системным сведениям других организаций. Такой контур подходит для одного клуба, пилотной группы и сети филиалов.
- состояние web, Taska Core, tenant database и Redis;
- ожидающие фоновые задачи и dead letter queue;
- ошибки за последние 24 часа по клубам;
- размер базы и время последней проверки;
- ручное обновление без перезагрузки всей страницы.
02
Проверка модулей и готовности клуба
Каждый tenant ProGym использует продуктовый manifest и собственный набор разрешённых модулей. Диагностика вычисляет effective modules по правилам Taska Core, тарифу, отключениям организации и preview-политике. Оператор видит количество включённых модулей, список отключённых возможностей и обязательные модули, которые отсутствуют. Потеря обязательного контура сразу переводит состояние в критичное.
Эта проверка защищает от незаметного расхождения конфигурации после обновления. Например, экран клиента может загрузиться, пока модуль оплат или контроля доступа уже отключён для tenant. Control Plane показывает проблему раньше полевого сценария. Product pin фиксирует минимальную проверенную версию Core, поэтому команда понимает, на каком контракте работает текущий релиз ProGym.
- product slug и тариф tenant;
- включённые и отключённые модули;
- обязательные модули с отдельным критичным статусом;
- совместимость с общей политикой Taska Core;
- безопасное поведение для старых tenant без нового модуля.
03
Интеграции, импорт и фоновые очереди
Подключения к платежам, ЭДО, уведомлениям и другим провайдерам имеют жизненный цикл и health status. ProGym показывает общее количество активных подключений, проблемные и критичные состояния, провайдеров и время последней проверки. Секреты, токены и сырой текст ответа провайдера остаются на сервере. Оператор получает достаточно контекста для выбора runbook и безопасной эскалации.
Импорт клиентской базы и обмены с внешними системами контролируются отдельно. На экране видны batches и строки за сутки, неуспешные запуски, количество проблемных строк и время последнего импорта. Глобальные фоновые метрики показывают ожидающие задачи и dead letter queue. Дорогой обход очередей запускается по запросу оператора, а обычное обновление dashboard остаётся быстрым.
- active, degraded, error и auth expired для подключений;
- последняя health-проверка провайдера;
- импортированные и проблемные строки за 24 часа;
- pending queue и DLQ без содержимого задания;
- безопасный счётчик tenant, которые не удалось просканировать.
04
Оплаты, касса и контроль доступа
Финансовый блок показывает ожидающие оплаты, ошибки за последние сутки и кассовые расхождения закрытых смен за 30 дней. Суммы, банковские реквизиты и provider reference в операторскую проекцию не входят. Руководитель видит масштаб проблемы и переходит к журналу оплат или кассовому runbook уже внутри tenant с подходящей ролью.
Контур СКУД показывает активные, online и offline устройства, последнее появление и версии приложения контроллера. Sandbox-устройства исключаются из боевого счётчика. Если один турникет перестал выходить на связь, оператор отличает локальный сбой от общей недоступности платформы. Решение о проходе и персональные данные клиента остаются в каноническом журнале доступа клуба.
- pending и failed payments без раскрытия суммы;
- кассовые расхождения после закрытия смены;
- online и offline устройства доступа;
- время последнего контакта и версии контроллеров;
- разделение sandbox и боевого оборудования.
05
Мобильные релизы и безопасные trace
Брендированные Client App и Trainer App выпускаются отдельными каналами для Android и iOS. Диагностика показывает последнюю версию для каждой аудитории и платформы, build number, channel, status и дату публикации. Команда сразу видит, где остался draft, какой релиз доступен пилоту и какое приложение требует действия в store-процессе.
Для связи между обращением клуба и серверной операцией используются masked correlation trace. В Control Plane попадает короткий необратимый ключ, тип операции, источник и время. Raw UUID, entity ID, payload, request path и сообщение исключения скрыты. Поддержка передаёт безопасный ключ инженеру, а инженер раскрывает подробности только в защищённом внутреннем контуре с журналом доступа.
- последние Android и iOS releases по аудитории;
- draft, internal, review и published status;
- version name и build number;
- короткий masked trace для эскалации;
- нулевая выдача payload и персональных идентификаторов.
06
Runbook превращает сигнал в конкретное действие
Красная карточка приносит пользу, когда рядом есть понятная реакция. ProGym связывает диагностику с регламентами для tenant database, очередей, провайдера, зависшей оплаты, offline-устройства, динамического QR, кассовой смены, push-доставки и mobile store rejection. Каждый runbook начинается с проверки масштаба, безопасной стабилизации и фиксации номера операции.
После устранения причины оператор повторяет health-проверку, контролирует очередь и записывает результат. Для восстановления tenant используется отдельный restore-процесс с проверкой checksum, migration head и бизнес-счётчиков. Прямое редактирование баланса, статуса оплаты или журнала проходов в диагностику не встроено. Исправления проходят через канонический сервис, ledger и audit.
На демонстрации можно открыть Control Plane, выбрать тестовый клуб, показать effective modules, payments, access devices, mobile releases и trace. Затем команда имитирует недоступный блок в fixture-контуре и проходит runbook. Боевой запуск дополняется реальными provider credentials и оборудованием конкретного клуба.
- кто реагирует и какой контур проверяет первым;
- условие эскалации и безопасная стабилизация;
- повторная проверка после исправления;
- отдельный порядок восстановления tenant;
- история релиза и production evidence.