Chaos Engineering для перевірки стабільності і надійності сервісів

Привіт! Мене звати Савицький Артем і протягом останніх п’яти років я керував та розробляв фреймворки швидкого прототипування і розробки, а також no-code рішення для тестування. Результат? Значне прискорення часу виходу на ринок, зменшення технічних боргів та поєднання швидкості з якістю. Все це дало нам перевагу, але залишалося питання стабільності і надійності наших сервісів. Саме тут Chaos Engineering стає ключовим.

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

Для кого ця стаття

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

SREs: назва говорить сама за себе — reliability. Часто очікується, що послуги будуть «завжди ввімкненими», вага на плечах SRE є величезною. SRE можуть передбачати й запобігати можливим збоям. У цій статті я проясню питання інтеграції практик хаосу для підвищення стабільності системи та проактивні заходи для протидії потенційним збоям.

QA/AQA Engineers: Якість — це не тільки робота системи, але й її стабільність. З цією статтею ви дізнаєтеся, як завдяки інженерії хаосу виявляти слабкі місця ще до їх появи.

Що таке Chaos Engenering

Chaos Engineering — це навмисне руйнування речей. Але чому? Викликаючи контрольовані збої, ми можемо ідентифікувати вразливі місця системи, які в іншому випадку залишалися б прихованими. Ці «controlled disruptions» необхідні для підвищення стійкості системи та розуміння потенційних точок збою. Мені подобається порівняння з тренуванням команди вогнеборців: вони спалюють старі будинки або симулятори, щоб вивчити, як краще гасити пожежі.

Чому small-mid-size team вагаються

• Обмежені ресурси. Невеликі команди часто стикаються з обмеженими ресурсами — як з точки зору робочої сили, так і інфраструктури. Впровадження інженерії хаосу вимагає виділених ресурсів для впровадження, моніторингу та аналізу збоїв, які можуть перевантажити і без того обмежені можливості.
• Недостатня обізнаність. Тоді як великі підприємства можуть бути більш схильні до найкращих галузевих практик та інновацій, менші команди можуть не мати такого ж доступу або впливу на зміну динаміки надійності системи.
• Страх невдачі. Сама передумова інженерії хаосу — навмисне руйнування речей — може лякати. Є побоювання, що все може піти не так, що призведе до фактичних збоїв або втрати даних, що може бути шкідливим, особливо для стартапів або підприємств середнього розміру.
• Жонглювання пріоритетами. З безліччю завдань під рукою та постійним перебуванням у режимі «гасіння пожежі» запровадження нової методології може здатися непотрібним ускладненням.

Де потрібен Chaos Engenering

Обов’язковий:

• Financial Systems: будь-який простій або збій може призвести до фінансових втрат, неправильних транзакцій або невідповідності нормативним вимогам.
• Healthcare Systems: дані пацієнтів і критичні операції зі здоров’ям повинні бути доступні цілодобово, без вихідних, що робить стійкість системи першорядною.
• E-commerce Platforms: навіть кілька хвилин простою під час пікового сезону покупок можуть призвести до значної втрати доходу.

Існує безліч систем, для яких Chaos Engineering є незамінним. Це може бути все — від розумних домашніх систем до масштабних промислових мереж. Основна причина, чому так багато систем потребують Chaos Engineering, полягає у тому, що технології швидко розвиваються, а зі збільшенням взаємозв’язків зростає й імовірність виникнення непередбачуваних проблем.

Chaos Engineering також може бути потрібен для окремої бізнес-задачі. Колись я працював в одній компанії, яка перемикала cloud-провайдерів для своїх клієнтів. Ці перемикання включали міграції великого обсягу даних до нових сховищ і мали чимало вимог типу SLO, синхронізації, кількості source of truth та інше. Тоді ми використовували функціональні, CDC та багато інших видів тестів, а також перевірка синхронізації даних як один із фінальних кроків. Це додало нам впевненості в наше рішення, але все хвилювання залишалося. Міграція в таких умовах — передбачає виконання обчислень у розподіленій системі, де як приклад будь-який компонент може бути недоступним. Такі випадки можна та потрібно було перевірити з використанням хаосу.

Менш важливий для:

• Static Websites: це рекламний щит біля дороги. Якщо він впаде... ну, нічого страшного.
• Internal Tools: деякі інструменти, які використовуються для внутрішніх операцій, як-от документація, можуть не вимагати такого ж рівня безвідмовної роботи, як клієнтські програми.

Chaos Engineering для таких систем — це ніби купувати спортивний автомобіль для їзди до магазину за кутом. Можливо, це потішно, але не завжди варто.

Growing Services, Growing Failures

У міру масштабування систем відбувається їхнє ускладнення. З кожною доданою службою кількість потенційних точок збою збільшується. Opengear ділиться дослідженнями, які показують, що 91% компаній у всьому світі щоквартально стикаються з принаймні одним збоєм, що вказує на необхідність покращення стійкості мережі.

Аналіз перебоїв у роботі Uptime Institute за 2022 рік показує, що витрати на простої та наслідки погіршуються, оскільки зусилля промисловості щодо обмеження частоти відключень не вдаються

Згідно зі звітом Gremlin за 2020 рік, минулого року 99% організацій зазнали збоїв у своїх критично важливих службах. У цьому ж звіті зазначено, що вартість простою в усьому світі перевищує 300 мільярдів доларів на рік.

Крім того, дослідження Gartner показало, що середня вартість простою ІТ становить $5 600 США за хвилину. Хоча це число змінюється залежно від масштабу та характеру бізнесу, воно підкреслює важливість стійкості системи.

В епоху cloud-систем взаємозалежність між службами робить їх більш сприйнятливими до каскадних збоїв. Один несправний мікросервіс може призвести до ефекту доміно, виводячи з ладу пов’язані служби. Таким чином, розуміння та перевірка цих взаємозалежностей за допомогою інженерії хаосу не просто корисна, але й важлива.

Імператив автоматизації в інженерії хаосу

Автоматизація — не тільки про те, щоб робити менше роботи, але й про те, як робити цю роботу правильно. Для хаосу автоматизація має свої унікальні переваги. Я виділів основні.

Simplification. Палиця з двома кінцями: хоча арсенал інструментів дає змогу нашим QA забезпечувати якість, він не позбавлений труднощів. Жонглювання декількома платформами може бути моральним податком. Однак глибина контролю та розуміння, які він пропонує, можуть стати «срібною кулею» для завчасного усунення вразливостей системи.

Recording. Хто взагалі любить записувати все вручну? Фіксація та журналізація стану окремого ресурсу, контейнера або системи в цілому — ці задачі допоможуть у складанні звітів, профайлінгу та подальшому аналізу. Виконати їх в ручному режимі — дуже незручна робота. Поєднання цього функціоналу із негайним зворотним зв’язком та тригером на події дає сильну перевагу для команди.

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

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

Scaling. Масштабування інфраструктури? Без проблем. Автоматизація гарантує, що випробування хаосу ефективно адаптуються, асигнувавши, що навіть наймасивніші системи не стануть перешкодою.

Time is money, efficiency is wealth. Дозволяє зменшити час на тестування в умовах хаосу в 10-20 разів. В класичному тестуванні ця тенденція також помітна, але менш виразна.

CI/CD. Інтеграція тестів хаосу із CI/CD схожа на репетицію головної події. Кожна функція та кожне оновлення проходять через віджим, забезпечуючи продуктивність після розгортання.

Створення автоматизованого проєктування хаосу з нуля

Тут я коротко ознайомлю вас з етапами для запуску процесу на прикладі нашого проєкту, а у подальших розділах розглянемо деталі більш докладно.

Research. Перш ніж щось почати, потрібно зрозуміти інструменти, методології та саму філософію інженерії хаосу.

Stakeholder alignment. Особливо в компаніях, які вперше знайомляться з цією концепцією, може виникнути опір або побоювання щодо навмисного порушення роботи. Забезпечення зацікавленості у stackholder-ів і передача довгострокових переваг — дуже важливий set-up крок. Це може бути трохи схоже на спробу переконати бабусю користуватися смартфоном. Можливо, спочатку буде скептицизм, але врешті-решт переваги стануть очевидними.

Evaluation. Перш ніж сіяти хаос, потрібно знати систему в деталях. Це передбачає глибоке занурення в поточну архітектуру системи, розуміння взаємозалежностей і потенційних слабких ланок, а також визначення найважливіших сервісів.

Integration. Йдеться не лише про вибір правильних інструментів, але й про те, щоб вони бездоганно інтегрувалися в нашу екосистему. Для цього можуть знадобитися спеціальні сценарії та рішення проміжного програмного забезпечення.

Scope definition. Вирішувати, які невдачі симулювати, — це поєднання мистецтва та науки. Занадто багато хаосу — і є ризик розладу; занадто мало — і експерименти можуть не виявити значущої інформації.

Monitoring and analysis. Хоча створення хаосу є частиною рівняння, справжня цінність полягає в моніторингу реакції системи та аналізі результатів. Налаштування детальних рішень для моніторингу, і, що більш важливо, знання, на що звертати увагу, є проблемою саме по собі.

Feedback loops​​. Інженерія хаосу — це не одноразова подія. Це безперервний цикл тестування, навчання, вдосконалення та повторного тестування. Налагодження ефективного циклу зворотного зв’язку для фіксації отриманих знань і повернення їх у процес є надзвичайно важливим.

Короткий огляд нашої інфраструктури: підготовка до розробки хаосу

Team. 3 спеціалізовані команди займаються окремими субдоменами, кожна з яких складається з 3-4 backends і 1-2 frontends, 1 AQA.

Architecture. Маємо 20 dockerized мікросервісів, переважно на Java та Golang. Також є наш приватний блокчейн. Self-managed Kafka, розподілений message broker, підтримує наші мікросервіси, сприяючи безперебійному спілкуванню. Крім того, сервіси ефективно спілкуються через протоколи HTTPS і gRPC. Використовували розподілений Clickhouse як OLAP, Postgres як OLTP і Redis для кешування. Кожна база даних може похвалитися своїми репліками для гарантії даних. У нас були консолідовані практики моніторингу, алертінгу та журналізацї подій.

Documentation. Діаграми C4, діаграми мереж, sequence діаграми, DFDs, а також ADRs у окремому репозиторію

Testing. Автоматизована функціональна регресія з ~1000 тестовими сценаріями та ~2 днями виконування в одному потоці. Виконання регресії інтегрували в CI/CD, це генерувало звіти. Охоплені сценарії тестування — REST API, WS API та UI. Написано за допомогою кастомного no-code інструменту тестування.

History. Рік у production з відстеженою історією збоїв, логів, інцидентів та сповіщень. А також фідбеками від юзерів.

Початкова оцінка системи на додавання хаосу

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

History analysis. Ми почали з отримання даних із наших інструментів керування інцидентами, журналів і сповіщень (StatusPage, ELK, Prometheus, Alerts in Telegram). Розмістивши ці інциденти на часовій шкалі, ми виявляли закономірності та повторювані проблеми. Події були класифіковані на основі тяжкості, частоти та зачеплених компонентів системи. Це дало нам зрозуміти, які частини нашої системи були найбільш вразливими.

Review of recovery. Ми переглянули наявні плани відновлення після аварій та реагування на інциденти. У результаті вказали recovery time objectives (RTO) and recovery point objectives (RPO) для різних сервісів.

Complexity analysis. Ми використовували засоби візуалізації мережі: відобразили потік і залежності між нашими сервісами, що дозволило визначити потенційні окремі точки збою та критичні шляхи зв’язку між сервісами.

Criticality designation. Завдяки співпраці команд, ми визначили, що означає «критичне» для нашої діяльності. Кожну функцію оцінювали за її впливом на користувачів, впливом на дохід і її значущістю на шляху користувача. Це допомогло розрізнити основні функції та ті, які могли тимчасово вийти з ладу, не спричиняючи значного впливу.

Classification. Ґрунтуючись на попередніх оцінках, ми позначили послуги на основі їхнього пріоритету стійкості. Крім того, ми визначили типи збоїв, з якими можуть зіткнутися ці служби: збої мережі, надмірне навантаження, збої в роботі апаратного забезпечення або невідповідність даних

Labeling. Визначивши критичні функції, ми відповідно позначали наші функціональні регресійні тести для додавання хаосу.

Як результат оцінки системи, аналізу інцидентів ми створили групу звітів:

• Incident history звіт: виділено компоненти, які найчастіше виходять з ладу, і характер їхніх збоїв.
• Communication complexity звіт: візуальне представлення взаємозалежностей послуг і потенційних перешкод.
• Critical functionality coverage звіт: розбивка нашого тестового покриття для основних функціональних можливостей, виявлення прогалин і сфер фокусування.
• Resilience priority and disruption звіти: списки сервісів, класифікованих за їхньою стійкістю та типами збоїв, з якими вони потенційно можуть зіткнутися.

Ці звіти послужили не лише основою для наших експериментів із хаосом, а й джерелом для подальшого використання. Завдяки цій комплексній оцінці у нас була чітка Road Map, яка гарантувала, що наші експерименти з хаосом будуть ефективними.

Визначення функціональних вимог до chaos engenering tools

Оцінюючи інструменти для chaos engenering, зосередилися на таких основних функціях:

• Гранулярний контроль. Наша складна екосистема, побудована на низці мікросервісів, потребувала інструменту, який міг би точно визначити конкретні сервіси, екземпляри чи навіть ресурси. Підхід із рушницею, коли хаос широко впроваджується, був би неефективним і потенційно більш руйнівним.
• Механізми безпеки. Хаос за своєю природою непередбачуваний. Нам потрібні вбудовані системи безпеки, щоб експерименти не вийшли з-під контролю, що потенційно може призвести до ненавмисних збоїв у роботі сервісу або катастрофічних збоїв.
• Автоматичний rollback. Враховуючи динамічне та безперервне надання функцій, ми не могли дозволити собі тривалі простої. Було вкрай важливо, щоб після експерименту системи можна було швидко відновити до початкового стану, забезпечуючи безперервність роботи.
• Stateful-data випробування. Наша залежність від баз даних означала, що ми повинні були розуміти наслідки потенційних порушень даних. Це зробило вирішальним для нашого інструменту полегшення експериментів, які могли б імітувати хаос у системах даних зі збереженням стану, наприклад, у базах даних.
• Rate limiting & throttling. У реальному світі системи часто стикаються з обмеженнями ресурсів. Симуляція таких сценаріїв, де ресурси навмисно обмежені, дасть нам уявлення про поведінку системи під напругою, гарантуючи, що ми готові до таких випадків.
• API-driven architecture: з величезною кількістю систем і потребою в налаштуванні наш інструмент мав бути розширюваним. Чітко визначений API означав, що ми могли інтегрувати, адаптувати та навіть автоматизувати експерименти відповідно до наших унікальних вимог.
• Documentation & community support. Хоча наша команда може похвалитися досвідченими професіоналами, сфера інженерії хаосу, що розвивається, означає, що завжди є чому навчитися. Інструмент, підкріплений вичерпною документацією, навчальними посібниками та активною спільнотою, гарантує, що ми ніколи не залишимося в невіданні.

Що ми обрали

У пошуках оптимального інструменту розробки хаосу я провів ретельний процес відбору, використовуючи Architecture Tradeoff Analysis Method. Це дослідження підкреслило потребу в функціях, які бездоганно інтегруються з нашою системою та практиками, а також відповідають нашим вимогам.

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

Resource атаки:

• CPU: споживає потужність CPU для навантаження на систему.
• Memory: виділяє та зберігає пам’ять.
• Disk: заповнює доступний простір на диску або чинить тиск на I/O операції.
• IO: stresses I/O операції.

State атаки:

• Shutdown: вимикає host.
• Process Killer: вбиває вказані процеси.

Network атаки:

• Latency: вводить затримку в мережеві операції.
• Packet Loss: скидає пакети для імітації ненадійності мережі.
• Blackhole: скидає весь трафік на певний хост або набір хостів.

Application Layer атаки:

• Time Travel: перекошує системний годинник.
• Function Call: вносить збої або затримку у виклики функцій.

Advanced атаки:

• Container: націлюється на певні контейнери, впливаючи на їхню продуктивність або вбиваючи їх.

Інші інструменти, варті уваги:

• Litmus: open-source code інструмент, розроблений для Kubernetes, що дозволяє користувачам запускати експерименти з хаосом на рівнях модуля, вузла та мережі.
• Pumba: легкий і зосереджений на контейнерах Docker, вносячи хаос на рівні контейнера для перевірки стійкості системи.
• Chaos Monkey: спочатку розроблений Netflix, він випадковим чином припиняє виробництво екземплярів, щоб переконатися, що інженери запускають свої сервіси, щоб бути стійкими до збоїв екземплярів.
• PowerfulSeal: підкреслює важливість Kubernetes і cloud-середовищ.
• Chaos Toolkit: розширювана платформа з open-source code.

Стратегія створення дизайну тестів

Для нас початковий крок не полягав у зануренні головою вперед у хаотичні глибини. Замість цього йшлося про методичне використання того, що ми вже знали та мали насамперед наш функціональний набір регресії, для виявлення ранніх вразливостей у стійкості. Цей основоположний крок мав розкрити першу групу проблем, пов’язаних зі стійкістю, створивши основу для більш комплексної стратегії розробки хаосу.

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

Також ми зв’язали доступний список атак на різні компоненти нашої системи та потенційні наслідки для них та системи в цілому:

Resource атаки та наслідки:

1. CPU:

• Під час атаки на CPU, API може втратити спроможність обробляти велике навантаження, що може спричинити затримки у відгуку або відмову в обслуговуванні.
• В Kafka обробка повідомлень може затримуватись, призводячи до акумуляції необроблених даних і збільшення латентності.
• Запити до Clickhouse можуть накопичуватись через нестачу CPU, викликаючи затримки у відгуці на інших рівнях системи.

2. Пам’ять:

• Нестача пам’яті в API може призвести до некоректної обробки запитів, а в екстремальних випадках — до зупинки сервісу.
• Kafka може почати втрачати повідомлення або знизити темп обробки через недостатнє виділення пам’яті.
• Clickhouse, при нестачі пам’яті, може відмовляти у збереженні нових даних, тоді як Postgres може переживати затримки при транзакціях.
• Redis, при перевищенні ліміту пам’яті, може почати витісняти старі записи, знижуючи ефективність кешування.

3. Диск та I/O:

• Завантаженість диска може призвести до затримок у логуванні та зберіганні даних в API.
• В Kafka великий трафік I/O операцій може призвести до затримок у збереженні та доставленні повідомлень.
• В Clickhouse та Postgres, I/O споживання може знижувати швидкість запису та читання.

State атаки та наслідки:

1. Shutdown:

• Закриття служби API негайно призводить до відсутності обслуговування користувачів.
• Зупинка Kafka призводить до відсутності обробки, збереження та доставлення повідомлень.
• Зупинка Clickhouse, Postgres або Redis призводить до недоступності даних для інших частин системи.

2. Process Killer:

• Вбивство процесу API може призвести до відмови в обслуговуванні. Вбивство ключових процесів Kafka може призвести до втрати даних.
• В Clickhouse, Postgres, і Redis, вбивство процесу може зупинити обробку даних або спричинити втрату даних.

Network атаки та наслідки:

1. Delays:

• Затримки у мережі можуть призвести до таймаутів між компонентами, що спричиняє затримки в обробці запитів API.
• Затримка може вповільнити обмін даними між Kafka, Clickhouse, Postgres та Redis.

2. Package loss:

• Втрата пакетів може призвести до нестабільності з’єднань між компонентами та мережевими вузлами, спричиняючи втрату даних.

3. Blackhole:

• Атака Blackhole відсікає весь трафік до певного вузла або сервісу, роблячи його повністю недоступним.

Application Layer атаки та наслідки:

1. Time Travel:

• Атака на мітки часу може призвести до некоректної синхронізації в API, особливо якщо служби залежать від часових відміток для операцій.
• Порушення в синхронізації може призвести до неправильної послідовності операцій, некоректних відгуків або втрати даних.

Також важливо відзначити, що атаки можуть бути спрямовані на окремі вузли баз даних та шин даних, результатом можуть бути проблеми з доступністю та узгодженістю даних, доступністю окремих операцій, перевантаження інших вузлів та проблеми відновлення систем після fail-over. Ряд потенційних проблем залежить від setup-а вашого розподіленого кластера. У нашій системі ми приділяли увагу нюансам кворумної реплікації, leader/follower та master-slave синхронізаціям.

Дуже результативними є тести на наближеній до production інфраструктури, а у разі великих розподілених систем — це важливий критерій. Цей setup може включати групу хостів на різних датацентрах. Своєю чергою це дає додатковий overhead у вартості тестової інфраструктури, при цьому додає нове поле для знаходження рідкісних багів на рівні мережі та транспорту.

Переваги такої стратегії як першого кроку:

• Ефективність: використання того, що ми вже мали регресію, пришвидшило наш процес впровадження інженерії хаосу, дозволяючи виявляти та виправляти основні проблеми стійкості швидше, ніж якби ми починали з нуля.
• Depth of сoverage: наші функціональні тести вже охопили критичні компоненти системи. Їхнє перепрофілювання забезпечило цілеспрямованість і результативність наших початкових тестів хаосу.
• Реалістичність: об’єднавши відомі тести з потенційними збоями, ми розробили сценарії хаосу, які точно віддзеркалюють виклики реального світу, з якими може зіткнутися наша система.
• Швидкий фідбек: знайомство наших команд із цими тестами означало, що будь-які несподівані результати під час експериментів з хаосом були негайно помітні, що пришвидшило цикл зворотного зв’язку.
• Економічний підхід: крім економії часу, ця стратегія була економічно ефективною. Ми максимізували рентабельність інвестицій, спираючись на інвестиції, вже зроблені в наші функціональні регресійні тести.

Результати першого кроку

• Критичний вибір тестів: із 1000 функціональних тестів ми вибрали 200, які безпосередньо стосувалися служб, життєво важливих для стійкості.
• Трансформація: після класифікації та поєднання цих тестів із різними методами зриву ми розширили наш набір до 2500 тестів. Вони не були абсолютно новими, але наші функціональні тести були доповнені додатковими кроками для впровадження та відновлення після збоїв.
• Ефективне створення тестів: наші базові функціональні тести служили шаблонами, завдяки чому створення хаос-тестів було більш оптимізованим, ніж можна було очікувати. Ми не починали з нуля; натомість ми створили нашу чинну структуру.
• Комплексні атаки: не всі порушення є простими. Деякі сценарії вимагали змішаних або комплексних збоїв, щоб справді перевірити ефективність наших послуг.
• System Coverage: ми піддали 10 наших мікросервісів 7 різним видам атак, забезпечивши широку оцінку нашої стійкості.
• Перевірка цілісності DB: чотири з наших баз даних зіткнулися з 5 різними типами збоїв. Нашою головною метою було перевірити дотримання принципів ACID, підтвердити eventual/causual/sequence consistency у конкретних випадках використання, і, перш за все, забезпечити, щоб наші дані залишалися цілісними навіть в умовах негараздів.
• Результати: на завершення цього етапу ми виявили 10 помилок, які проскочили під час традиційного тестування. Серед них 4 були критичними, підкреслюючи неоціненну природу інженерії хаосу для виявлення вразливостей системи.

Що ми не встигли зробити

Наші задачі в Chaos Engineering’s Roadmap, які залишились незавершеними:

• Multi datacenters’s infrastructure: створення розподіленої інфраструктури у кількох датацентрах вимагає дослідження підходів до симуляції мережевих та транспортних збоїв. Це включає тестування латентності та відмови ліній зв’язку.
• Stress-testing: ми успішно інтегрували хаос-інжиніринг в наші функціональні тести, але впровадження його в стрес-тест регресію залишилось за межами наших поточних задач.
• Docker’s restart policy: дослідження як конкретні контейнери реагують на політику перезапуску важливе для забезпечення оптимальної продуктивності та відновлення після відмов.
• Backups: є інтерес до перевірки процесу відновлення з бекапів під час симуляції різних сценаріїв відмов. Це дозволить перевірити, наскільки ефективно система може відновитися після критичних втрат даних.
• Snaphooting: планується впровадження системи, яка збиратиме логи з різних контейнерів в єдине time-series джерело.
• Segfault Emulation: перевірити, як система відгукується на внутрішні помилки, такі як segfault, та чи здатна відновитися після таких подій.
• External API’s: як ми працюємо, коли зовнішні сервіси, які ми використовуємо, недоступні.
• Poison Pills: навмисне введення пошкоджених даних у брокер повідомлень дозволяє перевірити механізми обробки помилок, які можуть виявляти та ігнорувати їх.
• Metrics: хочемо перевіряти метрики системи після атак, це дасть нам впевненість у нашому процесу моніторінгу та алертінгу.

Резюме

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

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

Пам’ятайте, що шлях кожної команди може бути різним. Формуйте свою стратегію відповідно до вашої інфраструктури, команди та бізнес-цілей. Зрештою, прагнення те саме: resilient і tolerant до збоїв система, яка забезпечує непохитну продуктивність, попри хаос.