---
title: "SLI, SLO и SLA"
url: "https://kzsaleshub.com/framework/sli-slo-sla/"
type: "framework"
category: "IT и разработка"
language: "ru"
source: "KZSalesHub"
published: "2026-08-11"
last_updated: "2026-09-03"
---

# SLI, SLO и SLA

**Суть.** Показатель — то, что реально измеряется. Цель — внутренний ориентир по этому показателю. Соглашение — обязательство перед клиентом с последствиями за нарушение. Внутренняя цель всегда строже внешнего обязательства, иначе любое отклонение сразу становится нарушением договора.

## Разница

| Элемент | Пример | Кому адресован |
| --- | --- | --- |
| Показатель | Доля успешных запросов за 5 минут | Инженерам |
| Цель | 99,9% успешных запросов за месяц | Команде — ориентир |
| Соглашение | 99,5%, иначе компенсация | Клиенту — обязательство |

## Запас на ошибку

Если цель 99,9%, то 0,1% — это разрешённый бюджет сбоев. Пока он не израсходован, команда выпускает изменения; когда израсходован — переключается на надёжность. Это превращает спор «выпускать быстрее или стабильнее» из вопроса убеждения в вопрос цифры.

## Как выбрать показатель

Хороший показатель отражает опыт клиента, а не состояние сервера. «Сервер доступен» — плохой: сервер отвечает, а страница не грузится. «Доля запросов, обработанных успешно и быстрее порога» — рабочий.

## Три уровня, которые часто путают

| Уровень | Что это | Кому адресовано | Пример |
| --- | --- | --- | --- |
| Показатель | Что измеряем | Инженерам | Доля успешных ответов сервиса |
| Цель | Внутренняя планка | Команде | 99,9% за календарный месяц |
| Обязательство | Что записано в договоре | Клиенту и юристам | 99,5%, иначе компенсация |

Внутренняя планка всегда строже договорной. Разница между ними — это запас, за счёт которого команда успевает среагировать до того, как обязательство нарушено.

## Как выбрать показатели

1. Считайте с точки зрения пользователя, а не сервера. «Сервер работает» и «человек может отправить заявку» — разные события.
2. Три-четыре показателя на сервис. Больше никто не смотрит.
3. Задайте бюджет ошибок: если планка 99,9%, вы имеете право на определённое время сбоев. Это не позор, а ресурс.
4. Договоритесь заранее, что происходит при исчерпании бюджета: обычно новые функции останавливаются в пользу надёжности.

## Где ломается

**Обещают 99,99% без понимания цены.** Каждая девятка дорожает кратно; обязательство, которое нельзя выполнить, хуже отсутствия обязательства.

**Меряют то, что легко измерить.** Доступность по опросу сервера не совпадает с тем, что видит пользователь.

**Соглашение без последствий.** Пункт в договоре, за нарушение которого ничего не происходит, не дисциплинирует никого.

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

**Измеряют доступность, а не пользу.** Сервис отвечает, но отвечает за восемь секунд. Формально всё в норме, фактически клиент ушёл.

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

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

## Разница между тремя

| Что | Кто читает | Пример |
| --- | --- | --- |
| Показатель | Инженеры | Доля запросов, обработанных быстрее 300 мс |
| Цель | Команда и руководство | 99,5% запросов быстрее 300 мс за 30 дней |
| Обязательство | Клиент и юристы | При падении ниже 99% — возврат части абонентской платы |

## Почему цель должна быть ниже возможного

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

Обратная ошибка тоже встречается: цель ставят заведомо достижимой, и она перестаёт что-либо ограничивать. Разумный ориентир — цель, которая нарушается несколько раз в год. Если не нарушается никогда, она слишком мягкая и не помогает принимать решения.

Из этой разницы вырастает бюджет ошибок: пока запас не израсходован, команда выпускает изменения; когда израсходован — переключается на надёжность. Это превращает спор «релизить или чинить» в арифметику.

## Что выбрать в качестве показателя

- **То, что чувствует пользователь.** Загрузка процессора его не волнует; время ответа страницы — волнует.
- **Не больше трёх-четырёх на сервис.** Больше — и на них перестают смотреть.
- **Измеримое со стороны клиента, а не только изнутри.** Иначе споры о том, чьи данные верны, неизбежны.
- **Доступность и скорость как минимум.** Остальное по ситуации.

## Признак, что работает

Решение «выпускать новое или заниматься надёжностью» принимается по числу, а не по громкости спорящих. Если такого разговора ни разу не было, показатели считаются, но не используются.

## Частые вопросы

**Что важнее для крупного заказчика**

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

**Нужны ли компенсации**

Они редко покрывают ущерб клиента и почти всегда обсуждаются. Гораздо сильнее работает описанный порядок действий при сбое.

**С чего начать, если ничего нет**

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

## Связанное

- [Разбор инцидентов](https://kzsaleshub.com/framework/incident-postmortem/)
- [DORA-метрики](https://kzsaleshub.com/framework/dora-metrics/)

Договорной процент — это про юристов. Бюджет ошибок — про управление. Второе меняет поведение команды, первое нет.

---
Источник: https://kzsaleshub.com/framework/sli-slo-sla/