Курьер сменил статус — его карточка осталась привязана к мёртвому профилю. Научили систему находить такие сама

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

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

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

Результат первого прогона: 1724 карточки в базе. У 163 из них профиль оказался неактивным при живом совпадении по фамилии, имени и телефону — то есть курьер работает, а его карточка смотрит в пустоту. У 138 совпадения не нашлось вовсе — это те, кто действительно ушёл, их трогать не нужно. Остались 3 карточки, где по имени и фамилии нашлось больше одного активного профиля — тут автоматика не должна решать за человека, слишком высока цена ошибки.

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

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

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

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