Ключевая роль платформ наблюдаемости заключается в том, чтобы помочь вам достичь бизнес- и технических целей по обеспечению непрерывной работы бизнеса по требованию при одновременном снижении затрат. За последнее десятилетие сложность управления корпоративной инфраструктурой и приложениями многократно возросла.
Появление генеративного ИИ в технологическом ландшафте усложнило систему, непреднамеренно увеличив нагрузку на команды DevOps и SRE. Корпоративная наблюдаемость генерирует огромное количество данных MELT (метрики, события, трассировки и логи), что приводит к лавине оповещений и срабатываний, и этот объем является главным источником операционной рутины. Стремление к доступности на уровне 99,999% требует видимости на каждом уровне — от оборудования до приложений, но это достигается ценой серьезной усталости от алертов.
До сих пор традиционный подход заключался в следующем: мониторить все, вручную настраивать условия оповещений, при срабатывании алерта вызывать дежурного специалиста, а процесс триажа начинается с изучения дашбордов наблюдаемости. Такой подход больше не применим в современных технологических реализациях.
Чтобы справиться с этой ситуацией, многие компании запустили виртуальных агентов ИИ SRE (инженеров по надежности сайтов). На первый взгляд многие агенты выглядят одинаково: они действуют как первая линия обороны, перехватывая оповещение до того, как оно попадет к человеку, просеивая логи и используя LLM посередине для поиска первопричины (RCA) и рекомендации шагов по устранению.
Но на практике во многих случаях опыт разработчика сводится к потерянным часам, галлюцинациям результатов, росту затрат на токены и все тому же копанию в куче дашбордов и выполнению запросов в множестве систем для поиска первопричины и устранения неполадок.
Создание SRE-агента, который обеспечивает высокую точность, низкую задержку и отсутствие галлюцинаций без превышения бюджета на токены ИИ. Системы, которая в реальном времени отображает взаимосвязи между службами, флагами функций и зависимостями команд, требует глубокого понимания основных компонентов технологического стека ИИ и создания ключевых модулей/компонентов платформы SRE, включая память, RAG-знания, доступ к репозиториям кода, деревья решений и нативные интеграции в экосистему разработчиков.
Создание SRE-агента, обеспечивающего высокую точность и малую задержку при нулевых галлюцинациях — и все это без превышения бюджета на токены ИИ — представляет собой сложную инженерную задачу. Для этого требуется система, которая поддерживает актуальную карту взаимосвязей между сервисами, флагами функций и командными зависимостями.
Для достижения этой цели требуется глубокое понимание технологического стека ИИ для создания ключевых компонентов платформы SRE, включая:
- Память и управление состоянием
- Поиск знаний на основе RAG
- Прямой доступ к репозиториям кода
- Нативные интеграции в экосистему разработчиков
Память: Подобно тому, как LLM является мозгом агентских рабочих процессов, память — это ее сердцебиение. Память предоставляет своевременную контекстную информацию для каждого запроса, что значительно повышает точность результатов. Создание высокоэффективного мультиагентного рабочего процесса требует архитектуры памяти, состоящей из нескольких подкатегорий, каждая из которых разработана с нуля для решения конкретного сценария использования. Существует кратковременная, долговременная, процедурная, эпизодическая и фактологическая память. Затем следует разработка контроллера, который управляет жизненным циклом памяти: от ее извлечения из различных пользовательских взаимодействий и системной обработки до хранения, извлечения, ранжирования и, что наиболее важно, очистки.
Поиск знаний на основе RAG: это важнейший компонент агентского рабочего процесса, который позволяет хранить и извлекать доменно-специфичные знания, необходимые для повышения точности и производительности. В случае SRE-агентов они имеют доступ к предыдущим инцидентам, отчетам по их разбору (retro), инструкциям (runbooks), например, как выполнить плавающий перезапуск кластера или выполнить определенную системную процедуру. Эта информация постоянно развивается и
Нативная интеграция в экосистему разработчиков: Чтобы обеспечить бесшовную и продуктивную работу, SRE-агент должен быть там, где работают инженеры. Когда происходит инцидент, триаж обычно проходит на корпоративных платформах для совместной работы, таких как Slack. Поскольку общение уже происходит там, для SRE-агента весьма эффективно вмешаться в качестве еще одного виртуального сотрудника — участвовать в обсуждении, давать ответы и поддерживать контекст в реальном времени.
Эффективный SRE-агент не должен быть изолированным приложением, он должен быть глубоко интегрирован в саму ткань жизненного цикла разработки программного обеспечения.
Попробуйте New Relic Autopilot.
