Експертиза · Інфраструктура та операції

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

Хостинг, запуск, моніторинг і безперервність для вебдодатків і платформ із базою даних. Ми працюємо на інфраструктурі, яку клієнт може собі привласнити: віртуальні машини в європейських провайдерів, nginx, процеси під наглядом, контейнери, самохостингова база даних. Це включає відповідь на запитання «де фактично зберігаються мої дані».

Обговорити проєкт

Вже збудованоМи так експлуатуємо кілька власних систем, а конфігурації зберігаються в репозиторіях, а не лише на серверах. Цей сайт працює на nginx з Next.js 16 під PM2, в OVHcloud București. Платформа асистентів працює на Microsoft Azure, Poland Central, з MySQL, Redis і RabbitMQ в контейнерах, з’єднаних із локальним інтерфейсом. Власна громадська платформа використовує systemd units із публікацією через атомарне перемикання символічного посилання, щоденну перевірену резервну копію та окреме завдання з ретенції, яке запускається лише якщо ця копія вдалася. Внутрішня дошка публікується через власний runner, з GitHub actions, зафіксованими на повному fingerprint, і з автоматичним поверненням до попередньої версії, якщо перевірка стану падає після публікації. Застереження, яке треба сказати: рівень автоматизації різниться від системи до системи. Публікація цього сайту досі виконується вручну, а міграції бази даних застосовуються вручну, навмисно. Ми не продаємо автоматичний ланцюг, якого в нас немає всюди.

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

Базовий вибір, який ми пропонуємо, — це інфраструктура, на яку клієнт може претендувати: віртуальна машина в європейського постачальника, nginx спереду, процеси під наглядачем, контейнери там, де це має сенс, самостійно розміщена база даних там, де незалежність важливіша за зручність. Не тому, що керовані платформи погані — а тому, що одного дня ви захочете забрати все й піти, і якщо це не було продумано на початку, дешево цього вже не зробиш.

Питання про суверенітет даних має лише одну чесну відповідь: перевірену. Локацію підтверджують, звертаючись до сервісу метаданих віртуальної машини та реєстру адреси, а не читаючи маркетингову сторінку постачальника. Різниця не теоретична — для передавання всередині Європейського економічного простору розділ про передавання в Законі 195/2024 просто не застосовується. Міграція, яку ми виконали, перенесла платформу з бази даних, розміщеної у Сполучених Штатах, на самостійно розміщений стек у Європейському Союзі, саме з цієї причини.

Чого ми не обіцяємо: що все автоматично. Міграції схеми ми застосовуємо вручну, свідомо, тому що міграція, застосована автоматично в продакшені ланцюгом, який не знає, що в таблиці, — це звичайний спосіб втратити дані. Публікацію коду автоматизують; зміну структури бази залишають людським рішенням, зі свіжою резервною копією позаду.

Що входить

Робота, за складовими

Реверсивне оприлюднення з перевіркою після, а не лише до

Оприлюднення не завершується, коли файли потрапили на сервер, а коли реальний запит доводить, що саме нова версія й обслуговується. В одній із реалізацій скрипт синхронізує директорію, зберігає попередню версію поруч, потім витягує назву пакета зі сторінки, що віддається, і перевіряє на публічній адресі, чи подається саме цей файл; якщо ні, сам повертається до попередньої версії. Це не теорія: механізм упіймав пакет, що залишився старим у директорії runnerului, і скасував оприлюднення, яке інакше здавалося б успішним.

Атомарне перемикання версії з процесом під systemd

Альтернатива до «зупиняємо, копіюємо поверх, запускаємо» — директорія версій плюс символічне посилання, що перемикається однією операцією. Одиниця systemd завжди вказує на стабільний шлях, а повернення означає перемикання посилання назад. Одиниця має політику перезапуску при збої з короткою паузою, максимальний час зупинки та системні обмеження: без підвищення привілеїв, захищена файлова система, особисті директорії недоступні, з явним списком шляхів, у яких їй дозволено писати.

nginx спереду, з обмеженнями, прописаними для реального випадку

Завершення TLS з автоматичним поновленням сертифіката, HSTS тривалістю один рік і включенням піддоменів, компресія з мінімальним порогом розміру, статичні ресурси з довгим терміном дії та незмінним маркуванням, а застосунок прив’язаний до локального інтерфейсу, щоб до нього не можна було дістатися напряму з інтернету. Обмеження швидкості встановлюються за типом трафіку, а не глобально. Одна оплачена наука: під HTTP/2 ліміт з’єднань рахує потоки, а не з’єднання — при малому значенні один завантажений вебсайт сам собі відхиляє шрифти й скрипти з 429.

Резервна копія, що перевіряється, а не лише запускається

Щоденне заплановане завдання, з запуском під час наступного boot, якщо машина була вимкнена на той час, і з випадковою затримкою, щоб усе не стартувало в одну й ту саму секунду. Експорт бази стискається, а якщо отриманий файл порожній, виконання вважається збоєм — експорт, що завершується «успішно» й дає нуль байтів, є звичним способом через шість місяців дізнатися, що копії немає. Файли зі сховища об’єктів синхронізуються окремо. 100% локальна копія не переживає втрату диска, тож копія йде і поза межі машини, до облікового запису сховища в Європейському Союзі з географічною реплікацією, версіонуванням, зворотним видаленням і автоматичним закінченням терміну дії — з доступом через керовану ідентичність, щоб на диску не було жодного ключа сховища.

Заплановане видалення запускається лише після успішної копії

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

Тривоги, які не брешуть і не спамлять

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

Ланцюг публікації, який не можна перехопити зверху

Дії в потоці інтеграції зафіксовані на повному відбитку commit, а не на мітці. У березні 2026 року популярну дію було перенаправлено з міток `v1`…`v45` на шкідливий код, і це торкнулося понад 23.000 сховищ за 24 години; відбиток не пересувається. Потік не зберігає креденціали в робочій копії, а оприлюднення не проходить через token: воно йде через власний runner, на цільовій машині, з правами, наданими точково. Так жоден ключ доступу до сервера не лежить на платформі коду.

Контейнери з обмеженнями, перевірками здоров’я та журналами, що не заповнюють диск

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

Самостійно розміщувана база даних, коли незалежність має значення

Повний стек у контейнерах — база даних, автентифікація, REST-інтерфейс, канал у реальному часі, сховище файлів, gateway — з явно увімкненими розширеннями та параметрами пам’яті й з’єднань, відповідними машині, а не залишеними на значеннях за замовчуванням. Міграції — це версіоновані файли в репозиторії, і вони застосовуються вручну, з перезапуском компонента, який тримає свою схему в пам’яті. Причина цього вибору проста: платформа, керована з-поза меж Європейського Союзу, може бути технічно чудовою і все ж юридично неприйнятною.

Як це виглядає

Шлях, крок за кроком.

Інвентаризуємо, що існує і що можна втратити

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

Закладаємо основу: сервер, nginx, процеси, hardening

Брандмауер, який за замовчуванням відхиляє вхідні з’єднання і відкриває лише те, що потрібно, захист від повторних спроб автентифікації, правильно розмірений простір swap, nginx із TLS та автоматичним поновленням, додаток, прив’язаний до локального інтерфейсу, наглядач процесів, налаштований запускатися під час boot. Ми передаємо конфігурації в сховищі, а не лише на машині, щоб наступна людина не відтворювала їх з пам’яті.

Робимо публікацію повторюваною і зворотною

Скрипт публікації зі збереженою попередньою версією, перевірка стану після публікації та автоматичне повернення при помилці. Там, де є команда й безперервна інтеграція, додається власний runner на цільовій машині, з action, зафіксованими на відбитку, і без credentials у робочій копії. Ми передаємо письмову процедуру і виконане повернення перед клієнтом — неперевірене повернення не є поверненням.

Розміщуємо копії, retention і alarms

Щоденна копія з перевіркою, що файл не порожній, копія поза машиною в регіоні Європейського Союзу, завдання retention, яке запускається лише після успішної копії і залишає слід, плюс alarms із обмеженням частоти, які читають вміст відповіді, а не лише код стану. Ми передаємо фактично виконане пробне відновлення і його журнал.

Передаємо ключі і пишемо, що лишається невиконаним

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

Шари інсталяції, знизу вгору: віртуальна машина в підтвердженому європейському регіоні, контейнерний рушій з ротацією журналів, база даних із перевіреною щоденною копією та копією поза машиною, процеси під наглядом із перезапуском у разі збою, nginx із TLS і лімітами запитів — а збоку ланцюг публікації з попередньою збереженою версією та автоматичним поверненням.

Дані

Чого торкаємося, де воно лежить і скільки лишається

Запитання, які ставить кожен, у кого є відповідальний за захист даних, — поставлені тут раніше, ніж їх поставить він.

Де фактично зберігаються дані і як це перевіряється: Локацію підтверджують з машини, а не з документації: сервіс метаданих провайдера показує реальний регіон, а реєстр адреси показує країну. Наші системи розміщені в OVHcloud, București, România, і на Microsoft Azure, Poland Central — обидва в Європейському економічному просторі. Резервні копії громадянської платформи зберігаються в північному регіоні Союзу, з реплікацією в другий регіон також із Союзу. Ці рядки замінили довший список локацій, який ми не змогли підтвердити.
Що ми бачимо під час роботи: Конфігурація, журнали, схема бази та стан процесів. Зміст персональних даних не входить до роботи; де для налагодження все ж потрібен приклад, використовується спеціально створений випадок. Адміністративний доступ надається на час втручання, іменний, і відкликається в кінці — а відкликання перевіряється, а не припускається.
Журнали і скільки вони живуть: Вебжурнали цього сайту ротуються щодня, із чотирнадцятьма збереженими екземплярами, з правами читання, обмеженими групою адміністрування. На рівні контейнерів ротацію виконує контейнерний рушій, із зафіксованими розміром і кількістю файлів, щоб надто балакучий сервіс не заповнив диск і не зупинив базу даних — найбанальніший спосіб упасти в production.
Секрети не зберігаються в сховищі: Чутливі значення потрапляють із файлів середовища з обмеженими правами, які читає системна одиниця, а не записує в одиницю — тому що визначення одиниці та системний журнал є доступними для читання більшій кількості людей, ніж здається. У ланцюгу публікації файл середовища продукції не проходить через кодову платформу: його копіюють локально на машину і одразу видаляють після побудови. Коли ми беремо на себе наявну інфраструктуру, перший прохід завжди є інвентаризацією секретів, що потрапили до сховищ, із планом ротації.
Безперервність: що відбувається, коли ми йдемо: Передавання означає доступ у власному обліковому записі у постачальника інфраструктури, сховище з усіма конфігураціями серверів, процедуру публікації та повернення, процедуру відновлення резервної копії — перевірену, а не просто записану — і список запланованих завдань із тим, що робить кожне. Блокування від випадкового видалення ставиться на групу ресурсів продукції від самого початку.

Випадок

Щоденний звіт, який не запускався одинадцять днів, у системі, де все відповідало 200

Ситуація

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

Що ми збудували

Щоденний звіт був відсутній одинадцять днів, і єдиним слідом була порожнеча в таблиці, на яку ніхто не дивився. Виявилися дві окремі вади. Перша: лічильник, запущений всередині застосунку, скидається щоразу після перезапуску служби, тож процедура з інтервалом, довшим за інтервал між публікаціями, ніколи не спрацьовує. Друга, більш підступна: процедура була правильно запущена всі одинадцять разів і щоразу повертала код 200 — але тіло відповіді містило часткові збої, які ніхто не читав.

Що вийшло

Планування було перенесене поза застосунок, у системний планувальник, якому байдуже до перезапусків. Виконання було загорнуте в скрипт, який записує один рядок журналу на кожен запуск, проходить тіло відповіді за ключами збоїв і надсилає сповіщення до каналу обміну повідомленнями — з обмеженням частоти, щоб залежність, що падає весь день, не створила дев’яносто шість однакових повідомлень. Відповідь 200 із внутрішніми збоями тепер має власний стан, окремий від успіху.

Чого цей випадок не каже

Усе це не було проблемою інфраструктури в класичному сенсі: сервер працював, на диску був простір, процес був живий. Саме тому це тривало одинадцять днів. Найдорожчі операційні вади — не падіння, їх видно, — а речі, які звітують про успіх, нічого не роблячи. Перевірка справності, яка має значення, не питає «ви запущені?», а питає «ви зробили те, що мали, стільки разів, скільки мали?».

Питання

Про що нас питають, перш ніж зателефонувати

Де фактично зберігатимуться наші дані?

Де ви оберете, і ми перевіримо, що вони справді там. Наші системи розміщені на OVHcloud, București, і на Microsoft Azure, Poland Central, обидва у Європейському економічному просторі, а місце було підтверджено шляхом опитування служби метаданих віртуальної машини та реєстру адреси — не читанням документації постачальника. Перевірка має значення: для передавання всередині Європейського економічного простору розділ про передавання у Законі 195/2024 не застосовується і не потрібні спеціальні дозволи. Поза ним з’являється пакет гарантій.

Чому власний сервер, а не керована платформа?

Не завжди. Керована платформа — правильний вибір, коли команда маленька, трафік нерівномірний і ніщо в стеку не має вимог до резидентності. Власний сервер стає кращим аргументом у трьох ситуаціях: коли дані мають залишатися в певній юрисдикції, коли витрати стають непередбачуваними в масштабі, і коли ви хочете мати змогу забрати все й піти. Ми робили і зворотну міграцію для власної системи: з бази даних, розміщеної у Сполучених Штатах, до саморозміщеного стеку в Європейському Союзі, з вісьмома контейнерами — база даних, автентифікація, REST-інтерфейс, реальний час, сховище, метадані, панель і шлюз доступу.

Що трапляється, якщо публікація виходить невдало?

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

Ви робите резервні копії? Як часто і чи тестуєте їх?

Щодня там, де ми її побудували — і ми це підкреслюємо, тому що автоматична копія не з’являється сама по собі, коли ви переносите застосунок на сервер. Копія запускається у фіксований час, відновлюється під час наступного boot, якщо машина була вимкнена, а якщо експорт виходить порожнім, виконання вважається збоєм. Копія також виходить за межі машини, до регіону в Європейському Союзі, з реплікацією, версіонуванням, зворотним видаленням і автоматичним завершенням строку дії. Тест відновлення є частиною доставки: копія, яку ніколи не відновлювали, — це припущення, а не копія.

Хто дізнається першим, коли щось падає?

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

Чи застосовуєте ви автоматично міграції бази даних під час кожного публікування?

Ні, і це свідоме рішення, а не недогляд. Ланцюг публікування будує і копіює код; і все. Зміни схеми — це версійовані файли в репозиторії, що застосовуються вручну, зі свіжою резервною копією позаду, а компоненти, які тримають свою схему в пам’яті, перезапускаються після цього. Міграція, застосована автоматично на production процесом, який не знає, що є в таблиці, — це звичайний спосіб безповоротно втратити дані.

Як ви запобігаєте тому, щоб ваш ланцюг публікування став шляхом атаки?

Через три правила. Зовнішні дії прив’язуються до повного хешу commit, а не до тегу — у березні 2026 року широко використовувану дію було перенаправлено з її тегів на шкідливий код, і це зачепило понад 23.000 репозиторіїв за 24 години. Робоча копія не зберігає облікові дані. Публікування не виконується ключем доступу, що зберігається на платформі коду, а через власний виконуваний компонент, який працює на цільовій машині, з правами, наданими точково. Ми визнаємо, що не всі наші старі проекти ще дотримуються всіх трьох правил; їхня міграція — це окрема робота.

Ви берете інфраструктуру, зроблену кимось іншим?

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

Що відбувається, якщо ми захочемо працювати з кимось іншим?

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

На чому ґрунтуються твердження вище (30 джерел)

https://www.megapromoting.com відповідає 200 на nginx + Next.jshttps://www.megapromoting.com/servicii · 2026-09-06

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

Як ми працюємо Усі послуги

Що вам хотілося б налагодити?

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

Поговорімо