Коли знадобиться — буде пізно

2 червня 2026 року AWS поклав monobank. І не лише його.

О 15:00 за київським часом користувачі по всій Україні почали бачити помилки. Monobank, ПриватБанк, Facebook, Netflix, Viber — все лягло протягом кількох хвилин. Причина — глобальний збій Amazon Web Services. Один провайдер, одна точка відмови, одна година паніки на весь український інтернет.

Олег Гороховський публічно підтвердив: причина зовнішня, на боці AWS. Це була чесна і правильна відповідь. Але для мільйонів клієнтів вона нічого не змінювала. Застосунок не працював. Що важливіше — не працював і колл-центр. Оператори підтримки не могли підтвердити баланс, уточнити статус транзакції, відповісти на питання «а гроші-то де?».

Це називається інформаційна сліпота. І саме вона — найдорожчий компонент будь-якої відмови.

Ви не втратили гроші. Ви втратили здатність це довести.

Банк не втратив даних того дня. Гроші клієнтів нікуди не зникли. Просто ніхто не міг отримати до них доступ — ні клієнт, ні оператор підтримки.

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

Кожна година «сліпоти» — це не просто незадоволені користувачі. Це репутаційні збитки на сотні тисяч доларів, регуляторні ризики та відтік клієнтів, який відчуватиметься ще місяцями.

Чому крос-хмара — не відповідь

Перша реакція багатьох інженерів на подібні інциденти — «потрібно ставити активно-активний кластер на двох провайдерах». Це звучить розумно. Це технічно можливо. І це в більшості випадків неправильна відповідь.

Причини три, і вони банальні. Синхронізація фінансових даних у реальному часі між двома хмарами — це задача, в якій теорема CAP працює проти вас. Найменша затримка синхронізації створює вікно для подвійного списання. Вартість інфраструктури подвоюється. А vendor lock-in, який вже є у будь-якого банку, що працює на специфічних сервісах AWS, робить переїзд не кварталом роботи — а роками.

Це усвідомлений компроміс. Але з нього не випливає, що альтернативи немає.

Що потрібно банку в день відмови

Оперативна підтримка не обробляє транзакції. Вона відповідає на три питання: чи пройшов платіж клієнта? Який його баланс? В якому статусі його остання операція?

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

Це називається Informational Survivability Layer — ISL. І її вартість не має нічого спільного з повним крос-хмарним резервуванням.

Як це влаштовано: принцип бортового самописця

Літак може розбитися. Але чорний ящик повинен вижити — саме тому, що він зберігає правду про те, що відбувалося. ISL працює за тим самим принципом. Це не дублювання бази даних. Це паралельний, асинхронний, однонаправлений потік фінансових фактів — назовні, за межі AWS, на незалежну інфраструктуру.

Транзакційний Outbox. Кожна зміна фінансового стану — платіж, переказ, зміна статусу — породжує запис не лише в основній базі, а й у спеціальній таблиці survival_outbox. Обидва записи робляться в одній SQL-транзакції. Немає коміту — немає події. Це гарантує: якщо подія в ISL є, гроші дійсно пройшли.

Однонаправлений потік (Data Diode). Дані рухаються лише в один бік: AWS → ISL. Жодного зворотного каналу. Це і міра безпеки, і архітектурна чистота: якщо ISL зламано, зловмисник не отримає доступу до продакшену.

Асинхронна доставка. Легкий агент (sidecar) читає outbox і батчами надсилає події на зовнішній сервер — на Hetzner, OVH або будь-який інший не-AWS провайдер. Якщо канал тимчасово недоступний — події накопичуються в локальному буфері й вирушають при відновленні. Основний платіжний шлях не блокується за жодних обставин.

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

Мітка свіжості: заборона на хибну впевненість

Це не технічний нюанс — це критична вимога до безпеки. Інтерфейс підтримки зобов'язаний показувати, наскільки свіжі дані. «Баланс 4 520 грн — дані на 14:47» — це коректне формулювання. «Баланс 4 520 грн» без часової мітки в момент інциденту — це юридичний ризик.

Якщо є розрив у даних (gap), система повинна сигналізувати червоним. Оператор, який впевнено повідомив клієнту неправильний баланс, створює проблему дорожчу, ніж мовчання.

Правило: за наявності gap — лише «баланс не менше X станом на Y». Жодних точних обіцянок.

Ghost Agent: блокування дій у момент сліпоти

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

Це не обмеження заради обмеження. Оператор, який бачить неповні дані і намагається «допомогти» клієнту ручною операцією, з високою ймовірністю створює подвійне списання або помилкове повернення. Детерміноване блокування виключає цю помилку на рівні архітектури, а не інструктажу.

Псевдонімізація: GDPR та безпека в одному рішенні

В ISL не повинно бути персональних даних. Не тому що не можна — тому що не потрібно. Замість номера телефону або імені клієнта зберігається його HMAC-хеш: HMAC_SHA256(secret_key, phone_number). Оператор вводить номер телефону — система обчислює хеш і знаходить рахунок. Дані є. Пошук працює. Але якщо база ISL витече — відновити з хешів реальні телефони без ключа неможливо.

Один технічний прийом вирішує одночасно задачу GDPR і задачу безпеки при компрометації.

Головна загроза: не AWS, а організаційна безтурботність

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

Прострочені TLS-сертифікати. Схема подій змінилась, ISL мовчки відкидає нові поля. Єдиний інженер, який знав паролі, пішов у відпустку. Ніхто не тестував перемикання вже вісім місяців. У день інциденту замість робочого резерву — темний екран.

Захист від цього простий, але вимагає дисципліни. Синтетичний heartbeat кожні 60 секунд: ISL автоматично перевіряє, чи отримав він контрольну подію за останні п'ять хвилин. Якщо ні — P1 alert негайно. Щомісячний «Game Day»: оператора відключають від AWS, він працює годину лише через ISL, фіксують результат. Щоквартальний drill з повним відключенням.

Система, яку не тестують — не працює. Це не припущення, це статистика.

Скільки це коштує

Найдешевша повноцінна реалізація — outbox → sidecar → Cloudflare Worker → Cloudflare KV + R2 — обходиться приблизно в $35 на місяць. Дещо продуманіша конфігурація з окремим VPS на Hetzner — порядку $50–130 на місяць залежно від обсягу.

Для порівняння: гаряче активно-активне резервування на двох хмарах — від $80 000 на місяць плюс виділена команда SRE. Одна година репутаційних збитків при глобальному збої для банку з мільйонами клієнтів — від $500 000 за мінімальними оцінками.

Розрахунок ROI тут не потрібен. Він очевидний.

Два принципи, які не можна порушувати

Система виживання не повинна вбивати основну систему. CDC-агент, що читає журнал транзакцій (WAL) з основної бази даних, може при неправильному налаштуванні утримувати цей журнал і врешті заповнити диск — зупинивши продакшен. Читайте WAL з репліки, а не з primary. Встановіть жорсткий ліміт на розмір retained WAL.

Незалежний IdP. Якщо авторизація операторів підтримки в ISL прив'язана до AWS Cognito або AWS IAM — у момент відмови AWS оператор не зможе увійти в систему. Аутентифікація для аварійного контуру має бути локальною, незалежною від жодного AWS-сервісу.

У день Х буде пізно розгортати

Технічно ISL можна побудувати за два тижні. Outbox у БД — це двадцять рядків коду. Агент експорту — ще сто. VPS із SQLite — $10 на місяць. Простий вебінтерфейс пошуку — ще три дні роботи.

Проблема не в складності. Проблема в тому, що це роблять після інциденту. А не до.

Коли AWS ліг 2 червня — будувати було вже пізно. Хто побудував раніше — спокійно працював. Хто не побудував — телефонував клієнтам «зачекайте, ми розбираємося».

Наступний чорний лебідь не чекатиме вашого спринту з планування.

Стаття підготовлена на основі аналізу 44 архітектурних рішень, розроблених провідними AI-системами в рамках багатоагентної дослідницької сесії PSI RADAR, червень 2026.