SLO: подход команды Webdelo к сопровождению проектов

Команда Webdelo при запуске сопровождения любого проекта формализует Service Level Objectives (SLO) — измеримые целевые показатели качества сервиса. Конкретные значения SLO определяются индивидуально после аудита проекта и фиксируются в техническом задании (SOW). Стандартный пакет сопровождения включает многослойный мониторинг, систему алертинга, модель реагирования на инциденты по уровням S1–S4 и регулярную отчётность. Мы не устанавливаем универсальные показатели «99.99% для всех» — вместо этого мы определяем реалистичные цели и берём на себя ответственность за их выполнение.

Определения терминов Scope SLI: что мы измеряем Компоненты пакета Severity-модель Error budget

Определения терминов

Термин	Определение
SLI (Service Level Indicator)	Конкретная измеримая метрика качества сервиса: доступность, latency(время обработки одного запроса ), частота ошибок
SLO (Service Level Objective)	Целевое значение или диапазон значений для SLI, которое команда обязуется поддерживать
SLA (Service Level Agreement)	Договорное соглашение между Webdelo и заказчиком, которое закрепляет SLO и последствия их нарушения
SOW (Statement of Work)	Техническое задание, в котором фиксируются конкретные значения SLO по результатам аудита проекта
Error budget	Допустимый объём деградации сервиса за расчётный период; исчерпание бюджета — сигнал к смещению приоритетов от разработки фич к стабилизации

Scope: что входит и что не входит в рамки SLO

В рамках SLO

Веб-приложения и API с определёнными уровнями критичности

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

Высоконагруженные аналитические платформы и системы обработки данных

Финансовые и трейдинг-системы, внутренние финтех/банкинг-инструменты

ERP-модули и системы автоматизации маркетинга

Инфраструктурный слой (серверы, контейнеры, базы данных, сетевые сервисы)

Вне рамок SLO

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

Плановые технические работы, согласованные с заказчиком заранее

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

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

От чего зависят параметры SLO

Команда Webdelo выработала подход, при котором целевые показатели определяются тремя факторами.

Сложность архитектуры

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

Тир сервисов

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

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

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

Когда формируется SLO

SLO устанавливается на одном из двух этапов.

При построении нового сервиса

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

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

Мы проводим аудит инфраструктуры, определяем тиры сервисов, оцениваем пробелы в мониторинге и поэтапно выстраиваем систему наблюдения. Конкретные целевые значения фиксируются в SOW по результатам аудита.

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

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

Категория SLI	Что измеряется	Примеры метрик
Доступность	Работоспособность сервисов в реальном времени	Healthcheck-статус, uptime по сервисам
Ошибки	Количество и динамика ошибок по сервисам	Частота HTTP 5xx, rate ошибок по типам и критичности
Latency	Время отклика на запросы	p50, p95, p99 latency по ключевым эндпоинтам
Ресурсы	Загрузка серверной инфраструктуры	CPU, RAM, disk I/O, трафик
Базы данных	Состояние и производительность БД	Latency запросов, slow query log, загрузка CPU/памяти
Сетевые endpoint'ы	Доступность внешних и внутренних зависимостей	Доступность сторонних API, внутренних микросервисов
Бизнес-метрики	Время выполнения бизнес-операций и их цепочек	Время перехода по статусам, SLA-метрики продуктовых процессов

Пример из практики

На одном из проектов Webdelo настроил мониторинг времени перехода заказов по статусам. Метрики показали, что часть заказов надолго застревает на определённых этапах. Расследование выявило комплексную проблему: сбои в процессе подтверждения со стороны службы поддержки + задержки внешних сервисов доставки = накопление «зависших» заказов = перегрузка базы данных = деградация всей системы. Каждый компонент по отдельности выглядел работающим — каскадный сбой был виден только через бизнес-метрики.

Стандартные компоненты SLO-пакета

Независимо от масштаба проекта, сопровождение Webdelo включает пять обязательных компонентов.

1. Система мониторинга

Основной стек: Grafana + Prometheus (или аналогичные инструменты, согласованные с заказчиком). Мониторинг охватывает все категории SLI из таблицы выше — доступность, ошибки, latency, ресурсы, БД, сетевые зависимости и бизнес-процессы.

2. Система алертинга

Алертинг строится на базе VictoriaMetrics (или аналога). Каждый алерт привязан к конкретному порогу метрики и уровню критичности. Оповещения направляются в мессенджер команды (Slack, Telegram или иной канал по договорённости). Дежурный получает только сигналы, требующие реакции — без шума низкоприоритетных событий.

3. Адресная книга и инструкции реагирования

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

4. Команда управления инцидентами

Команда включает три уровня:

Инцидент-менеджмент — специалисты со знанием архитектуры проекта, которые открывают инциденты, создают задачи в системе управления (Jira, ClickUp или другой), назначают ответственных.
Дежурные DevOps/SysOps — инженеры инфраструктуры для диагностики проблем на уровне серверов, контейнеров, сетей, оркестрации.
Дежурные разработчики — специалисты по конкретным сервисам, подключаемые при локализации проблемы на уровне кода или бизнес-логики.

5. Канал сбора обращений

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

Severity-модель инцидентов

Уровень	Критичность	Описание	Время начала реагирования	Целевое время устранения
S1	Критический	Полная недоступность ключевого сервиса или продукта; прямые финансовые потери	15 минут	4 часа
S2	Высокий	Частичная деградация ключевого сервиса; значительное ухудшение пользовательского опыта	30 минут	8 часов
S3	Средний	Деградация некритичного сервиса; работоспособность основного продукта сохраняется	4 часа	24 часа
S4	Низкий	Минорные проблемы, не влияющие на работоспособность; задачи улучшения мониторинга	Следующий рабочий день	По договорённости

Конкретные значения времён реагирования зависят от тира сервиса, режима дежурства и бюджета сопровождения. Итоговые параметры фиксируются в SOW.

Error budget policy

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

Когда error budget в норме

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

Когда error budget близок к исчерпанию

(остаток ниже порога предупреждения): приоритеты смещаются в сторону стабилизации. Новые фичи приостанавливаются до восстановления бюджета или пересмотра SLO с заказчиком.

Когда error budget исчерпан

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

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

Что входит в периодические отчёты

Раздел	Содержание
SLO-статус	Фактические значения SLI за период относительно целевых SLO
Error budget	Остаток budget'а по каждому сервису, динамика расхода
Инциденты	Перечень инцидентов по уровням S1–S4, MTTR, причины
Тренды	Изменения в производительности и надёжности по сравнению с предыдущим периодом
Рекомендации	Предложения по улучшению мониторинга, архитектуры или процессов

Работа с инцидентами после устранения

По каждому инциденту открывается задача с описанием причин, перечнем задействованных систем и предпринятых действий. К задаче привязываются тикеты на исправление выявленных проблем. Совокупность задач образует базу для postmortem-разбора и анализа эффективности работы команды в динамике.

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

Стандартная периодичность отчётов и service review — ежемесячно. По договорённости возможны еженедельные или квартальные форматы.

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

Честные capability boundaries — часть нашего подхода к доверию.

Универсальных SLO не существует

Мы не устанавливаем показатели «99.99% для всех» до аудита. Конкретные значения всегда определяются под конкретный проект.

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

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

SLO не заменяет SLA

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

Круглосуточное покрытие — не всегда по умолчанию

24/7 дежурство зависит от бюджета и тира сервиса; стандартный пакет может предусматривать только расширенные рабочие часы.

Нет гарантий нулевых инцидентов

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

Бизнес-метрики — только при соответствующем соглашении

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

Итог

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