Сложность в том, что сайт при этом продолжает работать, и первые недели уходят на ожидание. Ниже — пять возражений, за которыми это ожидание обычно прячется, и что на каждое из них стоит ответить. Порядок — от самого дорогого.
«Подожду ещё немного — вдруг вернётся»
Ждать можно, но ожидание не бесплатное, и счётчик у него чужой. Сроки в этой истории задаёт не подрядчик, а регистратор домена, хостинг и удостоверяющий центр: домен продлевается по расписанию, хостинг списывает за период, сертификат выпущен на срок. Всё это, скорее всего, оплачивалось с его карты и приходило на его почту. Когда оплаченный период закончится, сайт ляжет не потому, что человек исчез, а потому, что никто не заплатил.
Дальше начинается разница между неудобством и потерей. Освободившийся домен возвращается по отдельной процедуре и в ограниченное окно, а данные на неоплаченном хостинге хранятся не бесконечно. Поэтому правильный ответ на это возражение звучит не «не жди», а «жди сколько угодно, но опись доступов начни сегодня»: она не мешает подрядчику вернуться и обесценивает его исчезновение.
«У меня на руках всё равно ничего нет»
Обычно есть заметно больше, чем кажется, просто это не собрано в одном месте. Стоит пройти по сервисам и выписать, что известно про каждый: кто владелец, на какую почту зарегистрирован, с какой карты оплачивался, есть ли у вас платёжные документы. Даже если всё оформлено на подрядчика, у сервисов есть процедуры восстановления, а переписка и платежи — аргумент для их поддержки.
| Где искать | Что это даёт | Почему срочно |
|---|---|---|
| Регистратор домена | Кто администратор, как перевести домен на компанию | Продление идёт по расписанию, а не по договорённости |
| Хостинг или облако | Файлы проекта, база данных, настройки | После неоплаты данные хранят ограниченное время |
| Рабочая почта и корпоративные аккаунты | На них приходит восстановление паролей | Через них возвращается почти всё остальное |
| Репозиторий с кодом | Исходники и история изменений | Личный аккаунт исполнителя может закрыться вместе с ним |
| Договор, счета, переписка | Подтверждение, кто заказчик и за что заплачено | Нужны и для поддержки сервисов, и для юриста |
Отдельно выпишите то, что оплачивается ежемесячно и незаметно: почтовые рассылки, платные ключи к внешним сервисам, аналитика, эквайринг. Это места, где проект чаще всего ломается тихо — без падения сайта, но с исчезновением какой-нибудь одной функции.
«Он не станет вредить, мы нормально общались»
Скорее всего, так и есть, но риск здесь создаёт не умысел. Открытый доступ к боевой базе, к почте, к админке остаётся открытым независимо от того, как вы расстались, и живёт он ровно столько, сколько живёт ноутбук исполнителя, его почтовый ящик и его пароли. Ключ, о котором никто не помнит, утекает вместе с чужой учётной записью — без всякого злого умысла. Поэтому доступ закрывается по факту прекращения работы, а не по факту конфликта.
Это тот же принцип, по которому закрывают доступы уходящему сотруднику, и грабли там ровно те же — подробнее в статье утечка данных перед увольнением. Если есть основания думать, что клиентская база уже могла уйти на сторону, разбираться нужно не догадками: как это устанавливается технически — в материале как отследить, кто слил базу данных компании.
«Новый подрядчик всё равно скажет, что надо переписывать»
Иногда это правда, а иногда — самый удобный ответ, потому что писать с нуля проще, чем разбираться в чужом коде. Отличить одно от другого можно, и для этого не нужно быть программистом: попросите письменный вывод с основаниями, а не оценку на словах. Проверяемых оснований немного, и они звучат конкретно.
- •Есть ли исходники и собирается ли проект из них на чистой машине,
- •Разворачивается ли он заново по описанию, или запуск держится на одном настроенном сервере,
- •Есть ли структура базы данных и способ её воспроизвести,
- •На чём всё написано и поддерживаются ли эти версии до сих пор,
- •Что именно мешает продолжать разработку — с указанием мест, а не общего «там всё плохо».
Переписывание честно обосновано, когда исходников нет или они не собираются, когда развернуть проект заново невозможно, когда используемые версии давно не поддерживаются. Оно не обосновано тем, что читать чужой код неприятно. Разумная середина встречается чаще крайностей: рабочую систему оставляют на месте и меняют по частям, начиная с того куска, который мешает больше всего.
Если пропавший подрядчик оставил не сайт, а прошивку в железе, разбор устроен иначе: там идут от дампа памяти устройства к разбору бинарника и новому коду. Что в этом случае вообще поддаётся восстановлению и где работа обычно останавливается — как восстанавливают прошивку без исходников.
«Такое случается один раз, со следующим будет иначе»
Пропасть может кто угодно — вопрос только в том, чем это для вас закончится. Разница между «неприятно» и «катастрофа» задаётся не порядочностью исполнителя, а тем, на кого оформлены аккаунты. Проверьте перед следующим стартом:
- •Домен, хостинг и облачные сервисы зарегистрированы на компанию, исполнитель приглашён в них, а не владеет ими,
- •Код лежит в вашем репозитории, доступ выдаётся и отзывается вами,
- •У каждого исполнителя своя учётная запись — общих паролей «на всех» нет,
- •Ключи к боевой базе и внешним сервисам хранятся у вас, а не в личных заметках подрядчика,
- •Развёртывание описано так, чтобы новый человек поднял проект по инструкции,
- •Передача идёт по ходу работы, а не «в конце проекта».
Если по условиям работы исходники всё-таки остаются у исполнителя, на этот случай есть отдельная процедура — эскроу: копию кода передают на хранение третьей стороне и заранее оговаривают, при каких событиях её выдадут заказчику. Чем это отличается от депонирования ради авторства — депонирование исходного кода.
Это не про недоверие к конкретному человеку. Это про то, чтобы уход любого исполнителя — включая нас — был обычным рабочим событием, а не аварией. Мы придерживаемся того же порядка: права, исходники и доступы остаются у заказчика, и что это значит на практике — в разделе что мы делаем и что остаётся у вас. Как защитить клиентскую базу от выноса ещё до того, как кто-то исчез, разобрано отдельно — защита клиентской базы от копирования.
С чего начать сегодня
Порядок действий короткий, и первые четыре шага не требуют решения о судьбе проекта: они не пропадут зря, какое бы решение вы потом ни приняли.
| Шаг | Что сделать | Что это закрывает |
|---|---|---|
| 1. Опись | выписать сервисы проекта, а по каждому — владельца и плательщика | пока её нет, непонятно, что именно может пропасть |
| 2. Владение | перевести оплату и права на компанию, начиная с домена и хостинга | останавливает чужой счётчик, который идёт без вас |
| 3. Доступы | отозвать чужие учётные записи и ключи, сменить общие пароли | закрывает вход, который живёт и после расставания |
| 4. Копия | снять файлы, базу и настройки со всего, до чего дотянулись | даёт запас времени, если данные пропадут |
| 5. Решение | разговор о том, продолжать на существующем коде или заменять | решается на фактах, а не на догадках |
Если нужен взгляд со стороны на то, что осталось от проекта, и честный ответ, продолжать или заменять, — мы готовы взяться и посмотреть.
Частые вопросы
Подрядчик молчит неделю — это уже «пропал»?
Порог задаётся не сроком молчания, а тем, что стоит на счётчике: оплаченный период хостинга, срок продления домена, действующие ключи доступа. Пока подрядчик молчит, эти сроки продолжают идти. Опись доступов имеет смысл начинать до того, как молчание станет окончательным, — она ничего не портит, даже если человек завтра ответит.
Подрядчик не отдаёт исходный код — что делать?
Работать по двум направлениям сразу. Техническое: посмотреть, что можно снять с рабочего сервера — файлы, базу данных, конфигурацию, настройки развёртывания. Правовое: собрать переписку, техническое задание и платёжные документы, они подтверждают, кто заказчик и за что заплачено. На практике восстановление с боевого сервера часто идёт быстрее, чем спор о передаче.
Как отозвать доступы, если я не знаю, какие у него были?
Идти от систем, а не от людей. Выпишите все сервисы проекта — регистратор, хостинг, база данных, репозиторий, почта, платёжные и рекламные кабинеты — и в каждом откройте список пользователей, ключей и токенов. Всё, что не опознано как ваше, отзывается; общие пароли меняются, ключи выпускаются заново.
Можно ли продолжить проект без исходного кода?
Иногда да. Если это сайт на распространённой системе управления, значительная часть настроек живёт в базе и в админке, и работу можно продолжить с рабочего сервера. Если это собственная разработка со сборкой, без исходников продолжение почти всегда обходится дороже, чем аккуратная замена по частям.
Как понять, что следующий подрядчик не пропадёт так же?
Проверять доступом, а не обещанием. До старта попросите оформить домен, хостинг и репозиторий на вашу компанию и войдите в каждый сам, своим логином, — а не «мы вам покажем экран». Дальше повторяйте ту же проверку по ходу работы: появился сервис, вход в который есть только у исполнителя, — это будущая точка потери, и закрывать её дешевле сразу. И один раз попросите развернуть проект заново по написанной инструкции: недокументированную сборку это вскрывает лучше любых заверений.