Настройка 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. Ниже — вводные, которые запрашиваем на старте; часть из них можно собрать прямо на созвоне, если документации нет.
- Схема инфраструктуры: какие сервисы работают, где размещены, какие внешние зависимости и что критично по доступности.
- Как выпускаются изменения сейчас: где лежат код и конфигурации, кто и какой командой проводит релиз, сколько времени занимает откат на предыдущую версию.
- Доступы для разбора: токены с правами только на чтение в облако, доступ к хранилищу кода, системам наблюдения за состоянием сервисов и журналам.
- Ограничения: требования безопасности, отраслевые регламенты, окна, в которые работы запрещены, и сервисы, которые нельзя останавливать.
- Ожидания по объёму: внедрение с нуля, расширение текущей автоматизации инфраструктуры или поддержка инфраструктуры после запуска.
- Уже случившиеся сбои: что ломалось, как восстанавливались, какие ручные операции выполняются регулярно и кем.
В ответ вы получаете карту среды с узкими местами, поэтапный план, состав работ и границу ответственности: что закрываем мы, а что остаётся на вашей стороне. Опишите задачу — вернёмся с оценкой и планом.
