Я часто прихожу на разбор инцидента, где каждый отдельный инструмент формально работает. Prometheus собирает метрики, в Grafana есть dashboards, логи доступны для поиска, alerts доходят до on-call канала. Но первые двадцать минут команда все равно выясняет: проблема реальная? кто владелец? каких пользователей она затронула? что изменилось?
Обычно это не поломка инструмента. Это разрыв в пути от production-симптома до инженерного решения. Именно этот путь я проверяю на observability audit, потому что еще один dashboard редко его чинит.
Я начинаю с инцидента, а не со списка технологий
Список инструментов показывает, что компания установила. Timeline инцидента показывает, что система действительно позволяет сделать под давлением. Я беру один-два недавних инцидента и восстанавливаю первый сигнал, первую полезную гипотезу, передачи между командами и момент, когда стало понятно влияние на пользователей.
Так быстро отделяется telemetry, которая просто существует, от telemetry, которая помогает. Dashboard, открытый после того, как причина уже найдена, является документацией, а не обнаружением. Alert, который проходит через пять команд до определения владельца, является рассылкой, а не реакцией.
- Какой симптом первым оказался надежным?
- Можно ли было перейти от влияния на сервис к вероятной зависимости?
- Совпадали ли labels, названия сервисов и владельцы в metrics, logs и traces?
- Alert подсказывал решение или только сообщал условие?
Чаще всего не хватает контекста
В production обычно не мало сигналов. Не хватает согласованного контекста. Один workload может называться по-разному в Kubernetes, dashboard и support ticket. Environment, region, version и customer tier теряются между сбором и визуализацией.
Я задаю минимальную полезную идентичность сервиса и провожу ее через весь telemetry pipeline. Semantic conventions OpenTelemetry помогают единообразно называть атрибуты, но главное здесь не стандарт, а договоренность: команда должна одинаково понимать, как называется сервис и кто им владеет.
Page должен начинать расследование
Prometheus рекомендует alerting по симптомам и только тогда, когда уведомление требует действия. Я использую это как практический тест. Page должен объяснять, какое пользовательское обещание под угрозой, кто выполняет первое действие и где лежат следующие данные.
Не нужно помещать в уведомление огромный runbook. Нужно убрать неоднозначность: severity, владелец, ссылка на сфокусированный view, короткое первое действие и labels, по которым событие сопоставляется с deployment или изменением зависимости.
Если alert не меняет решение человека, я не считаю его поводом для page.
Что я меняю после ревью
Результат работы — приоритетный план исправлений, а не абстрактный maturity score. Каждую находку я связываю с задержкой, которую она создала: detection, validation, routing, diagnosis или recovery. Сначала исправляю несколько путей, влияющих на большинство инцидентов, и только потом обсуждаю перестройку платформы.
- Единая карта сервисов и владельцев во всем стеке
- Небольшой набор user-impact views для критичных сервисов
- Alert rules с действием, severity и runbook
- Deployment и config changes рядом с operational signals
- Короткая проверка на реальном или безопасно смоделированном отказе
Какой результат мне нужен
Я считаю работу успешной, когда первый responder может перейти от симптома к владельцу и обоснованной гипотезе, не держа архитектуру в памяти. В этом разница между мониторингом компонентов и эксплуатацией сервиса.
Дополнительная telemetry может понадобиться позже. Сначала я заставляю уже имеющиеся данные отвечать на вопросы, которые люди задают во время инцидента. Обычно это самый короткий путь к спокойному on-call и понятной ценности observability.
