Вывод Искусственный интеллект как будущее обеспечения наблюдаемости?

Будущее обеспечения наблюдаемости искусственный интеллект?

За последние девять месяцев были сделаны значительные прогрессы в области генеративного искусственного интеллекта, которые затронули практически все отрасли. Какие возникают последствия для того, как мы осуществляем наблюдение и мониторинг наших производственных систем?

Я предполагаю, что следующий этап развития в этой области будет представлен новым классом решений, называемых “вычислением вывода”, то есть прямым определением источника ошибки для разработчика с приемлемой точностью.

В этой статье мы рассмотрим:

• Вычисление вывода как естественный следующий шаг в области наблюдаемости.
• Уроки, извлеченные из AIOps – почему он не смог получить широкое распространение и какие это имеет последствия для вычисления вывода.
• Некоторые выявленные принципы для класса решений вычисления вывода.

Текущая ситуация

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

• Понимание пропущенных данных абсолютное руководство для специалистов по анализу данных
• Утопая в данных? Озеро данных может стать вашим спасателем
• База данных векторов Руководство для начинающих!

Если мы начнем с этого, мы увидим, что существуют три различных уровня поддержки, которые могут предоставить инструменты:

• Уровень 1: “Оповестить меня, когда что-то не так в моей системе” – мониторинг.
• Уровень 2: “Сообщить мне, почему что-то не так (и как это исправить)” – давайте назовем это вычислением вывода.
• Уровень 3: “Исправьте это сами и сообщите мне, что вы сделали” – автоматическое устранение ошибок.

Инструменты мониторинга достаточно хорошо выполняют уровень 1 (обнаружение проблем). Естественным следующим шагом является уровень 2, где система автоматически сообщает нам, почему что-то ломается. У нас еще нет решений, которые могли бы это делать, поэтому мы добавили категорию инструментов, называемых наблюдаемостью, между уровнями 1 и 2, целью которых было “помочь нам понять, почему что-то ломается”. Суть этого заключается в “любых данных, которые могут потенциально помочь нам понять, что происходит”.

Наблюдаемость против вычисления вывода

Проблема с наблюдаемостью сегодня

Основная проблема с наблюдаемостью сегодня заключается в том, что она имеет нечеткое определение и реализацию. Это объясняется тем, что мы не знаем заранее, какие данные нам понадобятся; это зависит от проблемы. Производственные ошибки обычно неожиданны и имеют длинный хвост; если бы их можно было предсказать, они были бы устранены. Поэтому мы собираем широкий спектр типов данных: метрики, журналы, распределенные трассировки, данные об ошибке в стеке вызовов, события K8s и непрерывное профилирование, чтобы обеспечить некоторую видимость, когда что-то идет не так.

Лучший способ понять наблюдаемость так, как она реализована на практике, это “все, что находится за пределами метрик, плюс метрики”.

Наблюдаемость на практике

Платформа наблюдаемости также должна принимать решения о том, сколько данных следует собирать и хранить. Это решение на данный момент принимается клиентами, и клиенты обычно собирают как можно больше данных, насколько это позволяют их возможности. Быстрое принятие облачных технологий и моделей SaaS позволило собирать и хранить огромные объемы данных.

Основной причиной сбора всё большего разнообразия и объема данных наблюдаемости является вопрос: “Что, если что-то сломается, и у меня не будет достаточно данных, чтобы устранить проблему?” Это – страшный кошмар для каждой инженерной команды. В результате этого сегодня у нас сложилась такая ситуация:

• Типы данных наблюдаемости постоянно расширяются.
• Объемы данных наблюдаемости растут.
• Увеличивается разброс инструментов – в среднем компания использует 5 и более инструментов для наблюдения.

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

Вычисление вывода: наблюдаемость плюс искусственный интеллект

Я утверждаю, что следующим шагом после наблюдаемости является вычисление вывода – когда платформа может объяснить, почему произошла ошибка, чтобы мы могли ее исправить. Это стало возможным в 2023 году благодаря быстрому развитию моделей искусственного интеллекта за последние несколько месяцев.

Представьте себе решение, которое:

• Автоматически выявляет только те ошибки, которые требуют немедленного вмешательства разработчика.
• Точно сообщает разработчику, что является причиной проблемы и где она находится – этот контейнер, этот сервер, этот путь кода, этот тип запроса.
• Помогает разработчику исправить ошибку.
• Использует фактические действия разработчика для непрерывного улучшения своих рекомендаций.

В этой области наблюдается некоторая ранняя активность, но мы все еще на очень ранней стадии, и мы можем ожидать появления нескольких новых компаний здесь в течение следующих нескольких лет.

Однако, любая беседа о сочетании ИИ и наблюдаемости будет неполной без обсуждения ИИОПс, который давал ту же обещанную возможность (использовать ИИ для автоматизации операций производства) и увидел волну инвестиций между 15 и 20 годами, но имел ограниченный успех и затих. Для полного исследования причин неудачи ИИОПс прочитайте статью – AIOps Is Dead.

Избегая ловушек ИИОПс

Исходное предположение ИИОПс заключалось в том, что если мы передадим данные из пяти или шести различных источников наблюдаемости в одну объединяющую платформу, а затем применим ИИ ко всем этим данным (метрики, логи, зависимости, трассировки, конфигурации, обновления, события K8s), мы сможем получить понимание причин поломки.

Архитектура платформы ИИОПс.

Хотя это звучит привлекательно в теории, это предположение оказалось недостаточным по нескольким причинам.

Во-первых, объединение всего оказалось непрактичным и гораздо более сложной задачей, чем ожидалось. Различные инструменты наблюдаемости собирали разные данные о разных системах в разные промежутки времени, и они предоставляли различные подмножества собранных ими данных стороннему инструменту. Кроме того, у каждого отдельного клиента были свои собственные практики сбора данных. Например, у предприятий могло быть несколько различных инструментов наблюдаемости с высоко настраиваемым и нестандартным сбором данных, и предприятие должно было вручную предоставлять контекст об этом новому инструменту ИИОПс. Все это влияло на качество ответа/выявления корневой причины, к которым могли прийти модели МО, и на создаваемую ими ценность.

Во-вторых, модель ИИОПс была слишком общей и неориентированной на конкретные случаи использования. Например, на какие конкретные виды ошибок нацелены модели? Ошибки инфраструктуры/ошибки кода/жесткие ошибки/мягкие ошибки? Большинство платформ ИИОПс шли довольно широко здесь и пытались включить в себя восемь различных типов данных в надежде найти паттерны и аномалии, и слишком много зависели от того, сколько данных и какого качества клиент передавал в платформу, что влияло на качество их вывода.

В-третьих, процесс интеграции в каждой компании был слишком сложным. У крупной компании есть фрагментированный набор инструментов наблюдаемости, которыми пользуются десятки различных команд. Платформа ИИОПс должна быть интегрирована во все эти инструменты, чтобы принести пользу. Даже в случае модуля ИИОПс в крупной платформе наблюдаемости, такой как Datadog или DynaTrace, требовалось, чтобы весь стек наблюдаемости был переведен к одному поставщику (включая инфраструктуру и метрики приложения, логи, распределенное трассирование, мониторинг ошибок и так далее), чтобы модуль ИИОПс был эффективным.

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

В результате этого многие ранние пользователи инструментов ИИОПс стали разочарованы, и большинство компаний вернулись к простому механизму “сбор данных и отображение на панелях инструментов” для своих потребностей.

Несколько уроков из этого будут применимы и могут быть изучены и применены при попытке вывода.

Принципы вывода

Вывод должен отличаться несколькими способами для более эффективного достижения конечной цели.

Создано c учетом ИИ с самого начала

Решение вывода должно быть спроектировано с самого начала для использования ИИ, то есть сбор данных, обработка, конвейер, хранение и пользовательский интерфейс разработаны с учетом “выявления причин проблем с помощью ИИ”.

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

Как бы это выглядело на практике?

Full-Stack AI-нативная архитектура с сбором данных, обработкой, хранением и визуализацией

Решение вывода должно быть вертикально интегрированным – оно должно собирать телеметрические данные, обрабатывать данные и владеть конвейером данных и слоем взаимодействия с пользователями.

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

Также критически важно, чтобы решение Inferencing могло собирать необходимые данные в нужном формате с нужным контекстом из среды клиента, чтобы иметь контроль над эффективностью обнаружения причин ошибок и опытом пользователя.

Адаптивный сбор данных

Решение Inferencing должно иметь интеллект, встроенный в сам процесс сбора данных. Это означает, что агент должен иметь возможность анализировать поступающие данные и в момент принимать решение о их захвате или отбрасывании.

Сегодня все агенты инструментации являются “глупыми” – они просто делают снимок всех данных и отправляют их, а обработка происходит позже. В настоящее время это имеет смысл, потому что мы в основном используем кодовые агенты, и мы хотим, чтобы агенты были как можно более легкими и добавляли минимальную нагрузку.

Однако с появлением технологий, таких как eBPF, которые позволяют нам собирать данные из ядра с минимальной нагрузкой, возможно представить интеллектуальный агент инструментации, который активно решает проблему качества данных, необходимых для моделей Inferencing.

Настройка обработки данных для конкретных случаев использования

В Inferencing все техники обработки данных должны быть сосредоточены вокруг конкретных случаев использования – например, как надежно определить ошибку типа A? И ошибку типа B? И так далее.

Все модели обработки данных должны следовать принципу надежного обнаружения причин ошибок и постепенно расширять количество типов ошибок, которые они могут идентифицировать по мере развития моделей. Это может привести к различным типам данных, потокам данных и подсказкам для каждого типа ошибок. Мы можем иметь некоторые платформы Inferencing, которые лучше всего подходят для обнаружения причин ошибок в инфраструктуре, некоторые для проблем безопасности, некоторые для кодовых ошибок и т.д., при этом каждый тип собирает немного разные наборы данных с немного разными потоками данных и другой моделью фреймворка.

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

Хранение, разработанное для ИИ

Представление хранения в мире Inferencing уже отличается от того, что в мире мониторинга или наблюдаемости. Теперь у нас есть огромные хранилища данных для всего, что происходит, но в инференции нам нужно только хранить наиболее актуальные и последние данные, необходимые моделям ИИ для надежного обнаружения причин ошибок. Это может включать несколько практик – хранение данных в векторных базах данных для удобной группировки и извлечения, хранение только небольшой части успешных случаев и отбрасывание остальных, удаление дубликатов ошибок и т.д.

В результате объем хранилища, необходимого для решений Inferencing, может быть даже меньше, чем у традиционных решений мониторинга и наблюдаемости.

Проще, более интерактивный пользовательский интерфейс

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

Резюме

В заключение, вероятно, произойдут кардинальные изменения в области мониторинга и наблюдаемости с недавними разработками в области Gen. AI.

Первая волна решений, вероятно, будет напоминать платформы AIOPs прежних лет, с тонким обертыванием Gen. AI вокруг существующих данных наблюдаемости. Лидеры рынка находятся в лучшем положении для победы в этой волне. Это, вероятно, будет похоже на Github Copilot – вы получаете хорошее предложение примерно в 10% случаев. Однако настоящий прорыв, вероятно, наступит через пару лет с появлением нового класса решений Inferencing, которые смогут точно обнаруживать причины ошибок в 80% и более случаев. Для этого им необходимо быть полнофункциональными и контролировать сбор данных, их обработку, хранение, модели и взаимодействие с пользователем. Мы рассмотрели некоторые начальные гипотезы о том, в чем Inferencing решения будут отличаться от существующих практик в каждой части стека.