Простой сайта — это не абстрактная техническая проблема, а конкретные финансовые потери. Каждая минута недоступности оборачивается упущенной выручкой, испорченной репутацией и дополнительными расходами на устранение последствий. При этом большинство владельцев сайтов не могут назвать даже приблизительную стоимость часа простоя. В этой статье разберём формулы расчёта потерь для разных типов бизнеса и покажем, как обосновать инвестиции в мониторинг.
Почему расчёт потерь важен
Без количественной оценки простоя невозможно:
- Обосновать бюджет на мониторинг, резервирование и инфраструктуру
- Приоритизировать задачи по надёжности
- Коммуницировать с руководством и инвесторами на языке цифр
- Оценивать эффективность внедрённых мер (сокращение MTTR, предотвращение инцидентов)
Расчёт не требует сложной аналитики. Достаточно базовых данных из бухгалтерии и аналитики. Точность ±20% — уже полезный результат для принятия решений.
Базовые формулы расчёта
Прямые потери выручки
Для бизнеса, где сайт напрямую генерирует доход, базовая формула проста:
Потери = (Выручка за период / Часы в периоде) × Часы простоя
Пример для интернет-магазина с выручкой 5 000 000 ₽/месяц:
5 000 000 ₽ / (30 дней × 24 часа) = 6 944 ₽/час
Один час простоя в среднем обходится в ~7 000 ₽. Но это усреднённая оценка. Реальные потери зависят от времени суток, дня недели и сезона.
Учёт неравномерности трафика
Трафик и конверсии распределены неравномерно. Пиковые часы (обычно 12:00–21:00 по местному времени) приносят 60–70% выручки. Если сайт падает в пик, потери выше среднего:
Потери_пик = Потери_средние × Коэффициент_пика (1.5–2.0)
Для того же магазина час простоя в пиковое время может стоить 10 000–14 000 ₽.
Формула с учётом конверсии
Более точный расчёт требует данных аналитики:
Потери = Посетители_за_период × Конверсия × Средний_чек × (Часы_простоя / Часы_в_периоде)
Пример:
- 100 000 посетителей в месяц
- Конверсия 2%
- Средний чек 3 000 ₽
- 2 часа простоя
100 000 × 0.02 × 3 000 × (2 / 720) = 16 667 ₽
Расчёт по типам бизнеса
E-commerce и интернет-магазины
Для интернет-магазинов потери наиболее прозрачны — каждая минута простоя равна упущенным заказам.
| Показатель | Малый магазин | Средний магазин | Крупный маркетплейс |
|---|---|---|---|
| Выручка/мес | 500 000 ₽ | 5 000 000 ₽ | 50 000 000 ₽ |
| Потери/час (средние) | 694 ₽ | 6 944 ₽ | 69 444 ₽ |
| Потери/час (пик) | 1 400 ₽ | 14 000 ₽ | 140 000 ₽ |
| 1% даунтайма/мес (7.2 ч) | 5 000 ₽ | 50 000 ₽ | 500 000 ₽ |
Дополнительные факторы для e-commerce:
-
Потеря привлечённого трафика. Если вы платите за рекламу (Яндекс.Директ, VK Реклама), трафик во время простоя уходит к конкурентам. Стоимость привлечения клиента (CAC) теряется полностью.
-
Корзины и отложенные заказы. Пользователи, добавившие товар в корзину, могут не вернуться. Исследования показывают, что 70–80% брошенных корзин не конвертируются при повторном визите.
-
Репутационные потери. Негативные отзывы, обсуждения в соцсетях, переход к конкурентам — сложно оценить количественно, но для брендовых магазинов это существенно.
SaaS и подписочные сервисы
Для SaaS-продуктов формула сложнее: выручка приходит по подписке, а не по каждой транзакции. Но простой влияет на несколько метрик.
Прямые потери:
Потери = (MRR / 720) × Часы_простоя × Доля_активных_пользователей
MRR (Monthly Recurring Revenue) — месячная выручка от подписок. Доля активных пользователей — те, кто реально использует продукт в данный момент (обычно 20–40%).
Пример: SaaS с MRR 1 000 000 ₽, 30% активных пользователей, 4 часа простоя:
(1 000 000 / 720) × 4 × 0.3 = 1 667 ₽ прямых потерь
Прямые потери для SaaS часто ниже, чем для e-commerce. Но косвенные — выше:
| Фактор | Влияние |
|---|---|
| Churn (отток) | Клиенты корпоративного сегмента могут расторгнуть контракт при нарушении SLA |
| Компенсации | По SLA часто предусмотрены кредиты (credit) за простой |
| Репутация | Для B2B один публичный инцидент может стоить крупного контракта |
| Поддержка | Рост нагрузки на саппорт, overtime сотрудников |
Расчёт SLA-компенсаций:
Типичный SLA для SaaS: 99.9% аптайма. При нарушении — возврат части оплаты.
99.9% = допустимо 43.2 минуты простоя в месяц
99.99% = допустимо 4.32 минуты простоя в месяц
При 99.5% аптайма (3.6 часа простоя) многие контракты предусматривают 10–25% кредита за месяц. Для MRR 1 000 000 ₽ это 100 000–250 000 ₽ прямых потерь.
Медиа и контент-сайты
Для новостных порталов, блогов и медиа-проектов модель иная: выручка идёт от рекламы и подписок, а не от транзакций.
Формула для рекламной модели:
Потери = RPM × (Трафик_за_час / 1000) × Часы_простоя
RPM (Revenue Per Mille) — доход с 1000 показов. Трафик за час — среднее число посетителей.
Пример: Сайт с 50 000 визитов в день, RPM 150 ₽:
50 000 / 24 = 2 083 визита/час
150 × (2 083 / 1000) × 2 = 625 ₽ за 2 часа простоя
Для крупных медиа с миллионами визитов потери исчисляются десятками и сотнями тысяч рублей за час простоя в пиковое время.
Специфика медиа: Пропущенная новость не восполняется. Если сайт упал во время важного события, трафик ушёл к конкурентам навсегда.
Корпоративные сайты и лендинги
Сайт-визитка или лендинг не генерирует прямую выручку, но его простой тоже стоит денег:
-
Потеря лидов. Каждый визит — потенциальный клиент. Стоимость лида (CPL) × количество визитов за период простоя.
-
Репутация. Клиент или партнёр, не сумевший открыть сайт, может усомниться в надёжности компании.
-
Внутренние процессы. Если на сайте размещены формы заявок, каталоги, калькуляторы — сотрудники не могут работать.
SLA: расчёт целевого аптайма
Service Level Agreement определяет допустимый уровень простоя. Переведём проценты в минуты:
| Аптайм | Простой в месяц | Простой в год |
|---|---|---|
| 99% | 7.2 часа | 3.65 дня |
| 99.5% | 3.6 часа | 1.8 дня |
| 99.9% | 43.2 минуты | 8.76 часа |
| 99.95% | 21.6 минуты | 4.38 часа |
| 99.99% | 4.32 минуты | 52.6 минуты |
Как выбрать целевой SLA:
- Оцените стоимость часа простоя по формулам выше.
- Сравните с стоимостью обеспечения более высокого аптайма (резервирование, CDN, премиум-хостинг).
- Учтите ожидания клиентов. B2B-клиенты часто требуют 99.9%+. Для лендинга может быть достаточно 99%.
Пример расчёта окупаемости мониторинга:
Стоимость Uptime Monitor — 50 токенов в месяц. Допустим, это 500 ₽. Если один предотвращённый инцидент (раннее обнаружение проблемы) экономит 2 часа простоя для магазина с выручкой 5 млн/мес — экономия 14 000 ₽. Окупаемость 28:1.
Скрытые и отложенные потери
Не все потери видны сразу.
SEO-последствия
Поисковые системы обходят сайты регулярно. Если в момент обхода Googlebot получает 5xx:
- Страница может временно выпасть из индекса
- Краулинговый бюджет сокращается
- При повторных инцидентах — снижение позиций
Восстановление позиций занимает недели или месяцы. Стоимость — упущенный трафик за весь период.
Доверие пользователей
Исследования показывают: 88% пользователей не вернутся на сайт после неудачного опыта. Один инцидент может стоить не только прямых потерь, но и постоянного оттока части аудитории.
Стоимость устранения
Срочное исправление в нерабочее время стоит дороже: overtime разработчиков, экстренный вызов DevOps, возможные переплаты за срочную поддержку хостинга.
Практический калькулятор
Сводная формула для быстрой оценки:
Потери = Базовые_потери × K_время × K_тип × K_дополнительно
Где:
- Базовые потери — выручка за период / часы в периоде
- K_время — 1.0 (ночь), 1.5 (день), 2.0 (пик)
- K_тип — 1.0 (e-commerce), 0.3 (SaaS), 0.1 (медиа/реклама)
- K_дополнительно — 1.2–1.5 (SEO, репутация, поддержка)
Чек-лист для расчёта потерь вашего сайта:
- Соберите данные: месячная выручка, трафик, конверсия, средний чек
- Рассчитайте базовую стоимость часа простоя
- Определите пиковые часы и коэффициент
- Умножьте на типичную длительность инцидента (без мониторинга — 30–60 минут, с мониторингом — 5–15 минут)
- Добавьте 20–50% на косвенные потери
Частые ошибки в расчётах
Ошибка 1: Игнорирование косвенных потерь
Прямая выручка — только часть. SEO-последствия, репутация, отток клиентов, стоимость срочного устранения — добавляют 20–50% к базовому расчёту.
Ошибка 2: Использование только средних значений
Средняя выручка за час — усреднение по ночи и дням, будням и выходным. При оценке рисков используйте пиковые коэффициенты.
Ошибка 3: Забывать про сезонность
Чёрная пятница, конец квартала, праздники — стоимость простоя в эти периоды в 2–5 раз выше. Планируйте инфраструктуру с учётом пиков.
Ошибка 4: Не учитывать время обнаружения
Без мониторинга вы узнаёте о проблеме от пользователей — через 30–60 минут или больше. С мониторингом — за 5–10 минут. Разница в длительности простоя напрямую влияет на потери.
Ошибка 5: Считать «маленький» бизнес незначительным
Даже при выручке 100 000 ₽/месяц час простоя стоит ~140 ₽. Четыре инцидента в год по 2 часа — 1 120 ₽. При стоимости мониторинга 500 ₽/мес окупаемость есть. И это без учёта репутационных потерь.
Инструменты мониторинга
Расчёт потерь — первый шаг. Второй — минимизация рисков.
Uptime Monitor — мониторинг доступности сайта с проверками каждые 5 минут. Мгновенные уведомления в Telegram при падении. Чем раньше вы узнаете о проблеме, тем меньше длительность простоя и потери.
SSL Monitor — мониторинг срока действия SSL-сертификатов. Истечение сертификата — частая причина «внезапного» даунтайма. Заблаговременное предупреждение за 14–30 дней позволяет обновить сертификат без простоя.
Регулярный мониторинг не предотвращает технические сбои, но сокращает время обнаружения с часов до минут. При стоимости часа простоя 7 000 ₽ разница между 60 и 5 минутами — 6 400 ₽ сэкономленных за один инцидент.
Реальные кейсы и сценарии
Кейс 1: Интернет-магазин электроники
Выручка 12 млн ₽/месяц, конверсия 1.5%, средний чек 8 000 ₽. Сайт упал в субботу в 14:00 на 2 часа — пиковое время.
Расчёт:
- Средние потери: 12 000 000 / 720 = 16 667 ₽/час
- Коэффициент пика: 1.8 (выходной, день)
- Суммарные потери: 16 667 × 2 × 1.8 × 1.3 (косвенные) ≈ 78 000 ₽
Дополнительно: 15 заказов в корзине не завершены, часть пользователей ушла к конкурентам. Реальные потери могли превысить 100 000 ₽.
Кейс 2: SaaS для малого бизнеса
MRR 500 000 ₽, 50 корпоративных клиентов. Простой 6 часов в рабочий день. SLA 99.9%, при нарушении — 10% кредита.
Расчёт:
- Прямые потери (25% активных): (500 000 / 720) × 6 × 0.25 ≈ 1 042 ₽
- SLA-кредит: 500 000 × 0.1 = 50 000 ₽
- Риск оттока: 2–3 клиента рассматривают расторжение (оценка 30 000–90 000 ₽)
Итого: 50 000–140 000 ₽. Прямые потери малы, но косвенные существенны.
Кейс 3: Новостной портал
200 000 визитов в день, RPM 200 ₽. Сайт упал во время важного события на 45 минут.
Расчёт:
- Средний трафик: 200 000 / 24 = 8 333 визита/час
- Пиковый трафик во время события: × 2.5 = 20 833 визита/час
- Потери: 200 × (20 833 / 1000) × 0.75 ≈ 3 125 ₽
Но главная потеря — трафик ушёл к конкурентам навсегда. Часть аудитории не вернётся. Оценка долгосрочного ущерба — 50 000–100 000 ₽.
Сезонность и особые периоды
Стоимость простоя резко возрастает в определённые периоды:
| Период | Коэффициент | Примечание |
|---|---|---|
| Чёрная пятница, 11.11 | 3–5× | Пик продаж для e-commerce |
| Конец месяца/квартала | 1.2–1.5× | B2B активнее |
| Праздники | 1.5–2× | Рост трафика |
| Ночь | 0.3–0.5× | Минимальная активность |
| Выходные (B2B) | 0.5–0.7× | Снижение активности |
При планировании инфраструктуры и мониторинга учитывайте: инцидент в Чёрную пятницу для магазина с выручкой 5 млн/мес может стоить 100 000+ ₽ за час.
ROI мониторинга: расчёт окупаемости
Мониторинг окупается, если предотвращает инциденты или сокращает их длительность.
Формула:
ROI = (Потери_предотвращённые × N_инцидентов_в_год) / Стоимость_мониторинга_за_год
Пример: Стоимость Uptime Monitor 500 ₽/мес = 6 000 ₽/год. Без мониторинга среднее время обнаружения — 45 минут, с мониторингом — 5 минут. Экономия 40 минут на инцидент. При 4 инцидентах в год и стоимости 7 000 ₽/час:
Экономия = 7 000 × (40/60) × 4 = 18 667 ₽
ROI = 18 667 / 6 000 ≈ 3.1
Мониторинг окупается в 3 раза. При большем количестве инцидентов или более высокой стоимости простоя — ROI выше.
Интеграция с бизнес-процессами
Расчёт потерь — первый шаг к системной работе с надёжностью:
-
Бюджетирование. Зная стоимость простоя, можно обосновать расходы на резервирование, CDN, премиум-хостинг.
-
Приоритизация. Если час простоя стоит 70 000 ₽, круглосуточная поддержка DevOps окупается. Если 700 ₽ — достаточно мониторинга с уведомлениями.
-
Коммуникация с руководством. «Сайт падал 3 раза в год по 2 часа — мы теряли 42 000 ₽. Мониторинг за 6 000 ₽/год сократит потери на 80%» — понятный аргумент.
-
SLA с подрядчиками. Если хостинг или разработчик гарантирует 99.9%, при нарушении можно требовать компенсацию. Расчёт потерь — основа для переговоров.
Рекомендации
- Рассчитайте свою стоимость простоя по формулам в этой статье. Хотя бы приблизительно.
- Документируйте расчёт — пригодится для обоснования бюджета на мониторинг и инфраструктуру.
- Настройте мониторинг до первого серьёзного инцидента. Узнавать о проблемах от клиентов — худший сценарий.
- Определите целевой SLA исходя из типа бизнеса и ожиданий клиентов.
- Проводите постмортемы после инцидентов — фиксируйте реальную длительность, причины и потери. Данные улучшат будущие расчёты.
- Учитывайте сезонность при планировании инфраструктуры и оценке рисков.
- Рассчитайте ROI мониторинга для вашего проекта — это поможет принять решение о внедрении.
Шаблон расчёта для презентации
Для обоснования бюджета перед руководством используйте структуру:
Слайд 1: Текущая ситуация
- Тип сайта и выручка/трафик
- Типичная длительность инцидентов (по данным постмортемов или оценка)
- Частота инцидентов в год
Слайд 2: Расчёт потерь
- Формула и исходные данные
- Стоимость часа простоя (средняя и пиковая)
- Суммарные потери за год без улучшений
Слайд 3: Предложение
- Стоимость мониторинга/инфраструктуры
- Ожидаемое сокращение потерь (MTTR, предотвращение)
- ROI и срок окупаемости
Слайд 4: Следующие шаги
- Конкретные действия и сроки
Такой подход переводит технический вопрос о мониторинге в бизнес-язык, понятный руководству.
Заключение
Расчёт потерь от даунтайма — не академическое упражнение, а практический инструмент. Он помогает обосновать инвестиции в мониторинг, приоритизировать задачи по надёжности и оценивать эффективность внедрённых мер. Формулы в этой статье применимы к большинству типов сайтов. Начните с приблизительной оценки, уточняйте данные по мере накопления статистики инцидентов. Даже грубый расчёт лучше, чем решение «вслепую».
Краткая справка: формулы
| Тип бизнеса | Базовая формула |
|---|---|
| E-commerce | (Выручка/мес / 720) × Часы × K_пик |
| SaaS | (MRR / 720) × Часы × Доля_активных + SLA_кредит |
| Медиа | RPM × (Трафик_час / 1000) × Часы |
| Лендинг | CPL × Визиты_за_период_простоя |
Коэффициент пика: 1.0 (ночь) — 2.0 (пик). K_дополнительно (SEO, репутация): 1.2–1.5.
Следующий шаг после расчёта — внедрение мониторинга. Uptime Monitor и SSL Monitor сокращают время обнаружения инцидентов с часов до минут, что напрямую снижает потери.
Подробнее о настройке мониторинга — в статье «Мониторинг доступности сайта: зачем нужен и как настроить». О действиях при падении сайта — в «Что делать когда сайт упал: план действий».