Сколько стоит простой сайта: как считать потери от недоступности, медленной загрузки и сбоев

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

Но считать ущерб по формуле «средняя выручка за час × время простоя» тоже неправильно. Ночной сбой и отказ во время рекламной кампании стоят по-разному. Часть покупателей возвращается позже. А иногда сайт вообще не падает: главная страница открывается, но корзина или форма заявки перестают работать.

Поэтому полезнее задавать другой вопрос: сколько бизнес-операций сайт не смог выполнить из-за сбоя и какая часть этих потерь оказалась невосстановимой?

Простой — это не только ошибка 500

Самый очевидный сценарий — сайт полностью перестал открываться. Но для бизнеса не менее значимы частичные отказы.

Каталог может работать, а корзина — нет. Пользователь оформляет заказ, но не может перейти к оплате. Форма визуально отправляется, однако данные не доходят до CRM. API периодически возвращает ошибки. На определённой версии браузера перестаёт работать кнопка оформления.

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

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

Именно поэтому в SRE-практике доступность рассматривают через успешность запросов, задержки, ошибки и показатели, отражающие фактический пользовательский результат.

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

Влияние простоя сайта на продажи, заявки, рекламу и оплату.

Начинать расчёт нужно с бизнес-операции

Универсальной стоимости минуты простоя не существует.

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

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

Для e-commerce базовая модель выглядит так:

Выручка под риском = трафик × обычная конверсия × средний чек × доля затронутого трафика.

Возьмём условный пример.

За час магазин обычно получает около 900 сеансов. Конверсия сопоставимого трафика — 2%, средний чек — 5 000 рублей.

Ожидаемый результат:

900 × 2% = 18 заказов.

18 × 5 000 = 90 000 рублей выручки.

Если оформление заказа полностью не работает 15 минут, а трафик распределяется примерно равномерно, под риском оказывается около:

90 000 × 15 / 60 = 22 500 рублей.

Но записывать в отчёт «бизнес потерял 22 500 рублей» пока рано.

Часть пользователей может вернуться позже. Кто-то воспользуется другим каналом. Кроме того, выручка и прибыль — разные показатели.

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

Невосстановленные потери = ожидаемый результат без инцидента − фактический результат с учётом последующих конверсий.

Как не надо считать: средняя выручка за час

Представим другой условный проект с выручкой 72 млн рублей за 30 дней.

Если просто разделить её на 720 часов, получится: 100 000 рублей в час.

Дальше возникает соблазн решить, что любой час недоступности стоит бизнесу именно столько.

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

А если проблема возникла в пиковый час распродажи, когда обычно проходит 250 000 рублей выручки, те же 100 000 рублей, наоборот, значительно занизят масштаб.

Поэтому baseline лучше брать из действительно сопоставимых периодов: учитывать день недели, время суток, источник трафика, устройства, регион и тип страницы.

Для сезонного бизнеса дополнительно важны акции, праздники и периоды повышенного спроса.

Рекламный бюджет во время сбоя

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

Поэтому отдельно стоит считать расходы на платный трафик, попавший в проблемный период.

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

Есть ещё один важный нюанс — встроенный мониторинг рекламных платформ не заменяет мониторинг бизнес-сценариев.

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

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

Получается принципиальная разница:

- техническая доступность: страница отвечает;
- бизнес-доступность: пользователь способен совершить целевое действие.

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

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

В Google Ads качество посадочной страницы также учитывается при диагностике рекламы, а сама платформа рекомендует уделять внимание в том числе мобильному пользовательскому опыту. Но это не означает, что единичный outage автоматически повысит CPC: прямой универсальной зависимости здесь нет.

Когда сайт не упал, а просто стал медленным

С экономической точки зрения это один из самых сложных сценариев.

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

Здесь особенно опасны формулы вроде «каждая дополнительная секунда снижает конверсию на X%». Единого коэффициента для всех сайтов нет.

Эффект зависит от устройства, аудитории, соединения, страницы, источника трафика и самого пользовательского сценария.

Поэтому стоимость деградации лучше оценивать по собственным данным:

Потери от деградации = трафик затронутого сегмента × разница в конверсии × ценность конверсии.

Например, команда может отдельно сравнить mobile-сегменты с разными значениями LCP.

Допустим, в условном проекте за месяц было 15 000 мобильных посещений. В сегменте с LCP менее 2,5 секунды конверсия составила 1,9%, а среди посещений с LCP выше 3,5 секунды — 1,2%.

Разница составляет 0,7 процентного пункта.

Если просто применить её к потоку в 15 000 посещений:

15 000 × 0,7% = 105 конверсий.

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

Поэтому такие данные нужны для поиска проблемы и проверки гипотезы, а не для мгновенного объявления всей разницы финансовым ущербом.

Почему mobile и desktop нужно разделять

Среднее значение по всему трафику способно скрыть проблему.

На мощном рабочем ноутбуке сайт работает быстро. На более слабом смартфоне при нестабильном соединении тот же интерфейс реагирует заметно хуже. Ошибка JavaScript может вообще проявляться только в конкретном браузере.

Поэтому производительность и конверсию полезно сегментировать хотя бы по:

1. mobile и desktop;
2. ОС и браузерам;
3. ключевым страницам;
4. географии;
5. источникам трафика.

Google использует в Core Web Vitals три основных показателя пользовательского опыта: LCP, INP и CLS. Рекомендованные границы «хорошего» опыта — LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1; оценка строится по 75-му процентилю пользовательских загрузок.

Но Core Web Vitals — не калькулятор денег. Они помогают найти проблемный сегмент, после чего технические показатели нужно связывать с реальной конверсией проекта.

Схема расчёта финансовых потерь от сбоя или замедления сайта.

Uptime тоже нужно переводить в понятные величины

Проценты доступности выглядят абстрактно. Для условного 30-дневного месяца:

Таблица с уровнями доступности сайта от 99% до 99,99% и соответствующим допустимым временем недоступности.

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

Если сайт формально доступен, но 5% checkout-запросов заканчиваются ошибкой, бизнес всё равно несёт потери.

Поэтому коммерческому проекту полезно контролировать два слоя: доступность инфраструктуры и успешность критических пользовательских сценариев.

Почему CPU и RAM недостаточно

Представим ситуацию: CPU загружен на 35%, свободной памяти достаточно, диск работает нормально.

Но API оформления заказа возвращает ошибку каждому пятому пользователю.

Инфраструктурный дашборд выглядит спокойно. Для бизнеса в это время идёт полноценный инцидент.

Google SRE рекомендует обращать внимание как минимум на четыре базовых сигнала: latency, traffic, errors и saturation — задержку, трафик, ошибки и насыщение ресурсов.

Для коммерческого проекта к ним стоит добавить собственные проверки:

1. работает ли поиск;
2. добавляется ли товар в корзину;
3. проходит ли авторизация;
4. отправляется ли форма;
5. отвечает ли API;
6. можно ли завершить оформление заказа.

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

Сколько времени бизнес может ждать восстановления

Здесь появляются два полезных термина — RTO и RPO.

RTO — Recovery Time Objective: сколько времени система может восстанавливаться до того момента, когда последствия становятся неприемлемыми для бизнеса.

Проще: если бизнес может ждать восстановления максимум 30 минут — RTO составляет 30 минут.

RPO — Recovery Point Objective: до какой точки во времени необходимо восстановить данные.

То есть если допустимо потерять максимум последние пять минут изменений — целевой RPO составляет пять минут.

Это уже не технические аббревиатуры ради аббревиатур, а конкретные требования к инфраструктуре.

Из них можно выводить частоту резервного копирования, архитектуру хранения данных, мониторинг и процесс реагирования.

Сам факт существования бэкапа ещё не означает, что задача решена. Нужно понимать, когда сделана последняя копия, что в неё попадает и сколько занимает реальное восстановление.

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

Этапы восстановления сайта после сбоя с обозначением RTO и RPO.

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

Для первого отчёта не нужна сложная финансовая модель.

1. Зафиксировать время и масштаб.Когда началась проблема, когда закончилась, что именно не работало?

2. Определить затронутый трафик.Сколько пользователей, сеансов или запросов пришлось на этот период?

3. Найти корректный baseline.Что обычно происходит в сопоставимый день и час?

4. Рассчитать ожидаемый результат.Сколько заказов, заявок или оплат должно было произойти?

5. Определить выручку под риском.Сколько результата отсутствовало непосредственно во время инцидента?

6. Проверить отложенные конверсии.Не использовать условные «30% пользователей вернутся», а посмотреть реальные данные.

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

Вместо фразы «сайт лежал 18 минут» руководство тогда получает значительно более полезную картину:

18 минут сбоя - 420 затронутых визитов - 9 ожидаемых заказов не состоялись во время проблемы - 4 были оформлены позднее - 5 остались потенциально потерянными.

Дальше финансовый эффект можно уточнить по среднему чеку, марже и другим метрикам компании.

Что фиксировать сразу после сбоя

Таблица с ключевыми показателями, которые нужно зафиксировать сразу после сбоя сайта: время, масштаб, затронутые функции, трафик, baseline и фактические конверсии.

Что добавить после анализа

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

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

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

Главный вопрос после сбоя

Техническая команда видит ошибки, latency и загрузку ресурсов. Маркетинг — конверсию и рекламные расходы. Руководитель — выручку и операционные риски.

Связать эти уровни можно одной последовательностью:

техническая проблема - затронутый пользователь - неуспешная операция - невосстановленная конверсия - финансовый эффект.

После этого разговор об инфраструктуре становится конкретнее.

Не «нужен ли более мощный сервер на всякий случай», а «сколько бизнес уже теряет из-за текущих ограничений».

Не «есть ли у нас резервная копия», а «сколько данных допустимо потерять и за какое время их нужно восстановить».

И не «сайт был недоступен всего десять минут», а «сколько значимых операций эти десять минут сорвали и сколько из них мы смогли вернуть».

Именно такую цифру имеет смысл использовать, когда бизнес решает, сколько инвестировать в мониторинг, производительность, резервирование и скорость восстановления.

Для руководителя

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