ProIT: медіа для профі в IT
2 хв.

Gremlin додає інструмент виявлення ризиків до сервісу Chaos Engineering

author avatar ProIT NEWS

Gremlin додав можливість виявлення ризиків до свого сервісу інженерії хаосу. Нагадаємо, Chaos Engineering – це навмисне руйнування системи, яке дає змогу виявити слабкі місця та вразливості.

Інструмент Detected Risk автоматично визначає проблеми, які можуть спричинити збої, і надає рекомендації щодо їх вирішення, повідомляє DevOps.com.

Detected Risk дає змогу скористатися перевагами методів інженерії хаосу без необхідності проводити експерименти чи запускати тести надійності.

Головний технічний директор Gremlin Колтон Андрус сказав, що цей підхід усуває велику частину тертя, яке раніше обмежувало впровадження найкращих практик інженерії хаосу для підвищення стійкості ІТ-середовища.

Інженерія хаосу ґрунтується на філософії тестування стійкості, згідно з якою програми повинні мати можливість продовжувати функціонувати незалежно від будь-яких збоїв служби чи інфраструктури. Проте більшість ІТ-організацій не мають досвіду для створення інструментів, необхідних для перевірки стійкості на основі принципів «Chaos Monkey».

Кожна команда DevOps повинна буде оцінити рекомендації Gremlin перед їх впровадженням. Але загальна мета полягає у тому, щоб надати ІТ-групам краще розуміння рівня ризику, пов’язаного, наприклад, з неправильною конфігурацією сервера. Для цього інструмент використовує механізм оцінки, наданий Gremlin, зазначив Андрус.

Проблема полягає у тому, що в міру ускладнення ІТ-середовища рівень залежності між програмами й інфраструктурою продовжує зростати. Команди DevOps часто не можуть вручну відстежувати всі приховані залежності, коли ІТ-середовища постійно оновлюються.

Теоретично, звичайно, впровадження хмарних застосунків на основі мікросервісів повинно зробити ІТ-середовище більш стійким, оскільки виклики інтерфейсів прикладного програмування (API) перенаправляються у разі збою. Проте майже завжди існують залежності, які не помічають під час розвитку цих програм, що створює потенційну єдину точку відмови.

Не кожну ІТ-команду влаштовує концепція навмисної поломки, щоб краще зрозуміти, які проблеми потенційно можуть спричинити збій. Оскільки організації стають все більш залежними від програмного забезпечення для керування критично важливими процесами, потрібен більш активний підхід для забезпечення стійкості, додав Колтон Андрус.

Поки що не ясно, якою мірою розвиток штучного інтелекту може вплинути на інженерію хаосу. Принаймні моделі ШІ повинні спростити оцінку рівня ризику, але вартість використання цих технологій є високою. Враховуючи, що вже існують платформи, які забезпечують такий самий результат.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!‌‌‌‌

Приєднатися до company logo
Продовжуючи, ти погоджуєшся з умовами Публічної оферти та Політикою конфіденційності.