ITKatya: культурные паттерны в IT

Самый отпускной пост!

Эта самая девочка, которая разбила чашку, так как научилась посылать все и уходить в отпуск теперь хочет научить менять все в темпе сига-сига!

Спасибо Оле за следующую чашку, которая ко мне едет!

А если хотите такую же-го к Оле! (Это не реклама, это то что люблю и использую сама) и чашка прекрасно моется в посудомойке! 😍

Что такое анти-дубль?

Есть поиск дублей. А есть менее очевидный, но не менее важный паттерн — поиск анти-дублей.

Это когда система должна понять не «кто на кого похож»,
а наоборот — что это точно не тот же объект!

Представьте: У вас уже есть пользователь. И внезапно на него начинают «прилетать» данные другого человека:
— прилетают ПД, которые полностью не равны имеющимся у вас атрибутам
— приходит документ с другим годом рождения
— появляется транзакция с параметрами, которые не пересекаются с историей и сценариями!

Если система настроена только на поиск похожести, она может сказать: Ну, не похоже. Ну, Ok. Обновим. Продолжим жить.

А надо наоборот — включить режим: это не дубль, это конфликт!

В KYC-домене есть атрибут, который часто недооценивают:
дата рождения.
Имя может не совпадать.
Фамилия может меняться.
Транслитерация может «гулять».
Адрес — можно переехать.

Но дата рождения — это якорь идентичности!

Да, бывают ошибки ввода.
Да, бывают разные форматы.
Но если дата рождения начинает «плавать» — это не просто НЕ дубль. Это сигнал, что идентичность может быть подменена.

Обычно мы строим системы, которые отвечают на вопрос:
кто похож на кого?

Но в KYC и финтехе не менее важен второй вопрос:
кто не может быть тем же самым человеком?

Так как допустить чужие данные на действие с основным объектом системы, это:
— фрод
— нарушение протоколов безопасности
— сыгранные риски (от финансовых до репутационных)

А главное, это разные алгоритмы!

Поиск дублей — про сходство. Поиск анти-дублей — про противоречия.

И если система умеет только первое, она либо склеит лишнее,
либо пропустит подмену.

💬 А знаете кейсы, когда гарантированно анти-дубли «идут лесом» и по негласному правилу, всем Оk, что один и тот же человек становится разными личностями!

Функции-мутанты: рассмотрим на практике

Теория была вот 👉 тут

Продолжим «раскручивать» дубликаты!

KYC: поиск + запрет регистрации нового аккаунта

Нашли совпадение по имени, дате рождения и частично документу → запретили создание нового аккаунта или подклеили аккаунты друг к другу.

При запрете:
— продуктовое ограничение пользователей: я не могу на tel_1 иметь один кабинет под один вид деятельности, а на tel_2 - под другой
— версии поиска будут меняться, значит будут те, кого «незаконно» не пропустили или кого «зря» пропустили

При склеивании:
— к новому пользователю «переезжают» старые ограничения
— флаги и доступы наследуются
— история операций смешивается

Везде:
1️⃣ В аудите невозможно понять, где была ошибка.
2️⃣ Система «оптимизировала», но потеряла управляемость.

Платежи: поиск + дедупликация транзакций

Похожие платежи → «это дубликат» → один отменяем.

А если:
— клиент реально платит дважды (представьте, как бесит, когда терминал продает ток по одному билетику, а у вас одна карточка с собой (Apple pay не работает в стране), а банк отбивает как дубликат)
— автосписание и ручной платеж совпали
— разные мерчанты с похожими атрибутами

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

Уползем с уровня процесса на уровень реализации.
Для примера про KYC удобно запрятать поиск дубликатов на уровень Conplience платформы и результаты поиска: с кем и на сколько совпало и по каким параметрам и по какой версии алгоритма хранить в одной табличке. Но, если дубликаты понадобятся для внешнего к платформе сервиса — выдать API, с методом который ищет, по переданным снаружи данным, но не сохраняет результат (пример, когда надо: у вас есть мерчант, который хочет понят объем пакета, собираемого с пользователя по одному документу и номеру телефона).

💬 Стало ли на примерах понятнее?

«Возьму Найду и не отдам…»

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

Давайте продолжим с дубликатами. Что же такое поиск дубликатов?

Поиск — это действия ищущего, розыски кого-чего-н. Он должен отвечать только на один вопрос: найдено/не найдено и с какой вероятностью это именно то, что искали?
ВСЕ!!!

Но в реальных системах к поиску незаметно приклеиваются другие глаголы:
— нашли → заблокировали
— нашли → запретили создание
— нашли → склеили
— нашли → переписали данные

И в этот момент это уже не поиск, а помесь крокодила 🐊 с курицей 🐔!

И вроде бы, «Что в этом такого?»

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

❔Как проверить, что функция содержит больше одного глагола?

Задайте себе несколько вопросов:
1️⃣ Можно ли изменить политику, не трогая алгоритм?
Если нет — глаголы смешаны.
2️⃣ Возвращает ли функция только данные или уже принимает решение?
Правильный поиск возвращает кандидатов и score.
Если он возвращает isBlocked = true — это уже не только поиск.
3️⃣ Есть ли внутри side-effects?
Запись статуса, блокировка, изменение флага — это другой глагол.
4️⃣ Можно ли переиспользовать функцию в другом сценарии?
Если для аналитики нужно «выключать половину логики» — функция перегружена.
5️⃣ Можно ли назвать еe одним словом (и не покривить душой)?
Если имя звучит как findAndBlockDuplicateUser — ответ очевиден.

Разделяйте:
👯‍♀️Match — кто на кого похож
👩‍⚖️ Decision — что с этим делать
☝️ Action — конкретное действие

Поиск дубликатов — это не «найти и не отдать».
Это «найти — и только потом выбрать правильный глагол».

Ну, а если вы соскучились по цитатам, то вот Цветаева:

«Возьму и не отдам…
Отдам и вновь,
В горсть соберу, миг подержу — и брошу…
— Хорош словарь?»

💬 А у вас в системах есть мутировавшие глаголы?!

PS если не понятно, завтра подробнее с примерами!

Когда знания дали шоры…

Я люблю справочники. И именно поэтому я продолбалась.

Много лет назад у меня была задача нормализации:
— в номерах машин буквы надо было менять по схожести написания
— в документах — по правилам транслитерации

Так в системе появились по две мапы на язык:
1. визуальная
2. фонетическая

Колесо было изобретено. Красивое. МОЕ!!!

В этом году — снова нормализация и поиск дублей. Я уже мысленно рисую по две таблицы на каждый язык плюс нормальный транслитерационный словарь. И думаю: да ну его. Загоняем все в Unicode и живем без нормализации букв вообще. Для MVP сойдет.

Параллельно обсуждаю это с ChatGPT. Но сама же ставлю рамки: «ищем в ISO, IEEE и прочих серьезных местах».
И сама же себя ограничиваю запросом!

Через две недели приходит разработчик. Без любви к справочникам. Без прошлых травм нормализации.
И приносит решение на базе стандарта гражданской авиации.

Знакомьтесь: ICAO Doc 9303

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

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

То есть готовый эталон нормализации идентификаторов.

И красота решения в том, что нам не нужен API (который выдается ток государствам). Достаточно один раз затащить к себе таблицы преобразований и жить по единому правилу.
Не важно, кто снаружи идеально соблюдает стандарт — важно, что внутри системы у нас единообразие и точка сверки.

Есть ли исключения? Конечно. Реформы языков.
Но посмотрите на динамику.
🇪🇸 В 2010 году Испания убрала «ch» и «ll» из списка отдельных букв алфавита — они стали просто диграфами.
🇰🇿 В 2021 Казахстан, пересобирая латинский алфавит, наоборот уточнял и добавлял диакритические варианты для передачи национальных звуков.

Добавления случаются — но обычно в рамках крупных реформ или смены графики.
В обычной жизни языки чаще упрощают.

А такие редкие кейсы спокойно выносятся в исключения:
выпустили новую версию правил → пересчитали базу → живем дальше.

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

Говорят что в выходные нельзя выкладывать умный контент. А так как я в отпуске и у меня все посты счас про нормализацию и тп…

А мозг не способен написать что-то простое, то вот вам секция «в мире животных»

Или звери за 2 дня путешествия по Эмиратам.

Обещаю даже обзор дать на то, как оно нам поездка в круиз. И плюсы/минусы для интровертных айтишников.

Когда болит ЧиЧиЧиПи!

Пока в отпуске, попробую вернуться к более регулярным постам.

Помню монолог Михаила Задорного про ЧиЧиЧиПи. Если вы не столь стары, чтобы помнить его, вот видео.

В прошлом посте мы говорили о том, что 1, 2, 4, 8 — это не про степень двойки, а про степень доверия к совпадению.

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

Поэтому если вы полезли в поиск,
заниматься им без нормализации — грешно.

Нормализация — это приведение данных к виду, в котором их можно честно сравнивать.

Чтобы:
AB-123 45
ab12345
АВ 123-45
вдруг оказались одним и тем же значением.

В поиске обычно нормализуют:
– цифры
– буквы
– регистр
– алфавиты
– форматы и разделители

И вот тут ЧиЧиЧиПи начинает болеть.

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

Получается пустая строка.

А дальше — сюрприз:
две пустые строки могут совпадать всегда или никогда — зависит от реализации.

Дальше — буквы.

Upper case или lower case?
Кажется, что все просто, но Unicode умеет удивлять.
То, что безопасно для кодов, плохо подходит для текста — и наоборот.

И, конечно, транслитерация.

Она не одна.

ФИО транслитерируются по правилам языка.
А вот номера еще и по внешнему виду символов.

Поэтому:
Р → P
С → C
Х → X
и получается PCX, а не «RSH».
Это уже правила визуального соответствия.


Отсюда вывод простой:
• разные данные → разная нормализация
• один универсальный алгоритм не работает
• нормализация — это часть бизнес-логики, а не предобработка

А в следующем посту расскажу, как моя любовь к словарям меня же и покарала!

@t_mobile_russia

Ты - победил!!! 🏅

АМ16 уже 7го февраля!

Программа Аналитического марафона 16 полностью готова, все спикеры уже на лендинге!

Внутри — три прикладных блока:
🔹 Архитектура и интеграция
Гибридные архитектуры, асинхронная интеграция, будущее ИТ-архитектуры в эпоху ИИ.
🔹 API, безопасность и данные, REST от базы до фишек, безопасность API (Basic Auth → OAuth 2.0, live-демо), ETL / ELT / CDC / Stream — без путаницы.
🔹 Инструменты и практика
Как выкатить сервис без команды, no/low-code и AI-агенты, API глазами аналитика, A/B-платформы и микросервисы.

🔥 Спикеры — огонь
🔥 Темы — практические
🔥 Формат — без воды

_ _ _

🎂 И еще повод для радости
У меня ДР 🎉
И у организатора Analyst Marathon — Максима тоже 🎉

По этому поводу разыгрываем билет на конференцию 🎁

Как участвовать:
— напиши комментарий под постом
— получи номерок

⏰ Розыгрыш до вечера 5 февраля

Если не хочешь ждать — скидка: IT_Katia_AM16
🔗 Билеты по ссылке

❤️ Спикеры — крутейшие, люблю их сильно

А я побежала дорабатывать и улетать в отпуск! Так что "номерки" будут прилетать с задержкой!

1, 2, 4, 8 — когда не про степень двойки

Когда показываешь последовательность: 1, 2, 4, 8
почти все говорят: «Ну понятно, степень двойки».

И да. Но это только половина ответа!

Потому что на практике это не столько про количество сложенных двоек, сколько способ думать про вес решений.

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

Например, мы ищем документ по номеру.
И получаем:
– документ, удостоверяющий личность
– совпадает номер
– совпадает страна

Но дальше начинаются нюансы.

Это может быть:
– паспорт гражданина Российской Федерации
– а может быть паспорт моряка

Формально оба — документы, удостоверяющие личность. Но это разные типы документов. И обрабатывать их как один и тот же кейс — ошибка.

А теперь другая ситуация.

Номер совпал, но:
– в одном случае его ввели как паспорт РФ
– в другом — как загранпаспорт
– в третьем — как еще какой-то тип документа (например страховой номер)

Это может быть:
– ошибка ввода
– копипаст
– пересечение номеров
– или реально один и тот же документ, заведенный несколько раз в «неправильные дырки»!

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

Каждое число — отдельный признак. Каждый признак можно сложить с другим. И результат никогда не будет двусмысленным.

Например (для поиска дубликатов по номеру документа):
1 — мы нашли совпадение внутри одной страны и одного документа
2 — совпадение внутри страны, но между разными документами одного вида
4 — совпадение между странами по документу
8 — совпали ключевые персональные данные с несколькими баллами по Левенштейну.

В итоге мы получаем не «да / нет», а:
— совпадение на 6 баллов
— или на 9
— или на 15
И сразу понятно — почему именно столько!

Еще одно удобство, можно в запросе откинуть вариант или варианты от определенного уровня, например: дубликаты пользователей с весом не более 6!

А вы "такое" использовали на практике?

PS Если не догадались - я тут чуток с поиском развлекаюсь. Вам еще про алгоритмы рассказывать или это "базовый минимум", который всем ясен/понятен?