Час простоя SaaS: прямые потери, отток и штрафы по SLA

MAATRIX

Когда SaaS-продукт падает на час, первая реакция — прикинуть, сколько выручки не пришло за это время, и на этом успокоиться: «час простоя стоит нам примерно X рублей». Это ошибка, причём системная: прямые потери в момент недоступности — только один из трёх разных по природе источников ущерба. Есть ещё отложенный отток клиентов, которые сталкивались с падением и решили не продлевать подписку, и есть договорные штрафы по SLA перед корпоративными клиентами. Если считать только первое, реальная цена простоя занижается в разы, а решения о том, сколько вкладывать в отказоустойчивость, принимаются на основе неполной картины.

Три разных ущерба — и почему их нельзя складывать в одну цифру

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

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

Отток — решение, которое клиент принимает не в момент простоя, а позже, иногда через недели. Клиент столкнулся с недоступностью, испытал неудобство или прямой урон своему бизнесу (если ваш SaaS — часть его рабочего процесса), и это стало одним из аргументов не продлевать подписку в конце периода. Отток нелинеен: одно короткое падение в нерабочее время почти не влияет на удержание, а повторяющиеся простои в рабочие часы клиентов заметно повышают вероятность ухода. И самое важное — отток размазан во времени и накладывается на естественный churn, поэтому его труднее выделить, чем прямые потери.

Штрафы по SLA — единственный из трёх видов ущерба, зафиксированный в договоре заранее. Если у вас есть корпоративные клиенты с подписанным SLA (например, обязательство 99.9% годовой доступности), простой сверх допустимого окна автоматически создаёт финансовое обязательство — обычно в виде кредита на будущие платежи. Это не оценка «на глазок», а конкретная сумма по формуле в договоре.

Честная оценка цены часа простоя — это не одно число, а сумма трёх составляющих, потому что решения на её основе разные: инвестиции в отказоустойчивость инфраструктуры отвечают на прямые потери и отток, а условия SLA в контрактах — отдельный вопрос управления рисками с юристами и sales-командой.

Прямые потери: что происходит в момент простоя

Это самая понятная часть ущерба — она измерима почти в реальном времени, если собрать нужные метрики заранее, до инцидента.

Что теряется в час простоя напрямую:

• Новые регистрации и триалы. Если продукт недоступен, потенциальный клиент либо уходит к конкуренту, либо откладывает решение — и часть таких людей не возвращается.
• Платежи по подпискам. Если биллинг привязан к расписанию и это окно попадает на простой, часть транзакций не проходит вовремя. Некоторые пройдут позже автоматически, но часть потребует ручного вмешательства, и не все клиенты доведут его до конца.
• Апгрейды и допродажи внутри продукта. Если пользователь именно в этот час собирался перейти на более дорогой тариф — вы теряете конкретно эту продажу.
• Usage-based выручка, если тариф зависит от активности (пакеты API-запросов, объём данных) — здесь недополученная выручка тоже почти линейна по времени простоя.

Практический способ оценить прямые потери — не гадать, а посчитать по своим метрикам:

Средняя почасовая выручка = MRR / (30 дней × 24 часа)
Прямые потери за час простоя ≈ Средняя почасовая выручка × доля операций,
которые физически не могли пройти во время простоя

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

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

Отток: почему клиенты уходят не сразу

Отток — самая недооценённая часть ущерба именно потому, что её труднее всего связать с конкретным инцидентом напрямую.

Механика такая: клиент подписан на ваш SaaS, встроил его в рабочие процессы, и вдруг сервис недоступен. Для B2C-подписки это может быть просто раздражение. Для B2B-клиента, у которого ваш продукт — часть операционной цепочки (заказы, CRM, биллинг, аналитика), простой означает остановку его собственных процессов — это уже прямой урон его бизнесу, а не просто неудобство.

Что важно понимать про отток как отдельный вид ущерба:

• Он отложенный. Решение не продлевать подписку принимается обычно ближе к концу расчётного периода — через недели или месяцы. Связь между конкретным инцидентом и потерей клиента не всегда очевидна, если вы не сопоставляете даты оттока с датами инцидентов.
• Он нелинейный по частоте. Единичный короткий инцидент, о котором вы честно и быстро сообщили, повышает риск ухода слабее, чем несколько повторяющихся падений за квартал. Клиенты прощают разовую аварию гораздо охотнее, чем паттерн ненадёжности.
• Он зависит от cost of switching. Если у клиента есть простая замена вашему сервису, отток после простоя будет выше. Если продукт глубоко интегрирован и переезд дорог, тот же инцидент вызовет меньше немедленных уходов — но накопит недовольство, которое проявится позже, при пересмотре бюджета.
• Он бьёт по LTV, а не по одному платежу. Ушедший клиент — это потеря всей оставшейся ценности этого клиента (Lifetime Value), включая потенциальные апгрейды и рекомендации другим компаниям, а не только одного месячного счёта.

Чтобы оценить отток от простоя, полезно сопоставлять когорты: сравнивать churn rate клиентов, которые столкнулись с инцидентом в рабочее время, с churn rate клиентов, которых он не затронул. Разница между этими показателями — приближение к оттоку, вызванному именно простоем, а не общим фоновым churn, который есть у любого SaaS независимо от аптайма.

Честная оговорка: не у каждого SaaS отток от единичного инцидента будет заметным статистически — если клиентов мало или инцидент был коротким и вне пиковых часов, эффект может потеряться в обычной вариативности churn. Не нужно придумывать точный процент оттока «для красивой формулы» — если данных недостаточно, честнее признать это как риск с широким диапазоном, а не как точную цифру.

Штрафы по SLA: договорная плата, а не абстрактная неустойка

Если часть ваших клиентов — корпоративные, с подписанным Service Level Agreement, штрафы за его нарушение — третий, отдельный вид ущерба, и он отличается от первых двух тем, что заранее зафиксирован в цифрах. Подробнее о том, как читать проценты доступности в договоре, — в статье SLA в договоре: как читать проценты.

Типичная структура SLA у SaaS-провайдеров:

Это ориентировочные округлённые расчёты по формуле «(1 − доступность) × длительность периода» — у конкретного провайдера в договоре может быть иная методология (исключение планового обслуживания, окна на измерение по кварталам), поэтому свои цифры нужно проверять по точному тексту договора, а не по общей таблице.

Что отличает штрафы по SLA от прямых потерь и оттока:

• Они формульные. Компенсация обычно прописана как процент от ежемесячного платежа за каждый процентный пункт недостигнутой доступности, часто со ступенчатой шкалой. Это не оценка на глаз, а таблица, которую можно применить к факту простоя напрямую.
• Они не денежные напрямую в большинстве случаев. Чаще компенсация — кредит на будущие счета клиента, а не возврат реальных денег, то есть это упущенная будущая выручка, а не немедленный отток кэша.
• Они требуют, чтобы клиент их запросил. Во многих договорах компенсация не начисляется автоматически — клиент должен формально обратиться в оговорённый срок. Реальные выплаты по SLA обычно меньше «теоретического максимума», потому что не все клиенты доводят процесс до конца.
• Они несравнимы с реальным ущербом клиента. Штраф по SLA почти никогда не покрывает реальные убытки корпоративного клиента от простоя — это символическая компенсация, а не возмещение вреда.

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

Как оценить общую цену часа простоя

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

1. Прямые потери = f(время суток, доля срываемых операций, MRR)
   → считается по факту сразу после инцидента

2. Отток = f(длительность простоя, частота инцидентов за период,
             доля затронутых B2B-клиентов, cost of switching)
   → считается по когортам через 1-3 месяца после инцидента

3. Штрафы по SLA = f(договорные условия конкретных клиентов,
                      факт превышения допустимого простоя)
   → считается по каждому клиенту отдельно, по формуле его договора

Практические шаги для команды:

1. Ведите точный лог инцидентов — начало, конец, какие клиенты и функции затронуты. Без него невозможно посчитать ни отток по когортам, ни штрафы по SLA постфактум.
2. Считайте прямые потери сразу, пока свежи данные о трафике и платежах, — как часть постмортема каждого значимого инцидента.
3. Отслеживайте churn по когортам «затронут / не затронут» хотя бы один-два расчётных периода после инцидента — это единственный способ увидеть отток, не гадая.
4. Держите реестр SLA-обязательств отдельно от общего учёта аптайма — минута простоя для клиента с SLA 99.99% гораздо «дороже» в договорном смысле, чем та же минута для клиента без SLA вообще.
5. Не суммируйте три цифры в одну «стоимость простоя» для маркетинговых заявлений — это иллюзия точности там, где на деле три компонента с разной степенью неопределённости. Прямые потери считаются довольно точно, отток — с широким доверительным интервалом, штрафы по SLA — точно, но только по факту накопленной статистики.

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

Что снижает каждый из трёх видов ущерба

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

Что снижает прямые потери:

• резервирование критичных узлов (балансировщик, база данных, платёжный шлюз), чтобы отказ одного компонента не останавливал весь сервис;
• graceful degradation — например, продукт продолжает работать в режиме «только чтение», если платёжный провайдер недоступен, вместо полной остановки;
• очередь для отложенных операций (биллинг, вебхуки), чтобы часть транзакций не терялась, а выполнялась с задержкой после восстановления.

Что снижает отток:

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

Что снижает штрафы по SLA:

• реалистичные обязательства при подписании контракта — не обещать 99.99%, если инфраструктура объективно не рассчитана на такой уровень отказоустойчивости;
• мониторинг доступности в реальном времени с алертами до того, как накопленный простой приблизится к порогу SLA, а не после;
• юридически чёткий текст SLA (что считается простоем, как измеряется, какие исключения) — расплывчатые формулировки создают риск конфликтных трактовок, когда клиент уже недоволен.

Если инфраструктура — часть проблемы (единая точка отказа на уровне сервера или сети), решение обычно начинается с базового резервирования по узлам кластера — этот подход на примере Proxmox разобран в статье высокая доступность в Proxmox при падении узла. Ещё один источник простоев, который легко упустить, — сам процесс выкладки новых версий; про то, как исключить его из статистики падений, — в статье безопасный деплой без простоя.

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