Databricks открыла бету агента для расследования сбоев в данных

Если утренний отчёт показывает цифры за вчера, источник проблемы может находиться далеко от самого отчёта. Загрузка остановилась, задача завершилась с ошибкой или одна из таблиц не обновилась вовремя. В Databricks такую проверку можно поручить Genie ZeroOps. В бета-версии агент следит за выбранными ресурсами в фоне и заводит отдельную карточку на проблему, которую обнаружил.

Что агент берёт под наблюдение

Администратор включает Genie ZeroOps в разделе Previews. Затем в Jobs & Pipelines пользователь выбирает, какие задания, конвейеры и таблицы отслеживать. Область можно задать обычным текстом в чате Genie Code, например включить все задания, которыми он владеет. Для ресурсов нужны соответствующие права просмотра или управления.

После настройки агент просматривает предыдущие 24 часа и поднимает уже случившиеся сбои, устаревшие или неполные таблицы. Новые случаи появляются в общей очереди. Для оповещений есть Slack, Microsoft Teams, PagerDuty и вебхуки. Чтобы их использовать, администратор должен заранее настроить точки назначения в рабочем пространстве.

От карточки до исправления

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

Дальнейшее действие зависит от того, где лежит код. Для файлов рабочего пространства Genie Code может применить изменение по команде пользователя. Если задание работает с Git, ZeroOps способен подготовить изменение для отдельной ветки. Отправка в репозиторий происходит после явной команды и подтверждения. Для этого нужны права записи, а сам pull request дальше проходит обычное ревью команды.

Очередь инцидентов после исправления

Карточку можно закрыть вручную после проверки. Для сбоя задания ZeroOps также умеет обновить статус после следующего успешного запуска. Databricks указывает, что это обычно занимает до 15 минут. В очереди доступны фильтры по состоянию инцидента, чтобы разбирать открытые случаи отдельно от исправленных.

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

Что проверить при настройке

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

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