Обязательство по доступности сервиса становится проблемой в трёх местах: когда обещанный уровень выше того, что даёт ваша собственная инфраструктура; когда не описано, что считается простоем; и когда ответственность не ограничена суммой. Работающая конструкция — измеримый уровень, исключения, понятный порядок фиксации и предел ответственности, соотнесённый со стоимостью договора.
Четыре элемента, без которых пункт не работает
- Что считается простоем. Полная недоступность, деградация производительности, недоступность отдельной функции — это разные вещи, и обычно уточняется только первая.
- Как измеряется. Чьи данные считаются доказательством: ваш мониторинг, мониторинг заказчика или независимый. Без этого пункта спор упирается в разные цифры.
- Исключения. Плановые работы с уведомлением, сбои на стороне заказчика, отказ внешних сервисов, форс-мажор.
- Что происходит при нарушении. Обычно возврат части абонентской платы, а не возмещение убытков заказчика. Это принципиальное разграничение.
Почему опасно обещать больше, чем можете
Уровень доступности вашего сервиса не может быть выше, чем у инфраструктуры, на которой он работает. Если облачный провайдер даёт определённый уровень, а вы обещаете заказчику больше, вы приняли на себя разницу за свой счёт. Считать нужно по всей цепочке: провайдер, каналы связи, сторонние сервисы. Обещание, которое звучит хорошо в предложении, через год превращается в регулярные выплаты.
Разграничение, которое стоит денег
| Формулировка | Что означает на практике |
|---|---|
| Возврат части платы за период простоя | Ограниченный и предсказуемый риск |
| Возмещение прямых убытков заказчика | Риск, который вы не контролируете и не можете оценить |
| Возмещение упущенной выгоды | Практически неограниченный риск |
| Без предела ответственности | Риск, превышающий стоимость договора в разы |
Про предел ответственности
Общепринятая практика — ограничить совокупную ответственность суммой, полученной по договору за определённый период. Это нормальное условие, и разумный заказчик его принимает. Отказ ограничивать ответственность должен отражаться в цене: вы принимаете риск, который не можете оценить, и это стоит денег.
Оговорка
Расчёт по цепочке на примере
Ваш сервис работает в облаке. Провайдер даёт по договору 99,9 процента доступности на виртуальные машины. База данных — управляемая услуга того же провайдера, там тоже 99,9. Внешний сервис отправки уведомлений — 99,5. Канал связи до вашего офиса, где сидит поддержка, — отдельная история.
Если сервис перестаёт работать при отказе любого из этих элементов, доступности перемножаются. Для трёх элементов с указанными значениями получается около 99,3 процента, то есть примерно пять часов простоя в месяц как расчётный максимум. Обещать заказчику 99,9 на этом основании означает принять на себя разницу.
Поднять цифру можно только резервированием: вторая зона размещения, запасной канал, обходной путь при отказе внешнего сервиса. Каждое резервирование стоит денег, и эти деньги должны быть в цене. Обещание без резервирования — это не уровень сервиса, а надежда.
Что означают уровни на практике
| Уровень | Простой в месяц | Что нужно, чтобы держать |
|---|---|---|
| 99,0 % | около 7 часов | Один сервер, ручное восстановление |
| 99,5 % | около 3,5 часов | Мониторинг, дежурство в рабочее время |
| 99,9 % | около 43 минут | Резервирование, автоматическое переключение |
| 99,95 % | около 22 минут | Две зоны размещения, круглосуточное дежурство |
| 99,99 % | около 4 минут | Полное резервирование, отдельная команда |
Плановые работы: как описать
Плановые работы почти всегда исключаются из расчёта доступности, и это нормально. Но исключение должно быть обусловленным, иначе оно превращается в лазейку: формально можно объявить плановыми любые работы.
Разумная формулировка ограничивает три параметра: время суток и день недели, длительность одного окна, суммарное время в месяц, и срок предупреждения. Например: не более четырёх часов за одно окно и не более восьми часов в месяц, в ночное время выходного дня, с уведомлением не позднее чем за пять рабочих дней. Срочные работы по безопасности выносятся отдельным пунктом с уведомлением по факту.
Заказчику такая конструкция понятна и обычно принимается без споров, потому что она защищает и его тоже.
Порядок фиксации простоя
- Чей мониторинг считается источником. Обычно ваш, с правом заказчика оспорить данными своего.
- С какого момента начинается отсчёт. С момента фиксации мониторингом или с момента обращения заказчика — это разные вещи и разные цифры.
- Как оформляется требование компенсации. Срок подачи, форма, кому направляется. Без срока требования появляются через год.
- В каком виде выплачивается. Обычно зачётом в следующий период, а не возвратом денег.
Когда уровень сервиса вообще не нужен
Частые вопросы
Обещайте уровень, который вы измеряете и который держит ваша инфраструктура. И разграничьте компенсацию с возмещением убытков — это разница между управляемым риском и неограниченным.
Материал обновлён 3 сентября 2026