Серверы настраивают вручную: почему drift дороже автоматизации

Новый сервер поднимают «как тот, боевой». Админ час вспоминает пакеты, правит конфиги руками, копирует файлы с прод хоста. Через полгода в кластере пять «почти одинаковых» машин. На одной другая версия библиотеки, на второй забыли агент мониторинга, на третьей SSH-ключ подрядчика, которого уже нет.

Когда падает сервис, отладка превращается в археологию. Тестовый контур не воспроизводит прод. Новый инстанс для нагрузки собирают сутки. После аварии «поднять такой же» нельзя — такого же больше не существует.

Ручная настройка кажется дешёвой, пока не считаешь время на drift, инциденты и онбординг следующего админа.

Где ручной труд бьёт по бизнесу

Масштабирование. Акция или сезон — нужны ещё две ноды. Вместо часа получается ночь ручной работы и риск забыть фаервол.

Безопасность. Патчи накатывают «где вспомнили». Часть хостов отстаёт, и именно она становится точкой входа.

Аудит и замена людей. Уходит единственный, кто «знает, как у нас принято» — вместе с ним уходит способ собрать среду.

Типичные оправдания

«У нас мало серверов, Ansible не окупится». Как раз на малом парке цена ошибки выше: нет запаса людей, каждый хост критичен.

«Автоматизация займёт месяц, а надо вчера». Ручной пожар тушат сегодня и повторяют каждый квартал. Автоматизация окупается на втором третьем воспроизведении.

«Мы уже в облаке, там всё само». Образ VM без кода конфигурации — та же снежинка, только в чужом датацентре.

Практичный минимум автоматизации

Не нужно сразу «весь enterprise инфраструктура как код». Нужен воспроизводимый путь от нуля до рабочего сервера роли: веб, БД, бастион, мониторинг.

Зафиксируйте эталон: список пакетов, пользователей, агентов, базовых усиление защиты настроек. Соберите это в роли (Ansible, cloud-init, образ + playbook — инструмент вторичен). Новый хост поднимается из эталона, а не из памяти.

Отдельно уберите ручной SSH-дрейф: изменения только через конфигурацию и репозиторий. Исключения документируйте — иначе снова снежинки.

Для облака добавьте шаблон сети и политик: security groups, диски, бэкапы. Иначе «сервер из playbook» живёт в уникальном сетевом болоте.

• одна команда/пайплайн = новый хост роли;
• тестовый контур собирается тем же способом, что прод;
• секреты — в хранилище, не в скриптах;
• проверка: уничтожили тестовый хост и собрали заново без сюрпризов.

С чего начать на этой неделе

Выберите одну самую болезненную роль — обычно веб или бастион. Опишите, как её собирают сейчас. Вынесите шаги в playbook. Следующий сервер поднимайте только так. Остальные роли — по очереди, не «всё сразу идеально».

Как убедить бизнес в автоматизации

Считайте не «красоту Infrastructure as Code», а часы на подъём нового хоста, время восстановления, число уникальных отличий между серверами и инциденты из-за «забыли накатить агент». Эти цифры переводят разговор из религии в экономику.

Покажите риск зависимости от одного администратора: что будет, если человек недоступен в момент масштабирования. Воспроизводимая сборка — это ещё и страховка непрерывности команды.

Начните с политики: ручные изменения на проде без записи в конфигурацию считаются инцидентом. Иначе playbook появится, а drift продолжит жить через SSH «на пять минут».

Через месяц после первой роли проведите контроль: поднимите хост с нуля по инструкции новичка. Если не получается — автоматизация ещё не автоматизация, а черновик.

Секреты, образы и окружения

Автоматизация без аккуратных секретов создаёт новый риск: ключи в репозитории, пароли в скриптах, одинаковые учётки на всех хостах. Вынесите секреты в хранилище и ротируйте их по регламенту.

Разведите сборку базового образа и прикладную конфигурацию. Так быстрее патчить систему и не смешивать «золотой образ» с разовыми костылями приложения.

Тестовый контур обязан собираться тем же пайплайном, что прод. Иначе вы снова отлаживаете снежинки и удивляетесь, почему на бою «другое поведение».

Ведите короткий каталог ролей: веб, база, бастион, мониторинг. Новые серверы появляются только из каталога. Всё, что вне каталога, считается техническим долгом с датой устранения.

На практике хорошо заходит правило «двух одинаковых поднятий». Если роль нельзя дважды подряд собрать с нуля и получить совпадающий результат, автоматизации ещё нет — есть черновик. Это простой критерий готовности, понятный и инженеру, и руководителю.

Добавьте инвентаризацию исключений: всё, что пока нельзя описать кодом, должно быть списком с датой. Иначе исключения становятся новой нормой, а drift возвращается под другим названием.

Свяжите автоматизацию с мониторингом: новый хост сам регистрируется в системе наблюдения и сразу получает базовые алерты. Сервер без мониторинга — незавершённая роль, даже если приложение уже отвечает.

Ещё один критерий зрелости — время онбординга нового инженера. Если человеку нужно две недели «узнавать наши снежинки», автоматизация не выполняет одну из главных задач: сохранять знания в коде и документации, а не в головах.

Наконец, свяжите релизы приложений и сборку инфраструктуры. Когда приложение выкатывают автоматически, а сервер под него собирают вручную, вы просто переносите хрупкость на другой уровень.

Практичный следующий шаг после первой роли — каталог запретов: что нельзя делать руками на проде без задачи и изменения в конфигурации. Без запрета автоматизация останется параллельной реальностью рядом с SSH.

И фиксируйте экономию времени публично: «новый веб сервер подняли за N минут». Видимый результат легче защищает продолжение работ, чем абстрактные разговоры про drift.

Итог

Ручная настройка серверов создаёт уникальные снежинки и дорогой drift: долгие аварии, невозможность масштабироваться и зависимость от одного человека.

Автоматизация на старте — это не мода, а способ сделать среду воспроизводимой. Начните с одной роли и запрета «подправить руками на проде». Уже это окупается на первом срочном масштабировании или восстановлении.