Как мы берём сайт на поддержку: аудит, доступы, регламент

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

Шаг 1. Доступы и резервные копии

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

Шаг 2. Технический аудит

Дальше смотрим на состояние проекта:

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

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

Шаг 3. Регламент работы

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

Что получает заказчик

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