Привет, %username%! Наверняка ты ловил себя на мысли «да неее, меня-то уж точно не разведут», а потом «опаньки» — и диктуешь, сам того не понимая, код, рядом с которым написано «НИКОМУ НЕ НАЗЫВАТЬ».

Мамам, папам, бабушкам и дедушкам часто сложно с компьютером. А фраза «придумай сложный пароль» вызывает панику и просьбу «придумай сам». Сверху — «повсеместная цифровизация» (напомню про “Запись только через сайт” ) и региональные МФЦ, где работают обычные люди, для которых «сложный пароль» автоматически превращается в 1955.12.21Яб. Виновных пусть ищут те, в чьи обязанности это входит.

Как меня развели

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

Через какое-то время я подумал «а дай я продублирую все рекомендации ещё и текстом», а когда счётчик символов перевалил за 1.5k — понял: пусть это будет самая простая статья в моём блоге, но она должна решить одну конкретную задачу — «объяснить любым маме/папе/бабушке/дедушке, зачем сложный пароль и как его придумать».

Осенью 2019 года я попался на тупой развод. Подробности опущу, но тот убийственный диалог не забуду:

М: «Вам СМСка пришла — видите, там написано Никому не называть?»
Я: «Да! Вижу!»
М: «Называйте!»
Я: «2314»
М: «Спасибо!»

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

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

Для справки: мошенники при попытке угнать аккаунт на Госуслугах просили именно код из СМС. Это значит, что пароль уже знали — поэтому «надо придумывать сложные пароли». А зная, что «помощь с регистрацией на Госуслугах» оказывают сотрудники МФЦ, через которые проходит большой поток людей — ребята и девчата стараются себе упростить жизнь. Свежая схема — угон Госуслуг через «отдел кадров» в Telegram-боте, и работает она ровно потому, что пароль слабый или повторяющийся.

Раньше (буквально 5–7 лет назад) хорошим паролем считался пароль с использованием латинских букв в нижнем и верхнем регистре и цифр 0-9, а достаточной длиной — 6–8 символов. Сейчас правила другие. NIST в актуальной редакции SP 800-63B (Rev.4, август 2025 ) формулирует прямо: длина важнее «сложности». Минимум — 15 символов, если пароль один и без второго фактора. Состав символов больше не обязателен — главное, чтобы пароль был длинным, уникальным и не светился в утечках.

Что делать

То, что я предложу дальше, кому-то покажется слишком сложным, кому-то слишком простым. Но сделать это надо.

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

• Сайт: ya.ru
• Логин/имя пользователя: vasilisapetrovna@ya.ru
• Пароль: МойТекущийПароль

Дальше — пройдись по списку и отметь, что не так. Имя, дата рождения, простое слово, которое легко соотнести с тобой (vasya, 10012990, prepod) — под замену. Всё, что короче 15 символов, — под замену. Повторяющиеся пароли — самое опасное: узнают пароль от Одноквашников и в остальные сервисы попадут без проблем.

Теперь главный вопрос: «как придумать сложный пароль?» Это проще, чем кажется.

Бери четыре слова, которые с тобой никак не связаны, и склеивай в одну фразу. Например: корзина-трактор-ягода-фонарь. Запомнить — секунда, а для бытовых угроз (фишинг, утечки, перебор) — больше чем достаточно. По-научному это «парольная фраза», и она бьёт «сложный» восьмисимвольный шифр с @, # и $ в одну калитку. Подробнее про парольные фразы и как их не забывать — у Теплицы социальных технологий и у Касперского .

Только не используй мою комбинацию буквально — как только пост уйдёт в публикацию, она через пару дней приедет в словари для перебора. Возьми свои четыре слова, желательно — из разных смысловых полей (не «кот-собака-хомяк-попугай», а что-то вроде «фиалка-домкрат-печенье-маяк»).

Если придумывать совсем лень — поставь менеджер паролей. Из живых и проверенных — четыре на выбор:

• Bitwarden — бесплатный, open-source, под все платформы и браузеры. По умолчанию пароли лежат в облаке самого Bitwarden, но можно поднять свой сервер — большинству не надо, берём облако и не паримся.
• KeePass и его форки — KeePassXC на десктопе, KeePassDX на Android, Strongbox на iOS. Тоже бесплатно и open-source, но всё хранится в одном зашифрованном файле — и ты сам решаешь, где этот файл лежит: на диске, в iCloud, в Яндекс.Диске, на флешке. Гибче, но и думать придётся больше.
• Proton Pass — бесплатный (с лимитами) или ~$4 в месяц за полную версию, open-source, от команды ProtonMail. Швейцарская юрисдикция, end-to-end шифрование, есть встроенный 2FA-аутентификатор и алиасы почты. По духу ближе к Bitwarden, но интерфейс заметно более «человеческий».
• 1Password — платный (~$48 в год для одного, ~$72 в год за семейный план на пятерых, с марта 2026 цена выросла ), зато с самым человеческим интерфейсом. Если настраиваешь маме и не хочешь объяснять, что такое «синхронизация vault’а» — это, пожалуй, самый короткий путь.

Один длинный пароль помнишь сам (тот самый, из четырёх слов) — это мастер-пароль от менеджера. Остальные пусть генерит и хранит он.

Тут есть ловушка, в которую попадают все, кто впервые ставит менеджер паролей: если потерял мастер-пароль — потерял всё. Никакой «восстановим по СМС» там не предусмотрено: это и есть фича, а не баг — иначе мошенник делал бы то же самое. Поэтому мастер-пароль выписываешь на бумажку (тот самый блокнот пригодится) и кладёшь в надёжное место дома. У 1Password есть ещё Secret Key — это второй ключ, который тоже нужен для входа на новом устройстве; его аналогично распечатываешь и хранишь.

А если ставить отдельное приложение всё равно лень — посмотри, что уже встроено. На iPhone и Mac это «Связка ключей iCloud» (в iOS 18 и macOS Sequoia — уже отдельным приложением «Пароли» ). На Android и в Chrome — Google Password Manager . У тех, кто живёт в Яндекс.Браузере, — встроенный менеджер Яндекса . Базовая механика везде одна: сгенерировать длинный пароль, запомнить, подставить в нужное поле и раскатать на остальные устройства. Для задачи «перестать использовать один и тот же пароль везде» этого хватает.

Цена простоты — привязка к экосистеме. Связка ключей не поедет на Android, Google Password Manager на iPhone — поедет, но криво. Яндекс — только в Яндекс.Браузере. Пин-код от карты или код от домофона туда тоже не положишь: это не сейф произвольных секретов, а хранилище логинов-паролей к сайтам. Поэтому встроенный менеджер — нормальный первый шаг, но как только сменишь телефон с iPhone на Android или наоборот — переезжать будет больно. Bitwarden, KeePass и 1Password в этом смысле нейтральны: работают одинаково везде.

А если и менеджер паролей — это уже слишком сложно (бабушке, дедушке, кому-то ещё, кто с компьютером на «вы»), есть рабочий вариант, над которым любят посмеяться безопасники: маленький блокнот и ручка. Да-да, тот самый, с которого мы начали — где выписаны сайт, логин и пароль. Пусть он и останется хранилищем для важного: Госуслуги, банк, почта, пин-коды от карт. Пароли в нём могут быть какими угодно длинными и страшными — записал и не запоминаешь.

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

Включи второй фактор (2FA) хотя бы на банке, почте и Госуслугах. Лучше через приложение-аутентификатор, а не через SMS — SMS уязвимы к SIM-swap (мошенник идёт в салон с поддельной доверенностью и перевыпускает симку на свой паспорт; все коды теперь идут ему) и к классическому выманиванию по телефону.

Из аутентификаторов на Android — Aegis (open-source, можно делать зашифрованный бэкап) или 2FAS . На iPhone — 2FAS или встроенный кодогенератор прямо в приложении «Пароли». Кроссплатформенно — Google Authenticator (с облачной синхронизацией) или Яндекс Ключ .

При подключении 2FA сервис показывает резервные коды — обычно 8–10 одноразовых кодов на случай, если телефон с аутентификатором утонет, разобьётся или потеряется. Их обязательно сохрани: в менеджер паролей, в тот же блокнот, в Telegram-избранное — куда угодно, но не игнорируй экран «вот ваши backup-коды, сохраните их». Без них при потере телефона восстановление доступа превращается в эпопею с фотографиями паспорта в техподдержку, а где-то — в полное «начать с нуля».

Где можно — переходи на passkeys. Google, Apple, Microsoft, GitHub уже поддерживают. Это вход без пароля, по биометрии. Продиктовать по телефону его в принципе нельзя — нечего диктовать.

Если коротко

Три правила, которые закроют львиную долю бытовых угроз:

1. Пароль от 15 символов, не повторяется между сервисами, не светится в утечках.
2. На критичных аккаунтах (банк, почта, Госуслуги) — второй фактор через приложение.
3. Никаких кодов из SMS вслух по телефону. С 1 июня 2025 в России действует правило : пока идёт голосовой вызов, SMS с кодами подтверждения (от Госуслуг, банков, маркетплейсов) задерживаются оператором связи и доставляются только после разговора. Но этот закон не помогает, если мошенник звонит через WhatsApp, Telegram или Zoom — для оператора это просто интернет-трафик, SMS пройдёт как обычно. Поэтому правило «положил трубку, перезвонил по номеру с карты» по-прежнему рабочее.

Если ты помог маме/папе/бабушке/дедушке настроить менеджер паролей и 2FA — ты сделал больше, чем три статьи на эту тему. Передай дальше.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.

Привет, %username%! Выкатил новый пост, поправил страницу, обновил title — и сидишь, ждёшь, пока поисковики соизволят переобойти сайт. День, два, неделя. А хочется, чтобы апдейт подхватился сразу после git push, без танцев с Search Console и ручных submission-форм.

Дальше — как закрыть эту боль одним шагом в GitHub Actions через мой CLI indexnow и почему оно вообще работает.

Что такое IndexNow и зачем он нужен

Протокол IndexNow — это простой способ сказать поисковику: «эти URL изменились, переобойди их побыстрее, пожалуйста». Ты делаешь один HTTP-запрос с ключом и списком URL, поисковик в ответ подтверждает приём (или отбивает с осмысленной ошибкой) — и дальше уже его проблема, когда именно он переобойдёт страницы.

Главное: submission автоматически шарится между всеми участниками протокола. По спеке достаточно дёрнуть один эндпоинт (например, api.indexnow.org или bing.com/indexnow), и тот же запрос провалидируется и расшарится со всеми: Bing, Yandex, Naver, Seznam, Yep и другие участники. Google к протоколу формально не присоединился — для него по-прежнему остаётся sitemap + Search Console.

Аутентификация — самая «забавная» часть протокола. Ты придумываешь ключ (произвольная hex-строка длиной 8–128 символов), хостишь его в виде текстового файла на собственном домене, например https://example.com/<key>.txt, и присылаешь этот ключ в каждом запросе. Поисковик идёт по URL, читает файл, сверяет содержимое с тем ключом, что ты прислал. Совпало — submission принят. Нет — 403. Просто и без OAuth.

И тут же — мой любимый перл из документации Яндекс.Вебмастера : «Ключ менять необязательно. Вы можете изменить ключ, если он стал известен третьим лицам.» То есть ключ, который ты по спеке обязан выложить публичным .txt на свой домен и который любой может вытащить одним curl, Яндекс предлагает ротировать, если он «стал известен третьим лицам». А он по дизайну протокола известен им всегда. Ну камон.

Зачем я написал свой CLI

Дёргать API руками лениво, особенно когда у тебя на пуш приходится 10–50 изменившихся URL и хочется делать это из CI. Можно, конечно, нагуглить готовый пример с curl и jq, но:

• ошибки разбирать в bash больно;
• ретраи на 429/5xx писать руками лень;
• sitemap парсить из XML в bash — отдельный жанр перформанса;
• лимит протокола в 10 000 URL на запрос тоже надо учитывать.

Поэтому я написал на Go маленький indexnow — сначала как CLI для разовых submission’ов, а с релиза v0.5.0 это уже и готовый GitHub Action. По дороге всё то, что обычно копится в самописных скриптах, я аккуратно унёс внутрь бинаря.

Заодно это стало хорошим pet-project’ом: тесты с -race, golangci-lint, mkdocs для документации, релизы через goreleaser, а теперь и composite Action с верификацией бинарей. Маленький инструмент, который и время экономит, и руки в форме держит.

Минимальный шаг в GitHub Actions

Самый короткий путь — взять готовый Action и засунуть один шаг в workflow:

- uses: jtprogru/indexnow@v0
  with:
    key: ${{ secrets.INDEXNOW_KEY }}
    sitemap: https://example.com/sitemap.xml

Всё. Этот шаг сам:

• определит ОС и архитектуру раннера (linux/amd64, linux/arm64, darwin/arm64, …);
• скачает релизный бинарь нужной сборки со страницы релизов;
• сверит его sha256 с checksums.txt, который лежит рядом с бинарями в релизе — это защищает от «а что если кто-то подменил артефакт»;
• закэширует бинарь в runner.tool_cache, чтобы следующие раны не качали его повторно;
• запустит indexnow submit с переданными параметрами.

Ключ передаётся через env, а не флагом, — даже если в твоём шаге случайно отрабатывает set -x, ключ в логах не светится. В $GITHUB_STEP_SUMMARY после прогона падает короткий отчёт: сколько URL улетело, сколько батчей упало, куда отправлял. Не нужно лезть в полный лог раннера, чтобы понять, прошёл submit или нет.

Submit только тех URL, что изменились

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

- uses: jtprogru/indexnow@v0
  with:
    key: ${{ secrets.INDEXNOW_KEY }}
    sitemap: https://example.com/sitemap.xml
    sitemap-since: ${{ github.event.before }}

sitemap-since фильтрует записи sitemap по <lastmod>: всё, что старее переданного времени, отбрасывается.

Один граничный случай, который я заложил по умолчанию: записи без <lastmod> всегда проходят. «Нет сигнала о времени» трактуется как «могло измениться», и для IndexNow это безопасный дефолт — повторный submit идемпотентен, лишний раз дёрнуть не страшно. Куда хуже промолчать про реально изменившуюся страницу.

А если sitemap’у не доверяешь — urls-from

sitemap-since хорош, когда <lastmod> у тебя действительно проставляется. Если нет (или ты не хочешь полагаться на свежесть sitemap’а вообще) — есть второй рецепт: собрать список URL из git diff между двумя коммитами и скормить его в Action через urls-from.

- uses: actions/checkout@v6
  with:
    fetch-depth: 0
- uses: jtprogru/indexnow@v0
  with:
    key: ${{ secrets.INDEXNOW_KEY }}
    urls-from: |
      git diff --name-only "${{ github.event.before }}..HEAD" -- 'content/**/*.md' |
        sed 's#^content/\(.*\)/index\.md$#https://jtprog.ru/\1/#'

urls-from — это просто bash-сниппет, чей stdout (по одной строке на URL) превращается в источник URL. Сниппет крутится в $GITHUB_WORKSPACE, так что git видит весь checked-out репозиторий и git diff работает как обычно. Пустой вывод — это не ошибка, шаг тихо выйдет с submitted-count=0.

Вот тот самый маппинг: content/<slug>/index.md → https://jtprog.ru/<slug>/. Никакого парсинга sitemap, никаких лишних submission’ов на страницы, которые не трогал. fetch-depth: 0 обязательно — без полной истории git diff против github.event.before молча отдаст пустоту.

Тег @v0 и плавающие версии

Одна из мелких, но важных деталей — модель версионирования.

• @v0.7.0 — конкретный релиз. Поведение зафиксировано, обновления только если ты сам поправишь workflow.
• @v0.7 — все патчи внутри 0.7.x, обновляется автоматически.
• @v0 — все релизы внутри 0.x, едет с каждым новым минором.

Плавающие теги (v0, v0.5) переставляются отдельным workflow на каждый релиз v0.Y.Z. То есть подписался один раз на @v0 — и едешь на последнем 0.x без правок workflow. Когда выкачу v1.0.0, тег @v0 останется на последнем релизе ветки 0.x: ты сам решаешь, переезжать ли на мажор. Никаких сюрпризов в духе «обновился — поведение сломалось».

Inputs, outputs и downstream-шаги

Inputs Action’а зеркалят флаги CLI: источники URL (urls / file / sitemap / urls-from), sitemap-since, endpoint, host, key-location, fail-on, retry-knobs (max-retries, base-backoff, max-backoff), dry-run, verbose, quiet, user-agent. Между «попробовал локально, всё работает» и «засунул в CI» нет шага «а как там оно в Action называется» — один и тот же набор имён.

Outputs тоже из коробки:

• exit-code — финальный код выхода CLI (0 / 1 / 2);
• submitted-count — сколько URL ушло (суммарно по батчам);
• failed-count — сколько батчей завершились не-2xx или ошибкой;
• report — одностраничная сводка; параллельно она же пишется в $GITHUB_STEP_SUMMARY.

Этими outputs удобно дёргать downstream-шаги: уронить алерт в Telegram, если failed-count > 0; или, наоборот, проигнорировать падение submit, если ты ему не доверяешь и не хочешь, чтобы из-за этого падал весь pipeline. Полный референс и готовые рецепты — в docs → GitHub Action .

Если Actions не вариант

GitLab CI, Drone, Woodpecker, cron на VPS, локальный запуск перед публикацией поста — для всех этих кейсов есть тот же бинарь, ставится двумя способами:

brew tap jtprogru/tap && brew install indexnow
# или
go install github.com/jtprogru/indexnow/cmd/indexnow@latest

Готовые бинарники под Linux / macOS / FreeBSD в связках amd64/arm64 лежат на странице релизов . И дальше тот же submit, только из шелла:

export INDEXNOW_KEY=8f7e6d5c4b3a29180706050403020100
indexnow submit \
    --sitemap https://example.com/sitemap.xml \
    --sitemap-since 2026-06-01T00:00:00Z

Источник URL — на выбор:

• позиционные аргументы: indexnow submit https://a https://b;
• --file urls.txt (по одному URL на строку, # — комментарий);
• --stdin — типичный pipe из другого CLI (sitemap-to-urls | indexnow submit --stdin);
• --sitemap — URL или локальный путь к XML.

С sitemap’ом отдельная история: <sitemapindex> раскрывается рекурсивно (ходишь по всем дочерним), а .gz-варианты гунзипятся прозрачно — отдельный шаг с gunzip не нужен. На больших проектах с десятками сегментированных sitemap’ов это здорово упрощает жизнь.

Что CLI делает за тебя

Если коротко — всё то, что обычно копится в скриптах вокруг такой задачи:

• Ретраи 429/5xx и transport-ошибок с экспоненциальным backoff’ом, jitter’ом и уважением к заголовку Retry-After (понимает и секунды, и HTTP-date). Ретраи без backoff превращают деградацию в катастрофу — особенно если поисковик уже под нагрузкой.
• Резка батчей по лимиту протокола (10 000 URL на запрос). Не нужно думать, что делать, когда у тебя 25 000 урлов: CLI сам режет на три батча, по каждому идёт отдельный submit и отдельный результат в отчёте.
• Несколько эндпоинтов сразу: --endpoint bing,yandex,naver. Если ты по какой-то причине не доверяешь «один эндпоинт расшарит всем», передай список — CLI отправит в каждый и склеит результат.
• Внятные exit code (0 — всё ок, 1 — submission failed по сети/HTTP/fail-on, 2 — usage error: кривые флаги, нет источника URL, нет ключа) и флаг --fail-on any|4xx|5xx|never. Например, на 429 ты можешь не хотеть падать (это не твоя проблема), а на 4xx по ключу — обязательно.
• Управление ключом через indexnow key: key gen --write public/ генерит ключ и кладёт hosted-файл в нужную директорию, key verify --host example.com --key $KEY дёргает GET по hosted-файлу и сверяет содержимое.

key verify стоит гонять до первого submit — чтобы убедиться, что key-файл реально отдаётся не только тебе из браузера, но и поисковикам. Иначе все submit’ы будут возвращать 403, а ты будешь чесать репу и читать changelog в поисках сломанного релиза.

Тонкие места, на которых легко споткнуться

• fetch-depth: 0 в actions/checkout. Без полной истории git diff против github.event.before молча отдаст пустоту: shallow-клон не видит предыдущий коммит. Симптом — submitted-count=0 на каждом пуше, и ты долго гадаешь, почему.
• Первый пуш в ветке. github.event.before там — нули (0000000...), git diff 0000000..HEAD сваливается с fatal: bad revision. Прикрой fallback’ом на HEAD~1.
• CDN кеширует hosted key-файл. Cloudflare, Fastly и прочие радостно складывают .txt в кеш на пять-десять минут. Поменял ключ — поисковик в это окно ловит старую версию и отбивает 403 на твой свежий submit. После ротации — явный purge, без вариантов.
• <lastmod> без timezone. sitemap-since ждёт RFC3339. Если Hugo (или чем ты там собираешь sitemap) пишет 2026-06-02T14:00:00 без Z и без смещения, фильтр поедет на таймзоне раннера: на GitHub-hosted это UTC, у себя на сервере — что настроил. Один и тот же sitemap начнёт давать разные срезы в зависимости от того, где крутится workflow.
• Параллельные эндпоинты ≠ страховка от лимитов. Отправил в bing,yandex,naver — формально получишь три ответа, но Bing всё равно поделится submission’ом с остальными. Если поисковик отбил 429, лучше уменьшить частоту запусков, чем долбить параллельно во все доступные API.

Где взять и куда нести issue

• Код, issues и звёздочки: github.com/jtprogru/indexnow
• Документация (EN + RU): jtprogru.github.io/indexnow
• Гайд по GitHub Action: jtprogru.github.io/indexnow/guides/github-action/

Если интегрируешь — поделись опытом в issues или прямо в комментариях. Особенно интересны истории про GitLab/Drone: под GitHub Action у меня самые подробные тесты, а на других CI оно проверяется реже.

PS: расскажи, как у тебя сейчас устроена индексация — Search Console + ручной запрос, sitemap-only, или что-то более хитрое? И насколько вообще IndexNow дал прирост по скорости индексации? Хочется собрать чуть более широкие данные, чем у меня одного.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.

Привет, %username%! В прошлой статье — «SLO как чертёж архитектуры» — я закончил тезисом, который тут же хочется развить: SLO выбирается не инженерами в одиночку, а вместе с бизнесом, потому что число в нём привязано к деньгам. А «вместе с бизнесом» в реальности чаще всего выглядит так: SRE придумал SLO, нарисовал дашборд, показал на демо, продакт покивал — и все разошлись. Чертёж готов. Надёжность… не выросла.

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

В этой статье я разворачиваю три практических следствия из этого тезиса, и все три — продолжение того же кейса с маркетплейсом (поиск каталога, 50M товаров, 30k RPS на пике), который я гонял в «чертеже»:

1. Диалог с бизнесом — это не презентация SLO, а формат принятия решений. SRE не «продаёт» таргет продакту, а вместе с ним выбирает уровень надёжности, политику бюджета ошибок и порядок разрешения спора «фичи против надёжности».
2. System Design-собес проверяет именно этот навык. Большинство «вопросов по SLO» — не про арифметику девяток, а про умение собрать разговор с бизнесом, удержать рамку трейд-оффов и перевести «бизнес хочет 100%» в инженерную работу.
3. Метрики SRE-команды меняются, когда продуктов больше одного. Ни «MTTR по компании», ни «SLO по сервису» как метрика команды не работают, когда команда обслуживает 5–10 продуктов. Нужен сводный язык.

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

Что ты унесёшь из статьи

Статья длинная (~40 000 знаков). Сразу — что заберёт каждая роль:

• SRE / SRE-lead. Как перестать «отдавать SLO» и начать вести по нему диалог: три признака, что разговор не состоялся; error budget policy как продуктовый, а не инженерный артефакт; и — отдельным блоком — какие метрики брать на команду, когда продуктов много, чтобы они не врали.
• Продакт / аналитик. Что именно бизнес должен уметь произнести сам (а не получать от SRE как откровение): где у нас критичные пользовательские пути, сколько стоит девятка в деньгах, кто и когда жмёт на стоп.
• Кандидат / интервьюер на System Design. Пять типовых собес-кейсов «про SLO», которые на самом деле проверяют переговорный навык, и разбор, что в них считается сильным ответом, а что — провалом.

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

TL;DR (если читать дальше уже некогда)

Четыре тезиса, к которым приходит статья:

1. SLO без error budget policy — это украшение дашборда. Контракт из SLO делает записанное правило: что происходит, когда бюджет сгорел, и кто принимает по этому поводу решение. Само число ничего не гарантирует. Без правила — это график, мимо которого все ходят.
2. Надёжность — это не состояние, а переговорный процесс. Её не «достигают» один раз. Каждый квартал бизнес и SRE заново выбирают уровень, потому что меняются нагрузка, деньги и приоритеты. SLO, который не пересматривают, врёт уже через полгода.
3. На собесе по SLO проверяют не формулы, а умение поменять поведение бизнеса. Сильный ответ всегда начинается со сценария и денег, а не с топологии и девяток. «100% доступности» — не повод сказать «нельзя», а повод показать цену.
4. Метрики SRE-команды при мультипродукте раскладываются на три слоя (надёжность продуктов / инженерное усилие / качество диалога) — один агрегат тут не справляется. Среднее по больнице — MTTR, composite SLO, число инцидентов — прячет ровно то, ради чего метрику заводили.

Дальше — как до этого дойти. Если интересует только управленческая кульминация — переходи сразу к разделу Метрики SRE-команды для мультипродукта .

Чертёж без переговоров — это просто дашборд

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

SLO как артефакт против SLO как контракта

SLO-артефакт — это число на дашборде. Его придумали, согласовали галочкой, поставили мониторинг, иногда даже сделали красивый burn-rate-график. Он существует. Он измеряется. И он ни на что не влияет, потому что ни одно решение в компании не принимается, глядя на него.

SLO-контракт — это то же число, но вокруг него выстроен процесс. Когда бюджет ошибок тает быстрее плана — кто-то останавливает рискованные деплои. Когда бюджет сгорел — спринт переключается на надёжность, и это не подвиг отдельного SRE, а записанное правило. Когда продакт хочет выкатить фичу к Чёрной пятнице — он сам спрашивает «сколько у нас осталось бюджета», потому что знает, что это его валюта тоже.

Разница видна по тому, как объект ведёт себя в жизни команды:

Разница между ними — не в качестве дашборда. Она в том, встроен ли SLO в принятие решений. И встроить его туда нельзя в одностороннем порядке: SRE не может «назначить» бизнесу, что теперь решения принимаются по бюджету ошибок. Это можно только договорить.

Три признака, что разговор не состоялся

Проверить, в каком режиме у тебя SLO, можно по трём симптомам. Если узнаёшь хотя бы один — диалога не было, был монолог SRE.

1. SLO «спущен сверху». Инженеры посчитали девятки, выбрали таргет «по аналогии с большими» и поставили продакта перед фактом. Продакт не участвовал в выборе числа — значит, он не считает его своим и не будет на него опираться в спорах. Для него это «инженерная штука», а не общий контракт.
2. Нет error budget policy. SLO есть, бюджет считается, дашборд горит то зелёным, то красным. Но что конкретно делать, когда бюджет на исходе — нигде не записано. В итоге красный дашборд не меняет ничего: «ну красный, ну ладно, катим дальше».
3. На пересечении бюджета никто не останавливает фичи. Самый жёсткий признак. Бюджет сгорел в ноль, а релизы продолжают выкатываться, потому что «дедлайн важнее». Это значит, что SLO проигрывает любому продуктовому приоритету — то есть фактически его нет.

Все три признака — про одно: SLO не имеет оперативных последствий. А инструмент без последствий — это декорация.

Кейс Mercari: переименовать мало, нужен ритуал

Хороший пример того, как легко перепутать артефакт с контрактом, — переход к User Journey SLO. Команды (в том числе Mercari, описавшие это в посте «Keeping User Journey SLOs Up-to-Date with E2E Testing» в декабре 2024 года) приходят к тому, что SLO «на сервис» прячет пользовательскую боль, и переезжают на SLO, привязанные к пользовательскому пути. Идея правильная — она ровно из «чертежа»: SLI вешаются на шаги критичного пути, а не на сервис целиком.

Но вот ловушка: само по себе переименование «SLO сервиса X» → «SLO пользовательского пути Y» ничего не меняет, если за ним не стоит сопровождающий ритуал с продактом. Если User Journey SLO живёт там же, где жил старый — на дашборде, который смотрит только дежурный SRE, — это просто более точный артефакт. Та же декорация, только лучше нарисованная.

Работает переход тогда, когда вместе с новым SLO появляется регулярная встреча, на которой продакт смотрит на бюджет своего пути и принимает по нему решения. Не SRE показывает — продакт смотрит и решает. Переименование — это 10% работы. Остальные 90% — встроить новый объект в процесс продукта.

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

Здесь стоит развести два понятия — продуктовую надёжность (видит ли пользователь, что сценарий работает) и техническую доступность (отвечает ли ручка /search двухсоткой). Важное следствие из этого разведения: продуктовая надёжность по определению не может принадлежать только SRE.

SRE владеет технической доступностью — это его зона: инфраструктура, репликация, failover, capacity. Но «работает ли поиск для пользователя так, что он покупает» — это вопрос, на который SRE физически не может ответить в одиночку, потому что «так, что он покупает» — это продуктовое определение, а не техническое. Кто решает, что пустая выдача по валидному запросу — это провал, а не «технически 200 OK»? Продакт. Кто решает, что цена на карточке старше минуты — это инцидент? Продакт.

Поэтому у продуктовой надёжности должен быть продуктовый владелец. Не «SRE отвечает за надёжность» — это и есть корень всех проблем из предыдущего раздела. А «SRE отвечает за инструментарий и техническую доступность, продакт — за то, что считается надёжностью с точки зрения пользователя, и они держат общий SLO». Диалог не состоится, пока с продуктовой стороны нет того, кто за этот SLO отвечает головой.

Что мы на самом деле обсуждаем с бизнесом

Допустим, продуктовый владелец есть и готов разговаривать. О чём конкретно идёт разговор? Не «покажи мне дашборд» — это не разговор. Настоящий диалог о надёжности крутится вокруг четырёх вещей.

1. Таргет как бюджет на компромисс

Главное, что должен понять бизнес: высокая надёжность — это не бесплатно и не всегда хорошо. Это позиция на шкале трейд-оффов.

• Высокий SLO = низкая скорость фич (бюджет ошибок мал, каждый релиз — ставка), дорогая инфраструктура (резервирование, регионы), медленные релизы (канарейка, постепенный rollout).
• Низкий SLO = быстрые фичи, дешёвая инфраструктура, но больше видимых пользователю сбоев.

Из «чертежа» помним конкретные множители для нашего маркетплейса: переход с 99.9% на 99.99% — это 4–6× → 15–25× baseline по инфраструктуре и 2–3× → 8–10× по людям. Это не «инженеры хотят красивую цифру». Это бизнес-решение, потому что платит за него бизнес, и отказывается от скорости фич — тоже бизнес.

Ключевая фраза, которую SRE должен уметь произнести в этом разговоре, звучит примерно так:

«Если снизим SLO поиска с 99.99% до 99.9% — освободим вот этот регион и вот эту часть дежурной нагрузки, сможем катить фичи в полтора раза быстрее. Заплатим за это вот таким ростом видимых сбоев на пике. Берём?»

Это и есть перевод надёжности в валюту, понятную обеим сторонам. Не «давайте сделаем понадёжнее», а «вот цена, вот что освобождается, решаем вместе».

2. Error budget policy: правила пишутся до пожара, а не во время

Error budget policy — это заранее зафиксированные правила игры. Не «что мы будем делать, когда бюджет сгорит» (это решается в панике и проигрывается дедлайну), а «что происходит автоматически, когда бюджет сгорел» — написанное и согласованное обеими сторонами заранее.

Минимальная политика отвечает на четыре вопроса:

• Кто и при каком условии останавливает релизы? Например: при burn-rate выше 14.4× за час — автоматический freeze рискованных деплоев до конца окна.
• Кто разрешает продолжить? Не «инженер решил» и не «продакт продавил», а названная роль с названным условием.
• Что переходит в roadmap при сгоревшем бюджете? Reliability-задачи получают приоритет над фичами — и это записано, а не выпрашивается каждый раз заново.
• Когда и как пересматривается сам SLO? Раз в квартал — короткий ритуал «изменилось ли что-то в бизнесе или системе, что меняет нужное число».

На практике это умещается на одну страницу — по образцу error budget policy из главы «Implementing SLOs» в Google SRE Workbook. Для поиска нашего маркетплейса политика могла бы выглядеть так:

Error budget policy — поиск каталога (SLO 99.9%, окно 30 дней)

• Жёлтая зона (потрачено 50% бюджета): уведомление в канал продукта, ретроспектива на ближайшем синке, новых рискованных экспериментов не начинаем.
• Красная зона (потрачено 90%): freeze рискованных деплоев — катим только хотфиксы и security-патчи. Reliability-задачи поднимаются над фичами в текущем спринте.
• Бюджет исчерпан (100%): полный freeze фич до конца окна. Эскалация продуктовому владельцу, обязательный разбор причин.
• Кто снимает freeze: продуктовый владелец по согласованию с SRE-lead, не раньше чем burn-rate вернулся к норме.
• Пересмотр SLO: первый понедельник квартала, участвуют продакт и SRE-lead.
• Подписали: имя продуктового владельца, имя SRE-lead, дата.

Эта страница важнее любого дашборда. Дашборд показывает, что бюджет горит. Страница говорит, что с этим делать и кто за это отвечает.

Важнейшее уточнение, которое часто упускают: error budget policy — это продуктовый артефакт, а не инженерный. Его подписывает не тимлид SRE «для себя», а продуктовый владелец — потому что это он соглашается, что при сгоревшем бюджете его фичи подождут. Подпись здесь не метафора: должно быть понятно, кто конкретно сказал «да» этим правилам. Если не можешь назвать имя — политики нет.

3. Перевод девяток в деньги

Бизнесу нужны не проценты, а валюта. «99.9% против 99.95%» для продакта — пустой звук, пока ты не показал, что стоит за этой разницей в деньгах. Поэтому в зрелом диалоге всегда есть связка SLI → ₽.

Берём наш маркетплейс. Из «чертежа»: GMV порядка 1 млрд ₽ в день, поиск кормит 40–70% покупок, каждые +100 ms латентности на ключевом read path стоят примерно −0.5…1.5% конверсии. Отсюда — простой мост:

Дальше бюджет ошибок перестаёт быть процентом и становится деньгами. Сгоревший за инцидент бюджет — это не «−2% за час на графике», а «вот столько недополученной выручки, если такой инцидент повторится на пике». Burn-rate из множителя (14.4×, 36× — подробно про него в статье «Скорость сгорания бюджета ошибок» ) превращается в скорость утечки денег: при таком-то burn-rate на пике Чёрной пятницы мы теряем столько-то рублей в минуту.

Посчитаем на пальцах для одного и того же 15-минутного инцидента в поиске — полная недоступность пути. GMV 1 млрд ₽ в день размазан неравномерно: обычным днём через поиск проходит порядка 400 млн ₽ выручки (предположим, 40% покупок стартуют с поиска), на пике распродажи дневной GMV умножается в ×3–5, и доля стартующих с поиска покупок растёт.

Цифры грубые и зависят от профиля трафика — но порядок и так говорит главное: один и тот же инцидент с одним и тем же burn-rate стоит на пике в разы дороже. Поэтому «потеряли 15 минут» — бессмысленная фраза без контекста «когда». А burn-rate как безразмерный множитель тут особенно удобен: 50× одинаково тревожен и во вторник, и в Чёрную пятницу, просто в деньгах разворачивается по-разному.

Это разговор, который продакт понимает мгновенно. Не «у нас burn-rate 14.4», а «при текущем burn-rate мы за час пикового трафика теряем выручку, равную недельной зарплате команды — продолжаем катить?». Конвертация в деньги и переводит SLO из инженерной плоскости в управленческую.

4. «Где у нас критичные пользовательские пути»

И последнее, самое неочевидное. Список критичных пользовательских путей (CUJ — critical user journey) бизнес должен уметь произнести сам. Это не то, что SRE приносит продакту как откровение — «смотри, я тут проанализировал, у вас критичен поиск». Если CUJ известны только инженерам, значит, бизнес не владеет собственной надёжностью.

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

Для нашего маркетплейса CUJ — это путь «пришёл с намерением купить → нашёл → выбрал → положил в корзину → оплатил». И продакт должен понимать, что поиск (вход в этот путь) и оплата (выход) — разного класса критичности, и что на них вешаются разные SLO. Это понимание — не бонус, это условие, без которого все предыдущие три пункта повисают в воздухе.

Диалог — это цикл, а не презентация

Сложим четыре пункта вместе. Диалог о надёжности — это не разовое «защитили SLO на демо», а повторяющийся цикл:

Каждый виток — это квартал. На входе бизнес приносит «что и сколько стоит», на выходе получает «вот сколько надёжности мы дали и какой ценой». Если хоть одно звено разорвано — цикл рассыпается, и SLO откатывается в режим артефакта. Именно эту целостность и проверяют на собесе — к нему и переходим.

Кейсы с System Design-собеса

Те же тезисы, но в позе «кандидат под прессом». Когда меня самого недавно гоняли по этой теме на интервью, стало особенно ясно: вопросы «про SLO» почти никогда не про SLO. Они про то, умеешь ли ты вести разговор о надёжности так, чтобы бизнес поменял поведение. Разберу пять типовых сценариев — на том же маркетплейсе.

Кейс 1. «Зачем тебе SLO 99.9, а не 99.99?»

Что проверяют: умеет ли кандидат держать рамку «бюджет → архитектура → деньги».

Провальный ответ: начать с топологии. «Ну, 99.99 — это active-active в трёх регионах, а 99.9 — один регион с failover между AZ». Технически верно, но это ответ на вопрос «чем отличаются архитектуры», а не «зачем тебе эта надёжность».

Сильный ответ всегда начинается со сценария бизнеса:

«Зависит от того, какой это путь. Если это поиск каталога — главный драйвер конверсии — то считаем: на 99.9% бюджет даунтайма на пике ~14 минут в месяц, на 99.99% — полторы минуты. Разница в архитектуре — лишних 15–25× против 4–6× baseline. Вопрос к бизнесу: эти 12 минут в месяц на пике стоят нам больше или меньше, чем утроение инфраструктуры? Если GMV такой, что минута пикового даунтайма — сотни тысяч, берём 99.99. Если нет — 99.9 с запасом».

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

Кейс 2. «У вас 99.95 по чекауту, но 30% оплат не проходит — что не так?»

Что проверяют: понимает ли кандидат разрыв между технической доступностью и продуктовой надёжностью.

Это мой любимый кейс, потому что он ловит самую частую ошибку. Дашборд зелёный — 99.95% по эндпоинту оплаты. А бизнес кричит, что треть оплат не доходит. Противоречие? Нет. SLI повешен не туда.

Что произошло: SLI считает «доля ответов 2xx от ручки /pay». Ручка честно отвечает 200 OK — она приняла запрос. А дальше платёж уходит в провайдера, провайдер таймаутит, ретрай не настроен, и для пользователя оплата «не прошла» — но для SLI всё прекрасно, ручка-то ответила.

Сильный ответ:

«SLI измеряет здоровье ручки, а не сценарий. Его надо переповесить на пользовательский результат: „доля начатых оплат, завершившихся подтверждённым списанием за < N секунд“. Тогда таймауты провайдера, потерянные колбэки и зависшие платежи попадут в знаменатель, и 99.95% превратятся в честные 70%. Дашборд начнёт показывать ту же боль, что чувствует бизнес».

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

Кейс 3. «Бизнес требует 100% доступности. Что отвечаешь?»

Что проверяют: переговорный навык в чистом виде.

Провальный ответ: «100% невозможно». Технически правда, но это ответ инженера, который закрывает разговор, а не ведёт его. Бизнес услышит «не хочу» и пойдёт давить.

Сильный ответ — не «нельзя», а цена:

«Окей, давай посчитаем, что такое 100%. Каждая девятка после 99.9 удорожает систему примерно в разы. 99.99 — это уже 15–25× baseline и заморозка скорости релизов. 99.999 — это multi-cloud, независимые DNS, частично независимые кодовые базы, подходы из telecom. А 100% — это бесконечность: ноль допустимых сбоев означает ноль деплоев, ноль экспериментов, ноль изменений. Мы перестанем выпускать фичи вообще. Точно нужны эти девятки — или нам нужно, чтобы конкретный сценарий, скажем оплата, не падал заметно для пользователя? Это разные задачи, и вторая решается сильно дешевле».

Кандидат переводит абсолютное требование в трейд-офф и возвращает бизнесу выбор. Часто за «хотим 100%» стоит «не хотим терять оплаты в пик» — а это не про 100%, это про правильный SLO на правильный путь плюс graceful degradation.

Кейс 4. «Кто принимает решение о фризе релизов при сгорании бюджета?»

Что проверяют: есть ли у кандидата error budget policy в голове и понимает ли он, что это продуктовый артефакт.

Провальный ответ: «SRE решает» или «тимлид решает». Это инженерный ответ, и он выдаёт, что у кандидата SLO живёт в инженерной резервации.

Сильный ответ:

«Решает не человек в моменте, а записанная заранее error budget policy. В ней зафиксировано: при таком-то burn-rate за такое-то окно — автоматический freeze рискованных деплоев. И подписана эта политика продуктовым владельцем, потому что это он соглашается, что его фичи подождут. Если решение каждый раз принимается заново и под давлением — значит, политики нет, и побеждает тот, кто громче».

Здесь проверяют понимание, что фриз — это не власть SRE над продуктом, а заранее согласованное обеими сторонами правило. Кандидат, который это понимает, не будет воевать с продактом — он сошлётся на то, что они вместе подписали.

Кейс 5. «Покажи, как сожжённый бюджет влияет на дорожную карту»

Что проверяют: встроен ли SRE в плановый цикл или живёт в параллельной вселенной с продуктом.

Провальный ответ: «при сгорании бюджета мы делаем post-mortem». Post-mortem — это хорошо, но это про прошлое. Вопрос — про будущее, про roadmap.

Сильный ответ:

«Сгоревший бюджет — это вход в планирование, а не только разбор инцидента. Механически: при систематическом сгорании reliability-задачи поднимаются в приоритете над фичами на следующий цикл — это записано в policy. На квартальном reliability review мы смотрим burn-rate за квартал по каждому пути и решаем, куда идёт инженерное усилие. Если поиск стабильно жжёт бюджет — значит, в следующем квартале часть roadmap уходит на его укрепление, и продакт это принимает, потому что видит связь „сгорание → потерянная выручка“».

Это проверка на то, что SRE и продукт планируют из одного документа, а не из двух. Если бюджет ошибок никак не дотягивается до roadmap — SRE и продукт живут в разных вселенных, и SLO снова декорация.

Главный паттерн всех пяти кейсов

Сведём пять кейсов в одну таблицу — что на самом деле проверяет каждый:

На собесе не проверяют знание формул сгорания бюджета — это гуглится за минуту. Проверяют, можешь ли ты вести разговор о надёжности так, чтобы бизнес поменял своё поведение. Все пять сильных ответов имеют одну форму: начать со сценария и денег, перевести требование в трейд-офф, вернуть выбор бизнесу, сослаться на заранее согласованное правило. Это и есть навык, который «чертёж» описывал как «SLO — интерфейс между System Design и бизнесом», только теперь — со стороны человека, который этим интерфейсом пользуется вживую.

Метрики SRE-команды для мультипродукта

Третий тезис — и самый практически болезненный. Пока продукт один, метрики команды SRE совпадают с метриками продукта: SLO продукта, его бюджет, его инциденты. Команда отчитывается надёжностью своего единственного сервиса, и всё сходится.

Когда продуктов становится 5–10, эта простая картина ломается. Команда обслуживает зоопарк сервисов с разными CUJ, разной критичностью, разной зрелостью. И тут возникает вопрос, на который у большинства команд нет хорошего ответа: как одной цифрой отчитаться перед менеджментом за надёжность, которую ты дал восьми разным продуктам? Соблазн — взять среднее. На нём всё и ломается.

Что не работает как метрика команды

Три популярных агрегата, каждый из которых врёт по-своему:

• MTTR в среднем по всем инцидентам. Растворяет редкие тяжёлые случаи в массе мелких. Команда, которая быстро закрывает сто пустяковых алертов и месяц не может починить один критичный, покажет прекрасный средний MTTR. Хуже того, метрика поощряет «закрыть быстро, не разбираясь» — лишь бы цифра была хорошей.
• Composite SLO по всем продуктам. «Средняя надёжность по компании 99.94%» — это средняя температура по больнице. Она теряет CUJ: упавший в ноль критичный путь одного продукта тонет в здоровье семи остальных. Наивная агрегация SLO в мультипродукте математически врёт — этот эффект хорошо разобран в посте Алекса Идальго «Implicit SLOs and their dangers» : композит почти всегда оптимистичнее, чем худший из путей, а пользователю больно именно от худшего.
• Количество инцидентов в абсолюте. Стимулирует молчать о мелких. Если команду меряют числом инцидентов, она перестаёт их заводить — и ты теряешь сигнал. Это классический закон Гудхарта: метрика, ставшая целью, перестаёт быть метрикой.

Общая болезнь всех трёх — они сжимают разнородное в одно число, и в этом сжатии теряется ровно то, ради чего метрику заводили.

Что осмысленно мерить: три слоя

Вместо одного агрегата — раскладка по трём слоям, параллельная трём ролям из «чертежа»: бизнес / инженерия / управление. Каждый слой отвечает на свой вопрос и не пытается заменить остальные.

Слой 1. Надёжность продуктов суммарно (бизнес-слой)

Не «средний SLO», а покрытие и распределение:

• Доля продуктов, у которых SLO существует, написан в терминах CUJ и формально подписан продактом. Это метрика зрелости, а не надёжности. «6 из 8 продуктов имеют подписанный SLO» говорит больше, чем любой композит.
• Доля продуктов с действующей error budget policy. Не «есть SLO», а «есть записанное правило, что делать при сгорании». Обычно эта доля сильно меньше первой — и разрыв между ними и есть фронт работ.
• Burn-rate бюджетов по всем продуктам как тепловая карта, а не среднее. Восемь строк, в каждой — сгорание за квартал. Красные клетки видно сразу, и ни одна не тонет в зелёных соседях.
• Сумма money loss за квартал — если связка SLI → ₽ настроена. Это единственная цифра из этого слоя, которую менеджмент понимает без перевода.

Слой 2. Инженерное усилие команды (продуктивность)

Сколько стоит надёжность в человекочасах и насколько это устойчиво:

• Toil как % времени команды. Гугловский потолок — 50% (правило из главы «Eliminating Toil» в Google SRE Book); всё, что выше, означает, что команда тонет в ручной рутине и не строит автоматизацию. Toil — отличная инженерная метрика зрелости именно потому, что растёт незаметно и душит команду медленно.
• Доля задач, переходящих от SRE обратно в продуктовую команду. Антипаттерн — «SRE как owner навсегда»: команда взяла продукт на поддержку и больше его не отпускает. Здоровая динамика — знания и ответственность постепенно возвращаются в продуктовую команду, а SRE остаётся на инструментарии и сложных случаях.
• Время от инцидента до закрытого action item — не до восстановления. Восстановили за 20 минут, а исправили причину через полгода — это плохо, и средний MTTR это скрывает, а эта метрика показывает.
• Доля постмортемов с реализованными action items. Постмортем, после которого ничего не сделали, — это терапия, а не инженерия. Эта доля показывает, учится ли команда на самом деле.

Слой 3. Качество диалога (управленческий слой)

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

• Регулярность product reliability review. Проводится ли квартальный разбор бюджета с каждым продактом — или только с теми, кто сам пришёл. Цель — со всеми и по расписанию.
• Доля продуктов, где бизнес сам приходит за обсуждением бюджета. Это лакмус. Если продакт сам спрашивает «сколько у нас бюджета осталось» — диалог здоров. Если SRE его догоняет — нет. Эта доля растёт медленно и означает культурный сдвиг, а не процессный.
• NPS/CSAT-аналог от команд разработки на сервис SRE. Команда SRE — это тоже сервис, у него есть внутренние пользователи (продуктовые команды), и их удовлетворённость измерима. Низкий внутренний CSAT при хороших технических метриках — сигнал, что SRE воспринимают как тормоз, а не как партнёра.

Соберём три слоя в одну таблицу — её удобно держать перед глазами при отчёте:

Ни одна метрика из правой колонки («какой агрегат заменяет») не исчезает полностью — MTTR и счётчик инцидентов остаются полезными для внутренней диагностики. Но как метрика команды перед менеджментом они проигрывают трёхслойной раскладке, потому что усредняют то, что усреднять нельзя.

Как это звучит в отчёте менеджменту

Финальная проверка всей раскладки — как команда отчитывается наверх. Сравни два варианта.

Плохо (агрегат): «У нас средний MTTR 22 минуты и composite SLO 99.94%». Менеджмент кивает, ничего не понимает, ни одно решение не меняется.

Хорошо (три слоя): «За квартал укрепили подписанный SLO с error budget policy у 6 из 8 продуктов (было 4), суммарное сгорание бюджета упало на 35%, бизнес-потери от инцидентов сократились на N рублей. Toil держим на 40%. Два продукта вернули в зону ответственности продуктовых команд. Осталось два продукта без политики — это фронт на следующий квартал».

Второй отчёт показывает движение, цену и план. Это и есть язык, на котором SRE-команда разговаривает с менеджментом, когда продуктов больше одного, — не «средняя температура», а «вот что мы дали бизнесу и как конвертировали инженерное усилие в продуктовый результат».

Что сделать завтра утром

Чек-лист «куда вернуться», когда дочитал. Пять вопросов — если на какой-то нет ответа, там и фронт работ.

1. Какой product reliability review встроен в наш квартальный план? Если ответ «никакой» или «по запросу» — начни с того, чтобы поставить в календарь регулярную встречу по бюджету с каждым продуктовым владельцем.
2. Кто из бизнеса формально подписал error budget policy — и подписал ли вообще? Если не можешь назвать имя — у тебя SLO-артефакт, а не контракт. Это задача номер один.
3. На какой панели я вижу „health по сценарию“, а не „health по сервису“? Если только по сервису — твои SLI повешены на ручки, а не на пути, и ты не видишь того, что чувствует пользователь.
4. Сколько раз за последний квартал бизнес сам поднял разговор о трейд-оффе „фича против надёжности“? Если ноль — диалог пока односторонний, и слой 3 у тебя в красной зоне.
5. Какой из метрик трёх слоёв у нас нет — и почему? Чаще всего отсутствует слой 3 (качество диалога), потому что его сложнее всего мерить. Но именно он отличает зрелую практику от набора дашбордов.

Заключение

В «чертеже» я доказывал, что архитектура без SLO — это эстетика, а не инженерия. Эта статья добавляет вторую половину: SLO без диалога — это дашборд, а не управление.

Чертёж надёжности сам по себе мёртв. Его надо защищать, торговать им и переписывать вместе с бизнесом каждый квартал. Технический инструмент — SLI, SLO, error budget — становится управленческим ровно в тот момент, когда у инженеров и бизнеса появляется одна картинка целевой надёжности и одна валюта компромиссов. До этого момента у тебя есть только красивые графики и предчувствия.

Три вещи, ради которых стоило городить всю статью:

• Диалог — это формат принятия решений, а не презентация. Его сердце — записанная error budget policy, подписанная продуктовым владельцем.
• На собесе по SLO проверяют переговорный навык, а не арифметику. Сильный ответ начинается со сценария и денег и возвращает бизнесу выбор.
• Метрики команды при мультипродукте — это три слоя, а не один агрегат. Среднее по больнице прячет именно ту боль, ради которой метрику заводили.

Надёжность не «достигается». Она каждый квартал заново строится в диалоге — и проигрывается ровно там, где этот диалог замолчал.

Спасибо, что дочитал до конца. Это продолжение цикла, начатого статьёй «SLO как чертёж архитектуры» . Если у тебя есть свой опыт диалога с бизнесом о надёжности — особенно истории, как error budget policy реально остановила релиз или как менялись метрики команды с ростом числа продуктов, — буду рад услышать.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.

Привет, %username%! QR-коды в 2026 году встречаются буквально везде: меню в кафе, оплата в магазине, ссылка на Wi-Fi в аэропорту, чек из терминала. Камера телефона декодирует такой код за десятки миллисекунд, и большинство людей воспринимают QR как магический чёрно-белый прямоугольник, который «как-то превращается в URL». А внутри — обычный документированный стандарт ISO/IEC 18004, и при желании его реально разобрать вручную: с карандашом, бумагой и базовой арифметикой.

В этом разборе пройдём по шагам, как декодировать QR-код глазами: что такое finder patterns и тайминг-полоски, где зашиты маска и уровень коррекции ошибок, как читать данные зигзагом снизу-справа вверх и собирать из битов исходную строку. В качестве подопытного — самый маленький Version 1 (21×21) с содержимым "HI", чтобы маска и зигзаг укладывались в голове, а не в Excel.

TL;DR

• Стандарт — ISO/IEC 18004, всего 40 версий: V1 — 21×21 модуль, дальше шаг +4 модуля на сторону до V40 (177×177).
• Три больших квадрата по углам — finder patterns, задают ориентацию. Четвёртого (в правом нижнем углу) нет — это и есть «низ-право».
• 15 бит format info вокруг finder-ов хранят уровень коррекции (L/M/Q/H) и номер маски (0–7); защищены своим BCH-кодом и продублированы дважды.
• Маска нужна, чтобы зона данных не складывалась в длинные одноцветные полосы и не имитировала случайно finder-паттерн — сканер бы поплыл. После XOR с правильной маской биты читаются «честно».
• Данные читаются зигзагом снизу-справа вверх, парами столбцов, перепрыгивая тайминг-колонку №6, по 8 бит на байт.
• Первые 4 бита — Mode Indicator (numeric / alphanumeric / byte / kanji), дальше Character Count Indicator переменной длины, потом сами данные, терминатор 0000 и padding EC 11 EC 11 ....
• За payload идут байты Reed-Solomon для коррекции ошибок: код над полем GF(256), число codeword’ов зависит от версии и уровня (для V1-L — 7, для V1-H — уже 17). В этом разборе их сознательно пропускаем — без таблиц и GF-арифметики на бумаге не возьмёшь.

После пары часов практики можно вытащить из небольшого кода (V1, 21×21) короткую строку вроде URL без сканера. До «прочитал визитку взглядом за секунду» — уже из области цирковых номеров: Reed-Solomon без вычислений в уме не выкрутишь, а на V10+ зигзаг становится ощутимо больно держать в голове.

Подопытный

Самый маленький размер — Version 1 (21×21 модуль). Содержимое: "HI". Раскрашены функциональные зоны.

Шаг 1. Ориентируемся

Три синих квадрата 7×7 — finder patterns. Они нужны сканеру, чтобы понять, где верх и поворот кода. Правило простое: три есть, а четвёртого (в правом нижнем углу) нет — туда смотрит «низ-право».

Вокруг каждого finder-а идёт separator — белая рамка в один модуль шириной (на схеме это пустая полоса между синим квадратом и всем остальным). Назначение прямолинейное: изолировать finder от данных, чтобы сканер не пытался разобрать «полуfinder-полуданные» на стыке и не плыл по координатам.

Между ними тянутся красные тайминг-полоски (строка 6 и столбец 6) — чередование чёрный-белый-чёрный. Они задают «линейку», по которой считаются координаты модулей. Если что-то поплыло — выравниваешься по ним.

Фиолетовый одиночный модуль — dark module, всегда чёрный по стандарту. Просто маркер, не несёт смысла.

Оранжевая зона — format info. 15 бит, продублированные дважды (для надёжности): одна копия идёт буквой Г вокруг левого верхнего finder-а, вторая — полоской справа от правого верхнего и снизу от левого нижнего. В ней зашифрованы две критичные вещи: уровень коррекции ошибок (L/M/Q/H) и номер маски (0–7).

Всё зелёное — это собственно данные плюс байты Рида-Соломона.

Чего в V1 ещё нет, но в больших версиях встретишь

В нашей маленькой сетке всё описанное выше — это полный набор функциональных зон. Но как только переходишь к версиям побольше, появляются ещё две вещи:

• Alignment patterns — маленькие квадраты 5×5 с чёрной точкой в центре, разбросанные по полю. Появляются с V2 (один штук, в правом нижнем углу), к V7 их уже шесть, а у V40 — целых 46. Нужны для локальной компенсации искажений сетки: V1 ещё читается «по линейке тайминга», а у большого QR на смятой или сфотографированной под углом картинке координаты модулей плывут, и без локальных якорей сканер промахивается.
• Version info — два блока 6×3 рядом с правым верхним и левым нижним finder-ами, появляются с V7. Внутри 18 бит: 6 бит самого номера версии и 12 бит BCH-чётности. Подход тот же, что у format info, только код покрупнее — BCH(18, 6), тоже исправляет до 3 ошибок. Декодеру эта зона нужна, чтобы достоверно определить размер кода, не доверяя «посчитаю клетки по краю» (на размытом снимке такой подсчёт ломается легко).

В V1 этого ничего нет, поэтому в нашем разборе обходимся без них — но если ты потом возьмёшь V3 с того же чека, держи их в голове: чёрная точка в правом нижнем — не часть данных, а alignment.

Шаг 2. Снимаем format info

Биты идут: вдоль строки 8 слева направо (с пропуском тайминг-колонки), а потом по столбцу 8 снизу вверх (тоже с пропуском тайминг-строки). Старший бит = #14, младший = #0.

Считываем по порядку от #14 до #0:

сырые биты : 1 1 0 1 1 0 0 0 1 0 0 0 0 0 1
XOR-маска  : 1 0 1 0 1 0 0 0 0 0 1 0 0 1 0
─────────────────────────────────────────
результат  : 0 1 1 1 0 0 0 0 1 0 1 0 0 1 1

Маска 101010000010010 зашита в стандарте — иначе формат, состоящий из нулей, тоже был бы валидным, и любая дырка на пустом месте всё ломала бы.

Разбираем результат 011100001010011:

• биты 14–13 = 01 → уровень коррекции L (~7 % избыточности)
• биты 12–10 = 110 → маска №6
• остальные 10 бит — BCH-код для коррекции ошибок в самих этих 15 битах (нам не нужны).

Теперь самое важное: мы знаем маску. Значит, можно снять её с зелёной зоны данных и прочитать настоящие биты.

Маска №6 задаётся формулой: клетка (r, c) инвертируется, если

Кодирование уровня коррекции

BCH(15, 5) под капотом

Format info — это не просто 15 случайных бит. Это BCH-код (15, 5) над GF(2): 5 содержательных бит (2 на EC level + 3 на номер маски) защищаются 10 битами чётности. Такой код исправляет до 3 ошибочных бит внутри своих 15 — то есть даже если три клетки в зоне format info замазаны или прокрашены неправильно, декодер всё равно вытянет верный уровень коррекции и маску.

Кодирование считается через порождающий полином

в двоичном виде — 10100110111. Алгоритм такой:

1. Берём 5 бит данных d = [EC level (2 бита)] [mask (3 бита)].
2. Сдвигаем влево на 10 позиций: получаем d · x^{10}.
3. Делим в GF(2) (по сути — длинное XOR-вычитание) на G(x), остаток — это 10 бит чётности.
4. Склеиваем: [5 бит данных] [10 бит остатка] = 15-битное кодовое слово.

Чтобы проверить целостность при чтении, декодер делает то же самое в обратную сторону: делит прочитанные 15 бит на G(x). Если остаток нулевой — ошибок не было. Если ненулевой — это синдром, по которому находятся испорченные биты. Для коротких BCH вроде нашего (всего 32 валидных слова, по числу комбинаций EC × mask) обычно держат готовую таблицу синдромов — это быстрее, чем гонять полный алгоритм исправления каждый раз.

Теперь становится понятно, зачем нужна XOR-маска 101010000010010. Без неё формат из одних нулей был бы валидным кодовым словом («EC level M, маска 0, нулевой остаток») — а это совпадает с пустой или замазанной белой областью QR. После XOR-а сплошные нули или единицы гарантированно дают невалидный синдром, и декодер не примет шум за легитимный формат.

И ещё деталь: те же 15 бит продублированы дважды, причём копии разнесены по разным углам — буква Г вокруг левого верхнего finder-а и полоска снизу от правого верхнего + справа от левого нижнего. Это страховка от случая, когда одна копия повреждена сильнее, чем BCH способен починить (больше 3 ошибок): декодер читает обе, считает синдром у каждой и берёт ту, что чище.

Шаг 3. Зигзаг и снятие маски

Биты данных читаются парами столбцов справа налево, зигзагом: пара (20, 19) — снизу вверх, пара (18, 17) — сверху вниз, и так далее, перепрыгивая тайминг-колонку №6. Внутри каждого ряда читается сначала правая клетка, потом левая. Все функциональные модули (finder, тайминг, format, dark) — пропускаются.

Видно, как поток идёт парами столбцов: красный (биты 1–2) внизу справа, поднимается вверх по правым двум колонкам до битов 15–16, потом перепрыгивает в следующую пару (зелёный, биты 17–32) и идёт вниз.

Каждый бит, прочитанный из решётки, XOR-им с маской 6: если для координаты (r, c) маска срабатывает — бит инвертируется.

После маскинга первые 4 байта получаются такими:

байт 1: 00100000  = 0x20
байт 2: 00010011  = 0x13
байт 3: 00001111  = 0x0F
байт 4: 00000000  = 0x00

Восемь масок и их формулы

Полный набор из стандарта — клетка (r, c) (строка, колонка) инвертируется, если выражение даёт true:

Маски устроены по-разному осмысленно: №0–№3 — простые «шахматные» / «полосатые» шаблоны, №4–№7 — более «шумные», с произведениями координат. Чем разнообразнее набор, тем больше шанс, что хотя бы одна из восьми разломает любой неудачный битовый рисунок в payload.

А выбирает кодировщик так: накладывает поочерёдно каждую из восьми масок на черновой код и считает штрафную функцию (penalty score). Штрафы накапливаются за длинные одноцветные полосы (5+ модулей подряд), за блоки 2×2 одного цвета, за паттерны, похожие на finder (1:1:3:1:1), и за дисбаланс чёрного и белого. Маска с минимальной суммой штрафов уходит в финальный QR. Поэтому маска №6 в нашем подопытном — не «любимая маска автора», а просто та, что для конкретного payload "HI" сложилась с минимальным penalty.

Шаг 4. Парсим payload

Первые 32 бита склеиваем в один поток и режем по логике формата:

0010 | 000000010 | 01100001111 | 0000
 ↑         ↑            ↑         ↑
 │         │            │         └─ терминатор «конец данных»
 │         │            └─ символы (11 бит на пару)
 │         └─ счётчик: 2 символа (9 бит для V1 alpha)
 └─ режим: 0010 = alphanumeric

Каждый payload в QR начинается одинаково: Mode Indicator (4 бита) + Character Count Indicator (CCI, ширина зависит от пары version+mode) + сами данные. Ширина CCI меняется ступеньками: для alphanumeric это 9 бит на V1–V9, 11 бит на V10–V26 и 13 бит на V27–V40. Сделано осмысленно: в маленьком V1 пол-байта не хочется тратить на нули перед длиной, а в большом V40 9 бит уже банально не хватит — туда влезает до 4296 alphanumeric-символов. Поэтому при ручном декодировании всегда первым делом смотришь на версию (размер сетки), и только потом — где у CCI заканчиваются биты.

Декодируем сами символы

Декодируем 11 бит данных: 01100001111 в десятичном = 783.

В alphanumeric-режиме два символа упаковываются как c1 × 45 + c2. Делим: 783 = 17 × 45 + 18. Таблица alphanumeric-алфавита: 0-9, A-Z, [space] $ % * + - . / : — итого 45 значений, отсюда и множитель.

• 17 → H
• 18 → I

Получили "HI".

Если бы строка была нечётной длины, последний символ кодировался бы отдельно — не 11, а 6 бит. Это полезно держать в голове: после CCI всегда сначала идут полные пары, а потом — возможно — «хвост» в 6 бит. Аналогично numeric-режим режется тройками по 10 бит, а одиночный/парный хвост — 4 и 7 бит соответственно. Стандарт педантично оптимизирует каждый бит: считает, что место в QR — это дорого.

Терминатор, padding и Reed-Solomon

Сразу за данными идёт терминатор 0000 — четыре нуля, говорящие «всё, payload закончился». По стандарту терминатор можно укоротить или вовсе выкинуть, если данные ровно дотягиваются до конца блока — но обычно его пишут целиком, и декодер на него ориентируется.

Дальше биты добиваются нулями до ближайшей границы байта, и потом блок данных заполняется до своей ёмкости чередующимися padding-байтами 0xEC (11101100) и 0x11 (00010001). Эти два конкретных значения зашиты в стандарте — выбраны они так, чтобы их битовый рисунок под любой из восьми масок ломал длинные одноцветные полосы и не складывался во что-то, похожее на finder-pattern (1:1:3:1:1). Поэтому если вытащил из кода строку «HI», а дальше пошло EC 11 EC 11 EC 11 ... — это не повреждение, это норма. И наоборот: если padding выглядит как-то иначе — где-то в зигзаге ошибся.

Для V1 с уровнем коррекции L общий размер блока — 26 codeword’ов (байт), из которых под данные отведено 19, а остальные 7 — это байты Reed-Solomon: код над полем GF(256), способный поднять до 3 искажённых байт на блок. Для нашего "HI" это значит: 4 уже прочитанных байта (20 13 0F 00) + 15 байт padding’а (EC 11 EC 11 ... EC) + 7 байт RS = ровно 26, полная ёмкость V1-L.

Раскручивать Reed-Solomon руками — занятие на отдельный пост: нужно считать синдромы, через алгоритм Берлекэмпа-Месси искать полином-локатор ошибок, потом Chien-search’ем — позиции, потом формулой Форни — значения, и всё это в арифметике GF(256). В декодере без ошибок RS-байты можно просто игнорировать — и в этом разборе мы именно так и поступим. Поднимется тема — вернёмся.

Режимы данных

Тонкие места, на которых легко споткнуться

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

• Забыл пропустить тайминг-колонку №6 в зигзаге. Самый популярный баг: пары столбцов должны «перепрыгивать» эту колонку, а не читать её клетки как данные. Если payload пошёл бредом с первого же байта — почти наверняка дело именно тут.
• Снял маску не только с данных. Маска накладывается исключительно на data + EC, то есть на зелёную зону. Finder, separators, тайминг, format info, dark module — не трогаем. Если случайно проинвертировал маской finder-патерны, дальше развалится всё, включая саму ориентацию.
• Перепутал порядок битов внутри пары столбцов. В зигзаге в каждой строке сначала правая клетка, потом левая. Прочитал наоборот — payload идёт зеркально по 2 бита, терминатор находится где-то в середине, и парсинг падает.
• Забыл, что зигзаг bounce-ит. Пары столбцов чередуют направление: (20, 19) — снизу вверх, (18, 17) — сверху вниз, (16, 15) — снова вверх. Это не «всегда снизу вверх», это «змейка». На стыках пар легко проскочить инерцией.
• Принял EC 11 EC 11 ... за продолжение данных. После терминатора 0000 идёт padding до конца блока данных. Если в декодированном байт-потоке после реального payload пошли повторяющиеся EC 11 — не пытайся их парсить как «следующее сообщение», это просто забивание блока до 19 байт (для V1-L).

Что с этим делать на практике

Чтобы из теории получилось ощущение «руками потрогал», самый рабочий заход — такой:

1. Сгенерируй V1 QR с заранее известным содержимым. Удобнее всего — через онлайн-демо Nayuki или через мой wifi-qr (для коротких SSID он как раз выдаёт V1–V2). Возьми короткую alphanumeric-строку: "HI", "OK", "TEST". Не забудь зафиксировать уровень коррекции (L) и номер маски — потом будет с чем сверять.
2. Распечатай крупно — A4 на 21×21 хватает с запасом. Альтернатива — нарисовать сетку на бумаге в клетку и закрасить модули вручную. Звучит занудно, но именно ручная отрисовка лучше всего ломает «магический квадратик» в голове.
3. Подсвети функциональные зоны карандашом или маркерами разных цветов: три finder-а, separators, обе тайминг-полоски, dark module, обе копии format info. После этого зелёная зона данных выделится сама собой.
4. Прочитай format info → XOR с 101010000010010 → выпиши уровень коррекции и номер маски. Сверь с тем, что задал в генераторе. Сошлось — значит, Шаг 2 ты понял правильно.
5. Обведи клетки, инвертируемые выбранной маской. Берёшь формулу из таблицы выше и проходишь по всей data-зоне: где условие — true, ставишь крестик. Эти клетки будешь инвертировать при чтении.
6. Пройди зигзагом первые 32 бита, для каждого инвертируй или нет в зависимости от маски, и распарси: 4 бита mode → CCI → данные. Должна получиться твоя исходная строка.

Когда «свой» QR разобрался — попробуй на чужом: возьми QR с любого чека из магазина или с Wi-Fi-стикера в кофейне. Только сразу проверь, что это V1 или V2 (для V1 сетка 21×21, для V2 — 25×25, считается по краю). На больших версиях ручной зигзаг быстро превращается в подвиг ради подвига.

Итог

Если потренироваться, то для маленьких QR (V1, alphanumeric, короткий текст) реально читать глазами за пару минут. Узкое горлышко — держать в голове маску и зигзаг, две операции, которые мозг плохо параллелит. Помогает распечатать QR на бумаге и фломастером заштриховывать клетки, которые маска инвертирует — после этого данные читаются «как обычный бинарный поток».

Алгоритм по шагам

1. Найти три finder patterns → определить ориентацию.
2. Прочитать format info → XOR с 101010000010010 → выделить EC level и mask number.
3. Применить маску к данным (XOR по формуле выбранной маски).
4. Прочитать биты зигзагом снизу-справа вверх, парами столбцов.
5. Распарсить: 4 бита режим → N бит счётчик → данные → терминатор.
6. (Опционально) проверить Reed-Solomon коды.

Дальше копать

• How to decode a QR code by hand — Robert Heaton — пошаговый разбор того же V1 «HI», только не моими словами. Хорошо для проверки себя: если в каком-то месте разошлись — значит, не до конца понял шаг.
• Thonky’s QR Code Tutorial — самый полный учебник в сети: все 40 версий, восемь масок с примерами, готовые таблицы для Reed-Solomon, разбор форматов. Если Heaton — обзорная статья, Thonky тянет уже на 30-страничный курс.
• nayuki/QR-Code-generator — каноническая референсная реализация на C/C++/Java/JS/Python/Rust. Читается как продолжение этого поста: чёткие имена, в комментариях — формулы из стандарта, никакой магии. У того же автора на nayuki.io лежит онлайн-демо с настраиваемой версией и маской — удобно сверять свои выкладки с эталоном.
• jtprogru/wifi-qr — мой собственный мини-проектик «с обратной стороны»: тащит WIFI_SSID и WIFI_PASSWD из .env и собирает Wi-Fi-QR в PNG одной командой make run. Внутри — крошечный Python-скрипт поверх библиотеки qrcode. Удобный мостик от «понимаю по битам» к «генерирую за секунду», заодно — готовый QR для гостевой Wi-Fi.
• zxing/zxing — production-grade декодер от Google, тот самый, который много лет крутился в Barcode Scanner на Android. Полезно посмотреть, чтобы понять разницу между «вытащить V1 в идеальных условиях» и «прочитать URL с мятого чека под углом 30° при тусклом свете».
• Reed–Solomon codes for coders на Wikiversity — лучший learn-by-doing разбор RS-кодов из всех, что попадались. GF(256), порождающие полиномы, синдромы, исправление ошибок — всё последовательно разложено по шагам, с примерами на Python. Без этой статьи в RS-кодах было сложно ухватиться хоть за что-то.
• QR code — Wikipedia — на удивление приличная обзорная статья: версии, режимы, история Denso Wave, лимиты по объёму данных, эволюция стандарта. Хорошо стартовать с неё, если QR в голове пока «магический квадратик».
• ISO/IEC 18004:2015 — сам стандарт. Платный, но если возишься со штрихкодами всерьёз — без него никак: только там нормально расписаны все 40 версий, все 4 режима кодирования и точные алгоритмы коррекции.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.

Привет, %username%! На системном дизайне 9 из 10 кандидатов начинают с компонентов: API gateway, Kafka, Redis, Postgres-реплики, шардинг, CDN. Это не дизайн — это плакат с логотипами. Дизайн начинается с вопроса, на который почти никто не отвечает первым: «какой надёжности я обещаю и почему именно этой, а не другой?».

Без числа в этом ответе — 99.5, 99.9, 99.99 — все архитектурные решения ниже становятся вопросом эстетики. С числом — превращаются в инженерные ограничения, которые решают за тебя, нужна ли вторая БД-реплика, имеет ли смысл repair-aware кэш и сколько регионов держать в active-active.

В этой статье я беру одну каноничную задачу с собеса — поиск каталога маркетплейса — и прокручиваю её сквозь три уровня SLO: 99.0%, 99.9%, 99.99%. На каждом уровне меняется не «настройка пары флагов», а сама архитектура. Главный тезис: SLI/SLO — это не SRE-декорация поверх готовой системы, а интерфейс между System Design и бизнесом. Тот самый, через который аналитик, бэкенд и SRE говорят на одном языке.

Что ты унесёшь из статьи

Статья длинная (~55 000 знаков), поэтому сразу — что заберёт каждая ЦА:

• Аналитик / продакт. Рамка для перевода бизнес-метрик в SLI и для разговора с инженерами в стиле «а если снизим SLO с 99.99% до 99.9% — что освободится?».
• Бэкенд-инженер. Как один и тот же поиск каталога превращается в три разные системы при смене таргета SLO — read path, кэш, индекс, failover.
• SRE / DevOps. Error budget как валюта в спорах «фича vs рефакторинг» + типовые ошибки выбора SLI: что делать, когда дашборд зелёный, а пользователи — в саппорте.

Общий блок для всех: разница между Observability, Monitoring и Alerting — в одной схеме.

TL;DR (если читать дальше уже некогда)

Если у тебя нет 30 минут на длинный разбор — четыре тезиса, к которым приходит статья:

1. SLO выбирается до архитектуры, а не после. Поднять SLO задним числом — это переписать систему, а не «добавить мониторинга». Снизить — освободить бюджет, но не вернуть деньги.
2. Один и тот же кейс на трёх SLO (99.0% / 99.9% / 99.99%) — это три разные системы. Меняется не «настройка флагов», а топология, технологии, capacity, RTO/RPO, операционная модель и стоимость (1× → 4–6× → 15–25× baseline).
3. SLI вешаются на шаги критичного пользовательского пути (CUJ), а не «на сервис в целом». «99.9% по системе» — это псевдо-метрика, которая прячет деградацию ключевого шага за здоровьем фоновых эндпоинтов.
4. Error budget работает как валюта в спорах «фича vs рефакторинг», только если есть записанная error budget policy. Без неё SLO — это график на дашборде, а не дисциплина.

Дальше — как до этих четырёх тезисов прийти через один сквозной кейс. Если интересует только инженерная кульминация — переходи сразу к разделу Один кейс — три SLO — три архитектуры .

Кейс: поиск каталога маркетплейса

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

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

Параметры — реалистичные для маркетплейса масштаба Ozon / Wildberries / Avito, но «приглаженные» под удобство арифметики:

Бизнес-контекст, про который часто забывают на собесе, и зря:

• Поиск — главный драйвер конверсии. По публичным отчётам (SimilarWeb, ContentSquare, материалы крупных маркетплейсов) на больших площадках 40–70% покупок начинается с поисковой строки, не с категорий или баннеров. Конкретный процент гуляет по сегментам и площадкам, но порядок одинаков. Любая деградация поиска — это прямая просадка GMV, не «инженерная неприятность».
• Эластичность по latency измерима. Цифры из публикаций Amazon (Greg Linden, 2006), Akamai (2017), Google/SOASTA (2017) и Deloitte (2020) разнятся по методологии и сегменту, но порядок сходится: каждые +100 ms latency на ключевом read path стоят примерно −0.5…1.5% конверсии. Для маркетплейса с GMV $10M в день это $50–150k недополученной выручки в день, если регресс закрепится. Это не разовый ущерб, а просадка, в которую конвертируется latency на ключевом read path.
• Стоимость недоступности нелинейна. 5 минут даунтайма обычным вторником и 5 минут даунтайма в Чёрную пятницу — это разные деньги в десятки раз. SLO должно учитывать сезонность, иначе оно меряет не то.

Эти три факта — ровно то, что превращает SLI/SLO из «инженерной гигиены» в инструмент бизнес-разговора. Я буду к ним возвращаться в каждом следующем разделе.

Что обычно ломается на собесе без SLO

Послушаешь сотню system-design интервью — и складывается узнаваемый паттерн ответа.

Типичная траектория

1. Уточнили требования. «Сколько пользователей? Какая нагрузка?» — кандидат услышал «много», и в голове щёлкнуло «значит, надо много всего».
2. Нарисовали API. REST с парой эндпоинтов, gateway, auth-middleware. Пока без сюрпризов.
3. Добавили слой данных. Postgres / MySQL — «реляционка для каталога норм». Кто-то сразу предложит Elasticsearch, потому что слышал про full-text search.
4. Поставили кэш. Redis — потому что «Redis fast». Без обсуждения, что именно кэшируем, какой hit rate ожидаем, как инвалидируем при изменении цены или остатков.
5. Подняли реплики. «На чтение пойдут реплики, на запись — мастер». Без обсуждения, насколько асинхронная репликация критична: а если пользователь не увидит свой только что выложенный товар?
6. Зашардировали. Чаще всего по category_id или seller_id. Потому что «у больших так».
7. Накинули CDN и очередь. Kafka — куда же без неё. Async-обработка событий, чтобы «развязать сервисы».

К концу интервью на доске — красивая распределённая система. Интервьюер кивает. Кандидат уверен, что справился.

Что в этой траектории не так

Простой тест. Ответь сам себе: какое из решений выше изменилось бы, если бы требование к доступности было 99.0%, а не 99.99%? А если бы P99 была не 500 ms, а 2 секунды?

Если ответ «никакое» — значит, дизайн не привязан к требованиям к надёжности. Кандидат строил систему «как принято», а не «как нужно бизнесу». А раз все решения принимались независимо от целевого SLO — значит, любые из них могут быть и преждевременными, и недостаточными одновременно. Точно сказать нельзя, потому что точки отсчёта нет.

Чтобы было совсем больно — разберём по решениям:

• Кэш Redis. Имеет смысл, если твой SLO по latency — десятки миллисекунд для горячих запросов или ты упираешься в нагрузку на БД при текущем availability-таргете. При расслабленном SLO P99 = 2 секунды кэш в read path — преждевременная оптимизация: ты поднимаешь эксплуатационную сложность (инвалидация, прогрев, репликация Redis-кластера, отдельный SLO на сам кэш) ради цели, которая выполнима и без него.
• Реплики на чтение. Имеют смысл, если твой SLO availability такой, что мастер-only архитектура не уложится в бюджет ошибок при типовом MTTR. На SLO 99.0% (~7 часов даунтайма в месяц) одного хорошо настроенного primary с мониторингом и быстрым backup-восстановлением часто достаточно.
• Шардинг. Оправдан, когда объём данных или write QPS упирается в один инстанс физически. До этого — это удвоение операционной нагрузки (rebalancing, hot shards, резолв cross-shard запросов) без выигрыша по SLI, ради которого его делают.
• Multi-region active-active. Имеет смысл при SLO availability 99.99%+ или когда регуляторика обязывает (data residency, ФЗ-149/ФЗ-152/ФЗ-242/GDPR-аналоги). На 99.9% обычно дешевле и предсказуемее active-passive с автоматическим failover и RTO в минутах.

Каждое из этих решений — правильное в одних условиях и преждевременное в других. Условия задаёт SLO. Без него ты выбираешь архитектуру не под задачу, а под насмотренность.

Главный сдвиг — направление дизайна

Хороший дизайн идёт сверху вниз: бизнес-цель → критичный пользовательский путь (CUJ, critical user journey) → SLI на каждый шаг этого пути → SLO как контракт → архитектура, которая в этот SLO укладывается с разумным запасом.

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

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

Шаг 1: от ФТ к критичному пользовательскому пути

Раз направление дизайна сверху вниз — нужна точка отсчёта на самом верху. Это функциональные требования (ФТ): что система делает в терминах пользователя и продукта. Не «использует Elasticsearch», а «возвращает релевантную выдачу по запросу».

ФТ для нашего кейса

• Принять поисковый запрос (текст + фильтры) от авторизованного и анонимного пользователя.
• Подбирать товары из активного каталога с учётом региона и доступной доставки.
• Ранжировать результаты с учётом релевантности, цены, рейтинга продавца и персонализации.
• Возвращать пагинированную выдачу с фасетами (категории, ценовые диапазоны, бренды).
• Поддерживать sorting (price asc/desc, popularity, rating).
• Подсказки и автодополнение по мере набора запроса.

Это всё одинаково «функциональные требования» — но не одинаково критичные. Если автодополнение тормозит на 200 ms, пользователь поморщится. Если выдача не приходит вовсе — он закроет вкладку и пойдёт к конкуренту. ФТ сами по себе плоские, в них нет приоритета. Этот приоритет приносит критичный пользовательский путь.

Критичный пользовательский путь (CUJ — critical user journey)

Это сценарий пользователя, который напрямую кормит ключевую бизнес-метрику. У маркетплейса бизнес-метрика — GMV, точка входа в неё — поиск, точка выхода — клик в карточку и далее в корзину. Получаем такой путь:

Пользователь приходит на сайт с намерением купить → формулирует запрос → получает релевантную выдачу → выбирает товар → переходит в карточку.

Это и есть «золотой путь», за который держимся в дизайне. Всё, что не обслуживает этот путь напрямую (статистика для аналитики, A/B-эксперименты, персональные рекомендации в стороннем виджете), может быть менее надёжным — и это нормально.

Декомпозиция пути на шаги

Дальше путь режется на дискретные шаги, каждый из которых станет отдельной точкой измерения:

Эти шесть шагов — каркас, на котором будет висеть всё дальнейшее. На каждый шаг повесим SLI, на каждый SLI — SLO. И увидим, что они не равноценны: шаг 4 (получение выдачи) для бизнеса принципиально важнее, чем шаг 2 (автодополнение). А значит, и инженерных усилий на их надёжность нужно несоизмеримо больше.

Почему это важно: ловушка «среднего по системе»

На многих собеседованиях кандидат, отвечая на «какую ты доступность хочешь», говорит «99.9% по системе». Это бесполезное число: если оно посчитано как «суммарный аптайм всех эндпоинтов», оно скрывает то, что выдача упала на 30 минут, а суммарно «вышло 99.9%, потому что autocomplete и health-чеки крутились». Пользователь страдал, дашборд зелёный.

Шаги критичного пути — антидот этой ловушки. Каждый шаг получает свою цифру, и провал шага 4 невозможно «размазать» доступностью соседних шагов.

Шаг 2: НФТ как свойства шагов, а не системы

Когда есть карта шагов, нефункциональные требования (НФТ) перестают быть размытым «надёжно, быстро, безопасно». Они становятся набором конкретных свойств каждого шага.

Свойства, которые нас интересуют

Для read-heavy критичного пути маркетплейса базовый набор НФТ выглядит так:

• Латентность. Сколько миллисекунд занял шаг. Меряем перцентилями (P50/P95/P99), не средним — оно скрывает хвосты, а хвосты и есть пользовательская боль.
• Доступность. Доля успешных шагов. Не «200/всего HTTP», а именно «шаг выполнен корректно с точки зрения сценария».
• Корректность. Получил ли пользователь ожидаемый результат. Для шага 4 — вернулась ли релевантная выдача или 0 результатов из-за бага в ранжировании.
• Свежесть. Насколько актуальны данные. Цена и наличие на карточке после клика — критичная свежесть; popularity-score в ранжировании — терпит часовую задержку.
• Целостность. Не «исчезает» ли часть результатов из-за частичного сбоя ноды или таймаута к шарду. Это специфично для распределённого поиска и шардированных индексов.

Привязка свойств к шагам пути

Не каждое свойство одинаково важно на каждом шаге. Покажу таблицей, какие НФТ для каких шагов нашего кейса критичны:

Сразу видно: шаг 4 — концентратор НФТ, на нём горят почти все колонки. Шаг 6 особенно требователен к свежести — потому что показать пользователю карточку с «вчерашней» ценой (а на чекауте уже другая) — это худший UX и часто прямой ущерб бизнесу через возвраты и репутацию.

Главное смещение от привычных НФТ из ТЗ

Классические нефункциональные требования — «система должна обеспечивать 99.9% доступности» — это средневзвешенное по чему попало. Они одинаково оценивают и autocomplete, и финальную выдачу. В реальной эксплуатации это приводит к двум симметричным болям:

1. Деньги тратятся не туда. Команда вкладывает усилия в надёжность шагов, которые этого не требуют (autocomplete с 99.99% — приятно, но конверсию не трогает), а критичные шаги остаются на «общем уровне».
2. Алерты молчат, когда болит. Дашборд показывает зелёный «99.9% по системе», пока шаг 4 деградирует и теряет каждую десятую выдачу. Эту потерю топит «здоровье» десятка других эндпоинтов и фоновых хелсчеков.

НФТ-по-шагам убирают эту усреднённость. Следующий шаг сверху вниз — превращаем эти свойства в измеримые SLI, чтобы было что мерить и за что отчитываться. Но прежде чем давать формулу — нужен общий словарь, без него разговор про SLI получится поверхностным.

Шаг 3: SLI как индикатор пользовательского опыта

Сначала — общий словарь: Observability ≠ Monitoring ≠ Alerting

В SRE-практике три термина часто валят в одну кучу, и тогда любой разговор про SLI разваливается на терминологические уточнения. Развожу их через цель каждой практики:

• Monitoring (мониторинг) отвечает на заранее заданные вопросы. Ты знаешь, что хочешь видеть: «жив ли primary», «какая P99 у эндпоинта /search», «не растёт ли latency». На каждую заготовку — метрика или дашборд. Это про known unknowns — вещи, о которых ты знаешь, что они могут пойти не так, и хочешь их видеть.
• Observability (наблюдаемость) — свойство системы, которое позволяет дойти до нового вопроса. Не «жив ли primary», а «почему именно в этом конкретном запросе latency 4 секунды». Высокая observability означает, что у тебя достаточно данных (метрик, структурированных логов, трейсов с tail-based sampling, событий) и инструментов поверх них, чтобы задать системе вопрос, который ты не предусмотрел заранее. Это про unknown unknowns — про неожиданности, которых ты не ждал. Такое разведение «monitoring = known unknowns / observability = unknown unknowns» — рамка из «Distributed Systems Observability» Cindy Sridharan (O’Reilly, 2018) и развитая инженерами Honeycomb (Charity Majors et al.); внутри Google SRE Workbook грань между ними размытее, и я сознательно беру более жёсткую формулировку — на ней легче строить дизайн.
• Alerting (алертинг) — действие по событию. Это слой, надстроенный над мониторингом и observability: правила, которые превращают наблюдаемое состояние в инцидент с пейджингом. Алерт — это не метрика, это обещание разбудить человека, и за него надо отвечать. Alert fatigue — отдельная боль, и лечится она burn-rate-алертами, а не увеличением количества правил.

Связь между ними — на одной схеме:

В этой триаде SLI — это специально выделенные метрики из мониторинга, которые отражают пользовательский опыт. SLO — правило поверх SLI, которое мы хотим выполнять. Алерты по burn-rate — правила поверх SLO. Observability — страховка на случай, когда SLO сгорает, и нужно понять, почему именно сейчас и в этом запросе. Иначе говоря: мониторинг, SLI и SLO живут в плоскости «всё ли в порядке по тем критериям, которые мы назначили». Observability — в плоскости «что именно сейчас не так и почему», когда привычные метрики не дают ответа.

Теперь, с этим словарём — переходим к самому SLI.

Что такое SLI

SLI (Service Level Indicator) — измеримая характеристика, которая отражает качество одного аспекта обслуживания пользователя. Ключевое слово — отражает. SLI меряет не «что система делает», а «насколько хорошо это видит пользователь».

Каноническая формула SLI — доля «хороших» событий от всех релевантных:

Что такое «хорошее событие» и какие события «релевантны» — определяется явно, иначе SLI получится бесполезным. Самая частая ошибка здесь — посчитать «все HTTP 2xx» как «хорошие». Так делать нельзя по двум причинам:

1. Не все 2xx одинаковы. Запрос, ответивший 200 OK за 5 секунд, формально успешен, но для пользователя это провал. SLI должен учитывать порог по латентности, иначе он маскирует деградацию.
2. Не все запросы одинаковы. Health-чек с другого сервиса тоже летит как HTTP-запрос, но на пользовательский опыт не влияет. Если он попал в знаменатель — SLI размылся.

Формат хорошего SLI

У хорошего SLI всегда три явные части:

• Числитель. Что считаем «хорошим» — порог по времени, корректности, объёму. Должно быть ясно, что туда входит, а что нет.
• Знаменатель. Какие события считаем релевантными — фильтр по эндпоинту, источнику трафика, типу запроса. Должно быть ясно, какие исключаем.
• Окно агрегации. За какой период считаем — 5 минут для алертов, 30 дней для отчётности. Без окна SLI — не число, а описание формы.

Конкретные SLI для нашего кейса

Возьмём ключевые шаги из таблицы НФТ и сформулируем для них SLI. Останавливаюсь на четырёх — этого достаточно, чтобы показать механику; в реальном проде их обычно 4–8 на сервис.

SLI-1 — Latency-SLI на шаге 4 «получение выдачи».

Доля поисковых запросов, на которые система ответила за время < 500 ms, от всех релевантных поисковых запросов с пользовательского трафика, за окно 30 дней.

• Числитель: запросы с status in {200, 204} AND request_duration < 500 ms.
• Знаменатель: запросы с status in {200, 204, 5xx} плюс таймауты, исключая 4xx-валидационные ответы (всё, что не health-check, не synthetic-проба, не вызов внутреннего сервиса).
• Окно: 30 дней rolling.

Заметь две вещи. Во-первых, 5xx в знаменателе: не учитывать их — значит нарисовать оптимистичную картинку, в которой провал «технически не считается». Во-вторых, 4xx-ответы пользовательского трафика в знаменатель не идут — по канонической Google SRE-практике (глава «Service Level Objectives» в SRE Workbook, O’Reilly, 2018) это корректное отвержение невалидного запроса (например, поисковая строка пустая или превышает лимит длины), система отработала ожидаемо. Включать их в знаменатель — раздуть его и сделать SLI оптимистичнее, чем он есть на самом деле.

SLI-2 — Availability-SLI на шаге 4.

Доля поисковых запросов, завершившихся успешно (не 5xx, не таймаут), от всех релевантных запросов, за окно 30 дней.

Это «классическая» availability. Но смотрим только на пользовательский трафик в шаг 4, не «по системе целиком». Знаменатель тот же, что у SLI-1, — 4xx-валидационные ответы исключены.

SLI-3 — Correctness-SLI на шаге 4.

Доля поисковых запросов, вернувших непустую и валидную выдачу, от всех запросов, для которых должна была быть хотя бы одна позиция (не 0-result-by-design).

Этот SLI сложнее, потому что нужно знать «должна была быть выдача или нет». Меряется офлайн-сэмплингом: берём X% запросов, прогоняем эталонный поиск, сравниваем долю «должно быть, но не было».

SLI-4 — Freshness-SLI на шаге 6 «клик в карточку».

Доля переходов в карточку, на которых цена и наличие отображены не старше 60 секунд от истинного состояния товара.

Этот SLI напрямую защищает от ситуации «увидел одну цену в выдаче — на чекауте другая». Без него ты рискуешь не техническим инцидентом, а репутационным: пользователь зол, возвраты растут, рейтинг продавцов падает.

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

Что мы НЕ берём как SLI

Контрпримеры, чтобы калибровать чутьё:

• CPU/Memory utilization. Это служебный сигнал, а не SLI. Пользователь не страдает от того, что у тебя CPU 80% — он страдает только если это превратилось в latency или 5xx. Утилизация — причина, SLI — следствие.
• Количество подов в реплике. Тоже служебный. Метрика для capacity planning, не для SLO.
• Среднее время ответа. Опасный «псевдо-SLI». Скрывает хвосты — а хвосты это и есть пользовательская боль. Только перцентили: P95 как минимум, P99 для критичных шагов.

Дальше — превращаем SLI в обещание самим себе. То есть в SLO.

Шаг 4: SLO как контракт и error budget математически

SLO (Service Level Objective) — целевое значение SLI на оговорённом окне. Если SLI отвечает на вопрос «как было», то SLO — «как мы обещаем, что должно быть».

Формула:

Где T — таргет (например, 99.9), W — окно агрегации (например, 30 дней rolling).

SLO для нашего SLI-1

Берём SLI-1 (latency-SLI поиска: доля запросов < 500 ms):

SLO: 99.9% поисковых запросов отвечают быстрее 500 ms на rolling-окне 30 дней.

Это полноценный контракт. И он автоматически рождает error budget.

Error budget математически

Error budget — это разрешённая доля «плохих» событий за период:

Для SLO 99.9% это 0.1%, или 1 «плохой» запрос из 1000.

Дальше переводим в абсолютные значения. Берём типовой день нашего маркетплейса:

• Пиковый RPS: 30 000 запросов/сек.
• Средний по дню (с учётом ночи): ~10 000 запросов/сек.
• Запросов в сутки: 10 000 × 86 400 ≈ 864 000 000.
• Запросов за 30-дневное окно: ~26 миллиардов.
• Допустимая доля «плохих» при SLO 99.9%: 0.1%.
• Бюджет ошибок за 30 дней: ~26 миллионов запросов.

Если перевести в эквивалент простоя — двумя срезами, на пике и при средней нагрузке за сутки:

Две колонки — потому что бюджет ошибок «горит» неравномерно. На пике RPS ты расходуешь запросы в три раза быстрее, чем в среднем по суткам, — поэтому инцидент в Чёрную пятницу обходится сильно дороже, чем тот же инцидент во вторник в 4 утра. Колонка «На пике» — про худший случай, на который надо проектировать SLO; колонка «При средней нагрузке» — про календарный «эквивалент полного простоя», который чаще видят в отчётах.

Это не просто разные числа — это разные физические возможности. На пике 8.7 секунд в месяц означают, что человек не успеет даже заметить пейдж: реакция должна быть автоматической. 7 часов в месяц при средней нагрузке — означают, что можно позволить себе ручной разбор каждого инцидента.

Что error budget значит на практике

Бюджет — не «допустимый ущерб», а бюджет на риск. На него тратятся:

• Деплои. Каждый релиз — ставка из бюджета. Откат + время на восстановление = израсходованные ошибки.
• Эксперименты. A/B-тесты, постепенный rollout, фиче-флаги — потенциальные источники регрессии.
• Учения. Game days, chaos engineering, плановые отказы — расходуют бюджет, но взамен дают уверенность в стабильности на реальных инцидентах.

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

К теме «бюджет как валюта в спорах» вернусь в разделе про error budget как арбитр. Сейчас важно зафиксировать одно: SLO без error budget — это пожелание, а не контракт. Бюджет — то, что превращает SLO из табло в инструмент принятия решений.

Дальше — главный технический разбор статьи. Берём один и тот же поиск маркетплейса и прокручиваем сквозь три уровня SLO: 99.0%, 99.9%, 99.99%. Покажу, что меняется в архитектуре, что — в стоимости, что — в эксплуатационной нагрузке.

Один кейс — три SLO — три архитектуры

Дальше беру тот же поиск маркетплейса с теми же параметрами и проектирую три разные системы. Меняется структура read path, выбор технологий, capacity, RTO/RPO, эксплуатационная модель. Остаётся постановка задачи, объём каталога (50M), пиковый RPS (30k), 5 регионов, 70% mobile.

Структура каждого подраздела одинаковая: бюджет → схема read path → числа (capacity, RTO/RPO, кэш, индекс) → что добавилось по сравнению с предыдущим уровнем и зачем → чего намеренно НЕ делаем.

SLO 99.0%: «дешёвая надёжность» для не-критичных сценариев

Бюджет: ~260M «плохих» запросов за 30 дней, или ~2 ч 24 мин полного даунтайма на пике / ~7 ч 13 мин при средней нагрузке. Почти полный рабочий день на инциденты в месяц — много, но выживаемо при ручной операционной модели.

Когда уместно: внутренние инструменты, ранний MVP стартапа, неосновные feature-paths в большом продукте (например, search в каталоге сторонних услуг, не кормящий основную конверсию).

Read path:

Числовые прикидки:

• Capacity. 30k RPS пика → при 99.0% можно потерять ~300 запросов/сек без нарушения SLO. Один хорошо настроенный Postgres primary с trigram-индексом на title/description тянет 1–3k RPS read на сложных запросах с фильтрами и фасетами, до 5–8k RPS — на простых коротких запросах с маленькой выборкой (P99 < 200 ms, при правильном connection pooling). Read replica удваивает чтение, итого ~2–15k RPS в зависимости от профиля. На пике 30k ты либо урежешь long-tail запросы кэшем приложения, либо примешь деградацию — бюджет позволяет.
• Кэш. In-memory LRU на каждом app-инстансе, размер ~256 MB. Hit rate 30–40% на популярных запросах. Без Redis — отдельный сервис добавил бы операционную сложность, нерелевантную для этого SLO.
• Полнотекстовый индекс. pg_trgm + tsvector поверх 50M товаров занимают 3–5× от размера индексируемых текстовых полей (title, description, attributes-text). Для нашего каталога с расширенными текстовыми атрибутами это порядка 1.5–2.5 TB индексов. Реалистично на одной мощной машине (NVMe, 256 GB RAM).
• RTO. До 30–60 минут на ручной failover на реплику. Автоматизации нет — стоит отдельный сервис.
• RPO. До 5 минут (типовая асинхронная репликация Postgres).
• Алерты. На симптомы: 5xx-rate, P99 latency, replication lag. Реакция оператором, не автоматическая remediation.

Почему этого достаточно — счёт по бюджету. Бюджет 99.0% — это ~7 часов даунтайма в месяц при средней нагрузке. Типовой худший случай выхода из строя primary с восстановлением из pg_basebackup + PITR — 30–90 минут от пейджа до возобновления read path (включая ручное переключение приложений на реплику и прогрев кэша). Даже два таких инцидента в месяц съедают ~3 часа — это меньше половины бюджета. Платить за синхронную репликацию, автоматический failover-tooling (Patroni / RepMgr / Stolon) и дежурную команду, способную их обслуживать, на этом уровне SLO нечем: бюджет покрывает ручной MTTR с большим запасом. На 99.9% этого запаса уже нет — отсюда и Active-passive failover на следующем уровне.

Что намеренно НЕ делаем:

• Не поднимаем Elasticsearch — он добавит +1 систему-источник истины, требующую отдельного индексирования, мониторинга и SLO. На 99.0% это лишний оверхед.
• Не делаем шардинг — одна машина с 256 GB RAM в 2025 году утаскивает 50M документов с trigram-индексом без проблем.
• Не делаем multi-region даже active-passive. Бюджет 7 часов покрывает любой региональный инцидент с ручным восстановлением.

Стоимость: обозначу как 1× baseline для последующего сравнения.

SLO 99.9%: рабочий production-уровень

Бюджет: ~26M «плохих» запросов за 30 дней, или ~14 мин 27 с полного даунтайма на пике / ~43 мин 20 с при средней нагрузке. На инцидент при средней нагрузке остаётся минут 20–30 — хватает на автоматический failover, но не на ручной разбор каждого 5xx.

Когда уместно: основные пользовательские пути в среднем e-commerce, обычный production. Большинство сервисов в индустрии живут в этом диапазоне.

Read path:

Числовые прикидки:

• Capacity. 30k RPS пика → допустимо терять ~30 запросов/сек. На Elasticsearch при 50M документов и 6 primary shards × 1 replica (~33 GB на шард, в коридоре best-practice 30–50 GB): запрос идёт в координатор, координатор делает fan-out на 6 шардов, агрегирует. Целевая нагрузка 30–40k RPS с запасом. На 8–12 ES-нодах (64–128 GB RAM каждая) держится с P99 в районе 300–400 ms чистого ES-времени.
• Кэш Redis. Кластер на 3–6 нодах, ~50 GB под топовые запросы и autocomplete. Hit rate 65–75% — ключевой множитель: при 70% hit rate на ES падает только 30% от 30k RPS, то есть ~9k RPS. Это уже посильно для умеренного ES-кластера. Прогрев после деплоя — 5–10 минут на горячих топ-1000 запросах.
• Индексирование. Postgres → Debezium / собственный CDC → Kafka → потребитель в ES. Lag индексирования: 15–60 секунд на типовых изменениях, 2–5 минут на массовых обновлениях цен (например, при загрузке от продавца XML-фида). Это freshness-SLI — ценник старше 60 секунд считается «плохим событием» по SLI-4.
• Структура документа и размер индекса. Каждая карточка в ES — денормализованный документ: title, description, attributes (10–20 полей), price, stock, seller_rating, geo, popularity. Размер ~3–5 KB на документ. 50M × 4 KB = ~200 GB primary + 200 GB replica = 400 GB Lucene-данных. На 12 нодах ≈ ~33 GB на ноду, рабочее множество легко помещается в RAM.
• Failover. Active-passive между двумя AZ внутри региона. RTO 1–3 минуты через автоматический promote secondary. RPO ~30 секунд через CDC.
• Алерты. Multi-window multi-burn-rate: две пары окон со своими threshold — быстрая пара 5 мин + 1 час с burn-rate 14.4× (срабатывает на острый инцидент за минуты, 2% бюджета за час) и медленная пара 30 мин + 6 часов с burn-rate 6× (ловит «тихую» деградацию, 5% бюджета за 6 часов). Это табличные значения из главы Alerting on SLOs в Google SRE Workbook. Подробно про burn-rate как множитель — в моей предыдущей статье «Скорость сгорания бюджета ошибок» .

Что добавилось по сравнению с 99.0%:

• Отдельный поисковый индекс (ES) — потому что pg_trgm на 30k RPS + ranking + facets уже не вытянет с нужной P99.
• Redis-кластер — без него ES под пиком пришлось бы масштабировать в 3–4 раза.
• CDC + Kafka — из-за разделения source of truth и поискового индекса нужна асинхронная синхронизация. Это новый слой риска (lag, потеря событий) и новый SLO на freshness.
• Active-passive failover — потому что 43 минуты бюджета мало для ручного переключения.
• Burn-rate-алерты — потому что классические «5xx > 1%» при 0.1% бюджета будут срабатывать слишком поздно или генерить шум.

Что намеренно НЕ делаем:

• Не делаем active-active multi-region. На 99.9% это избыточно: один регион с грамотным failover между AZ покрывает бюджет с большим запасом, а active-active добавляет проблем синхронизации (split-brain, write-write конфликты, кросс-региональные чтения по сети).
• Не делаем repair-aware кэш — на 99.9% достаточно правильного TTL и event-driven invalidation.
• Не делаем graceful degradation на уровне UI («поиск работает, ranking упал»). Это усложнение, оправданное на 99.99%+.

Стоимость: 4–6× baseline в инфраструктуре, 2–3× baseline в людях (нужна команда SRE с дежурствами, отдельные процессы для Kafka и ES).

SLO 99.99%: дорогая надёжность для tier-1 сценариев

Бюджет: ~2.6M «плохих» запросов за 30 дней, или ~1 мин 27 с полного даунтайма на пике / ~4 мин 20 с при средней нагрузке. На инцидент остаются секунды-минуты — реакция должна быть автоматической. Ручной разбор перед remediation = превышение бюджета.

Когда уместно: tier-1 пользовательские сценарии в крупном бизнесе уровня Ozon/Wildberries или сопоставимого по GMV, где минута даунтайма стоит сотни тысяч долларов и оправдывает мультипликатор инфраструктуры. Платёжные шлюзы, биржи, ключевые поисковые сценарии больших маркетплейсов.

Read path:

Числовые прикидки:

• Capacity. 30k RPS пика делятся между 3 регионами ~по 10k RPS нормально. Но каждый регион должен один переварить 100% трафика при отказе двух других — то есть sized под 30–40k RPS. Это утроение инфраструктуры по сравнению с одним регионом 99.9%, плюс запас.
• Кросс-региональная синхронизация индексов. ES → Kafka MirrorMaker (или managed cross-region streaming) → ES в каждом регионе. Lag 5–30 секунд между регионами в нормальном режиме, 1–3 минуты при региональной сетевой деградации. Eventually consistent модель данных — для поиска приемлемо, для цен/наличия (freshness-SLI) — узкое место, требующее отдельной стратегии (часто — fetch цены при клике в карточку из локального region-БД).
• Repair-aware кэш. Когда регион вышел из деградации и снова healthy, кэш в нём может содержать «грязные» ключи — данные, менявшиеся в других регионах, но не доехавшие. Решение: каждый ключ в кэше помечен суффиксом версии данных (hash или LSN); при возврате региона — проактивный прогрев топовых ключей со свежими версиями. Это отдельный сервис, обычно in-house.
• Graceful degradation. Если ranking-сервис упал — поиск отдаёт базовое ранжирование (popularity + recency) без персонализации. Если упал autocomplete — прячем подсказки, оставляя ввод. Если упал ES — отдаём кэш-результаты + предупреждение «возможно, не самые свежие». Каждый из этих режимов — отдельный код-path и отдельный SLI.
• Failover. Автоматический на уровне geo-anycast / global LB, RTO 5–30 секунд на регион. Health-чеки агрегируют SLI критичного пути, а не пинг сервера.
• RPO. Околонулевой для критичных данных (заказы, корзина) через synchronous replication между двумя регионами + async на третий. Для каталога/индекса — до 1 минуты.
• Алерты. Multi-window multi-burn-rate с поджатыми окнами: быстрая пара 2 мин + 1 час с threshold 36× (для tier-1 порог берут агрессивнее, чем 14.4× — иначе быстрый алерт догонит инцидент уже после исчерпания бюджета) + медленная пара 15 мин + 3 часа с threshold ~10× для затяжной деградации. Auto-remediation для известных классов: автоматический drain региона при превышении burn-rate, автоматический rollback деплоя.

Что добавилось по сравнению с 99.9%:

• Multi-region active-active — потому что 1 минута 27 секунд бюджета на пике не покрывают ни один региональный инцидент (4 мин 20 с в среднем — тоже).
• Repair-aware кэш — потому что после возврата региона данные могут разойтись, и без проактивного прогрева накопится freshness-долг, съедающий SLI-4.
• Graceful degradation — потому что без неё любой отказ зависимости (ranking, persona) забирает весь бюджет.
• Auto-remediation — потому что человек физически не успевает посмотреть пейдж за 1 мин 27 с пикового бюджета, не то что разобраться.
• Канареечный rollout с автоматическим откатом по burn-rate — каждый деплой иначе ставит весь бюджет.

Что намеренно НЕ делаем (и здесь это особенно важно):

• Не идём в 99.999% без очень сильного бизнес-обоснования. 26 секунд в месяц требуют существенно более сложной модели резервирования, чем 99.99%: multi-cloud или multi-provider, независимые DNS, частично независимые кодовые базы, подходы из telecom/aerospace. Это часто дешевле решить через UX — например, кэшированием выдачи на клиенте на минуту, чтобы из 100% даунтайма пользователь увидел только новые сессии.

Стоимость: 15–25× baseline в инфраструктуре, 8–10× baseline в людях (24/7 SRE, регулярные game days, отдельная команда reliability engineering).

Сводная таблица: SLO как бюджет на сложность

Главный вывод раздела

Один и тот же кейс на трёх SLO — это три разные инженерные задачи. Не «та же задача с разными настройками», а с разной топологией, разными технологиями, разной операционной моделью, разной стоимостью.

Из этого следуют две вещи, которые часто упускают:

1. Поднять SLO задним числом — это переписать систему, а не «добавить мониторинга». Если архитектура построена под 99.0%, поднять её до 99.99% означает: добавить регионы, переписать индексирование под cross-region, ввести graceful degradation, перепроектировать кэш. Не «настройка пары флагов» — рефакторинг порядка половины кодовой базы.
2. Снизить SLO задним числом освобождает бюджет, но не возвращает потраченных денег. Если ты построил под 99.99%, а реально нужно 99.9% — лишний регион уже куплен, репликация уже настроена, команда SRE уже нанята. Снижение SLO в этом случае имеет смысл только перед следующим циклом капекса.

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

SLA: что уходит наружу

Третий и последний термин «троицы» — SLA (Service Level Agreement). Это контракт с пользователем (или клиентом, партнёром, регулятором), оформленный обычно юридически, с финансовыми санкциями за нарушение.

Принципиальное отличие от SLO:

Главное правило: SLA ≤ SLO − запас

Самая частая ошибка — поставить SLA равным SLO. Например, инженеры обещают себе 99.99%, и юристы пишут пользователю «гарантируем 99.99%». В этом случае любое попадание в нижнюю границу SLO — уже автоматически нарушение SLA.

Правильно: между SLO и SLA должен быть запас, обычно один-два разряда 9.

• SLO 99.99% → SLA 99.9% или 99.95%.
• SLO 99.9% → SLA 99.5%.

Запас не стоит ничего — это просто разница между «что мы хотим внутри» и «что мы готовы юридически защищать снаружи».

И ещё одно важное

SLA пишется не на ту же метрику, что SLO. SLA обычно — это availability в чистом виде (грубое «отвечает / не отвечает»). SLO — набор тонких индикаторов (latency, freshness, correctness). Ты внутри живёшь на сложной картине из 4–8 SLI, наружу выдаёшь одну простую цифру с запасом.

Golden Signals, RED, USE — какую призму брать и когда

Кейс выше показал три разные системы под три SLO. Прежде чем переходить к разговору про error budget как арбитр в спорах, важно понять — а каким набором метрик мы вообще смотрим на эти системы. В SRE-сообществе живут три популярных набора-призмы для метрик:

• Golden Signals — Latency, Traffic, Errors, Saturation. Универсальный набор для пользовательских сервисов. Введён Rob Ewaschuk и закреплён в Google SRE Book (глава «Monitoring Distributed Systems», O’Reilly, 2016).
• RED — Rate, Errors, Duration. Подмножество Golden Signals, ориентированное на запрос-ответные сервисы. Введён Tom Wilkie (Weaveworks, ныне Grafana Labs) в докладе «The RED Method» (2017).
• USE — Utilization, Saturation, Errors. Для ресурсов: CPU, диск, память, сеть. Введён Brendan Gregg в «Systems Performance» (2-е изд., 2020) и серии постов на brendangregg.com (2012+).

Эти призмы часто валят в одну кучу и спорят, какая «правильная». Спор бессмысленный — они отвечают на разные вопросы.

Golden Signals — самая полная призма для сервиса

Если ты только начинаешь и не знаешь, что меряет — начни с Golden Signals на каждый твой сервис:

• Latency. Сколько времени занял успешный запрос (отдельно — неуспешный, потому что медленный 500 искажает картину).
• Traffic. Сколько запросов обрабатываем (RPS, qps, events/sec).
• Errors. Доля «плохих» — 5xx, таймауты, протокольные ошибки, неуспешные заказы.
• Saturation. Насколько ресурс заполнен — очередь, пул соединений, утилизация worker-ов.

В нашем кейсе для search-сервиса Golden Signals разворачиваются так:

• Latency: P50/P95/P99 на эндпоинт /search, разбитые по типу запроса (autocomplete vs full search).
• Traffic: RPS на /search, отдельно по регионам.
• Errors: доля 5xx + таймаутов к ES + ошибок ranking-сервиса.
• Saturation: размер очереди в Kafka-consumer индексирования, пул коннектов в ES, hit rate Redis.

Эти четыре сразу дают верхнеуровневую картину здоровья сервиса. SLI ты выбираешь из них (обычно — Latency и Errors), но мониторить нужно все четыре.

RED — тот же набор, проще запомнить

RED (Rate, Errors, Duration) — это Golden Signals минус Saturation. Удобный мнемоник, особенно для request/response-сервисов: каждый эндпоинт обязательно имеет три метрики и хотя бы один дашборд по ним.

Когда брать RED вместо Golden Signals: если ты делаешь дашборд per-endpoint в большом сервисе и не хочешь ставить четыре графика на каждый эндпоинт. Saturation — ресурсная метрика, и она часто живёт отдельно (на дашборде ресурсов или инфраструктуры), а не на дашборде эндпоинтов.

USE — призма для ресурсов, не для сервисов

USE (Utilization, Saturation, Errors) — про ресурс, не про сервис. Когда мерить:

• CPU — utilization = % busy, saturation = run queue, errors = throttling.
• Диск — utilization = busy time, saturation = await, errors = bad sectors / IO errors.
• Сеть — utilization = bandwidth %, saturation = drops, errors = retransmits.
• Пул соединений — utilization = used/max, saturation = очередь ожидания, errors = таймауты.

USE — для диагностики, не для SLO. Никогда не делай SLO на CPU utilization напрямую — это служебный сигнал. Но USE-метрики бесценны, когда burn-rate-алерт сработал и нужно быстро понять, где в стеке давит.

Когда какую призму брать — простое правило

Главное смещение

Призмы не противоречат — они дополняют. У зрелой команды есть все три уровня дашбордов:

• Верхний — Golden Signals + дашборд SLI/SLO с burn-rate. Заходишь и сразу видишь, всё ли в порядке с пользовательским опытом.
• Средний — RED по эндпоинтам. Заходишь, когда верхний показывает деградацию, и видишь, какой эндпоинт вносит вклад.
• Нижний — USE по ресурсам. Заходишь, когда RED показывает, какой эндпоинт болит, и нужно понять, в каком ресурсе упёрлись.

Error budget как арбитр в спорах «фича vs рефакторинг»

Самый недооценённый эффект от грамотного SLO — это не алерты и не отчёты. Это то, что бюджет ошибок становится валютой в архитектурных спорах, и решения принимаются на цифрах, а не на ощущениях.

Классический спор без бюджета

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

Продакт: «Нам нужно срочно выкатить персонализированную выдачу до Чёрной пятницы».
SRE: «Мы только что прошли через два инцидента из-за деплоя. Я хочу заморозить деплои на неделю и провести post-mortem».
Продакт: «Каждая неделя задержки — это $500k недополученной выручки».
SRE: «Каждый инцидент — это репутация».

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

Тот же спор с бюджетом

Продакт: «Хочу выкатить персонализацию до BF».
SRE: «Бюджет на этот месяц — 26M запросов. За последние две недели мы сожгли 22M на двух инцидентах. У нас осталось 4M на оставшиеся 16 дней. Вот burn-rate-график за неделю».
Продакт: «Сколько бюджета съедает выкатка персонализации?»
SRE: «По прошлым выкаткам сопоставимого риска — медианно 3–4M запросов на постепенный rollout. То есть канарейка съест от 75% до 100% оставшегося бюджета. Если что-то пойдёт не так — превышаем SLO до конца окна».
Продакт: «Сколько ждать, пока бюджет восстановится?»
SRE: «Окно rolling, считается на последних 30 днях — каждые сутки самые старые сутки выпадают, новые входят. Самые тяжёлые инциденты были 28 и 25 дней назад: через 2–5 дней они выпадут из окна, и мы откатимся к ~10M свободного бюджета без всяких новых усилий».
Продакт: «До BF — 24 дня. Подождём 5 дней, потом выкатываем канарейку — рискуем уже на восстановленном бюджете, а не на остатках от инцидентов».

Спор кончился за 5 минут, без эмоций, на цифрах. Это и есть «бюджет как валюта»: он переводит инженерное «надо подождать» и продуктовое «надо быстрее» в единицу измерения, значимую обеим сторонам.

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

Что разрушает «бюджет как арбитр»

• Несогласованный SLO. Если бюджет в глазах продакта — «инженерная штука», он не примет его как аргумент. SLO нужно согласовывать с продуктом, а не объявлять.
• SLO без явного оперативного следствия. Если «бюджет сгорел» не запускает freeze автоматически, это просто график на дашборде. Должна быть записанная политика, что делать.
• Слишком жёсткое SLO. Если SLO нереалистичный («99.99% на сервисе, который объективно может только 99.9%»), бюджет всё время в минусе, и команда привыкает его игнорировать. Лучше реалистичный SLO с дисциплиной, чем красивая цифра, в которую никто не верит.

Бюджет — это не магический инструмент, а дисциплина. Он работает, если команда договорилась его соблюдать. Не работает — если нет.

Типичные ошибки выбора SLI/SLO и чек-лист

Соберу в один блок самые частые ошибки, которые ломают SLO-практику. Часть из них уже разобрана в основных разделах — в этом блоке они сведены в одну строку для самопроверки. Развёрнутые контрпримеры — в соответствующих главах выше.

Ошибка 1. SLI = «всё, что не 5xx»

Правильно: SLI — это success AND fast, и оба критерия записаны явно. Полный разбор — в Шаге 3 (про «хорошее событие»).

Ошибка 2. SLO «по системе» вместо SLO «по шагу пути»

Правильно: SLO живёт на каждом шаге критичного пути, а не на сервисе в целом. Развёрнуто — в Шаге 1 (ловушка «среднего по системе»).

Ошибка 3. SLO без error budget policy

SLO написано, бюджет считается, но что делать, когда бюджет сгорел — не записано. В итоге команда живёт в режиме «дашборд красный, ну ладно, продолжаем выкатку».

Правильно: записанная политика: при превышении burn-rate X× за окно Y минут — freeze деплоев до конца окна / привлечение reliability-команды / эскалация. Без процедуры SLO — это украшение. Развёрнуто — в разделе «Что разрушает „бюджет как арбитр“».

Ошибка 4. SLO = SLA

Правильно: между SLO и SLA — запас один-два разряда 9. Подробнее — в разделе «SLA: что уходит наружу».

Ошибка 5. Среднее вместо перцентилей

Правильно: SLI на latency — это перцентиль (P95/P99), не среднее. Развёрнуто — в Шаге 3, блок «Что мы НЕ берём как SLI».

Ошибка 6. SLI на CPU/Memory utilization

Правильно: SLI — на пользовательских следствиях (latency, errors). Утилизация — служебная метрика для USE-дашборда. Развёрнуто — в Шаге 3, блок «Что мы НЕ берём как SLI».

Ошибка 7. Слишком много SLI

«У нас 50 SLI на сервис» — означает, что SLI никто не читает, и алерты по ним — шум. SLI должен фокусировать внимание, а не размывать его.

Маленькое терминологическое уточнение, без которого пункт читается двусмысленно: «сервис» здесь — пользовательский сервис в смысле CUJ, а не каждый микросервис в твоей архитектуре. На один CUJ (поиск каталога) — 4–8 SLI; на ranking-микросервис, который обслуживает этот же CUJ, не нужно отдельно вешать ещё 4–8. Иначе «50 SLI» получаются арифметически — суммой по микросервисам, — и читать их никто не будет.

Правильно: 4–8 SLI на пользовательский сервис (CUJ), привязанных к ключевым шагам пути. Если хочется больше — это, скорее всего, сигнал, что внутри одного «сервиса» спрятаны два CUJ, и его пора разделить. Развёрнуто — в Шаге 3, блок «Конкретные SLI для нашего кейса».

Ошибка 8. SLO выбран копированием

«У Google 99.99%, у нас тоже будет». Без разговора с бизнесом, без расчёта стоимости, без понимания, тянет ли архитектура.

Правильно: SLO выбирается из двух чисел — что окупается (бизнес) и что достижимо (архитектура). Между ними может быть зазор — он отражает либо недоинвест в reliability, либо переинвест в обещания.

Ошибка 9. SLO не пересматривается

Поставили SLO 99.9% год назад, написали в Confluence, забыли. Бизнес-контекст изменился, нагрузка выросла в 10 раз, продукт перешёл в зрелую фазу — SLO остался прежним.

Правильно: SLO пересматривается раз в квартал минимум, в idle-режиме — раз в полгода. Каждый пересмотр — короткий ритуал «изменилось ли что-то в бизнесе или в системе, что меняет нужное число».

Ошибка 10. SLO выбран без учёта зависимостей

Сервис обещает 99.99%, но критически зависит от внешнего сервиса с 99.5%. Математика: твой SLO не может быть выше произведения SLO твоих критичных зависимостей.

Правильно: при выборе SLO учитывай dependency budget. Если у тебя 3 последовательные критичные зависимости с 99.9% каждая, твой достижимый максимум — ~99.7%. Для опциональных или параллельных зависимостей формула мягче — но любую цепочку нужно явно проговорить.

Чек-лист: 10 вопросов до утверждения SLO

Если ответ «нет» хотя бы на один — SLO ещё не готов.

• Привязан ли SLO к конкретному шагу критичного пути, а не к сервису целиком?
• Прописаны ли числитель, знаменатель и окно агрегации?
• Пройдён ли тест «5xx за 5 секунд = плохое событие»?
• Используется ли перцентиль, а не среднее?
• Есть ли error budget в абсолютных значениях для текущего объёма трафика?
• Есть ли записанная error budget policy (что делать при сгорании)?
• Есть ли запас между SLO и SLA (если SLA вообще обещаем)?
• Согласованы ли числа с бизнесом (а не «команда придумала»)?
• Учтены ли SLO критичных зависимостей в верхней границе нашего?
• Назначена ли дата следующего пересмотра?

Заключение: SLO — это мост между системой и деньгами

Я начинал статью с тезиса, что архитектура без SLO — это эстетика, не инженерия. К концу хочется его уточнить.

SLO — не просто constraint на архитектуру, хотя я почти всю статью акцентировал именно это. SLO — это общий язык между четырьмя ролями, которые иначе говорят на разных:

• Продакт / аналитик говорит: конверсия, retention, GMV, NPS.
• Бэкенд говорит: P99, шарды, hit rate, репликация.
• SRE говорит: error budget, burn rate, MTTR, blast radius.
• Бизнес говорит: деньги, репутация, регуляторика.

SLO — это формат, в котором все четверо могут договориться. «Поднять availability с 99.9% до 99.99% стоит 4× инфраструктуры и сэкономит N часов даунтайма в год, что на нашем GMV $X — это Y денег. Делаем или нет?». Этот вопрос имеет ответ, к которому пришли все четверо. Без SLO такого вопроса просто не существует — есть только предчувствия.

Что сделать в понедельник

1. Возьми один пользовательский путь и разложи его на шаги. Не сервис целиком — один сценарий, шесть-семь шагов, как в нашем кейсе. На каждый шаг — кандидаты в SLI. Это упражнение делается за два часа и показывает, где ты измеряешь не то.
2. Сравни свои текущие SLO с реальными зависимостями. Если твой SLO выше произведения SLO критичных зависимостей — ты обещаешь больше, чем можешь дать. Цифру лучше пересмотреть до того, как её пересмотрит пользователь.
3. Напиши error budget policy на одну страницу. Что происходит при превышении burn-rate X× за Y минут? Кто принимает решение freeze? Без этого документа SLO остаётся графиком на дашборде, а не дисциплиной.

Спасибо, что дочитал до конца. Эта статья — переработанная версия плана несостоявшегося доклада для System Design World . Если у тебя есть свой опыт работы с SLO в системе высокой нагрузки — особенно интересны истории, как менялся выбор SLO с ростом продукта или после крупного инцидента — пиши в комменты или в мой Telegram-канал «Мишка на сервере ».

Чертёж — это половина дела. Как именно выглядит тот самый диалог с бизнесом, без которого SLO остаётся картинкой на дашборде, я разбираю в продолжении: «Надёжность строится в диалоге с бизнесом» .

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.