Ansible Automation Platform 2.4: EDA становится стабильным и мы переводим первого клиента в полный автопилот

Red Hat выпустила Ansible Automation Platform 2.4, и первое, что мы сделали - проверили список изменений в части Event-Driven Ansible. После нескольких месяцев с 2.3, где EDA работал, но требовал постоянного присмотра, хотелось конкретики: что именно починили, а не просто «улучшена стабильность».

Конкретика нашлась. И нашёлся клиент, которого мы наконец переключили из режима «параллельно с дежурным» в полноценный автопилот.

Что изменилось в 2.4 по части EDA

Главное изменение - eda-server переработан в части управления активациями. В 2.3 активация иногда молча умирала при перезапуске пода, и узнать об этом можно было только заглянув в UI или получив звонок от клиента. В 2.4 появился healthcheck контроллер активаций: упавшая активация перезапускается автоматически, и в истории остаётся запись о рестарте. Звучит как базовая вещь - но именно её не хватало для производственного использования.

Второй значимый момент - нормальная поддержка air-gapped окружений. В 2.3 установка в изолированную сеть была технически возможна, но требовала изрядного шаманства с зеркалами образов и переменными инсталлятора. В 2.4 Red Hat наконец оформила это как поддерживаемый сценарий с документированной процедурой. Для наших клиентов из КИИ это принципиально: изолированные сегменты - не исключение, а норма.

Из того, что заметили при обновлении: Decision Environment теперь лучше версионирован, и принудительное обновление образа при изменении rulebook-а стало предсказуемым. В 2.3 иногда непонятно было, какой именно образ используется активной активацией - приходилось смотреть через API.

Почему именно сейчас перевели клиента в автопилот

В июле мы запустили EDA + Zabbix + AWX на первом клиенте в режиме «дежурный всё равно смотрит». Полгода собирали статистику: сколько срабатываний, сколько из них правильных, сколько случаев, когда автоматика запускала плейбук и он делал что-то не то.

Итог шести месяцев: из нескольких десятков реальных срабатываний по перекрытым сценариям (nginx, несколько прикладных сервисов, заполнение диска под логи) ни одного случая, когда плейбук навредил. Было два случая, когда он не помог - сервис упал по причине, которую плейбук не умеет устранять (проблема с зависимостью, которая требует ручного вмешательства). В обоих случаях плейбук отработал корректно, алерт остался активным, и дежурный получил уведомление как обычно.

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

Конкретный результат: 90 секунд вместо 15 минут

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

С EDA цепочка другая: Zabbix фиксирует проблему - уходит webhook в EDA - EDA проверяет rulebook - запускается job template в Controller - плейбук восстанавливает сервис. От момента срабатывания триггера в Zabbix до завершения плейбука - около 90 секунд на типичном сценарии. Из них секунд 10-15 - сам EDA и запуск job, остальное - время выполнения плейбука.

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

Как устроен rulebook для сервисов

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

rules:
  - name: Recover application service
    condition: >
      event.payload.trigger.severity == "High" and
      event.payload.trigger.status == "PROBLEM" and
      event.payload.trigger.tags.auto_recover is defined
    throttle:
      once_within: 5 minutes
      group_by_attributes:
        - event.payload.host.host
    action:
      run_job_template:
        name: "recover-app-service"
        organization: "Default"
        job_args:
          extra_vars:
            target_host: "{{ event.payload.host.host }}"
            trigger_name: "{{ event.payload.trigger.name }}"

Кастомный тег auto_recover на стороне Zabbix - тот же принцип, что мы применяли в сценарии с MaxPatrol SIEM: не все триггеры должны запускать автоматику, только явно размеченные.

Air-gapped: первое реальное использование

Один из клиентов, которому нужен был EDA, работает в изолированном сегменте. В 2.3 мы отложили внедрение именно из-за сложности с установкой без доступа в интернет. В 2.4 прошли через процедуру air-gapped инсталляции по официальной документации - заняло время, но процесс предсказуемый. Все образы для Decision Environment и eda-server забираются через podman pull заранее, инсталлятор принимает путь к локальному реестру.

Пока это только установка и базовое тестирование - продакшн запуск там позже. Но важно, что путь теперь не через хождение по форумам и изучение исходников инсталлятора.

Где открытые вопросы

UI для EDA в 2.4 стал заметно лучше относительно 2.3, но до уровня остального интерфейса AAP не дотягивает. История активаций и детали срабатываний смотрятся нормально, но отлаживать новый rulebook через UI всё ещё неудобно - проще ansible-rulebook локально с --verbose.

Масштабирование EDA при большом количестве активаций - вопрос, который у нас пока открытый. На текущих объектах нагрузка умеренная, но несколько клиентов параллельно с разными rulebook-ами - это уже требует понимания, как eda-server ведёт себя под нагрузкой.

Managed-сопровождение инфраструктуры с EDA - это другой уровень ответственности за содержимое плейбуков. Если раньше плейбук запускал человек и мог остановиться, увидев что-то не то, то теперь он запускается автоматически. Это означает жёсткие требования к тестированию плейбуков и к тому, как именно прописаны условия в rulebook. Работы по-прежнему хватает - она просто сместилась из «ночные дежурства» в «качество автоматики».