SLI — Индикаторы уровня сервиса

На этой странице описано, какие индикаторы уровня сервиса (SLI) мы используем для клиентских проектов, как именно их измеряем и где проходят границы этих измерений. Мы публикуем эту информацию, чтобы клиент мог понять не только целевые показатели, но и методику, ограничения и порядок интерпретации метрик.

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

Как читать страницу SLI, SLO, SLA Что мы измеряем Инструменты Error Budget Планы поддержки Инциденты

Как читать эту страницу

SLI — это измеряемые показатели, а не маркетинговые обещания.

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

Источники данных зависят от конфигурации проекта: внешние синтетические проверки, инфраструктурные метрики, APM и CI-аудиты.

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

Фактическая отчётность и доступ к дашбордам зависят от выбранного плана поддержки.

Зачем бизнесу SLI

Когда клиент передаёт проект на поддержку, ожидание обычно формулируется просто: сайт или приложение должны работать стабильно, быстро и предсказуемо. Но формулировка «работает нормально» слишком размыта для управления качеством. SLI переводят её в набор измеряемых показателей, которые можно проверять, сравнивать и обсуждать на основе данных.

Что происходит прямо сейчас?

Мониторинг в реальном времени фиксирует любое отклонение.

Насколько стабилен сервис за период?

Исторические данные показывают тренды и сезонность.

Когда нужно вмешаться?

Пороговые значения запускают оповещения до того, как проблему заметит пользователь.

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

SLI, SLO, SLA — как они связаны

Три уровня работы с качеством сервиса выстраиваются в цепочку: от измерения — к целям — к обязательствам.

SLI — Service Level Indicator

Что мы измеряем.

Числовые показатели, отражающие реальный пользовательский опыт: доступность, скорость отклика, процент ошибок, Core Web Vitals. SLI — это факт, зафиксированный инструментами мониторинга, а не субъективная оценка.

SLO — Service Level Objective

К чему мы стремимся.

Внутренние целевые планки для каждого SLI. Например: «время отклика API — не более 300 мс для 95 % запросов». SLO задаёт планку качества, которую мы контролируем ежедневно и пересматриваем ежеквартально.

SLA — Service Level Agreement

Что мы гарантируем.

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

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

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

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

Основные индикаторы

Индикатор	Что показывает	Как считаем	Ориентир (SLO)
Uptime (Доступность)	Доля времени, когда сервис доступен и отвечает корректно	Доля успешных HTTP-ответов (2xx/3xx) от общего числа синтетических проверок	≥ 99,5 % (стандарт), ≥ 99,8 % (цель)
Latency (Время отклика)	Скорость ответа сервера на запрос пользователя	Перцентили P50, P95, P99 по всем запросам за период	P95 < 300 мс (API), P95 < 2 с (страница)
Error Rate (Уровень ошибок)	Доля запросов, завершившихся серверной ошибкой	Процент ответов 5xx от общего числа запросов	< 0,1 %
First Response Time	Как быстро команда реагирует на поступивший тикет	Время от создания тикета до первого содержательного ответа	≤ 20 мин (S1, рабочие часы)

Core Web Vitals

Google использует Core Web Vitals как фактор ранжирования. Мы отслеживаем их отдельно, потому что они напрямую влияют на SEO и конверсию.

Метрика	Что измеряет	Порог «хорошо»	Наш инструмент
LCP (Largest Contentful Paint)	Скорость загрузки основного контента страницы	≤ 2,5 с	Lighthouse CI
INP (Interaction to Next Paint)	Отзывчивость страницы на действия пользователя	≤ 200 мс	Lighthouse CI
CLS (Cumulative Layout Shift)	Визуальная стабильность — отсутствие «прыжков» элементов	≤ 0,1	Lighthouse CI

Lighthouse CI запускается автоматически в пайплайне деплоя. Если Core Web Vitals деградируют после обновления — мы узнаём об этом до того, как это повлияет на позиции в поиске.

Дополнительные индикаторы

Индикатор	Что показывает	Ориентир (SLO)
TTMR (Time to Mitigation/Restore)	Время от начала инцидента до восстановления работоспособности	≤ 4 ч (S1), ≤ 8 ч (S2)
Deployment Success Rate	Доля деплоев, не приведших к деградации сервиса	≥ 99 %
Saturation (Насыщенность)	Загрузка серверных ресурсов: CPU, RAM, диск	CPU idle > 10 %, RAM < 85 %, диск > 10 % свободно
SSL/Domain Expiry	Контроль сроков действия сертификатов и доменов	Оповещение за ≥ 30 дней до истечения

Значения в таблицах выше приведены как базовые ориентиры. Для конкретного проекта они уточняются после онбординга, анализа архитектуры, профиля нагрузки и критичности бизнес-процессов.

Как мы измеряем: инструменты и методология

Достоверность метрик зависит не только от инструмента, но и от способа его применения: частоты проверок, настроек алертов, состава точек мониторинга, горизонта хранения данных и корректности интерпретации. Поэтому мы используем комбинацию внешнего синтетического мониторинга и анализа на уровне инфраструктуры и приложения.

Обзорный дашборд Grafana с ключевыми метриками проекта

UptimeRobot — внешний мониторинг доступности

Синтетические проверки с нескольких географических точек каждые 1–5 минут:

HTTP/HTTPS, Ping, порт-проверки, DNS и SSL-мониторинг
Мгновенные оповещения при недоступности через email, Slack, Telegram
Исторические данные uptime для отчётности
Публичные status-страницы для прозрачности перед пользователями

Grafana — мониторинг доступности и здоровья сервиса — Grafana — история доступности и health-статусов проекта

Grafana + Prometheus — визуализация и аналитика

Prometheus собирает метрики с серверов и приложений, Grafana визуализирует их на настраиваемых дашбордах:

Latency (P50, P95, P99), error rate, throughput — в реальном времени
Мониторинг серверных ресурсов: CPU, RAM, диск, сеть
Настраиваемые алерты при превышении пороговых значений
Исторические тренды для выявления деградации до того, как она станет инцидентом

Grafana — дашборд метрик latency и error rate — Дашборд latency и error rate

Grafana — агрегированные логи приложения — Агрегированные логи приложения

Laravel Nightwatch — мониторинг на уровне приложения

Глубокая инструментация Laravel-приложений от создателей фреймворка:

Трассировка каждого запроса от входа до ответа
Выявление медленных SQL-запросов и узких мест в очередях
Мониторинг исключений и ошибок в реальном времени
Контроль выполнения фоновых задач и cron-расписания

Примечание: На отдельных проектах в качестве альтернативы Nightwatch используется New Relic APM — полнофункциональная платформа мониторинга производительности. Выбор инструмента определяется архитектурой проекта и требованиями клиента.

Laravel Nightwatch — трассировка отдельного запроса — Трассировка запроса

Laravel Nightwatch — список запросов с временными метками — Список запросов

Laravel Nightwatch — детали исключения с трассировкой стека — Исключение с трассировкой стека

Lighthouse CI — контроль Core Web Vitals

Автоматический аудит производительности при каждом деплое:

Запуск в CI/CD-пайплайне Bitbucket Pipelines
Сравнение метрик с предыдущим релизом — регрессии видны сразу
LCP, INP, CLS, а также аудит доступности и SEO
Блокировка деплоя при критическом ухудшении показателей

Методология

Для веб-приложений мы применяем подход RED (Rate, Errors, Duration) — три ключевых сигнала, которые первыми реагируют на деградацию пользовательского опыта. Для инфраструктурных метрик используется дополняющий подход USE (Utilization, Saturation, Errors).

С точки зрения пользователя

Не внутренние метрики сервера, а реальный опыт: скорость загрузки страниц, успешность действий, время ожидания.

Перцентили, а не средние

P95 и P99 показывают худший опыт реальных пользователей, а не «среднюю температуру по больнице».

Непрерывно, 24/7

Метрики собираются круглосуточно, а не только в рабочие часы.

Ежеквартальный пересмотр порогов

После каждого значимого инцидента и при изменении профиля нагрузки.

Error Budget — бюджет допустимых ошибок

Ни один сервис не может работать без сбоев. Error Budget — это инженерный подход, который переводит эту реальность в управляемую величину: допустимый объём простоя или ошибок за период, при котором сервис остаётся в рамках SLO.

Целевой Uptime	Допустимый простой в месяц	Допустимый простой в год
99,5 %	~3 ч 39 мин	~43 ч 48 мин
99,8 %	~1 ч 27 мин	~17 ч 31 мин
99,9 %	~43 мин	~8 ч 46 мин
99,95 %	~22 мин	~4 ч 23 мин

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

Можно обновлять, деплоить новые функции, экспериментировать.

Бюджет на исходе

Фокус смещается на стабильность: только критичные исправления, усиленное тестирование.

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

Заморозка изменений до восстановления запаса. Приоритет — устранение корневых причин.

Почему это важно для вас: Error Budget помогает нам принимать решения не на основе эмоций («давайте ничего не трогать»), а на основе данных. Это означает, что ваш проект развивается максимально быстро при заданном уровне надёжности.

Уровни мониторинга по планам поддержки

Глубина мониторинга и набор отслеживаемых SLI зависят от выбранного плана поддержки.

Возможность	Basic	Extended	Enterprise
Синтетические проверки доступности (Uptime)	✓	✓	✓
Контроль SSL-сертификатов и доменов	✓	✓	✓
Оповещения при недоступности	✓	✓	✓
Lighthouse CI (Core Web Vitals)	✓	✓	✓
Мониторинг latency (P50, P95, P99)	—	✓	✓
Мониторинг error rate	—	✓	✓
Мониторинг ресурсов (CPU, RAM, диск)	—	Выборочно	✓
APM на уровне приложения (Nightwatch / New Relic)	—	Выборочно	✓
Настраиваемые дашборды Grafana	—	—	✓
Проактивные уведомления о деградации	—	✓	✓
Error Budget tracking	—	—	✓
Отчётность по SLI	По запросу	Ежемесячно	Еженедельно + QBR
Целевой Uptime (SLO)	99,5 %	99,5–99,8 %	до 99,9 %*

* Целевые значения Enterprise-плана определяются индивидуально после онбординга и оценки архитектуры.

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

Все инциденты классифицируются по влиянию на бизнес. Каждому уровню критичности соответствуют свои целевые показатели реакции.

Уровень	Описание	Первая реакция (SLO)	Восстановление (SLO)
S1 — Критический	Полная или частичная недоступность, заблокирован ключевой бизнес-процесс, инцидент безопасности	≤ 20 мин (рабочие часы)	≤ 4 часа
S2 — Высокое влияние	Существенная деградация с обходными путями, влияние на SEO или конверсию	≤ 1 час	≤ 8 часов
S3 — Среднее влияние	Дефекты с ограниченным влиянием на бизнес	≤ 4 часа	В рамках спринта
S4 — Низкое влияние	Косметические проблемы, UX-улучшения	≤ 1 рабочий день	По приоритету в бэклоге

Прозрачность и отчётность

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

Набор дашбордов Grafana для клиентских проектов — Набор дашбордов Grafana — пример того, что доступно на Enterprise-плане

Что входит в отчёт по SLI

Раздел	Содержание
Uptime за период	Фактический процент доступности в сравнении с целевым SLO
Latency-тренды	Динамика времени отклика (P50, P95) с выделением аномалий
Error rate	Процент ошибок с разбивкой по типам и источникам
Core Web Vitals	Динамика LCP, INP, CLS и влияние на SEO-позиции
Инциденты за период	Количество, критичность, время реакции и восстановления
Error Budget	Сколько бюджета израсходовано и сколько осталось
Рекомендации	Конкретные шаги по улучшению показателей

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

План	Отчёт по SLI	Формат
Basic	По запросу	Сводка в тикет-системе
Extended	Ежемесячно	PDF + комментарии
Enterprise	Еженедельно + ежеквартальный QBR	Дашборд + PDF + созвон

Наш подход к надёжности

SLI — это не просто цифры в отчёте. Это основа инженерной культуры, которая определяет наши ежедневные решения.

Restore-first

При инциденте приоритет — восстановление работоспособности, а не поиск первопричины. Расследование начинается после того, как сервис снова работает.

Без замалчивания

Если что-то идёт не так — клиент узнаёт об этом от нас, а не из собственного мониторинга. Проактивные уведомления — часть нашего стандарта работы.

Blameless postmortem

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

Автоматизация мониторинга

Всё, что можно автоматизировать — автоматизировано. Инженеры принимают решения, а не проверяют графики вручную.

Разделённая ответственность

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

Границы ответственности и исключения

Чёткое разграничение зон ответственности делает SLI полезными и интерпретируемыми. Без этого любые метрики и целевые значения легко становятся вводящими в заблуждение.

Наша зона ответственности

Код приложения, деплой и CI/CD-пайплайны

Настройка, поддержка и развитие системы мониторинга

Реакция на инциденты, RCA и корректирующие действия

Контроль Core Web Vitals и рекомендации по оптимизации

Управление error budget и отчётность по SLI

Зона ответственности заказчика

Инфраструктура хостинга и DNS, если они не переданы под наше управление

Сторонние сервисы и API: платёжные системы, CRM, почтовые провайдеры и другие внешние зависимости

Управление доступами, учётными записями и внутренними политиками безопасности

Контент, настройки и действия пользователей в административной панели

Своевременное предоставление данных и доступов, необходимых для диагностики

Что обычно не покрывается SLI

Форс-мажор

Крупные сбои провайдеров, аварии дата-центров, стихийные события.

Плановое обслуживание

Согласованные заранее maintenance windows.

Несогласованные изменения

Изменения со стороны заказчика или третьих лиц без участия нашей команды.

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

Внешние API, CDN, почтовые и платёжные сервисы.

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

Часто задаваемые вопросы

Чем SLI отличается от SLA?

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

Могу ли я видеть метрики своего проекта в реальном времени?

Да. Формат доступа зависит от плана поддержки и конфигурации проекта. Для части проектов доступны регулярные отчёты, для Enterprise-поддержки — отдельные дашборды и расширенная визуализация метрик.

Что происходит, когда SLO нарушен?

Мы фиксируем нарушение, уведомляем клиента, проводим разбор инцидента и определяем корректирующие действия. Если для проекта действует SLA с сервис-кредитами или иными обязательствами, дальнейшие действия определяются условиями этого соглашения.

Как определяются целевые значения SLO для моего проекта?

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

Гарантируете ли вы 100 % uptime?

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

Какие инструменты мониторинга вы используете?

Базовый стек зависит от проекта, но обычно включает UptimeRobot для внешних проверок доступности, Grafana и Prometheus для метрик и визуализации, Laravel Nightwatch или New Relic для APM, а также Lighthouse CI для контроля производительности и Core Web Vitals.

Что такое Error Budget и зачем он нужен?

Error Budget показывает, какой объём простоя или ошибок допустим в рамках выбранного SLO. Это помогает балансировать надёжность и скорость изменений: пока бюджет не исчерпан, продукт можно развивать активнее; при исчерпании приоритет смещается на стабилизацию.

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

Глоссарий

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

APM (Application Performance Monitoring) — мониторинг производительности приложения изнутри. Инструменты APM (Laravel Nightwatch, New Relic) трассируют каждый запрос, выявляют медленные SQL-запросы, исключения и узкие места в очередях.

Blameless postmortem — разбор инцидента без поиска виноватых. Цель — найти системные причины сбоя и устранить их, результат — конкретный план действий по предотвращению повтора.

CDN (Content Delivery Network) — сеть доставки контента; распределённая инфраструктура серверов, которая отдаёт статические файлы с ближайшей к пользователю географической точки.

CI/CD (Continuous Integration / Continuous Delivery) — непрерывная интеграция и доставка кода. Автоматизированный конвейер, который собирает, тестирует и деплоит изменения при каждом коммите.

CLS (Cumulative Layout Shift) — метрика визуальной стабильности из набора Core Web Vitals. Измеряет суммарное смещение элементов страницы в процессе загрузки. Хороший результат: ≤ 0,1.

Core Web Vitals — набор метрик пользовательского опыта от Google (LCP, INP, CLS), используемых как сигнал ранжирования в поиске и показатель реального качества работы страницы.

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

Deployment Success Rate — доля успешных деплоев, не приведших к деградации или сбою сервиса. Ориентир: ≥ 99 %.

DNS (Domain Name System) — система доменных имён; переводит доменное имя сайта в IP-адрес сервера. Сбои DNS делают сайт недоступным даже при исправном сервере.

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

Error Rate (уровень ошибок) — доля запросов, завершившихся серверной ошибкой (HTTP 5xx), от общего числа запросов за период. Ориентир: < 0,1 %.

First Response Time (время первой реакции) — период от создания тикета до первого содержательного ответа команды поддержки. Ориентир для S1: ≤ 20 минут в рабочие часы.

HTTP / HTTPS (HyperText Transfer Protocol / Secure) — протокол передачи данных в вебе. HTTPS — защищённая версия с шифрованием через SSL/TLS. Используется для синтетических проверок доступности.

INP (Interaction to Next Paint) — метрика отзывчивости из набора Core Web Vitals. Измеряет время от действия пользователя до следующей визуальной реакции страницы. Хороший результат: ≤ 200 мс.

Latency (задержка, время отклика) — время от отправки запроса клиентом до получения ответа от сервера. Измеряется через перцентили P50, P95, P99.

LCP (Largest Contentful Paint) — метрика скорости загрузки из набора Core Web Vitals. Фиксирует момент, когда основной видимый контент страницы отрисован. Хороший результат: ≤ 2,5 с.

P50 / P95 / P99 (перцентили) — статистические пороги распределения времени отклика. P95 означает: 95 % запросов выполнены быстрее этого значения. Перцентили точнее средних отражают реальный пользовательский опыт — в том числе «самых медленных» пользователей.

QBR (Quarterly Business Review) — ежеквартальный бизнес-обзор; встреча команды поддержки с клиентом для совместного анализа результатов SLI/SLO, инцидентов и планов на следующий квартал.

RAM (Random Access Memory) — оперативная память сервера. Высокое потребление RAM (> 85 %) может приводить к замедлению приложения или его аварийному перезапуску.

RCA (Root Cause Analysis) — анализ первопричин инцидента; систематическое расследование, направленное на выявление глубинной причины сбоя, а не только его симптомов.

RED (Rate, Errors, Duration) — методология мониторинга запросов: Rate (число запросов в секунду), Errors (доля ошибок), Duration (время выполнения). Первыми реагирует на деградацию пользовательского опыта.

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

Saturation (насыщенность) — степень загрузки ресурса (CPU, RAM, диск) относительно его максимальной ёмкости. Высокая насыщенность предсказывает будущие проблемы с производительностью ещё до появления явных ошибок.

SEO (Search Engine Optimization) — поисковая оптимизация; комплекс мер по улучшению позиций сайта в результатах поисковых систем. Core Web Vitals напрямую влияют на SEO-ранжирование.

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

SLI (Service Level Indicator) — индикатор уровня сервиса; измеримая метрика, отражающая реальное качество работы сервиса с точки зрения пользователя: uptime, latency, error rate, Core Web Vitals.

SLO (Service Level Objective) — целевой показатель уровня сервиса; внутренняя планка для каждого SLI (например, «P95 latency < 300 мс»), которую команда контролирует ежедневно и пересматривает ежеквартально.

SOW (Statement of Work) — техническое задание / описание работ; документ, фиксирующий конкретный объём, сроки и параметры поддержки, включая целевые значения SLO.

SQL (Structured Query Language) — язык структурированных запросов для работы с базами данных. Медленные SQL-запросы — частая причина деградации производительности приложений.

SSL (Secure Sockets Layer) — протокол шифрования для защищённых HTTPS-соединений. В контексте мониторинга: контроль срока действия SSL-сертификата (оповещение за ≥ 30 дней до истечения).

Throughput (пропускная способность) — количество запросов, которые сервис обрабатывает в единицу времени (например, запросов в секунду). Один из трёх сигналов методологии RED.

TTMR (Time to Mitigation / Restore) — время от момента обнаружения инцидента до полного восстановления работоспособности сервиса. Ориентир: ≤ 4 ч для S1, ≤ 8 ч для S2.

Uptime (доступность) — доля времени, в течение которого сервис работает и отвечает корректно. Рассчитывается как отношение успешных синтетических проверок к общему их числу за период. Ориентир: ≥ 99,5 %.

USE (Utilization, Saturation, Errors) — методология мониторинга инфраструктуры: Utilization (использование ресурса), Saturation (насыщенность), Errors (ошибки на уровне железа). Дополняет RED для диагностики серверных узких мест.

Правовая оговорка

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

Хотите узнать больше?

Соглашение об уровне сервиса (SLA)

Там описаны процессы, эскалация и формальные гарантии. Перейти к SLA →

Запросить пример отчёта по SLI

Мы подготовим демонстрацию на основе реального проекта, адаптированную под вашу архитектуру и технологии. Оставить заявку →