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

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

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

Все мы привыкли к общепринятым инструментам для тестирования. Думаю, список есть у каждого и он постоянно пополняется. Лично мой: Postman, IntelliJ IDEA и DataGrip от JetBrains, ShareX для скриншотов и его величество DevTools. 

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

В М2 большой объём письменной коммуникации с клиентами. Это и ответы на общие вопросы — о компании, процессах подбора и покупки недвижимости, — и обсуждение конкретных деталей запущенных сделок. К примеру, клиенты хотят знать, в каком отделении банка они будут подписывать документы, пришли ли деньги продавцу, прошёл ли объект недвижимости проверки перед продажей.

Работа с вопросами происходит в тикет-системе клиентской поддержки (UseDesk). Для каждого вопроса через любой канал коммуникации (e-mail, мессенджеры, чат на сайте) заводится обращение, и сотрудник экспертной поддержки отвечает на него с определённым SLA. 

Для оптимизации работы с обращениями процесс разделён на 3 линии поддержки. Первая линия отвечает только на вопросы без привязки к продукту и не знает о конкретных сделках. Она обрабатывает порядка 10 000 обращений в месяц. Вторая линия знает о продуктах и отвечает на вопросы по сделкам, таких обращений около 3 000 в месяц. Третья линия — это уже команды продуктов, до них доходят единичные вопросы.

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

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

Кстати, интересно ваше мнение, как бы вы подошли к решению задачи по автоматизации такого бизнес-процесса? Напишите в комменты или личку. 

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

Привет, меня зовут Саша, я Head of mobile в компании «Метр квадратный». Под катом — почему появился этот комплекс и как с ним бороться. Сразу оговорюсь, в статье много моего личного мнения, и будет круто, если в комментах вы поделитесь своим.

— Дима, посмотри, пожалуйста, тикет по саппорту, ЭТО ОЧЕНЬ СРОЧНО!!!

Было время, когда ответы на такого рода сообщения занимали большую часть рабочего времени нашей дежурной смены от команды разработки. К счастью, постепенно ситуацию удалось исправить. 

Подходами, за счет которых это получилось сделать, как раз и хочется поделиться в этой статье. Если у вас, как и у меня, от упоминания технической поддержки начинает дергаться глаз, а необходимость ей заниматься не вызывает ничего, кроме чувства вселенского уныния, добро пожаловать под кат. Серебряной пули не обещаю, но что-то полезное, может, и найдется.

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

Писать, собирать, агрегировать и сохранять логи для последующего анализа важно: это наиболее подробное представление того, как работает система.

Логи можно собирать и отправлять в централизованную систему по-разному, например используя библиотеки в самом приложении или сторонние агенты вроде Filebeat, Fluent Bit, Vector. Есть множество систем хранения вроде Elasticsearch, Loki, Splunk, файлы на диске или объекты в S3.

Мы в М2 тоже занимаемся этим вопросом и постоянно ищем схемы и инструменты, помогающие улучшать централизованную систему логирования. Я, как инженер развития инфраструктуры, непосредственно принимаю в этом участие. В статье хотел бы поговорить об этапе агрегации и поделиться нашими наработками.

Привет, Хабр!  Разрабатывая экосистему для «Метр квадратный», мы со старта проекта планировали большую линейку продуктов. Поэтому подбирали стек, который поможет реализовать максимум идей. В итоге мы пришли к протоколу gRPC.

 В этом материале я расскажу:

— о преимуществах gRPC;

— об особенностях работы с протоколом, и о том, как с ними жить;

— о тех проблемах, с которыми мы столкнулись; 

— и о том, как их решить.

Привет! Меня зовут Максим Гореликов, я Backend Tech Lead в M2. Несколько вещей, которые надо знать об этой статье, прежде чем углубляться в нее:

— эта статья — расшифровка моего доклада на конференции Yandex Scale 2021 с некоторыми доработками;

— данные собирали с разных участников переезда и набрали много интересного, но доклад был в слоте про Yandex Data Platform, поэтому оставили кейсы только на эту тему;

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

События, описанные в статье, происходили в 2020 году, сейчас входим в топ-5 клиентов по объему потребляемых сервисов Yandex.Cloud. Когда переезжали, ещё не все процессы в Yandex.Cloud были хорошо налажены, поэтому расскажу о самых ярких воспоминаниях — проблемах, с которыми столкнулись. Хороших моментов тоже хватало, но проблемы всегда интереснее обсудить.

Привет, Хабр! Меня зовут Андрей Перепелкин. Я руководитель группы бэкенд-разработчиков, вошел в IT более 15 лет назад, 10 лет занимаюсь Java и около 4 плотно работаю с микросервисами. 

В этой статье я расскажу, как:

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

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

— встраиваем микросервисы в инфраструктуру и собираем метрики и логи, не загружая этим разработчиков.