Настройки серверов разъехались из‑за ручных правок: как вернуть контроль

На одном сервере nginx настроен «как надо», на втором — почти так же, но с другой версией модуля и ручным патчем в юните systemd. На третьем кто-то «временно» открыл порт и оставил. Документации нет. Новый человек спрашивает: «Какой из трёх эталон?» Ответа нет. Эталон размазан по истории чатов и памяти уехавшего админа.

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

Как дрифт проявляется в авариях

Сценарий «на проде работает, на новом узле — нет». Автоскейл или замена железа поднимает «чистый» сервер. Сервис падает, потому что живая конфигурация никогда не была полной в репозитории.

Сценарий «починили один, сломали одинаковость». Срочный sysctl или правка лимитов на одном хосте спасла ночь. Через месяц балансировщик показывает разное поведение нод — и никто не связывает это с той правкой.

Сценарий аудита безопасности. Требуют подтвердить, что SSH и sudo одинаковы. Обход серверов вручную занимает дни и находит зоопарк исключений.

Почему ручные правки побеждают процесс

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

Нет запрета на тихие изменения. Можно править прод без заявки в IT и без записи.

Нет эталонного образа. Каждый сервер рождается уникальным с первого дня.

Как вернуть воспроизводимость

Сначала выбирают источник истины. Это может быть система управления конфигурацией, образ ВИМ/контейнера, пакет политик — инструмент вторичен. Важно правило: то, чего нет в источнике истины, считается случайностью.

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

Дальше собирают эталон для одной роли: web, db, bastion. Выравнивают группу серверов этой роли под эталон. Только потом берут следующую роль. Попытка «выровнять всё сразу» обычно тонет.

Хотфиксы не запрещают — их канализируют. Аварийная правка допустима, но в течение короткого окна должна либо попасть в код/рецепт, либо быть откатана. Иначе дрифт снова станет официальной политикой.

Опытный подход в связке с виртуализацией и серверной эксплуатацией предполагает также одинаковые базовые образы и понятный пайплайн обновлений. Иначе вы лечите симптомы на уже разъехавшихся машинах.

Признаки, что контроль вернулся

• новый сервер роли поднимается без ручного «ещё чуть-чуть»;
• diff эталона и хоста пустой или объясним исключением с владельцем;
• инцидент больше не требует SSH археологии по пяти машинам «на удачу»;
• обновление парка планируется, а не откладывается из страха.

Полезно завести простой ритуал: раз в неделю отчёт о дрифте по критичным ролям. Даже короткий список расхождений держит дисциплину лучше, чем годовой «проект наведения порядка», который никто не начинает.

Культура изменений важнее инструмента

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

Полезно разделить роли серверов жёстко. Чем меньше уникальных ролей, тем проще эталоны. Зоопарк «на этой машине ещё и вот это» — главный враг воспроизводимости.

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

Обновления пакетов тоже проводят через ту же дисциплину. Иначе после патч дня получите новый дрифт уже на уровне версий.

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

Итог

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

Благодаря воспроизводимой конфигурации бизнес ускоряет восстановление сервисов и делает изменения более предсказуемыми. Инфраструктура становится стандартизированной, что упрощает управление.

Бизнес результат

Стандартизация конфигураций позволяет сократить время на восстановление сервисов и уменьшить затраты на изменения. Уникальность каждой конфигурации перестаёт быть проблемой.

Для руководителя это звучит просто: можно заменить узел, масштабироваться и обновляться без лотереи. Пока настройки разъехались, любой рост инфраструктуры размножает хаос. Когда эталон живой — рост размножает рабочую схему.

Введите простой индикатор здоровья парка: процент хостов роли без дрифта относительно эталона. Пусть это будет видно так же, как доступность. То, что измеряют, начинают чинить.

Новых сотрудников онбордьте через эталон, а не через «спроси у Сергея, как у нас принято». Иначе дрифт воспроизводится через культуру быстрее, чем через технологии.

Запретите «тихие» правки на проде без follow-up задачи в эталон. Можно чинить ночью, нельзя забывать утром.

Публикуйте еженедельный список хостов с дрифтом. Прозрачность сама снижает число снежинок.

Новую роль серверов не запускайте, пока для неё нет эталона. Иначе вы сознательно размножаете хаос.

Выберите одну роль и доведите diff до нуля — это демонстрация метода для руководства. Большой bang «выровнять всё» обычно тонет.

Хотфикс без задачи на возврат в эталон считайте незакрытым инцидентом. Иначе дрифт снова станет политикой.

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

Свяжите дрифт с риском безопасности: расхождение SSH/sudo между хостами — не косметика, а поверхность атаки. Так проще получить мандат на эталон.

Если не обновлять эталон после каждого хотфикса, то система управления конфигурацией не будет работать эффективно.