Эксплуатация и соответствие требованиям

TL;DR: Контур отвечает за нефункциональную готовность магазина: чтобы площадки выдержали нагрузку, инциденты имели владельцев и планы реагирования, а применимые требования законодательства совпадали с реальным процессом. Страница не повторяет общие руководства инфраструктуры и правового раздела — она фиксирует, как их объём применения выглядит для магазина.

Назначение контура

Три задачи:

Надёжность и безопасность — витрина, checkout и платёжный поток работают в пиках, восстановление проверено, webhook-приём и ручные операции защищены и управляемы. См. Надёжность и безопасность.
Соответствие требованиям РФ — матрица применимости: что из законов и правил применяется к этому конкретному магазину при этих способах продажи и оплаты. См. Требования РФ: матрица применимости.
Готовность к запуску и к распродажам — чек-лист запуска, репетиции нагрузок, зафиксированные SLA.

Связь с другими контурами

Нефункциональная готовность опирается на смежные контуры и не заменяет их:

Инфраструктура (хостинг, CI/CD, окружения) — раздел инфраструктуры; здесь только следствия для магазина: нагрузка, бэкапы, доступы.
Базовая безопасность веб-приложения (WAF, пароли, обновления) — безопасность сайтов; здесь — бизнес-уровень: роли, аудит, антифрод, мониторы.
Правовой объём (документы, договоры) — раздел legal; здесь — матрица, что и где применимо.
Функциональные контуры (рост, витрина, платежи, логистика, интеграции) — готовность к их отказам и задержкам считается здесь, а не в самих контурах.

Launch / operational readiness checklist

Чек-лист применяется одинаково к новому запуску и к переносам и переконфигурациям. Он дополняет, а не заменяет общее руководство инфраструктуры:

№	Блок	Минимум
1	Владельцы процессов	Кто отвечает за заказы, платежи, логистику, контент, маркетинговые механики; у каждого блока имя и запасной человек
2	Окружения	Prod отделён от stage; stage — не место, «где все ловят случайно»; деплой в prod из CI, не «с ноутбука»
3	Доступы и секреты	Список админского доступа актуален; секреты в хранилище/переменных окружения, не в конфигах в git и не в общем чате; отзыв доступа — за один шаг
4	Резервное восстановление	База и файлы бэкапятся по расписанию; восстановление проверено на тестовом стенде не позже полугода назад
5	План нагрузки на распродажи	Ожидаемое x-кратное превышение трафика прогнозируется; проверка витрина/checkout/оплаты в peak-mode перед акцией
6	Runbook инцидентов	Определён канал тревоги, кто разбирается, шаблон сообщения, офлайн-альтернатива (оформление «по телефону»), критерий отката
7	Бизнес-SLA	Не uptime, а оперативные лимиты: реакция на платёжные ошибки, отставание остатков, ручные операции
8	Контроль ручных операций	Перечень ручных задач (дочистки чеков, повторные отправки, обновления остатков) с исполнителем и проверяющим

Окружения, доступы, восстановление

Окружение stage — рабочий инструмент деплоя: stage воспроизводит конфигурацию prod (версия PHP, очереди, шлюзы в sandbox-режиме) и используется для проверки платёжных и учётных потоков до продакшена. Правило доступа: у каждого человека личная учётка, у критичных операций — журнал действий (audit log), у самой опасной — второй человек, который понимает, что она делает.

Резервное восстановление проверяется регулярной репетицией: скачать бэкап, восстановить на стенде, прогнать репрезентативную выборку. Бэкап, который ни разу не был развёрнут, не существует в смысле SLA.

План нагрузки на распродажи

Распродажи ломают не всю систему и не равномерно; типичный профиль: пик на витрине и каталоге, при этом checkout и третий шаг оплаты остаются узким звеном. Что проверяется заранее:

Прогноз трафика: во сколько раз ожидается превышение обычного; как быстро растёт продажа на marketplace-каналах (там пик короче и резче).
Тест витрины и checkout под пиковой нагрузкой: время ответа, ошибки, поведение очередей и кеша.
Поведение платёжного шлюза: лимиты запросов, консистентность платежей и возвратов при высокой конкуренции запросов.
Сценарий отказа: откат акции, ограничение трафика, сообщение пользователю — но не пустая страница.

Runbook инцидентов и бизнес-SLA

Инцидент магазина — не только «сайт упал». Бизнес-SLA фиксируются на уровне оперативных лимитов:

Группа	Пример нарушения	Реакция
Платёжные ошибки	Часть платежей не проходит дольше 15 минут (число условное)	Разбор по отчёту платёжной системы, подключение запасного шлюза
Отставание остатков	Остаток не синхронизирован больше 1 часа (число условное)	Предупреждение о перепродаже отсутствующего товара, ручная правка
«Потерянный» заказ	Заказ не попал в CRM/учёт больше 30 минут (число условное)	Проверка приёма заказов, ручной разбор очередей
Документы отгрузки	Документы ЭДО не проведены к сроку отгрузки	Задержка выпуска следующего заказа, эскалация
Свежесть фида	Фид не выгружался больше 1 часа при активной кампании (число условное)	Остановка товарных кампаний до обновления фида
Очередь задач	Рост очереди больше N минут (порог по бизнесу)	Проверка воркеров, приостановка нечувствительных ко времени задач

У каждого лимита — владелец и канал уведомления (мессенджер дежурного, тикет); нарушения фиксируются в журнале, чтобы инциденты накапливали статистику, а не начинались заново.

Процесс: как проходит репетиция

Общий сценарий проверки готовности (перед запуском и перед крупной распродажей):

Сборка чек-листа по блокам выше с проставленными владельцами и датами.
Проверка восстановлений и доступов — по факту, а не «в прошлый раз работало».
Нагрузочная репетиция в согласованном профиле (см. ниже) с фиксацией результатов.
Прогон end-to-end на stage: заказ → оплата (sandbox) → статус → учёт → чек.
Обновление runbook: актуальные контакты, границы ответственности, проверенные сценарии отката.
Go/No-go решение с зафиксированным критерием (что отменяет запуск).

Исключения и краевые случаи

Мини-запуск (новый раздел, новый способ доставки): чек-лист сокращается до блоков 1, 3, 6, 7, но решение о сокращении фиксируется явно, а не принимается «само собой».
Сезонные всплески без акции: репетиция проводится с профилем прошлого сезона, а не обычного трафика.
Новые ключевые интеграции (новый шлюз, новая учётная система): к стандартному списку добавляется план отката интеграции и окно наблюдения.
Ручной контур мелких изменений цен и остатков: связка «кто проверяет» сохраняется даже в ускоренном режиме, иначе ошибки попадают в каталог во время распродажи.

Контроль ручных операций

Перечень ручных задач и их исполнители — часть готовности:

Кто заполняет и проверяет товарные данные при их отсутствии.
Кто обрабатывает возвраты и невыкупы, кто формирует чек возврата, чей бюджет несёт последствия ошибок.
Кто сверяет наличие в учётной системе с витриной и согласует возвраты средств с менеджером.

Правило: у каждой ручной операции есть исполнитель и проверяющий; операции, которую нельзя воспроизвести по письменной инструкции, в списке вести нельзя.

Карта страниц контура

Страница	О чём
Надёжность и безопасность	Кэш без персональных данных, webhook, антифрод, e2e-сценарии, бизнес-мониторинг
Требования РФ: матрица применимости	Что из законов и правил применяется к конкретному магазину и почему

Связанные страницы

Надёжность и безопасность магазина — кэш, секреты, webhook, e2e-сценарии, мониторинг.
Требования РФ: матрица применимости — применимость требований по осям B2C/B2B, товар, способ продажи и оплаты.
Раздел инфраструктуры — общее hosting/среда/CI/CD (не дублируется здесь).
Раздел legal — юридические документы и подробная проработка законодательства.

Материалы и источники

Раздел инфраструктуры базы знаний — базовые руководства, к которым контур добавляет специфику магазина.
Раздел legal базы знаний — правовые документы, на которые ссылается compliance-страница.