01
Разделите бизнес-показатели и здоровье системы
Владелец фитнес-клуба ежедневно смотрит выручку, новые продажи, посещения, продления, загрузку занятий и дебиторку. Эти показатели объясняют результат бизнеса. Они могут выглядеть правдоподобно даже при технической проблеме. Сбой импорта задержит часть клиентов, offline-контроллер перестанет отправлять проходы, а зависшая очередь отложит уведомления. Вчерашний отчёт сохранит красивые цифры и не покажет текущую причину.
Добавьте второй слой: здоровье платформы. В него входят доступность web и API, tenant database, Redis, миграции, очереди, интеграции, оплаты, кассовые расхождения, устройства СКУД и мобильные релизы. Сигнал должен отвечать на три вопроса: какой клуб затронут, насколько широк масштаб и какой следующий шаг разрешён оператору.
Зафиксируйте владельцев контуров. Руководитель клуба принимает бизнес-решение, администратор смены выполняет резервный процесс, бухгалтер отвечает за оплату и документы, интегратор разбирает оборудование, а платформа контролирует инфраструктуру. Один общий чат без ролей замедляет реакцию. У каждой категории должен быть основной ответственный, заместитель и время эскалации.
Согласуйте рабочие определения. Pending payment означает ожидаемое подтверждение, failed payment требует отдельного разбора, offline device учитывается после утверждённого порога, а DLQ содержит задачу, которую автоматический retry уже не завершил. Эти термины включаются в инструкцию смены и acceptance-план пилота.
- бизнес: выручка, продажи, посещения, удержание и загрузка;
- платформа: web, API, database, Redis и migrations;
- операции: очереди, импорт, оплаты, касса и СКУД;
- релизы: Client App, Trainer App и контроллеры;
- ответственные и время эскалации по каждому контуру.
02
Соберите короткий утренний dashboard
Утренний контроль должен занимать несколько минут. Начните с общего health ProGym и Taska Core. Проверьте доступность tenant database и Redis, migration status и задержку ответа. Затем откройте фоновые очереди: pending tasks, dead letter queue и число tenant, которые не удалось просканировать. Нулевая ошибка сканирования важна так же, как нулевой DLQ.
Следом проверьте интеграции. Посмотрите active, degraded, error и auth expired, время последнего health-check и список затронутых провайдеров. Истёкшая авторизация часто требует действия владельца аккаунта. Сетевая ошибка может восстановиться повтором. Разные причины получают разные runbook, поэтому общий статус «интеграция сломалась» подходит только для первичного уведомления.
Финансовая часть включает pending payments, failures за сутки и кассовые расхождения. Pending сам по себе бывает нормальным, если платёж создан недавно и провайдер ещё обрабатывает его. Долгая pending-операция требует сверки server-to-server callback, статуса провайдера и ledger. Сотрудник не отмечает продажу оплаченной по скриншоту клиента или странице возврата.
Завершите проверку устройствами и mobile releases. Offline СКУД оценивается по времени последнего контакта и режиму филиала. Draft mobile release допустим до согласованной даты, застрявший review требует владельца store-аккаунта. Результат утренней проверки фиксируется коротко: время, оператор, отклонения, назначенные действия и срок следующего контроля.
03
Настройте уровни серьёзности и правила уведомлений
Уровень P1 назначается событию, которое останавливает вход в клуб, оплату, работу всех tenant или создаёт риск неверного финансового результата. Для него нужен немедленный канал связи, ответственный за стабилизацию и регулярное обновление статуса. P2 влияет на часть клубов или один важный контур, но имеет безопасный резервный процесс. P3 охватывает локальное отклонение, которое можно исправить в рабочее время.
Серьёзность определяется влиянием, а не громкостью ошибки. Один offline-турникет в филиале с работающей второй точкой может быть P2. Ошибка, которая разрешает проход заблокированному клиенту, становится P1 даже при одном событии. Две failed payments могут быть P3, если подписи корректны и клиент получил понятный отказ. Рост неподписанных callbacks указывает на атаку или неверную конфигурацию и требует другого уровня.
Уведомление содержит клуб, контур, время начала, текущее влияние, безопасный correlation key и следующий update. Телефон клиента, сумма оплаты, provider token, raw payload и stack trace в общий чат не попадают. Для инженерной диагностики используется защищённый журнал с отдельным правом. Такой порядок сохраняет скорость реакции и tenant isolation.
Защитите команду от alert fatigue. Не отправляйте сообщение на каждый успешный retry и каждую краткую сетевую задержку. Объединяйте повторяющиеся сигналы по tenant и типу операции, используйте порог времени и закрывайте уведомление после подтверждённого восстановления. Ежедневный отчёт показывает количество событий по серьёзности и просроченные действия.
04
Разбирайте очередь и DLQ без двойных операций
Фоновая очередь выполняет уведомления, интеграционные обмены и другие отложенные задачи. Сначала определите, растёт ли pending и продолжают ли workers обрабатывать новые элементы. Большая очередь при стабильном снижении может быть последствием краткого пика. Постоянный рост указывает на недоступный worker, Redis, provider или ошибку конкретного типа задания.
DLQ хранит задачи, которые исчерпали автоматические попытки. Оператор смотрит счётчики по tenant и типу, выбирает безопасный пример и находит masked trace. Содержимое задания и персональные данные остаются в защищённом контуре. Перед повтором нужно понять, является ли операция идемпотентной и сохранил ли внешний провайдер фактический результат.
Для оплаты, списания занятия, выдачи доступа и складского движения простой повтор особенно опасен. Проверьте канонический статус и ledger, затем используйте существующий idempotency key. Если provider уже принял запрос, повтор должен вернуть прежний результат. Новый ключ создаётся только для новой бизнес-операции после явного решения ответственного сотрудника.
После восстановления следите за скоростью разгрузки, новыми DLQ и error rate. Закройте инцидент после достижения нормального уровня и проверки нескольких фактических операций. Запишите причину, применённое действие и защиту от повторения. Массовое удаление очереди не считается восстановлением и может потерять обязательства клуба.
05
Проверяйте оплату по callback и ledger
При обращении клиента найдите payment intent, попытку провайдера и каноническую продажу. Сравните статус, время, валюту, ожидаемую сумму и наличие подписанного callback. Страница успешного возврата в приложении подтверждает удобный путь пользователя, но источник истины находится в server-to-server уведомлении и финансовом ledger.
Если платёж pending дольше нормы, проверьте доступность callback URL, подпись, внешний идентификатор и ответ provider status API. Повторное уведомление обрабатывается с тем же ключом и не увеличивает оплаченную сумму. Изменённая сумма или другая цель с прежним ключом должна завершиться конфликтом. Ручное подтверждение проходит отдельным регламентом сверки.
Failed payment сохраняет код причины, доступный сотруднику, и безопасный технический контекст для поддержки. Клиент получает понятный следующий шаг: повторить, выбрать другой способ или обратиться в клуб. Raw provider error, банковские реквизиты и токен карты не отображаются в обычном интерфейсе. Сотрудник не копирует эти данные в задачу.
После восстановления проведите положительный и отрицательный сценарий. Успешный callback создаёт ровно одну проводку и применяет членство или услугу согласно сохранённому snapshot. Повтор возвращает существующий результат. Неверная подпись отклоняется, баланс и доступ клиента остаются прежними. Результат включается в field acceptance конкретного провайдера.
06
Разбирайте offline СКУД по устройству и политике клуба
Сначала определите масштаб: одно устройство, один филиал или весь access API. Проверьте last seen, app version, сеть площадки и состояние других контроллеров. Если Core доступен, а одно устройство offline, причина обычно находится между контроллером и сетью филиала. Если все устройства потеряны одновременно, проверьте общую конфигурацию, DNS и сертификаты.
Переведите смену на утверждённую offline-политику. Она заранее задаёт срок локального пакета, разрешённые credentials, зоны и действия после истечения. Ресепшен видит понятную инструкцию и фиксирует ручные проходы с причиной. Экстренные и эвакуационные процессы остаются в зоне ответственности физической безопасности клуба.
После связи контроллер отправляет накопленные события с уникальными ключами. Повтор не создаёт второй визит. Конфликт присутствия попадает в отдельную очередь сверки, где сотрудник видит устройство, время и credential согласно своей роли. Нельзя исправлять проблему удалением событий или прямой правкой даты последнего прохода.
Закройте инцидент после проверки входа, выхода, anti-passback, offline sync и нового last seen. Если обновлялась версия контроллера, сохраните build number и результат rollback-проверки. Для нового производителя проведите полный стенд: виртуальные правила, физическое реле, датчик двери, потеря сети и повторную доставку.
07
Контролируйте интеграции и импорт по свежести данных
Health status интеграции показывает техническое соединение, но бизнесу важна свежесть результата. Для импорта отслеживайте время последнего batch, количество строк, failed runs и failed rows. Для ЭДО проверяйте cursor входящих документов, очередь draft и handoff на подпись. Для уведомлений учитывайте принятые, доставленные и окончательно отклонённые сообщения.
Auth expired требует повторной авторизации владельцем provider account. Degraded позволяет части операций продолжать работу и требует контроля. Error переводит зависимый сценарий в безопасный режим. Клуб заранее решает, можно ли принять оплату другим способом, сформировать документ позже или записать клиента вручную с последующей сверкой.
Импорт повторяется через исходный batch и mapping version. Исправьте данные или правило сопоставления, затем запустите повтор только для проблемного набора. Успешные строки не дублируются. Отчёт ошибок должен объяснять поле и причину, не раскрывая данные другой организации. Итоговые счётчики сравниваются с контрольным файлом клуба.
Для каждой интеграции храните владельца, договор, provider environment, дату последней проверки и срок секрета. Секреты находятся в зашифрованном хранилище и не отображаются в диагностике. Замена токена сопровождается health-check, одним положительным сценарием, одним ожидаемым отказом и записью в audit.
08
Следите за мобильными релизами как за рабочим контуром
Client App и Trainer App участвуют в записи, пропуске, посещаемости и коммуникации. Поэтому версия приложения относится к операционному контролю. Для каждой аудитории и платформы фиксируйте version name, build number, channel, status, дату публикации и минимально поддерживаемую версию Core.
Internal build проходит smoke на тестовом tenant. Проверяются Telegram-вход, выбор организации, расписание, offline cache тренера, dynamic QR, push и logout. Review status получает владельца store-аккаунта и ожидаемую дату. Rejected release сохраняет причину в защищённом контуре, а оператор видит безопасный статус и runbook.
Публикация проводится по волнам. Сначала пилотная группа, затем один клуб или небольшой процент аудитории, после этого общий rollout. Контролируйте auth failures, crash-free sessions, ошибки API и обращения поддержки. Возможность остановить rollout и вернуть предыдущий compatible build входит в release plan.
Web и PWA тоже требуют версии. После deploy проверьте health, manifest, service worker, загрузку ключевых маршрутов и mobile layout. Кэш не должен удерживать устаревший контракт после обязательного обновления. Инструкция смены объясняет, когда достаточно перезагрузить приложение, а когда требуется новая store-версия.
09
Проведите короткий инцидентный цикл
Первый шаг называется стабилизацией. Остановите повторяющийся вред, включите безопасный резервный процесс и сохраните evidence. Для платежа это может быть пауза автоматических попыток конкретного provider, для интеграции ограничение очереди, для СКУД утверждённый offline-режим. Область действия должна быть минимальной и обратимой.
Второй шаг устанавливает факты. Зафиксируйте tenant, время начала, затронутый контур, первую известную ошибку, masked correlation key, состояние очереди и последние изменения. Проверьте соседний tenant и другой сценарий того же клуба. Так команда отличает локальную конфигурацию от общей регрессии платформы.
Третий шаг восстанавливает канонический процесс. Используйте штатный retry, provider reconciliation, device reconnect, forward fix или rollback совместимого релиза. Финансовые и складские результаты проходят через ledger. Истории доступа и документов сохраняют исходные события. Прямое удаление строк и ручная смена статуса обходят доказательство и создают новый риск.
Четвёртый шаг подтверждает результат. Проверьте health, очередь, реальный пользовательский сценарий, tenant isolation и отсутствие новых ошибок. Сообщите клубу, что восстановлено, какие операции требуют сверки и когда будет следующий update. После закрытия добавьте regression test, мониторинг и короткое изменение runbook.
10
Зафиксируйте ежедневный и ежемесячный ритм
Каждое утро оператор проверяет общий health, очереди, критичные интеграции, pending payments, offline devices и mobile release status. В течение дня система уведомляет только по утверждённым порогам. Вечером смена сверяет открытые оплаты, кассу, незакрытые визиты и операции, которые остались в ручном процессе.
Раз в неделю руководитель смотрит динамику инцидентов: количество по уровню, среднее время реакции, повторные причины, просроченные действия и клубы с частыми отклонениями. Эти показатели связываются с бизнес-эффектом, например потерянными записями, задержанными оплатами или ручными проходами. Сырые технические события сами по себе не являются KPI команды клуба.
Перед закрытием месяца проверьте кассовые расхождения, незавершённые provider reconciliation, failed imports, неподписанные документы и критичные access incidents. Закрытый период защищается от поздней правки. Исправление проходит через повторное открытие с причиной или компенсирующую операцию согласно финансовому регламенту.
Раз в квартал проведите restore drill и пересмотрите runbook. Восстановление tenant подтверждается checksum, migration head, ролями, ключевыми счётчиками и одним пользовательским сценарием. Удалите временную базу после проверки по утверждённой процедуре. Обновите контакты провайдеров, владельцев store-аккаунтов и список оборудования филиалов.
- утро: health, queues, integrations, payments, devices;
- день: пороговые уведомления и назначенные действия;
- вечер: касса, визиты и ручная сверка;
- неделя: причины, время реакции и повторные инциденты;
- месяц: финансовое закрытие и provider reconciliation;
- квартал: restore drill, контакты и обновление runbook.
11
Пройдите приёмку мониторинга на пилотном клубе
Создайте матрицу из положительных и отрицательных сценариев. Откройте здоровый tenant, проверьте enabled modules и отсутствие required missing. Имитируйте degraded интеграцию в тестовом контуре, failed import, зависшую оплату, offline sandbox device и draft mobile release. Для каждого сигнала зафиксируйте ожидаемый статус, фактическую карточку и предложенный runbook.
Проверьте безопасность. Обычный сотрудник клуба не открывает Control Plane. Оператор ProGym видит только брендированные tenant. Диагностика не отдаёт tokens, provider errors, raw request IDs, entity UUID, суммы и payload. Masked trace помогает инженеру найти внутреннюю запись, но не позволяет восстановить исходный идентификатор из браузера.
Проверьте UX на desktop и телефоне шириной 390 пикселей. Карточки должны складываться в одну колонку, страница сохраняет собственную ширину, navigation остаётся доступной, кнопки имеют touch target от 44 пикселей. Loading, unavailable и scan failed показываются честно. Нулевой счётчик отличается от отсутствующих данных.
Завершите production smoke. Composite health должен подтвердить web и Taska Core, диагностические API без сессии закрываются, raw route отсутствует, release symlink указывает на точный commit. Затем откройте Control Plane через реальную superadmin-сессию, обновите данные и пройдите один runbook. Результат и внешние FIELD-проверки добавьте к акту приемки клуба.