Service Level Indicators — что и как мы измеряем

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

Uptime ≥ 99.5% (целевое значение 99.8%)

P95 latency · API < 300 мс

Error rate < 0.1%

UptimeRobot · Grafana · Prometheus

Lighthouse CI в pipeline

RED + USE methodology

live · production monitoring ● UP

99.93% ▲ within SLO

uptime · последние 30 дней · целевое значение ≥ 99.8%

P95 latency 214 ms

Error rate 0.04%

Throughput 1.42k/s

SLI · основы

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

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

≥ 99.5%

базовый uptime SLO (целевое значение 99.8%)

< 300 мс

P95 latency на API endpoints

< 0.1%

error rate (HTTP 5xx)

≤ 20 мин

first response S1, в рабочие часы

Подход

RED + USE

RED для запросов (Rate, Errors, Duration), USE для ресурсов (Utilization, Saturation, Errors).

Стек

UptimeRobot · Grafana · Prometheus · Nightwatch · Lighthouse CI

Альтернатива — New Relic APM. Стек подбирается по архитектуре проекта.

Перцентили

P50 · P95 · P99

Среднее скрывает worst-case. Перцентили показывают реальный опыт самых медленных пользователей.

CWV

LCP ≤ 2.5 с · INP ≤ 200 мс · CLS ≤ 0.1

Lighthouse CI в pipeline блокирует деплой при критическом регрессе.

Мониторинг

24/7, не «в рабочие часы»

Метрики собираются круглосуточно. Реакция on‑call — по выбранному плану.

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

SOW · SLA

Конкретные SLO и обязательства — в контракте. Эта страница информационная.

Ориентация

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

Документ информационный. Цифры здесь — типовые ориентиры для проектов на сопровождении; они не заменяют условий вашего контракта, SOW или SLA.

SLI — это измеримые метрики, а не маркетинговые обещания. Каждая цифра подкреплена конкретным инструментом сбора.

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

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

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

Доступ к отчётам и дашбордам зависит от тарифного плана.

Ценность для бизнеса

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

«Всё работает» — слишком расплывчатая формулировка для управления качеством. SLI переводят это в измеримые числа, которые можно проверить, сравнить и обсудить на основе реальных данных.

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

Real-time мониторинг ловит отклонение в момент возникновения.

Насколько стабильно во времени?

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

Когда вмешиваться?

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

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

Иерархия качества

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

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

Trust & Legal

Соответствие требованиям GDPR

Соответствие требованиям защиты данных

Мы выстраиваем обработку персональных данных по принципам General Data Protection Regulation (GDPR Compliance): минимизируем объём данных, фиксируем цели и сроки хранения, учитываем права субъектов и требования к логам, аналитике и бэкапам.

Подробнее

Trust & Legal

ISO 27001 и SOC 2

на пути к сертификации

Мы выстраиваем информационную безопасность по принципам ISO 27001 и SOC 2: управляем доступами по принципу наименьших прав, документируем политики, внедряем Secure SDLC и DevSecOps и проводим внутренние аудиты.

Подробнее

Trust & Legal

NDA и конфиденциальность информации

Защита коммерческой информации

Для проектов Webdelo действует NDA-by-default: ограничиваем доступ к данным и репозиториям по ролям, используем защищённые каналы и менеджеры секретов. Материалы клиента не передаём во внешние сервисы и публичные ИИ-модели без отдельного согласия.

Подробнее

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

Метрики

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

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

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

Индикатор

Что показывает

Как измеряем

Ориентир (SLO)

Uptime / Availability

Процент времени, когда сервис доступен и отвечает корректно

Доля успешных HTTP-ответов (2xx/3xx) от общего числа синтетических проверок

≥ 99.5% (стандарт), ≥ 99.8% (целевое значение)

Latency / Response Time

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

Перцентили P50, P95, P99 по всем запросам за период

P95 < 300 мс (API), P95 < 2 с (page)

Error Rate

Процент запросов, завершившихся серверной ошибкой

Доля 5xx-ответов от всех запросов

< 0.1%

First Response Time

Скорость первой реакции команды на тикет

Время от создания тикета до первого содержательного ответа

≤ 20 мин (S1, рабочие часы)

Core Web Vitals

Google использует CWV как фактор ранжирования. Мы выделяем их в отдельную группу — они напрямую влияют на 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

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

Индикатор

Что показывает

Ориентир (SLO)

TTMR Time to Mitigation/Restore

Время от старта инцидента до восстановления сервиса

≤ 4 ч (S1), ≤ 8 ч (S2)

Deployment Success Rate

Процент деплоев без деградации сервиса

≥ 99%

Saturation

Утилизация ресурсов: CPU, RAM, disk

CPU idle > 10% · RAM < 85% · disk > 10% free

SSL/Domain Expiry

Мониторинг сроков сертификата и домена

Alert ≥ 30 дней до истечения

Стек и методология

Инструменты и методология

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

Grafana — overview dashboard grafana.webdelo.io

Uptime · 30d 99.93% target ≥ 99.8%

P95 latency 214 ms SLO < 300 ms

Error rate · 5xx 0.04% SLO < 0.1%

Throughput 1.42k req/s

Request rate / 6h

P95 latency / 6h (ms)

CPU idle 71%

RAM used 62%

Disk free 38%

Grafana — overview-дашборд с ключевыми метриками проекта.

External availability

UptimeRobot

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

HTTP/HTTPS, Ping, port checks, DNS, SSL monitoring

Мгновенные уведомления (email, Slack, Telegram) при простое

Историческая uptime-статистика для отчётов

Публичные status-страницы для прозрачности с конечными пользователями

Visualization & analytics

Grafana + Prometheus

Prometheus собирает метрики с серверов и приложений

Latency (P50, P95, P99), error rate, throughput — в реальном времени

Мониторинг CPU, RAM, disk, network

Настраиваемые алерты при превышении порогов

Исторические тренды — деградация ловится до инцидента

Grafana — health & uptime

api.example.com UP200 OK last check 23s ago

app.example.com UP200 OK last check 14s ago

cdn.example.com UP200 OK last check 18s ago

Uptime history · 30d

30d agouptime 99.91% · 2 incidentsnow

История доступности и здоровья сервисов проекта.

Grafana — latency & error rate

P50 / P95 / P99 — last 1h

P50 92 msP95 214 msP99 518 ms

Error rate · 5xx

peak 0.42% · current 0.04%

Дашборд latency и error rate.

Grafana — aggregated logs

10:42:18INFOUser login successful · uid=8341

10:42:21INFOPOST /api/orders · 201 · 87 ms

10:42:33WARNSlow query · orders.find · 412 ms

10:42:47INFOCache hit ratio · 94.2%

10:42:51ERRExternal API timeout · delivery.svc · 5000 ms

10:42:58INFOGET /api/profile · 200 · 41 ms

10:43:02WARNQueue lag · default · 124 jobs

10:43:11INFODeployment v2.18.4 · success

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

Application-level APM

Laravel Nightwatch

Трейсинг каждого запроса от входа до ответа

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

Real-time мониторинг исключений и ошибок

Контроль background jobs и cron-расписания

Альтернатива: New Relic APM — выбор зависит от архитектуры проекта

Nightwatch — request trace

GET/api/orders/8341 214 ms · 200 OK

Controller@showApp\Http\Controllers 214 ms

Middleware: auth2 ms 2 ms

DB: orders.findSELECT 38 ms

DB: order_items.whereSELECT 26 ms

External: delivery.svcPOST 90 ms

Cache: redis.get2 hits 7 ms

View: orders.showrender 39 ms

Полный трейс запроса с разбивкой по слоям.

Nightwatch — request list

TIMEMETHODURLDURATIONSTATUS

10:42:18 GET /api/orders/8341 214 ms 200

10:42:14 POST /api/checkout 892 ms 201

10:42:09 GET /api/profile 41 ms 200

10:42:01 GET /api/products?cat=12 318 ms 200

10:41:55 DELETE /api/cart/items/22 68 ms 204

10:41:48 POST /webhooks/payment 156 ms 200

10:41:42 GET /api/orders 1240 ms 500

Список запросов с временами выполнения и статусами.

Nightwatch — exception

Illuminate\Database\QueryException SQLSTATE[HY000]: General error: 2006 MySQL server has gone away at vendor/laravel/framework/src/Illuminate/Database/Connection.php:759
at App\Http\Controllers\OrderController->show:34
at App\Http\Middleware\Authenticate->handle:18
GET /api/orders/8341 · trace_id=a3f8b91c

first seen 2h agooccurrences 14affected users 9

Детали исключения со стек-трейсом.

Core Web Vitals

Lighthouse CI

Автоматические performance-аудиты при каждом деплое

Запускается в Bitbucket Pipelines CI/CD

Сравнение метрик с предыдущим релизом — регрессы ловятся сразу

LCP, INP, CLS + accessibility и SEO аудиты

Блокирует деплой при критическом падении performance

98 Performance scoreCI passing

LCP2.1 с✓ good

INP180 мс✓ good

CLS0.05✓ good

Bitbucket Pipelines · последний прогон 8 мин назад · порог блокировки деплоя ≥ 90

Методология

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

Перспектива

Со стороны пользователя

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

Статистика

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

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

Покрытие

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

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

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

Управление риском

Error Budget — допустимые ошибки в числах

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

99.5%

простой / месяц ~3 ч 39 мин

в год ~43 ч 48 мин

~43 ч 48 мин в год

99.8%

простой / месяц ~1 ч 27 мин

в год ~17 ч 31 мин

~17 ч 31 мин в год

99.9%

простой / месяц ~43 мин

в год ~8 ч 46 мин

~8 ч 46 мин в год

99.95%

простой / месяц ~22 мин

в год ~4 ч 23 мин

~4 ч 23 мин в год

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

Можно двигаться вперёд

Деплои, новые фичи, эксперименты — в стандартном темпе.

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

Фокус на стабильности

Только критичные правки, более жёсткое тестирование.

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

Заморозка изменений

До восстановления буфера — приоритет на устранение первопричины.

Тарифы

Уровни мониторинга по тарифным планам

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

Возможность

Basic

Extended

Enterprise рекомендуем

Синтетические проверки (Uptime)

Мониторинг SSL и домена

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

Lighthouse CI (Core Web Vitals)

Мониторинг задержки (P50, P95, P99)

—

Мониторинг доли ошибок

—

Мониторинг ресурсов (CPU, RAM, диск)

—

выборочно

APM приложения (Nightwatch / New Relic)

—

выборочно

Индивидуальные дашборды Grafana

—

Проактивные оповещения о деградации

—

Отслеживание Error Budget

—

Отчётность по SLI

по запросу

ежемесячно

еженедельно + QBR

Целевой uptime (SLO)

99.5%

99.5–99.8%

до 99.9%^*

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

Инциденты

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

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

Sev

Уровень

Описание

First Response (SLO)

Resolution (SLO)

Critical

Полный или частичный outage, заблокирован core-процесс, security-инцидент

≤ 20 мин (раб. часы)

≤ 4 часа

High Impact

Значимая деградация при наличии обходного решения, влияние на SEO/конверсию

≤ 1 час

≤ 8 часов

Medium Impact

Дефекты с ограниченным бизнес-влиянием

≤ 4 часа

В рамках спринта

Low Impact

Косметика, UX-улучшения

≤ 1 рабочий день

Приоритизация в backlog

S1 · Critical — реакция в минутах

S2 · High — реакция в часах

S3 · Medium — в рамках спринта

S4 · Low — в backlog

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

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

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

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

Раздел

Содержание

Uptime за период

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

Latency trends

Динамика времени отклика (P50, P95) с подсветкой аномалий

Error rate

Процент ошибок с разбивкой по типам и источникам

Core Web Vitals

Тренды LCP, INP, CLS и их влияние на SEO

Incidents за период

Количество, severity, response time, time to resolution

Error Budget

Сколько использовано, сколько осталось

Recommendations

Конкретные шаги по улучшению

Частота отчётов

План

Частота

Формат

Basic

По запросу

Сводка в тикет-системе

Extended

Monthly

PDF + комментарий

Enterprise

Weekly + quarterly QBR

Dashboard + PDF + call

Культура надёжности

Подход к надёжности

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

Сначала восстановление

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

Без сюрпризов

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

Разбор без обвинений

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

Автоматизированный мониторинг

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

Чёткая зона ответственности

Мы отвечаем за код, деплой и мониторинг. Хостинг, доступы и контракты со сторонними сервисами — на стороне клиента.

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

Пороги и SLO пересматриваются ежеквартально и после значимых инцидентов.

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

Зона ответственности и исключения

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

Наша ответственность

Код приложения, деплои, CI/CD pipelines

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

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

Мониторинг и оптимизация Core Web Vitals

Управление Error Budget и SLI-отчётность

Ответственность клиента

Хостинг и DNS (если не передан в наше управление)

Сторонние сервисы и API: платежи, CRM, email, внешние зависимости

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

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

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

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

Форс-мажор

Outage провайдеров, отказ ЦОД, стихийные события.

Плановые окна

Согласованные заранее окна плановых работ.

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

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

Внешние зависимости

Сторонние API, CDN, email, payment-сервисы вне нашего контроля.

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

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

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

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

Оставить заявку

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

Чем 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 для диагностики серверных узких мест.