Как Alchemy использует более 230 агентов для триажа и устранения оповещений во всем парке нод

Alchemy управляет инфраструктурой для более чем 230 блокчейн-сетей и обслуживает тысячи серверов, через которые ежегодно проходят транзакции на сумму более 1 трлн долларов. Наша задача — поддерживать каждую ноду в исправном и синхронизированном состоянии, чтобы зависящие от нее приложения продолжали работать без сбоев.

За последние четыре месяца мы создали фабрику агентов, которая управляет более чем 230 отдельными агентами (по одному на каждую блокчейн-сеть) для расследования и устранения инцидентов. Медианное время устранения оповещения теперь составляет 8 минут против 30 минут у человека. Агенты самостоятельно устраняют около 73% оповещений без участия человека, а около 120 инженерных часов каждый месяц теперь направляются на более продуктивную работу вместо диагностики и исправления проблем.

Проблема: 500 оповещений в неделю в разнородной инфраструктуре

Наш парк нод генерирует более 500 оповещений в неделю для команды Node Ops. Как и любая команда разработки программного обеспечения, дежурный инженер проводит каждое оповещение через стандартную процедуру расследования из пяти вопросов:

В какой сети проблема?
Затронуты ли пользователи?
Проблема в нашем парке или выше по цепочке в самой сети? Возможно, дело в развертывании?
Случалось ли это раньше?
Что мне делать дальше?

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

Правило проектирования: оптимизация для принятия решений

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

Поэтому у нас есть одно правило: оптимизируем процесс для принятия решений.

Как это работает

1. Сначала определяем влияние, прежде чем беспокоить человека

Наша система оповещений уже обнаруживает проблемы более 500 раз в неделю. Агентам не нужно обнаруживать их заново. Их задача — решить, должен ли кто-то обращать на это внимание.

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

Если агент не обнаруживает вреда, он публикует свои выводы в отдельный информационный канал («FYI»). До дежурного канала доходят только реальные инциденты.

2. Расследования с вынесением вердикта

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

Пять реальных примеров:

Оповещение

Что обнаружил агент

Результат

Неисправная нода

1 из 6 нод неисправна, 0% ошибок сервера, повторяющаяся проблема на одной изолированной ноде

Устранено агентом

Неисправная нода

1 из 2 нод неисправна в одном регионе, 0% ошибок сервера, P95 задержка 8 мс

Устранено агентом

Все ноды неисправны

Единственная неисправная нода, 0.14% ошибок, резервная инфраструктура принимает трафик, влияния на пользователей нет

Устранено агентом

Высокая задержка

Уровень ошибок 22%, P95 задержка 10 секунд

Эскалировано; агент предложил уровень серьезности для подтверждения человеком

Сеть зависла

Седьмое зависание в этой же сети за день

Эскалировано

Инженер в первую очередь читает результат и только во вторую — доказательства, если вообще читает.

3. Действия в рамках ограничений, контролируемых кодом

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

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

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

За пределами этих путей агенты только считывают данные из баз знаний и инструкций с ограниченным доступом. Ограниченный доступ агентов — это залог успеха, когда вы позволяете агентам взаимодействовать с рабочей продакшн-инфраструктурой.

4. Сделать вывод «проблема на стороне вышестоящей системы» самым сложным

Самая забавная часть (или по крайней мере нам так кажется) управления блокчейн-нодами заключается в том, что они по своей природе ненадежны. У клиентов могут возникать проблемы, сети ведут себя по-разному при различных нагрузках, а вышестоящие операторы сети (валидаторы, секвенсоры и т. д.) могут вызывать сбои или остановку нашей инфраструктуры. Поэтому каждому агенту необходимы память и инструкции, специфичные для конкретной сети, и они нужны для ответа на один вопрос: «Это мы или они?».

Агент должен соответствовать четырем условиям, прежде чем заявить о проблеме «вышестоящей системы»:

Наши ноды должны быть исправны с точки зрения уровня ошибок и задержки.
Ошибки вышестоящей системы (например, «зависание» сети) должны выглядеть одинаково во всех регионах нашего присутствия.
Независимые провайдеры должны подтвердить это, а запросы клиентов в остальном должны выглядеть нормально.
Зависание только в некоторых регионах никогда не является проблемой вышестоящей системы.

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

Результаты: повышение надежности, более быстрое устранение

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

Оповещения устраняются почти в четыре раза быстрее. Медианное время устранения сократилось с 30 минут до 8.
Большинству оповещений вообще не требуется инженер. Агент самостоятельно устраняет около 73% оповещений по сравнению с 0% в июне.
Команда вернула около 120 часов в месяц. Инженерное время, затрачиваемое на оповещения, сократилось примерно со 150 часов в месяц до 30, что составляет 80% сокращения. Это около трех инженерных недель каждый месяц, которые теперь уходят на устранение причин, а не на восстановление контекста.
Агент прав с первого раза. Из более чем 200 расследований за последний месяц точность определения первопричины с первой попытки составила около 98%.

Что бы мы посоветовали команде, создающей собственный дежурный агент

Измеряйте результаты. Оценивайте дежурный агент по времени устранения, точности и сэкономленным инженерным часам.
Требуйте вынесения вердикта. Агент, который возвращает страницу с выводами, перенес работу, а не избавил от нее. Требуйте, чтобы он начинал с решения: устранить проблему или вызвать человека и указать степень срочности.
Предоставляйте именованные действия с фиксированной областью применения. Перезапуск одной ноды с ограничением в 24 часа безопаснее, чем прямой доступ к оболочке (shell).
Дайте каждому агенту узкую специализацию и долгую память. Один агент на сеть, знающий ее руководства, особенности и историю инцидентов, не должен заново открывать для себя вашу систему при каждом оповещении. Он уже знает, что это седьмое зависание за сегодня.

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

Нравится такой синергетический подход прикладного ИИ и инфраструктуры?