Приняли проект вместе с сервером: чек-лист первых суток

MAATRIX

Заказчик подписал договор, назвал дату старта — и вместе с проектом на вас свалился чужой сервер: с чужой конфигурацией, чужими паролями (или без них) и репутацией, которую теперь придётся поддерживать вам, хотя настраивал всё это не ваш инженер. Первые сутки такого перехода решают больше, чем кажется: именно в этот день закладывается, будете ли вы через месяц отвечать за чужие грехи, или у вас на руках будет чёткая картина того, что вы приняли и в каком состоянии. Ниже — чек-лист на первые 24 часа: не только технический аудит сервера, но и организационные вещи, без которых аудит бессмысленен.

Другой сценарий, чем «ушёл админ»: разграничим сразу

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

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

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

До первого захода на сервер: что нужно получить от заказчика

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

До первого реального захода на инфраструктуру запросите у заказчика письменно (email или таск-трекер — не устно на созвоне, чтобы был след):

• Доступы к серверу. SSH-ключ или временный пароль root/sudo-пользователя, IP или домен, порт SSH, если нестандартный.
• Доступ к панели хостинг-провайдера. Личный кабинет, где можно посмотреть статус оплаты, снапшоты, консоль (VNC/IPMI) на случай, если SSH внезапно отвалится.
• Доступ к регистратору домена и DNS-зоне — отдельная система, которая часто не совпадает с хостингом сервера, и без неё вы не сможете, например, продлить или перевыпустить сертификат при смене IP.
• Контакты предыдущего исполнителя, если он ещё выходит на связь — не для того, чтобы делить вину, а потому что пять минут его комментария экономят часы вашего разбора.
• Список известных проблем и хрупких мест, если заказчик о них знает: «раз в месяц падает импорт», «не трогайте cron в 3 ночи, там выгрузка в 1С» — то, что не видно снаружи, но известно тем, кто с этим уже жил.
• Контакт для эскалации на стороне заказчика — конкретный человек, который может быстро подтвердить критичное решение (например, разрешить перезагрузку продакшена), а не «весь отдел в почте».

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

Первые часы: экспресс-аудит сервера без права на ошибку

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

Минимальный набор, который стоит прогнать в первые часы, чтобы не потерять время на детальный разбор позже:

# базовая картина: сколько живёт без перезагрузки, кто заходил
uptime
last -20
cat /etc/os-release

# что слушает порты и что реально запущено
ss -tulpn
systemctl list-units --type=service --state=running
docker ps 2>/dev/null

# домены, которые обслуживает веб-сервер — обычно самый быстрый способ понять назначение
grep -r "server_name" /etc/nginx/sites-enabled/ 2>/dev/null
ls /etc/apache2/sites-enabled/ 2>/dev/null

# кто имеет доступ прямо сейчас
awk -F: '$7 !~ /nologin|false/ {print $1, $7}' /etc/passwd
for u in $(awk -F: '$7 !~ /nologin|false/ {print $1}' /etc/passwd); do
  echo "== $u =="; sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null;
done

# бэкапы: есть ли и когда снимались в последний раз
crontab -l | grep -iE "backup|rsync|dump"
find / -iname "*.sql.gz" -o -iname "*.dump" 2>/dev/null | grep -v proc | xargs ls -lt 2>/dev/null | head -5

Результат этого прогона — не готовый отчёт, а сырой снимок, который вы кладёте рядом с журналом наблюдений. Дальше два пути: либо картина простая (один сайт, понятный стек, свежий бэкап) — и можно двигаться дальше по чек-листу; либо картина сложная (десяток сервисов, самописная логика, следы забытых интеграций) — и тогда честнее сказать заказчику прямо сейчас, что полноценный аудит займёт не сутки, а несколько дней, чем героически обещать закрыть его к вечеру и не успеть. Подробный порядок такого более глубокого разбора — в статье про методичный разбор незнакомой машины, на которую мы уже ссылались.

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

Первые сутки: организационные точки с заказчиком

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

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

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

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

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

Протокол приёмки: зафиксируйте состояние на входе письменно

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

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

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

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

SLA переходного периода: что обещать, а что нет

Одна из типичных ошибок — подписывать полноценный SLA («реакция 30 минут, доступность 99.9%») с первого дня работы над сервером, который вы ещё не успели изучить. Обещать быструю и качественную реакцию на систему, архитектуру которой вы видели последние несколько часов, — риск не для заказчика, а в первую очередь для вас: вы либо не уложитесь в срок, либо уложитесь ценой поспешного и рискованного решения.

Более честная и рабочая модель — двухступенчатый SLA:

• Первые 5–10 рабочих дней — переходный режим. Время реакции на инциденты остаётся быстрым (например, признать инцидент и начать разбор в течение часа), но время устранения — с оговоркой «может потребовать больше времени, чем в штатном режиме, пока идёт освоение системы». Это не снижает ответственность, а честно называет реальность: разбираться в чужой конфигурации на ходу, во время инцидента, дольше, чем чинить то, что вы настраивали сами.
• После переходного периода — целевой SLA, зафиксированный в договоре, который вы уже можете обещать осознанно, потому что успели пройти полный аудит.

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

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