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

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

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

SLI: availability · latency · errors

S1–S4 incident model

Monthly service review

Grafana · Prometheus · VictoriaMetrics

Error budget policy

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

Ключевые факты (answer-first)

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

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

S1–S4

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

15 мин

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

monthly

стандартная 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.

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

Zero incidents · 24/7 by default

Минимизируем влияние инцидентов; круглосуточное покрытие — по тарифу и 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

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

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

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

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

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

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

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

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

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

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

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

02 Tier

Tier сервиса

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

03 Бюджет

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

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

Точки входа

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

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

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

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

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

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

Onboarding на существующий проект

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

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

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

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

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

Категория SLI

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

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

Availability

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

healthcheck status, per-service uptime

Errors

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

HTTP 5xx rate, error breakdown by type/severity

Latency

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

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

Resources

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

CPU, RAM, disk I/O, network throughput

Databases

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

query latency, slow query log, CPU/memory load

Network endpoints

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

third-party API reachability, internal microservice availability

Business metrics

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

order status transition times, product-level SLA metrics

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

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

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

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

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

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

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

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

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

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

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

Incident Severity Model — S1–S4

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

Sev

Уровень

Описание

Time to acknowledge

Target resolution

Critical

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

15 минут

4 часа

High

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

30 минут

8 часов

Medium

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

4 часа

24 часа

Low

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

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

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

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

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

Error Budget Policy

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

Healthy

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

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

Approaching exhaustion

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

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

Exhausted

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

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

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

Отчётность и service reviews

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

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

Раздел

Содержание

SLO status

Фактические значения SLI за период vs SLO-таргеты

Error budget

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

Incidents

Список инцидентов по S1–S4, MTTR, root causes

Trends

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

Recommendations

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

Post-incident process

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

Cadence

Стандарт

Monthly

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

Опционально

Weekly

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

Опционально

Quarterly

QBR-формат

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

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

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

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

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

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

Third-party

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

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

SLO ≠ SLA

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

Юридические последствия за нарушения определяет отдельный SLA.

Покрытие

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

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

Идеал

Zero incidents — не гарантируется

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

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

Требуют отдельного 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 и обеспечивает меньший расход ресурсов при высоких нагрузках.