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 дней до истечения |
Значения в таблицах выше приведены как базовые ориентиры. Для конкретного проекта они уточняются после онбординга, анализа архитектуры, профиля нагрузки и критичности бизнес-процессов.
Как мы измеряем: инструменты и методология
Достоверность метрик зависит не только от инструмента, но и от способа его применения: частоты проверок, настроек алертов, состава точек мониторинга, горизонта хранения данных и корректности интерпретации. Поэтому мы используем комбинацию внешнего синтетического мониторинга и анализа на уровне инфраструктуры и приложения.
UptimeRobot — внешний мониторинг доступности
Синтетические проверки с нескольких географических точек каждые 1–5 минут:
- HTTP/HTTPS, Ping, порт-проверки, DNS и SSL-мониторинг
- Мгновенные оповещения при недоступности через email, Slack, Telegram
- Исторические данные uptime для отчётности
- Публичные status-страницы для прозрачности перед пользователями
Grafana + Prometheus — визуализация и аналитика
Prometheus собирает метрики с серверов и приложений, Grafana визуализирует их на настраиваемых дашбордах:
- Latency (P50, P95, P99), error rate, throughput — в реальном времени
- Мониторинг серверных ресурсов: CPU, RAM, диск, сеть
- Настраиваемые алерты при превышении пороговых значений
- Исторические тренды для выявления деградации до того, как она станет инцидентом
Laravel Nightwatch — мониторинг на уровне приложения
Глубокая инструментация Laravel-приложений от создателей фреймворка:
- Трассировка каждого запроса от входа до ответа
- Выявление медленных SQL-запросов и узких мест в очередях
- Мониторинг исключений и ошибок в реальном времени
- Контроль выполнения фоновых задач и cron-расписания
Примечание: На отдельных проектах в качестве альтернативы Nightwatch используется New Relic APM — полнофункциональная платформа мониторинга производительности. Выбор инструмента определяется архитектурой проекта и требованиями клиента.
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 имеют ценность только тогда, когда они доступны и понятны клиенту. Мы не прячем метрики — мы делаем их основой совместных решений.
Что входит в отчёт по 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).
Хотите узнать больше?
Запросить пример отчёта по SLI
Мы подготовим демонстрацию на основе реального проекта, адаптированную под вашу архитектуру и технологии. Оставить заявку →
Соглашение об уровне сервиса (SLA)
Там описаны процессы, эскалация и формальные гарантии. Перейти к SLA →
