Активні майданчики й аварійне перемикання

Після більш ніж чотирьох років повномасштабної війни питання безперервності корпоративних інформаційних систем залишається одним із головних пріоритетів українських підприємств. Резервні копії, географічно рознесені дата-центри та хмарні платформи дозволяють зменшувати наслідки окремих аварій, але не гарантують збереження узгодженості даних під час складних інфраструктурних порушень. Особливо небезпечними є ситуації, коли кілька майданчиків втрачають зв’язок між собою, а інформаційні системи продовжують приймати незалежні транзакції. У таких умовах вирішальну роль відіграють правильний вибір моделі реплікації, контроль повноважень основного вузла, механізми quorum і fencing, а також перевірені процедури failover та failback.

1. Квітень 2026 року: безперервність бізнесу в умовах тривалих інфраструктурних загроз

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

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

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

Наприклад, головний дата-центр залишається доступним локальним користувачам, проте втрачає зв’язок із резервним майданчиком. Система автоматичного моніторингу може помилково трактувати таку ситуацію як повну відмову основного вузла.

Якщо резервний вузол активує приймання транзакцій, підприємство ризикує отримати дві незалежні версії своїх корпоративних даних. Для ERP це може означати конфлікти фінансових документів, складських залишків і замовлень.

Для MDM — появу різних редакцій довідників. Для Data Warehouse — суперечливу аналітику, яка використовує записи з різних інформаційних гілок.

Тому сучасна стратегія Business Continuity повинна розглядати не тільки доступність серверів, а й узгодженість корпоративних даних. Згідно з оприлюдненою 23 лютого 2026 року спільною оцінкою RDNA5, потреби України у відновленні та реконструкції протягом десятиліття становлять майже 588 млрд доларів. Оцінка охоплює наслідки війни станом на 31 грудня 2025 року та відображає масштаб пошкоджень, зокрема енергетичної й транспортної інфраструктури.

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

Головне архітектурне запитання квітня 2026 року: як забезпечити доступність критичних інформаційних сервісів, не допустивши появи кількох суперечливих джерел істини?

2. Active-Passive та Active-Active: принципова відмінність

У корпоративній практиці використовуються різні моделі резервування. Найпростішою з погляду логіки запису є Active-Passive.

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

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

Це відносно поширена архітектура. Натомість два незалежні екземпляри ERP, які одночасно змінюють ті самі фінансові записи, створюють значно складніше завдання.

Порівняння моделей

Для великих корпоративних ERP модель із єдиним активним авторитетним записом часто залишається практичнішою. Це не означає, що Active-Active є поганим рішенням.

Воно означає, що його потрібно застосовувати лише за відповідної інформаційної моделі.

3. Архітектура Multi-Site: різні рівні мають різні режими доступності

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

Транзакційна база — мати основний вузол та синхронну або асинхронну репліку. Аналітичне сховище — відновлюватися з резервних копій і повторного завантаження.

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

Логічна архітектура

Корпоративні користувачі та філії

Захищений доступ · маршрутизація · контроль автентифікації

• Майданчик А
• Прикладні сервіси
• Основна ERP-БД
• Інтеграції
• Майданчик Б
• Прикладні сервіси
• Standby ERP-БД
• Резервні інтеграції

Реплікація даних · контроль ролей · захищений зв’язок

Незалежний арбітраж та контроль перемикання

Quorum · fencing · правила promotion · журнал рішень

Незалежне резервне сховище

Історичні копії · контроль цілісності · перевірені процедури відновлення

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

Такий підхід зменшує складність узгодження інформації.

4. Синхронна реплікація: гарантії та обмеження

• У PostgreSQL 18 доступні штатні механізми синхронної й асинхронної реплікації.
• Синхронна реплікація дозволяє налаштовувати очікування підтвердження транзакції від визначених резервних вузлів.
• Наприклад, параметр synchronous_standby_names підтримує пріоритетний вибір і кворумний режим ANY.
• Офіційна документація PostgreSQL описує можливість очікування підтвердження від певної кількості резервних серверів.
• Умовний приклад:

synchronous_standby_names = 'ANY 1 (standby_a, standby_b)'
synchronous_commit = on

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

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

Якщо резервний майданчик розташований далеко, це може впливати на продуктивність ERP.

Порівняння

Для критичних систем вибір повинен визначатися BIA, RPO та вимогами до продуктивності.

5. Quorum не замінює fencing

Однією з найнебезпечніших помилок є припущення, що наявність кворуму автоматично усуває ризик split-brain. Quorum допомагає системі визначати, чи має вона достатню підтримку для прийняття певного рішення.

Проте це не гарантує, що старий основний сервер фізично припинив приймати записи. Припустимо, дата-центр А втратив зв’язок із резервними вузлами.

Система на майданчику Б вирішує активувати резервний сервер. Але локальні користувачі дата-центру А продовжують працювати зі старою ERP.

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

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

При цьому fencing повинен бути надійним навіть за часткової втрати мережі.

Розподіл функцій

Найважливішим є порядок дій.

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

6. Автоматичне та ручне failover

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

Наприклад, автоматичне перемикання між двома вебсерверами зазвичай менш ризиковане, ніж автоматичне promotion транзакційної ERP. У другому випадку помилкове рішення може призвести до втрати підтверджених операцій або split-brain.

Тому для критичних баз даних необхідно визначити умови перемикання.

Порівняння

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

Тому для деяких ERP раціональним може бути напівавтоматичний процес із обов’язковою перевіркою перед promotion.

7. PostgreSQL: моніторинг реплікації

Для оцінювання стану реплікації PostgreSQL 18 можна використовувати системне представлення pg_stat_replication.

SELECT
    application_name,
    client_addr,
    state,
    sync_state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

Запит дозволяє визначити поточний стан підключених резервних вузлів.

Для оцінювання відставання у байтах WAL:

SELECT
    application_name,
    pg_wal_lsn_diff(
        pg_current_wal_lsn(),
        replay_lsn
    ) AS replay_bytes_behind
FROM pg_stat_replication
WHERE replay_lsn IS NOT NULL;

Однак відставання в байтах WAL не можна автоматично ототожнювати з часовим RPO. Одна транзакція може створювати значно більше WAL, ніж інша.

Крім того, відсутність нових записів не обов’язково означає проблему реплікації. Тому для критичних систем потрібні додаткові перевірки: доступність резервного вузла, підтвердження застосування змін та фактичні тести відновлення.

8. Failback: повернення на основний майданчик

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

Проте повернення до основного майданчика може бути не менш складним.

Припустимо, ERP перейшла з дата-центру А на дата-центр Б.

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

Його стан уже застарів. Необхідно синхронізувати його з поточним авторитетним вузлом.

PostgreSQL має інструмент pg_rewind, який дозволяє синхронізувати каталог даних старого primary з новим primary після розходження часових ліній — за виконання відповідних технічних передумов.

Проте pg_rewind не є універсальним засобом злиття двох незалежних історій бізнесових транзакцій. Якщо після split-brain обидва вузли приймали незалежні записи, потрібне окреме розслідування та бізнесове узгодження.

Контрольна процедура failback

1. Підтвердити, який вузол є авторитетним.
2. Виключити запис на старому основному сервері.
3. Перевірити стан і доступність необхідних WAL.
4. Синхронізувати або відновити старий вузол.
5. Перевірити реплікацію.
6. Виконати тестові прикладні операції.
7. Погодити повернення з власниками бізнесових процесів.
8. Контрольовано змінити маршрути доступу.
9. Підтвердити RPO/RTO та Data Integrity.

Повернення не повинно виконуватися лише тому, що основний майданчик знову доступний.

Воно має бути економічно й технічно виправданим.

9. Kafka 4.2 та стійкість подієвих систем

У лютому 2026 року вийшла Apache Kafka 4.2.0.

Однією з важливих змін стала готовність Kafka Queues (Share Groups) до виробничого використання.

Цей механізм дозволяє кільком споживачам кооперативно обробляти повідомлення з окремими підтвердженнями та обліком повторних доставок. Також Kafka 4.2 розвиває моніторинг, протоколи перебалансування Kafka Streams і засоби обробки помилкових повідомлень.

Проте для побудови стійкої подієвої архітектури необхідно розділяти кілька різних питань. Реплікація Kafka забезпечує збереження записів між брокерами відповідно до конфігурації.

Consumer Offsets визначають позиції читання. Share Groups дозволяють організовувати певні сценарії спільної обробки.

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

Навіть якщо повідомлення надійно збережене в Kafka, ERP повинна контролювати повтори.

Приклад інформаційного потоку

• ERP: підтверджена транзакція
• Transactional Outbox / CDC
• Kafka: реплікований журнал подій
• Ідемпотентний інтеграційний сервіс
• WMS / DWH / CRM
• Data Reconciliation

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

У такому випадку потрібна контрольована повторна обробка.

10. Data Warehouse: відновлення аналітики після failover

Корпоративне сховище даних має інші вимоги до доступності, ніж транзакційна ERP.

Наприклад, підприємство може допустити тимчасову недоступність складної аналітики, але не може зупинити оформлення відвантажень.

Тому архітектура DWH повинна враховувати можливість поступового відновлення.

Пріоритети

Особливо важливо не запускати всі ETL-процеси одночасно після тривалого простою. Якщо кілька підрозділів накопичили дані, масове передавання може перевантажити ERP або мережеві канали.

Тому потрібна керована процедура catch-up processing. Вона повинна включати пріоритети, обмеження швидкості, контроль повторів і Data Quality Gates.

11. Міжсистемне звіряння після аварії

Припустимо, ERP відновлена до 10:15, WMS містить операції до 10:20, а CRM — замовлення до 10:25. Якщо автоматично відновити всі інтеграції, виникає ризик дублікатів і пропущених операцій.

Тому перед поверненням до штатної роботи потрібно визначити узгоджений інформаційний стан.

Приклад контрольної таблиці

CREATE TABLE recovery_control (
    reconciliation_id BIGSERIAL PRIMARY KEY,
    source_system VARCHAR(100) NOT NULL,
    target_system VARCHAR(100) NOT NULL,
    business_date DATE NOT NULL,
    expected_count BIGINT,
    actual_count BIGINT,
    expected_amount NUMERIC(18, 2),
    actual_amount NUMERIC(18, 2),
    status VARCHAR(30) NOT NULL,
    checked_at TIMESTAMPTZ
);

Пошук розбіжностей:

SELECT
    source_system,
    target_system,
    business_date,
    expected_count,
    actual_count,
    expected_amount,
    actual_amount
FROM recovery_control
WHERE expected_count IS DISTINCT FROM actual_count
   OR expected_amount
      IS DISTINCT FROM actual_amount;

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

Особливо це стосується фінансових і складських операцій.

12. Активні майданчики та модель CAP

Під час обговорення Active-Active часто посилаються на CAP-теорему. Вона описує обмеження розподілених систем щодо одночасного забезпечення узгодженості та доступності за наявності мережевого розділення.

Проте CAP не означає, що підприємство повинно назавжди вибрати «узгодженість або доступність» для всіх своїх даних. Різні бізнесові операції можуть використовувати різні моделі.

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

Для локальної чернетки замовлення можлива автономна робота з подальшим підтвердженням.

Практичне розмежування

Саме бізнесовий зміст визначає допустимий компроміс. Важливо також відрізняти мережеву доступність від можливості безпечно виконати операцію.

Іноді правильне рішення — тимчасово відмовити в записі, щоб не створити суперечливі фінансові дані.

13. Економіка Multi-Site архітектури

Географічне резервування створює додаткові витрати. Підприємству необхідно оплачувати сервери, сховища, канали зв’язку, резервне електроживлення, ліцензії та адміністрування.

Тому модель повинна відповідати критичності бізнесових функцій.

Умовне порівняння

Суми умовні й не є ринковими тарифами.

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

Наприклад, Active-Active може бути виправданою для високонавантаженого клієнтського порталу.

А для внутрішньої ERP із відносно невеликою кількістю користувачів Warm Standby може забезпечувати кращий баланс вартості та стійкості.

14. Практичний сценарій: виробниче підприємство з двома майданчиками

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

Основні системи:

• ERP на PostgreSQL;
• WMS;
• CRM;
• електронний документообіг;
• Kafka;
• корпоративне DWH;
• MDM.

Етап 1. BIA

Підприємство визначає критичні функції та допустимі RPO/RTO.

Етап 2. Архітектурна карта

Формуються залежності між застосунками, базами та каналами.

Етап 3. Реплікація

Для ERP обирається режим відповідно до вимог бізнесу.

Етап 4. Fencing

Реалізується перевірений механізм виключення старого основного вузла.

Етап 5. Контрольоване failover

Проводиться тестове перемикання.

Етап 6. Data Reconciliation

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

Етап 7. Відновлення DWH

Контрольовано запускаються ETL-процеси та повторна обробка.

Етап 8. Failback

Старий основний вузол синхронізується з новим авторитетним станом.

Етап 9. Бізнесове приймання

Власники процесів підтверджують працездатність.

Етап 10. Документування

Фактичні RPO/RTO та проблеми фіксуються у звіті.

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

15. Дорожня карта впровадження на 90 днів

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

16. KPI географічної стійкості

Показники повинні перевірятися регулярно.

Сам факт налаштування реплікації не гарантує готовності до аварійного перемикання.

17. Ризики та типові помилки

• Active-Active без аналізу даних. Одночасний запуск застосунків не означає безпечності multi-writer.
• Відсутність fencing. Старий primary може продовжувати приймати записи.
• Надмірна довіра до автоматичного failover. Мережева ізоляція не дорівнює фізичній втраті сервера.
• Неправильна оцінка RPO. Відставання у байтах WAL не є прямим часовим показником.
• Реплікація замість backup. Логічні помилки можуть передаватися на репліки.
• Непідготовлений failback. Повернення старого сервера може призвести до втрати нових транзакцій.
• Недостатній контроль Kafka. Доступність брокерів не гарантує правильного виконання бізнесових операцій.
• Ігнорування MDM. Після аварії довідники різних систем можуть розходитися.
• Відсутність Data Reconciliation. Технічне відновлення не доводить коректності бізнесових записів.
• Надмірна складність. Найскладніша архітектура не обов’язково є найнадійнішою для конкретної команди.

18. Компетенції Intecracy Group

Забезпечення географічної стійкості корпоративних інформаційних систем потребує поєднання компетенцій інфраструктури, інтеграції та управління даними.

Data Management IG (dmig.com.ua) спеціалізується на ETL, MDM, Data Quality, Data Warehouse, Data Lake, Data Governance та корпоративній аналітиці. Ці компетенції можуть використовуватися для відновлення інтеграційних потоків, перевірки узгодженості корпоративних даних, захисту історичних інформаційних ресурсів і контролю Data Quality після перемикання.

IQusion IT (iqusion.com) представляє системну інтеграцію, електронний документообіг, Business Process Management та автоматизацію бізнесових процесів. Відповідні компетенції важливі для відновлення наскрізних процесів, погоджень, документів і прикладних інтеграцій між майданчиками.

Станом на листопад 2026 року Softline IT зазначає серед своїх послуг побудову корпоративних мереж, серверну інфраструктуру та системи зберігання даних. Ці напрями можуть забезпечувати фізичну основу основних і резервних дата-центрів, мережевої зв’язності й надійного зберігання даних.

Станом на листопад 2026 року SL Global Service зазначає серед своїх послуг міграцію в хмару, віртуалізацію та проєктування гібридних хмарних середовищ. Ці компетенції дозволяють розглядати географічно розподілені середовища, резервні обчислювальні ресурси й гібридні моделі розміщення.

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

доступність без узгодженості не гарантує безперервності бізнесу

На п’ятому році повномасштабної війни українські підприємства повинні продовжувати розвиток стійкої інформаційної архітектури.

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

Проте збільшення кількості активних майданчиків створює додаткову складність.

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

Тому Active-Active необхідно застосовувати усвідомлено.

Для прикладних сервісів вона може забезпечувати високу доступність.

Для транзакційних баз вона потребує спеціалізованих протоколів або обмеження запису до одного авторитетного вузла.

Важливу роль відіграють quorum, fencing та контрольована процедура promotion.

При цьому реплікація не замінює незалежного резервного копіювання.

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

Особливо важливим залишається failback.

Повернення на старий основний майданчик не повинно призводити до втрати транзакцій, створених під час роботи резервного.

Для корпоративного DWH та аналітики потрібна окрема стратегія відновлення, яка враховує історичні дані, ETL, контрольні точки й можливість повторної обробки.

Крім того, рішення повинно бути економічно обґрунтованим.

Не кожному підприємству потрібна складна multi-writer архітектура.

У багатьох випадках простіша модель Active-Passive з перевіреним failover забезпечить кращу стійкість за нижчих витрат.

Головний висновок квітня 2026 року: стійка корпоративна архітектура повинна забезпечувати не максимальну кількість активних серверів, а збереження єдиного авторитетного інформаційного стану та контрольоване відновлення критичних бізнесових функцій.

Для Data Management IG це означає посилення ролі управління даними у проєктах високої доступності.

Data Replication, Data Quality, MDM, ETL Recovery та Data Governance стають невіддільними складовими Business Continuity.

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