⏱️ Гарантии доступности · Регламент реагирования

Service Level Agreement -
обязательства, а не обещания

Один наш проект работает 19 лет, обслуживая 100,000+ пользователей ежедневно. Это не реклама - это операционная дисциплина: измеримые метрики доступности, чёткие приоритеты инцидентов, регламент эскалации и проверяемые обязательства, зафиксированные в контракте.

Уровни доступности

Доступность измеряется в процентах от общего календарного времени за расчётный период (месяц). Плановые работы, согласованные за 5 рабочих дней до проведения и выполненные в окне обслуживания, в простой не засчитываются.

Standard - 99.9%

Допустимый простой: ≈ 8.76 часов в год (≈ 43.8 минут в месяц).

Подходит для большинства внутренних enterprise-систем без жёстких требований к непрерывной доступности. Резервирование критических узлов, плановое резервное копирование, рабочее время поддержки + дежурство.

Business - 99.95%

Допустимый простой: ≈ 4.38 часов в год (≈ 21.9 минут в месяц).

Для систем, поддерживающих основные бизнес-процессы. Активное резервирование, автоматизированное восстановление, мониторинг 24×7, дежурная смена. Подходит для большинства финансовых, торговых и операционных платформ.

Critical - 99.97%

Допустимый простой: ≈ 2.63 часа в год (≈ 13.1 минут в месяц).

Для критических enterprise-систем: горячее резервирование, geo-распределение, регулярные DR-учения, круглосуточная поддержка с гарантированным временем реакции, post-mortem по каждому инциденту P1/P2.

Уровни выше 99.99% («четыре девятки») - отдельная инфраструктурная задача, требующая множественного географического резервирования и сертифицированных дата-центров. Доступно в проектном порядке.

Приоритеты инцидентов и целевое время реакции

Время реакции = время от регистрации обращения до старта работ ответственным инженером. Время восстановления зависит от характера дефекта; фиксируется отдельно для каждого приоритета. Нормативы ниже - индикативные значения для Business-уровня; для Critical SLA сроки сокращаются вдвое.

P1 - Критический

Полная неработоспособность системы или ключевого бизнес-процесса; пострадало значимое количество пользователей.

  • Время реакции: 15 минут (24×7)
  • Целевое восстановление: 2-4 часа (зависит от характера сбоя)
  • Эскалация: архитектор + руководитель направления немедленно
  • Коммуникации: статус каждые 30 минут до восстановления
  • Post-mortem: обязательно, в течение 5 рабочих дней

P2 - Высокий

Серьёзная функциональная деградация без полного отказа; обходные пути ограничены или существенно неудобны.

  • Время реакции: 1 час (рабочие часы), 2 часа (нерабочие)
  • Целевое восстановление: в течение рабочего дня
  • Эскалация: руководитель направления в течение часа
  • Коммуникации: статус каждые 2 часа
  • Post-mortem: обязательно для критичных бизнес-функций

P3 - Средний

Функциональный дефект с доступным обходным решением. Влияние ограничено отдельной функцией или группой пользователей.

  • Время реакции: 4 рабочих часа
  • Целевое восстановление: в следующем релизном цикле
  • Эскалация: по запросу или по истечении сроков
  • Коммуникации: обновление при изменении статуса

P4 - Низкий

Некритический дефект, запрос на доработку, информационный вопрос или консультация.

  • Время реакции: 1 рабочий день
  • Целевое восстановление: в плановом порядке
  • Эскалация: по запросу
  • Коммуникации: при закрытии

Модель поддержки и регламент эскалации

Каналы обращений

Регистрация инцидентов через утверждённую систему учёта (Jira / ServiceNow / собственная система клиента). Для P1 - дополнительно телефон дежурного инженера. Email и мессенджеры - только для классификации P3/P4 и общих запросов.

Эскалация

Three-tier: L1 - диагностика и обходные решения; L2 - инженер-разработчик / DevOps; L3 - архитектор / руководитель направления. Автоматическая эскалация по истечении нормативного времени реакции на каждом уровне.

Окно обслуживания

Плановые технологические работы - согласовываются не менее чем за 5 рабочих дней. Стандартное окно: ночь субботы/воскресенья по согласованному часовому поясу. Экстренные работы (с уведомлением, но без согласования) допустимы только для устранения критических уязвимостей безопасности.

RPO / RTO

Стандартные значения: RPO 15-60 минут, RTO 2-4 часа для Standard/Business SLA. Для Critical SLA: RPO ≤ 5 минут, RTO ≤ 30 минут при горячем резервировании. Конкретные значения для каждого проекта фиксируются в контракте.

Резервное копирование

Ежедневное полное и почасовое инкрементное (стандарт), хранение 30 дней (Standard), 90 дней (Business), 365 дней (Critical / регулируемые системы). Регулярная проверка восстанавливаемости - обязательная практика, документируется актами.

Отчётность

Ежемесячный SLA-отчёт: фактическая доступность, перечень инцидентов с приоритетами и временем закрытия, статус корректирующих действий по post-mortem. Ежеквартальный архитектурный обзор - для Business / Critical.

Сервисный кредит при нарушении SLA

При нарушении гарантированного уровня доступности или нормативов времени реакции SLA-соглашение предусматривает сервисный кредит - снижение стоимости услуг поддержки за расчётный период. Точные пороги, проценты и потолки согласовываются индивидуально и фиксируются в контракте каждого проекта.

Индикативный шаблон - Business SLA, нарушение доступности:

99.5% ≤ ДОСТ < 99.95%

Сервисный кредит 10% от месячной стоимости поддержки.

99% ≤ ДОСТ < 99.5%

Сервисный кредит 25% от месячной стоимости поддержки.

ДОСТ < 99%

Сервисный кредит 50% от месячной стоимости поддержки + post-mortem с корректирующими действиями.

Уровни SLA - обсуждаются под конкретный проект

Конкретный уровень доступности, RPO/RTO, нормативы реакции и шаблон сервисного кредита подбираются под бизнес-критичность системы. За один разговор оценим, какой уровень оправдан, какая инфраструктура потребуется и как это отразится на стоимости.

Согласовать SLA проекта

Связанные материалы

Compliance

152-ФЗ, ФСТЭК и регуляторные требования - операционная сторона начинается с архитектуры.

Compliance roadmap

Кейсы

Системы, которые работают 19 лет под реальной нагрузкой - это и есть SLA, проверенный практикой.

Кейсы

Регулируемые системы

Архитектура для медицинских, банковских и государственных систем - где SLA не маркетинг, а контрактное обязательство.

Регулируемые системы