Час простоя сайта считают по потерянной марже и восстановлению, а не по полной выручке

Что считать стоимостью часа простоя? Сравните два сценария: система работает и система сломалась. В ущерб входят деньги, которые бизнес потерял или потратил дополнительно из-за сбоя.

Маржа здесь означает выручку за вычетом переменных расходов, которых удалось избежать. ACCA использует такой маржинальный доход для анализа затрат; определение сверили 7 октября 2026.

Товар не продали, закупку и доставку по нему не оплатили. Эти деньги не потеряны. Если товар уже закуплен и испортился, его стоимость придётся учесть отдельно.

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

Сломалась только оплата, а каталог открывается? Считайте затронутые покупки. Число посетителей всего сайта ещё не говорит, сколько денег потеряла касса.

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

Все числа магазина ниже условные, расчёт составлен 7 октября 2026. Обычно за сопоставимый час он продаёт на 100 000 ₽ без НДС. Сбой затронул 60 % ожидаемых продаж.

Половина затронутой выручки вернулась после починки без дополнительных потерь. Невосстановленная выручка составила 30 000 ₽. При марже 30 % магазин потерял 9 000 ₽ маржинального дохода.

Исправление потребовало ещё 12 000 ₽, компенсации и ручная обработка ещё 3 000 ₽. Итого 24 000 ₽ за этот инцидент. Это условный пример, а не кейс нашего клиента.

Вернувшиеся заказы меняют результат сильнее, чем точность секундомера. В этом же примере при полном уходе затронутых продаж потери составят 33 000 ₽. Если вернётся 80 %, получится 18 600 ₽.

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

Неизвестную долю возврата лучше показать диапазоном. Предположение «все вернутся завтра» превращает реальную поломку в нулевую потерю на бумаге.

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

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

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

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

Google SRE называет проверку внешнего поведения глазами пользователя отдельным видом мониторинга. Определение сверили 7 октября 2026. Ответ сервера дополняют проверкой нужного действия.

Наш опыт относится к vibecoding.ru, где инженер ведёт машину ИИ-агентов. Денежных замеров клиентов нет. Наши два сбоя показывают, почему починку и доступность проверяют отдельно.

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

Восстановление упавшего сайта начинают с границы сбоя, затем проверяют основной сценарий.

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

После починки добавляют тест на этот сбой. Он ловит повторение; внешняя проверка следит за доступностью. Ответственность за ошибки ИИ разобрана отдельно.

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

Продолжим условный пример, а не прогноз для клиента. До мер ожидаются шесть сбоев по 24 000 ₽ за год. После мер предполагаются два по 18 000 ₽.

Ожидаемые потери снизятся со 144 000 до 36 000 ₽ в год. Разница 108 000 ₽ даёт 9 000 ₽ в месяц для сравнения с расходами на меры. На границе равенства экономического выигрыша ещё нет.

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

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

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

В подписке на разработку можно поставить задачу устранить повторную поломку и добавить проверку доступности. Граница живой страницы на 7 октября 2026: ночные дежурства в подписку не входят.

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

Согласуйте время реакции и критерий восстановления до аварии. Пример выпуска исправления за 20 минут не заменяет этих условий. Быстрая правка не убирает ожидание дежурного.