Новый админ хочет всё переделать: как отличить дело от самоутверждения

MAATRIX

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

Почему новый человек почти всегда хочет что-то переделать

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

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

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

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

Все три причины работают одинаково и когда переделка реально нужна, и когда не нужна вовсе — само по себе желание переписать ничего не говорит об обоснованности. Дальше нужны критерии, не зависящие от того, насколько убедительно звучит презентация.

Признаки реальной проблемы: за предложением стоит технический долг

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

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

Масштаб решения соразмерен масштабу проблемы. Если сервис падает из-за нехватки памяти на одном компоненте — решение это увеличить лимит или найти утечку, а не переезд на новую архитектуру целиком. Когда небольшая проблема лечится тотальной переделкой всего стека, стоит спросить: почему нельзя точечно?

Специалист называет цену бездействия конкретно. Не абстрактное «это небезопасно», а «если не обновить версию, уязвимость уже в открытых базах CVE, и её найдёт первое же автоматическое сканирование». Подробнее о том, как оценивать работу технического специалиста, не разбираясь в деталях самому, — в статье «Как проверить работу админа, если сами вы в серверах не разбираетесь»: многие маркеры оттуда (отчётность, готовность объяснять, независимый аудит) работают и здесь.

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

Признаки синдрома новой метлы

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

Предложение не привязано к деньгам или риску бизнеса. Если разговор идёт в категориях «так правильнее», «так принято», «более современно» — без единого слова о том, что это изменит для бизнеса, это разговор об эстетике, а не об управлении рисками.

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

Раздражение или уклонение в ответ на «объясните попроще». Поток терминов без перевода, снисходительное «вы всё равно не поймёте», «просто доверьтесь» — тревожный сигнал вне зависимости от того, права переделка по существу или нет. Кто продумал решение, обычно объясняет суть в двух-трёх предложениях даже без технического бэкграунда у слушателя.

Спешка без веской причины. «Решить нужно прямо сейчас, иначе будет поздно» в отношении изменений, не связанных с активным инцидентом, — приём из продаж, а не инженерная практика. Настоящая срочность (эксплуатируемая уязвимость, реальный риск потери данных) обосновывается фактами и без давления — их и так достаточно, чтобы убедить.

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

Как оформить обоснование в документе, а не на словах

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

1. Проблема: что не работает или работает плохо (факты, даты)
2. Последствия бездействия: что случится, если не менять, и через какой срок
3. Варианты решения: минимум два — точечное исправление и полная переделка
4. Сравнение по деньгам, времени и риску простоя
5. План выполнения: этапы, даты, что со старой системой на каждом этапе
6. План отката: что делать, если новое решение не заработало как ожидалось

Эффект двойной. Во-первых, вы получаете структурированную информацию для решения даже без понимания деталей реализации. Во-вторых, сам процесс написания отсеивает часть случаев синдрома новой метлы естественно: специалисту, который предлагает переделку из желания показать себя, обычно сложнее заполнить пункты 2, 4 и 6 конкретикой, чем тому, кто действительно наткнулся на проблему и продумал решение.

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

Правило «сначала стабилизировать, потом улучшать»

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

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

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

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

Как не дать сломать рабочую систему ради красивого кода

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

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

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

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

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

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

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