План непрерывности онлайн-продаж: готовый шаблон для бизнеса

10 августа 2026 · 6 мин чтения

План непрерывности онлайн-продаж описывает, как бизнес продолжит принимать или безопасно приостановит заказы, сохранит данные, сообщит покупателям и восстановит полный процесс при отказе сайта, оплаты, ERP, склада или другого критического поставщика. Он начинается не с резервного сервера, а с минимально приемлемого бизнес-режима.

Рабочий план содержит конкретные роли, пороги запуска, RTO и RPO для каждого процесса, проверенные обходы, порядок возврата в нормальный режим и сверку накопившихся операций.

Коротко

Чтобы составить план:

1. перечислите критические результаты бизнеса;
2. задайте максимальный допустимый перерыв;
3. определите допустимую потерю данных;
4. выберите минимальный режим работы;
5. назначьте владельцев решения и исполнения;
6. подготовьте обходы и сообщения;
7. опишите восстановление и сверку;
8. проведите учение и исправьте пробелы.

План без теста — гипотеза. Обход, который не способен обработать реальный объём, — не обход.

RTO и RPO простыми словами

• RTO — за какое время процесс должен быть восстановлен или переведён в приемлемый режим.
• RPO — какой объём данных по времени бизнес готов потерять и восстановить вручную.

Пример:

Процесс	RTO	RPO	Почему
Приём оплаченных заказов			Прямое влияние на деньги
Передача заказа в ERP			Можно временно поставить в очередь
Обновление остатков			Риск перепродажи
Аналитика			Продажи могут продолжаться
Рекомендации			Возможна деградация

Значения утверждает бизнес на основе ущерба и доступных мер, а не техническая команда в одиночку.

Шаг 1. Определите минимальный режим

Ответьте на вопросы:

• можно ли принимать заказы без мгновенной передачи в ERP;
• можно ли временно оставить один способ оплаты;
• можно ли отключить персонализацию и сложный поиск;
• какие товары безопасно продавать при задержке остатков;
• какой объём заказов команда обработает вручную;
• когда безопаснее закрыть checkout;
• как покупатель узнает об ограничениях;
• где будут храниться операции до восстановления.

Минимальный режим должен сохранять целостность денег и заказов, даже если сервис стал менее удобным.

Шаг 2. Постройте сценарии

Сценарий	Первый сигнал	Решение	Минимальный режим
Сайт недоступен	Внешняя проверка	Активация команды	Статус/резервная страница
Checkout сломан	Тестовый путь	Откат или ограничение трафика	Резервная форма/пауза
Платежи недоступны	Ошибки + статус провайдера	Переключение способа	Оплата при получении/ссылка по регламенту
ERP недоступна	Возраст последнего обмена	Буфер заказов	Очередь с ID и контролем
Остатки недостоверны	Сверка SKU	Ограничить ассортимент	Безопасная квота
Склад не исполняет	Операционный сигнал	Ограничить обещания	Новые сроки/приостановка
Аналитика недоступна	Контроль качества	Пометить данные	Продажи без оптимизации кампаний

Каждый обход проверяйте на законность, безопасность, защиту данных и операционную ёмкость.

Шаг 3. Назначьте роли

Роль	Полномочие
Руководитель непрерывности	Запускает план и выбирает бизнес-режим
Технический координатор	Диагностика и восстановление
Ecommerce	Витрина, цены, воронка, ограничения
Операции	Заказы, склад, доставка
Финансы	Платежи, возвраты, сверка
Поддержка	Сообщения и обращения покупателей
Коммуникации	Статус-страница и внешняя информация

Укажите заместителей. План не должен зависеть от одного человека, который может быть недоступен.

Шаг 4. Подготовьте карточку запуска

Поле	Значение
Условие запуска
Кто подтверждает
Какой путь затронут
Максимальное время ожидания
Выбранный режим
Команда и контакты
Первая коммуникация
Следующее обновление
Условие возврата
Обязательная сверка

Шаг 5. Спланируйте возврат

Восстановить интерфейс недостаточно. После аварийного режима нужно:

1. остановить поступление в обходной канал;
2. сохранить и пронумеровать накопившиеся операции;
3. безопасно перенести их в основную систему;
4. исключить дубли;
5. сверить оплаты, заказы, остатки и уведомления;
6. подтвердить полный путь контрольной операцией;
7. наблюдать стабильность;
8. сообщить о возвращении к нормальной работе;
9. удалить временные доступы и данные по регламенту.

Шаблон одностраничного плана

Критический результат

• Что бизнес обязан сохранить:
• Владелец:
• RTO:
• RPO:

Сигналы и запуск

• Автоматический сигнал:
• Ручное подтверждение:
• Кто запускает план:

Минимальный режим

• Что продолжает работать:
• Что отключается:
• Максимальная мощность:
• Ограничения и риски:

Коммуникация

• Команда:
• Покупатели:
• Поставщики:
• Частота обновлений:

Восстановление

• Порядок возврата:
• Сверка:
• Критерии завершения:

Учение раз в квартал

1. Выберите один реалистичный сценарий.
2. Не сообщайте заранее точную точку отказа.
3. Проверьте обнаружение и запуск.
4. Рассчитайте фактическую мощность обхода.
5. Пройдите коммуникацию и решения.
6. Смоделируйте возврат и сверку.
7. Запишите действия с владельцами и сроками.
8. Повторите слабый участок после исправления.

Начинайте с кабинетного упражнения без воздействия на production. Технические переключения проводите только в безопасном согласованном окне.

Типичные ошибки

• считать резервную копию полным планом бизнеса;
• задавать одинаковые RTO всем системам;
• принимать заказы в таблицу без ID, защиты и лимита;
• не учитывать людей, склад и поставщиков;
• не сообщать покупателям ограничения;
• не планировать возврат из обхода;
• не сверять деньги и заказы;
• хранить план там, куда нет доступа во время сбоя;
• ни разу не проводить учение.

FAQ

Чем план непрерывности отличается от disaster recovery?

Disaster recovery обычно фокусируется на восстановлении IT и данных. Непрерывность отвечает, как бизнес выполняет критические функции до, во время и после восстановления.

Нужен ли такой план маленькому магазину?

Да, но он может занимать одну-две страницы. Малому бизнесу особенно полезны контакты, резервный способ приёма, лимит ручной обработки и понятное условие остановки продаж.

Где хранить план?

В доступном команде защищённом месте с офлайн-копией контактов и ключевых действий. Секреты и пароли храните отдельно в предназначенном хранилище.

Источники

• NIST Cybersecurity Framework 2.0
• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• Google SRE: Managing Incidents

Проверено: 10 августа 2026 года.

Вернуться к Академии поддержки и устойчивости онлайн-бизнеса. Полезно также: карта внешних зависимостей и проверка восстановления из бэкапа.

Pingvera даёт независимые сигналы запуска и подтверждения восстановления, но решение о минимальном режиме, RTO и допустимом риске остаётся за бизнесом.

Читайте также: Карта зависимостей онлайн-бизнеса: шаблон · Отчёт об инциденте сайта: шаблон для клиента · Регламент мониторинга сайтов клиентов: шаблон · Зависимость от канала продаж: оценка риска · Бесплатно проверить сайт.