Налаштування Hetzner Cloud: де ручне керування дає збій
Налаштування Hetzner Cloud через панель і ssh-сесії працює рівно до першого розходження. Минулого тижня підняли ліміти, додали правило у файрвол, примонтували диск під логи — у листуванні пара рядків, у репозиторії порожньо. За місяць інженер розгортає копію під навантажувальний контур і отримує іншу систему.
Дрейф конфігурації — прямий наслідок ручного адміністрування серверів. Робочий і тестовий контури розходяться за десятком дрібниць: версія бібліотеки, порядок запуску служб, забутий параметр ядра.
Кожна окремо нешкідлива, разом — це вже інше середовище, і будь-яка діагностика починається зі звірки «а як у нас насправді».
Ціна проявляється в момент відмови. Відновлення середовища перетворюється на археологію: піднімати з пам’яті, шукати, хто і коли правив мережеві правила, вгадувати, які сертифікати прив’язані до старої адреси.
Простій рахується годинами, а впевненості, що нова збірка ідентична загиблій, немає ні в кого — відтворюваного відкату до попереднього стану просто не існує.
Найтихіше поводиться третій збій: незадокументовані зміни не спливають до аудиту або передачі проєкту іншій команді. Тоді з’ясовується, що половина налаштувань живе лише в голові однієї людини, а вхід в інфраструктуру є в усіх, хто колись підключався. Розбираємо, як це закривається.
Що дає декларативна інфраструктура: вимірювані ефекти
Декларативний опис середовища прибирає головне джерело аварій — розходження між документацією і тим, що реально працює на серверах.
Поки інфраструктуру правлять руками через панель керування Hetzner Cloud, кожна зміна живе в історії чужих сесій, і збій доводиться розбирати з пам’яті.
Єдине джерело правди про середовище змінює картину: стан середовища — файл у репозиторії, а сервери приводяться до нього автоматично.
Швидкість відновлення після збою
Середовище піднімається з опису заново, а не збирається по кроках із чек-листа. Повернення після відмови вузла або цілої зони займає десятки хвилин: розгортається та сама конфігурація, що працювала до збою, включно з мережевими правилами, балансуванням і прив’язкою сховищ.
Відкат до попереднього стану — це повернення до минулої версії опису, а не пошук відмінностей за логами. Клас відмов «забули параметр під час ручної правки» зникає разом із самими ручними правками.
Відтворюваність середовищ
З одного опису піднімаються тестовий, передпродуктивний і продуктивний контури — з однаковою мережевою топологією і однаковими правилами доступу.
Розходження між середовищами перестають бути загадкою: якщо щось працює на тесті й не працює в проді, різниця видна в описі, а не шукається днями.
Середовище під навантажувальну перевірку або під окремого замовника створюється й видаляється цілком, без забутих ресурсів, які продовжують працювати й вимагати уваги.
За галузевими даними DORA, у команд із високим рівнем автоматизації відновлення після інциденту вимірюється десятками хвилин, і саме швидкість повернення до робочого стану найсильніше скорочує час простою.
Підходи до керування інфраструктурою: порівняння режимів
Режим керування визначає, скільки ручної роботи коштує кожна зміна і як швидко команда відновлюється після збою. Нижче — чотири варіанти, між якими реально обирають під час налаштування Hetzner Cloud.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручне адміністрування | разові стенди під експеримент | стан не зафіксовано, стенди розходяться, відкат вручну |
| Декларативний опис | постійна інфраструктура, кілька середовищ | потрібен контроль стану й рев’ю змін |
| Збірка образів серверів | багато однотипних вузлів, часті оновлення | образ перезбирається за кожної правки, випуск довший |
| Цикл безперервної доставки | часті релізи, кілька команд | вищий поріг входу: потрібні перевірки у гілці й спостережуваність |
Обмеження ручного режиму
Ручний режим тримається на пам’яті виконавця: сервер із правками в конфігурації не можна відтворити один в один, тому розходження між стендами накопичується місяцями й проявляється в момент збою. Відновлення після відмови займає години, а причина поточних налаштувань живе в листуванні.
Ціна переходу до декларативного опису
Переходити можна частинами: спочатку описуємо мережу, правила доступу й сервери, потім збірку образів і доставку. Основні витрати — імпорт наявних ресурсів і спільне сховище стану; далі кожна зміна перевіряється до застосування, а середовище піднімається відтворювано й однаково.
Порядок упровадження: аудит, налаштування, перевірка, передача
Упровадження в Hetzner Cloud іде ітераціями: спочатку фіксуємо фактичний стан середовища, потім переносимо його в опис і лише після цього вмикаємо автоматичні перевірки.
На кожному кроці середовище залишається робочим — відкат можливий, поки новий контур не підтвердив еквівалентність.
Аудит поточного середовища
- Інвентаризація: збираємо сервери, мережі, томи, DNS-записи, сертифікати, доступи й зовнішні залежності; розходження між документацією і фактом виносимо окремим списком.
- Аудит конфігурації: звіряємо правила міжмережевого екрана, розмежування прав, ротацію ключів, режими резервного копіювання; позначаємо ручні правки, які не переживуть перестворення ресурсу.
- План міграції: розкладаємо перенесення за групами — що описуємо як код одразу, що залишається ручним, у якому порядку перемикаються середовища; для кожного кроку визначаємо точку повернення.
Збірка, перевірка і передача
- Опис середовища як коду: модулі Terraform, розділення середовищ, стан у спільному сховищі з блокуваннями, перегляд плану змін до застосування.
- Конвеєр: збірка образу, тести, публікація в реєстр, доставка через GitOps-агент; секрети надходять зі сховища, а не лежать у репозиторії.
- Перевірка конфігурації: звіряємо фактичний стан з описаним і проганяємо сценарії відмов — недоступність вузла, втрата зв’язку зі сховищем стану, помилковий план.
- Передача в експлуатацію: регламент випуску й відкатів, моніторинг і оповіщення, порядок розбору інцидентів, навчання команди й передача доступів.
Артефакти упровадження: конфігурації, схеми, регламенти
На виході в команди замовника залишається не набір скриншотів із панелі керування, а репозиторій, з якого інфраструктура розгортається заново з нуля.
Конфігурації, схеми й регламенти лежать поруч із кодом застосунку, проходять рев’ю і версіонуються — будь-яка зміна середовища видна в історії.
- Опис інфраструктури — конфігурація на Terraform: сервери, мережі, балансувальники, сховища й зв’язки між ними.
- Схема мережі — поділ на приватний і публічний сегменти, підмережі, точки виходу в інтернет, правила маршрутизації.
- Політики доступу — ролі й ключі, розділення бойового й проміжного контурів, порядок видачі й відкликання доступів.
- Регламент відновлення — цільовий час і точка відновлення, порядок підняття зі снапшотів, ролі під час збою.
- Документація щодо середовищ — чим відрізняються прод, стейдж і тестове середовище, які змінні, секрети й ліміти задано.
- Інструкції з викочування — як проходить збірка й доставка, де точки ручного підтвердження, як відкотити реліз.
- Пам’ятка чергового — типові інциденти й перші дії за кожним.
Документація і порядок відновлення
Регламент описує відновлення покроково: підняття мережі, розгортання сервісів із конфігурації, перевірка після відкату. Його оновлюють за кожної зміни інфраструктури — інакше за місяць він розійдеться з реальністю. Раз на квартал проводимо навчальне відновлення на окремому майданчику й фіксуємо фактичний час.
Кейс: переведення сервісу на декларативний опис середовища
Сервіс із шести компонентів жив на серверах, зібраних вручну в панелі Hetzner Cloud: конфігурація кожного середовища існувала лише в історії дій інженера, який її налаштовував.
Через пів року тестовий контур перестав збігатися з продуктивним — розходження спливали вже на викочуванні, а підняття нового середовища займало два-три дні й трималося на одній людині, яка пам’ятала порядок кроків.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час підняття середовища | 2–3 дні | 25 хвилин |
| Частка випусків без ручних доопрацювань | 68% | 97% |
| Інциденти через розсинхрон середовищ | 5–6 за квартал | 0–1 |
Середовище стало результатом одного опису: змінюється змінна — змінюється тільки вона, а не набір ручних правок, що розійшлися трьома контурами. Повторний запуск на чистому середовищі дає ідентичний результат, тому «у мене локально працює» перестало бути аргументом.
Що дало розділення середовищ
Ми розвели продуктивний, передпродуктивний і тестовий контури на окремі набори описів зі спільними модулями. Розходження тепер видно на етапі перевірки змін, а не на промисловому контурі: різниця конфігурацій обчислюється автоматично й потрапляє в рев’ю.
Відкат виконується повторним застосуванням попереднього опису — випуск перестав бути незворотною дією, і черговий інженер повертає робочу версію за хвилини, без відновлення з резервної копії.
Підсумок: підготовка середовища скоротилася з днів до пів години, а частка випусків, що потребували ручних доопрацювань після викочування, упала втричі.
Що робити, якщо інфраструктура вже розгорнута вручну?
Розгорнуте вручну середовище не вимагає зупинки сервісу, щоб потрапити під керування описом. Перший крок — інвентаризація ресурсів: зібрати сервери, томи, приватні мережі, балансувальники, DNS-записи, правила файрвола і те, що реально запущено на кожному вузлі.
Частина картини видна через API провайдера, частина — тільки з самих машин: юніти systemd, завдання cron, контейнери, точки монтування й зовнішні залежності, про які пам’ятає лише той, хто налаштовував.
Далі — опис чинного середовища, а не бажаного. Ми фіксуємо поточний стан як є, включно з ручними правками й історично складними місцями, та імпортуємо наявні ресурси, не перестворюючи їх.
Імпорт наявної інфраструктури читає реальні ідентифікатори й прив’язує їх до конфігурації — сервіс продовжує працювати, а план змін на цьому етапі залишається порожнім.
Порожній план і є головним критерієм: він доводить, що опис збігся з реальністю, і лише після цього можна щось змінювати.
Поетапна міграція йде від периферії до ядра: спочатку те, що не впливає на трафік — снапшоти, мережі, правила доступу, потім середовища, і вже потім вузли під навантаженням.
Кожен етап закривається перевіркою плану без застосування; розходження розбираємо до нуля, і лише тоді зміни йдуть у прод. Окремо вирішуємо, що залишається ручним: сховища зі станом вводять пізніше й обережніше, бо ціна помилки там вища, ніж у веб-вузла.
Страховка на кожному кроці та сама — свіжий снапшот і відсутність змін у проді до явного підтвердження. Так середовище переходить під опис без простою, а подальші правки вже проходять через рев’ю, як звичайний код.
Технічні сумніви: доступи, секрети, відкат змін
Сумніви щодо інфраструктурних проєктів зазвичай ті самі: де лежать ключі, у кого є доступ до продуктивного середовища, що буде, якщо зміна зламає конфігурацію.
Нижче — короткі відповіді за кожним пунктом: як це влаштовано в наших упровадженнях на Hetzner Cloud і чому саме так, а не інакше.
Де зберігаються секрети й ключі доступу?
В окремому сховищі секретів, а не в git і не у файлі стану Terraform. Застосування читає їх у момент виконання, тому в репозиторії й журналах збірки залишаються тільки посилання на запис. Ключі видаються сервісним обліковим записам з обмеженим терміном життя, ротація йде за розкладом.
Як розмежовуються ролі й права?
Кожній ролі — мінімально необхідний набір прав: інженер застосовує план у тестовому середовищі, продуктивне змінюється тільки через конвеєр після погодження. Постійних ручних доступів у прод немає: вони видаються на час і потрапляють у журнал.
Що відбувається за невдалої зміни?
Інфраструктура описана кодом, тому відкат — це повернення до попередньої ревізії та повторне застосування. Стан версіонується, зміни ідемпотентні, тож повернення займає хвилини замість годин ручного лагодження.
Як ведеться аудит дій?
Будь-яка зміна проходить через запит на злиття з обов’язковим переглядом, тому в історії видно, хто, коли і навіщо правив конфігурацію. Журнал дій облікових записів зберігається окремо від робочого середовища.
Обговоримо завдання: розберемо ваше середовище і повернемося з планом
Щоб повернутися з оцінкою і планом робіт, а не із загальними словами, нам потрібен доступ до фактів про ваше середовище в Hetzner Cloud. Нижче — вступні дані, які запитуємо на старті; частину з них можна зібрати прямо на дзвінку, якщо документації немає.
- Схема інфраструктури: які сервіси працюють, де розміщені, які зовнішні залежності й що критично за доступністю.
- Як випускаються зміни зараз: де лежать код і конфігурації, хто і якою командою проводить реліз, скільки часу займає відкат на попередню версію.
- Доступи для розбору: токени з правами лише на читання в хмару, доступ до сховища коду, систем спостереження за станом сервісів і журналів.
- Обмеження: вимоги безпеки, галузеві регламенти, вікна, у які роботи заборонені, і сервіси, які не можна зупиняти.
- Очікування щодо обсягу: упровадження з нуля, розширення поточної автоматизації інфраструктури або підтримка інфраструктури після запуску.
- Уже наявні збої: що ламалося, як відновлювалися, які ручні операції виконуються регулярно і ким.
У відповідь ви отримуєте карту середовища з вузькими місцями, поетапний план, склад робіт і межу відповідальності: що закриваємо ми, а що залишається на вашому боці. Опишіть завдання — повернемося з оцінкою і планом.
