Проект закрыли, а данные остались: кому они теперь принадлежат

MAATRIX

Проект закрыли месяц назад, команду расформировали, тикет в трекере закрыт статусом «done». А на сервере как стояла база на 40 ГБ, так и стоит — с рабочими учётками, действующими токенами API и правами на чтение у половины бывшей команды. Никто не принимал решения удалить или сохранить эти данные — просто в момент закрытия проекта об этом вопросе никто не подумал. Дальше разберём, почему так происходит почти всегда, и какой явный шаг нужно добавить в процесс закрытия любого проекта, чтобы данные не оставались «ничьими».

Анатомия «ничьих» данных: как это происходит на практике

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

Формально у данных есть владелец — компания. Фактически у них нет ответственного — человека или команды, которая мониторит место на диске, следит за истечением TLS-сертификата перед базой, помнит, что в дампах лежат персональные данные пилота, и знает пароль от S3-бакета с логами. Суть проблемы не в том, что данные потеряны, а в том, что никто не может ответить на вопрос «что мы вообще храним и зачем» без археологических раскопок в старых чатах и коммитах.

Типичные находки при таких раскопках:

• База данных закрытого MVP с реальными email и телефонами первых 200 пользователей — GDPR/152-ФЗ риск, который никто не считал активным.
• Бакет с выгрузками аналитики за два года — платится каждый месяц, но отчёты из него никто не открывал с момента закрытия.
• Сервисный аккаунт с правами записи в продовую CRM — остался «на всякий случай», потому что удалять страшно, а зачем нужен — уже никто не помнит.
• Дамп базы на ноутбуке уволившегося разработчика — потому что «на сервере не хватало места, я сохранил локально».

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

Почему это риск, а не безобидная пауза

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

Юридический риск. Если в данных есть персональные данные, платёжная информация или что-то регулируемое (медицинские записи, данные несовершеннолетних), то обязанности по 152-ФЗ, GDPR или отраслевым нормам не исчезают вместе с закрытием проекта. Обязанность обеспечивать сохранность и ограничивать доступ действует, пока данные физически существуют — независимо от того, работает продукт или нет. Утечка из давно забытой базы разбирается точно так же, как утечка из боевой системы.

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

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

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

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

Обязательный этап закрытия проекта: явное решение о данных

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

Это решение всегда сводится к одному из трёх вариантов:

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

Ключевое слово везде — «явно». Молчаливое «ну наверное само рассосётся» вариантом не является. Пока решение не принято и не зафиксировано, проект формально не закрыт — он просто перестал получать внимание, что гораздо хуже, чем открытый статус с понятным планом.

Три варианта и критерии выбора между ними

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

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

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

Как это делается технически: архивация, удаление, передача ответственности

Три решения — три разных набора технических действий. Ниже — рабочий минимум для каждого.

Архивация

Цель — снять данные с прод-инфраструктуры, но сохранить возможность их поднять и прочитать через год или три.

# 1. Снимок базы с метаданными о времени и версии схемы
pg_dump -Fc mydb_prod > /archive/staging/mydb_prod_2026-08-29.dump

# 2. Файлы проекта и конфиги (без секретов в открытом виде)
tar -czf /archive/staging/project-files_2026-08-29.tar.gz \
  /srv/project/uploads /srv/project/config

# 3. Шифрование архива перед долгим хранением
gpg --symmetric --cipher-algo AES256 \
  /archive/staging/mydb_prod_2026-08-29.dump.gz

# 4. Перенос в холодное хранилище (объектное хранилище с классом archive/glacier)
rclone copy /archive/staging/ remote:cold-archive/project-name/ --progress

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

Минимальный набор в README архива:

# Проект: имя-проекта
Дата закрытия: 2026-08-29
Причина закрытия: продукт не вышел на окупаемость
Ответственный за решение: ФИО, роль
Содержимое: дамп PostgreSQL 16, файлы загрузок пользователей
Срок хранения: до 2029-08-29 (юр. требование по договорам)
Как восстановить: pg_restore -d newdb mydb_prod_2026-08-29.dump
Пароль от архива: хранится в Vault, путь secret/archive/project-name
Содержит ПДн: да, email и телефоны ~2000 пользователей

После архивации — обязательно снести исходные ресурсы: остановить и удалить контейнеры/VM, отозвать DNS-записи, аннулировать TLS-сертификаты, удалить сервисные учётки и API-ключи. Архив без этого шага не снимает риск — вы просто продублировали данные, оставив исходную копию активной и уязвимой.

Удаление

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

# Удаление самой базы
psql -c "DROP DATABASE mydb_prod;"

# Поиск и удаление снапшотов/бэкапов, которые дублируют эти данные
aws s3 rm s3://backups-bucket/project-name/ --recursive

# Ротация бэкапов: убедиться, что старые полные копии с этими данными
# тоже выйдут из хранения по расписанию, а не будут жить бессрочно

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

Назначение нового ответственного

Если данные должны остаться активными, назначение ответственного — это не устная договорённость в переписке, а конкретные технические изменения:

• Владелец облачного аккаунта/проекта (billing owner, IAM root) переоформляется на нового ответственного.
• Права доступа к базе, серверу и секретам пересматриваются заново — старая команда получает revoke, новая — explicit grant по минимально необходимому принципу.
• В системе мониторинга и алертинга меняется контакт, куда уходят уведомления о проблемах с этим сервисом.
• В любом внутреннем реестре систем (CMDB, вики, таблица в Notion — что у вас используется) обновляется запись «ответственный».

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

Как встроить это в процесс, чтобы не повторялось

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

Практические механизмы, которые реально приживаются:

• Чек-лист закрытия проекта как часть оффбординга проекта, а не отдельная инициатива. Пункт «принято решение о судьбе данных: архив / удаление / передача, ответственный указан» — обязательная строка рядом с «отключены доступы» и «закрыт биллинг».
• Дата-триггер, а не память людей. При архивации сразу ставится календарное напоминание на дату пересмотра (обычно через 1-3 года — в зависимости от юридического срока хранения), а не расчёт на то, что кто-то вспомнит.
• Единый реестр «что у нас есть». Даже простая таблица с колонками «сервис / статус (активен, заморожен, архив, к удалению) / ответственный / дата последнего пересмотра» закрывает 80% проблемы — без реестра невозможно узнать, что вообще нужно закрыть.
• Владелец процесса, а не только владелец данных. Кто-то на уровне DevOps/инфраструктуры должен раз в квартал сверять список активных проектов со списком активных серверов и баз — расхождения и есть кандидаты на разбор.

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

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