Fortech 
Тендеры и лиды
Информация
Это случается чаще, чем принято признавать. Разработчик уходит – иногда со скандалом, иногда тихо, «по собственному желанию» – и оставляет после себя работающий сайт, который никто кроме него не понимает. Или не совсем работающий. Или вообще не работающий, потому что домен, хостинг и все пароли были у него на личной почте.
Мы разберем по шагам – в каком порядке и что делать, если разработчик ушёл по-английски.
Первое, что нужно понять: у вас есть. Составьте список всего, к чему у вас есть доступ прямо сейчас:
Проверьте почту – домен и хостинг часто регистрируют на корпоративный адрес, но не всегда. Попробуйте восстановить доступ через «Забыл пароль» на reg.ru, nic.ru, timeweb, beget – где вы вообще платили за хостинг? Посмотрите в бухгалтерии, кому шли платежи.
Найдите договор – если разработчик работал официально, в договоре должны быть прописаны права на код, доменное имя и обязанность передать доступы. Это ваш главный инструмент давления в случае конфликта.
Посмотрите DNS – через whois.domaintools.com или просто через «Яндекс.Вебмастер» можно увидеть, на каком хостинге находится сайт. Это уже что-то.
Проверьте репозиторий – если разработчик делал коммиты на GitHub/GitLab, у вас мог остаться доступ к репозиторию организации. Заходите, скачивайте всё что есть.
Если хостинг оплачивался с карты компании –звоните в службу поддержки хостера с документами. Большинство российских хостеров (Beget, Timeweb, REG.RU) готовы передать доступ юридическому владельцу домена при наличии подтверждающих документов: выписки из ЕГРЮЛ, копии договора, иногда достаточно письма на фирменном бланке.
Если домен зарегистрирован на физлицо (то есть на разработчика лично) – это хуже. Формально это его имущество. Но есть варианты:
Во-первых, можно попробовать договориться. Большинство людей не хотят проблем и передадут домен за небольшую компенсацию или просто так, если их попросить нормально.
Во-вторых, если договориться не получается – готовьтесь к юристу и претензионному письму. Если домен совпадает с вашим товарным знаком, у вас хорошие шансы в споре.
В-третьих, в крайнем случае – зарегистрируйте новый домен и переезжайте. Больно, но иногда проще, чем судиться.
Код получили – хорошо. Теперь вопрос: а что с ним делать?
Новый разработчик или команда должны будут провести аудит. Это несколько часов или дней работы в зависимости от размера проекта. Что они ищут:
Понятна ли структура проекта? Есть ли документация хоть в каком-то виде?
Нет ли жёстко прописанных паролей, ключей API прямо в коде?
Работает ли локально? Есть ли зависимости, которые уже не поддерживаются?
Есть ли «таймбомбы» – фрагменты, которые могут сломаться при обновлении или в определённую дату?
Да, такое бывает. Редко, но бывает. Особенно если расставались плохо.
Это надо сделать сразу, как только получите доступ. Список минимум:
Пароль от панели управления хостингом
Пароль от базы данных
Ключи API всех сервисов (платёжные системы, СМС-шлюзы, аналитика)
Пароль от почты, привязанной к сайту
Доступы от CMS (Bitrix, WordPress, и т.д.) – все пользователи, созданные «под разработчика», удалить
Если использовался CI/CD – ротируем токены
Это не паранойя. Это гигиена.
Вот здесь многие делают ошибку: нанимают нового разработчика и возвращаются к той же схеме. Один человек, всё у него, всё в его голове.
Есть несколько вещей, которые стоит сделать системно:
Документируйте всё. Хотя бы простой файл README с описанием, что где лежит, какие сервисы используются, где хранятся доступы. Это займёт час раз в квартал и сэкономит недели нервов при смене подрядчика.
Храните доступы в компании. Используйте менеджер паролей с корпоративным аккаунтом. Разработчик работает через него – пришёл, поработал, ушёл, а пароли остались у вас.
Требуйте репозиторий под аккаунтом организации. Не «на гитхабе разработчика», а на вашем GitHub Organizations. Это просто и бесплатно.
Прописывайте в договоре. Передача исходного кода, документации и доступов – обязательный пункт. Лучше с неустойкой за непередачу.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13507 тендеров
проведено за восемь лет работы нашего сайта.
После истории с внезапно пропавшим разработчиком многие наши клиенты приходят к простой мысли: нам не нужен человек, которому надо платить полную зарплату за то, что он три недели из четырёх сидит без задач. Нам нужна команда, которая реагирует когда надо.
Это именно то, что решает техподдержка по подписке. Фиксированная ежемесячная оплата – и у вас есть команда, которая следит за сайтом, оперативно решает проблемы, делает мелкие доработки и не исчезает в ночь перед распродажей.
Мы работаем по такой схеме: клиент платит за пакет часов в месяц, а мы берём на себя мониторинг, обновления, баги и плановые задачи. Если что-то сломалось – реагируем в течение часа в рабочее время. Если горит – быстрее.
Главное отличие от штатного разработчика: у вас нет зависимости от одного человека. Есть команда, есть документация, есть процессы. Заболел один – его закроет другой. Ушёл – никто не забрал с собой базу знаний.
Ситуация с пропавшим разработчиком неприятная, но не катастрофическая – если действовать спокойно и последовательно. Восстановить доступы можно почти всегда. Разобраться в коде – тоже.
Главное, что стоит вынести: один разработчик, у которого всё, – это риск. Процессы, документация и правильно выстроенные отношения с подрядчиком – это защита от повторения.
Если вы сейчас находитесь в такой ситуации или хотите выстроить нормальную схему поддержки – напишите нам. Разберёмся.
