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

Второй разговор — сколько это стоило бизнесу — часто не происходит вообще. А зря. Именно он меняет отношение к инфраструктуре.

Не «у нас иногда бывают сбои», а «каждый сбой стоит нам X рублей в час, и мы знаем это точно».

Что такое простой IT-системы и почему его недооценивают

Простой — это любое состояние, при котором система не выполняет свои функции в полном объёме.

Сайт не открывается. CRM не отвечает. 1С зависла перед отправкой документов. Платёжная страница возвращает ошибку. Клиент не может оформить заказ. Менеджер не может открыть карточку сделки. Бухгалтерия не может провести документ.

Важный момент: частичная деградация — это тоже простой.

Если сайт работает, но страница оплаты открывается за 12 секунд вместо двух, часть пользователей уже ушла. Если CRM доступна, но отчёты строятся по 40 минут, менеджеры работают вполсилы. Если 1С вроде бы не упала, но каждая операция занимает вечность, бизнес всё равно теряет время.

Это не «всё нормально». Это потери, которые просто сложнее посчитать.

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

Каждая цифра сама по себе терпима. Суммарно — уже нет.

Из чего складывается реальная стоимость простоя

Стоимость простоя — это не только «сколько заказов не пришло за два часа». Это прямые, косвенные и скрытые потери. И часто именно косвенные оказываются больнее.

Прямые потери

Это то, что считается сразу и очевидно.

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

Штрафы и неустойки. Если у вас есть SLA перед клиентами или партнёрами, простой сверх допустимого порога — это не просто репутационная история. Это деньги по договору.

Расходы на устранение. Сверхурочные инженеров, привлечённые подрядчики, экстренная аренда мощностей, срочная диагностика, ручное восстановление. В режиме «горим» всё стоит дороже.

Косвенные потери

Здесь суммы обычно больше, но их сложнее зафиксировать в моменте.

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

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

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

Потеря производительности команды. Менеджеры не могут работать в CRM, бухгалтерия ждёт, пока поднимется 1С, склад не проводит накладные. Каждый час простоя внутренней системы — это час, который потом нужно наверстать. Часто сверхурочно.

Скрытые потери

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

Репутация. Один громкий сбой в нужный момент — и часть аудитории формирует устойчивое впечатление: «у них нестабильно». В B2B это особенно болезненно: корпоративные клиенты выбирают подрядчиков в том числе по надёжности.

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

Стресс и выгорание команды. Это не отдельная строка в финансовом отчёте, но она влияет на текучку, качество работы и скорость реакции на следующие инциденты. А текучка — очень даже финансовая строка.

Сколько стоит час простоя для разных типов бизнеса

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

E-commerce

В e-commerce стоимость простоя считается проще всего: дневная выручка делится на количество рабочих часов.

Если интернет-магазин делает 300 000 рублей в день, то средняя потеря — около 12 500 рублей в час. Но это только средняя цифра. В Чёрную пятницу, в сезон распродаж или во время рекламной кампании она может вырасти в три-пять раз.

И это только прямая выручка.

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

В итоге час простоя в e-commerce редко стоит только «час средней выручки». Обычно больше.

1С, ERP, CRM и внутренние системы

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

Простой 1С перед сдачей отчётности — это не просто дискомфорт. Это сорванные сроки, штрафы, переработки и главбух, который пьёт валерьянку.

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

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

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

Финансовые и клиентские сервисы

Здесь цена простоя максимальная. И не только из-за прямых потерь.

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

Для платёжных сервисов, банков, страховых и клиентских платформ простой даже на 15 минут в пиковый период может стоить больше, чем весь месячный бюджет на инфраструктуру.

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

Почему один и тот же простой для разных компаний стоит по-разному

Представим два интернет-магазина с одинаковым трафиком. Оба лежат два часа.

Для одного это неприятность. Для другого — катастрофа.

Разница в нескольких вещах.

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

Скорость обнаружения и реакции. Если о проблеме узнали через 10 минут — потери одни. Если через два часа — другие. Зависимость прямая: чем быстрее обнаружили, тем меньше потеряли. Именно поэтому проактивный мониторинг 24/7 — не статья расходов, а способ контролировать цену инцидента.

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

Качество процессов реагирования. Команда с чётким планом действий восстанавливает систему за 30 минут. Команда без плана — за несколько часов, с риском сделать хуже в процессе.

Простой редко бывает просто технической проблемой. Это всегда проверка архитектуры, процессов и готовности команды.

Как рассчитать стоимость простоя

Универсальной формулы нет, но есть рабочая модель.

Базово стоимость простоя можно считать так:

Стоимость простоя = потерянная выручка + простой сотрудников + стоимость восстановления + косвенные потери

А годовые потери так:

Годовые потери = стоимость одного инцидента × количество инцидентов в год

Теперь по шагам.

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

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

Шаг 3. Стоимость восстановления. Сверхурочные инженеров, привлечённые подрядчики, экстренная диагностика, ручное восстановление, дополнительные мощности. Если плана нет, эта цифра становится непредсказуемой.

Шаг 4. Косвенные потери. Самое сложное для точного расчёта. Минимальная оценка: рекламный трафик, потраченный впустую за время простоя, плюс средний чек, умноженный на примерное количество потерянных конверсий.

Сложите шаги 1–4 и умножьте на типичную продолжительность инцидента. Это и есть цена одного среднего простоя. Потом умножьте на количество инцидентов в год.

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

Как RTO и RPO связаны со стоимостью простоя

RTO и RPO звучат как технические аббревиатуры, но на самом деле это бизнес-решения.

RTO (Recovery Time Objective) — сколько времени система может не работать.

RPO (Recovery Point Objective) — сколько данных бизнес готов потерять.

Если ваш RTO — 4 часа, значит, вы принимаете, что в случае серьёзного сбоя бизнес может стоять 4 часа. Умножьте это на стоимость часа простоя — и получите максимально допустимые потери от одного инцидента.

Это уже не абстрактная метрика. Это финансовая граница.

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

Подробнее об этом мы разбираем в [статье про Disaster Recovery Plan](https://u-team.by/blog/disaster-recovery-plan-drp).

Главное: RTO и RPO нельзя определить только технически. Их определяет бизнес, исходя из цены простоя. Инженеры уже строят инфраструктуру под эти цифры.

Почему ничего не делать почти всегда дороже

Логика «пока работает, не трогаем» понятна. Но у неё есть скрытая стоимость.

Каждый месяц без мониторинга — это месяц, когда проблема может нарасти незаметно.

Каждый месяц без резервирования — это месяц, когда один отказавший компонент может остановить всё.

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

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

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

Как инфраструктурная зрелость снижает стоимость простоя

Системная работа с инфраструктурой напрямую влияет на цену инцидента. Не на уровне красивых слов, а на уровне конкретных денег.

Мониторинг сокращает время обнаружения. Проблему видят за минуты, а не узнают от клиентов через час. Меньше время обнаружения — меньше суммарный downtime.

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

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

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

Инфраструктурная зрелость — это не про «дорого и сложно». Это про то, чтобы каждый сбой стоил меньше, длился меньше и не превращался в ночной пожар для всей команды.

Когда бизнесу уже пора считать цену простоя всерьёз

Если хотя бы один пункт про вас, разговор давно нужен.

• Сервис или сайт напрямую влияет на выручку, и каждый час недоступности — это деньги.
• Есть пиковые периоды: сезон, акции, отчётность — и каждый раз это тревога.
• Инциденты случаются, но никто не считал, сколько они реально стоят.
• Нет понимания, какой RTO и RPO допустим для бизнеса.
• Нет уверенности, что при серьёзном сбое команда знает, что делать.
• Внутренних ресурсов не хватает: есть администратор, но он занят текущими задачами, а не системной работой.
• Проблемы замечают пользователи, а не мониторинг.
• Восстановление каждый раз происходит вручную и по-разному.

Если вы не уверены, сколько на самом деле стоит простой ваших IT-систем, начните с [аудита инфраструктуры](https://u-team.by/vulnerability). Он помогает понять реальные точки риска, допустимый downtime и меры, которые снизят потери.

Вывод

Простой IT-системы — это не только технический инцидент. Это потерянная выручка, остановленная команда, потраченный рекламный бюджет, репутационные риски и время, которое никто не вернёт.

Пока стоимость простоя не посчитана, инфраструктура часто кажется расходом. Как только бизнес видит цену одного часа downtime, разговор меняется. Мониторинг, резервирование, DRP и регулярный аудит перестают быть «техническими хотелками» и становятся способом управлять рисками.

В [U-team](https://u-team.by/) мы проектируем, сопровождаем и мониторим инфраструктуру так, чтобы она выдерживала нагрузку, быстрее восстанавливалась после сбоев и не превращала каждый инцидент в пожар.

Хотите проверить свою инфраструктуру на прочность? Оставьте заявку — посмотрим, где у вас слабые места и что можно усилить в первую очередь.

Частые вопросы

Что считается простоем IT-системы?

Простой — это любое состояние, при котором система не выполняет свои функции в полном объёме. Это может быть полная недоступность, медленная работа или частичная деградация. Например, сайт открывается, но страница оплаты недоступна, CRM работает слишком медленно, а 1С зависает при проведении документов.

Как рассчитать стоимость простоя сайта?

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

Чем отличаются прямые и косвенные потери от простоя?

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

Что такое downtime cost?

Downtime cost — это совокупная стоимость одного инцидента недоступности. В неё входят прямые потери выручки, стоимость простоя сотрудников, расходы на восстановление и косвенные последствия: репутационные, операционные и коммерческие.

Как RTO и RPO связаны со стоимостью простоя?

RTO — это допустимое время простоя, RPO — допустимая потеря данных. Это финансовые решения, а не только технические метрики. Если RTO равен 4 часам, бизнес фактически принимает возможный простой на 4 часа. Умножив это время на стоимость часа простоя, можно понять максимально допустимые потери от одного инцидента и определить, сколько разумно вкладывать в отказоустойчивость.

Как снизить потери от простоя?

Системно: настроить мониторинг, который обнаруживает проблему раньше пользователей; выстроить отказоустойчивую архитектуру с резервированием; разработать [Disaster Recovery Plan](https://u-team.by/drp); регулярно проводить аудит инфраструктуры, чтобы находить риски до того, как они стали инцидентами.