Модернізація без зупинки: як IQusion оновлює складні інформаційні системи на UnityBase
Основна спеціалізація ТОВ «Айкюжн ІТ» — розробка, інтеграція та модернізація складних інформаційних систем. Такі системи забезпечують тривале зберігання й обробку значних обсягів даних, одночасну роботу багатьох користувачів із різними рівнями доступу та постійний обмін інформацією між взаємопов'язаними застосунками.
Логіка їхньої роботи залежить від багатьох чинників: поточного стану даних, попередніх операцій, повноважень користувачів і результатів взаємодії з іншими системами. Особливе значення мають розмежування прав доступу, захист інформації, контроль її використання та можливість відстежити історію змін і дій користувачів.
Під час модернізації інформаційна система продовжує працювати: користувачі виконують звичні операції, поки ми переносимо й перевіряємо дані. Якщо для фінального перемикання систему треба зупинити, робимо це в коротке, заздалегідь погоджене нічне вікно.
Чому одна зміна потребує плану для всієї системи
Розгляньмо умовний приклад. Є діюча інформаційна система, у якій потрібно змінити правила доступу до документів. Раніше доступ визначався підрозділом користувача. Тепер документ мають бачити також фахівці, яким явно надали доступ у межах конкретної справи.
На тестовій базі достатньо налаштувати кілька ролей і перевірити кілька записів. У робочій системі треба встановити, як нове правило діє для відкритих і завершених справ, вкладень та запитів через API. Якщо частина історичних документів не має повного набору зв’язків, команда погоджує для них окреме правило. Наприклад, документи, для яких неможливо однозначно визначити коло користувачів, ще до перемикання спрямовують на перевірку.
Тривалість переходу залежить від кількості записів, складності їх перетворення та швидкості обробки під робочим навантаженням. Додати поле до схеми — одна операція, заповнити його в мільйонах наявних записів — зовсім інша. У другому випадку записи треба прочитати, обчислити нові значення, записати їх і звірити результат. Масове оновлення конкурує за ресурси СУБД і сховища зі звичайною роботою користувачів. Якщо система має репліки, інтенсивний запис може збільшити їхнє відставання.
Вкладення перевіряють окремо. Навіть коли кількість записів до й після міграції збігається, потрібно підтвердити, що файл відкривається з правильної справи, користувач має до нього належний доступ, а історія дій збереглася. Для інтеграцій перевіряють, чи суміжні системи коректно отримують нові дані, обробляють повторні повідомлення та відновлюють обмін після перерви.
Перед робочим переходом ми відтворюємо цей сценарій на репрезентативній копії. За результатами репетиції визначаємо розмір пакетів — від десятків тисяч до мільйонів записів — і погоджуємо контрольні точки й пороги, за яких перенесення сповільнюємо або призупиняємо. План відновлення охоплює і застосунок, і дані: команда заздалегідь знає, як повернути систему до узгодженого стану, не втративши записів, створених уже після перемикання.
Чому ми обрали UnityBase
Для таких проєктів ми використовуємо UnityBase як основу прикладної архітектури. Бізнес-правила реалізуємо на серверному JavaScript. Для структурованих даних добираємо СУБД — PostgreSQL, Oracle або Microsoft SQL Server — з урахуванням редакції платформи та вимог до системи. Вкладення й версії документів зберігаємо у файловому сховищі, із суміжними застосунками обмінюємося через API, для автентифікації використовуємо OpenID Connect, Kerberos або інші механізми, яких потребує замовник. Конфігурацію доповнюємо моніторингом, резервним копіюванням і, якщо цього вимагає схема експлуатації, реплікацією.
UnityBase ми обрали тому, що одна зміна прикладної моделі часто зачіпає базу даних, API та кілька інтерфейсів. Спільний опис сутностей і повторне використання серверних методів скорочують обсяг робіт у кожному з цих шарів. Звільнений час команда витрачає на те, що визначає результат модернізації: перенесення історичних даних, перевірку доступу та підготовку переходу під робочим навантаженням.
Відкритий вихідний код — одна з головних причин, чому ми обрали UnityBase. Відкрита редакція OpenUB доступна за ліцензією Apache 2.0. Команда може вивчати, як працюють компоненти цієї редакції, розбирати причини збоїв і передавати ці знання іншим виконавцям. Можливості й умови ліцензування залежать від редакції. Редакції UnityBase.
Чому безпека вплинула на вибір UnityBase
Для систем із чутливими даними важливо перевіряти і дозволені дії, і доступ до конкретних справ. Двоє фахівців можуть мати однакову роль і працювати з різними документами. UnityBase дає серверні механізми, щоб застосовувати ці правила й фіксувати події безпеки.
Підбір або викрадення пароля. У UnityBase можна налаштувати блокування облікового запису після заданої кількості невдалих спроб входу. Невдалі спроби фіксуються в журналі безпеки. Для підтримуваних способів входу можна ввімкнути другий фактор, щоб викраденого пароля самого по собі було недостатньо. Документація UnityBase про автентифікацію й аудит.
Спроба відкрити чужу справу через API. Зловмисник може змінити номер документа в запиті й спробувати отримати його напряму. Для операцій, на які поширюється налаштоване правило доступу, UnityBase перевіряє права на сервері. Навіть якщо зловмисник увійшов під викраденим обліковим записом, його доступ обмежений правами скомпрометованого облікового запису. Окремо перевіряємо завантаження вкладень і власні методи API. Документація UnityBase про доступ до записів.
Перехоплення даних і розслідування інцидентів. HTTPS захищає дані під час передавання. Журнал безпеки допомагає з’ясувати, коли почалися підозрілі спроби входу та які облікові записи вони зачепили. Під час модернізації ці механізми перевіряємо разом із налаштуваннями доступу. Захист від перевантаження трафіком, своєчасні оновлення й відновлення з резервних копій плануємо окремо на рівні інфраструктури та експлуатації.
Zero Trust та інші практики модернізації
Zero Trust. Сам факт підключення до внутрішньої мережі не дає права читати документи або викликати API. Рішення про доступ спирається на ідентичність користувача чи сервісу, запитаний ресурс і контекст сеансу. У прикладі зі справою сервер перевіряє право на операцію й доступ до конкретного документа. Інтеграціям надають окремі ідентичності з мінімальними дозволами. Серверні ролі та правила доступу UnityBase допомагають реалізувати прикладну частину цієї моделі. Перевірка стану пристроїв, керування ідентичностями та сегментація мережі потребують рішень на рівні всієї архітектури. NIST SP 800-207.
Безпека ланцюга постачання ПЗ. Для релізу важливо знати, з якої версії коду й залежностей його зібрали. Інвентар компонентів (SBOM) допомагає визначити, які системи зачіпає нова вразливість. Підтвердження походження збірки (build provenance) дає змогу перевірити, звідки взявся артефакт і як його зібрали. Під час переходу це допомагає зіставити версію, яка пройшла тестування, з тією, яку готують до розгортання. SLSA Build Provenance.
Спостережуваність і контроль переходу. Команда заздалегідь погоджує цілі рівня сервісу (SLO) та пороги, після яких призупиняє перенесення або повертається до попереднього режиму роботи. У нашому умовному прикладі під час перенесення вимірюємо час відповіді, частоту помилок і відставання реплік, якщо вони є. Окремі перевірки підтверджують коректність прав доступу та цілісність даних. Ці результати разом дають підставу вирішити, чи можна продовжувати перемикання.
Чому інформаційні системи національного рівня потребують фінансування
Навіщо платити за систему, яку вже зробили? Законодавство України регулярно змінюється. Якщо змінюються строки розгляду заяв, перелік потрібних документів або коло осіб, які мають доступ до записів, ці зміни треба відобразити в реєстрі й перевірити на реальних сценаріях роботи. Наприклад, під час зміни порядку розгляду заяв потрібно перевірити, як система обробить заяви, подані до набрання чинності новими правилами.
Технології теж змінюються. Версії операційних систем і баз даних виходять із підтримки, з’являються нові вразливості, а суміжні сервіси оновлюють свої інтерфейси. Якщо заморозити реєстр, він може ще якийсь час працювати. Згодом для його компонентів перестануть виходити виправлення безпеки, а обмін даними із сервісами, які вже перейшли на нові інтерфейси, може зупинитися.
Підтримка потрібна, щоб виявляти збої й відновлювати роботу. Модернізація дає змогу пристосувати систему до нових вимог. Якщо функція працює й вимоги до неї не змінилися, підстав переробляти її немає. Для кожного доопрацювання варто запитати, яка зміна його спричинила, що станеться без нього та як замовник перевірить результат.
Які роботи потребують фінансування? Адміністратор встановлює готове оновлення. До встановлення потрібно оплатити розробку змін, їх перевірку та ресурси для репетиції переходу. Замовник може звірити ці витрати з погодженими завданнями й результатами приймання.
Як річна закупівля вписується в багаторічний проєкт? Модернізацію можна планувати на кілька років і закуповувати послуги окремими річними етапами. Кожен етап спирається на вже прийняті результати. У плані на рік варто зазначити, які зміни мають запрацювати і як замовник їх перевірить.
Чи можна залучити іншу команду? Відкритий код OpenUB дає змогу вивчити платформу. Для супроводу конкретної системи новій команді потрібні доступ до коду самого застосунку, право його використовувати й змінювати, документація та можливість самостійно зібрати й розгорнути систему в тестовому середовищі. Новій команді знадобиться час, щоб перевірити інтеграції та відпрацювати відновлення після збою. Для системи національного рівня особливо важливо визначити, хто відповідає за її роботу під час передачі й після неї.
Як кілька компаній працюють над однією системою? У проєкті національного рівня роботи можна розподілити між кількома виконавцями. Наприклад, одна компанія розробляє зміни, друга обслуговує інфраструктуру, а третя незалежно перевіряє оновлення. Кожен підрядник відповідає за результат, визначений у його договорі. Роботи свідомо розподіляють, щоб зменшити залежність від одного постачальника й мати змогу передати окрему ділянку іншій команді.
За кінцевий результат часто відповідає державна структура, наприклад державне підприємство, яке виконує функції замовника. Воно узгоджує роботи підрядників, приймає результати за договорами й визначає, хто забезпечує роботу системи під час оновлення та хто відновлює її у разі збою.
Коли варто замінити систему? Порівнюють повну вартість модернізації та заміни. Для нової системи до ціни розробки або ліцензії додаються перенесення даних і вкладень, підключення суміжних сервісів, навчання користувачів і паралельна експлуатація. Обидва сценарії оцінюють за однаковими вимогами до доступності, збереження даних і можливості передати супровід іншій команді.
Які компетенції потрібні для такого переходу
| Компетенція | За яке рішення відповідає |
|---|---|
| Архітектура застосунку | Як змінюються сутності й серверні методи, скільки часу співіснують дві структури та коли можна перемикати читання й запис. |
| Інженерія даних і СУБД | Як перенести історичні записи під навантаженням, продовжити перервану міграцію та звірити дані й вкладення. |
| Системна інтеграція | Як зберегти сумісність API, обробити повторні повідомлення й відновити обмін після перерви. |
| Безпека й аудит | Де перевіряти повноваження, як тестувати доступ для різних ролей і за якими даними відтворювати дію після релізу. |
| Експлуатація та тестування | Які показники дозволяють продовжити перехід, коли його треба зупинити та як перевірити готовність до відновлення. |
| FinOps | Скільки коштують репетиції, паралельна робота середовищ і конфігурація, яка залишиться після переходу. |
Ці рішення впливають одне на одне. Довший період сумісності дає суміжним командам більше часу на перехід, але збільшує витрати на паралельну експлуатацію. Додаткова потужність прискорює міграцію лише тоді, коли усуває виміряне вузьке місце. Якщо швидкість обмежують операції запису або блокування, додаткові процесори самі по собі проблеми не розв’яжуть.
Як FinOps допомагає оцінити вартість переходу
Після розподілу робіт команда порівнює, скільки коштуватимуть різні способи переходу та подальша експлуатація.
FinOps допомагає зіставити витрати на інфраструктуру з потребами системи. Для модернізації ми окремо плануємо два бюджети. Бюджет переходу охоплює репетиції, копії даних, тимчасові сховища, передавання файлів і період, коли працюють обидва середовища. Бюджет подальшої експлуатації залежить від робочого навантаження, резервного копіювання, строків зберігання історії та ресурсів, потрібних системі після завершення робіт.
Припустімо, репетиція показала, що швидкість перенесення обмежує запис у сховище. Один варіант — тимчасово підвищити його продуктивність і скоротити період паралельної роботи. Інший — зберегти поточну конфігурацію й відвести на перехід більше часу. Щоб порівняти їх, ми рахуємо повну вартість кожного сценарію: і ціну додаткової потужності, і витрати за кожну добу, протягом якої працюють обидва середовища.
Цей розрахунок впливає й на рішення після перемикання. Для тимчасово збільшеної потужності визначаємо умову її зменшення, для старого середовища, потрібного на випадок відновлення, — строк і критерії виведення з експлуатації. Так FinOps прибирає з кошторису ресурси, які вже не виконують своєї функції. Почати контроль можна з трьох показників: вартості повної репетиції, вартості доби паралельної роботи та прогнозу щомісячних витрат після переходу.
За рахунок чого UnityBase зменшує обсяг розробки
У UnityBase сутності, поля та зв’язки описують у метаданих. Цю модель використовують ORM, інструменти підготовки схеми БД, типові операції API та адміністративний інтерфейс. Для нашого прикладу це означає, що нові зв’язки між документом, справою та користувачем мають один спільний опис. Розробник використовує його в кількох шарах системи, а прикладний код пише для правил переходу, історичних винятків і спеціалізованих сценаріїв.
{
"caption": "Доступ до справи",
"attributes": [
{ "name": "caseID", "dataType": "Entity",
"associatedEntity": "doc_case" },
{ "name": "userID", "dataType": "Entity",
"associatedEntity": "uba_user" }
]
}"mixins": { "rls": {
"expression": "підрозділ користувача
АБО запис у doc_caseAccess" } }| Де виникає економія | Яка робота скорочується |
|---|---|
| Схема БД і робота з даними | Інструменти платформи готують за моделлю DDL, а ORM працює з оновленою структурою. Команда підтримує менше окремих описів сутностей і зв’язків. |
| API та адміністрування | Типові операції над сутностями та стандартні адміністративні форми спираються на модель. Для довідників і службових екранів цю основу можна використати повторно. |
| Доступ до записів | Серверні правила видимості й методи сутностей діють у різних інтерфейсах, тож одне правило не доводиться реалізовувати кілька разів. Доступ до вкладень і спеціальних методів перевіряють у відповідних сценаріях. |
| Репетиція міграції | Генерацію схеми й власні сценарії JavaScript або SQL включають у процес оновлення. Той самий набір кроків повторюють на тестовій копії та під час робочого переходу. |
Без повторного використання цих механізмів кошторис був би вищим. Він охоплював би окремі зміни схеми, типових операцій, адміністративних форм і перевірок доступу, а також їх узгодження між собою. UnityBase зменшує саме цю повторювану частину розробки та супроводу. Ресурси для фактичного перенесення й перевірки даних ми оцінюємо окремо. Так у кошторисі видно, де економію дає архітектура застосунку, а де — рішення щодо інфраструктури. Докладніше про ці механізми — у статті «П’ять переваг UnityBase для розробників корпоративних систем».
Як ми приймаємо модернізацію
Приймання починаємо зі справи, відкритої ще до оновлення. Користувач знаходить свої матеріали, бачить дозволені дії та продовжує роботу. Суміжна система коректно приймає результат. За журналом можна відтворити операцію.
До перемикання команда показує результати цієї перевірки, визначає умови відновлення та розраховує вартість роботи системи після переходу.
Що дає модернізація після переходу
Після оновлення важливо, наскільки легко додати до системи наступну функцію. Повернімося до прикладу зі справами й документами. Коли система вже знає, які документи належать до справи та хто може їх читати, ці правила можна використати для нової дії в картці справи.
Наприклад, фахівцю потрібно швидко зрозуміти, що змінилося в документах справи. Він натискає «Підготувати огляд змін». Система перевіряє його права, відбирає дозволені для обробки фрагменти й передає їх моделі ШІ. Модель готує чернетку огляду з посиланнями на документи. Фахівець звіряє її з джерелами й вирішує, що робити далі.
Для цієї функції команда додає підготовку огляду й використовує наявні зв’язки між справою та документами, а також правила доступу. Якщо документи мають залишатися в інфраструктурі замовника, модель запускають там само. Користь оцінюють за тим, скільки часу займає підготовка огляду разом із перевіркою та виправленнями. Докладніше про інтеграцію ШІ в інформаційні системи.
Той самий принцип працює для звіту, сповіщення чи нової дії в картці справи. Після модернізації команда може додавати такі функції, спираючись на вже перевірені дані, зв’язки й правила доступу.
Документація UnityBase: архітектура платформи · матриця редакцій · міграції · контроль доступу на рівні записів
