У грудні 2022 року український бізнес зіткнувся з безпрецедентними викликами через масовані удари по енергетичній інфраструктурі. Як зазначило Міністерство енергетики України у повідомленні від 13 грудня, енергосистема працювала з великим дефіцитом, що спричинило часті вимкнення електрики та мережевого зв'язку. У таких умовах традиційна централізована ІТ-архітектура стає вразливою, оскільки будь-яка втрата доступу до центрального сервера паралізує роботу складів, магазинів чи виробничих ліній. Для збереження операційної стійкості необхідно перейти до підходу Offline-first та архітектури відкладеної синхронізації.
Архітектура автономної роботи та стійкі черги
Основою Offline-first підходу є здатність локальних систем функціонувати без постійного зв'язку з центральною ERP. Наприклад, якщо складська програма втрачає інтернет, вона не повинна зупинятися. Замість спроб синхронного запиту до сервера, програма має записувати операції у локальний журнал. Ключовим інструментом тут є патерн Transactional Outbox, де бізнесова операція та повідомлення для синхронізації фіксуються в межах однієї транзакції локальної бази даних. Це гарантує, що при раптовому вимкненні живлення жодна транзакція не загубиться.
Ідемпотентність і розв'язання конфліктів
Коли зв'язок відновлюється, черга накопичених операцій передається до центральної системи. Проте масовий запуск після блекауту створює ризик перевантаження сервера та дублювання записів. Приймальна сторона повинна бути ідемпотентною: якщо повідомлення надійшло повторно (через збій передавання), система не повинна виконувати дію двічі, а просто повертати результат попередньої обробки. Для цього кожна подія має володіти унікальним ідентифікатором, що дозволяє центральному серверу ігнорувати дублікати.
Ще складнішим завданням є конфлікти бізнесової логіки. Уявіть, що під час блекауту два відділи одночасно змінили залишки товару. Автоматичне правило "перемагає останній" тут не працює. Підприємства мають заздалегідь розділити повноваження: наприклад, локальний склад відповідає за фізичне приймання, а центральний офіс — за остаточне підтвердження кредитних лімітів та фінансових документів. Це зменшує ймовірність паралельних змін одного й того самого об'єкта.
Керування даними та аналітика
Для майстер-даних (MDM) критично важливо заборонити неконтрольовані зміни в офлайн-режимі. Створення нового клієнта чи зміна реквізитів повинні мати статус "чернетки" до перевірки в центральній базі. Аналогічно, сховища даних (DWH) мають адаптуватися до нерівномірного надходження інформації. Звіти повинні містити метадані про актуальність — користувач повинен чітко бачити, на яку годину дані є свіжими, а де спостерігається відставання через блекаут. Замість приховування проблеми краще вказувати ступінь повноти звіту, що дозволяє керівництву приймати виважені рішення в умовах неповної видимості бізнес-процесів.
Автор матеріалу