Клиент давит, а вы не знаете, почему система тормозит? Это не совсем ваша вина

На бумаге Observability должен быть инструментом, доступным каждому разработчику, продакт-менеджеру и специалисту по эксплуатации. Но реальность совершенно иная.

Автор: Юваль Сусманович

Вы наверняка знакомы со следующим сценарием: система работает в продакшене, выглядит исправной, но внезапно клиент сообщает, что она работает медленно, или одна из функций не функционирует должным образом. И тогда вы начинаете поиски: изучаете логи в одной системе, просматриваете метрики во второй, проверяете трассировки (traces) в третьей и пытаетесь сопоставить информацию, чтобы понять, кроется ли корень проблемы в коде, инфраструктуре или данных клиента.

Системы, которые мы разрабатываем, не всегда ведут себя так, как мы ожидаем. Причины варьируются от упущений при реализации требований до неожиданных «узких мест» или факторов, не учтенных в сценариях использования клиентом. Ответственность за понимание происходящего в системе в режиме реального времени ложится на плечи команд разработки.

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

Да, но…

На бумаге Observability должен быть доступен каждому, но на практике он часто остается уделом экспертов, таких как команды DevOps или SRE. У этого есть три основные причины:

1. Переизбыток информации: Дашборды переполнены графиками, логами и сложными трассировками. Разработчику приходится погружаться в море данных, разбираться в сложных запросах и отфильтровывать шум.

2. Отсутствие стандартизации: Во многих организациях нет единообразия. Один проект написан на Node.js, второй — на Python, третий работает в другой облачной среде. Нет единого языка и «золотого пути». Разработчику, переходящему между проектами, каждый раз приходится заново учиться исследовать сбои.

3. Больше кода, меньше времени: Инструменты ИИ позволяют создавать код быстрее, но огромное количество сервисов делает систему настолько запутанной, что исследователь уже не знает свой код в деталях. Observability требует понимания того, что искать, но при драматическом росте сложности систем разработчики просто не знают, с чего начать.

Observability превратился из инструмента для получения ответов в огромную базу данных, требующую экспертных знаний. Естественным решением является создание ИИ-агентов, но если каждый проект имеет разную структуру логов и инструментов, нам придется создавать сотни разных агентов. Чтобы один агент мог помочь всей организации, необходима стандартизация.

---

Четыре шага к созданию Observability

Решение изменить способ создания Observability требует мужества, так как связано с инвестициями времени и денег. Но при разбиении задачи на четкие шаги путь становится проще.

1. Изменение метода отчетности

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

2. Переход к проектам с открытым исходным кодом

Следующий этап — замена технологий конечных точек. Мы отказались от платных поставщиков (Grafana, Coralogix, Dynatrace, New Relic, Datadog) в пользу Prometheus (метрики), OpenSearch (логи) и Jaeger (трассировки). Это не только экономия, но и независимость от проприетарных моделей данных, что позволяет нам полностью контролировать информацию.

3. Интеллектуальная инфраструктура оповещений

После унификации телеметрии мы создаем систему проактивных оповещений. Цель — выявлять аномалии и «узкие места» в режиме реального времени. Система должна быть «живой»: с ростом нагрузок требуется постоянная настройка для минимизации ложных срабатываний (False Positives). Все определения оповещений управляются в Git-репозитории и развертываются через Helm.

4. Обеспечение доступности через IDP

Мы построили IDP (Internal Developer Portal), который делает телеметрию доступной как для отдельных проектов, так и в консолидированном виде. Это позволяет видеть корреляции между метриками, логами и трассировками. Организации могут использовать Backstage от Spotify или разработать портал с нуля для большей гибкости.

Следующим этапом является подключение интеллектуального агента к инструментам мониторинга через MCP. Поскольку все проекты работают в одном формате, одного качественного агента достаточно для обслуживания всей организации через чат-бот в IDP.

---

Не просто замена одного инструмента другим

Спустя два года мы достигли существенных изменений:

• Независимость от экспертов: Информация доступна всем, и каждый разработчик может исследовать проблему самостоятельно.

• Супер-агент: Мы разработали агента, который работает поверх всех данных и дает полный анализ за считанные минуты с точностью 90%.

• Прогнозные системы: Алгоритмы машинного обучения теперь предупреждают о проблемах с высокой вероятностью возникновения, позволяя предотвратить их заранее.

«Золотой путь» — это концептуальное изменение: переход от мира, где каждая команда выбирает свои инструменты, к миру с единым языком и инфраструктурой. Это необходимое условие для развития организации в эпоху ИИ.