Когда Ansible‑автоматизации становится много: разбираем Automation Dashboard в Astra Automation 2.1

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

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

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

Для таких задач в Astra Automation 2.1 появился Automation Dashboard.

Контроль сценариев при росте инфраструктуры

В системах на базе Ansible данные о заданиях уже есть в истории запусков, логах, статусах, сведениях об inventory и пользователях. Их можно смотреть в контроллере, получать через API, выгружать во внешние системы и собирать собственные отчеты.

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

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

В Dashboard доступны данные о:

- Количестве и динамике запусков

- Длительности выполнения заданий

- Успешных и неуспешных операциях

- Активности пользователей

- Востребованности шаблонов заданий и сценариев

- Затраченном времени для оценки экономии ресурса с помощью автоматизации

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

Допустим, сценарий обновления серверов запускается несколько сотен раз в месяц. По отдельным логам видно, что время от времени он завершается с ошибкой. 
На дашборде может оказаться, что сбои происходят регулярно и затрагивают одну группу хостов. Тогда причину уже имеет смысл искать в inventory, правах доступа, параметрах подключения или самом playbook’е, 
а не разбирать каждый неуспешный запуск отдельно.

Метрики для эксплуатации

Инженерной команде дашборд нужен прежде всего для работы с качеством сценариев и нагрузкой на платформу.

По данным Dashboard можно:

- Найти задания с высокой долей ошибок

- Сравнить длительность типовых операций за разные периоды

- Заметить рост числа запусков и подготовиться к изменению нагрузки

- Выделить сценарии, которые требуют оптимизации

- Понять, какие шаблоны давно не используют и стоит ли их поддерживать дальше

Метрики сами по себе не объясняют причину ошибки. Dashboard не заменяет логи, мониторинг и расследование инцидентов. Его задача — подсветить участок, который требует внимания, и помочь расставить приоритеты.

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

Данные для управленческих решений

У команды, которая развивает автоматизацию, часто возникает вопрос о том, какие сценарии приносят наибольшую пользу и куда стоит направить ресурсы.

Количество playbook’ов здесь мало о чем говорит. Один сценарий может запускаться редко, но закрывать критичную операцию. Другой работает каждый день, но требует регулярного ручного вмешательства. Третий формально существует, но больше не используется.

Dashboard позволяет сопоставить активность, успешность и длительность запусков. На этой основе проще понять:

- Какие процессы автоматизированы в реальной работе, а не только описаны в репозитории

- Какие команды используют платформу активнее других

- Где автоматизация растёт, а где не получила распространения

- Какие сценарии стоит доработать, масштабировать или вывести из эксплуатации

- Какие направления требуют дополнительной инфраструктуры или поддержки

Руководитель сам определяет приоритеты для инвестиций, а Dashboard дает для этого основу в виде данных о востребованности сценариев, результатах их выполнения, длительности операций и потенциальной экономии времени.

Событийная автоматизация

Особенно заметна польза аналитики в сценариях Event-Driven Automation.

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

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

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

Это важно для процессов, которые затрагивают критичную инфраструктуру:

- Обновление систем

- Управление конфигурациями

- Настройка сетевого оборудования

- Применение политик безопасности

- Реакция на инциденты

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

Что еще изменилось в версии 2.1

Automation Dashboard — одно из ключевых функциональных изменений Astra Automation 2.1.

В релиз также вошли доработки, связанные с установкой и эксплуатацией платформы.

Компоненты Astra Automation можно разворачивать в контейнеризированном виде. Команда получает ещё один вариант установки и может использовать привычные процессы эксплуатации контейнерных приложений.

Доработан и механизм предварительной диагностики Fast Fail. Перед развертыванием платформа проверяет синхронизацию времени, сетевую доступность компонентов, свободное место на диске, параметры балансировщика и базы данных Automation Gateway.

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

Подробнее о составе платформы Astra Automation и её возможностях можно прочитать в предыдущей статье на Хабре, а также на портале документации.