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 §1). Раздел 08 уже разобрал половину этапа 6 — отказы по каждому узлу и перегрузку (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 §10; стратегия выката в эталонах — ../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 — метрика там была четвёртым шагом каждого отказа):

Перцентили, не средние — правило №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 §3). Это же замыкает кольцо секции: требования этапа 1 → метрики → изменения по метрикам → финал: «каждое требование контролируется метрикой». Нефункциональные требования, которые мы собрали в этапе 1 (статья 01 §4) и посчитали в этапе 5 (статья 02), здесь обретают управление: SLO и error budget (§3), golden signals (§2), алерты на них (§3), выкат по ним (§6) — и возврат к листу требований.

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

Ядро раздела и ответ на второй AC. Этап 6 — 10 минут, и это скрипт, который кандидат ведёт сам. Полный чек-лист — ../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 §4) и типичные провалы именно на эксплуатации:

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 §6; сверка с эталонами — ../classic-designs.md §1–2. Если этап 6 проходит потоком и заканчивается возвратом к листу требований — раздел готов, а с ним и вся серия: от фреймворка этапа 1 до жизни продакшена.

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

• 00-overview.md — обзорная статья по всем 12 разделам брифа (TASK-45.40); §12 — карта раздела и «как поймёте, что система жива?»
• 01-interview-framework.md — этап 6 в каркасе, правило «эксплуатацию не режем никогда», кольцо секции (возврат к листу требований)
• 02-estimations.md — латентности (p95/p99) как вход для SLO; этап 5: расчёт headroom
• 06-caching.md — прогревы кэшей при выкате/отказе (§9 этой статьи)
• 07-queues-streams.md — лак очереди как золотой сигнал; DLQ и ядовитые сообщения в отладке
• 08-fault-tolerance.md — половина этапа 6: отказы по узлам, перегрузка, N+1 как условие rolling; обещанные мосты сюда (golden signals, SLO, canary)
• ../brief.md — бриф: раздел 12 с критерием «умею, если» (назвать самому, не дожидаясь вопроса)
• knowledge-base.md — §10 эксплуатация (golden signals, SLO/error budget, релизы, expand/contract, ёмкость, tail amplification, metastable), §9 отказоустойчивость, §13.5
• methodology.md — §2 карточка этапа 6 (цель → доска → речь → грабли), §3 паттерн metrics first, §4 топ-10 ошибок, §6 протокол тренировок, §7 карточка на секцию
• classic-designs.md — §1 shortener (43 сервера, обновление по 3 воркера и ДЦ последовательно, мониторинг по классам, тестовый контур), §2 лента (деградации, метрики ленты)
• materials/yandex-564132.md — источник этапа 6: мониторинг по классам серверов, квантили, защита кодов от шума, логи и трассировка по объёмам, обновление, принцип metrics first
• 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 живёт целиком)