Сколько компании стоит простой сайта и как договориться о восстановлении

У недоступности бывает разная цена

Остановка оформления заказа может обходиться дороже, чем недоступность всего сайта ночью. Оценивать простой стоит по действиям, которые компания теряет в конкретное время: принять оплату, получить обращение, подтвердить остаток или выдать документы клиенту. Такой расчёт помогает договориться о восстановлении и понять, за какую скорость действительно стоит платить.

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

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

В руководстве NIST SP 800-34 Rev. 1 анализ влияния на деятельность назван Business Impact Analysis, или BIA. Документ предназначен для информационных систем федеральных ведомств США, а здесь его понятия помогают разделить задачу восстановления на понятные части. Это не нормативный срок ремонта российского магазина. Руководитель выбирает допустимые последствия вместе с сотрудниками продаж и эксплуатации. Начните с одного важного действия покупателя: его проще связать с деньгами и временем, чем абстрактную «работоспособность сайта».

Как посчитать потерянный вклад продаж

Выручка за час — слишком грубая оценка ущерба. Из неё оплачивают товар и другие расходы, а часть покупок просто переносится, поэтому в сценарном расчёте лучше считать вклад несостоявшихся заказов после связанных с ними затрат и отдельно оценивать возвращение покупателей. Иначе защита сайта может выглядеть выгоднее, чем она есть.

Расчётный пример для обсуждения

Возьмём условные числа: без сбоя магазин ожидал бы 40 оплаченных заказов, средний вклад одного заказа после переменных расходов составляет 900 рублей. Предположим, что 12 заказов позже восстановятся через сайт или другой канал. Потерянный вклад получится равным 28 × 900 = 25 200 рублей. Это сценарий, а не измеренный результат компании. Отдельная строка с 12 вернувшимися заказами делает спорное предположение видимым и позволяет пересчитать оценку.

Возврат покупателей неизвестен заранее. Полезно показать диапазон потерь при разных долях отложенных покупок, а не прятать неопределённость внутри единственной суммы с точностью до рубля.

Базу лучше брать из сопоставимых часов и дней, учитывая ассортимент, наличие и активные рекламные размещения. Средняя месячная выручка сглаживает именно те пики, ради которых компания обсуждает быстрое восстановление. Если оплаченных заказов мало, расчёт по одному часу будет сильно колебаться. Тогда можно объединить похожие периоды и оставить широкий диапазон. Точность исходных данных важнее количества знаков после запятой.

Дополнительные расходы и двойной счёт

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

Однако расход на рекламу нельзя автоматически прибавлять к уже посчитанному вкладу, если та же рекламная затрата была вычтена при его расчёте. Иначе получится двойной счёт. Сначала бухгалтер или финансовый специалист уточняет состав среднего вклада заказа. Затем команда добавляет только расходы, которых в нём ещё нет. Например, отдельно оплаченные аварийные работы подрядчика или дополнительную смену сотрудников.

Что считать отдельной строкой

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

У каждой денежной строки нужны основание расчёта и сотрудник, который подтвердит число. Переработку считают по часам и ставке, испорченный товар — по учётной стоимости, а затраты на возврат денег включают только в том объёме, который действительно возникает у магазина. Репутационные последствия лучше сначала описать отдельно: жалобы, отказы от повторного заказа, нагрузка на поддержку. Придуманный процент от оборота не объясняет этих событий. Пока компания не умеет обосновать денежную оценку, я бы оставил её пустой и перечислил сведения, которые помогут уточнить ущерб после реального сбоя.

Учёт затрат должен сохранять смысл. Один и тот же сорванный заказ не превращается одновременно в потерю полной выручки, потерю полной маржи и отдельную «стоимость клиента», иначе итог многократно увеличивается без новых событий.

Время восстановления и возраст данных

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

NIST использует RTO — Recovery Time Objective, целевое время восстановления доступности ресурса. RPO — Recovery Point Objective — относится к точке, до которой можно восстановить данные. На языке магазина первый вопрос звучит как «сколько ждать рабочее оформление», второй — «какой промежуток новых заказов допустимо потерять». Уменьшение одного срока не уменьшает другой автоматически. Быстрое развёртывание старой копии решает только часть задачи.

Есть и предел для деятельности. MTD, Maximum Tolerable Downtime, обозначает максимально терпимую длительность нарушения процесса, поэтому при его оценке учитывают последствия после технического запуска, например время на разбор накопленных заказов и возвращение сотрудников к обычной работе.

Для магазина полезно назначить отдельные требования каталогу, оформлению и обмену с учётной системой. Если каталог восстановлен, но новые заказы не доходят сотрудникам, основной процесс ещё не вернулся. Предпочтительнее описать работающее действие целиком, чем принять открытие главной страницы за завершённый ремонт. Отсчёт также требует ясности: от обнаружения сбоя, регистрации обращения или начала работ. Разные точки старта делают одинаковые обещанные часы несопоставимыми.

Какая защита оправдана экономически

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

Резервная копия помогает вернуть данные, но её ещё надо развернуть и подключить к рабочим зависимостям. Дублирующий сервер может сократить переключение, однако ошибка в данных способна затронуть обе работающие копии. Наблюдение за доступностью сокращает время до обнаружения, а не длительность самого ремонта. У каждого средства своя роль. Подрядчик связывает предлагаемую меру с той частью времени или ущерба, которую она уменьшает.

Сравнивайте готовые способы восстановления. Смета только на дополнительное оборудование хуже предложения, где есть проверенный порядок переключения, доступы, ответственный и испытание принятия заказа, потому что во время сбоя работают именно эти связи.

Экономическая граница особенно полезна при выборе дежурства. Если ночью сайт принимает существенную часть заказов, поддержка только в рабочие часы оставляет длинный период без реакции. Если ночной поток невелик и обращения могут дождаться утра, круглосуточная работа может оказаться дороже её ожидаемой пользы. Для решения нужны данные по времени покупок и последствиям задержки, а не общий страх простоя. При неизвестной вероятности аварии честнее сравнить несколько сценариев частоты, чем выдавать точную годовую экономию.

Несколько средств могут закрывать разные причины остановки. Выбранный набор надо испытать: именно пробное восстановление показывает, помещаются ли люди, доступы, файлы и внешние сервисы в обещанный срок.

Что закрепить в порядке восстановления

Документ о восстановлении полезен, когда по нему можно действовать. Для магазина в нём перечисляют затронутые функции, ответственных, порядок связи и критерий возвращения к работе, причём результат подтверждает сотрудник, который умеет провести заказ до нужного состояния в учётной системе. Технического сообщения «сервер поднят» мало.

NIST разделяет работу при нарушении на активацию и уведомление, восстановление и возвращение к обычной эксплуатации. Эти три части удобно перевести в обязанности команды. Кто получает сигнал и решает начать аварийные работы? Кто восстанавливает систему и сообщает о ходе? Кто принимает результат и разрешает вернуть рекламу на обычные страницы? Ответы закрывают промежутки, в которых авария уже известна, а работа ещё не началась.

• Срок реакции с указанием часов обслуживания и канала регистрации обращения.
• Цель восстановления по конкретной функции и событие начала отсчёта.
• Допустимая потеря данных, перечень копий и способ сверки новых заказов.
• Условия привлечения хостинга, разработчика и владельцев внешних сервисов.
• Состав итогового отчёта: причина, действия, фактическое время и оставшиеся расхождения.

Доступы принадлежат компании. Если пароль от критичного сервиса знает только отсутствующий сотрудник, обещание быстрого ремонта упирается в организационную задержку, которую резервный сервер не устранит.

Приёмку лучше проводить по заранее подготовленному сценарию на безопасной среде. В нём проверяют открытие каталога, оформление, получение заказа сотрудником и состояние данных, а реальную оплату заменяют тестовым режимом платёжной системы. Отдельно отмечают действия, которые пришлось выполнять вручную. Это материал для улучшения порядка, а не повод скрыть неудачное испытание. Обсудить такой объём можно с исполнителем поддержки сайта, приложив расчёт последствий и перечень важных функций.

Решение выражается в допустимом ущербе

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

Начальный результат умещается в небольшое описание: какая функция останавливается, что компания теряет, сколько времени готова ждать и какой промежуток данных способна восстановить вручную. Рядом стоят исходные цифры и допущения расчёта. После этого предложения поддержки становятся сопоставимыми. Один подрядчик обещает ответить быстрее, другой сокращает время ремонта, третий уменьшает потерю записей. Выбор опирается на ту проблему, которая обходится компании дороже.

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