Как принять чужой сайт на техническую поддержку: аудит, доступы и SLA

Что принимают вместе с сайтом

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

В текущей коммерческой выдаче сам аудит перед поддержкой уже стал отдельным обещанием. Amplify Lab пишет о проверке кода, инфраструктуры и доступов до договора, а Brusnica Development — об аудите кода, безопасности, мониторинга и резервных копий чужого проекта. Это описания услуг самих компаний, а не независимое подтверждение качества. Их сходство показывает реальную границу: нельзя отвечать за систему, которую ещё невозможно воспроизвести и восстановить.

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

Инвентаризация начинается с бизнеса, а не с репозитория

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

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

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

Сначала чтение, копия и воспроизводимая сборка

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

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

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

Аудит должен закончиться очередью решений

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

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

1. Критичные риски, которые уже могут остановить сайт, потерять данные или открыть лишний доступ.
2. Условия безопасной эксплуатации: мониторинг, проверяемые копии, управляемые секреты и аварийный канал.
3. Дефекты, влияющие на заявки, оплату, поиск и работу сотрудников, с воспроизводимыми шагами.
4. Устаревшие зависимости и архитектурные ограничения, которые мешают следующим изменениям, но не требуют ночного переписывания.
5. Список неизвестного: недостающие права, документация, владельцы сервисов и участки, которые нельзя подтвердить.
6. План первых тридцати дней с ответственными, способом проверки и возможностью отката для каждого изменения.

SLA начинается с определения инцидента

Публичные предложения поддержки показывают разные модели: у Adict пакеты связаны с платформой, мониторингом, резервными копиями и временем реакции, а Intervolga указывает минимальный объём часов и отдельный аудит. Цена сама по себе не раскрывает покрытие. Нужно сравнивать часы дежурства, критичность, первый ответ, цель восстановления, доступный резерв команды и перечень работ, которые считаются развитием.

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

В прайсе pommeDeTerre поддержка начинается от 30 000 ₽ в месяц, стандартный формат — от 60 000 ₽, расширенный SLA и постоянный резерв команды — от 120 000 ₽. Эти уровни можно обсуждать после аудита, потому что неизвестное состояние меняет и объём первых работ, и реалистичное время восстановления. Передача закончена не при получении паролей, а когда стороны подписали карту системы, проверили копию и релиз, назначили владельцев и одинаково понимают, что произойдёт при следующем сбое.