Software Architect · Модуль 17
Observability отвечает на вопрос: можем ли мы понять, что происходит в системе, не деплоя новый код и не гадая по косвенным признакам.
Logs · metrics · traces · correlation id · alerting
Наблюдаемость нужно проектировать вместе с системой, а не прикручивать после первого большого инцидента.
Три сигнала решают разные задачи
Температура, карта и видеозапись дороги показывают разные стороны поездки. Одного прибора недостаточно.
Metrics показывают агрегированное состояние: latency, error rate, queue depth, memory, throughput. Logs дают события и контекст. Traces показывают путь запроса через сервисы.
Архитектор должен определить, какие signals нужны для критичных user journeys. Для checkout важны payment latency, failed authorizations, retry count, outbox lag, provider errors. Для контентного сайта важны cache hit ratio, build failures, p95 page load и search freshness.
Alert должен требовать действия
Сигнализация, которая пищит каждый час без причины, быстро становится частью фона.
Плохие alerts создают fatigue. Хороший alert связан с пользовательским эффектом или приближением к опасному лимиту. У него есть owner, severity, runbook и понятное действие.
Не всё должно будить ночью. Error logs без влияния на SLO могут быть dashboard-ом или ticket-ом. А падение успешных платежей должно поднимать on-call сразу.
Во время инцидента observability должна сокращать время до понимания, а не добавлять шум.
Пример: correlation id через весь request path
Номер дела в суде позволяет найти все документы, свидетелей и решения. Без номера всё ищут по памяти.
Каждый входящий запрос получает correlation id. Он проходит через API, worker, broker messages и downstream calls. Logs и traces используют этот id. Support может взять id из ошибки пользователя, а инженер быстро увидеть путь запроса.
Это резко снижает MTTR: команда ищет не «что-то около 14:03», а конкретную цепочку событий.
Антипример: логи как поток текста
Книга без глав, страниц и оглавления содержит информацию, но пользоваться ей почти невозможно.
Сервис пишет something failed, bad request, payment error, но без user id, tenant id, order id, provider code, retry count и severity. В incident review команда понимает, что данные были, но расследовать по ним нельзя.
Структурированные logs с контекстом лучше красивых строк.
- Какие SLO видны в metrics? - Можно ли проследить один запрос через все сервисы? - Какие alerts требуют немедленного действия? - Какие поля нужны в logs для расследования?