Підвищення надійності сайтів за допомогою Azure SRE Agent: детальний огляд

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вступ

Як ми використовували Azure SRE Agent для автоматизації завдань і підвищення надійності сайтів разом.

Що таке Azure SRE Agent

Microsoft оголосила про запуск Azure SRE Agent . Перш ніж перейти до демонстрації, давайте коротко розглянемо, що це за продукт і що він вміє.

Azure SRE Agent — це новий інструмент на основі штучного інтелекту, який допомагає керувати вашими продуктивними додатками в середовищі Azure.

Чому його створили

У розмовах з багатьма розробниками та інженерами з надійності сайтів (SRE) були виявлені дві основні проблеми:

1. Ніхто не хоче прокидатися серед ночі для вирішення інцидентів, особливо коли потрібно проводити root cause analysis під час стресу та відновлення роботи додатків.
2. Рутинна робота — виконання повторюваних завдань, як-от обробка ad hoc запитів або аналіз логів, що знижує ефективність.

Саме для вирішення цих проблем і був створений SRE Agent.

Основні можливості Azure SRE Agent

У SRE Agent є чотири ключові можливості:

1. Цілодобовий моніторинг: безперервно відстежує стан і продуктивність Azure-ресурсів.
2. Проактивні рекомендації: надає найкращі практики для захисту інфраструктури.
3. Автоматизована реакція на інциденти.
4. Прискорений root cause analysis та усунення проблем.

Реальний сценарій

Azure SRE Agent — це новий тип ресурсу в Azure. Після створення ресурсу та виклику його endpoint ви отримуєте інтерфейс для взаємодії з агентом.

Сценарій: збій на e-commerce сайті

Уявіть, що ваш сайт із великим трафіком, який продає телескопи, перестає показувати каталог товарів. Продажі падають — потрібно терміново все виправити.

Традиційний підхід

• Перегляд pod logs, deployment logs (додаток працює в AKS).
• Аналіз, чи проблема в конфігурації або в коді.
• Пошук у helm charts, activity logs — вручну, довго.

SRE Agent у дії

• Виявляє коливання в availability.
• Фіксує, що product catalog deployment знаходиться у стані crash loop back-off.
• Знаходить stack trace.
• Корелює з activity logs — нещодавній деплоймент є причиною.
• Пропонує відкат до робочої версії.
• Усунення проблеми — менше ніж за 3 хвилини.

Розробники можуть спокійно виправити код, а додаток уже працює.

Trend Analysis у стабільному стані

Навіть коли все працює, SRE Agent продовжує:

• Створювати knowledge graph про ваші ресурси.
• Відстежувати залежності між додатками.
• Моніторити продуктивність і відповідати на запити.

Приклади запитів до агента

• Якими resource groups ти керуєш?

  

• Які додатки керуються агентом: Container Apps, AKS, Function Apps, Web Apps?

  

• Показажи memory usage.

  

• Показажи 500 errors, latency, response times.

  

• Візуалізуй розподіл 200/500 відповідей — agent дає area chart з поясненням.

  

Що змінилось?

Питання, яке часто виникає: «Що змінилося?»

• SRE Agent переглядає activity logs.
• Визначає slot swaps, зміни конфігурації, застосовані політики.
• Дає зрозумілий, структурований огляд.

Це економить багато часу.

Best Practices від агента

SRE Agent пропонує список найкращих практик у сферах:

• Security
• Configuration
• Reliability
• DevOps

Це допомагає бути впевненим у надійності додатку.

Візуалізація архітектури

Knowledge graph агента — це його мозок. Він:

• Створює зв’язки між ресурсами (навіть із різних subscriptions).
• Показує, як Container App підключений до Redis Cache через Virtual Network.
• Показує статус, CPU, memory, та інтеграцію з Grafana в реальному часі.

  

Повернення до попереднього інциденту

• Додаток знову працює.
• Каталог товарів доступний.
• Availability повернулося до норми.

Це приклад AI-орієнтованого управління продуктивністю.

Автоматизована реакція на інциденти

Сценарій: тривога о 2-й ночі

Ви — черговий інженер. Прийшов алерт, web app недоступний.

Традиційно

• Зрозуміти зміст алерта.
• Дізнатися, що вплинуло.
• Перевірити вручну.

SRE Agent робить це самостійно

1. Інтеграція з Azure Monitor
   Як тільки з’являється alert, агент автоматично запускає аналіз і усунення.
2. Root Cause Analysis

• Зчитує метадані alert’у.
• Пропонує гіпотезу з 90% впевненістю: наприклад, slot swap.

• Availability = 0%
• CPU, memory, thread count — не причина.
• Агент автоматично звужує діапазон пошуку.

Вирішення та пост моніторинг

• Погоджуєтесь на дію агента.
• Агент запитує GitHub-репозиторій.
• Записує stack trace — для недопущення повторення помилки.

Фінальна перевірка

• Web App знову працює.
• Сесія завершується вдало.