Архитектура

Observability stack для оператора: видеть систему до жалоб клиента

Метрики, логи, трейсы — три pillar'а, без которых operator летит вслепую. Архитектура observability для multi-system телеком-ландшафта.

Обсудить задачу

Зачем оператору unified observability

В типичном операторе observability фрагментирована: network team имеет свой NMS, IT — Zabbix или Nagios, app team — свой APM, biller — свои логи в файлах. Когда инцидент пересекает границы команд, никто не видит full picture.

Результат: первое уведомление о проблеме приходит из contact-center («клиенты жалуются»), а не из системы мониторинга. К моменту обнаружения impact уже масштабный.

Unified observability — архитектурный подход, при котором три класса данных (metrics, logs, traces) собираются и коррелируются на единой платформе, доступной всем engineering командам.

Three pillars

Metrics. Числовые показатели, агрегированные во времени. CPU, memory, request rate, latency p50/p95/p99, error rate. Time-series store (Prometheus, InfluxDB, cloud-native). Дешёвые, быстрый query, ограничены по cardinality.

Logs. Структурированные события с контекстом. Детальные, полнотекстовый поиск. Log aggregation (Elastic, Loki, Splunk). Дороже metrics, но больше детали.

Traces. End-to-end путь запроса через несколько систем. Понимание distributed system. Distributed tracing (Jaeger, Zipkin, Tempo). Особенно важно для микросервисной архитектуры.

Без всех трёх получается слепая зона. Metrics показывают «что-то не так», logs объясняют «что именно», traces — «где конкретно».

Структурные элементы платформы

Collectors. Агенты на каждой системе, которые отправляют metrics/logs/traces в централизованный stack. Standard: OpenTelemetry collectors.

Pipelines. Потоковая обработка (фильтрация, enrichment, sampling) перед записью в storage.

Storage. Tier’ы: hot (последние часы, fast query) → warm (дни, slower) → cold (долгое хранение для compliance).

Query layer. Unified UI для exploration — по metrics, logs, traces — с возможностью быстро перейти от метрики к relevant логам и trace.

Alerting. Threshold и anomaly-based alerts. Routing — кто получает alert по какому компоненту. Alert fatigue management — suppression, dedup, escalation.

Dashboards. Per-system, per-service, per-business-flow. Не «один большой dashboard», а layered set.

Где обычно ломается

Каждая команда имеет свой stack. Корреляция инцидента между системами невозможна без человека, который собирает данные вручную.

Sampling слишком aggressive — при инциденте нет нужных traces, чтобы расследовать.

Alerts не tuned — приходит 200 alerts в день, команда игнорирует. Critical alert тонет в шуме.

Logs не structured — каждая команда логирует в своём формате, корреляция невозможна.

Retention слишком короткий — при post-mortem нужны данные за неделю, а есть только за два дня.

Cost out of control — observability стоит больше, чем приложения, которые она мониторит. Без discipline это инфляционная стоимость.

SLI / SLO дисциплина

Без SLI (service level indicators) и SLO (objectives) observability — просто dashboards. С SLO появляется бизнес-смысл.

Per service:

SLI: что меряем (availability, latency, error rate)
SLO: целевой уровень (например, 99.9% availability за квартал)
Error budget: допустимое отклонение

Когда error budget исчерпан — release запрещён, команда фокусируется на reliability. Это операционная дисциплина, не просто метрика.

Operating model

Owner — Head of SRE / Platform Reliability. Не каждая команда сама — central function с standards, остальные следуют.

Команды:

Platform engineering (collectors, pipelines, storage, query, alerting)
SRE per critical service (defines SLI/SLO, on-call)
Service owners (используют platform, отвечают за свои SLO)

Routine — еженедельный SLO review, ежеквартальный reliability review, post-mortem на каждый significant incident.

Что меряется

MTTD (mean time to detect) — сколько от инцидента до alert.

MTTR (mean time to resolve) — сколько от alert до resolution.

Alert noise ratio — какая доля alerts оказалась actionable.

SLO compliance — какая доля services в зелёной зоне.

Cost per metric / log / trace — экономика observability.

Как SamaraliSoft подключается

Observability Blueprint — 6-8 недель. Inventory current observability fragments, дизайн target stack, SLI/SLO framework для critical services, governance, choice of platform (open-source: Prometheus + Grafana + Loki + Tempo; managed: Datadog, NewRelic; cloud-native). Pilot — обычно один critical service end-to-end.