Как перестать тушить пожары в разработке: Observability без миллиарда на Prometheus и Loki

Автор: Олег Казаков · Spectr

Олег Казаков — CTO в Spectr, выступал на митапе Spectr в сентябре 2025 года. Spectr — продуктовая IT-компания, и Казаков рассказывает о внедрении observability изнутри: не как консультант, а как человек, который жил с проблемой и решал её в работающем продукте.

«Тушение пожаров» — это диагноз: команда реагирует на инциденты после того, как они случились, вместо того чтобы видеть деградацию заранее. Observability меняет режим работы с реактивного на проактивный. Казаков разбирает, как это сделать без enterprise-бюджета: стек Prometheus + Loki, который покрывает 90% потребностей продуктовой команды, и подход к внедрению в существующий продукт без остановки разработки. Центральный тезис: не нужен Datadog за сотни тысяч долларов в год. Нужны правильные метрики, алерты, которые срабатывают до того как пользователи пишут в поддержку, и процесс, который команда реально использует.

Кому смотреть: CTO и техлидам продуктовых компаний, у которых observability — это «когда-нибудь потом» или «слишком дорого», и которые хотят конкретный стек и подход для старта.

Из этого можно взять в работу: определи три метрики, которые лучше всего описывают здоровье твоего продукта (p95 latency, error rate, длина очереди задач). Настрой алерты только на них — всё остальное потом. Три правильных алерта лучше, чем 300 шумящих.

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

Стек: Prometheus для метрик (сбор и хранение time series), Loki для логов (log aggregation от Grafana Labs, более дешёвая альтернатива ELK), Grafana для визуализации обоих. Всё self-hosted, без vendor lock-in. Казаков приводит приблизительные цифры инфраструктурных затрат — в разы дешевле managed решений типа Datadog или New Relic при сопоставимом функционале для команды до 20 человек.

Как внедрялось в работающий продукт. Первый шаг — instrumentation: добавить Prometheus-клиент в сервисы и начать экспортировать базовые метрики (HTTP статусы, latency, memory). Это не требует остановки разработки. Второй шаг — alerting: настроить алерты на RED-метрики (Rate, Errors, Duration) для ключевых endpoint-ов. Третий шаг — log correlation: структурированные логи с trace ID, чтобы от алерта по метрике можно было перейти к конкретным запросам в Loki.

Alert fatigue — отдельная тема. Если алертов много и они часто ложные, команда перестаёт на них реагировать. Принципы Казакова: алертировать на симптомы (пользователь получает ошибки), не на причины (CPU > 80%); использовать скользящие средние и аномалии вместо фиксированных порогов; каждый алерт должен требовать конкретного действия.

Результат в Spectr: переход от «узнаём об инциденте от пользователей» к «алерт приходит за 5–10 минут до того, как пользователи начинают жаловаться». Не идеально, но принципиально другой режим работы.