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