Что такое SLA дата-центра
SLA (Service Level Agreement) — это письменное обязательство дата-центра по доступности инфраструктуры: электропитания, охлаждения и сети. В договоре аренды выделенного сервера SLA обычно выражен в процентах, например 99.9% или 99.99%, и привязан к денежной компенсации за простой сверх нормы.
Процент доступности сам по себе мало что говорит, пока вы не переведёте его в часы и минуты простоя за год. Дальше разберём, как это сделать и на что в SLA дата-центра смотреть в первую очередь.
Уровни Tier I-IV: в чём разница
Классификация Uptime Institute делит дата-центры на четыре уровня по резервированию инженерных систем — питания, охлаждения, вводов связи.
| Tier | Резервирование | Гарантированная доступность | Простой в год |
|---|---|---|---|
| Tier I | Без резерва | 99.671% | 28.8 часа |
| Tier II | N+1 | 99.741% | 22.0 часа |
| Tier III | N+1, обслуживание без остановки | 99.982% | 1.6 часа |
| Tier IV | 2N+1, отказоустойчивый | 99.995% | 0.4 часа |
Провайдер редко указывает Tier явно в маркетинге, но почти всегда пишет процент SLA — по нему можно понять реальный уровень резервирования систем питания, о которых рассказано отдельно.
Сколько это в минутах простоя
Перевести проценты в абсолютные цифры несложно: (100% − SLA%) × количество минут в году.
| SLA | Простой в год |
|---|---|
| 99% | 3.65 суток |
| 99.9% | 8.76 часа |
| 99.95% | 4.38 часа |
| 99.99% | 52.56 минуты |
| 99.999% | 5.26 минуты |
Разница между 99.9% и 99.99% — это разница между рабочим днём простоя и часом обеда. Для интернет-магазина или биллинга это принципиально.
Что SLA дата-центра не покрывает
SLA дата-центра отвечает за инфраструктуру здания и канала до стойки. Он не отвечает за:
- Аварии операционной системы и приложений на самом сервере.
- Выход из строя диска или планки памяти внутри вашего оборудования.
- Ошибки конфигурации, которые внёс администратор сервера.
- DDoS-атаки на уровне приложения — от них помогает отдельная защита.
Поэтому высокий процент SLA от дата-центра не отменяет мониторинга самого сервера и резервного копирования данных.
Как проверить доступность сервера самостоятельно
Не полагайтесь только на отчёты провайдера — ведите независимый учёт аптайма.
uptime
# 10:14:02 up 214 days, 3:41, 2 users, load average: 0.12, 0.09, 0.05
Для внешнего контроля используйте сторонний сервис проверки доступности с интервалом опроса 30-60 секунд и алертом в мессенджер. Это дополняет мониторинг железа через IPMI, который следит за температурой, дисками и питанием внутри самого сервера.
Чек-лист перед выбором дата-центра
- Уточните заявленный Tier и процент SLA письменно, а не на словах.
- Проверьте, что компенсация в SLA не превращается в символические бонусные дни.
- Спросите про резервирование электропитания и локацию дата-центра относительно рисков региона.
- Ведите собственный мониторинг доступности параллельно с отчётами провайдера.
Частые формулировки в SLA и что за ними стоит
| Формулировка в договоре | Что она означает на практике |
|---|---|
| Компенсация в виде bonus days | Возврат не деньгами, а бесплатными днями аренды — реальная компенсация ниже, чем кажется в процентах |
| SLA распространяется на сетевую инфраструктуру ЦОД | Не включает канал до конкретного сервера внутри стойки и оборудование, установленное клиентом |
| Плановые работы не считаются простоем | Дата-центр может исключить из расчёта SLA заранее анонсированные окна обслуживания |
| Форс-мажор исключён из расчёта | Стихийные бедствия и внешние события за пределами контроля ЦОД не влияют на выплату компенсации |
SLA дата-центра vs SLA хостинг-провайдера
| Уровень | За что отвечает | Куда обращаться |
|---|---|---|
| SLA дата-центра | Питание, охлаждение, канал до стойки | Обычно только через хостинг-провайдера |
| SLA хостинг-провайдера | Работоспособность сервера и поддержка | В службу поддержки провайдера |
| Мониторинг клиента | Раннее обнаружение проблемы | Собственные инструменты и алерты |
| Резервное копирование | Восстановление данных при любом сбое | Собственная политика бэкапов клиента |
Когда SLA дата-центра не имеет значения
- Простой из-за DDoS-атаки на приложение — покрывается отдельной защитой, а не SLA инфраструктуры
- Ошибка администратора (неверная команда, удалённые данные) — ответственность самого клиента
- Сервер работает без резервирования сети или диска на стороне клиента, хотя дата-центр резервирует всё своё
- Договор подписан не напрямую с дата-центром, а через посредника, который сам определяет условия компенсации для конечного клиента
Как считается компенсация за нарушение SLA
Типичная схема компенсации — процент от ежемесячной стоимости аренды за каждый час простоя сверх гарантированного, с потолком в 100% месячной платы. То есть даже при многодневном простое клиент обычно не получит больше, чем стоимость месяца аренды — компенсация покрывает неудобство, но не упущенную выгоду бизнеса. Эту разницу стоит учитывать при выборе между дешёвым дата-центром без явного SLA и более дорогим с прозрачной схемой компенсации: сама компенсация редко бывает большой, но её наличие говорит об уровне ответственности провайдера.
Частые вопросы
Если дата-центр заявлен как Tier III, значит ли это, что у хостинг-провайдера такой же уровень SLA?
Не обязательно: уровень Tier описывает резервирование инженерных систем самого здания, а SLA, который клиент подписывает с хостинг-провайдером, может быть мягче или жёстче, потому что покрывает ещё и работу самого сервера, сеть внутри стойки и поддержку. Эти два документа стоит смотреть отдельно, а не считать, что высокий Tier автоматически переносится на договор с провайдером.
Если SLA дата-центра исключает плановые работы из расчёта простоя, это тревожный признак?
Само по себе исключение плановых работ — обычная практика в отрасли, а не повод для тревоги, если окна обслуживания анонсируются заранее и укладываются в разумные рамки. Настороженность стоит проявлять тогда, когда формулировка расплывчата и не уточняет ни периодичность, ни продолжительность таких работ — тогда под неё можно списать практически любой простой задним числом.
Стоит ли переплачивать за дата-центр уровня Tier IV для небольшого проекта?
Для небольшого проекта с нормальным окном на обслуживание и допустимым изредка кратким простоем переплата за максимальный уровень резервирования обычно не окупается. Смысл в Tier IV появляется там, где простой стоит дорого каждую минуту: биллинг, финансовые сервисы, критичная инфраструктура клиента — именно для таких задач разница в резервировании питания и сети становится ощутимой.
Зачем вообще смотреть на SLA дата-центра, если клиент подписывает договор только с хостинг-провайдером?
SLA дата-центра задаёт потолок, выше которого провайдер физически не может подняться: если здание само по себе не резервирует питание и сеть, никакое обещание в договоре провайдера это не исправит. Поэтому SLA дата-центра стоит воспринимать как основу, на которой строится договор с провайдером, а не как документ, не имеющий отношения к клиенту.