Соглашения об уровне обслуживания и дежурная модель

Версия: 1.0 Дата: 27.04.2026 Статус: Готов к обсуждению

Назначение документа

Документ определяет формальные соглашения об уровне обслуживания (Service Level Agreement, SLA) платформы Vitiana для тенантов и дежурную модель (on-call model) платформы. Включает:

• Каноничную модель SLA: SLAClass, SLAObligation, SLAMeasurement, ServiceCredit, SLABreachIncident.
• Каноничные показатели уровня обслуживания (Service Level Indicators, SLIs) и целевые значения (Service Level Objectives, SLOs) по тарифам.
• Структуру компенсаций (service credits) при нарушении SLA.
• Бюджет ошибок (error budget) как операционный механизм управления релизами.
• Дежурную модель — структура смен, эскалация, ротация, follow-the-sun.
• Обязанности дежурного, психологическую безопасность.
• Каноничный процесс отчётности по SLA для партнёров.
• Процедуру урегулирования споров по SLA.
• Метрики операционной зрелости дежурной модели.
• Связь SLA с тарифами и контрактами.
• Фазы развёртывания.

Документ читается после:

• Программный интерфейс как продукт — концептуальные SLA по тарифам (95% / 99% / 99.9%).
• Операционная ось — принципы on-call rotation.
• Runbook'и инцидент-плейбуки — каноничная процедура эскалации.
• Observability And Incident Response — классы инцидентов, измерение метрик.
• Архитектурный якорь и бизнес-модель — SLA как продуктовый атрибут тарифов.
• Экономическая модель платформы — финансовые следствия service credits.

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

SLA — формальное обещание платформы тенанту, не маркетинговый материал. Нарушение SLA — это финансовое обязательство (service credits) и репутационный риск. Без чёткой каноничной модели измерения и обещаний — споры с партнёрами становятся бесконечными.

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

Реальное состояние реализации: формальных SLA нет (платформа не запущена в production для партнёров); дежурная модель не сформирована. Этот документ закладывает целевую структуру.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: SLA задаются платформой, не наследуются от поставщиков. Если поставщик нестабилен — SLA платформы по-прежнему гарантирует тенанту определённый уровень обслуживания, потому что платформа обязана смягчать деградацию поставщиков (через failover, fallback, circuit breaker — см. Runbook 1. Supplier Degradation Incident).

Главное решение

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

Дежурная модель — структурированная инфраструктура с явными ролями, ротацией, эскалацией, защитой от выгорания.

Это означает:

• Многоуровневая модель — SLI, SLO, SLA — каждый уровень с разной ролью.
• Каноничные SLI — что измеряется (доступность, задержка, ошибки, свежесть данных).
• Целевые значения SLO — внутренние цели команды (типично выше публичных SLA для запаса).
• Публичные SLA — обещания тенантам (формализованные в контракте по тарифу).
• Бюджет ошибок (error budget) — допустимая «доля плохого» в SLO; используется для управления релизами и экспериментами.
• Service credits — каноничная компенсация при нарушении SLA, рассчитываемая по формуле.
• Дежурная модель — primary + secondary on-call, чётко определённые смены, регулярная ротация.
• Защита от выгорания — лимиты на число смен в месяц, обязательный отдых после крупного инцидента, обязательная поддержка.
• Public status page — публичный канал коммуникации о состоянии платформы.
• Регулярная отчётность — ежемесячный SLA report для партнёров Professional и выше.

Каноничная модель SLA

Главные сущности

SLAClass — класс SLA

Сущность, представляющая именованный класс уровня обслуживания, привязанный к тарифу.

{
  class_id: UUID,
  class_key: enum,
  class_name: string,
  applicable_tariffs: array,
  obligations: array,
  service_credit_policy: object,
  effective_from: timestamp,
  effective_to: timestamp,
  schema_version: string,
  is_active: boolean
}

Поля:

• class_key — каноничный ключ (best_effort для Free; standard_sla для Starter; professional_sla для Professional; enterprise_sla для Enterprise; custom_enterprise_sla для индивидуальных контрактов).
• obligations — массив SLAObligation.
• service_credit_policy — формула расчёта компенсаций.

SLAObligation — обязательство SLA

Сущность, представляющая конкретное измеримое обязательство в рамках класса.

{
  obligation_id: UUID,
  sla_class_id: UUID,
  sli_metric: string,
  target_value: numeric,
  measurement_window: object,
  evaluation_period: enum,
  applicable_surface: array,
  exclusions: array,
  schema_version: string
}

Поля:

• sli_metric — каноничная метрика SLI (см. ниже).
• target_value — целевое значение (например, 99.5 для доступности).
• measurement_window — окно измерения (например, 30 дней rolling).
• evaluation_period — период оценки (monthly / quarterly).
• applicable_surface — для каких поверхностей применимо (партнёрская, потребительская, агентская, Tour Builder).
• exclusions — что исключается (запланированное обслуживание с предупреждением, форс-мажор, проблемы на стороне партнёра).

SLAMeasurement — измерение SLA

Сущность, представляющая зафиксированное значение SLI за период.

{
  measurement_id: UUID,
  obligation_id: UUID,
  tenant_id: UUID,
  measured_period_start: timestamp,
  measured_period_end: timestamp,
  measured_value: numeric,
  obligation_target: numeric,
  is_breached: boolean,
  affected_minutes: integer,
  affected_requests_count: integer,
  measurement_methodology: object,
  measured_at: timestamp
}

Поля:

• is_breached — нарушено ли обязательство.
• affected_minutes — общая длительность периодов вне SLI (для расчёта credits).
• affected_requests_count — число затронутых запросов (для тарифов с per-request credits).

ServiceCredit — служебная компенсация

Сущность, представляющая зачёт компенсации тенанту за нарушение SLA.

{
  credit_id: UUID,
  tenant_id: UUID,
  triggered_by_measurement_id: UUID,
  credit_amount: numeric,
  credit_currency: string,
  applicable_billing_period: string,
  state: enum,
  applied_at: timestamp,
  approved_by: string,
  customer_notification_sent_at: timestamp
}

Поля:

• state — состояние (pending_review / approved / applied / disputed).
• approved_by — кто одобрил (для крупных сумм — несколько уровней одобрения).
• applicable_billing_period — на какой расчётный период применяется кредит.

SLABreachIncident — инцидент нарушения SLA

Сущность, представляющая зафиксированное нарушение SLA.

{
  breach_id: UUID,
  tenant_ids_affected: array,
  obligation_id: UUID,
  detected_at: timestamp,
  resolved_at: timestamp,
  duration_minutes: integer,
  root_cause: string,
  related_runbook_executions: array,
  related_incidents: array,
  customer_notifications_sent: array,
  service_credits_issued: array,
  post_mortem_required: boolean,
  post_mortem_completed_at: timestamp
}

Связь с другими каноничными сущностями

• SLAClass.applicable_tariffs — связь с PricingPlan из Экономическая модель платформы.
• SLAMeasurement.tenant_id — связь с Tenant из Tenancy And Identity.
• ServiceCredit отражается в счетах через Партнёрские взаиморасчёты.
• SLABreachIncident.related_runbook_executions — связь с RunbookExecution из Runbook'и инцидент-плейбуки.

Каноничные показатели SLI

Базовый набор SLI платформы

SLI 1. Доступность партнёрской поверхности (Partner API Surface availability)

Определение: доля успешных запросов (HTTP 2xx или 4xx — клиентские ошибки тенанта не считаются нарушением SLA) от всего трафика партнёрской поверхности.

Формула:

availability = (successful_requests + client_error_requests) / total_requests

Окно измерения: 30 дней rolling.

Исключения:

• Запланированное обслуживание с уведомлением за 7 дней.
• Форс-мажор (стихийные бедствия, действия государственных органов).
• Проблемы на стороне партнёра (тенант превысил лимит — это не наша проблема).

SLI 2. Задержка партнёрской поверхности (latency)

Определение: 95-й процентиль (p95) времени ответа основных эндпоинтов программного интерфейса.

Окно измерения: 30 дней rolling, отдельно по эндпоинту.

Метрики:

• p50, p95, p99 для каждого эндпоинта.
• Целевое значение для p95 — определяется тарифом (см. ниже).

SLI 3. Доставка уведомлений по обратным вызовам (webhook delivery success)

Определение: доля webhook-уведомлений, успешно доставленных партнёру в первой попытке.

Окно измерения: 30 дней rolling.

SLI 4. Свежесть поисковой выдачи (search freshness)

Определение: задержка между событием изменения предложения у поставщика и отражением в поисковой выдаче.

Окно измерения: 95-й процентиль за 30 дней rolling.

Целевое значение: медианно меньше 5 секунд для критичных изменений (доступность, цена), меньше 5 минут для контентных.

SLI 5. Скорость подтверждения бронирования (booking confirmation rate)

Определение: доля бронирований, переходящих в platform_confirmed за определённое время от submitted.

Окно измерения: 30 дней rolling.

Целевое значение: более 95% бронирований подтверждаются за 60 секунд.

SLI 6. Доля unknown_external_state бронирований

Определение: доля бронирований, попавших в unknown_external_state за период (см. Статусная машина бронирования).

Окно измерения: 30 дней rolling.

Целевое значение: менее 1% (как зафиксировано в booking-state-machine.md).

SLI 7. Доля успешных платёжных операций

Определение: доля PaymentTransaction со state captured (успешная фиксация) от всех попыток фиксации.

Окно измерения: 30 дней rolling.

SLI 8. Доля успешного восстановления из unknown_external_state

Определение: доля бронирований, для которых BookingRestorationJob дошёл до state_clarified без ручной эскалации.

Окно измерения: 30 дней rolling.

Целевое значение: более 95%.

SLI 9. MTTR — Mean Time To Resolve

Определение: среднее время от обнаружения инцидента до полного восстановления.

Окно измерения: месяц или квартал, разбивка по severity.

Целевые значения по severity:

• Critical — менее 1 часа.
• High — менее 4 часов.
• Medium — менее 24 часов.
• Low — менее 1 недели.

SLI 10. Время первого ответа поддержки

Определение: время от поступления тикета до первого ответа от человека в команде поддержки.

Целевое значение: зависит от тарифа (см. ниже).

Каноничные SLO и SLA по тарифам

Принцип SLO выше SLA

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

Пример:

• Публичный SLA: 99% доступности.
• Внутреннее SLO: 99.5% доступности.
• Бюджет ошибок: 0.5% (между SLO и SLA).

При исчерпании бюджета ошибок — релизы замедляются, эксперименты приостанавливаются.

Таблица обязательств по тарифам

SLI	Free	Starter (95%)	Professional (99%)	Enterprise (99.9%)
Доступность партнёрской поверхности	best effort	95.0%	99.0%	99.9%
Задержка p95 на основных эндпоинтах	best effort	менее 1с	менее 500мс	менее 300мс
Доставка webhook'ов в первой попытке	best effort	95%	98%	99%
Свежесть поисковой выдачи (медиана)	best effort	менее 30с	менее 10с	менее 5с
Скорость подтверждения бронирования (p95)	best effort	менее 5 минут	менее 90 секунд	менее 60 секунд
Доля unknown_external_state	без обещания	менее 3%	менее 1.5%	менее 1%
Время первого ответа поддержки (рабочие часы)	сообщество	24 часа	4 часа	1 час
Время первого ответа поддержки (24/7 для critical)	—	—	в рабочие часы	30 минут (24/7)
MTTR для critical инцидентов	—	best effort	менее 4 часов	менее 1 часа
Уведомление об инциденте	публичная страница статуса	публичная страница статуса	+ email	+ email + персональный звонок (для critical)

Особенности Enterprise SLA

Enterprise SLA — индивидуальный контракт с возможными расширениями:

• Гарантированная мощность (capacity guarantee) — выделенные ресурсы инфраструктуры.
• Выделенный инженер по успеху клиентов (dedicated success engineer).
• Расширенные часы поддержки (включая выходные).
• Custom SLA на специфические возможности (например, для конструктора туров).
• Recovery Time Objective (RTO) и Recovery Point Objective (RPO) для выделенной инфраструктуры — см. Восстановление после аварии и планирование мощностей.
• Процедура регулярных операционных сверок (operational reviews) — раз в квартал.

Бюджет ошибок (error budget)

Концепция

Бюджет ошибок — финансовое управление надёжностью. SLO выше SLA даёт «запас» — допустимую долю плохих минут/запросов, не нарушающую обещания тенанту.

Применение бюджета:

total_minutes_in_period = period_days × 24 × 60
allowed_bad_minutes = total_minutes_in_period × (1 - SLO)
consumed_bad_minutes = sum of incident durations affecting this SLI
remaining_budget = allowed_bad_minutes - consumed_bad_minutes
budget_consumption_rate = consumed / allowed

Например, для SLO 99.5% за 30 дней:

total_minutes = 30 × 24 × 60 = 43,200 минут
allowed_bad_minutes = 43,200 × 0.5% = 216 минут
если исчерпано 100 минут — бюджет 116 минут на остаток

Как используется бюджет

При наличии бюджета (например, 50% бюджета ещё не потрачено)

• Релизы идут штатно.
• Эксперименты A/B запускаются.
• Chaos engineering проводится по плану.
• Инфраструктурные изменения (миграции, апгрейды) проводятся.

При исчерпании бюджета (потрачено более 80%)

• Заморозка релизов не-критических возможностей.
• Приостановка экспериментов не-критичных.
• Отмена chaos engineering на текущий период.
• Фокус команды на стабилизацию.

При полном исчерпании (потрачено 100%+)

• Только критические релизы (security, hotfix) разрешены.
• Активное расследование root causes исчерпания.
• Эскалация к leadership.

Защита от «накопления резерва»

Бюджет ошибок не должен накапливаться между периодами. Если за месяц потрачено 0% — это не повод на следующий месяц быть менее осторожным. Каждый период — отдельный бюджет.

Расчёт служебных компенсаций (service credits)

Каноничная формула

При нарушении SLA по конкретному SLI:

breach_severity = max(0, SLA_target - measured_value)
credit_percent = breach_severity_to_credit_percent(breach_severity)
service_credit = monthly_subscription × credit_percent

Канонические уровни компенсаций

Для доступности:

Достигнутая доступность	Уровень нарушения	Service credit
≥ SLA target	(нет нарушения)	0%
SLA target − 0.5pp до SLA target	minor	5% от месячной подписки
SLA target − 2pp до SLA target − 0.5pp	moderate	10% от месячной подписки
SLA target − 5pp до SLA target − 2pp	major	25% от месячной подписки
ниже SLA target − 5pp	critical	50% от месячной подписки (максимум)

pp — процентный пункт; например 99% против 99.5% — разница 0.5pp.

Каноничная процедура запроса

• Автоматический расчёт — для большинства нарушений ServiceCredit создаётся автоматически на основе SLAMeasurement без явного запроса тенанта.
• Запрос тенанта — для пограничных случаев тенант может явно запросить пересмотр через программный интерфейс или поддержку.
• Срок применения — кредит применяется к следующему расчётному периоду в течение 30 дней с момента инцидента.
• Запрет на возврат деньгами — кредиты применяются только к будущим счетам, не возвращаются деньгами (стандарт индустрии).

Максимум на месяц

Совокупный размер service credits за месяц не превышает 100% месячной подписки — даже если несколько SLA нарушены одновременно. Это защита платформы от каскадного финансового удара при крупном инциденте.

Запрет на скрытые исключения

• ❌ Скрытые исключения, не указанные в контракте.
• ❌ Изменение методики измерения после нарушения для уменьшения компенсации.
• ❌ Отказ в кредите при подтверждённом нарушении.

Дежурная модель (on-call model)

Структура смен

Уровень 1 — Primary on-call

Состав: 1 инженер на смену.

Длительность смены: 12 или 24 часа в зависимости от фазы.

Обязанности:

• Подтверждение алертов в течение 15 минут (MTTA).
• Выполнение runbook'ов первой линии.
• Эскалация secondary при необходимости.

Доступность: в смене инженер обязан быть доступен в течение 15 минут с момента алерта.

Уровень 2 — Secondary on-call

Состав: 1 инженер на смену, более опытный.

Обязанности:

• Поддержка primary при сложных инцидентах.
• Принятие смены при недоступности primary в течение 15 минут.
• Совместный анализ root cause.

Активация: не вызывается на каждый алерт; вступает только при escalation.

Уровень 3 — Engineering Manager / Tech Lead on-call

Состав: руководитель команды.

Обязанности:

• Принятие архитектурных решений в инциденте.
• Координация cross-team действий.
• Решение по rollback крупных релизов.

Активация: при инцидентах severity critical или при затяжных high.

Уровень 4 — Director / VP on-call

Состав: ротация среди руководителей.

Обязанности:

• Принятие решений по приоритезации ресурсов.
• Коммуникация с leadership и leadership других команд.
• Согласование внешних коммуникаций.

Активация: только для крупных инцидентов с финансовым или регуляторным следствием.

Уровень 5 — CTO / CISO

Состав: один из них или оба в зависимости от типа инцидента.

Активация:

• Security инциденты (CISO).
• Критические архитектурные решения (CTO).
• Крупные публичные инциденты с затронутыми регуляторами.

Ротация смен

• Бросок монеты не используется — справедливое чередование по графику.
• Минимум 2 недели между сменами primary для одного инженера.
• Не более 2 смен в месяц primary для одного инженера (защита от выгорания).
• Запрет дежурить во время отпуска — все смены должны быть покрыты резервными.
• Прозрачный график на 3 месяца вперёд.

Follow-the-sun (фаза 4)

При появлении глобальной команды (фаза 4) — модель follow-the-sun:

• Команда в Европе дежурит во время EU дня.
• Команда в Азии (если будет) — во время Азиатского дня.
• Команда в Америке (если будет) — во время Американского дня.

Это устраняет необходимость ночных дежурств и значительно снижает нагрузку.

Каноничная процедура передачи смены (handover)

В момент смены — обязательная синхронизация:

• Текущие активные инциденты.
• Текущее состояние бюджета ошибок.
• Запланированные релизы или изменения.
• Открытые расследования.

Без формальной передачи — реальные риски пропустить критическое.

Защита от выгорания дежурных

Каноничные правила

• Лимит на смены — не более 2 раз primary в месяц на одного инженера.
• Обязательный отдых — после крупного инцидента (severity critical с длительностью более 4 часов) дежурный получает компенсирующий день отдыха.
• Психологическая поддержка — после крупных инцидентов с финансовым или регуляторным следствием — обязательный разговор с leadership и/или внешним психологом (если запрашивается).
• Защита от обвинений — все post-mortem blameless (без обвинения конкретных людей). Фокус на системных причинах.
• Право на отказ от смены — инженер может отказаться от смены без штрафа при болезни, выгорании, личных обстоятельствах. Дежурство — это работа, не личная жертва.

Запрет на «героические смены»

• ❌ Дежурство более 24 часов подряд (даже добровольно).
• ❌ Смена сразу после большого инцидента без отдыха.
• ❌ Шейминг за «упущенный» алерт — сначала разбираемся, почему алерт не дошёл, прежде чем винить дежурного.

Публичная страница статуса

Назначение

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

Содержимое

• Текущее состояние каждого основного компонента (партнёрский программный интерфейс, потребительская витрина, агентская поверхность, конструктор туров, поиск, платежи, уведомления).
• Текущие инциденты с описанием, затронутыми компонентами, временем начала, обновлениями.
• Запланированное обслуживание с временем и затронутыми компонентами.
• Историческая статистика доступности (за последние 90 дней).
• Подписка на уведомления — email, RSS, webhook для машинной интеграции.

Каноничные правила обновления

• Critical инциденты — публикация на странице в течение 5 минут с момента подтверждения.
• High инциденты — в течение 15 минут.
• Medium инциденты — обычно не публикуются (внутренний характер).
• Запланированное обслуживание — публикация за 7 дней до начала.
• Обновления статуса — каждые 30 минут во время активного инцидента, чаще при изменениях.

Запрет на скрытие инцидентов

• ❌ Замалчивание инцидентов с подтверждённым внешним влиянием.
• ❌ Задержка публикации сверх каноничных правил «чтобы не пугать».
• ❌ Удаление исторических инцидентов из истории статуса.

Каноничная отчётность по SLA

Месячный SLA-отчёт

Для тенантов Professional и выше — ежемесячный SLA-отчёт:

• Достигнутые значения каждого SLI.
• Сравнение с обещанным SLA.
• Список инцидентов за период с длительностью и причиной.
• Расчёт service credits, если применимо.
• Доступ через партнёрскую консоль и через программный интерфейс аналитики.

Квартальный operational review (Enterprise)

Для тенантов Enterprise — квартальный операционный обзор:

• Подробная разбивка инцидентов и SLA.
• Анализ совместных операционных вопросов.
• Обсуждение приоритетов на следующий квартал.
• Согласование индивидуальных метрик и обещаний.

Годовой compliance audit

Для регулятивно-критичных тенантов (с уровнем изоляции dedicated_infrastructure) — годовой compliance audit с участием third-party аудитора (по запросу).

Процедура урегулирования споров по SLA

Каноничный процесс

Тенант фиксирует подозрение на нарушение
       ↓
Запрос через support ticket с указанием периода и SLI
       ↓
Команда поддержки в течение 5 рабочих дней представляет:
   - Замеренные значения SLI
   - Список инцидентов за период
   - Обоснование (нарушение/не нарушение)
       ↓
   ├── Тенант согласен → процесс закрыт
   └── Тенант не согласен → escalation
       ↓
Escalation:
   - Совместный технический разбор
   - Анализ методологии измерения
   - Решение в течение 30 дней
       ↓
   ├── Согласие → service credit применён
   └── Несогласие → стандартная dispute resolution по контракту

Запрет на затяжку процесса

Каждый шаг имеет жёсткие сроки. Затяжка процесса со стороны платформы — сама по себе нарушение SLA на поддержку.

Метрики операционной зрелости дежурной модели

• MTTA (Mean Time To Acknowledge) — среднее время от алерта до подтверждения дежурным. Цель — менее 10 минут.
• MTTR по severity — см. выше.
• Доля смен без алертов — индикатор стабильности (высокая доля — хорошо).
• Доля алертов, разрешённых без эскалации — индикатор автономности дежурных.
• Доля смен с большим количеством алертов (более 5 за смену) — индикатор alert fatigue, требует разбирательства.
• Удовлетворённость дежурных (через регулярные опросы) — индикатор устойчивости команды.
• Доля смен с компенсирующим отдыхом — индикатор частоты крупных инцидентов.

События SLA и дежурной модели

Событие	Когда	Главные потребители
sla.measurement.recorded	Зафиксировано измерение SLI	Платформа данных, аналитика SLA
sla.target.approaching_breach	Приближение к нарушению (бюджет ошибок исчерпан более чем на 80%)	Команда платформы, управление релизами
sla.target.breached	Нарушение SLA	Тенант, контур аудита, finance
service_credit.calculated	Расчёт service credit	Тенант, finance
service_credit.applied	Применение к счёту	Тенант, расчётный контур
oncall.shift.started	Начало смены	Команда, контур наблюдаемости
oncall.alert.acknowledged	Подтверждение алерта дежурным	Контур наблюдаемости (отсчёт MTTA)
oncall.escalated	Эскалация на следующий уровень	Команда, escalation chain
oncall.handover.completed	Передача смены	Контур аудита
status_page.incident.published	Публикация инцидента	Все подписчики status page
status_page.incident.resolved	Закрытие на странице статуса	Все подписчики
sla.report.generated	Генерация ежемесячного отчёта	Тенанты Professional+

Полная таксономия — в Первоначальная таксономия событий.

Технологический выбор

Компонент	Технологии
Алертинг	PagerDuty / OpsGenie / Grafana OnCall
Status page	Statuspage.io (Atlassian) / собственный на базе платформы
Расчёт SLA	Собственный сервис на базе платформы данных
Партнёрская отчётность	Дашборды в партнёрской консоли + программный интерфейс аналитики
Учёт смен	Графики в системе алертинга + интеграция с HR-системой

Фазы развёртывания

Фаза Bootstrap (0–6 месяцев)

Что разворачивается:

• Каноничная модель (SLAClass, SLAObligation, SLAMeasurement, ServiceCredit, SLABreachIncident) зафиксирована в схеме хранения.
• Базовые SLI измеряются через Grafana.
• Best-effort SLA для первых пользователей (без формальных обещаний).
• Дежурство в рабочие часы для одной команды.

Триггер выхода:

• Запуск партнёрского доступа в production — нужны формальные SLA.

Фаза 2 — Production SLA и on-call (6–18 месяцев)

Что разворачивается:

• Формальные SLA по тарифам Starter / Professional / Enterprise.
• Автоматический расчёт service credits.
• Партнёрская отчётность ежемесячная.
• 24/7 покрытие critical и high инцидентов.
• Public status page.
• Каноничная процедура урегулирования споров.

Триггер выхода:

• Появление Enterprise партнёров с custom SLA.
• Глобальная команда — нужен follow-the-sun.

Фаза 3 — Mature SLA (18–30 месяцев)

Что разворачивается:

• Custom SLA для крупных Enterprise.
• Расширенные метрики (включая бизнес-уровневые).
• Quarterly operational reviews.
• ML-приложения для предсказания нарушений SLA.

Фаза 4 — Global SLA (30+ месяцев)

Что разворачивается:

• Multi-region SLA с региональными показателями.
• Follow-the-sun on-call ротация.
• Federated incident response для крупных корпоративных партнёров.

Архитектурные решения с тезисным обоснованием

Решение 1. Многоуровневая модель SLI / SLO / SLA с error budget

Цель: разделение измеримых показателей, внутренних целей и публичных обещаний.

Тезисы:

1. SLA напрямую от внутренних метрик — путь к выгоранию команды (любая мелочь — нарушение).
2. SLO как буфер выше SLA даёт время на восстановление.
3. Error budget — стандарт Google SRE индустрии. Это база.

Решение 2. Автоматический расчёт service credits

Цель: избежать ручных споров о компенсации, обеспечить честность.

Тезисы:

1. Ручной расчёт открывает дверь для торговли о размере, что разрушает доверие.
2. Автоматический расчёт по каноничной формуле — прозрачен.
3. Тенанты получают credits быстро без необходимости запрашивать.

Решение 3. Защита дежурных от выгорания как архитектурное правило

Цель: обеспечить устойчивость команды на длительной перспективе.

Тезисы:

1. Выгорание дежурных — реальная угроза устойчивости платформы. Один выгоревший инженер — это потеря годов опыта.
2. Каноничные правила (лимит смен, обязательный отдых) — единственный способ защиты.
3. Современные платформы (Google, AWS, Stripe) — все имеют формальные правила защиты дежурных. Это база.

Решение 4. Публичная страница статуса как обязательное обещание

Цель: обеспечить прозрачность платформы перед партнёрами.

Тезисы:

1. Без status page партнёры в неведении — растёт количество тикетов support.
2. Прозрачность повышает доверие даже при инцидентах.
3. Современные платформы (Stripe, Twilio, GitHub) — все имеют публичный status page. Это база.

Решение 5. SLA задаётся платформой, не наследуется от поставщиков

Цель: обеспечить тенанту определённый уровень обслуживания независимо от стабильности поставщиков.

Тезисы:

1. Партнёр платит платформе — платформа отвечает перед партнёром.
2. Если поставщик нестабилен — платформа должна смягчать через failover, fallback, circuit breaker.
3. Это применение правила 00000 в операционной плоскости.

Открытые развилки

Развилка 1. Конкретные значения SLA для каждого тарифа

Структура SLA зафиксирована, конкретные числа (95%/99%/99.9%) — концептуальные. Точная калибровка зависит от:

• Реальной измеренной стабильности после нескольких месяцев в production.
• Конкурентного бенчмарка.
• Готовности команды поддерживать обещания.

Эскалируется: при подготовке к запуску фазы 2.

Развилка 2. Outsourcing of L1 on-call

См. также Runbook'и инцидент-плейбуки, Развилка 3. Аутсорсинг L1 для покрытия 24/7 без раздувания внутренней команды.

Эскалируется: при росте инцидентного объёма.

Развилка 3. Custom SLA метрики для Enterprise

Какие именно дополнительные метрики могут быть в custom SLA Enterprise (например, специфические бизнес-KPI). Открытая развилка.

Эскалируется: при появлении первых Enterprise партнёров.

Развилка 4. ML-предсказание нарушений SLA

В фазе 3 — ML-модели для прогнозирования приближения к нарушению. Глубина (от простого алерта до автоматических смягчающих действий) — открытая развилка.

Эскалируется: при создании ML-стратегии для операций.

Развилка 5. Региональные SLA (фаза 4)

При multi-region инфраструктуре — должны ли SLA различаться по регионам? Возможны региональные специфичные метрики. Открытая развилка.

Эскалируется: при подготовке к фазе 4.

Связанная документация

Корневые архитектурные документы

• Манифест переосмысления — обязательство operations as product.
• Архитектурный якорь и бизнес-модель — SLA как продуктовый атрибут.
• Платформа как продукт — публичная страница статуса.
• Операционная ось — принципы on-call rotation.

Связанные операционные документы

• Runbook'и инцидент-плейбуки — каноничная процедура эскалации.
• Observability And Incident Response — измерение метрик SLI.
• Релизы и совместимость — связь error budget с релизной дисциплиной.
• Дорожная карта инфраструктурного масштабирования — фазы инфраструктуры.

Связанные доменные документы

• Программный интерфейс как продукт — концептуальные SLA по тарифам.
• Платёжный домен — SLA на платёжный контур.
• Статусная машина бронирования — unknown_external_state как ключевая метрика SLA.
• Партнёрские взаиморасчёты — применение service credits в счетах.
• Экономическая модель платформы — финансовые следствия service credits.
• Уведомления и коммуникации — каналы публикации инцидентов.
• Аналитика и бизнес-аналитика — дашборды SLA для партнёров.
• Сила тенантной изоляции — связь уровня изоляции с SLA.

Документы развития

• Первоначальная таксономия событий — события SLA.
• Техническое задание для подрядчика — § 7.1 SLA targets per tenant tier.

Архитектурные правила

• Закон 00000 — платформа главенствует над поставщиками — SLA задаётся платформой.
• Современные лучшие практики верхнеуровневых платформ — Google SRE, AWS, Stripe как ориентиры.
• Развитие без деградации — фазы как расширение, не миграция.
• Эластичное масштабирование и упаковка по фазам — фазы операционной зрелости.
• Тезисное обоснование архитектурных решений — формат принятия решений.