Три похожие буквы про надёжность. SLA (service level agreement) — обещание клиенту, часто с деньгами: «доступность не ниже 99.9%, иначе штраф». SLO (service level objective) — внутренняя цель команды, к которой стремятся, обычно чуть строже SLA. SLI (service level indicator) — сам показатель, который реально меряют: доступность, доля ошибок, задержка. Связь простая: SLI меряем → по SLO целимся → SLA обещаем наружу. Число решает всё: 99.9% доступности — это около 43 минут простоя в месяц, а 99.99% — уже меньше пяти. Разница между обещанием и реальностью — это error budget: сколько простоя ещё можно «потратить». Когда система падает, начинается инцидент со своей серьёзностью (severity), а после — постмортем без поиска виноватых (blameless): учимся, а не наказываем. Для аналитика главное: переводить расплывчатое «надёжно» в конкретный SLO с числом и понимать, что за каждой девяткой стоят деньги.
Однажды в договоре с клиентом стояла строчка «сервис работает стабильно». Сервис упал на сорок минут — клиент потребовал штраф, мы развели руками: «стабильно — это сколько?». Доказать было нечего ни одной стороне: слова без числа не доказуемы. С тех пор я знаю: «надёжно» и «стабильно» — это не требования, это ощущения, пока к ним не приставлено число и способ его померить. Вся история про SLA, SLO и SLI — это про то, как превратить ощущение надёжности в число, за которое можно отвечать. Аналитику это нужно не чтобы настраивать мониторинг, а чтобы на этапе спеки спросить ровно одно: «сколько именно девяток нам нужно и за чей счёт».
Три буквы: SLI, SLO, SLA
Их путают, потому что они похожи и идут вместе. Но это три разных слоя одной идеи, и проще всего их понять снизу вверх.
- SLI (indicator) — показатель. Это то, что реально меряют: доступность в процентах, доля ошибок, время ответа. Голое число, снятое с системы. «Доступность за май — 99.93%».
- SLO (objective) — цель. Это значение SLI, к которому стремимся внутри: «доступность не ниже 99.9%». Внутренняя планка команды, обычно чуть строже того, что обещано наружу, — чтобы был запас.
- SLA (agreement) — обещание. Это SLO, вынесенное в договор с клиентом, часто с деньгами: «если доступность ниже 99.5% — компенсация N% от платежа».
| Буква | Что это | Для кого | Пример |
|---|---|---|---|
| SLI | показатель, который меряем | факт, число | «доступность 99.93%» |
| SLO | внутренняя цель | команда | «целимся в 99.9%» |
| SLA | обещание с последствиями | клиент, договор | «ниже 99.5% — штраф» |
Связь читается одной фразой: SLI меряем, по SLO целимся, SLA обещаем. Зачем SLO строже SLA: чтобы внутренняя тревога сработала раньше, чем нарушится обещание клиенту. Если обещали 99.5%, а целитесь в 99.9% — у вас есть зазор, чтобы заметить деградацию и починить до того, как прилетит штраф.
SLI — это и есть метрика
SLI — не какая-то особая сущность, это обычная метрика из записи про логи, метрики и трейсы, выбранная как мерило надёжности. Доступность, доля ошибок, p95 задержки — всё это метрики, которые снимает мониторинг. SLO — это просто порог на такой метрике, а алерт на этот порог предупреждает, что бюджет надёжности тает. Поэтому SLA без работающей метрики, которая его считает, — это число в воздухе: нечем доказать ни нарушение, ни соблюдение.
Что значит 99.9% в минутах
«Три девятки», «четыре девятки» звучат абстрактно, пока не перевести их в простой. А простой — это минуты, когда сервис недоступен, и за ними стоят деньги. Вот сколько недоступности в месяц прячется за каждой девяткой:
| Доступность | Сколько девяток | Простой в месяц | Простой в год |
|---|---|---|---|
| 99% | две девятки | ≈ 7 часов 18 минут | ≈ 3,65 дня |
| 99.9% | три девятки | ≈ 43 минуты | ≈ 8,76 часа |
| 99.99% | четыре девятки | ≈ 4,4 минуты | ≈ 52 минуты |
| 99.999% | пять девяток | ≈ 26 секунд | ≈ 5,26 минуты |
Главное, что видно из таблицы: каждая лишняя девятка — это в десять раз меньше допустимого простоя и кратно дороже инженерно. Прыжок с 99% до 99.9% — это с семи часов до сорока минут в месяц. С 99.9% до 99.99% — с сорока минут до четырёх. Поэтому «давайте сделаем пять девяток» — почти всегда не то, что нужно: 26 секунд простоя в месяц требуют дублирования всего и стоят как небольшой самолёт. Правильный вопрос не «как надёжнее», а «сколько девяток реально нужно бизнесу и сколько мы готовы за них заплатить».
Error budget на пальцах
Из цели вытекает красивая штука — error budget, «бюджет ошибок». Если SLO — это 99.9% доступности, то оставшиеся 0.1% — это разрешённый простой: те самые ≈43 минуты в месяц, которые можно «потратить» без нарушения цели. Это не «плохо», это заложенный лимит, как лимит по карте.
Идея бюджета меняет разговор о надёжности с морального на инженерный. Пока бюджет не исчерпан — можно рисковать: выкатывать новые фичи, экспериментировать, ведь немного простоя заложено. Бюджет на исходе — команда тормозит новые выкатки и занимается стабилизацией, пока не накопит запас снова. Вместо вечного спора «разработка хочет фичи, эксплуатация хочет стабильности» появляется общая цифра, которая сама говорит, чья сейчас очередь.
Зачем аналитику думать про бюджет
Error budget — это явный размен «скорость против стабильности», выраженный числом. Когда заказчик одновременно требует «выкатывайте быстрее» и «чтобы никогда не падало», бюджет ошибок позволяет показать ему, что это две ручки одного механизма: хочешь больше первого — соглашайся на меньшую вторую цифру, и наоборот. Это честный разговор о цене, а не обещание чуда.
Инцидент и его серьёзность
Рано или поздно бюджет начинает тратиться по-настоящему — что-то ломается. Инцидент — это незапланированное событие, которое нарушает или грозит нарушить работу сервиса: оплата отвалилась, сайт лёг, ответы поползли по десять секунд. Инциденты не равны по тяжести, поэтому им присваивают серьёзность (severity) — обычно от SEV1 (всё горит, сервис недоступен всем, поднимают людей среди ночи) до SEV3/SEV4 (мелочь, потерпит до утра).
Зачем формальная шкала: чтобы реакция была пропорциональна беде. SEV1 будит дежурного и собирает команду немедленно; SEV3 спокойно ждёт рабочего времени. Без шкалы либо на каждый чих поднимают всех (и быстро выгорают), либо на серьёзную аварию реагируют вяло. Severity — это заранее согласованное «насколько срочно бежать».
Постмортем без поиска виноватых
Инцидент потушили — и тут начинается самое ценное: постмортем (postmortem), разбор того, что произошло. Хорошая практика — blameless postmortem, разбор без обвинений: цель не найти, кого наказать, а понять, как система и процессы позволили этому случиться, и сделать так, чтобы не повторилось.
Почему именно без обвинений — это не доброта, а инженерный расчёт. Если за инциденты наказывают, люди начинают их скрывать, замалчивать детали и защищаться вместо того, чтобы честно рассказать, что пошло не так. И тогда команда не учится — она просто прячет ошибки, пока не рванёт сильнее. Blameless-подход исходит из того, что человек почти никогда не «накосячил по глупости»: если один человек смог уронить прод одной командой, виновата система, которая это позволила, — и чинить надо систему. Виноват не «Петя нажал не туда», а «у нас выкатка на прод не требовала подтверждения».
Связь с НФТ и деньгами
SLA и SLO — это не отдельная вселенная, это нефункциональные требования с числом. Помните правило «НФТ без числа — не требование»? SLO — это и есть то самое НФТ, доведённое до конкретики: не «надёжно», а «доступность 99.9%, измеряется как доля успешных ответов за месяц». Если в спеке стоит «система должна быть надёжной» без цифры — это пустая строчка, ровно как «стабильно» из истории в начале.
И всё это упирается в деньги. Простой стоит напрямую: пока оплата лежит, клиенты не платят — это упущенная выручка. Плюс штрафы по SLA. Плюс репутация. С другой стороны денег и каждая лишняя девятка: дублирование серверов, резервные каналы, дежурные сутками — всё это тоже деньги. Поэтому выбор уровня надёжности — это всегда баланс двух сумм: сколько стоит простой против того, сколько стоит его предотвратить. Аналитик помогает положить обе суммы на стол.
«Надёжно» без числа и без «за чей счёт» — пустая строка
Две классические дыры в требованиях к надёжности. Первая — нет числа: «работает стабильно» ничего не значит и недоказуемо ни одной стороной. Вторая — есть число, но не сказано, что считается простоем и как меряем: 99.9% «по какой метрике, за какой период, что именно считаем недоступностью — полное падение или рост ошибок?». К каждому SLA/SLO приучитесь дописывать три вещи: число, способ измерения и последствия нарушения. Без последнего обещание ничем не подкреплено.
Что меняется для аналитика
Аналитик не настраивает мониторинг и не дежурит по ночам. Но именно аналитик ловит момент, когда заказчик говорит «надёжно», и не даёт этому слову проскочить в спеку безнаказанным. Конкретно: перевести «надёжно» в SLO с числом (сколько девяток и почему столько), привязать к нему метрику (как именно меряем доступность и за какой период), проговорить последствия (что в SLA, какой штраф) и назвать цену (во сколько обходится каждая лишняя девятка и стоит ли она того). Это и есть ваша работа: не обеспечить надёжность руками, а сделать договорённость о ней конкретной, измеримой и оплаченной осознанно.
Откуда это взялось
Сами SLA старше IT: они пришли из телекома и энергетики, где поставщики связи и электричества десятилетиями обещали клиентам уровень обслуживания с компенсациями за простой. А вот стройную инженерную дисциплину вокруг надёжности оформил Google под названием SRE (Site Reliability Engineering) — подход, где за надёжность отвечают инженеры по чётким числам. В 2016 году Google выпустил книгу «Site Reliability Engineering», которая разнесла по индустрии и связку SLI/SLO/SLA, и идею error budget (тратить допустимый простой как бюджет), и практику blameless postmortem — разбора без поиска виноватых. До этого надёжность чаще была вопросом героизма и интуиции; Google сделал её предметом расчёта.
Частые вопросы
Чем SLA отличается от SLO и SLI?
Это три слоя одной идеи. SLI (indicator) — сам показатель, который меряют: доступность, доля ошибок, задержка; голое число. SLO (objective) — внутренняя цель команды по этому показателю, например «доступность не ниже 99.9%». SLA (agreement) — обещание клиенту в договоре, часто с деньгами и штрафами за нарушение, обычно чуть мягче внутреннего SLO, чтобы был запас. Связь: SLI меряем, по SLO целимся, SLA обещаем наружу.
Сколько простоя в месяце при 99.9%?
Около 43 минут. Каждая девятка кратно меняет картину: 99% — это примерно 7 часов 18 минут простоя в месяц, 99.9% — около 43 минут, 99.99% — уже меньше пяти минут, 99.999% — около 26 секунд. Важно понимать, что каждая следующая девятка стоит кратно дороже инженерно (нужно дублирование, резервирование, круглосуточные дежурные), поэтому «давайте пять девяток» почти никогда не оправдано. Правильный вопрос — не «как надёжнее», а «сколько девяток реально нужно бизнесу и сколько мы готовы за них заплатить».
Что такое blameless postmortem и зачем он?
Это разбор инцидента без поиска виноватых: цель не наказать человека, а понять, как система и процессы позволили аварии случиться, и не дать ей повториться. Логика инженерная, а не моральная: если за инциденты наказывают, люди начинают их скрывать и защищаться, и команда перестаёт учиться. Blameless исходит из того, что если один человек смог уронить прод одной командой — виновата система, которая это позволила, а не человек. Поэтому чинят не «Петю», а процесс: например, добавляют обязательное подтверждение перед выкаткой на прод.