---
title: Статья 12 — Эксплуатация и наблюдаемость
source: подготовлено 2026-09-18, TASK-45.52; каркас — brief.md §12; развёртка knowledge-base.md §10 (мосты в §9, §13.5); источники — статья Яндекса, этап 6 (TASK-45.5), DDIA 2-е изд. гл. 2 (TASK-45.39), методичка §2 карточка этапа 6
---

# Статья 12: эксплуатация и наблюдаемость

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

Место раздела в серии и в секции — особое. В каркасе (статья 01) этап 6 «Эксплуатация» — 10 минут из 60, но методичка ставит железное правило: **«эксплуатацию не режем никогда — именно она отличает senior-ответ»** ([`../methodology.md`](../methodology.md) §1). Раздел 08 уже разобрал половину этапа 6 — отказы по каждому узлу и перегрузку ([`08-fault-tolerance.md`](08-fault-tolerance.md)) и неоднократно обещал мосты сюда: «golden signals, SLO/error budget, релизы без простоя — статья 12», «мост к rolling-выкату из статьи 12», «наблюдаемость перегруза (saturation, очереди, p99) — золотые сигналы из KB §10, подробно в статье 12». Здесь эти обещания закрываются. Статья 07 тоже ссылалась сюда — «мониторинг лага — раздел 12 (golden signals)». Итого раздел 12 — это **вторая половина этапа 6**: наблюдаемость, алерты, релизы, миграции, ёмкость — и принцип, который стягивает всё: **metrics first** (статья Яндекса, этап 5–6). Глубина — [`../knowledge-base.md`](../knowledge-base.md) §10; стратегия выката в эталонах — [`../classic-designs.md`](../classic-designs.md) §1 (Яндекс) и §2 (лента).

## 1. Три столпа наблюдаемости: метрики, логи, трейсинг

Первый ответ на «как поймёте, что система жива?» — не «мониторинг», а конкретика: **тройка метрики/логи/трейсинг**, у каждого своя работа и своя цена:

- **Метрики** (Prometheus-класс) — числовые временные ряды: QPS, латентность, ошибки, утилизация. Дёшево агрегируются и долго хранятся, на них держатся **алерты** («что-то горит сейчас»). Отвечают на «работает ли система в целом», но без деталей: кто, где, почему.
- **Логи** — события с контекстом: каждый запрос/ошибка/переход состояния. Дороже метрик на порядки (объём и хранение — §4), зато дают ответ «что именно случилось». Структурированные (JSON, request id, шаблонный формат) — иначе бесполезны.
- **Трейсинг** (OpenTelemetry) — путь **одного** запроса через все сервисы: спаны с таймингами, сквозной **trace id**, который связывает логи разных сервисов одной нитью. Отвечает на «где именно потерялись миллисекунды» — в нашем сервисе, в соседе или в сети.

Правило выбора — по фазе разбирательства: **метрика находит симптом (SLO горит), трейс находит сервис, лог находит строчку**. На секции достаточно проговорить тройку в один абзац: «собираю метрики на алерты, структурированные логи с trace id для поиска, трассировку OpenTelemetry с выборкой — когда 5xx взлетели, трейс показывает, какой хоп съел латентность». Различие наблюдение vs мониторинг можно назвать одной фразой: «мониторинг отвечает на заданные вопросы, наблюдаемость — позволяет задавать новые, которых мы не предусмотрели» (DDIA гл. 14).

## 2. Golden signals: что меряем и почему перцентили

Канон Google SRE — **четыре золотых сигнала** на каждый класс узлов: **latency, traffic, errors, saturation**. Их сила в полноте: любой инцидент проявится хотя бы в одном. Два нюанса, которые надо проговаривать:

- **Латентность — раздельно для успехов и ошибок.** Ошибки почти всегда быстрые (фейлим сразу); если смешать, кривая врёт и проблема прячется. «p99 успешных ответов» — отдельная метрика, не общая.
- **Saturation** — «насколько близко к пределу»: очередь, лаг, утилизация CPU/памяти/соединений. Именно она — ранний сигнал перегруза (статья 08 §7): при 100 % утилизации задержки становятся неограниченными (DDIA гл. 9), поэтому saturation ловится **до** роста латентности.

Таблица по классам узлов типовой схемы (тот же зум, что у прогонки отказов в статье 08 §10 — метрика там была четвёртым шагом каждого отказа):

| Класс узлов | Latency | Traffic | Errors | Saturation |
|-------------|---------|---------|--------|------------|
| **LB / шлюз** | p95/p99 ответа (успехи и ошибки отдельно) | RPS входящих по коду ответа | доля 5xx/429/таймаутов | коннекты, очередь, CPU |
| **Stateless-сервис** | p50/p95/p99 по эндпоинту | RPS по ноде (разброс → перекос балансировки) | error rate по кодам | CPU, потоки, пулы (bulkhead-пулы тоже, 08 §6) |
| **Кэш** | время хопа (мкс) | hit ratio, RPS | недоступность кластера | память, eviction |
| **БД** | время запроса p95/p99 | QPS чтение/запись | ошибки записи, deadlocks | replication lag, коннекты, CPU/диск |
| **Очередь** | — (асинхронно) | rate продюсера/консьюмера | under-replicated партиции | **consumer lag**, старость сообщений |
| **Внешние зависимости** | p99 вызова | вызовы/с | доля открытых circuit breaker | ретраи/с (метрика retry budget, 08 §5) |

**Перцентили, не средние** — правило №1 латентности (DDIA гл. 2): среднее скрывает хвост, а отказ живёт в хвосте; p50 показывает норму, p95 — впечатления большинства, p99 — границу терпимого. Плюс словарь производительности: **response time ≠ service time ≠ latency** — разница это **queueing delay**, главный источник задержек (§9, статья 08 §4).

**Tail amplification** — аргумент, почему перцентили критичны именно в fan-out: если страница собирается из N независимых вызовов и каждый «почти всегда быстрый», то медленный хвост кого-то из них тащит всю страницу. Арифметика: если каждый из 10 бэкендов отвечает за p99 (99 % быстрых), вероятность, что все быстрые — 0.99¹⁰ ≈ 90 %: **каждая десятая страница ловит чужой хвост**; при N=50 — уже 40 % страниц медленные. В fan-out-горячем пути (лента, рекомендации) это превращает единичные хвосты в системную проблему — лечится параллельными повторами к медленным (hedged requests) или сокращением числа хопов. Назвать пару чисел — маркер, что перцентили не «вычитаны», а прожиты.

## 3. SLI/SLO/error budget: управляем надёжностью числом

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

- **SLI** — что реально измеряем: «доля запросов с ответом <200 мс и кодом 2xx за окно».
- **SLO** — цель на SLI: «SLI ≥ 99.9 % за месяц». Это наша внутренняя договорённость, из неё считаются алерты.
- **SLA** — публичный контракт с клиентом; обычно **слабее** SLO (нельзя клиенту обещать строже, чем держим внутри). Фраза для секции: «SLA — внешний документ, SLO — внутренняя цель, SLI — измерение».

**Error budget** — всё управление: SLO 99.9 % даёт **43 минуты простоя в месяц** (KB §10; девятки и стоимость — статья 08 §1). Бюджет — и мера, и политика: пока он есть — можно катить рискованные релизы и эксперименты (платим из бюджета), **бюджет кончился — фризим фичи и чиним надёжность**. Это механизм, который не даёт продакшну деградировать молча: каждое изменение стоит бюджетных минут, и это видно.

**Алерты — на симптомы, не на причины** (NB из методички и KB §10): симптомный алерт — «SLO тратит бюджет быстрее допустимого» (burn rate: 99.9 % за месяц горит за 1 ч ×14.6), он побуждает дежурить независимо от того, что сломано. Причинный алерт — «CPU 90 %» — может быть нормой под пиком: он годится для поиска, а не для побудки. Формула: **симптомы будят, причины ищут**. И «защита от шума» (Яндекс): известные шумные коды ответов (частые несуществующие ссылки, аккаунты с исчерпанной квотой) — в отдельный счётчик, чтобы не разводить ложные тревоги и не прятать реальные.

Связка с каркасом — здесь же замыкается кольцо секции: **SLO заявлен в требованиях (этап 1) → здесь им управляем через error budget → в финале возвращаемся к листу**: «SLO 99.9 % обеспечен и контролируется burn-rate алертом». Это и есть обещанный статья 01 «маркер production-зрелости».

## 4. Логи и трейсинг при больших объёмах

У логирования в high-load есть специфика, которую мало кто проговаривает — **логи сами по себе нагрузка**. Статья Яндекса даёт готовую позицию: «логи веб-серверов при таких объёмах дороги и сами влияют на производительность». Решения по нарастанию:

- **Писать быстро и ротировать**: SSD/NVMe, частая ротация, сжатие, перекладка в дешёвое хранилище (первый уровень — HDD на том же сервере).
- **Уровни избыточности по возрасту архива**: свежее — горячий поиск, старее — холодное хранилище, ретеншн по требованиям (аудит, разбор инцидентов).
- **Сэмплинг вместо «логируем всё»**: тестировать, что логи не сжирают диски; отладка — **каждый k-й запрос и/или по флагу в запросе** (Яндекс); трейсинг — выборка, не 100 % (агрегируем статистику на метриках, детали — в трейсе по trace id).
- **Структура**: JSON, единый формат, обязательный **request/trace id** — иначе логи N сервисов не связать.

Фраза для секции: «логи — это продукт с ценой хранения: сэмплирую, ротирую, разделяю по возрасту; трассировку включаю на каждый k-й запрос или по флагу — иначе сам мониторинг становится узким местом» (эта же мысль у Яндекса в «Доп. вопрос: отладка в работающем кластере»).

## 5. Конфигурация и feature flags: расходим деплой и релиз

Пункт «конфигурация» из брифа — недооценённый, а у него есть одна сильная мысль: **конфиг — это тоже релиз, и он должен быть версионирован и раскатываться отдельно от кода** (same deploy/release split, что и фичи). Три пункта:

- **Конфигурация отдельно от кода**: не зашита в бинарь, версионирована, раскатывается как артефакт; плохая конфигурация откатывается быстрее, чем плохой код. Изменение конфига в проде «на живую» — это тоже выкат со всеми его правилами (canary, откат).
- **Feature flags**: выключатель фичи в рантайме. Главный приём — **расходим деплой кода и релиз фичи**: код выкатили (strategy), фичу включили когда надо (timing). Флаги же — готовый механизм заранее спроектированных деградаций из статьи 08 §7 («деградации — это фичи-флаги, выключатели по приоритету, прописанные до инцидента»).
- **Ловушки флагов**: флаги-зомби копятся годами и мешают читать код (правило: флаг живёт ровно до полного выката — потом убирается); чтение флага на горячем пути стоит денег — решение кэшируется.

## 6. Релизы без простоя: rolling, canary, blue-green

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

- **Rolling release** — обновляем по частям: новая версия разворачивается на подмножестве нод, остальные продолжают работать; по завершении — на следующем подмножестве. Дёшево (не нужны лишние ресурсы), но откат — «дооткатить остальные ноды», медленный; в полёте работают **две версии кода сразу** → нужна обратная совместимость (схема данных — §8). Конкретика Яндекса для stateless-воркеров: **«по 3 воркера, ДЦ строго последовательно, сравнивая метрики с остальными»** — запас N+1 (08 §3) позволяет терять несколько воркеров на ДЦ без потери качества.
- **Canary** — катим на малый процент трафика: **1 % → 10 % → 50 % → 100 %** с **авто-откатом по метрикам**: на каждом шаге сравниваем canary-контур с контролем (5xx, p99, бизнес-метрики — конверсия, ошибки записи); отклонение — автоматически откат. Это релиз как **эксперимент**: метрики решают, оставляем или откатываем. Канарейку сравнивают с контролем (остальным трафиком), а не с «вчерашним днём» — иначе получим ложное срабатывание из-за суточных колебаний.
- **Blue-green** — две полные среды: подняли green, переключили трафик целиком, **откат — мгновенный переключателем**. Цена — двойные ресурсы и требование, чтобы **обе версии работали с одной схемой** (миграции несовместимы с blue-green в чистом виде — привет, expand/contract §8).
- **База данных** — самая консервативная часть: сначала реплики, потом лидер; короткое окно записи (Яндекс: «обновление СУБД с коротким даунтаймом после проверки на тестовом контуре, чтение не страдает»). Принцип: **код катим по правилам стейтлеса, данные — по правилам стейтфула**.

Связка с 08: grace period деплоя (вывели ноду из ротации readiness-пробой, дали дообработать in-flight, погасили) — это «мост к rolling-выкату», обещанный в статье 08 §3. Финальная фраза раздела: «любой выкат — это эксперимент с авто-откатом; флаг разводит деплой и релиз; схема эволюционирует на шаг вперёд от кода».

## 7. Shadow traffic: репетиция прода раньше прода

**Shadow traffic** — прогон реального прод-трафика через новую версию без влияния на пользователей: запросы дублируются в новый контур, ответы отбрасываются, а мы сравниваем поведение (результат, латентность, ошибки). Это репетиция: новая версия впервые видит **настоящую** нагрузку и настоящие данные — то, что никакой load-тест не даст. Конкретика из статьи Яндекса — **тестовый контур меньшего размера, куда дублируется каждый k-й продовый запрос**.

Две вещи проговаривать обязательно:

- **Лестница проверки перед продом**: shadow (безопасно, но ответа пользователю не даёт) → canary (реально, но рискованно — поэтому начинается с 1 %) → полный выкат. Порядок называется сам: **shadow проверяет «сломается ли», canary — «устроит ли»**.
- **Ловушка shadow — side effects**: если новая версия **пишет** (БД, платёж, письма), дублированный запрос выполнит запись дважды. Правила: shadow-дублирование только для чтения, либо записи в изолированный контур, либо идемпотентность (возврат к 08 §5). Фраза: «shadow на запись опасен двойным эффектом — пускаю его только если операция идемпотентна или дублируется в отдельный контур».

## 8. Миграции без даунтайма: expand/contract

Любой релиз, трогающий схему данных, упирается в одно правило: **код старой и новой версий должен работать с одной и той же схемой** (rolling и blue-green живут только при этом условии — мост к 06 §8 и 05 §4 о совместимых миграциях схем). Инструмент — **expand/contract** (в KB §10 — четыре шага, каждый сам по себе рабочий релиз):

1. **Expand**: расширяем схему — новая колонка/таблица, nullable / с дефолтом. Старый код не замечает.
2. **Двойная запись + backfill**: пишем в новое и старое; backfill исторических данных — в фоне, по батчам; **сверка** (reading comparison) — сверяем новое с источником правды.
3. **Переключаем чтение**: кодик начинает читать из нового; старый контур ещё пишет.
4. **Contract**: убираем старое (колонку, таблицу, ветку кода). Только когда готово следующее релизное окно — схема снова «одна версия вперёд».

Два антипаттерна, которые называть прямо: **большие ALTER на живых больших таблицах** (блокировки, простой записи; expand-контракт именно потому, что «больших миграций» не бывает — есть мелкие совместимые шаги) и **dual writes без сверки** (две системы записи расходятся тихо — расхождение всплывёт в инциденте). И обратная сторона: **откат релиза не должен откатывать схему** — деплой откатывается кодовой версией, схема остаётся на шаг впереди (contract — в следующем цикле, если откатились).

## 9. Ёмкость: headroom, load-тесты, репетиция пика

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

- **План на пики заранее**: реклама, праздники, сезон (их видно в календаре) — закладываем в этап 5 (статья 02 §4). **Headroom ≥ 2×** — правило KB §10; аргумент из 08 §4: при 100 % утилизации задержки неограниченны, запас — механизм отказоустойчивости, а не расточительство.
- **Регулярные load-тесты**: синтетика + shadow (§7) — периодически, а не перед релизом; прогрев холодных кэшей после выката/отказа (мост 08 §8: «разогрев нового лидера»).
- **Автоскейлинг назвать, но приземлить**: скейлинг вверх быстрее, чем вниз; новые ноды не получают мгновенно тёплые кэши и коннекты; поэтому «расту со скейлером по метрике saturation, но headroom и прогрев держу сам».
- **Metastable failure** — мост к 08 §5,7: перегруз → таймауты → retry storm → система застревает в перегрузе даже после спада нагрузки; весь узел «ёмкость» и есть профилактика этого класса: запас не даёт войти в спираль, shedding — выход из неё.

## 10. Metrics first: принцип, который стягивает раздел

Финальный принцип из статьи Яндекса — и он же метод над всем этапом 6: **«сначала определить или построить метрику, которую улучшаете, и только затем менять систему»**. Метрики — и контроль работоспособности в моменте, и основа ретроспективного анализа решений: если нет метрики, которую изменение должно сдвинуть, — изменение нельзя ни оценить, ни защитить.

На секции это звучит как привычка говорить в начале изменений, на любом этапе: «метрика, которую улучшаем: p95 редиректа ≤ 150 мс / доступность чтения 99.99 %» (паттерн из [`../methodology.md`](../methodology.md) §3). Это же замыкает кольцо секции: **требования этапа 1 → метрики → изменения по метрикам → финал: «каждое требование контролируется метрикой»**. Нефункциональные требования, которые мы собрали в этапе 1 (статья 01 §4) и посчитали в этапе 5 (статья 02), здесь обретают управление: SLO и error budget (§3), golden signals (§2), алерты на них (§3), выкат по ним (§6) — и возврат к листу требований.

## 11. Что назвать на этапе 6, не дожидаясь вопроса

Ядро раздела и ответ на второй AC. Этап 6 — 10 минут, и это **скрипт, который кандидат ведёт сам**. Полный чек-лист — [`../methodology.md`](../methodology.md) §2 (карточка этапа 6); порядок проговора — такой (часть шагов — из статьи 08, здесь они встроены в цельный рассказ):

1. **Топология**: «2–4 ДЦ, балансировка в каждом ДЦ своя, GeoDNS с коротким TTL» (детали — 08 §9) — одна фраза, не разворачивать.
2. **Отказы**: «пройду по каждой ноде: отказ → что происходит → что делаю → метрика» — таблица 08 §10 по своей схеме, 3–4 минуты.
3. **Перегрузка**: «headroom ≥ 2×, rate limiting с 429, shedding по приоритетам, заранее спроектированные деградации; подозрительный трафик — в blacklist» (08 §7).
4. **Наблюдаемость (сам, не дожидаясь вопроса)**: «golden signals по классам узлов — p50/p95/p99, latency отдельно для ошибок; SLI/SLO 99.9 % = 43 мин/мес error budget; алерты на burn rate, а не на CPU; логи — сэмпл/ротация/холодное хранилище; трейс — каждый k-й запрос со сквозным trace id».
5. **Релизы (сам)**: «rolling по 3 воркера и ДЦ последовательно, сравнение метрик с остальными; canary 1→10→50→100 с авто-откатом; feature flags разводят деплой и релиз; тестовый контур с дублем каждого k-го запроса из прода».
6. **Миграции**: «схему меняю expand/contract — четыре совместимых шага, каждый релизен; без больших ALTER».
7. **Финал — возврат к листу требований** (ход из 01 §5): «сверимся: SLO закрывает запас 30→10 мс, доступность — N+1 по ярусам, лимиты — rate limiter; **каждое требование контролируется метрикой, на неё стоит алерт**».

Как это звучит вслух целиком (60–90 секунд на шаги 4–6): «Наблюдаемость — golden signals на каждом ярусе: латентность успехов и ошибок раздельно, перцентили, saturation по очередям и лагу. SLO 99.9 % — бюджет 43 минуты в месяц; алерт срабатывает по burn rate, а не по CPU — причины ищем уже по трейсу с trace id и логам. Катим rolling по 3 воркера, ДЦ строго последовательно, метрики сравниваю с контролем; критичные фичи — canary с авто-откатом по тем же метрикам; код и фичу развожу флагами. Схему меняю expand/contract: сначала расширение, двойная запись со сверкой, переключение чтения, уборка старого. Каждое требование из этапа 1 контролируется метрикой с алертом».

## 12. Ошибки этого раздела

Подмножество топ-10 ошибок ([`../methodology.md`](../methodology.md) §4) и типичные провалы именно на эксплуатации:

| Ошибка | Как выглядит | Противоядие |
|--------|--------------|-------------|
| «Поставим мониторинг» без конкретики | Ответ на «как поймёте, что система жива?» — «ну, мониторинг» | Тройка метрики/логи/трейс + golden signals по классам узлов (§1–2) |
| Средние вместо перцентилей | «средняя латентность 120 мс» — а p99 уже 2 с | p50/p95/p99; latency успехов и ошибок раздельно (§2) |
| Алерты на причины | «CPU > 90 %» будит в 4 утра, а это пик | Симптомные алерты: burn rate по SLO; причины — для поиска (§3) |
| SLO без бюджета | Цель назначена, но решениями не управляет | Error budget: кончился — фриз фич (§3) |
| Деплой без плана Б | Выкатили, «а если что — руками» | Canary с авто-откатом; KISS-выбор rolling там, где дёшево (§6) |
| Две версии кода в полёте игнорируют схему | Blue-green без совместимых миграций → поломанные записи | Expand/contract первым; схема на шаг впереди кода (§6, §8) |
| Большой ALTER на живой таблице | Блокировки, простой записи | Мелькие совместимые шаги expand/contract (§8) |
| Dual write без сверки | Две системы записи, расходятся молча | Сверка (reading comparison) как обязательный шаг 2 (§8) |
| Shadow с side effects | Дублированный запрос дважды платит/пишет | Shadow только на чтение или идемпотентно/в отдельный контур (§7) |
| Логи без цены | «Логируем всё» — диски кончились и сами логи стали узким местом | Сэмплинг, ротация, холодное хранилище, уровни по возрасту (§4) |
| Нет плана на пик | Чёрная пятница роняет проде, load-тестов не было | Headroom ≥2×, плановые load-тесты, shadow как репетиция (§9) |

## 13. Самопроверка «умею, если»

Критерий раздела из брифа: **на этапе 6 сам называю наблюдаемость и стратегию выката, не дожидаясь вопроса**. Проверка с закрытыми материалами: взять схему shortener (или ленты) и провести этап 6 полностью по скрипту §11 — от топологии и отказов до финального возврата к листу требований — без пауз и без просьб. Контрольное время: весь этап 6 — 8–10 минут; шаги 4–6 (мониторинг, релизы, миграции) — 2–3 минуты. Маркеры готовности: (1) при вопросе «как поймёте, что система жива?» рука тянется к golden signals по классам узлов и burn rate, а не к слову «мониторинг»; (2) стратегия выката называется сама — rolling/canary с авто-откатом и порядком сравнения метрик; (3) миграция рассказывается expand/contract четырьмя шагами без подсказки; (4) SLO из этапа 1 всплывает в финале с алертом на него; (5) фраза metrics first звучит в момент изменения («метрика, которую улучшаем — …»). Порядок тренировок и рубрика 0–3 — [`../methodology.md`](../methodology.md) §6; сверка с эталонами — [`../classic-designs.md`](../classic-designs.md) §1–2. Если этап 6 проходит потоком и заканчивается возвратом к листу требований — раздел готов, а с ним и вся серия: от фреймворка этапа 1 до жизни продакшена.

## Связанные документы

- [`00-overview.md`](00-overview.md) — обзорная статья по всем 12 разделам брифа (TASK-45.40); §12 — карта раздела и «как поймёте, что система жива?»
- [`01-interview-framework.md`](01-interview-framework.md) — этап 6 в каркасе, правило «эксплуатацию не режем никогда», кольцо секции (возврат к листу требований)
- [`02-estimations.md`](02-estimations.md) — латентности (p95/p99) как вход для SLO; этап 5: расчёт headroom
- [`06-caching.md`](06-caching.md) — прогревы кэшей при выкате/отказе (§9 этой статьи)
- [`07-queues-streams.md`](07-queues-streams.md) — лак очереди как золотой сигнал; DLQ и ядовитые сообщения в отладке
- [`08-fault-tolerance.md`](08-fault-tolerance.md) — половина этапа 6: отказы по узлам, перегрузка, N+1 как условие rolling; обещанные мосты сюда (golden signals, SLO, canary)
- [`../brief.md`](../brief.md) — бриф: раздел 12 с критерием «умею, если» (назвать самому, не дожидаясь вопроса)
- [`knowledge-base.md`](../knowledge-base.md) — §10 эксплуатация (golden signals, SLO/error budget, релизы, expand/contract, ёмкость, tail amplification, metastable), §9 отказоустойчивость, §13.5
- [`methodology.md`](../methodology.md) — §2 карточка этапа 6 (цель → доска → речь → грабли), §3 паттерн metrics first, §4 топ-10 ошибок, §6 протокол тренировок, §7 карточка на секцию
- [`classic-designs.md`](../classic-designs.md) — §1 shortener (43 сервера, обновление по 3 воркера и ДЦ последовательно, мониторинг по классам, тестовый контур), §2 лента (деградации, метрики ленты)
- [`materials/yandex-564132.md`](../materials/yandex-564132.md) — источник этапа 6: мониторинг по классам серверов, квантили, защита кодов от шума, логи и трассировка по объёмам, обновление, принцип metrics first
- [`materials/ddia-2ed/ch-02-nfr-timelines-case.md`](../materials/ddia-2ed/ch-02-nfr-timelines-case.md) — источник: словарь производительности (response vs service time vs latency), p50/p95/p99, tail latency amplification, 100 % утилизация → неограниченные задержки
- Соседние статьи: `08-fault-tolerance.md` (отказы — шаги 1–3 скрипта §11) · `09-consistency.md` (кворумы, fencing — глубина миграций и выкатов схемы) · `10-components-patterns.md` (rate limiter, ID под выкатами) · `11-reference-designs.md` (эталонные разборы, где этап 6 живёт целиком)