Service Level Objectives — измеримые цели качества сервиса

Когда Webdelo берёт проект на сопровождение, первым шагом мы определяем SLO — целевые значения SLI, которые обязуемся поддерживать. Конкретные цифры всегда фиксируются в SOW после аудита: универсальных «99.99% на всё» мы не обещаем. Вместо этого мы согласуем реалистичные цели и берём на себя ответственность за их выполнение. Стандартный пакет включает многослойный мониторинг, alerting, S1–S4 модель реагирования, error budget и регулярную отчётность.

Цели — после аудита, в SOW

SLI: availability · latency · errors

Модель инцидентов S1–S4

Ежемесячный обзор сервиса

Grafana · Prometheus · VictoriaMetrics

Политика error budget

Коротко о главном

Ключевые факты

SLO — операционные цели, не контрактные обязательства. Конкретные значения всегда определяются после аудита и фиксируются в SOW. Универсальных uptime-чисел мы не публикуем — целевые значения всегда привязаны к проекту, его архитектуре, тиру сервиса и бюджету поддержки.

SLI-категорий в стандартном пакете

S1–S4

модель severity для инцидентов

15 мин

acknowledge для S1 (индикативно)

ежемесячно

стандартная cadence service review

Подход

Цели — после аудита

Без аудита SLO не назначаются. Реалистичные целевые значения — после анализа архитектуры, нагрузки и tier'ов.

Где фиксируется

SOW

Конкретные значения SLO, error budget'ы, response times и cadence отчётности — приложение к договору.

Стек

Grafana · Prometheus · VictoriaMetrics

Базовый стек. Альтернативы (Datadog, NewRelic и др.) — по согласованию с клиентом.

SLI vs SLO vs SLA

Три разные сущности

SLI — метрика. SLO — целевое значение для метрики. SLA — контракт. SLO живёт в SOW; SLA — отдельный документ.

Error budget

Управляет приоритетами

Когда бюджет исчерпан — feature work останавливается, команда переходит на reliability.

Что не обещаем

Ноль инцидентов · 24/7 по умолчанию

Минимизируем влияние инцидентов; круглосуточное покрытие — по тарифу и tier'у сервиса.

Общий язык

Терминология: SLI · SLO · SLA · SOW · Error budget

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

Термин

Определение

SLI Service Level Indicator

Конкретная измеримая метрика качества сервиса: availability, latency, error rate.

SLO Service Level Objective

Целевое значение или диапазон для SLI, который Webdelo обязуется поддерживать.

SLA Service Level Agreement

Контрактная договорённость между Webdelo и клиентом, формализующая SLO и последствия нарушений.

SOW Statement of Work

Технический документ, в котором фиксируются конкретные значения SLO после аудита проекта.

Error budget

Допустимый объём деградации сервиса в пределах периода измерения; исчерпание — сигнал переключиться с feature delivery на reliability.

Границы ответственности

Область действия: что покрывается, что — нет

SLO применимы к системам и слоям, которые мы наблюдаем и контролируем. Внешние сервисы, плановые окна обслуживания и форс-мажорные события — за пределами наших целей по умолчанию.

В области действия

Web-приложения и API с определёнными service tier'ами

Микросервисная архитектура и распределённые системы

Высоконагруженные аналитические платформы и data pipelines

Финансовые и торговые системы, internal fintech/banking-инструменты

Marketing automation и ERP-модули

Инфраструктурный слой: серверы, контейнеры, БД, network services

Вне области действия

Сторонние сервисы и API вне нашего или клиентского контроля (платёжные шлюзы, внешние провайдеры)

Плановые окна обслуживания, согласованные заранее

Деградации, вызванные изменениями со стороны клиента вне согласованного change-management процесса

Форс-мажорные события вне разумных технических средств контроля

Ключевые факторы

Что определяет параметры SLO

Целевые значения SLO формируются под три основных фактора. Их комбинация определяет, как глубоко покрыт мониторинг, насколько строгие пороги и кто и как реагирует.

01 Архитектура

Архитектурная сложность

Монолит на одной БД и распределённая система из 20 сервисов требуют принципиально разных подходов к мониторингу. Чем сложнее — тем больше точек наблюдения и шире on-call.

02 Tier

Tier сервиса

Не все компоненты несут одинаковый бизнес-вес. Мы делим сервисы на tier'ы по их влиянию на доступность основного продукта клиента. Платёжный шлюз и сервис генерации внутренних отчётов имеют разные требования к response. Tier определяет приоритет мониторинга, time-to-respond и состав on-call.

03 Бюджет

Бюджет поддержки

Бюджет определяет число специалистов, режим работы (рабочие часы / extended / 24×7) и глубину мониторинга бизнес-метрик.

Точки входа

Когда устанавливаются SLO

Есть две точки входа. Идеальный сценарий — мониторинг встроен в архитектуру с самого начала. На существующих проектах observability достраивается постепенно после аудита.

Сценарий A · Green-field

Новые сервисы

Мониторинг и метрики закладываются в архитектуру с самого начала. К моменту запуска полное observability-покрытие уже на месте — идеальный сценарий.

Сценарий B · Brown-field

Подключение существующего проекта

Webdelo проводит аудит инфраструктуры, определяет tier'ы сервисов, выявляет пробелы в мониторинге и достраивает observability итеративно. Конкретные SLO фиксируются в SOW по итогам аудита.

В обоих сценариях для ключевых метрик определяются error budget'ы — они становятся инструментом приоритизации между разработкой фич и работами по стабильности.

Метрики сервиса

SLI: что мы измеряем

Семь категорий измерений, которые покрывает стандартный пакет. Конкретные пороги — индивидуально, но категории и подход неизменны.

Категория SLI

Что измеряется

Примеры метрик

Доступность

Real-time состояние сервиса

healthcheck status, per-service uptime

Ошибки

Объём ошибок и тренды по сервисам

HTTP 5xx rate, error breakdown by type/severity

Задержка

Время отклика на запросы

p50, p95, p99 latency на ключевых endpoints

Ресурсы

Нагрузка на серверную инфраструктуру

CPU, RAM, disk I/O, network throughput

Базы данных

Здоровье и производительность БД

query latency, slow query log, CPU/memory load

Сетевые зависимости

Доступность внешних и внутренних зависимостей

third-party API reachability, internal microservice availability

Бизнес-метрики

Время выполнения бизнес-операций и workflows

order status transition times, product-level SLA metrics

Реальный кейс — мониторинг бизнес-метрик

На одном из проектов был настроен мониторинг времени переходов между статусами заказа. Метрики показали, что часть заказов «застревает» на конкретных стадиях обработки. Расследование вскрыло составной отказ: misfire в support confirmation flow + спайки latency у внешнего delivery API = накопление зависших заказов = перегрузка БД = деградация всей системы. Каждый компонент в изоляции выглядел здоровым; каскад был виден только через бизнес-метрики.

Состав поддержки

Стандартный SLO-пакет: пять компонентов

Каждое engagement по поддержке Webdelo включает пять обязательных компонентов. Конкретные инструменты и пороги — настраиваются.

Инфраструктура мониторинга. Базовый стек — Grafana + Prometheus (или согласованные эквиваленты). Покрытие охватывает все семь SLI-категорий: availability, errors, latency, resources, databases, network dependencies, business processes.

Система оповещений. Реализуется на VictoriaMetrics или эквиваленте. Каждый алерт привязан к конкретному порогу метрики и уровню severity. Доставка — в командный мессенджер (Slack, Telegram или согласованный канал). On-call инженеры получают только actionable-сигналы; low-priority шум фильтруется.

Runbooks и пути эскалации. Для каждого сервиса ведётся карта ответственности: кому идёт алерт, порядок эскалации и шаги первого реагирования до подключения профильного специалиста. Это устраняет задержку «кто за это отвечает?» в момент инцидента.

Команда управления инцидентами. Работает на трёх уровнях: управление инцидентами — специалисты с полным знанием архитектуры, открывают инциденты, заводят тикеты в Jira/ClickUp/системе клиента, назначают владельцев; on-call DevOps/SysOps — диагностика на уровне серверов, контейнеров, сети, оркестрации; on-call разработчики — профильные инженеры конкретного сервиса, подключаются, когда проблема локализована в коде или бизнес-логике.

Канал для сообщений о проблемах. Канал для сотрудников клиента, чтобы сообщать о замеченных аномалиях. Конечные пользователи часто видят проблемы раньше, чем срабатывают автоматические алерты. Все сообщения консолидируются, триажируются и попадают в стандартный incident-workflow.

Приоритеты инцидентов

Модель критичности инцидентов S1–S4

Четырёхуровневая модель критичности. Указанные времена — индикативные; финальные параметры зависят от tier'а сервиса, режима on-call и бюджета и фиксируются в SOW.

Sev

Уровень

Описание

Время подтверждения

Целевое время устранения

Critical

Полная недоступность ключевого сервиса или продукта; прямое финансовое влияние

15 минут

4 часа

High

Частичная деградация ключевого сервиса; значимое влияние на пользователей

30 минут

8 часов

Medium

Деградация некритичного сервиса; core-продукт работает

4 часа

24 часа

Low

Незначительные проблемы без операционного влияния; улучшения мониторинга

Следующий рабочий день

По договорённости

Конкретные значения зависят от tier'а сервиса, режима on-call и бюджета. Финальные параметры фиксируются в SOW.

Управление надёжностью

Политика Error Budget

Error budget — допустимый объём деградации сервиса в пределах периода измерения (обычно месяц или квартал). Состояние бюджета напрямую определяет, на что команда тратит время — на фичи или на стабильность.

Норма

Бюджет в норме

Остаток выше порога предупреждения. Команда работает в стандартном темпе: разработка фич и инфраструктурные изменения идут как обычно.

Близок к исчерпанию

Бюджет на грани

Остаток ниже порога предупреждения. Приоритеты сдвигаются на стабильность. Новые фичи паузятся, пока бюджет не восстановится — или пока SLO не будет пересмотрен с клиентом.

Исчерпан

Бюджет исчерпан

Работа над фичами останавливается полностью. Команда фокусируется только на восстановлении надёжности. Совместный с клиентом review — первопричина и обновлённый план.

Прозрачность работы

Отчётность и обзоры сервиса

Регулярная отчётность даёт клиенту прозрачность по SLI, состоянию error budget и тренду надёжности. Стандартная cadence — месяц; недельный или квартальный формат — по согласованию.

Состав периодического отчёта

Раздел

Содержание

Статус SLO

Фактические значения SLI за период в сравнении с целевыми значениями SLO

Error budget

Остаток бюджета по сервисам, тренд расходования

Инциденты

Список инцидентов по S1–S4, MTTR, первопричины

Тренды

Изменения performance и reliability vs предыдущий период

Рекомендации

Предложения по мониторингу, архитектуре или процессам

Процесс после инцидента

Каждый инцидент порождает задачу с описанием первопричины, затронутых систем и предпринятых шагов. К ней линкуются bug-fix и logic-correction тикеты. Получившийся кластер задач — основание для postmortem-ревью и долгосрочного анализа эффективности команды.

Периодичность

Стандарт

Ежемесячно

регулярный service review

Опционально

Еженедельно

для high-tier систем

Опционально

Ежеквартально

QBR-формат

Честные ограничения

Чего мы не обещаем

Чёткие границы возможностей — часть того, как Webdelo выстраивает доверие. Лучше прямо назвать, где наши гарантии заканчиваются, чем подписаться под цифрами, которых не сможем выдержать.

Универсальные SLO

Не публикуем «99.99% на всё»

Никаких единых цифр до аудита. Целевые значения всегда привязаны к проекту.

Сторонние сервисы

Внешние зависимости вне контроля

Мониторим внешние API и сервисы, но не можем гарантировать их доступность.

SLO ≠ SLA

SLO — операционная цель

Это не юридически обязывающее обязательство: последствия за нарушения определяет отдельный SLA.

Покрытие

24/7 — не по умолчанию

Круглосуточный on-call зависит от бюджета и tier'а. Стандартный пакет может ограничиваться расширенными рабочими часами.

Идеал

Ноль инцидентов — не гарантируется

Работаем над предотвращением и снижением влияния. Полное отсутствие инцидентов не обещаем.

Бизнес-метрики

Требуют отдельного scope

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

Итог

Подход команды Webdelo к SLO — это инженерная практика, а не маркетинговые обещания. Мы определяем, что именно измерять, настраиваем инструменты, формируем команду и согласовываем реалистичные целевые показатели. Конкретные значения SLO фиксируются в SOW после аудита. Это позволяет нам брать на себя ответственность за результат, а заказчику — понимать, что именно ему гарантируется.

Если вас интересует сопровождение вашего проекта — свяжитесь с нами для обсуждения.

терминология

Глоссарий

API (Application Programming Interface) — программный интерфейс, позволяющий приложениям взаимодействовать друг с другом. Например, подключение платёжной системы к сайту или обращение сервиса к внешнему провайдеру доставки происходит через API.

Capability boundaries — границы возможностей; честное описание того, что команда может и не может гарантировать в рамках соглашения об уровне сервиса.

CPU (Central Processing Unit) — центральный процессор; основной вычислительный компонент сервера. Высокая загрузка CPU — один из ключевых сигналов деградации производительности.

DevOps (Development + Operations) — практика и культура, объединяющая разработку и эксплуатацию. DevOps-инженер отвечает за CI/CD, инфраструктуру, контейнеризацию и автоматизацию развёртывания.

Disk I/O (Disk Input/Output) — операции чтения и записи на дисковый накопитель. Высокий disk I/O может быть причиной замедления базы данных или всего сервиса.

Endpoint — точка доступа к сервису или API; конкретный URL или сетевой адрес, по которому принимаются запросы. Мониторинг endpoint'ов позволяет отслеживать доступность каждого отдельного интерфейса.

ERP (Enterprise Resource Planning) — система планирования ресурсов предприятия; интегрированное ПО, объединяющее финансы, склад, производство, HR и другие бизнес-процессы в единой платформе.

Fintech (Financial Technology) — финансовые технологии; сектор, использующий программные решения для предоставления финансовых услуг: платежи, кредитование, торговля, страхование.

Grafana — платформа с открытым исходным кодом для визуализации метрик и построения дашбордов мониторинга. Используется в связке с Prometheus или VictoriaMetrics для отображения состояния систем в реальном времени.

Healthcheck — периодическая автоматическая проверка работоспособности сервиса. Возвращает статус «живой» или «недоступен» и является базовым инструментом обнаружения отказов.

HTTP 5xx — класс HTTP-кодов ответа (500–599), означающих ошибки на стороне сервера: внутренняя ошибка (500), недоступность шлюза (502), перегрузка (503) и другие. Рост частоты 5xx — прямой сигнал деградации сервиса.

Latency — задержка отклика; время между отправкой запроса клиентом и получением ответа от сервера. Измеряется в миллисекундах; высокая latency ухудшает пользовательский опыт даже при формально работающем сервисе.

MTTR (Mean Time To Resolve) — среднее время устранения инцидента с момента его обнаружения до полного восстановления работоспособности сервиса. Один из ключевых показателей эффективности команды сопровождения.

p50 / p95 / p99 (перцентили latency) — статистические показатели распределения времён отклика. p95 означает, что 95% запросов обрабатываются быстрее указанного значения; p99 — 99% запросов. Перцентили точнее среднего значения отражают реальный опыт пользователей.

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

Prometheus — система сбора и хранения метрик с поддержкой гибких запросов на языке PromQL и встроенным механизмом алертинга. Стандарт де-факто для мониторинга облачных и микросервисных приложений.

RAM (Random Access Memory) — оперативная память; быстрое временное хранилище данных для запущенных процессов и приложений. Исчерпание RAM приводит к деградации производительности или аварийной остановке сервиса.

S1 / S2 / S3 / S4 (Severity 1–4) — уровни критичности инцидента от критического (S1: полная недоступность, прямые финансовые потери) до низкого (S4: минорные дефекты, не влияющие на работоспособность). Определяют приоритет и скорость реагирования команды.

Scope — область применения; границы, в рамках которых действуют соглашения, обязательства или покрытие мониторинга. Чёткое определение scope позволяет избежать разногласий об ответственности.

Service review — регулярная встреча команды сопровождения и заказчика для анализа метрик за период, разбора инцидентов и обсуждения плана улучшений. Стандартная периодичность — ежемесячно.

Severity — уровень критичности инцидента; определяет, насколько серьёзно нарушена работоспособность сервиса и насколько быстро требуется реакция команды.

Slow query log — журнал медленных запросов к базе данных; автоматически фиксирует запросы, время выполнения которых превышает заданный порог. Ключевой инструмент диагностики проблем с производительностью БД.

SysOps (Systems Operations) — специалист по эксплуатации систем; отвечает за серверную инфраструктуру, сети, хранилища и оркестрацию контейнеров. Подключается к инциденту при локализации проблемы на инфраструктурном уровне.

Trading-система — программная платформа для автоматизированного совершения сделок на финансовых рынках. Относится к классу высококритичных систем с жёсткими требованиями к latency и доступности.

Uptime — время непрерывной работы сервиса или системы без сбоев. Обычно выражается в процентах за период: 99.9% uptime означает не более ~8.7 часов простоя в год.

VictoriaMetrics — высокопроизводительная база данных временных рядов; используется для долгосрочного хранения метрик и алертинга. Совместима с форматом Prometheus и обеспечивает меньший расход ресурсов при высоких нагрузках.