Оновлення UBD у проді: процедура без простою

Класична модель «зупинимо систему вночі на 4 години для оновлення» прийнятна для невеликих внутрішніх систем. Для систем 24/7 — це втрата довіри і потенційні штрафи за порушення SLA. Стаття описує, як оновлювати UBD без простою, і коли це насправді можливо, а коли — ні.

Типи оновлень

Коли потрібна повторна експертиза

Експертиза захищеності прив’язана до конкретної версії системи на момент видачі висновку. Будь-яке оновлення формально вимагає оцінки впливу на захищеність.

Не потребує повторної експертизи:

• Виправлення помилок без зміни функцій безпеки.
• Покращення продуктивності без зміни алгоритмів.
• Косметичні зміни UI.
• Додавання нових прикладних об’єктів моделі (нові форми, нові таблиці) без зміни моделі прав.

Потребує повторної експертизи:

• Зміна алгоритмів криптографії.
• Зміна моделі авторизації (RBAC → ABAC, нові типи політик).
• Зміна формату WORM-журналу.
• Додавання нових каналів автентифікації.
• Зміна архітектури кластера (single → distributed).

Сіра зона (вимагає консультації з експертною організацією):

• Додавання нових інтеграцій (нові ЦСК, нові SSO-провайдери).
• Зміна СУБД (Oracle → MS SQL).
• Перехід у хмару.

Rolling deployment у кластері

Стандартний підхід для кластера UBD з 3+ нодами:

1. Вивести 1 ноду з ротації load balancer (drain).
2. Дочекатися, поки всі активні запити завершаться (graceful shutdown, 30-60 секунд).
3. Оновити ноду.
4. Запустити, health check’нути.
5. Повернути у ротацію.
6. Дочекатися стабілізації (5-10 хвилин — моніторинг помилок).
7. Повторити для наступної ноди.

Для кластера з 5 нод і 10 хв на ноду — повне оновлення займає ~1 годину без простою. Користувачі помічають тільки якщо потрапили на ноду під час drain (рідко, при правильно налаштованому graceful shutdown — не помічають взагалі).

Blue-green deployment

Підхід для випадків, коли rolling не підходить (наприклад, несумісна зміна формату даних):

1. «Зелений» (поточний) кластер працює на проді.
2. «Синій» (новий) кластер розгортається паралельно, з новою версією.
3. Дані синхронізуються у «синій» (для read-only — реальний час, для write — як підготовка).
4. «Синій» тестується внутрішньо (smoke tests, не з користувачами).
5. Load balancer переключається на «синій». Перехід — секунди.
6. «Зелений» залишається у standby на 24-72 години для можливого rollback.
7. Якщо все добре — «зелений» виводиться, через 1-2 тижні стає основою для наступного циклу.

Перевага: миттєвий rollback при проблемі (повертаємось на «зелений»). Недолік: подвійні ресурси на час deployment.

Канарковий випуск (canary)

Для функцій з невпевненістю — поступова розкатка:

1. Нова версія розгортається на 1% нод.
2. Моніторинг метрик: помилки, latency, скарги користувачів.
3. Якщо все добре через 1-2 години — 5%.
4. Потім 25%, 50%, 100%.

Підходить для функцій, які важко відтестувати в lab: специфіка реальних навантажень, інтеграцій, користувацьких патернів.

Відкат

План відкату — обов’язкова частина процедури оновлення. Перед запуском:

• Бекап БД на момент перед оновленням.
• Збережена попередня версія бінарних файлів і конфігурації.
• Документована послідовність дій для повернення.
• Чітка точка прийняття рішення «йдемо далі / відкочуємось» (наприклад, через 30 хвилин після завершення розгортання).
• Відповідальна особа з повноваженнями приймати рішення.

Тонкий момент: якщо нова версія міняла схему БД — відкат складніший. Іноді міграцію треба робити двома фазами: фаза 1 — додає нові колонки/таблиці (сумісно зі старою версією), фаза 2 — видаляє старі (вже після стабілізації нової версії).

Комунікація з користувачами

Навіть rolling deployment без простою — комунікується заздалегідь:

• Оголошення за 1-2 тижні з планованим часом.
• Повідомлення про початок і завершення.
• Можливі візуальні попередження у системі.
• Контакти support для проблем після оновлення.

Для систем КІІ і держсектору — додатково повідомлення регулятора, особливо якщо оновлення зачіпає функції безпеки.

Особливості air-gapped середовищ

Системи в air-gapped мережі (без виходу у інтернет) — окремий випадок:

• Файли оновлення передаються через контрольований канал (USB-носій з санітизацією).
• Підпис файлів оновлення обов’язково перевіряється перед запуском.
• Тестування — у ідентичній air-gapped тестовій мережі, не у lab з інтернетом.
• Rolling deployment — за тим самим алгоритмом, що у звичайних мережах.
• Регуляторні особливості: для систем з державною таємницею — узгодження кожного оновлення з СБУ.