Azure SRE Agent научился сам разбирать Terraform-drift и не ломать прод — VogueTech

Что нового

Microsoft добавила в Azure SRE Agent HTTP-триггеры для event-driven работы с инфраструктурой как кодом (IaC). Главное — агент больше не просто фиксирует Terraform-drift, а сам проводит расследование и предлагает, когда нельзя откатывать изменения.

Ключевые новшества:

Классификация дрейфа инфраструктуры
Агент не ограничивается списком diff'ов из terraform plan. Каждый найденный drift он относит к одному из трёх уровней:
- Benign — безвредный (например, дополнительные теги);
- Risky — рискованный (например, понижение версии TLS);
- Critical — критичный (например, резкий рост стоимости ресурса).
Связка дрейфа с инцидентами
Агент автоматически:
- читает Azure Activity Log;
- анализирует телеметрию в Application Insights;
- связывает изменения инфраструктуры с пиками латентности и ошибками.
В демо-сценарии он:
- нашёл, что App Service Plan изменили со SKU B1 (~$13/месяц) на S1 (~$73/месяц) — рост затрат примерно на 462%;
- увидел, что это совпало с инцидентом: endpoint /api/data стал отвечать за 25 919 мс в среднем и 57 697 мс на P95;
- зафиксировал, что 97,6% запросов (40 из 41) были затронуты высокой латентностью.
Контекстные рекомендации по ремедиации
Агент не советует «просто сделать terraform apply». Он:
- рекомендует немедленно вернуть TLS с 1.0 на 1.2 как отдельный безопасный шаг;
- разрешает откат безвредных тегов через terraform apply -target;
- прямо пишет “DO NOT revert” для критичного параметра (SKU App Service) до исправления кода, потому что откат вернёт прод в состояние активного инцидента.
Автономное расследование по HTTP-триггеру
Любой инструмент дрейф-детекции (в демо — Terraform Cloud) шлёт webhook, который через Azure Logic Apps попадает в HTTP Trigger агента. Дальше агент сам:
- читает Terraform-конфигурации и реальное состояние Azure;
- анализирует логи и метрики;
- проверяет код в GitHub;
- формирует отчёт;
- пишет в Microsoft Teams;
- при необходимости создаёт pull request с фиксом.
Самообучающиеся skills
Агент использует «скиллы» — текстовые файлы с доменной логикой. После выполнения расследования он:
- делает Execution Review;
- находит пробелы в своём skill-файле terraform-drift-analysis.md (например, отсутствие инструкций проверять App Insights и Activity Log);
- сам редактирует skill, добавляя шаги корреляции инцидентов и «умной» ремедиации.
Автоматический pull request с фиксом
В демо агент сам создал PR в GitHub, где:
- исправил серверный код (server.js), добавив защитные константы MAX_DELAY_MS и SERVER_TIMEOUT_MS;
- обновил skill-файл с новым пайплайном анализа дрейфа.
В итоге из одного webhook-а цепочка выглядит так: drift → расследование → корреляция с инцидентом → отчёт → улучшение skill → PR с фиксом.

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

Общая архитектура пайплайна

Пайплайн «от детекции до решения» строится вокруг одного webhook-а:

Terraform Cloud (или другой инструмент детекции дрейфа) запускает ночной terraform plan.
При обнаружении дрейфа Terraform Cloud отправляет webhook с данными о ранe: workspace, организация, run ID, сообщение и т.д.
Azure Logic App выступает в роли auth-bridge:
- принимает внешний webhook;
- через Managed Identity получает токен Azure AD;
- проксирует запрос на HTTP Trigger Azure SRE Agent уже с аутентификацией.
HTTP Trigger Azure SRE Agent получает запрос и запускает автономное расследование по заранее заданному промпту и skill-файлам.

Инфраструктура демо

В качестве стенда Microsoft использует простое приложение на Node.js в Azure App Service, развёрнутое через Terraform.

Terraform-конфигурация задаёт желаемое состояние:

App Service Plan: SKU B1 (Basic), Linux, один vCPU, примерно $13/месяц.
App Service: Node 20-lts, TLS 1.2.
Теги: environment: demo, managed_by: terraform, project: sre-agent-iac-blog.

Пример ресурса плана:

resource "azurerm_service_plan" "demo" {
  name                = "iacdemo-plan"
  resource_group_name = azurerm_resource_group.demo.name
  location            = azurerm_resource_group.demo.location
  os_type             = "Linux"
  sku_name            = "B1"
}

Параллельно разворачивается Logic App, которая будет мостом между Terraform Cloud и HTTP Trigger SRE Agent через Managed Identity.

Skill для анализа дрейфа

В Azure SRE Agent skills — это текстовые файлы с описанием шагов расследования. Для этого сценария создаётся skill terraform-drift-analysis с восьмишаговым workflow:

Identify Scope — определить ресурсную группу и ресурсы для проверки.
Detect Drift — сравнить Terraform-конфиг с реальным состоянием в Azure.
Correlate with Incidents — проверить Azure Activity Log и Application Insights.
Classify Severity — присвоить каждому drift статус: Benign, Risky, Critical.
Investigate Root Cause — прочитать исходники из подключенного репозитория.
Generate Drift Report — собрать структурированный отчёт с таблицей по severity.
Recommend Smart Remediation — выдать контекстные рекомендации, а не «откатить всё».
Notify Team — отправить результаты в Microsoft Teams.

Ключевой принцип, зашитый в skill:
«NEVER revert critical drift that is actively mitigating an incident.»
То есть агент должен вести себя как опытный SRE, а не как бездумный инструмент сравнения конфигов.

HTTP Trigger: промпт и запуск расследования

В интерфейсе SRE Agent создаётся HTTP Trigger tfc-drift-handler с промптом, который описывает сценарий расследования. В него подставляются поля из webhook-пейлоада Terraform Cloud:

A Terraform Cloud run has completed and detected infrastructure drift.

Workspace: {payload.workspace_name}
Organization: {payload.organization_name}
Run ID: {payload.run_id}
Run Message: {payload.run_message}

STEP 1 — DETECT DRIFT: Compare Terraform configuration against actual Azure state...
STEP 2 — CORRELATE WITH INCIDENTS: Check Azure Activity Log and App Insights...
STEP 3 — CLASSIFY SEVERITY: Rate each drift item as Benign, Risky, or Critical...
STEP 4 — INVESTIGATE ROOT CAUSE: Read the application source code...
STEP 5 — GENERATE DRIFT REPORT: Produce a structured summary...
STEP 6 — RECOMMEND SMART REMEDIATION: Context-aware recommendations...
STEP 7 — NOTIFY TEAM: Post a summary to Microsoft Teams...

Каждый запуск HTTP Trigger — это отдельная автономная сессия расследования. На дашборде видно статусы и количество завершённых запусков.

Интеграции: GitHub и Microsoft Teams

В разделе Connectors в SRE Agent включаются две интеграции:

GitHub — агент получает доступ к исходникам приложения, может читать и редактировать файлы, создавать PR.
Microsoft Teams — агент может отправлять сообщения в командный канал: отчёты о дрейфе, краткие резюме расследований, ссылки на PR.

Обе интеграции должны быть в статусе Connected, чтобы сценарий работал полностью.

Как агент разбирает конкретный инцидент

1. Баг в приложении

В демо-аппликейшене есть тяжёлый endpoint /api/data. Он вызывает processLargeDatasetSync() — синхронную функцию, которая на каждом шаге сортирует массив. Это O(n² log n) и полный блокирующий вызов.

На плане B1 с одним vCPU это фактически блокирует event loop Node.js. Под нагрузкой:

время ответа растёт с миллисекунд до 25–58 секунд;
Azure Load Balancer начинает отдавать 502 Bad Gateway.

2. Реакция on-call-инженера

On-call инженер ночью видит алерты по латентности и действует напрямую через Azure Portal и CLI, обходя Terraform. Он:

добавляет теги manual_update=True, changed_by=portal_user — это дрейф, но без влияния на функциональность (Benign);
понижает минимальную версию TLS с 1.2 до 1.0 в процессе отладки — это регрессия по безопасности (Risky), уязвимость к BEAST и POODLE;
масштабирует App Service Plan с B1 до S1, чтобы «насыпать compute» — это критичный рост стоимости (Critical): ~$13 → ~$73 в месяц, около +462%.

Инцидент частично гасится: больше ресурсов — меньше латентность, но код всё ещё блокирует event loop. Terraform никто не обновляет.

3. Ночной drift-check

Утром nightly terraform plan находит три дрейфа:

SKU B1 → S1;
TLS 1.2 → 1.0;
новые теги.

Terraform Cloud отправляет webhook, Logic App добавляет аутентификацию и передаёт запрос HTTP Trigger SRE Agent. Агент стартует расследование.

4. Слои анализа

Layer 1 — Drift detection и отчёт
Агент сравнивает Terraform-конфиги с актуальными ресурсами в Azure и строит таблицу:

Critical: App Service Plan SKU B1 → S1, рост стоимости примерно на 462%.
Risky: Minimum TLS 1.2 → 1.0, регресс по безопасности.
Benign: новые теги changed_by: portal_user, manual_update: True.

Отчёт включает колонки Expected vs Actual и severity.

Layer 2 — Корреляция с инцидентом
Дальше агент идёт в Application Insights и Activity Log:

видит, что endpoint GET /api/data имеет среднюю латентность 25 919 мс и P95 — 57 697 мс;
фиксирует, что 97,6% запросов (40 из 41) затронуты высоким временем ответа;
обнаруживает, что /api/data есть в проде, но нет в репозитории — то есть деплой не соответствует коду в GitHub;
делает вывод: в коде, который реально работает в проде, есть блокирующий синхронный паттерн; масштабирование с B1 до S1 не решает проблему event loop, а только частично маскирует её.

Из Activity Log агент также вытаскивает, кто и когда сделал изменения: все правки шли от конкретного пользователя через Azure Portal примерно в 23:19 UTC.

Layer 3 — Smart remediation
На основе всего этого агент формирует разные рекомендации для каждого drift:

Теги (Benign) — можно безопасно вернуть в состояние из Terraform, например, через terraform apply -target.
TLS 1.0 (Risky) — нужно вернуть 1.2 как отдельный приоритетный шаг, потому что это регресс по безопасности, не связанный с латентностью.
SKU S1 (Critical) — запрещает немедленный откат и объясняет почему: если вернуть план на B1, пока в проде крутится блокирующий код /api/data, латентность снова станет катастрофической, и инцидент вернётся.

Агент предлагает последовательность из пяти шагов:

Найти и исправить блокирующий код /api/data на асинхронный паттерн.
Задеплоить исправленную версию.
Убедиться по метрикам, что латентность пришла в норму.
Только после этого откатить SKU с S1 обратно на B1 через Terraform.
Зафиксировать изменения в репозитории и обновить конфигурации.

Layer 4 — Итоговый отчёт
Агент собирает в один summary:

таблицу дрейфа с severity;
кто сделал изменения и через какой инструмент (Portal, CLI);
параметры инцидента по /api/data;
факт расхождения между прод-кодом и репозиторием;
вывод, что масштабирование до S1 было частью инцидент-реакции, а не «несанкционированным дрейфом»;
список выполненных действий: уведомление в Teams, обновление skill, создание PR.

Layer 5 — Уведомление в Teams
В Microsoft Teams агент отправляет сообщение вида «Terraform Drift Detected» с:

таблицей дрейфа по severity;
кратким описанием инцидента (латентность, затронутые запросы);
объяснением корневой причины;
пошаговым планом действий;
ссылкой на полное расследование в SRE Agent.

On-call-инженеру утром не нужно собирать пазл из пяти дашбордов. В одном сообщении он видит: что изменилось, почему, и что делать дальше.

Самообучение и PR от агента

После завершения расследования агент запускает Execution Review:

фиксирует, что сработало хорошо: сравнение Terraform ↔ Azure через az CLI, Activity Log для поиска актёра, App Insights для поиска инцидента;
находит 5 пробелов в skill-файле terraform-drift-analysis.md:
- нет явных инструкций по корреляции с инцидентами;
- нет шага проверки соответствия кода в проде и в репозитории;
- нет явной логики «умной ремедиации» и запрета отката критичного дрейфа;
- в шаблоне отчёта не хватает колонки Incident Correlation;
- нет руководства по использованию Activity Log.

Агент сам редактирует skill-файл, добавляя эти пункты. В следующий раз он будет по умолчанию проверять:

App Insights;
Activity Log;
соответствие кода;
контекст для рекомендаций по откату.

Параллельно агент создаёт pull request в GitHub:

в server.js добавляет константы MAX_DELAY_MS и SERVER_TIMEOUT_MS, чтобы ограничить максимальные задержки и таймауты;
обновляет terraform-drift-analysis.md, внося туда новую логику инцидент-корреляции и ремедиации.

PR содержит два коммита, изменения в двух файлах, +103 / -10 строк.

Что это значит для вас

Для чего это реально полезно

Команды, которые живут на Terraform и Azure
Если вы:
- деплоите инфраструктуру через Terraform;
- используете Azure App Service, Application Insights, Activity Log;
- ловите дрейф каждое утро в Slack/Teams и потом вручную расследуете,
— Azure SRE Agent может снять с инженеров рутину:
- автоматизировать расследования после terraform plan;
- объяснять, почему дрейф произошёл;
- подсказывать, что безопасно откатывать, а что трогать нельзя.
SRE и on-call-ротации
Агент полезен, если у вас есть ночные инциденты и «ручные» правки через портал:
- он не просто ругается на дрейф, но понимает, что это была часть аварийной реакции;
- помогает не превратить утренний terraform apply в новую P1-аварию.
Команды, которые хотят формализовать runbook-и
Skills в SRE Agent — это по сути живые runbook-и. Вы можете:
- описать в них вашу логику расследования и ремедиации;
- позволить агенту дополнять их на основе реальных кейсов.
Организации с жёстким контролем стоимости
В примере рост затрат на App Service Plan с B1 до S1 — примерно +462%. Агент:
- фиксирует такие изменения как Critical;
- связывает их с инцидентом;
- помогает выбрать момент, когда можно безопасно вернуть дешевый SKU.

Где это не поможет

Если вы не на Azure
SRE Agent завязан на:
- Azure Logic Apps;
- Azure Activity Log;
- Application Insights;
- Managed Identity.
Если ваша инфраструктура живёт в другом облаке без Azure, сценарий из коробки не заработает.
Если Terraform у вас «для галочки»
Если большинство изменений делается руками в портале и не отражается в коде, агент будет постоянно видеть дрейф и пытаться его расследовать. Польза появится только если вы действительно управляете инфраструктурой через Terraform и держите конфиги в актуальном состоянии.
Если у вас нет доступа к GitHub/Teams интеграциям
Без доступа к исходникам и командному чату агент:
- не сможет анализировать код;
- не сможет отправлять удобные отчёты.
Часть пользы (автоматический PR, контекстный анализ кода) пропадёт.
Ограничения по доступности
Azure SRE Agent и интеграции с Terraform Cloud, GitHub и Microsoft Teams требуют доступа к соответствующим сервисам. При жёстких сетевых ограничениях или необходимости VPN нужно заранее проверить, сможете ли вы подключиться к этим сервисам из вашей сети.

Как использовать на практике

Настройте Terraform Cloud (или другой drift-детектор) на отправку webhook при каждом plan с дрейфом.
Поднимите Logic App с Managed Identity как auth-bridge.
В SRE Agent:
- опишите skill для анализа дрейфа с вашей логикой приоритизации и безопасных откатов;
- создайте HTTP Trigger с промптом, подставляющим поля из webhook-пейлоада;
- подключите GitHub и Teams.

После этого каждый ночной drift-чек превращается не в сухой diff, а в полноценное расследование с рекомендациями.

Место на рынке

Сценарий Azure SRE Agent лежит на стыке нескольких классов инструментов:

Terraform Cloud / Atlantis / Spacelift — хорошо умеют находить дрейф и запускать plan/apply, но не анализируют, почему дрейф возник и что будет, если его откатить.
Системы мониторинга и APM (Application Insights, Datadog, New Relic) — отлично показывают метрики, латентность и ошибки, но не связывают это автоматически с дрейфом инфраструктуры и Terraform-конфигами.
Классические SRE-runbook-и — описывают, как действовать при инцидентах, но живут в wiki и не запускаются сами по webhook.

Azure SRE Agent с HTTP-триггерами соединяет эти части:

забирает структуру drift из Terraform Cloud;
подтягивает метрики и логи из Application Insights и Activity Log;
читает код из GitHub;
пишет в Teams;
меняет свои же runbook-и (skills) и код приложения через PR.

Прямых численных сравнений с другими решениями Microsoft не приводит: нет данных по скорости расследования против ручной работы, нет сравнения с аналогичными SRE-агентами от других вендоров. Но сам сценарий показывает, что агент умеет пройти путь от webhook-а до pull request-а без участия инженера.

Если вы уже используете Terraform Cloud и Azure, SRE Agent с HTTP-триггерами логично вписывается в стек как надстройка над drift-детекцией и мониторингом — не заменяя их, а связывая в один контур действий.

Установка / Как запустить

Ниже — базовый каркас, на который можно опереться, если вы хотите повторить демо-сценарий.

1. Деплой инфраструктуры через Terraform

Создайте Terraform-конфиг для ресурсной группы, App Service Plan и App Service. Пример фрагмента для плана:

resource "azurerm_service_plan" "demo" {
  name                = "iacdemo-plan"
  resource_group_name = azurerm_resource_group.demo.name
  location            = azurerm_resource_group.demo.location
  os_type             = "Linux"
  sku_name            = "B1"
}

В конфиге App Service укажите:

runtime Node 20-lts;
минимальную версию TLS 1.2;
теги environment: demo, managed_by: terraform, project: sre-agent-iac-blog.

Примените конфигурацию через terraform apply.

2. Настройка Logic App как auth-bridge

В Azure Portal создайте Logic App.
Настройте HTTP-триггер Logic App для приёма webhook-а от Terraform Cloud.
Включите Managed Identity для Logic App.
В workflow добавьте шаги, которые:
- получают токен Azure AD через Managed Identity;
- пересылают запрос на HTTP Trigger Azure SRE Agent, добавляя аутентификацию.

3. Создание skill `terraform-drift-analysis`

В SRE Agent создайте новый skill-файл, в котором опишите восемь шагов:

Identify Scope.
Detect Drift.
Correlate with Incidents.
Classify Severity.
Investigate Root Cause.
Generate Drift Report.
Recommend Smart Remediation.
Notify Team.

Не забудьте явно зашить правило: «NEVER revert critical drift that is actively mitigating an incident.»

4. Создание HTTP Trigger `tfc-drift-handler`

В интерфейсе SRE Agent:

Создайте новый HTTP Trigger.
Назовите его, например, tfc-drift-handler.
Вставьте промпт с шагами расследования и плейсхолдерами \{payload.X\}:

A Terraform Cloud run has completed and detected infrastructure drift.

Workspace: {payload.workspace_name}
Organization: {payload.organization_name}
Run ID: {payload.run_id}
Run Message: {payload.run_message}

STEP 1 — DETECT DRIFT: Compare Terraform configuration against actual Azure state...
STEP 2 — CORRELATE WITH INCIDENTS: Check Azure Activity Log and App Insights...
STEP 3 — CLASSIFY SEVERITY: Rate each drift item as Benign, Risky, or Critical...
STEP 4 — INVESTIGATE ROOT CAUSE: Read the application source code...
STEP 5 — GENERATE DRIFT REPORT: Produce a structured summary...
STEP 6 — RECOMMEND SMART REMEDIATION: Context-aware recommendations...
STEP 7 — NOTIFY TEAM: Post a summary to Microsoft Teams...

Привяжите триггер к skill terraform-drift-analysis.

5. Подключение GitHub и Microsoft Teams

В разделе Connectors:

подключите GitHub-репозиторий с вашим приложением;
настройте Microsoft Teams-канал, куда агент будет слать отчёты.

Убедитесь, что оба коннектора в статусе Connected.

6. Настройка webhook-а в Terraform Cloud

В Terraform Cloud:

Откройте нужный workspace.
В разделе Notifications/Webhooks создайте новый webhook.
Укажите URL Logic App.
Настройте отправку webhook при завершении run-а с дрейфом.

После этого каждый раз, когда terraform plan найдёт дрейф, цепочка Terraform Cloud → Logic App → SRE Agent запустит автономное расследование.

Полные Terraform-файлы, определения skills и демо-скрипты Microsoft выложила в отдельном репозитории — их можно использовать как шаблон для собственного пайплайна.