Когда клиент спрашивает «а у вас есть SLA?», он редко хочет услышать цифру. Он хочет понять, что произойдёт в четверг вечером, когда всё ляжет, и кому он будет звонить. Продавец, который отвечает «99,9%», формально прав и практически проиграл: 99,9% — это почти девять часов простоя в год, и если они выпадут на день закрытия периода, никакой процент клиента не утешит. Разговор о надёжности — это разговор о сценарии отказа, а не о числе в договоре.
Что на самом деле означают девятки
Арифметика простая, и её стоит знать наизусть, потому что она мгновенно меняет тон переговоров.
99% — примерно 3,65 дня простоя в год. Почти четыре рабочих дня.
99,9% — около 8,8 часа в год. Один полный рабочий день.
99,95% — около 4,4 часа.
99,99% — около 53 минут в год. Меньше часа на всё: обновления, сбои, ошибки людей.
Разница между 99,9% и 99,99% в договоре выглядит как лишняя девятка. В инженерии это разница между «дежурный успеет проснуться и починить» и «должно чиниться само, без человека». Отсюда и разница в цене — не в два раза, а в разы, потому что вторая девятка покупается резервированием, автоматическим переключением и людьми, которые это поддерживают.
Практический приём: когда клиент требует четыре девятки, спросите, сколько стоит час простоя именно для него. Часто выясняется, что для его бизнеса допустимы два часа, и он платит за уровень, который ему не нужен. Продавец, который это озвучил, запоминается — и обычно получает следующий проект.
Три слова, которые надо понимать
Доступность (uptime). Доля времени, когда система работала. Ключевой вопрос: как считается. Если сервис отвечает, но отвечает за 40 секунд вместо секунды — это простой для пользователя и рабочее время по договору. Уточнять надо всегда.
Время восстановления (RTO). Через сколько система снова работает после аварии. Именно эту цифру клиент чувствует физически.
Допустимая потеря данных (RPO). Сколько работы можно потерять. Если резервные копии делаются раз в сутки, RPO — сутки: при аварии в 17:00 теряется весь рабочий день. Для бухгалтерии это катастрофа, для архива документов — ничего страшного.
Эти два параметра — RTO и RPO — задают стоимость решения сильнее, чем любой список функций. И почти никогда не обсуждаются на первой встрече, хотя должны бы.
Почему «мы никогда не падаем» — плохой ответ
Любая система падает. Инженер на стороне клиента это знает, и обещание безотказности читает как признак того, что вы не эксплуатировали ничего сложного. Сильный ответ устроен иначе: не «не упадёт», а «вот что происходит, когда упадёт».
Хороший рассказ содержит четыре элемента: как вы узнаёте о сбое (мониторинг, а не звонок клиента), за сколько минут отвечает человек, что делается в первую очередь, и как клиент узнаёт о ходе работ, не звоня каждые десять минут. Клиент покупает предсказуемость, а не отсутствие проблем.
Отдельно стоит говорить про плановые работы. Они не считаются простоем по договору, но для клиента это то же самое: не работает. Честно проговоренное окно обслуживания снимает половину будущих конфликтов.
Где вендоры преувеличивают
«Четыре девятки» без определения. Уточняйте, что входит в расчёт: только ядро сервиса или весь путь до пользователя. Часто договорная доступность считается по компоненту, который почти никогда не падает, а падает всё остальное.
Компенсация как гарантия. Штраф за нарушение SLA обычно равен доле абонентской платы за период простоя — то есть нескольким процентам месяца. Он не покрывает убытки клиента и не должен подаваться как «мы отвечаем деньгами». Подаётся честно: это дисциплина поставщика, а не страховка бизнеса.
«Резервирование включено». Резерв бывает разный: горячий (переключение секунды), тёплый (минуты), холодный (часы). Слово одно, цена и результат разные. Вопрос инженеру: что именно и за сколько переключается.
«Круглосуточная поддержка». Круглосуточный приём заявок и круглосуточная работа над решением — не одно и то же. Ночью нередко работает только первая линия, которая регистрирует обращение до утра.
Что спросить у своего инженера перед встречей
- Какая доступность у нас реально была за последний год и что было причиной крупнейшего сбоя?
- Что входит в расчёт SLA, а что исключено — плановые работы, сбои на стороне клиента, каналы связи?
- Какое RTO и RPO мы обеспечиваем в базовой поставке и что нужно докупить, чтобы их улучшить?
- Что переключается автоматически, а что руками, и сколько времени занимает ручная часть?
- Кто конкретно дежурит ночью и в выходные, и что он может решить без эскалации?
Красные флаги на стороне клиента
- Требует четыре девятки, но не может назвать стоимость часа простоя. Требование скопировано из чужого документа; надо возвращать разговор к реальной потребности, иначе проект будет дорогим и всё равно неудачным.
- Никогда не проверял восстановление из копий. Резервные копии, которые не разворачивали, — это не резервные копии, а надежда. Проверка часто вскрывает, что часть данных не попадала в бэкап годами.
- Нет ответственного за инцидент. Если при аварии неясно, кто принимает решения, любое время восстановления растянется втрое на согласованиях.
- SLA обсуждает только юрист. Тогда документ будет строгим и нерабочим. Нужен разговор с тем, кто эксплуатирует.
Вопросы, которые задаст технический директор
«Покажите отчёт о доступности за прошлый год» — если такого отчёта нет, это говорит больше, чем любые обещания.
«Как вы разбираете инциденты?» — зрелый поставщик пишет разбор без поиска виноватых и меняет процесс. Ответ «уволили дежурного» пугает сильнее самого сбоя.
«Что происходит, если пропадёт связь между площадками?» — классический вопрос про поведение системы при частичном отказе, а не полном. Именно частичные отказы самые болезненные.
«Кого я разбужу в три часа ночи?» — имя, номер, порядок эскалации. Конкретика здесь ценится выше любой презентации.
Что забрать с собой
- 99,9% — это почти девять часов простоя в год; называть процент без часов бессмысленно.
- RTO и RPO определяют цену сильнее, чем список функций, и почти никогда не обсуждаются вовремя.
- Клиент покупает предсказуемость поведения при сбое, а не обещание отсутствия сбоев.
- Компенсация по SLA — дисциплина поставщика, а не страховка бизнеса клиента; подавать иначе опасно.
- Требование четырёх девяток без расчёта стоимости простоя — почти всегда скопированное требование.
Как объяснить разницу в цене между 99,9% и 99,99%?
Через то, что покупается: в первом случае человек успевает вмешаться, во втором система должна восстанавливаться сама. Второе требует полного дублирования и автоматики, поэтому дороже кратно, а не на проценты.
Клиент требует SLA, которого у нас нет. Что делать?
Разложить требование на RTO, RPO и часы поддержки и посмотреть, какая часть действительно нужна. Часто достижимый компромисс есть. Подписывать недостижимый SLA хуже, чем не получить сделку: через год это будет разбирательство и потерянный клиент.
Стоит ли рассказывать о своих прошлых сбоях?
Да, если рассказ заканчивается изменением процесса. История «упало, разобрались, поменяли вот это» строит доверие быстрее, чем идеальная статистика, в которую никто не верит.
Что делать, если простой произошёл не по нашей вине?
Помогать разбираться всё равно. Клиенту в момент аварии безразлична зона ответственности, и поведение поставщика в эти часы определяет продление контракта сильнее, чем весь предыдущий год.
Как понять, что клиенту нужна высокая доступность, а не просто хочется?
Спросить, что происходит с деньгами и людьми в час простоя. Если процесс останавливается физически — производство, торговый зал, приём платежей, — потребность настоящая. Если сотрудники переключаются на другую работу и наверстают позже, требование можно снижать.
Материал обновлён 6 сентября 2026
Рамки по теме
Разобранное выше опирается на эти рабочие рамки — их можно открыть отдельно.
- Каркас хорошей архитектурыШесть опор для оценки решения: надёжность, безопасность, производительность, стоимость, эксплуатация, устой…
- Разбор инцидентов без поиска виноватыхПорядок работы во время сбоя и разбор после. Ключевое правило — искать условия, которые позволили ошибке пр…
Ещё в серии «Технологии для продавца»