Перейти к основному содержимому

Уровни SLA и реальное время простоя

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Аналитику
Теория данных (раздел 3)

Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.

Уровни SLA и реальное время простоя​

SLA (Service Level Agreement / Соглашение об уровне обслуживания) — это официальный юридический или внутренний договор между заказчиком и поставщиком услуг, который четко описывает саму услугу, фиксирует целевые показатели ее качества (например, доступность, скорость ответа), а также определяет штрафы и компенсации за их нарушение.

Время простоя (Downtime) — это суммарный период времени, в течение которого сервис, ИТ-система или инфраструктура полностью недоступны для использования или не выполняют свои критически важные бизнес-функции.

Уровень обслуживания (Service Level / SL) — это конкретная, измеримая метрика или процентное значение, которое отражает фактическое качество работы сервиса (например, «доступность 99.9%» или «время ответа техподдержки до 15 минут») и используется для оценки выполнения условий SLA.

Концепция услуги, договора, заказчика и обязательных блоков SLA — в разделе 7.16 / SLA. Ниже — инженерный расчёт доступности ("девятки") и связь с SLO.

SLA — это соглашение об уровне обслуживания. Это формальный документ, в котором фиксируются обязательства поставщика услуг перед клиентом. В контексте информационных технологий SLA описывает, насколько надежно и стабильно будет работать сервис, как быстро будут устраняться сбои, и какие параметры качества гарантированы.

SLA содержит конкретные метрики, измеримые показатели и временные рамки. Эти условия становятся основой для взаимодействия между сторонами — заказчик знает, чего ожидать, а исполнитель несет ответственность за выполнение обещанного. Часто SLA включает финансовые санкции или компенсации в случае нарушения условий — например, возврат части оплаты при превышении допустимого времени простоя.

Основная цель SLA — установить прозрачные и предсказуемые правила работы. Это особенно важно в IT-инфраструктуре, где даже короткий простой может повлечь за собой серьезные последствия: потерю дохода, репутационный ущерб или срыв бизнес-процессов. SLA помогает минимизировать риски, выстроить доверие и обеспечить согласованность ожиданий.

Уровни доступности и понятие "пять девяток"​

Доступность сервиса (Availability) — это доля времени (обычно выраженная в процентах), в течение которого ИТ-система или услуга находится в рабочем состоянии, выполняет свои функции и открыта для использования клиентами. Это один из ключевых параметров в любом SLA. Она выражается в процентах и показывает, какую долю времени система находится в рабочем состоянии за определенный период, обычно за календарный год. Этот показатель напрямую связан с допустимым временем простоя.

При фиксации «доступности» стороны обязаны договориться, какие именно часы и минуты вычитаются из формулы:

  • Плановое обслуживание (Maintenance): обычно ИТ-команды вычитают время согласованных ночных апдейтов из «Общего времени периода», чтобы они не портили статистику доступности.
  • Частичная доступность: если у банка работает сайт, но «легло» мобильное приложение — это простой или нет? В SLA важно прописать, доступность каких именно критических функций (авторизация, оплата, просмотр баланса) приравнивается к доступности всего сервиса.
  • Географический фактор: сервис должен быть доступен из любой точки мира или только из целевого региона бизнеса?

Часто используют терминологию, основанную на количестве девяток после запятой. Например:

  • 90% — "одна девятка"
  • 99% — "две девятки"
  • 99.9% — "три девятки"
  • 99.99% — "четыре девятки"
  • 99.999% — "пять девяток"

Каждая дополнительная девятка означает порядок снижения допустимого времени простоя. При этом разница между уровнями кажется незначительной только на первый взгляд. На практике она кардинально влияет на архитектуру, стоимость эксплуатации и требования к инженерным решениям.

Реальное время простоя при разных уровнях доступности​

Рассмотрим, сколько минут или секунд в году соответствует каждому уровню доступности.

При 90% доступности система может быть недоступна до 36.5 дней в году. Такой уровень приемлем лишь для некритичных сервисов, где простои не влияют на основную деятельность.

При 99% доступности допустимый простой составляет около 3.65 дней в год, или чуть больше 87 часов. Это уже подходит для внутренних корпоративных систем, но не для публичных онлайн-сервисов.

Уровень 99.9% ("три девятки") допускает простой до 8.76 часов в год. Многие коммерческие веб-приложения стремятся к этому показателю. Он требует базовой отказоустойчивости — резервирование каналов связи, мониторинг, автоматическое переключение на резервные компоненты.

Переход на 99.99% ("четыре девятки") сокращает допустимое время простоя до 52.6 минут в год. Достижение такого уровня требует продуманной архитектуры — географически распределенные дата-центры, активное резервирование серверов, автоматическое восстановление, тщательное тестирование аварийных сценариев.

Наивысший практический уровень — 99.999% ("пять девяток"). Здесь допустимый простой составляет всего 5.26 минуты в год. Такой уровень характерен для телекоммуникационных систем, финансовых платформ, критически важных государственных сервисов. Обеспечение "пяти девяток" требует не только технической сложности, но и строгих организационных процедур — круглосуточная поддержка, многоуровневое резервирование, регулярные учения по восстановлению, избыточность на всех уровнях — от оборудования до персонала.

Почему "пять девяток" — это не просто цифра​

Переход от трех или четырех девяток к пяти меняет математику простоя, архитектуру систем и стоимость обслуживания. При уровне 99.999% система имеет право не работать всего 5 минут и 15 секунд за целый год (или около 26 секунд в месяц). Посмотрите на разницу в допустимом простое:

  • 99.0% (две девятки) — 3.6 дня простоя в год. Подходит для локального блога.
  • 99.9% (три девятки) — 8.7 часа в год. Стандарт для большинства бизнес-систем (CRM, ERP).
  • 99.99% (четыре девятки) — 52.5 минуты в год. Уровень хороших облачных провайдеров.
  • 99.999% (пять девяток) — 5.25 минуты в год. Уровень ядра сотовых операторов, межбанковских транзакций (SWIFT) и систем жизнеобеспечения.

Главный вывод из математики пяти девяток: человек физически не способен обеспечить такую доступность. Если система упала, дежурный инженер даже при мгновенной реакции потратит:

  • 1 минуту на получение СМС от мониторинга.
  • 2 минуты на открытие ноутбука и авторизацию в VPN.
  • 2 минуты на ввод базовых команд диагностики.

Все, лимит в 5 минут на год исчерпан.

Цель достичь "пяти девяток" часто звучит как маркетинговый лозунг, но на деле это чрезвычайно трудоемкая задача. Каждая дополнительная девятка увеличивает стоимость владения системой в разы. Инженерные усилия, необходимые для перехода от четырех к пяти девяткам, значительно превосходят усилия, затраченные на достижение трех или четырех. Нельзя получить 99.999% просто купив надежный сервер. Ломается абсолютно всё. Чтобы пережить любой сбой, архитектура должна быть построена по принципу «Zero Single Point of Failure» (отсутствие единой точки отказа):

  • Active-Active в нескольких ЦОД: сервис запущен одновременно в двух или трех географически разнесенных дата-центрах. Если один ЦОД полностью сгорит или уйдет под воду, оставшиеся мгновенно подхватят нагрузку.
  • Резервирование инфраструктуры: к каждому серверу подведено минимум два независимых луча питания от разных подстанций, а сетевые стыки идут через разных магистральных провайдеров.
  • Масштабирование баз данных: синхронная репликация данных между площадками. Это сложнейшая инженерная задача, так как запись в базу не считается успешной, пока данные не запишутся на все узлы сети.

Более того, реальное время простоя зависит не только от технических факторов. Человеческий фактор, ошибки конфигурации, задержки в реакции на инциденты, проблемы с поставщиками — всё это влияет на итоговую доступность. Поэтому высокие уровни SLA требуют не только надежного оборудования, но и зрелых процессов — управления инцидентами, управления изменениями, автоматизации, документирования.

Важно понимать, что заявленный уровень SLA не всегда совпадает с реальным временем безотказной работы. Некоторые поставщики могут исключать из расчета плановые технические работы, обновления или форс-мажорные обстоятельства. Поэтому при заключении соглашения необходимо внимательно изучать формулировки — что именно считается простоем, какие события включаются в расчет, и как фиксируется нарушение условий.

Практические аспекты измерения простоя​

Практическое измерение простоя — это главная точка конфликта между клиентом и поставщиком. Клиент считает простоем время, когда его сотрудники или клиенты не могли работать, а провайдер — время, когда его «железо» не отвечало на проверочные запросы (ping). Чтобы настроить прозрачный мониторинг и исключить манипуляции, нужно внедрить пять практических шагов.

  1. Согласовать техническую точку измерения (Boundary). Нельзя мерить доступность «вообще», нужно четко зафиксировать, откуда и куда идет запрос. Настройте внешние проверки (Synthetic Monitoring) из разных географических точек (например, через UptimeRobot, Pingdom или собственные агенты в дружественных сетях).
  2. Заменить Ping на проверку бизнес-логики (Health Checks). Доступность порта или сервера не означает работоспособность сервиса. Создайте специальный служебный URL (например, /healthcheck), который при обращении выполняет реальный легкий запрос к базе данных, проверяет доступность кэша и дисковой системы.
  3. Автоматизировать фиксацию и открыть логи (Dashboard). Человеческий фактор при подсчете минут должен быть исключен. Разверните совместный или публичный дашборд (Status Page) на базе систем мониторинга (Prometheus/Grafana, Zabbix).
  4. Внедрить правило «Окна простоя» (Time Window). Единичные секундные моргания сети не должны размывать общую статистику, но и не должны игнорироваться, если они регулярны. Установите минимальный порог непрерывной ошибки. Например, простой засчитывается, если сервис недоступен более 3 минут подряд.
  5. Четко регламентировать «Плановые работы» (Maintenance). Самый частый способ легального завышения uptime со стороны провайдера — проведение бесконечных регламентных работ. Введите жесткие лимиты на обслуживание в тексте договора.

Измерение времени простоя — это отдельная инженерная задача. Для объективной оценки используются внешние системы мониторинга, которые проверяют доступность сервиса из разных точек мира с заданной периодичностью. Если сервис не отвечает в течение определенного интервала, это фиксируется как инцидент.

Время простоя начинает отсчитываться не с момента возникновения сбоя внутри системы, а с момента, когда пользователь не может получить доступ к функциональности. Это принципиально — внутренние ошибки, не влияющие на конечного пользователя, не считаются простоем в рамках SLA.

Также важно учитывать, что простоя может не быть, но сервис может работать некорректно — например, возвращать ошибочные данные или сильно замедляться. В таких случаях SLA может включать дополнительные метрики — время отклика, процент успешных запросов, точность данных. Это делает соглашение более полным и защищает клиента не только от полного отсутствия сервиса, но и от его деградации.

Как читать SLA без иллюзий​

Чтобы читать SLA (Service Level Agreement) без иллюзий, важно понимать, что документ защищает провайдера от выплат в той же мере, в какой обещает клиенту стабильность. Заветные «девятки» (например, доступность 99.9%) на практике часто оказываются юридической уловкой.

Перед подписанием соглашения полезно пройти короткий список вопросов:

  1. Как именно считается простой — по внутренним метрикам поставщика или по внешнему мониторингу?
  2. Входит ли деградация производительности в нарушение SLA, или учитывается только полная недоступность?
  3. Исключаются ли из расчёта плановые окна, инциденты провайдера и форс-мажор?
  4. Какая формула компенсации и каков верхний лимит выплат?

Этот шаг часто важнее самой цифры "99.95%", потому что формулировки определяют реальную ответственность сторон.

Мини-кейс "Три девятки vs четыре девятки"​

Два продукта:

  • внутренний сервис отчетности для команды продаж;
  • внешний платежный API для клиентов.

Для отчётности уровень 99.9% обычно достаточен: при инциденте несколько часов простоя в год допустимы.
Для платежного API переход к 99.99% оправдан, потому что каждая недоступная минута напрямую влияет на выручку и доверие пользователей.

Вывод: уровень SLA выбирается из бизнес-риска, а не из "красоты числа".

Связанные метрики вокруг SLA​

SLA полезно трактовать вместе с эксплуатационными показателями:

  • SLI — что именно измеряем (доступность, latency, error rate).
  • SLO — целевое значение для команды.
  • Error budget — допустимый объём ухудшения до остановки релизов.

Такой набор связывает договорную часть с технической практикой команды.

Смежные материалы​

Содержание