Магазин с постоянным потоком заказов не должен узнавать о сбое от покупателя. Нужны проверки ключевых страниц и сценариев, уведомления в рабочий канал и копии, из которых действительно можно восстановиться. Проверенная копия важнее самого факта её существования.
Страница для магазинов с постоянным потоком заказов.
О недоступности сайта вы узнаёте от покупателей или случайно.
Копии, возможно, делает хостинг, но никто не проверял, что из них можно восстановиться.
Неизвестно, какая глубина хранения копий и что именно в них попадает.
Срок действия домена или сертификата однажды заканчивался неожиданно.
Проверяется только главная страница, а не оформление заказа.
Нет заранее описанного порядка действий на случай сбоя.
Если нужны регулярные проверки, исправления и развитие по регламенту, посмотрите Техническая поддержка
Основная проблема
Копия, из которой не восстановились, ещё не резервная копия
Мониторинг главной страницы создаёт ложное спокойствие. Главная может открываться при полностью неработающем оформлении заказа: сломался шаг оплаты, перестал отвечать сервис расчёта доставки, упало соединение с учётной системой. Поэтому проверять нужно не один адрес, а набор ключевых URL и сценариев: страницу каталога, карточку товара, добавление в корзину, доступность шага оформления и отправку формы. Такой набор ловит именно те сбои, которые напрямую останавливают продажи.
С копиями похожая ситуация. Часто копии формально есть, но никто не знает, что в них входит и можно ли из них подняться. Резервное копирование магазина состоит из нескольких объектов: файлы и код, база данных, загруженные изображения, а также конфигурация. Пропуск любого из них означает, что восстановление будет неполным. К этому добавляются частота, глубина хранения и — самое важное — контроль успешности: копия, которая не создалась или создалась повреждённой, хуже отсутствия копии, потому что создаёт ложную уверенность. Именно поэтому мы включаем в регламент периодический тест восстановления: копия считается рабочей только после того, как из неё поднялся работающий магазин.
И третье, о чём стоит сказать прямо: мониторинг сокращает время обнаружения сбоя, но не предотвращает его. Мы не обещаем непрерывную доступность и нулевую потерю данных. Доступность обеспечивает хостинг, а работоспособность оплаты, доставки и других внешних сервисов — их владельцы. Между двумя копиями всегда есть интервал, и данные, появившиеся внутри него, при восстановлении могут быть потеряны. Мы делаем этот интервал понятным и согласованным, а не скрываем его.
Что происходит без изменений
Что следует из работы без мониторинга и проверенных копий
Только логические следствия, без выдуманных цифр.
Сбой длится до жалобы
Без проверок время недоступности определяется тем, когда кто-то заметит.
Незамеченная поломка заказа
Проверка только главной страницы не выявляет неработающее оформление.
Копия оказывается непригодной
Без теста восстановления факт наличия копии ничего не гарантирует.
Неполное восстановление
Если база или изображения не попали в копию, магазин поднимется частично.
Внезапное истечение домена или сертификата
Без контроля срока сайт становится недоступным по предсказуемой причине.
Потеря времени в момент аварии
Без заранее описанного порядка действий первые часы уходят на согласования.
Что создаётся
Что создаётся
Результат — работающий регламент наблюдения и проверенные копии.
Снимает: В момент аварии никто не тратит время на согласование порядка.
Разграничение зон ответственности
Фиксируем, что относится к хостингу, что к внешним API, что к сайту.
Снимает: Причина определяется быстро, без спора между участниками.
Схема работы
Где решение работает в цепочке продаж
Мониторинг наблюдает за узлами цепочки, но не управляет ими.
ТрафикСледим за доступностью страниц входа.Общий контур
КаталогПроверяем доступность страниц каталога.Зона этой услуги
Карточка товараПроверяем открытие карточки и вывод данных.Зона этой услуги
КорзинаПроверяем добавление товара и расчёты.Зона этой услуги
ОплатаПроверяем доступность шага, работоспособность — у оператора.Зависимость
СкладКонтролируем факт обмена, учёт — у клиента.Зависимость
ДоставкаПроверяем отклик расчёта, API — у службы.Зависимость
CRMКонтролируем передачу заказов.Зависимость
Повторная продажаОбеспечиваем сохранность данных для повторов.Общий контур
Целостный контур описан на странице раздела; здесь — что находится под наблюдением.
Состав решения
Состав решения
Сначала определяем, что критично, затем настраиваем наблюдение и копии.
01
Определение критичных URL и сценариев
Входные данные
Структура магазина, статистика заказов, перечень способов оплаты и доставки.
Работа
Выбираем адреса и сценарии, отказ которых останавливает продажи; описываем ожидаемый результат каждой проверки.
Результат в системе
Перечень объектов наблюдения с критериями исправности.
Зависимость
Согласование перечня и допустимость тестовых обращений — зона клиента.
Проверка готовности
Для каждого объекта задан критерий исправности, а не только код ответа.
02
Настройка проверок и частоты
Входные данные
Требования к скорости обнаружения, ограничения хостинга по нагрузке.
Работа
Настраиваем интервал проверок, число повторов до подтверждения сбоя и таймауты.
Результат в системе
Проверки выполняются регулярно без ложных срабатываний.
Зависимость
Слишком частые проверки могут ограничиваться хостингом.
Проверка готовности
Проверки выполняются по расписанию, единичный таймаут не вызывает уведомления.
03
Уведомления
Входные данные
Каналы связи, получатели, требования к рабочему времени.
Работа
Настраиваем оповещения в согласованные каналы, задаём правила повторного уведомления и снятия тревоги.
Результат в системе
Уведомление доходит до ответственного лица.
Зависимость
Работоспособность канала уведомлений и готовность получателя реагировать — зона клиента.
Проверка готовности
Тестовое уведомление доставлено всем получателям, сообщение о восстановлении приходит.
04
Контроль домена и сертификата
Входные данные
Данные домена, сертификата и регистратора.
Работа
Настраиваем контроль срока действия с заблаговременным предупреждением.
Результат в системе
Истечение срока не приводит к внезапной недоступности.
Зависимость
Оплата домена и продление сертификата — зона клиента.
Проверка готовности
Предупреждение приходит заранее до истечения срока.
05
Определение объектов копирования
Входные данные
Структура проекта, база данных, каталог загруженных файлов, конфигурация.
Работа
Определяем полный состав копии, исключаем временные и кэш-данные.
Результат в системе
Состав копии позволяет восстановить магазин целиком.
Зависимость
Данные, находящиеся во внешних системах, копируются их владельцами.
Проверка готовности
Каждый объект копирования перечислен, состав согласован.
06
Регламент копирования и хранения
Входные данные
Требования к глубине истории, доступное место, характер изменений данных.
Работа
Задаём периодичность, глубину хранения, место размещения копий и правила ротации.
Результат в системе
Есть выбор точки восстановления в пределах согласованной глубины.
Зависимость
Объём места для копий и его оплата — зона клиента.
Проверка готовности
Копии создаются по расписанию, глубина хранения соответствует регламенту.
07
Контроль успешности копирования
Входные данные
Журналы копирования, размеры и контрольные признаки копий.
Работа
Настраиваем проверку факта создания и целостности копии, уведомление при неудаче.
Результат в системе
Пропущенная или повреждённая копия обнаруживается сразу.
Зависимость
Доступ к журналам копирования на стороне хостинга или сервера.
Проверка готовности
Неудачное копирование вызывает уведомление, журнал доступен.
08
Тест восстановления
Входные данные
Актуальная копия, отдельное окружение для проверки.
Работа
Восстанавливаем магазин из копии в тестовое окружение и проверяем работоспособность ключевых сценариев.
Результат в системе
Подтверждённая пригодность копий.
Зависимость
Наличие окружения для теста и согласование его стоимости — зона клиента.
Проверка готовности
Тест выполнен, результат зафиксирован, найденные пробелы устранены в регламенте.
09
Порядок действий после обнаружения сбоя
Входные данные
Контакты ответственных, доступы, контакты хостинга и внешних сервисов.
Работа
Описываем последовательность действий, порядок эскалации и критерии перехода к восстановлению.
Результат в системе
Регламент реагирования, понятный до аварии.
Зависимость
Сроки реакции хостинга и внешних сервисов вне нашего контроля.
Проверка готовности
Регламент передан, роли и контакты указаны.
10
Разграничение ответственности
Входные данные
Схема размещения магазина, перечень внешних сервисов и API.
Работа
Фиксируем, какие сбои относятся к хостингу, какие к внешним сервисам, какие к сайту.
Результат в системе
Причина определяется быстро, обращения адресуются верно.
Зависимость
Договоры с хостингом и сервисами — зона клиента.
Проверка готовности
Схема ответственности согласована и включена в регламент.
Сценарии использования
Типовые исходные ситуации
Обезличенные схемы. Аудитория — магазины с постоянным потоком заказов.
О сбоях узнают от покупателей
Настраиваем проверки ключевых сценариев и уведомления в рабочий канал.
Копии делает хостинг, но их не проверяли
Определяем состав копии и проводим тест восстановления.
Сайт был недоступен из-за истёкшего сертификата
Подключаем контроль срока домена и сертификата с заблаговременным предупреждением.
Оформление заказа ломалось при работающей главной
Включаем в наблюдение сценарий оформления, а не только доступность страниц.
Нужна возможность вернуться на несколько дней назад
Задаём глубину хранения копий и правила ротации.
В момент аварии никто не знает, что делать
Описываем порядок действий, эскалацию и разграничение ответственности.
Интеграции и зависимости
Что участвует и где границы
Наблюдение показывает проблему, но устраняют её владельцы соответствующих участков.
Хостинг
Доступность сервера и, часто, собственные копии.
Граница: Доступность, оборудование и сроки реакции — зона хостинга; непрерывную доступность мы не обещаем.
Внешние API
Оплата, доставка, обмен с учётной системой.
Граница: Работоспособность и изменения на их стороне — зона владельцев сервисов.
Домен и сертификат
Условие доступности магазина.
Граница: Оплата и продление — зона клиента; мы предупреждаем заранее.
Место хранения копий
Размещение резервных копий.
Граница: Объём, оплата и сохранность площадки хранения — зона клиента.
Канал уведомлений
Доставка сообщения о сбое.
Граница: Работоспособность канала и готовность получателя реагировать — зона клиента.
Данные во внешних системах
Заказы и клиенты в CRM, документы в учётной системе.
Граница: Копирование таких данных выполняется средствами их владельцев.
Этапы работы
Этапы работы
Регламент считается работающим только после теста восстановления.
01
Разбор контура
Изучаем размещение магазина, интеграции и внешние сервисы.
02
Перечень объектов наблюдения
Определяем критичные URL и сценарии с критериями исправности.
03
Настройка проверок
Задаём частоту, таймауты и правила подтверждения сбоя.
04
Уведомления
Настраиваем каналы, получателей и тестируем доставку.
05
Домен и SSL
Подключаем контроль сроков с предупреждением.
06
Состав копий
Определяем объекты копирования и исключения.
07
Регламент копий
Задаём частоту, глубину хранения и место размещения.
08
Контроль успешности
Настраиваем проверку копий и уведомление при неудаче.
09
Тест восстановления
Поднимаем магазин из копии и проверяем сценарии.
10
Регламент реагирования
Описываем порядок действий и разграничение ответственности.
Сроки заранее не фиксируем. Мониторинг сокращает время обнаружения сбоя, но не предотвращает его; непрерывную доступность и нулевую потерю данных мы не обещаем.
Что проверяется при сдаче
Что проверяется при сдаче
Проверяем не наличие настроек, а фактическую работу регламента.
Перечень проверяемых URL и сценариев согласован, для каждого задан критерий исправности.
Проверяется не только доступность страниц, но и сценарий оформления заказа.
Частота проверок и правила подтверждения сбоя настроены, единичный таймаут не вызывает тревогу.
Тестовое уведомление доставлено всем получателям в согласованный канал.
Сообщение о восстановлении работы приходит после устранения сбоя.
Контроль срока действия домена и сертификата настроен, предупреждение приходит заранее.
Состав резервной копии согласован и включает файлы, базу данных, загруженные изображения и конфигурацию.
Периодичность, глубина хранения и место размещения копий соответствуют регламенту.
Неудачное или повреждённое копирование вызывает уведомление.
Тест восстановления выполнен: магазин поднят из копии, ключевые сценарии проверены.
Интервал между копиями и возможная потеря данных внутри него зафиксированы явно.
Порядок действий после обнаружения сбоя передан, роли и контакты указаны.
Разграничение ответственности хостинга, внешних API и сайта согласовано.
Нет горизонтальной прокрутки на 1440, 1280, 1024, 768, 390 и 360 px.
Кому подходит
Кому подходит
Магазины с постоянным потоком заказов
Решение имеет смысл при таких исходных данных
Простой магазина напрямую означает потерю заказов.
Есть доступы к сайту, серверу и панели хостинга.
Есть место для хранения копий или готовность его выделить.
Есть рабочий канал, в котором уведомления действительно читают.
Есть ответственные лица, готовые реагировать на оповещение.
Есть понимание, что мониторинг сокращает время обнаружения, но не предотвращает сбои.
Когда нужен другой формат
Когда точнее подойдёт другая страница
Указываем прямо, чтобы объём соответствовал задаче.
Нужны регулярные исправления и развитие магазина по регламенту.
Более короткий интервал обнаружения означает больший объём наблюдения.
Объём и состав копий
Размер базы и каталога изображений влияет на время копирования и место хранения.
Глубина хранения
Большая история копий требует больше места и более сложной ротации.
Периодичность теста восстановления
Каждый тест — это отдельная работа с развёртыванием окружения.
Сложность контура
Несколько серверов и внешних сервисов увеличивают объём наблюдения и разграничения.
Оценку формируем после разбора контура магазина и требований к глубине копий. Стоимость места хранения и услуг хостинга в оценку не входит и оплачивается клиентом напрямую.
Вопросы и ответы
Вопросы о мониторинге и копиях
Нет. Мониторинг сокращает время обнаружения сбоя, но не предотвращает его. Доступность обеспечивает хостинг, а работоспособность оплаты, доставки и других сервисов — их владельцы. Мы делаем так, чтобы о проблеме узнали быстро и по заранее описанному порядку начали действовать, а не чтобы сбоев не было вовсе — обещать это невозможно.
Потому что главная может открываться при полностью неработающем оформлении заказа: сломался шаг оплаты, не отвечает расчёт доставки, оборвалось соединение с учётной системой. Такие сбои напрямую останавливают продажи и при проверке одного адреса остаются незамеченными. Поэтому в перечень наблюдения входят и страницы, и сценарии.
Файлы и код, база данных, загруженные изображения и конфигурация — состав согласуется письменно. Пропуск любого объекта делает восстановление неполным: например, без каталога загруженных файлов магазин поднимется без изображений товаров. Данные, которые живут во внешних системах вроде CRM, копируются средствами их владельцев.
Нет. Между двумя копиями всегда есть интервал, и данные, появившиеся внутри него, при восстановлении могут быть утрачены. Мы не скрываем этот интервал, а согласуем его: чем чаще копии, тем меньше возможная потеря, но тем больше нагрузка и место хранения. Величину интервала фиксируем явно, чтобы вы понимали риск.
Потому что факт наличия копии ничего не гарантирует. Копия может быть неполной, повреждённой или созданной с ошибкой конфигурации, и это выясняется в самый неподходящий момент. Мы периодически поднимаем магазин из копии в отдельном окружении и проверяем ключевые сценарии: только после этого копию можно считать рабочей.
Иногда достаточно, но проверить это нужно, а не предполагать. Важно понимать состав копии, глубину хранения, доступность копии по вашему запросу и возможность восстановиться из неё. Кроме того, хранение копий только на той же площадке, что и сам магазин, снижает их ценность при проблемах с самой площадкой.
В согласованный рабочий канал и только после подтверждения сбоя повторными проверками — единичный таймаут тревогу не вызывает. Сообщение о восстановлении работы тоже приходит. Важное условие: канал должен читаться, а получатель должен быть готов действовать, иначе даже быстрое обнаружение не сократит простой.
Действует регламент, который описан заранее: фиксация симптомов, оценка масштаба, ограничение дальнейшего ущерба, определение зоны — сайт, хостинг или внешний сервис, — эскалация и, при необходимости, переход к восстановлению. Смысл в том, чтобы в момент аварии не тратить время на согласование порядка действий.
Следующий шаг
Обсудим мониторинг и копии
Напишите, где размещён магазин, какие копии есть сейчас и какая глубина истории нужна. Разберём контур и предложим регламент.