Ты можешь писать идеальный код, но если клиент не понимает, чего ждать от сервиса, он не доверяет. Жесткая правда: без SLA ты продаешь обещания на словах. И да, это хлопотно, но именно SLA превращает «мы стараемся» в «мы отвечаем». Особенно, когда ты маленький и каждое падение бьет по репутации сильнее, чем по крупной компании.
Коротко: SLA — это соглашение об уровне сервиса
В нем ты простыми словами и цифрами описываешь, как работает твой продукт, как быстро реагируешь на проблемы и что происходит, если что-то идет не так. Это не только про аптайм. Это про ответственность и предсказуемость.
Сюрприз: даже если ты не подписывал никакой SLA, у клиента он есть — в голове
Он считает, что «все всегда работает», «поддержка отвечает за пять минут», «данные никогда не теряются». Пока ожидания не совпадают, тебя ждут ночные звонки, сложные разборки и обиженные письма в выходной.
Личный кейс. Мы запускали небольшой SaaS для биллинга. Первые клиенты пришли быстро, MRR растет, летим. Потом у потенциального крупного клиента юристы спрашивают: «Пришлите SLA». А у нас соглашения нет — только бодрые слова на демо. Сделка зависла на четыре недели, затем ушла конкуренту, у которого был даже не идеальный, но понятный SLA на две страницы. Больно? Очень. После этого мы написали свой документ за два дня, и следующие два тендера закрыли без вопросов.
Зачем SLA маленькому проекту:
- Снимает неопределенность. У тебя есть четкие обещания и критерии, у клиента — реальные ожидания.
- Защищает от эмоциональных эскалаций. Вместо «вы все сломали» — «это инцидент S2, реакция 2 часа, статус-апдейты каждые 60 минут».
- Помогает продавать в B2B. Отдел закупок любит чек-листы. SLA — пункт, который закрывает часть рисков.
- Упрощает приоритизацию. Если ты один инженер на все, тебе нужен фильтр, что чинить в первую очередь.
- Строит доверие. Ты признаешь риски заранее и показываешь, как ими управляешь.
Определимся с терминами, без перегруза:
- SLA (Service Level Agreement) — договоренность с клиентом: какие уровни сервиса ты поддерживаешь и что делаешь, если нет.
- SLO (Service Level Objective) — целевой показатель: «99.5% доступности в месяц».
- SLI (Service Level Indicator) — как ты измеряешь это: «успешные 200/OK на health-check каждые 30 секунд».
Перевод на человеческий: SLA — это текст с твоими SLO плюс процесс и последствия. Не обещай то, что не умеешь мерить. Если не можешь посчитать доступность, обещать ее опасно.
Про цифры, которые имеют значение. 99.9% звучит красиво, но это допускает примерно 43 минуты даунтайма в месяц. 99.5% — около 3.6 часа. 99% — уже 7.3 часа. Если у тебя один сервер без репликации, обещать 99.99% — приглашение к конфликту. Спойлер: тебя спасет честность и ясные исключения.
Как выглядит минимальный SLA на одну-две страницы для маленького SaaS:
- Предмет: что именно ты считаешь «сервисом» (веб-API, веб-UI, вебхуки).
- Доступность: целевой аптайм за месяц (например, 99.5%), метод измерения и период наблюдения.
- Исключения: плановое обслуживание, форс-мажор, проблемы у провайдеров клиента, DDoS сверх твоих мощностей.
- Поддержка: часы работы (например, 9:00–21:00 МСК в будни) и время первой реакции по уровням критичности.
- Критичность: S1 — простой для всех, S2 — частичный сбой, S3 — баг без влияния на работу, S4 — вопрос/консультация.
- Коммуникации: где статус (статус-страница, канал рассылки), частота апдейтов по инцидентам.
- Компенсации: кредиты на счет при невыполнении целей (простая таблица процентов).
- Резервное копирование: периодичность бэкапов, RPO и RTO в простых словах.
- Безопасность: минимум — шифрование в транзите и хранении, контроль доступа, журналы.
- Процедура изменений SLA: уведомление за X дней, право клиента отказаться.
Пример конкретики:
- Доступность: 99.5% за календарный месяц. Измерение: внешний мониторинг HTTP 30-секундным интервалом из 3 регионов, кворум 2/3.
- Поддержка: S1 — реакция 1 час, S2 — 2 часа, S3 — 1 рабочий день, S4 — 2 рабочих дня. Канал — почта или чат-поддержка.
- Компенсация: за каждый полный процент ниже цели — кредит 10% от месячной платы, максимум 50%. Кредиты не наличные, а скидка на следующий период.
- RPO: до 24 часов, RTO: до 4 часов в рабочее время. Перевод: мы можем восстановить данные на состояние не старше суток и поднять сервис в течение четырех часов.
Зачем такая конкретика?
Потому что она экономит нервы. Когда у тебя есть четкая шкала S1–S4, ты не споришь с клиентом «это важно или нет» — ты сравниваешь с определением. Когда есть формула кредитов — нет торгов на эмоциях.
Ситуация из практики. У клиента падали вебхуки из-за таймаутов, а мы в логах не видели очевидного. Раньше спорили бы неделями. С SLA выбрали уровень S2, согласовали workaround и план фикса, отправляли апдейты каждый час. Итог: клиент остался доволен, хотя сбой был. Доверие выросло, потому что процесс прозрачен.
Типичные ловушки, в которые попадают маленькие команды:
- Обещают «24/7» без дежурств. Результат — выгорание и хрупкий сервис. Честнее заявить 12/5 и SLA на реакции в эти часы.
- «Доступность» без определения. Считать по uptime облака? По своему логу? Нужен внешний мониторинг и четкий метод.
- Нет исключений. Плановое окно обслуживания — это нормально, если ты о нем предупредил и ограничил по времени.
- Компенсации в деньгах. Для маленького бизнеса рискованно. Кредит на счет — честно и безопасно.
- Слишком амбициозные цифры. Начни с достижимого, потом повышай, когда архитектура подтянется.
Как выбрать свои SLO, если ты небольшой:
- Оцени архитектуру. Один инстанс без реплики? 99.5% реалистично. Есть реплика и автоматический фейловер? Можно тянуться к 99.9%.
- Смотри на цепочку зависимостей. Если ты живешь на одном облачном регионе и одном провайдере БД, это предел.
- Проверь мониторинг. То, что не меряешь, не держишь. Заведи мониторинг аптайма, алерты по задержкам, журнал инцидентов.
- Оставь себе запас. Не обещай уровни, которые держишь «впритык». Ошибка оператора или миграция БД всегда случится не вовремя.
Минимальный набор инструментов, который поможет выполнить SLA:
- Внешний аптайм-мониторинг (несколько регионов, короткий интервал).
- Статус-страница, где можно объявлять инциденты и обслуживание.
- Канал инцидентов: чат с уведомлениями, простой регламент S1–S4.
- Еженедельный обзор ошибок и технический долг по результатам инцидентов.
- Шаблон постмортема на одну страницу: причина, влияние, что поменяли.
Важный нюанс: SLA — это не про «штрафовать себя», а про «держать обещания и честно признавать ограничения». Клиенты не требуют невозможного. Они хотят понимать, что будет, если случится сбой, и как быстро ты вернешь их в рабочее состояние. Если у тебя есть план, ты уже выигрываешь.
Немного математики для аргументации на встречах с заказчиками:
- 99% доступности — это до 7 часов простоя в месяц. Для SaaS с пиками нагрузки это может стоить десятков тысяч.
- Разница между 99.5% и 99.9% — почти три часа. Чтобы их убрать, нужна репликация, здравый деплой и тесты отказоустойчивости. Это деньги, и SLA помогает объяснить, за что платит клиент.
Еще одна жизненная сцена. Маленькая команда продает интеграцию в крупную сеть аптек. Продакт на стороне клиента говорит «обожаю вашу скорость», безопасность кивает, но юристы стопорят: «Где SLA?» Ребята тянут неделю, собирают документ, проходят согласование за день. После этого закупки перестают мучить вопросами — потому что есть, чему доверять.
Что включает хороший раздел «Коммуникации по инцидентам»:
- Первый апдейт — сразу после подтверждения инцидента: «признаки, влияние, работаем».
- Далее регулярные апдейты по расписанию (например, каждые 30–60 минут).
- После закрытия — краткий разбор: причина, что сделали, что изменится.
- Открытый канал: статус-страница и короткие ссылки на инциденты.
Про данные. Многие пишут «делаем бэкапы», и на этом заканчивают. Клиенту важно два числа: RPO (сколько данных можно потерять) и RTO (сколько времени вы будете восстанавливать). Если ты говоришь «RPO 24 часа, RTO 4 часа», это понятно и проверяемо. Если случится худшее, ты не геройствуешь, а выполняешь обещанное.
Триггерная мысль: пока ты читаешь это, твой потенциальный клиент сравнивает тебя с конкурентом по двум критериям — «понятно ли, как вы работаете, когда все плохо» и «можно ли вас поставить в тендер». SLA закрывает оба.
И да, SLA — живой документ. Пересматривай его раз в квартал после постмортемов. Наш опыт: сначала обещали 99.5% и реакцию S1 за два часа в рабочее время. Через полгода добавили дежурства на пике и подняли до 99.9% без ночных героических подвигов. Просто потому, что появились процессы и мониторинг получше.
Главное — не усложняй. Начни с короткого SLA на одну страницу, где каждое слово проверяемо практикой. Определи уровни, измерение, исключения, коммуникации и компенсации. Сделай это однажды — и у тебя появится взрослый разговор с клиентами на языке ответственности, а не взаимных ожиданий.
Вывод простой: SLA — это дисциплина и доверие, оформленные текстом. В маленьких командах это особенно ценно, потому что снижает хаос, экономит время и открывает двери к большим договорам. А еще это честный способ сказать: «Мы не идеальны, но мы управляем рисками и держим слово». Этого более чем достаточно, чтобы выиграть у тех, кто по-прежнему отвечает на вопросы про надежность фразой «да не переживайте, все будет нормально».