Володимир Котенко

8 июня 2026, 03:33

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.