SLA (Service Level Agreement, соглашение об уровне сервиса) обычно читают в тот день, когда что-то уже упало. К этому моменту в нём ничего не изменить: время реакции, окно поддержки и список исключений закреплены подписью. Поэтому читать его стоит раньше — и читать как инженерный документ, а не как рекламный буклет.
Хороший SLA отвечает на четыре вопроса: что именно обещано, как это измеряется, когда обещание не действует и что будет, если его не выполнили. Пройдём по ним по порядку.
Время реакции — не время решения
Типичная ошибка — прочитать «реакция 30 минут» как «починим за 30 минут». Это разные обязательства.
- Время реакции — срок, за который инженер подтвердил, что увидел проблему, и начал ею заниматься. Проверьте, что именно считается реакцией: автоматическое письмо «ваше обращение зарегистрировано» ею быть не должно.
- Время решения, или восстановления, — срок, за который сервис снова работает. Его гарантируют реже и осторожнее: никто не знает заранее, что именно сломается.
Отсутствие гарантированного времени решения — ещё не признак плохого договора. Плохо, когда из текста непонятно, что происходит после реакции. Нормальная формулировка: время реакции зафиксировано, дальше работа идёт без перерыва до восстановления, а заказчик получает сведения о ходе работ через понятные интервалы. В наших тарифах администрирования время реакции — от 30 минут до 4 часов, и это именно реакция инженера, а не срок, за который «всё починится».
Посмотрите также, зависит ли время реакции от приоритета. Обычно обращения делят на критичные (сервис недоступен), серьёзные (работает с ошибками) и обычные (вопрос, мелкая неисправность). Важно, кто назначает приоритет и можно ли с ним не согласиться.
Окно поддержки: когда идут часы
Время реакции отсчитывается только внутри окна поддержки. Если окно — будни с 9:00 до 19:00, а реакция — 4 часа, то на обращение в пятницу в 18:00 инженер вправе ответить в понедельник до 12:00: час в пятницу и три в понедельник. Формально SLA выполнен, фактически магазин простоял выходные.
Отсюда два вывода. Первый: «мониторинг 24/7» и «поддержка 24/7» — разные вещи. Мониторинг может круглосуточно фиксировать проблему, а реагировать на неё инженер будет в своё окно. Второй: окно выбирают не по цене, а по тому, когда у вас идут продажи. Интернет-магазину, который зарабатывает вечером и в выходные, будничное окно не подходит, как бы привлекательно ни выглядел тариф.
Уточните и то, что происходит за пределами окна: работы невозможны совсем или возможны по повышенной ставке. Второй вариант честнее — у вас остаётся выбор.
Что считается простоем
Процент доступности ничего не значит, пока не определено слово «недоступен». В тексте должны быть ответы на такие вопросы.
- Что измеряется. Отвечает ли сервер на ping, открывается ли главная страница, проходит ли заказ до конца — это три разных уровня. Сервер, который «пингуется», не обязательно продаёт.
- Кто и откуда измеряет. Внешняя проверка каждую минуту и внутренний отчёт провайдера дадут разные цифры.
- С какого момента идёт отсчёт. С момента сбоя, с момента срабатывания мониторинга или с момента вашего обращения.
- Считается ли деградация. Сайт, который открывается за сорок секунд, формально доступен.
- За какой период считают. Месяц и год — не одно и то же, и это видно из арифметики ниже.
Сколько часов в девятках
Проценты удобно переводить во время — так они перестают быть абстракцией.
| Доступность | Простой за год | Простой за месяц (30 дней) |
|---|---|---|
| 99% | около 3 суток 16 часов | около 7 часов 12 минут |
| 99.5% | около 1 суток 20 часов | около 3 часов 36 минут |
| 99.9% | около 8 часов 46 минут | около 43 минут |
| 99.95% | около 4 часов 23 минут | около 22 минут |
| 99.99% | около 53 минут | около 4 минут |
Обратите внимание на период. 99.9% за месяц — это примерно 43 минуты простоя, и превысить их нельзя ни в одном месяце. 99.9% за год позволяют один раз пролежать целый рабочий день и остаться в рамках договора. Чем короче отчётный период, тем строже обязательство.
И ещё одно: каждая следующая девятка стоит дороже предыдущей. 99.99% — это резервирование, дублирование и круглосуточное дежурство, а не «тот же сервер, только аккуратнее». Если четыре девятки предлагают по цене обычного хостинга, раздел об исключениях стоит прочитать дважды.
Исключения и компенсации
Исключения — это случаи, когда простой не считается простоем. Сами по себе они нормальны, но именно этот список определяет, чего стоит цифра на первой странице. Типичные пункты:
- плановые работы — важно, за сколько о них предупреждают, в какое время проводят и есть ли предел по длительности;
- сбои у третьих сторон: магистральные провайдеры, регистратор домена, внешние сервисы;
- последствия действий самого заказчика — например, изменений, внесённых на сервер в обход подрядчика;
- ошибки в коде приложения, если договор покрывает только инфраструктуру;
- сетевые атаки и обстоятельства непреодолимой силы.
Если список исключений длиннее списка обязательств, обещание доступности превращается в декларацию.
SLA без последствий за нарушение — это не обязательство, а пожелание самому себе.
Теперь о последствиях. Обычный механизм — компенсация: перерасчёт или скидка на следующий период, размер которой зависит от того, насколько превышен порог. Посмотрите, начисляется ли она автоматически или только по заявлению в ограниченный срок, есть ли у неё верхний предел и чем подтверждается сам факт простоя. Компенсация по SLA, как правило, не покрывает упущенную выручку. Её задача в другом: у исполнителя должен быть денежный интерес не нарушать договор.
Что проверить до подписи
- Время реакции и время решения названы отдельно, и понятно, что считается реакцией.
- Окно поддержки совпадает с часами, когда ваш бизнес зарабатывает.
- Описано, что такое простой, кто его фиксирует и за какой период считается доступность.
- Проценты переведены в часы — и эти часы вас устраивают.
- Список исключений прочитан, плановые работы ограничены по времени и согласуются заранее.
- Есть компенсация за нарушение и понятный порядок её получения.
- Указаны каналы обращения и порядок эскалации, если ответа нет.
- Предусмотрен регулярный отчёт: доступность, инциденты, выполненные работы.
- Отдельно описаны резервные копии: как часто делаются, где хранятся и как проверяются. Подробнее — в статье о бэкапах, которые восстанавливаются.
SLA не делает систему надёжной — надёжной её делает работа, которая за ним стоит. Из чего эта работа состоит, мы рассказали в статье «Как мы держим аптайм 99.9%». А сам документ нужен, чтобы в трудный момент обе стороны одинаково понимали, кто, что и к какому сроку должен сделать.