Azure Chaos Studio допомагає організаціям перевіряти стійкість додатків

Azure Chaos Studio допомагає організаціям тестувати стійкість додатків, імітуючи збої, аварійні перемикання, збої мережі та інфраструктурні збої до того, як вони вплинуть на виробниче середовище

Ви не можете з упевненістю сказати, що ваш додаток стійкий до відмов, поки не буде підтверджено. Краще дізнатися, навмисно зламавши його в тестовому середовищі та спостерігаючи за реакцією, ніж переживаючи збій у виробництві. Azure Chaos Studio — це наш керований сервіс, створений саме для цього, безпечно та цілеспрямовано.

Сьогодні Azure Chaos Studio Workspaces перебуває у публічному попередньому перегляді: це підхід, орієнтований на сценарії, який дозволяє тестувати режими збоїв, з якими клієнти Azure насправді стикаються у продакшені. Ми доклали багато зусиль, щоб зробити Workspaces простими у використанні, з широкою підтримкою аварій і іменованими скриптами, які імітують реальні збої, а не окремі помилки.

Чому дизайну сталого розвитку недостатньо

Клієнти Azure інвестували у відмовостійку архітектуру: багатозонне розгортання, георезервне зберігання, автоматичне перемикання на базу даних, логіку повторних спроб, балансування навантаження на стороні клієнта. Однак головне питання виникає, коли починається інцидент: чи відновлюють ці механізми вашу заявку у визначений термін?

У реальних відмовах архітектурна схема не враховує специфіку системи. Розгортання з надлишковою зоною може не вплинути через неправильну конфігурацію перевірки стану стану, проведену роками тому. База даних, яка автоматично переходить на резервний сервер, може спричинити збій додатка, якщо рядок з'єднання жорстко закодований до однієї області. Георезервне зберігання може короткочасно створювати застарілі дані для читання, яких ваш код застосунку не очікував. Ці помилки є поширеними і виникають лише у разі відмови.

Надійність і стійкість Azure — це спільна відповідальність. Microsoft відповідає за платформу та відмовостійкість, вбудовану в сервіси Azure. Клієнти відповідають за налаштування цієї відмовостійкості та коду, який її використовує. Жоден рівень не компенсує прогалини в іншому. Єдиний спосіб дізнатися, чи витримають ваша архітектура, конфігурація та логіка застосунків тест у виробничому середовищі — це довести, що вони працюють у разі відмови, перш ніж зможуть протестувати їх на практиці.

Як Chaos Studio Workspaces змінює спосіб тестування відмовостійкості

Chaos Studio — це керований сервіс моделювання хаосу за допомогою Azure, розроблений для перевірки поведінки додатків у разі збоїв. Імітуючи контрольовані відмови в інфраструктурі, мережах, базах даних і залежностях додатків, він допомагає командам виявляти вразливості до відмов до того, як їх виявляють клієнти. Робочі простори Chaos Studio зосереджені на сценаріях, які відповідають ситуації в продакшн-середовищі, тому ви починаєте з реального сценарію відмови, а не з окремих помилок. Ви починаєте з іменованого скрипту, такого як «zone failure», «DNS failure» або «SQL switching», які вже налаштовані для ресурсів у робочому просторі.

Більшість відмов стосуються двох рівнів одночасно. Перший — це рівень платформи: чи відновлено сервіс, чи завершено резервування на сервер очікування в межах цільового часу відновлення, чи був трафік перенаправлений. Другий — це прикладний шар: чи ваш код зберігав цілісність даних, обробляв поточні транзакції, повторював необхідні дії і чи відбувається погіршення продуктивності правильно. яка зупиняє лише віртуальну машину (VM), що дозволяє оцінити стан платформного рівня. Скрипти в Chaos Studio Workspaces розроблені для тестування всієї системи.

Робочі простори полегшують початок. Найпоширеніша причина, чому тестування на відмовостійкість застрягає, полягає в тому, що команди не знають, з чого почати. Робочий простір — це новий ресурс верхнього рівня: ви вказуєте підписку або групу ресурсів для нього, і його керована ідентичність обмежує його та рекомендує відповідні сценарії. Ці сценарії з'являються всередині робочого простору, готові до налаштування та запуску, а оновлення оновлює рекомендації щоразу, коли ваша інфраструктура змінюється.

Бібліотека реальних сценаріїв аварій.Chaos Studio Workspaces містить ретельно підібрані сценарії, засновані на патернах, виявлених у реальних інцидентах Azure, тому ті сценарії, які ви тестуєте, — це ті, з якими клієнти стикаються. Уявіть їх як шаблони стійкості до відмов — швидкий спосіб перевірити режими відмов, які найчастіше потрібні командам, а якщо потрібно щось інше — створіть власні скрипти на основі тієї ж бібліотеки багів.

Доступно сьогодні:

• Зона доступності вимкнена: Віртуальні машинні масштабні набори (VMSS) вимкнені з цільовою ціллю для кожної зони для перевірки маршрутизації між зонами та відновлення роботи.
• Вимкнення зони доступності та резервування бази даних: вимкнення обчислювальної зони у поєднанні з переходом Azure Database for PostgreSQL (Flexible Server) дозволяє відстежувати поведінку резервування відповідно до налаштованих цілей відновлення та обробки з'єднань на стороні додатків.
• DNS-помилка: повний збій у розв'язці DNS-імен через те, що правила NSG блокують трафік резолвера для тестування поведінки вашого додатку у разі невдачі розв'язання імен.
• Збій Microsoft Entra ID: перевірка помилок провайдера ідентифікації для повторної автентифікації, кешування токена та шляхів резервного копіювання.
• Cache Influx: Очищення кешу Redis у поєднанні з перезавантаженням бази даних і збоєм процесу App Service для тестування поведінки під час бурі промаху кешу та сплеску активності баз даних. Опція збою процесу App Service наразі підтримує плани Windows App Service.
• Порушення повідомлень, пов'язане з подіями: Azure Service Bus та Event Hub вимкнені для тестування обробки мертвих літер і зворотного тиску.

У центрі кожного сценарію розташовані детальні API-активності, розроблені для робочих просторів:

• Вимкнення зони VMSS
• Завершення процесу App Service
• Force failover for Azure Database for PostgreSQL L (Flexible Server)
• Clean up Azure Managed Redis
• Мережеві контролі на основі мережевих груп безпеки (NSG)

А якщо скрипт з коробки не підходить для вашого робочого навантаження, ви можете створити власний. Новий конструктор сценаріїв — це інструмент перетягування в порталі Azure, який дозволяє створювати власні сценарії за допомогою перетягування, впорядковування кроків, гілок і багів з тією ж гнучкістю, що й класичні експерименти Chaos Studio, тепер доступні безпосередньо в робочих просторів. Почніть з готового шаблону або створіть скрипт з нуля, використовуючи повну бібліотеку помилок.

Збої агентів віртуальної машини, такі як центральний процесор (CPU) та проблеми з поза пам'яттю, також виконуються у робочих просторах. Кожен скрипт автоматично виявляє правильну комбінацію помилок, тому запуск скрипту «Зона відключення + база даних резервування» не означає, що потрібно думати в термінах «вимкнути екземпляри VMSS у зоні 1 і потім примусово відмовити головну базу даних». Бібліотека продовжить розвиватися у Публічний попередній перегляд як у GA, так і з часом планується дослідити додаткові сценарії, такі як:

• Резервне копіювання облікового запису зберігання у разі помилки
• Microsoft Azure SQL Managed Instance failover
• Microsoft Azure Front Door та Microsoft Azure Application Gateway
• Часткова деградація зон
• Хаос подів, властивий Microsoft Azure Kubernetes Service (AKS).
• Регіон, який контролює клієнт, недоступний.

Така ж основа актуальна для AI-додатків, які реалізуються у виробництві. Інструменти-допоміжники, агенти, конвеєри генерації з розширеними можливостями вилучення даних і кінцеві точки виведення можуть вводити нові збої, специфічні для ШІ, але вони все одно базуються на тих самих будівельних блоках Azure, що й інші розподілені додатки: обчислення, бази даних, кеші, пошукові індекси, ідентифікація, мережі, обмін повідомленнями та сховище.Chaos Studio Workspaces сьогодні може протестувати цю основу, використовуючи такі сценарії, як вимкнення зони, резервування до резервної бази даних, збій DNS, перевантаження кешу та подійно-орієнтоване повідомлення, тоді як каталог продовжує розвиватися у напрямку специфічних для ШІ поведінкових дій, таких як зміна швидкості отримання даних, обмеження кількості токенів і зміна поведінки моделі під навантаженням, оскільки нові дані накопичуються внаслідок тісної співпраці з клієнтами, які створюють штучний інтелект на Azure.

Звіти про сценарії. Після завершення скрипта Chaos Studio Workspaces генерує структурований звіт про навчання. Він точно описує, що було реалізовано в результаті сценарію, які ресурси були вплинуті, як розвивався графік відновлення, які сигнали були пов'язані з навчанням порівняно з нормальним базовим рівнем і де навантаження поводилося інакше, ніж очікувалося. Це робить його корисним як для команди, яка проводила навчання, так і для менеджерів, які хочуть регулярно перевіряти стійкість до відмов. Teams можуть експортувати його та прикріплювати до запитів на зміни, аудиторських документів або перевірок статусу сервісу.

Інтегруйте тестування на стійкість у операції з використанням штучного інтелекту.

Окрім продукту, ми пропонуємо два способи керування Chaos Studio за допомогою інструментів, з якими інженери вже працюють. Перший — навичка Chaos Studio для GitHub Copilot: вона проведе вас через увесь цикл у діалозі. Направте робочий простір на підписку, перегляньте рекомендовані сценарії, запустіть drill-down і отримайте звіт про те, що насправді сталося , корелюючи його з сигналами Azure Monitor .

Другий варіант — сервер Model Context Protocol (MCP), який надає доступ до тих самих операцій Chaos Studio у вигляді типізованих інструментів, тому інші помічники та автономні агенти: Claude, Cursor, Codex або ваш власний — можуть створювати робочий простір, запускати скрипт і запитувати відповідні сигнали без втручання людини. Обидва варіанти працюють з тими ж API Chaos Studio та вашими власними Обліковий запис Azure, і ви можете спробувати їх вже сьогодні.

Ми запускаємо це в перший день з однієї причини: коли клієнт запитує AI-асистента про Chaos Studio, цей досвід має формуватися нами, а не імпровізувати велика мовна модель (LLM), що читає наш REST API. З нашого досвіду, однією з найскладніших частин тестування на відмовостійкість часто є рішення про те, чи проводити це тестування взагалі, і це рішення дедалі частіше приймається через чат-інструменти, які інженери вже використовують, тому його слід впроваджувати і там.

Куди все це веде: навичка стає етапом автоматизованих операційних процесів у Microsoft Foundry і одним із способів, яким агент Azure SRE перевіряє власні припущення щодо причин збоїв робочого навантаження. Спробуйте і розкажіть, чого бракує; ми вирішимо ці прогалини в рамках публічного прев'ю.

Починайте

Сьогодні Azure Chaos Studio Workspaces перебуває у відкритому попередньому перегляді. Загальна дата доступності запланована на кінець 2026 року, але це може змінитися.

Щоб почати:

1. Створіть робочий простір, обмежений підпискою або групою ресурсів, яку хочете протестувати.
2. Нехай система виявлення автоматично пропонує рекомендовані сценарії для знайдених ресурсів. Віддаєте перевагу створенню власного? Відкрийте Script Builder і створіть власний скрипт із бібліотеки помилок — скрипти не потрібні.
3. Запустіть свій перший тест. Якщо ви ніколи не проводили експерименти з аналізом хаосу, запустіть Zone Down. Повний збій у зоні доступності покаже, як обчислювальне розміщення, перехід на резервну базу даних, DNS-розв'язання та логіка повторних спроб на рівні додатку реагують на стрес. Якщо ваше навантаження відновиться у прийнятний час, ви отримаєте дані про те, як воно реагує на одну з найпоширеніших причин довготривалих Час відпочинку в хмарі. Якщо ні, проблема буде на ваших умовах, а не на умовах клієнтів.

Стійкість — це не те, що можна досягти однією функцією, одним механізмом резервування чи єдиним архітектурним рішенням. Це інженерна дисципліна, і вона потребує валідації. Azure Chaos Studio Workspaces — це спосіб зробити цю валідацію стандартною для робочих навантажень Azure, включно з AI-навантаженнями, які все більше наших клієнтів впроваджують у виробництві