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

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.

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.

99.5% ≤ ДОСТ < 99.95%

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

99% ≤ ДОСТ < 99.5%

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

ДОСТ < 99%

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

Как рассчитывается процент доступности?

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

Какая доступность реалистична для enterprise-систем?

99.9% (около 8.76 часов в год) - достижимо для большинства систем без избыточной инфраструктуры. 99.95% (около 4.38 часов) - требует резервирования критических узлов и автоматизированного восстановления. 99.97% (около 2.63 часа) - горячее резервирование, geo-распределение, проверенный план DR. Выше 99.99% - отдельная задача с пропорциональной стоимостью.

Что означают приоритеты P1 / P2 / P3 / P4?

P1 - система или ключевой процесс полностью неработоспособны. P2 - серьёзная деградация без полного отказа, обходные пути ограничены. P3 - дефект с обходным решением, влияние локализовано. P4 - некритический дефект, обращение, запрос на доработку или вопрос.

Что входит в регламент реагирования на инциденты?

Регистрация обращения, классификация по приоритету, назначение ответственного, диагностика, обходное решение или восстановление сервиса, передача в работу постоянного исправления, акт закрытия, для P1/P2 - пост-инцидентный анализ. Все этапы фиксируются в системе учёта обращений.

Что такое RPO и RTO?

RPO - максимально допустимая потеря данных при сбое (в единицах времени). RTO - максимально допустимое время восстановления. Стандарт для enterprise: RPO 15-60 минут, RTO 2-4 часа. При горячем резервировании: RPO не более 5 минут, RTO не более 30 минут. Значения фиксируются в SLA каждого проекта.

Предусмотрены ли компенсации при нарушении SLA?

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

Compliance

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

Compliance roadmap

Кейсы

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

Кейсы

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

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

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