Инфраструктура 02. Эксплуатация платформы и SLA¶
Статус: ревизия №2 по итогам аудита корпуса · 10.10.2026. Обязательства отсюда зеркалятся в Пользовательское соглашение; офлайн-контур — в
../specs/04-deployment-offline.md.Ресторан не останавливается на «починим завтра»: касса должна работать всегда, данные не имеют права теряться, инцидент у клиента — событие уровня всей платформы. Документ фиксирует операционные обязательства и порядок действий.
1. Уровни сервиса¶
| Сервис | Обязательство | Основание |
|---|---|---|
| Кассовый контур (офлайн-первый) | продажи возможны без облака норматив 8 часов; чеки не теряются (ФН хранит автономно) | ../product-blueprint.md, §5 |
| Облачные сервисы (кабинеты, события, отчёты) | доступность 99,9% в месяц (≤43 мин простоя) | Пользовательское соглашение |
| Приём заказов через гостевой контур | 99,9%; деградация — витрина читает кэш меню, заказы складываются в очередь | ../specs/04-deployment-offline.md |
| Потеря данных (события, заказы, справочники) | 0: журнал событий реплицируется, бэкапы проверены восстановлением | ниже, §4 |
2. Мониторинг: что смотрим в первую очередь¶
- «Чеки не уходят» — разрыв «чек пробит, но не подтверждён ОФД» дольше порога → алерт точке и платформе (
../components/01-pos-fiscal.md). - Офлайн дольше порога — точка без связи: уведомление УК, контроль очереди синхронизации.
- Ошибки вебхуков и платежей (идемпотентность повторов — контракт мок/боевых сервисов,
banks-kassa-ofd.md, §7). - Очереди событий, лаг репликации, заполненность ФН (%).
- Бизнес-алерты: падение выручки точки против базовой линии, всплеск отмен/инцидентов доставки.
3. Инциденты: уровни и время реакции¶
| Уровень | Признак | Реакция | Пример |
|---|---|---|---|
| SEV-1 | Не принимаются оплаты/заказы в точке или контуре | немедленно, дежурный, статус каждые 30 мин | отказ платёжного шлюза у всех |
| SEV-2 | Деградация функции (отчёты, кабинеты) при работающих продажах | ≤1 час | недоступен кабинет УК |
| SEV-3 | Локальный дефект без потери данных | ≤1 рабочий день | опечатка в отчёте |
| ИБ-инцидент | подозрение на утечку ПДн | уведомление Роскомнадзора в течение 24 часов (ст. 21 п. 3.1 152-ФЗ), расследование и повторное уведомление в течение 72 часов | ../legal/02-privacy-policy-draft.md |
Порядок: фиксация → классификация → обходное решение для точки → исправление → постмортем без поиска виноватых; клиент получает сообщение о причинах и мерах.
4. Резервные копии и восстановление¶
- Журнал событий — источник истины: репликация в второй контур + ежедневные снимки.
- Цели: RPO ≤ 15 минут (потеря данных), RTO ≤ 4 часов (восстановление сервиса) — гипотезы до первой тренировки восстановления (Г).
- Тренировка восстановления — ежеквартально, с протоколом времени.
- Экспорт клиентских данных по запросу — обязательство соглашения (
../legal/04-terms-of-use-draft.md, §4).
5. Изменения и плановые работы¶
- Релизы — вне пиковых часов общепита (запретное окно: пт вечер — вс вечер, 11:00–16:00 будни).
- Плановые окна — ночью, с уведомлением за 48 часов в кабинете; кассовый контур релизами не останавливается (офлайн-первый).
- Откат любого релиза — приоритет над «чиним вперёд» (правило плана: откат дешевле простоя,
../plan/01-implementation-plan.md).
6. Поддержка клиентов¶
| Линия | Канал | Срок первой реакции |
|---|---|---|
| 1 — справка/настройка | чат в кабинете, база знаний | ≤15 мин в рабочее время |
| 2 — техническая | тикет с телеметрией точки | ≤1 час |
| 3 — разработка | эскалация инцидента | по уровню SEV |
Поддержка работает на данных: у оператора обращения виден тенант, журналы точки и состояние синхронизации — «расскажите, что нажали» не нужно.