# Не видишь — не починишь

Экспресс-курс о наблюдаемости. 22 понятия — Observability, Structured Logging, Four Golden Signals, Trace и Span, Correlation ID, SLI/SLO/SLA, Alert Fatigue и другие — у каждого английское название, схема, карточка и связи с остальными. Только суть: в проде нельзя подключить отладчик, поэтому ты строишь систему так, чтобы она объясняла себя сама. В конце — шпаргалка по всем понятиям на одной странице.

- **Author:** Фёдор Чищин
- **Level:** intermediate
- **Reading time:** ~35 минут чтения
- **Published:** 2026-06-13
- **Source:** https://fedorthinks.com/ru/learn/observability-express

---

## 1. Зачем наблюдаемость

Вся область существует из-за одного жёсткого факта: нельзя отлаживать живую продакшен-систему так, как отлаживаешь код на машине. Так что приходится заставить систему рассказывать, что она делает.

### Карта: 22 понятия в семи группах

> Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Сначала три **основы** — почему в проде летишь по приборам, чем мониторинг отличается от наблюдаемости и что такое чёрный ящик. Дальше шесть групп, по одной на главу: **логи**, **метрики**, **трейсы**, как три столпа работают **вместе**, **алертинг** и как **применять хорошо**.

У каждого понятия дальше одно и то же: **английское название** (запомни его — это термин), образ из жизни, **схема** и **карточка** с полями: _проблема_, _идея_, _пример_, _цена_ или _подвох_, _когда брать_ и _связи_.

_Diagram: Основы сверху, ниже — шесть групп, по ним идут главы 2–7._

### Flying by Instruments — к проду нельзя подключить отладчик

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

На ноутбуке ты ставишь код на паузу, смотришь переменные, шагаешь. В **проде (production)** — реальные серверы, реальные пользователи, прямо сейчас — нельзя остановить, чтобы посмотреть. Узнать, что происходит, можно только из **сигналов (signals)**, что система излучает на ходу.

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

_Diagram: На ноутбуке ты смотришь внутрь отладчиком. В проде видно только то, что система сама излучает: логи, метрики, трейсы._

#### Flying by Instruments (прод, полёт по приборам)

- **Проблема:** Живой прод нельзя поставить на паузу и осмотреть отладчиком.
- **Идея:** Узнавать, что происходит, только по сигналам, которые система излучает на ходу.
- **Пример:** Вместо брейкпоинта в платёжном коде — метрика ошибок, трейс запроса и строка лога.
- **Следствие:** Приборы надо поставить на панель заранее, а не во время сбоя.
- **Связи:** Приборы — это три столпа: **logs**, **metrics**, **traces**.

### Monitoring vs Observability — известные и новые вопросы

> Приборка машины показывает те немногие вещи, что ты знал отслеживать, — скорость, топливо, температуру. Но когда начинается странный новый звук, тебе надо мочь исследовать то, под что никто не поставил стрелку.

**Мониторинг (monitoring)** — это слежение за проблемами, что ты предвидел: дашборды и алерты для известных режимов сбоя. **Наблюдаемость (observability**, часто пишут **o11y**) — более глубокое свойство: можешь ли ты ответить на вопросы, что _не_ предвидел, просто из данных, что система производит?

Реальные сбои обычно новы — «почему пользователи в Бразилии видят медленные оплаты с двух дня?» — и наблюдаемость это то, излучает ли твоя система достаточно, чтобы дать тебе гнаться за вопросом, что ты никогда не планировал.

_Diagram: Мониторинг отвечает на заранее заданные вопросы. Наблюдаемость даёт нарезать богатые данные под вопрос, которого вчера ещё не было._

#### Observability (наблюдаемость, o11y (против monitoring))

- **Проблема:** Дашборды и алерты ловят только сбои, что ты предвидел; реальные сбои обычно новые.
- **Идея:** Система излучает достаточно данных, чтобы ответить на непредвиденный вопрос.
- **Пример:** «Почему в Бразилии медленные оплаты с двух дня?» — режешь данные по региону, времени и эндпоинту.
- **Мониторинг:** Слежение за известным. Нужен, но его мало.
- **Связи:** Даёт расследовать; **alerting** говорит, когда начать.

### Black Box — система, о которой можно только гадать

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

Система, что излучает мало, — это **чёрный ящик (black box)**: когда она ведёт себя плохо, ты сведён к гаданию и перезапускам. Цена проявляется в худший момент — продакшен-инцидент, где каждая минута важна, а ты понятия не имеешь, куда смотреть.

Наблюдаемость оплачивается заранее, **инструментируя (instrumenting)** систему, пока она спокойна, чтобы, когда она в огне, у тебя был свет, чтобы видеть.

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

#### Black Box (чёрный ящик)

- **Что это:** Система, которая почти ничего о себе не излучает.
- **Почему плохо:** На инциденте остаётся гадать и перезапускать, пока каждая минута стоит денег.
- **Пример:** Сервис падает, а в логах пусто и метрик нет — куда смотреть, неясно.
- **Лекарство:** Инструментировать систему, пока она спокойна.
- **Связи:** Лечится практикой **Instrument as You Build**.

> **Вопрос рамки:** «Когда это сломается в проде в три ночи, что система реально сможет мне рассказать — или я останусь гадать в темноте?»

> Нельзя поставить прод на паузу, чтобы осмотреть. Наблюдаемость — это строить систему так, чтобы она объясняла себя, — чтобы отвечать на непредвиденные вопросы, а не только следить за предвиденными.

## 2. Логи

Старейший и самый детальный сигнал — лог: текущий дневник того, что система сделала. Это первое, к чему тянешься, и самое лёгкое в злоупотреблении.

### Log — дневник системы

> Судовой журнал: записи с отметкой времени о том, что случилось и когда — «10:42, вошли в гавань» — чтобы любой потом мог восстановить плавание.

**Лог (log)** — это запись события с отметкой времени: «пользователь 42 вошёл», «платёж упал: карта отклонена», «начал обработку заказа 91». Каждая строка — маленькая, детальная заметка о чём-то, что случилось, написанная по ходу работы кода.

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

_Diagram: Поток логов: время, уровень, событие. Одна строка — одно событие._

#### Log (лог, журнал событий)

- **Что это:** Запись одного события с отметкой времени и деталями.
- **Отвечает на:** «Что именно случилось в этом конкретном случае?»
- **Пример:** `10:42:09 ERROR payment failed: card declined`
- **Подвох:** Легко переборщить — шум, деньги на хранение, медленный поиск.
- **Связи:** Становится полезным с **structured logging** и **log levels**; связывается с трейсом через **correlation ID**.

### Structured Logging — логи, которые можно искать

> Разница между коробкой рукописных заметок и таблицей — обе держат факты, но только одна даёт мгновенно отфильтровать всё про клиента 42.

Строку свободного текста трудно искать по миллионам записей. **Структурированные логи (structured logs)** пишут каждое событие как данные — поля вроде `user_id: 42`, `status: failed`, `duration_ms: 230`, — чтобы по ним можно было запрашивать: «покажи каждый упавший платёж дольше 500 мс сегодня».

Это превращает логи из стены текста, что ты пролистываешь, в базу, что можно допрашивать. Структура — вот что делает логи пригодными в масштабе прода.

_Diagram: Та же запись свободным текстом и как данные с полями. По полям можно делать запрос._

#### Structured Logging (структурированные логи)

- **Проблема:** Свободный текст не найти и не отфильтровать по миллионам строк.
- **Идея:** Писать событие как данные: именованные поля вместо фразы.
- **Пример:** `user_id: 42`, `status: failed`, `duration_ms: 230` → «все упавшие платежи дольше 500 мс за сегодня».
- **Цена:** Нужно договориться об именах полей и держать их единообразными.
- **Когда брать:** Всегда, как только логов больше, чем можно пролистать глазами.
- **Связи:** Поле `request_id` в каждой строке — основа **correlation ID**.

### Log Levels — уровни отделяют сигнал от шума

> Дневник, где рутинные записи карандашом, а ЧП красными чернилами, — чтобы в кризис можно было пролистать сразу к красному и игнорировать остальное.

У каждого лога есть **уровень (level)**, отмечающий важность: `DEBUG` и `INFO` для рутинной детали, `WARN` для чего-то не так, `ERROR` для реального сбоя. Уровни дают прибавить громкость при расследовании и убавить в нормальной работе, и прыгнуть сразу к ошибкам в потоке записей.

Использованные хорошо, уровни — это как держать важные строки находимыми; проигнорированные, каждый лог выглядит одинаково срочным, и ни один не выделяется.

_Diagram: Четыре уровня по важности. В обычной работе пишешь от INFO и выше; при расследовании включаешь и DEBUG._

#### Log Levels (уровни логов: DEBUG, INFO, WARN, ERROR)

- **Что это:** Метка важности на каждой строке лога.
- **Как работает:** `DEBUG`/`INFO` — рутина, `WARN` — что-то не так, `ERROR` — реальный сбой.
- **Пример:** В инциденте фильтруешь только `ERROR` и сразу видишь сбои.
- **Подвох:** Если всё пишется как `ERROR`, ничего не выделяется.
- **Связи:** Регулятор громкости против **log volume**.

### Log Volume — слишком много логов так же бесполезно, как слишком мало

> Дневник, что записывает каждый вдох, так же нечитаем, как пустой, — нужный сигнал погребён в шуме, что никто не просеет.

Логи соблазнительно переусердствовать, и **чрезмерное логирование (over-logging)** имеет реальную цену: дорого хранить, медленно искать, и оно хоронит важные строки под шумом.

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

_Diagram: Мало логов — слепота. Много — шум и счёт за хранение. Польза в середине: решения, сбои, ключевые события._

#### Log Volume (объём логов, over-logging)

- **Что это:** Логи «на всякий случай» на каждый шаг.
- **Почему плохо:** Дорого хранить, медленно искать, важное тонет в шуме.
- **Пример:** Дневник, где записан каждый вдох, — читать его так же бесполезно, как пустой.
- **Лекарство:** Логировать нарочно: решения, сбои, ключевые события.
- **Связи:** Управляется **log levels**; та же ловушка шума, что и **alert fatigue**.

> **Вопрос логов:** «Когда я буду отлаживать это позже, будет ли в логах деталь, что мне нужна, — структурированная, с уровнями и сфокусированная на важном, а не хоронящая его?»

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

## 3. Метрики

Логи рассказывают об отдельных событиях. Метрики рассказывают о целом, во времени, — числа, что показывают с одного взгляда, здорова ли система или сползает.

### Metric — число во времени

> Больничный график, отслеживающий пульс через ночь, — не каждое биение, а число, снимаемое ровно, чтобы растущий тренд бросался в глаза.

**Метрика (metric)** — это измерение, отслеживаемое во времени: запросов в секунду, доля ошибок, время ответа, использованная память. В отличие от лога, она не про одно событие — это **агрегат (aggregate)**, снимаемый непрерывно, так что ты видишь тренды и всплески.

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

_Diagram: Метрика — ряд точек во времени. Видно не отдельный запрос, а тренд и всплеск._

#### Metric (метрика)

- **Что это:** Числовое измерение, снимаемое ровно во времени.
- **Отвечает на:** «Есть ли проблема и каков тренд?»
- **Пример:** Запросов в секунду, доля ошибок, время ответа, память.
- **Плюс:** Дёшево собирать и хранить — можно держать по всему и всегда.
- **Минус:** Не знает деталей одного запроса — за ними идут в трейсы и логи.
- **Связи:** Бывает **counter** или **gauge**; смотрят на **dashboard**; основа **SLI**.

### Counter vs Gauge — счётчик растёт, датчик качается

> Одометр только лезет вверх, считая общий пробег; спидометр поднимается и падает с тем, как быстро ты едешь прямо сейчас.

Две базовые формы покрывают большинство метрик. **Счётчик (counter)** только растёт — всего обслужено запросов, всего ошибок — и ты смотришь его _скорость_ изменения. **Датчик (gauge)** ходит вверх-вниз, показывая текущее значение — память в использовании, активные соединения, длину очереди.

Знать, на что из них смотришь, говорит, как это читать: у счётчика история — это наклон; у датчика — текущая высота.

_Diagram: Счётчик как одометр: читаешь наклон (скорость). Датчик как спидометр: читаешь текущее значение._

#### Counter vs Gauge (счётчик и датчик)

- **Counter:** Только растёт: всего запросов, всего ошибок. Читаешь скорость роста.
- **Gauge:** Ходит вверх-вниз: память, активные соединения, длина очереди. Читаешь текущее значение.
- **Пример:** «Ошибок всего: 10 400» мало что говорит; «ошибок в минуту выросло втрое» — говорит.
- **Подвох:** Читать счётчик как датчик — смотреть на высоту, а не на наклон.
- **Связи:** Две формы любой **metric**.

### Dashboard — тренды становятся видны

> Стена датчиков в диспетчерской: с одного взгляда оператор видит, что всё зелёное и ровное, или что одна стрелка лезет к красному.

Метрики обычно смотрят на **дашборде (dashboard)** — графиках ключевых чисел во времени, бок о бок. Хороший дашборд даёт увидеть здоровье системы за секунды и заметить миг, когда линия согнулась не туда.

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

_Diagram: Четыре графика рядом: три ровные, а ошибки загибаются вверх в два дня — видно с одного взгляда._

#### Dashboard (дашборд)

- **Что это:** Графики ключевых метрик во времени, бок о бок.
- **Зачем:** Увидеть здоровье системы за секунды и момент, когда линия согнулась.
- **Пример:** Ошибки поползли вверх в 14:00 — видно раньше, чем дошли жалобы.
- **Подвох:** Дашборд не будит — на него надо смотреть. Срочное идёт в **alerts**.
- **Связи:** Показывает **metrics**; первые графики — **four golden signals**.

### Four Golden Signals — четыре жизненных показателя

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

Не нужна тысяча метрик, чтобы начать. **Четыре золотых сигнала (four golden signals)** покрывают бо́льшую часть здоровья системы: **latency** (задержка — сколько занимают запросы), **traffic** (трафик — сколько спроса), **errors** (ошибки — сколько запросов падает) и **saturation** (насыщение — насколько полны ресурсы).

Следи за этими четырьмя — и поймаешь подавляющее большинство проблем рано. Это жизненные показатели сервиса — первые стрелки, что ставишь на панель.

_Diagram: Четыре золотых сигнала вокруг сервиса: задержка, трафик, ошибки, насыщение._

#### Four Golden Signals (четыре золотых сигнала)

- **Проблема:** Непонятно, с каких метрик начать, а тысяча метрик — шум.
- **Идея:** Четыре числа покрывают бо́льшую часть здоровья: latency, traffic, errors, saturation.
- **Пример:** Сервис оплаты: время ответа, запросов в секунду, доля упавших, загрузка пула соединений.
- **Когда брать:** Первые графики на любой новый сервис.
- **Связи:** Ставятся на **dashboard**; из них берут **SLI**; старт практики **Start Small and Grow**.

> **Вопрос метрик:** «Отслеживаю ли я жизненные показатели — задержку, трафик, ошибки, насыщение — чтобы видеть беду трендом, до того как она станет сбоем?»

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

## 4. Трейсы

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

### Trace — путь одного запроса через сервисы

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

В современных системах один запрос скачет через много сервисов — шлюз зовёт сервис заказов, что зовёт платежи, что зовут базу. **Трейс (trace)** записывает весь этот путь для одного запроса, сшитый так, чтобы видеть каждый скачок, что он сделал.

Он отвечает на вопрос, что ни логи, ни метрики не могут: не «что случилось» или «сколько», а «каков был путь _этого конкретного запроса_ через всю систему?»

_Diagram: Один трейс — один запрос: пользователь → шлюз → заказы → платежи → база, все скачки сшиты под одним ID._

#### Trace (трейс, след запроса)

- **Что это:** Запись всего пути одного запроса через все сервисы.
- **Отвечает на:** «Где на пути этого запроса проблема?»
- **Пример:** Шлюз → заказы → платежи → база, всё под одним trace ID.
- **Цена:** Каждый сервис должен передавать ID дальше, иначе путь рвётся.
- **Связи:** Состоит из **spans**; его ID — тот самый **correlation ID**.

### Span — куда ушло время

> Маршрут поездки, разбитый на отрезки, у каждого своя длительность, — и мгновенно видно, что трёхчасовая пересадка, а не перелёты, съела день.

Трейс состоит из **спанов (spans)** — по одному на шаг, каждый замеряет, сколько занял тот кусок. Разложенные **водопадом (waterfall)**, спаны показывают ровно, где медленный запрос провёл своё время: спан базы занял 900 мс, пока всё остальное заняло 50.

Без этого «запрос был медленным» — загадка через много сервисов; с этим ты указываешь прямо на виновника. Спаны превращают смутную медлительность в точное место.

_Diagram: Водопад спанов: из 950 мс запроса 900 мс съел один запрос к базе._

#### Span (спан, шаг трейса)

- **Что это:** Один замеренный шаг внутри трейса: начало, конец, длительность.
- **Как работает:** Спаны вложены и раскладываются водопадом по времени.
- **Пример:** Спан базы — 900 мс, всё остальное вместе — 50 мс. Виновник очевиден.
- **Зачем:** Превращает «медленно где-то» в точное место.
- **Связи:** Кирпичик **trace**.

### Distributed Tracing — как отлаживают распределённые системы

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

Когда запрос падает или ползёт, а работа размазана по сервисам, трейс часто единственный способ найти где. Это и есть **распределённый трейсинг (distributed tracing)**.

Метрики говорят, что система медленна; логи говорят, что сказал каждый сервис; трейс связывает путь одного запроса вместе и указывает на точный сервис и шаг, что сломался. Для всего распределённого трейсинг — инструмент, что превращает «где-то там пошло не так» в «вот здесь».

_Diagram: Метрики говорят «где-то медленно», логи — что сказал каждый сервис, а трейс показывает конкретный сломанный шаг._

#### Distributed Tracing (распределённый трейсинг)

- **Проблема:** Работа размазана по сервисам; из финального результата не видно, какой шаг сломался.
- **Идея:** Прослеживать каждый запрос через все сервисы как один трейс.
- **Пример:** Оплата падает: трейс показывает, что сбоит шаг сервиса платежей.
- **Когда брать:** Как только запрос проходит больше чем через один сервис.
- **Связи:** Строится из **trace** и **span**; второй шаг в потоке **notice → locate → explain**.

> **Вопрос трейсов:** «Когда один запрос медленный или падает через несколько сервисов, могу ли я проследить весь его путь и увидеть ровно, какой шаг виноват?»

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

## 5. Три столпа вместе

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

### Three Pillars — каждый столп отвечает на свой вопрос

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

**Три столпа наблюдаемости (three pillars of observability)** делят работу. **Метрики** отвечают «_есть_ ли что-то не так и каков тренд?» — дешёвый, всегда-включённый обзор. **Трейсы** отвечают «_где_, через все сервисы, проблема?» — сужая до шага. **Логи** отвечают «_что именно_ там случилось?» — полная деталь на месте.

Ни один сам по себе не достаточен; каждый подхватывает там, где другие останавливаются.

_Diagram: Три столпа: метрики — есть ли проблема, трейсы — где, логи — что именно. Вместе держат наблюдаемость._

#### Three Pillars of Observability (три столпа: metrics, traces, logs)

- **Проблема:** Ни один сигнал не отвечает на все вопросы инцидента.
- **Идея:** Метрики — «есть ли проблема?», трейсы — «где?», логи — «что именно?».
- **Пример:** Только метрики: знаешь, что плохо, но не где. Только логи: тонешь в деталях без карты.
- **Когда брать:** Для любого сервиса в проде.
- **Связи:** Проходятся по порядку **notice → locate → explain**; связываются **correlation ID**.

### Notice → Locate → Explain — естественный поток

> Врач видит жар на графике, осматривает, чтобы найти, какой орган, потом гонит конкретный тест, что называет болезнь, — широкий сигнал, потом узкий, потом точный.

На практике ты движешься через них по порядку. **Метрика** или алерт говорит, что что-то не так (доля ошибок подскочила). **Трейс** показывает где (шаг сервиса платежей падает). **Лог** в той точке говорит ровно что (платёжный провайдер вернул таймаут).

От широкого к узкому к точному: **метрика замечает, трейс локализует, лог объясняет**. Знать этот поток — бо́льшая часть знания, как отлаживать прод.

_Diagram: Воронка расследования: метрика замечает, трейс локализует, лог объясняет._

#### Notice → Locate → Explain (метрика → трейс → лог)

- **Проблема:** В инциденте непонятно, с какого сигнала начать.
- **Идея:** Идти от широкого к точному: метрика, потом трейс, потом лог.
- **Пример:** Доля ошибок подскочила → трейс: сбоит шаг платежей → лог: провайдер вернул таймаут.
- **Подвох:** Начинать с grep по логам — искать иголку без карты.
- **Связи:** Работает быстро, только если сигналы связаны **correlation ID**.

### Correlation ID — нить, что связывает всё вместе

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

Столпы куда сильнее, когда связаны. Прикрепление общего **request ID** (или **trace ID**) к метрикам, трейсу и каждой строке лога для запроса даёт прыгнуть от «этот запрос упал» прямо к его трейсу и его точным логам. Это и есть **корреляция (correlation)**.

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

_Diagram: Один request_id в метрике, трейсе и логах каждого сервиса — и вся история запроса находится за один шаг._

#### Correlation ID (request ID, trace ID, корреляция)

- **Проблема:** Метрики, трейсы и логи лежат в трёх отдельных стогах.
- **Идея:** Один общий ID на запрос — в трейсе и в каждой строке лога.
- **Пример:** Ищешь `request_id=abc123` — и сразу видишь трейс и логи шлюза и платежей по этому запросу.
- **Цена:** ID надо передавать через каждый сервис и писать в каждый лог.
- **Связи:** Склеивает **three pillars**; удобно хранить полем в **structured logging**.

> **Вопрос столпов:** «Могу ли я пройти от метрики, что замечает проблему, к трейсу, что её локализует, к логам, что её объясняют, — с общими ID, что вяжут все три к одному запросу?»

> Метрики замечают, трейсы локализуют, логи объясняют — от широкого к узкому к точному. Свяжи их общими request ID, и три инструмента станут одной историей о том, что пошло не так.

## 6. Алертинг и SLO

Наблюдаемость даёт расследовать; алертинг говорит, когда начать. Сложная часть не в обнаружении проблем — в решении, какие из них стоят того, чтобы будить человека.

### Symptom-based Alerting — алертить на то, что чувствуют пользователи

> Дымовой датчик должен сработать на настоящий пожар, а не каждый раз, как кто-то делает тосты, — иначе люди вырывают батарейку и пропускают настоящий.

**Алерт (alert)** — это автоматическое уведомление, когда что-то пересекает черту. Искусство — алертить на **симптомы, что пользователи реально чувствуют (symptoms)**: падающие оплаты, медленный сайт, — а не на каждое внутреннее подёргивание.

Сервер на 80% памяти — не проблема, если пользователям хорошо; всплеск упавших заказов — да, даже если каждый сервер выглядит здоровым. Алерть на обращённый к пользователю исход, и будешь будить людей ради того, что правда важно.

_Diagram: Внутренний сигнал без вреда для пользователей — на дашборд. Симптом, который пользователи чувствуют, — повод будить человека._

#### Symptom-based Alerting (алерты на симптомы)

- **Проблема:** Алерты на каждое внутреннее подёргивание будят людей ради неважного.
- **Идея:** Будить только на исход, который чувствует пользователь.
- **Пример:** 80% памяти при довольных пользователях — не алерт. Всплеск упавших заказов — алерт, даже если серверы «зелёные».
- **Когда брать:** Для всего, что отправляет уведомление человеку.
- **Связи:** Черту задаёт **SLO**; спасает от **alert fatigue**.

### SLI / SLO / SLA — определить «достаточно хорошо»

> Служба доставки, обещающая «99% посылок приходят за два дня», — ясная, измеримая планка того, что считается приемлемым сервисом, согласованная заранее.

Три аббревиатуры формализуют «насколько хорошо достаточно хорошо». **SLI (service level indicator)** — это измерение (доля запросов, обслуженных под 300 мс). **SLO (service level objective)** — цель, что ты ставишь для него (должно быть 99,9%). **SLA (service level agreement)** — договорное обещание клиенту, с последствиями при провале.

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

_Diagram: SLI — что меряем, SLO — какая цель, SLA — что обещано клиенту по договору._

#### SLI / SLO / SLA (индикатор, цель, соглашение)

- **SLI:** Измерение: доля запросов, обслуженных быстрее 300 мс.
- **SLO:** Цель для SLI: должно быть 99,9%.
- **SLA:** Договорное обещание клиенту с последствиями при провале.
- **Зачем:** «Достаточно надёжно» становится числом — и ясной чертой, когда действовать.
- **Связи:** SLI строят из **metrics** и **golden signals**; SLO — черта для **alerts**.

### Alert Fatigue — усталость от алертов, тихий убийца

> Машина, что постоянно пищит на ерунду, приучает водителя игнорировать все писки, — так что одно предупреждение, что было важно, отсеивается со всеми остальными.

Слишком много алертов — это свой сбой: когда людей будят ради того, что не важно, они начинают игнорировать алерты целиком, и настоящий теряется в шуме — это **усталость от алертов (alert fatigue)**.

Каждый алерт должен быть **действенным (actionable)** и стоить человеческого внимания прямо сейчас; если нет — ему место на дашборде, а не в пейджере. Меньше, острее алертов бьёт поток, потому что алерт, которому никто не доверяет, хуже, чем никакого.

_Diagram: Поток шумных алертов приучает игнорировать все — и настоящий тонет. Пара точных алертов остаётся доверенной._

#### Alert Fatigue (усталость от алертов)

- **Что это:** Люди перестают реагировать на алерты, потому что их слишком много.
- **Почему плохо:** Настоящий алерт пропускают вместе с шумом.
- **Пример:** Пейджер пищит на ерунду каждый час — на важный писк уже никто не встаёт.
- **Лекарство:** Каждый алерт — действенный и срочный; остальное — на дашборд.
- **Связи:** Лечится **symptom-based alerting** и SLO; родственник **log volume**.

> **Вопрос алертинга:** «Срабатывает ли этот алерт на то, что пользователь реально чувствует и на что человек должен среагировать сейчас, — или это шум, что приучит всех игнорировать пейджер?»

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

## 7. Применять хорошо

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

### Instrument as You Build — инструментируй, пока строишь, а не после пожара

> Провести дымовые датчики, пока строишь дом, — а не стоять в дыму, жалея, что не провёл.

Худшее время добавить наблюдаемость — во время сбоя, когда обнаруживаешь, что система не говорит ничего. Так что встраивай **инструментирование (instrumentation)** по ходу: излучи метрику для новой фичи, логируй её ключевые решения, убедись, что запрос можно протрейсить через неё.

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

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

#### Instrument as You Build (инструментирование по ходу)

- **Проблема:** О пустоте в сигналах узнаёшь во время сбоя — слишком поздно.
- **Идея:** Метрика, ключевые логи и трейсинг — часть каждой новой фичи.
- **Пример:** Новая фича оплаты сразу шлёт метрику ошибок, логирует решения и пропускает trace ID.
- **Цена:** Немного работы, пока код свеж, — вместо часов гадания потом.
- **Связи:** Противоядие от **black box**.

### Start Small and Grow — начни с золотых сигналов и расти

> Новый владелец магазина сперва следит за теми немногими числами, что важны, — продажи, проходимость, жалобы, — и добавляет более тонкое отслеживание, лишь когда возникают конкретные вопросы.

Не нужно полное покрытие в первый день. Начни с **четырёх золотых сигналов** и горстки логов в ключевых точках решений, потом добавляй деталь там, где реальные инциденты покажут тебе **слепое пятно (blind spot)**.

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

_Diagram: Старт с золотых сигналов, дальше цикл: инцидент показывает слепое пятно → добавляешь деталь → покрытие растёт._

#### Start Small and Grow (начни с малого, расти по инцидентам)

- **Проблема:** Инструментировать всё заранее — долго, дорого и шумно.
- **Идея:** Старт с золотых сигналов; детали добавлять там, где удивил реальный сбой.
- **Пример:** Инцидент показал, что не видно таймаутов провайдера, — добавляешь метрику и лог именно туда.
- **Когда брать:** С первого дня любого сервиса.
- **Связи:** Стартует с **four golden signals**; держит в узде **log volume**.

### Как понятия связаны

> Приборная панель самолёта: десяток стрелок, но все про один полёт — и пилот читает их вместе.

Всё в курсе — части одной панели. Работающая система излучает три сигнала: **метрики** замечают, **трейсы** локализуют, **логи** объясняют. **Correlation ID** связывает все три к одному запросу. Из метрик и **золотых сигналов** строятся **SLI и SLO**, а по ним — **алерты на симптомы**, немногие и точные, чтобы не было **alert fatigue**. А сама панель растёт, если **инструментировать по ходу** и добавлять детали по реальным инцидентам.

_Diagram: Система излучает три сигнала; поток метрика → трейс → лог; correlation ID склеивает их; из метрик — SLO и алерты._

#### Прежде чем выкатывать сервис

- **Что он может мне рассказать** в проде — или это чёрный ящик, когда ломается?
- **Золотые сигналы** — отслеживаю ли я задержку, трафик, ошибки и насыщение?
- **Логи** — структурированы, с уровнями и сфокусированы на важных решениях и сбоях?
- **Трейсинг** — могу ли я проследить один запрос через сервисы, что он касается?
- **Корреляция** — делят ли метрики, логи и трейсы request ID?
- **Алерты и SLO** — будит ли меня то, что чувствуют пользователи, против определённой цели?

#### Признаки, что ты наблюдаешь хорошо

- Когда что-то ломается, система **говорит, куда смотреть**, а не оставляет гадать.
- Ты движешься **метрика → трейс → лог**, от «заметить» к «локализовать» к «объяснить».
- Общий **request ID** вяжет сигналы одного инцидента вместе.
- Твои **алерты** срабатывают на обращённые к пользователю симптомы, и люди им всё ещё доверяют.
- У тебя есть явные **SLO**, и ты инструментировал **пока строил**, а не во время сбоя.

## Шпаргалка: все 22 понятия

### Основы

- **Flying by Instruments** (полёт по приборам): Прод не поставить на паузу — видишь только то, что система излучает.
- **Observability** (наблюдаемость, o11y): Ответ на непредвиденные вопросы из данных системы. Monitoring — слежение за известным.
- **Black Box** (чёрный ящик): Система, что ничего не излучает: на сбое остаётся гадать.

### Логи

- **Log** (лог): Запись события с отметкой времени. Отвечает «что именно случилось».
- **Structured Logging** (структурированные логи): Событие как поля данных — логи можно запрашивать.
- **Log Levels** (DEBUG · INFO · WARN · ERROR): Метка важности: громкость вверх при расследовании, вниз в обычной работе.
- **Log Volume** (over-logging): Слишком много логов — шум и счёт. Логируй нарочно.

### Метрики

- **Metric** (метрика): Число во времени. Дёшево, всегда включено, показывает тренд.
- **Counter vs Gauge** (счётчик и датчик): Счётчик только растёт (читай наклон), датчик качается (читай значение).
- **Dashboard** (дашборд): Графики ключевых метрик рядом: здоровье за секунды.
- **Four Golden Signals** (золотые сигналы): Latency, traffic, errors, saturation — жизненные показатели сервиса.

### Трейсы

- **Trace** (трейс): Путь одного запроса через все сервисы. Отвечает «где».
- **Span** (спан): Замеренный шаг трейса; водопад спанов показывает, куда ушло время.
- **Distributed Tracing** (распределённый трейсинг): Отладка распределённой системы: «где-то» превращается в «вот здесь».

### Вместе

- **Three Pillars** (три столпа): Метрики — есть ли проблема, трейсы — где, логи — что именно.
- **Notice → Locate → Explain** (метрика → трейс → лог): Поток расследования от широкого к точному.
- **Correlation ID** (request ID, trace ID): Один ID во всех сигналах запроса — вся история за один шаг.

### Алертинг

- **Symptom-based Alerting** (алерты на симптомы): Будить на то, что чувствуют пользователи, а не на внутренние подёргивания.
- **SLI / SLO / SLA** (мера, цель, обещание): Измерение, цель для него и договорное обещание клиенту.
- **Alert Fatigue** (усталость от алертов): Слишком много алертов — их перестают слушать. Меньше и острее.

### Применять хорошо

- **Instrument as You Build** (инструментирование по ходу): Сигналы — часть постройки фичи, а не реакция на пожар.
- **Start Small and Grow** (начни с малого): Старт с золотых сигналов; детали — там, где удивил реальный сбой.

> Хорошая наблюдаемость встроена: золотые сигналы с самого начала, структурированные логи, трейсируемые запросы, скоррелированные по ID, и пара алертов, которым доверяешь, против реального SLO.

Конец экспресс-курса · 7 глав · 22 понятия

Дальше — практика: возьми один сервис и добавь четыре золотых сигнала на дашборд, поставь строку структурированного лога на его ключевые решения и убедись, что один запрос несёт ID, за которым можно проследить. Потом сломай его нарочно и попробуй продиагностировать, используя только то, что он излучает. Ценность приходит в тот миг, как ты чинишь что-то по одним сигналам, ни разу не подключив отладчик. Но держи одну мысль выше прочих: в проде ты летишь по приборам. Построй систему так, чтобы она объясняла себя, — логи для «что», метрики для «сколько», трейсы для «где», — и сбой в три ночи станет вопросом, на который ты можешь ответить, а не загадкой, что ты гадаешь.