Что перестают делать опытные админы и почему

MAATRIX

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

Перестают чинить руками на проде

На старте карьеры путь к решению проблемы выглядит прямым: зашёл по SSH, открыл nano /etc/nginx/nginx.conf, поправил директиву, перезапустил сервис, проблема исчезла. Это быстро, наглядно, и результат виден сразу — этим объясняется вся привлекательность подхода: правка займёт две минуты, а оформление pull request'а и прогон CI — двадцать.

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

Дальше опытные админы держат конфиги в git, применяют их через Ansible или хотя бы через scp из репозитория, а разницу перед выкладкой смотрят предсказуемо:

git diff origin/main -- configs/nginx/site.conf
ansible-playbook -i inventory/prod deploy_nginx.yml --check --diff

Флаг --check --diff показывает, что именно изменится на сервере, до того как это применится — это тот шаг, которого не хватает ручной правке в принципе. Подробный разбор этого антипаттерна и переход на версионирование конфигов — в статье про правку конфигов на проде.

Есть исключение, о котором стоит сказать честно: разовая диагностическая команда вроде curl -v localhost:8080/health или journalctl -u myapp -f — это не правка состояния, и её не нужно проводить через пайплайн. Граница простая: если команда меняет файл или конфигурацию сервиса — она идёт через git и деплой; если только читает — можно и руками.

Перестают паниковать на первом алерте

Первый месяц работы с продакшеном обычно проходит по одному сценарию: приходит алерт «диск заполнен на 92%» или «5xx на бэкенде выросли», и рука сама тянется удалять логи, перезапускать сервис или увеличивать лимиты — лишь бы алерт погас. Логика понятна: алерт горит, значит что-то сломано, значит нужно немедленно что-то менять, и любое действие кажется лучше бездействия.

Проблема в том, что перезапуск сервиса без понимания причины иногда просто прячет симптом на 20 минут, пока проблема не вернётся — а иногда делает хуже: docker restart контейнера с активной транзакцией к базе данных может оставить данные в неконсистентном состоянии, которое проявится не сразу. Опытные админы через несколько таких случаев вырабатывают другую последовательность действий:

1. Сначала посмотреть, что именно говорит алерт и с какого момента начался тренд — journalctl -u myapp --since "30 min ago" или график в Grafana за последний час.
2. Проверить, не связано ли с внешним фактором: деплой, ротация сертификатов, плановое обновление зависимостей, скачок трафика.
3. Только после этого выбрать действие — и часто оно не «перезапустить», а «подождать 5 минут и посмотреть на график», потому что проблема уже саморазрешилась.

Разница по времени невелика — 5-10 минут на чтение логов против немедленного действия — но именно эти минуты отделяют устранение причины от временного глушения симптома, который вернётся снова, обычно ночью.

Перестают полагаться на память о конфигурации

«Я помню, что там настроено» — фраза, которая работает первые полгода-год, пока серверов немного и все изменения делались лично. Полагаться на память интуитивно логично: держать в голове топологию из пяти серверов проще, чем писать документацию, которую, возможно, никто не прочитает.

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

Дальше конфигурация сервера описывается декларативно — Ansible-плейбуком, Terraform-модулем или хотя бы подробным README в репозитории с датой последнего изменения: подход, который в индустрии называют инфраструктурой как код. Промежуточный шаг, который тоже работает, — обычный текстовый файл SERVER-NOTES.md в репозитории проекта с датами и причинами изменений: не так надёжно, как IaC, но кратно надёжнее памяти.

Перестают ставить самое свежее ради самого свежего

Желание поставить последнюю версию PostgreSQL, свежий мажорный релиз ядра или бета-версию модуля nginx понятно: новая версия обещает более быструю работу, закрытые уязвимости и модные фичи, а на тестовом стенде за пять минут всё завелось без единой ошибки. Отказ от старых версий на проде интуитивно выглядит как забота о безопасности.

Расплата приходит, когда бета-релиз ломает совместимость с драйвером, который использует основное приложение, — и это выясняется не в тесте, а в продакшене под нагрузкой, потому что тестовый стенд не воспроизводил реальный профиль запросов. Или когда мажорное обновление PostgreSQL меняет поведение планировщика запросов, и запрос, который раньше выполнялся за 40 мс, начинает выполняться за 4 секунды — без единой ошибки в логах, просто медленно.

После одного-двух таких случаев выбор версии на проде смещается в сторону предсказуемости:

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

Перестают гнаться за трендом ради тренда

Kubernetes на проекте с одним сервером и тремя пользователями, микросервисная архитектура для MVP, который ещё не нашёл product-market fit, — типичное решение специалиста, который недавно прочитал статью о том, как эти технологии решают проблемы масштаба в компаниях с сотнями серверов. Логика на старте карьеры выглядит убедительно: «так делают в больших компаниях, значит это правильно, и лучше сразу заложить архитектуру на рост».

Опытные администраторы на практике сталкиваются с обратной стороной: Kubernetes на трёх нодах требует отдельного человека, который следит за самим кластером, а не за приложением, — control plane, etcd, сетевые плагины и their собственные отказы добавляют работы больше, чем экономят. Микросервисы, разнесённые ради «чистой архитектуры», превращают локальную отладку в распределённую трассировку по логам пяти контейнеров вместо одного стектрейса, а один упавший вспомогательный сервис иногда утягивает за собой остальные через таймауты синхронных запросов.

Дальше выбор технологии подчиняется не моде, а конкретным цифрам: сколько сейчас серверов, сколько человек их обслуживает, где реально узкое место. Разбор того, кому Kubernetes действительно нужен, а кому это лишняя эксплуатационная нагрузка, — в статье про миф о том, что Kubernetes нужен любому проекту; аналогичный разбор для микросервисов и монолита — в статье про миф «микросервисы правильно, монолит устарел». Docker Compose с тремя сервисами на одном VPS часто закрывает задачу полностью, и это не признак нехватки квалификации — это признак того, что технология выбрана под реальный масштаб, а не под резюме.

Перестают экономить на процессах, которые кажутся лишними

Три отдельные привычки, объединённые одной причиной отказа — цена ошибки оказывается выше сэкономленного времени.

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

Пропуск обновлений безопасности «на потом». Обновление безопасности откладывается, потому что оно не добавляет фич, а рисует шанс что-нибудь сломать прямо сейчас — логика «работает, не трогай» кажется безопаснее любого патча. Ломается это не сразу, а в момент, когда становится известно об эксплуатируемой уязвимости в конкретном пакете — и выясняется, что на сервере патч не стоит уже полгода, потому что «руки не дошли». Дальше это уже не гипотетический риск, а конкретное окно для эксплойта. Автоматизация регулярных обновлений безопасности через unattended-upgrades на Debian/Ubuntu или dnf-automatic на AlmaLinux закрывает вопрос системно, без ручного контроля каждого пакета.

Единственная резервная копия без плана восстановления. Бэкап настраивается один раз, складывается на тот же сервер или в тот же дата-центр, и на этом внимание к теме заканчивается — бэкап есть, значит, вопрос закрыт. Настоящая проверка происходит не в момент создания копии, а в момент восстановления, и именно тогда чаще всего выясняется, что бэкап на том же диске, который отказал, или что восстановление не тестировалось ни разу и занимает не полчаса, а шесть часов правок по ходу дела. Полноценный план аварийного восстановления — не про наличие копии, а про то, за сколько времени и в каком состоянии можно поднять сервис заново; разбор того, из чего состоит такой план для небольшой инфраструктуры, — в статье про план аварийного восстановления для малого бизнеса.

Перестают недооценивать мониторинг и риски безопасности

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

С безопасностью работает похожий механизм самоуспокоения: «у нас маленький проект, кому он интересен» — и это единственный пункт в списке, ошибка в котором не откладывается на будущее, а происходит один раз и сразу дорого. На практике сканеры уязвимостей и боты для брутфорса SSH не разбирают размер проекта — они перебирают целые диапазоны IP-адресов автоматически, вне зависимости от того, «интересен» ли конкретный сервер кому-то персонально. Отказ от иллюзии «со мной такого не случится» обычно происходит после первого реального инцидента — взлома, утечки или хотя бы обнаруженного майнера в процессах — и именно тогда чек-лист безопасности перестаёт быть формальностью и превращается в рабочий процесс: смена портов и ключей, fail2ban, аудит запущенных сервисов, план действий на случай, если что-то всё же произошло.

Частые вопросы