Модуль 6 · Урок 18 · ~10 минут

Наблюдаемость: как узнать, что сломалось

Одна идея этого урока: если о поломке тебе сообщают пользователи – наблюдаемости нет. Система должна рассказывать о себе сама, раньше клиентов.

Знакомая ситуация

Суббота, вечер. В чате школы сообщение от ученицы: «Оплатила курс, доступ не пришёл». Открываешь сервер – оказывается, бот выдачи доступов упал ещё в четверг. Двое суток люди платили и ничего не получали, а ты узнал об этом последним – от клиента, и в худшем тоне.

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

Наблюдаемость (observability) – это способность системы сообщать о своём состоянии без твоего участия. Вопрос сеньора при запуске любой фичи: «как я узнаю, что она сломалась, раньше клиентов?»

Три окна в систему

Вся наблюдаемость держится на трёх видах сигналов – это база из книги Google SRE, переведённая на простой язык:

1
Логи logsЖурнал событий: ЧТО случилось. «Оплата от Марии принята», «Ошибка: не удалось выдать доступ». Отвечают на вопрос «что произошло в 14:32?». Ключ – понятные сообщения об ошибках (вспомни урок 14): запись «Error 500» не помогает, запись «не выдан доступ: у заказа нет email» решает проблему за минуту.
2
Метрики metricsЧисла во времени: СКОЛЬКО и КАК БЫСТРО. Оплат в час, ошибок в минуту, время ответа бота. Логи – про отдельные события, метрики – про тренды: по ним видно «оплаты упали до нуля» ещё до первой жалобы.
3
Алерты alertsПравило «разбуди меня, если…». Алерт превращает наблюдение в действие: «если ошибок больше 5 за минуту – сообщение в телеграм». Без алертов логи и метрики – это камера наблюдения, которую никто не смотрит.

Плюс один простой инструмент: проверка здоровья (health check) – страница-«пульс», по которой видно, что приложение живо. Внешний сервис раз в минуту стучится в неё, и если ответа нет – шлёт тебе уведомление. Бот из истории выше был бы пойман за минуту, а не за двое суток.

Минимум для твоих приложений

Не нужен дорогой мониторинг-комбайн. Для телеграм-бота, лендинга или мини-сервиса школы достаточно трёх вещей:

1
Страница здоровьяАдрес, который отвечает «жив», плюс бесплатный внешний сервис, который проверяет её и шлёт уведомление, если ответа нет.
2
Лог ошибок с человеческими сообщениямиКаждая ошибка записывается с контекстом: что делали, с какими данными, что пошло не так. Это твоя (и агента) машина времени при разборе инцидентов.
3
Уведомление в телеграм при паденииКритические ошибки – оплата не прошла, доступ не выдан, бот упал – прилетают тебе сообщением сразу, а не ждут, пока ты заглянешь в логи.

Главное правило: просить агента закладывать наблюдаемость сразу, при создании фичи, а не после первого инцидента. Достроить сигналы «потом» – это как ставить дымовой датчик после пожара.

И второе: меряй то, что важно бизнесу. Загрузка процессора – это про сервер. «Оплат в час» и «выдано доступов» – это про школу. Первым сломается не сервер, а бизнес-процесс, и заметить это можно только по бизнес-метрике.

Как думают три уровня

ДжунУзнаёт о поломке из чата клиентов. Мониторинг – «потом, когда будет время». Каждый инцидент – сюрприз и пожар.
МидлЛоги есть, и он умеет их читать – но открывает их, когда уже горит. Наблюдение реактивное: сигналы существуют, но сами к нему не приходят.
СеньорПроектирует сигналы заранее: запуская фичу, сразу отвечает на вопрос «как я узнаю, что она сломалась?». Меряет то, что важно бизнесу: оплаты в час, а не только загрузку процессора.

Проверь себя

1. Агент закончил фичу «оплата в один клик» и спрашивает, что ещё сделать перед запуском. Какой вопрос здесь главный для сеньора?

2. У твоего бота есть подробные логи. Ночью он упал, и ты узнал об этом утром из сообщений учеников. Чего не хватило?

3. Агент предлагает мониторинг для сервиса школы: «Поставлю красивую панель с загрузкой процессора, памяти и диска». Что скажет сеньор?

Что говорить агенту уже сегодня

Источники