Андрій Фоменко Architect у Astravel, Викладач Комп'ютерної школи Hillel.

🍋 ЯК МІЛЬЙОН УКРАЇНЦІВ ОДНОЧАСНО ЗЛАМАЛИ MONOBANK ЛИМОНАМИ (І ЧОМУ ЦЕ ДОБРЕ)

Коли мільйон користувачів одночасно клацають по цифрових лимонах у банківському додатку — це вже не маркетинг. Це warfare testing у реальному часі.

17 жовтня 2025 року Monobank святкував 10 мільйонів клієнтів веселою грою. За лічені хвилини весела акція перетворилася на найбільший стрес-тест в історії українського фінтеху — ідеальну ілюстрацію принципів Chaos Engineering.

ЩО СТАЛОСЯ: ХРОНОЛОГІЯ ІНЦИДЕНТУ

17 жовтня, 12:00 — Monobank запускає гру: знайди цифрові «лимони» (сленг для «мільйона») у додатку (виграй iPhone або бонуси).

12:03 — Перші повідомлення у соцмережах: «Додаток лагає!».

12:05 — Мільйони одночасних запитів обрушуються на сервери. Затримки в UI, помилки авторизації, короткі «фризи».

12:15 — Автоскейлінг спрацьовує. Система стабілізується.

12:30 — Telegram-канал Monobank: «Працюємо над цим 🔧».

Результат: Система витримала. Критичні банківські операції не постраждали.

Monobank зламали лимони!

соцмережі вибухнули мемами

Мільйони користувачів одночасно полюють на цифрові лимони — ідеальний сценарій для тесту розподіленої архітектури.

прокоментувала українська IT-компанія ELEKS

ЩО ТАКЕ CHAOS ENGINEERING?

Chaos Engineering — це дисципліна, яка навчає ламати системи контрольовано, щоб вони не ламались у критичний момент.

Методологію створили інженери Netflix у 2011 році, коли розробили Chaos Monkey — інструмент, що випадково вимикає сервери у продакшні.

Основна ідея:

Якщо система витримує хаос у тестах — вона витримає і реальність.

ТИПОВІ СЦЕНАРІЇ ЕКСПЕРИМЕНТІВ:

🔌 Вимкнення випадкових серверів
🐌 Імітація затримок у мережі (latency injection)
📈 Раптові сплески трафіку
❌ Відмова сторонніх API

ІНСТРУМЕНТИ ІНДУСТРІЇ:

Chaos Toolkit — універсальний фреймворк
Gremlin — SaaS для enterprise
LitmusChaos — для Kubernetes
k6 / Locust — навантажувальне тестування

У фінтехі це критично: кожна секунда downtime = втрачені гроші + регуляторні штрафи. SLA банків зазвичай вимагає 99.99% аптайму (≈4 хвилини простою на місяць).

ЯК ЛИМОНИ СТАЛИ НЕСПОДІВАНИМ CHAOS-ЕКСПЕРИМЕНТОМ

Акція не планувалася як технічний тест, але на практиці відбулася ідеальна симуляція реального інциденту.

Анатомія навантаження:

Нормальний день:     ~10K запитів/сек
Пік "лимонів":       ~1-2M запитів/сек (оцінка)
Зростання:           ×100-200

ЩО СПРАЦЮВАЛО

1. Мікросервісна архітектура

[Ігровий модуль] ─── впав
[Платежі]        ─── працюють ✓
[Авторизація]    ─── працюють ✓
[Баланс]         ─── працює ✓

2. Правильний blast radius (зона ураження): проблема торкнулася лише розважального модуля, а не критичних банківських функцій.

3. Автоматичне масштабування: Kubernetes HPA (Horizontal Pod Autoscaler) підняв додаткові інстанси за хвилини.

4. Швидка комунікація: Команда відразу повідомила про проблему — це зберегло довіру користувачів.

4 КЛЮЧОВІ УРОКИ ДЛЯ ІНЖЕНЕРІВ

1. Масові акції = технічний ризик

Завжди моделюйте «worst-case scenario»:

Що якщо 50% користувачів зайдуть одночасно?
Чи витримають бази даних?
Чи є rate limiting на критичних ендпоінтах?

2. Observability рятує

Без моніторингу ви сліпі. Інструменти, що допомагають:

Метрики:    Prometheus + Grafana
Логи:       ELK Stack / Loki
Трейсинг:   Jaeger / Tempo
Алерти:     PagerDuty / Opsgenie

3. Chaos Engineering як страховка

Краще зламати систему в п'ятницю о 15:00 (контрольовано), ніж у понеділок о 9:00 (під час пікового трафіку).

4. Комунікація = частина incident response

Шаблон повідомлення для користувачів:

✅ Що сталося
✅ Що ми робимо
✅ Коли очікувати фікс
❌ Технічні деталі (нікому не цікаві)

🔬 ПРАКТИКА: ВАШ ПЕРШИЙ CHAOS-ЕКСПЕРИМЕНТ

Крок 1: Поставте гіпотезу

Система витримає 10x трафік на ендпоінт /api/promo.

Крок 2: Запустіть навантажувальний тест

# Встановлення k6 (без глобальної інсталяції)
brew install k6  # macOS
# або
choco install k6  # Windows

# Запуск тесту
k6 run --vus 1000 --duration 30s load-test.js

// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export default function () {
  const res = http.get('https://your-app.com/api/promo');

  check(res, {
    'статус 200': (r) => r.status === 200,
    'latency < 500ms': (r) => r.timings.duration < 500,
    'без помилок': (r) => !r.error
  });

  sleep(1);
}

Крок 3: Аналізуйте результати

# Приклад виводу k6
     ✓ статус 200
     ✓ latency < 500ms
     ✗ без помилок  [90% passed]

     http_req_duration..........: avg=450ms min=120ms med=380ms max=1.2s
     http_req_failed............: 10.00% (100/1000 requests failed)

Червоні прапорці:

❌ Latency > 500ms стабільно
❌ CPU > 85% на всіх нодах
❌ Error rate > 1%
❌ Черги (queues) наповнюються

Крок 4: Додайте fallback-механізми

// Приклад Circuit Breaker (TypeScript)
class PromoService {
  private failures = 0;
  private readonly THRESHOLD = 5;
  private circuitOpen = false;

  async getLemons(): Promise<Lemon[]> {
    if (this.circuitOpen) {
      return this.getFallbackLemons(); // Закешовані дані
    }

    try {
      const data = await this.fetchFromDB();
      this.failures = 0; // Скинути лічильник
      return data;
    } catch (error) {
      this.failures++;

      if (this.failures >= this.THRESHOLD) {
        this.circuitOpen = true;
        setTimeout(() => this.circuitOpen = false, 30000); // 30 сек
      }

      return this.getFallbackLemons();
    }
  }

  private getFallbackLemons(): Lemon[] {
    return [{ id: 'cached', prize: 'Try again later' }];
  }
}

Важливо: Починайте експерименти в staging, не в продакшні!

ПОРІВНЯННЯ З ІНШИМИ ІНЦИДЕНТАМИ

ПОДІЯ	РІК	НАВАНТАЖЕННЯ	DOWNTIME	УРОК
Pokemon GO launch	2016	×1000	~3 год	Потрібен глобальний CDN
Monobank лимони	2025	×100-200	~15 хв	Мікросервіси врятували
AWS S3 outage	2017	N/A	~4 год	Single point of failure = смерть