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

Сегодня запусаю розыгрыш бесплатного билета на конференцию Аналитический марафон #17. Тема — прям очень в сердечко: «Технологии и коммуникации в работе системного аналитика» Если коротко — это не про “писать ТЗ”, а про то, как аналитик: — работает с архитектурой — использует AI в задачах — ускоряет процессы и снижает хаос И программа там прям жирная: 🔹 ADR & Agent Skills — как готовить архитектурные решения с помощью LLM 🔹 AI-ассистент на коде компании — live-demo RAG-системы 🔹 Стандартизация API — от хаоса к метрикам 🔹 От промпта к прототипу — проверяем требования до разработки И это не теория, а реальные практики, которые можно забирать и применять. Теперь к самому приятному: 🎁 Разыгрываю 1 бесплатный билет Чтобы поучаствовать — просто напишите в комментариях: «Я хочу» ⏰ Итоги подведу в понедельник Если давно смотрели в сторону таких тем — это прям хороший шанс зайти. (А если не повезет — все равно рекомендую посмотреть программу, она правда клевая, и будет дополнительная скидка, котороую можно применить до подорожания билетиков!!!)

Продолжаем про подделку взаимодействия. Если в прошлый раз мы притворялись, что все синхронно, то теперь наоборот — делаем синхронку на асинхронке. И тут ощущение еще страннее: вроде очередь… но ведет себя как API. Как это выглядит: — X отправляет сообщение в очередь — Y его обрабатывает и ответ возвращается тоже через очередь — X сидит и ждет как ни в чем не бывало И в голове у X:

"я сделал запрос и получил ответ и не финальный. Хотя ни одного HTTP-вызова не было."

Зачем так жить? 1️⃣ Изоляция сервисов Нет прямых вызовов — только брокер. Но бизнесу все равно нужен «запрос → ответ». 2️⃣ Надежность Очереди умеют ретраи и доставку. HTTP — умеет падать. 3️⃣ Контроль нагрузки Очередь — это буфер. Можно не ловить пики лицом. 4️⃣ Саги и процессы Все общается событиями, но отдельные шаги хочется мыслить как вызовы. Что по факту происходит? Мы берем асинхронную инфраструктуру и начинаем использовать ее как синхронную. Немного против природы. Но работает. Почему это больно? — ответ может прийти «когда-нибудь» — correlation id становится вашим лучшим другом — дебаг выглядит как археология сообщений Когда это нормально? — event-driven архитектура — нет прямых соединений — важнее надежность, чем скорость Когда не надо? — если можно просто сделать HTTP-запрос — если важны миллисекунды, а не «дойдёт точно» В итоге картина симметричная: 💃👯‍♀️асинхронка на синхронке — чтобы упростить жизнь клиенту 👯‍♀️💃 синхронка на асинхронке — чтобы выжить внутри системы Мы либо притворяемся, что все просто, либо притворяемся, что все надежно. Иногда — одновременно 😅 Да, такое тоже бывает!

Подделка взаимодействия! Есть два подхода, которые почти всегда вызывают споры: 👯‍♀️💃 синхронка поверх асинхронки 💃👯‍♀️ асинхронка поверх синхронки И каждый раз ощущение странное: то ли тебя обманывают, то ли это нормальная инженерная практика, просто неочевидная. Давайте разберем любимое — асинхронка на синхронке. Как это выглядит на практике: 1️⃣ система X отправляет синхронный запрос 2️⃣ система Y синхронно отвечает: «принял, вот id» 3️⃣ система X: - либо ждет - либо ходит опрашивать статус 4️⃣ когда что-то изменилось — Y шлет webhook Снаружи — синхронный API. По факту — распределенный асинхронный процесс. Когда это нужно 🤖Интеграционные гейты и мерчанты. У вас есть N клиентов, которым нужно: - понимать, что произошло - получать однозначные ответы - не разбираться в очередях и событиях А внутри вы хотите: - строить очередь - ретраить - управлять нагрузкой В итоге вы даете им синхронный контракт, но живете в асинхронной модели. 🤺Саги и каскадирование. Процесс стартует в одном сервисе → уходит в другой → дальше цепочка шагов, ретраев, откатов. Но у первого сервиса: - свои таймауты - свои SLA - необходимость понимать, что произошло Поэтому: - снаружи он делает «синхронный» вызов - внутри запускается асинхронная сага 🤔 Пользовательские сценарии (UI). Есть запрос из: - мобильного приложения - веба И где-то в цепочке появляется прокси-сервис, который: - агрегирует - модифицирует - маршрутизирует Но при этом: - жесткие таймауты - нельзя держать соединение долго - пользователь ждет ответ «сейчас» Решение: - быстро принять запрос - отдать «синхронный» результат - остальное доделать асинхронно ❓Что еще сюда попадает Если посмотреть шире, таких сценариев больше: ⏱️ Долгие внешние интеграции Когда вы ходите во внешние системы с непредсказуемой латентностью и не хотите держать открытое соединение ⛓️‍💥 Нестабильные провайдеры Когда нужны ретраи, фолбэки, каскадирование, но клиенту это показывать нельзя 🎛️ Регуляторные процессы Когда важно зафиксировать факт «запрос принят» даже если обработка займет часы 🛟 Буферизация нагрузки Когда входящий поток нужно сгладить очередью но API при этом остается синхронным Почему это вызывает споры? Потому что это компромисс. Мы: - упрощаем контракт снаружи - усложняем систему внутри И создаем риск: - «ответ уже был, а результат еще меняется» - рассинхронизации статусов - сложного дебага Но при этом без этого паттерна: - не живут платежные гейты - не строятся интеграционные слои с внешними мерчантами 💬 А теперь вопрос: если мы умеем делать асинхронку на синхронке… зачем тогда делают наоборот? Про синхронку поверх асинхронки — в следующем посте.

Пропала на прошлой неделе — потому что у нас в компании был хакатон. И мы запилили продукт AIAjɯ. Ajɯ (Айыы) — это светлые божества в якутской мифологии. Обитатели Верхнего мира, покровители людей, воплощение доброго начала. А у нас получились AI-духи, которые помогают. В основу легла идея продукта от Миши, про которую я рассказывала тут: https://t.me/ValueGoalsDDD/782 Но на хакатоне мы ее прокачали и добавили: • авторизацию • корпоративную библиотеку промтов • корпоративные AI тулзы • работу не только с текстом, но и с картинками Главная идея — демократизировать AI внутри компании и постепенно уходить от “теневых” сервисов в ежедневных задачах. Например, банального перевода сообщений в Slack через chatGPT, тк корпоративный Gemini! Мы не выиграли 😣 Но получили невероятный кайф и сделали штуку, которой сами пользуемся теперь каждый день! Спасибо моей прекрасной команде ❤️ С которыми мы обычно работаем в разных командах и доменах — а тут наконец собрались вместе и сделали корпоративную полезняшку. Это был мой первый хакатон, и вот что я вынесла: 1️⃣ Команду надо выбирать из людей, которые тебя драйвят. И которых ты любишь работать рядом. 2️⃣ Самый большой кайф — сделать за короткое время то, что реально работает и нужно тебе самому. В этот момент уже не важно, выиграл ты или нет. 3️⃣ И да, у меня есть профессиональная деформация: я постоянно думаю, как из текущих “кубиков” собрать что-то новое. Хакатон — идеальное место, чтобы быстро “закостылять” систему так, чтобы она не падала и давала новую ценность. 4️⃣ Самое важное личное: я готова выступать на английском. Даже с небольшими докладами минут на 15. Я очень боялась, но оказалось — вполне реально. Просто требует чуть больше подготовки. На видео — наши первые пользователи. А на фото — наше чудесное трио AIAjɯ как раз в процессе работы ✨

Старое доброе... 👵👨‍🦳 Иногда, когда в IT обсуждают API, кажется, что все началось с REST, RPC, JSON и микросервисов. Но в финансовой индустрии есть пример куда более старого и при этом до сих пор живого интерфейса. Речь про ISO 8583. Этот стандарт появился в 1987 году (меня еще не было) и описывает формат сообщений для операций по банковским картам. По сути это API, через которое системы общаются друг с другом при каждой оплате картой. Каждый раз, когда вы: — платите картой в магазине — снимаете деньги в банкомате — оплачиваете что-то через POS-терминал где-то в инфраструктуре проходит сообщение по ISO 8583. И это не «музейный экспонат», который просто оставили работать. Стандарт обновляется, поддерживается и используется огромным количеством банков, процессингов и платежных сетей. Причем устроен он довольно необычно по современным меркам: — бинарные сообщения — bitmap-структура полей — фиксированные форматы данных Вместо привычного JSON сообщение выглядит как набор полей, где часть из них определяется специальной битовой картой — она говорит системе, какие поля вообще присутствуют. С архитектурной точки зрения это один из самых долгоживущих индустриальных API-протоколов. И одновременно хороший пример того, как техническое решение может прожить десятилетия, если оно оказалось достаточно устойчивым для своей задачи. (Про удобство, как можете догадаться, или про "читаемость" речь не идет) Но это "фигня" по сравнению с тем, что в некоторых крупных банках часть core banking до сих пор написана на COBOL (1959) (еще даже мамы не было)! 💬 А знаете в какой отралсли есть еще более страые и более "увлекательные" протоколы? И, нет, речь не про передачу данных 🙂

Бухгалтерская "полторашка" 🍷 Вернемся к финтеху... В классическом учете действует двойная запись: дебет одного счета = кредит другого счета. А вот термин полуторная запись я услышала недавно — оказалось, что сам паттерн я использую давно, просто не называла его так 🙂 В прикладном банковском смысле под ней обычно понимают ситуацию, когда:

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

есть баланс не меняется, но нужная нам величина в учете появляется. Простой пример: выдана гарантия клиенту. Денежные средства в момент выдачи не движутся, но обязательство банка возникает. Поэтому сумма отражается на внебалансовых счетах — внутри них запись двойная, но на баланс она не влияет. Вот эта "дополнительная фиксация рядом с балансом" в практике и дала ощущение "половинки”. 📌Где тот же самый паттерн встречается в финтех-архитектуре? Реализуют его обычно двумя способами. 1️⃣ Через отдельную техническую сущность (аналог счета холдов) 2000 € — основной остаток 300 € — сумма в HOLD Балансовый счет при этом один — мы просто отдельно учитываем часть средств, которой нельзя пользоваться. Это классика карточных авторизаций. 2️⃣ Через “окрашенные деньги” Счет один — 2000 € Но внутри: — 1700 € свободные — 300 € с меткой HOLD (или с идентификатором операции) Никакой дополнительной балансовой проводки — только расчет доступного остатка. ❓Зачем это вообще нужно Потому что в реальной жизни между:

“деньги есть” и “деньгами можно пользоваться”

почти всегда есть промежуточное состояние. И если его не моделировать — начинаются: — «красненькие» сальдо — гонки списаний — магия с доступными средствами — сложная логика в каждом сервисе А вот почему я раньше не задумывалась про “полторашку”, расскажу в следующем посте. Спойлер: на уровне процессинга можно жить вообще без бухгалтерских категорий — там все операции целые 🙂 💬 А вы этот термин используете? Слышали?

Я наконец-то понимаю зачем мне Miro 🤣 В пятницу у нас на работе хакатон. И одна из тем — AI-инструменты внутри компании. И я поймала себя на мысли, что сейчас вокруг AI есть два параллельных мира. 1️⃣ Первый — маркетинговый. Когда в продукт просто добавляют слово AI, потому что так легче продавать. 2️⃣ А второй — когда AI действительно начинает менять рабочие инструменты. И на днях я внезапно поняла, как пользоваться Miro! Я работаю с ним давно — доски, воркшопы, стратегические сессии, брейнштормы. Но то, что они начали добавлять AI прямо в рабочий процесс — оказалось реально полезно. Что сейчас умеет AI в Miro: 1️⃣ Генерировать идеи Можно задать тему — и Miro создает набор стикеров для брейншторма. 2️⃣ Разбирать хаос после мозгового штурма AI автоматически кластеризует стикеры по темам или ключевым словам. 3️⃣ Делать саммари обсуждений Можно выделить группу стикеров — и AI сделает краткое резюме идей и ключевых тем. 4️⃣ Строить диаграммы и схемы Достаточно описать процесс текстом — Miro может сгенерировать flowchart или mind-map. 5️⃣ Превращать хаос в структуру AI может преобразовать набор заметок в документ, план или таблицу. 6️⃣ Прототипировать UI К сожалению, пока не попробовала, так как не включен add-on. Но, надеюсь, что в ближайшее время смогу и тут потыкаться! 📌И вот что для меня оказалось самым ценным. После любого воркшопа в Miro обычно остается стена из стикеров. Красиво, но дальше начинается ручная работа. AI впервые реально помогает быстро превратить этот хаос в структуру. И, да, мы на хакатон тащим AI-инструмент! Уже после хакатона, расскажу, чем закончилось! 💬 А вы уже "потыкали" AI Miro? И как вам?

Полезняшка про AI 🤖 На днях LinkedIn порекомендовал мне — Евгения Брензовича. И я быстро провалилась в его посты про AI и особенно один про целую образовательную платформу. Вначале решила что это платный хайп: «5 видео и вы все знаете», но на деле! Женя создал большой, структурированный ресурс про AI-агентов, который, на мой взгляд, лучше воспринимать не как курс, а как базу знаний. Тут собрана очень большая и аккуратно разложенная по темам информация: — что такое AI-агенты и как они устроены — как с ними работать и экспериментировать — подборки материалов и статей (многие переведены) — практические инструкции и разборы — инфраструктурные вещи, включая то, где и как поднимать сервера По сути, это end-to-end учебник, который объясняет не только теорию, но и то, как реально начать что-то делать руками. И важный момент. Это не реклама. Я сама написала Жене и предложила рассказать про этот ресурс, потому что, на мой взгляд, он проделал действительно большую работу, которая может быть полезна многим! Важно: ресурс полностью бесплатный. Ссылки оставлю ниже: Учебник: https://ai.arckep.ru/ Канал Жени в Tg: https://t.me/brenzovich_ai

Иногда большие технологические прорывы происходят не в лабораториях. А потому что одна женщина просто садится и едет. В 1888 году Bertha Benz без ведома мужа взяла автомобиль, который изобрел Karl Benz, посадила в него двух сыновей и отправилась навестить свою маму. Сегодня это звучит как обычная семейная поездка. Но есть одна деталь: это был первый автомобиль в мире — Benz Patent-Motorwagen. Она проехала около 106 километров по маршруту из Mannheim в Pforzheim. По дороге: • покупала топливо в аптеке (так появилась первая в истории «заправка»), • прочищала топливную систему шпилькой для шляпы, • изолировала провод подвязкой, • а тормоза ей помог усилить местный сапожник. Эта поездка стала первой демонстрацией того, что автомобиль — это не эксперимент, а реальный транспорт. Сегодня этот маршрут официально признан памятником технической истории Германии и известен как Bertha Benz Memorial Route. И мне кажется, в этом есть очень важный символ 8 марта. В истории технологий мы часто помним имена изобретателей. Но рядом с ними были женщины, которые: поддерживали, верили, проверяли идеи на практике и иногда просто брали и делали, когда остальные сомневались. Иногда именно это и превращает изобретение — в реальность. И маленькая деталь — про матерей и силу любви. Фильм, который напоминает, что любовь и вера преодолевает любые препятствия, даже те, которые не способна преодолеть физика: Обещание на рассвете. История о том, как далеко может зайти человек, если рядом есть кто-то, кто в него верит. С Международным женским днем. 🌷 Пусть у нас всегда будет смелость садиться и ехать первыми. А если вы захотите поддерживать и любить, пусть это ценят!

Раз уж неделя у меня пошла по линии «археология собственного прошлого», держите еще один артефакт. Прекрасная Аня Афонина принесла запись моего доклада с летнего ProIT Fest V. Это тот самый доклад в формате почти стендапа — для тех, кто хотя бы раз «нюхал» процессинг и понимает, почему некоторые вещи в финтехе одновременно смешные и трагические. YouTube: https://youtu.be/mTgxAY_bja0?si=xUItSK9CPcBmudMM VK: https://vkvideo.ru/video-214863425_456239162 К интеллектуальному контенту вернемся уже на следующей неделе. А пока можно просто полюбоваться на меня прекрасную 🙂

Большой материал про ОНБОРДИНГ! 👋 В свете последних постов и прямого эфира, поделюсь циклом материалов про онбординг, которые вышли Хабре! Финальная часть - только вчера (02/03/2026)! Это три части одной большой статьи, которая выросла из моего мастер-класса (того самого, что попал в шорт-лист лучших на DevOpsConf), а потом мы еще серьезно перерабатывали и сокращали текст вдвое, чтоб хоть 3 части, а не 6 получить! Внутри материала: — как выстраивать системный онбординг, — где ломаются процессы, — почему «выйти на работу» ≠ «встроиться в команду», — и что с этим делать на уровне продукта и культуры. вот весь цикл: Часть 1: https://habr.com/ru/companies/oleg-bunin/articles/987298/ Часть 2: https://habr.com/ru/companies/oleg-bunin/articles/987308/ Часть 3: https://habr.com/ru/companies/oleg-bunin/articles/987314/ Это не пересказ МК, а полноценный разбор с логикой, структурой и акцентами, которые обычно не помещаются в тайминг конференции. 💬 Будете читать — напишите потом, как вам. Так как это мой первый опыт переделки материалов МК в текст! Можно в комментариях на Хабре или мне в личку.

Не очень сложное, но пугающее с выходных (и я не про политические конфликты) 😱 Я видела много. Очень много. Разные формулировки, странные процессы, вакансии «и швец, и жнец», компании с культом переработок и стартапы с зарплатой «зато идея». Но такую вакансию — впервые. Я сейчас даже не про вилку, не про формат оформления и не про «ненормированный рабочий день». Меня искренне интересует другой продуктовый артефакт. Мудборд в Pinterest. Серьезно?

Сделай доску с тем, что тебе нравится. Сделай доску с тем, что тебе не нравится.

И только после этого с тобой готовы поговорить. Я пытаюсь понять продуктовую гипотезу этого решения. Если цель — 👉 отсеять людей, которые не готовы тратить несколько часов жизни в никуда — окей, это честный фильтр. Тут логика есть. Но если это попытка — оценить продакт-мышление — понять культурный фит — привлечь сильных кандидатов — или, прости господи, увидеть «вайб» …то у меня не сходится модель. Потому что все, что там действительно проверяет профессию, — лежит в относительно нормальном кейсе в Notion. А Pinterest — это что? Отдельно меня восхищает формулировка:

заявки без артефактов будут удаляться без рассмотрения.

То есть воронка найма начинается с многочасового неоплачиваемого задания без какого-либо контакта с компанией. Ребята, я правда пытаюсь понять. Это: 🟡 новые реалии российского рынка 🟡 специфика конкретного стартапа 🟡 способ найти very specific type of people 🟡 или просто случайный артефакт, который вывалился в ленту Потому что пока моя единственная продуктовая интерпретация звучит так:

«Мы ищем не продакта. Мы ищем человека, которому норм».

И вот это уже честная ценностная гипотеза 🙂 💬 Что думаете?

Помощь тем, кто хо стать спикером! 🤍 Каждый раз, когда я готовлюсь к конференции, во мне просыпается один и тот же человек. Маленький, противный, очень убедительный! Он садится рядом и начинает тихо спрашивать...

а это кому-нибудь вообще нужно? а ты точно не капитан очевидность? а вдруг ты сейчас выйдешь и будешь рассказывать какую-то странную, никому не понятную штуку? а может, вообще не надо?

И самое забавное — это никак не зависит от количества выступлений, текстов, проектов, менторинга и всего остального. Можно сколько угодно раз выходить на сцену, регулярно консультировать компании и людей, можно получать хорошие отзывы — этот внутренний диалог все равно запускается по кругу. Иногда это похоже на идиотские вопросы. Иногда — на очень честные и очень болезненные. И я вдруг поняла, что пишу этот пост не потому, что нашла универсальный способ это починить. Но я знаю одну важную вещь. Я знаю людей, которых сама считаю невероятными спикерами — и они проживают ровно то же самое. Каждый год. Перед каждым докладом. Это не исчезает. Это просто становится частью процесса. Поэтому если вы в этом году думаете:

«а не начать ли мне выступать», «а не написать ли первый пост», «а не податься ли на конференцию»

— то вот вам честный ответ изнутри: да, будет страшно. И это нормально. Бояться — нормально. Быть неуверенным — нормально. Даже хотеть все бросить — тоже нормально. И при этом именно живые люди, с реальными кейсами и настоящими объяснениями, — это самое ценное, что у нас есть. Не идеальные презентации. Не вылизанные тексты. А возможность прийти к кому-то, кто разбирается, задать точный вопрос и услышать живой ответ. Унести с собой мысль, которой у тебя не было, и побежать дальше работать. Никакой AI пока не заменяет это ощущение. Поэтому если вам нужна поддержка — приходите. Правда. Я готова помогать с темами, со структурой, с первыми шагами — просто потому, что спикеров должно становиться больше. Новых. Разных. Своих. И Паша Гертман @zarazum , кстати, тоже сейчас этим занимается — помогает готовить выступления. А еще мне очень хочется сделать из этого не мой монолог, а что-то большее. Если вы тоже готовы помогать начинающим — со статьями, с докладами, с блогами, с подачами — напишите об этом в комментариях. Давайте соберем живой список людей, к которым можно прийти за поддержкой. Потому что чем шире этот круг — тем больше в нем света. И тем меньше каждый из нас остается наедине со своим внутренним самозванцем! 💛

Новый рекорд или пробила дно! 🕳 На днях я, кажется, либо пробила дно, либо поставила личный рекорд. ⚠️15 встреч за 10 часов.⚠️ И это были не те созвоны, где можно тихо «присутствовать» фоном. Каждая — с включенной головой, с решениями, с ответственностью. Пятнадцать переключений контекста подряд. Я не уверена, что такая акробатика вообще совместима с понятием «результативность». Потому что после какого-то N-го переключения мозг уже не работает в режиме deep, он работает в режиме «следующая вкладка». И ровно в этот момент мне попадается письмо Маска про: — убирайте большие встречи — убирайте частые встречи — уходите, если не добавляете ценности — общайтесь напрямую — руководствуйтесь здравым смыслом И самое ироничное — часть моих текущих правил хождения на встречи с этим почти совпадает. Если хотите — отдельно расскажу. Но есть нюанс. В больших нетехнологических компаниях (где продукт в "реальной" сфере, а космические технологи и тп) почти всегда огромный разрыв между бизнесом и разработкой даже на уровне понимания продукта (и это нормально). Чтобы команда могла работать и не жила в календаре, менеджерский слой ходит на встречи вместо нее — собирает контекст, договаривается, снимает зависимости! Поэтому иногда 15 встреч — это не про неэффективность, а про попытку защитить фокус команды. Но вопрос остается: — мы синхронизируемся — или уничтожаем друг другу рабочий день? 💬 Какой у вас был самый безумный рекорд по встречам за день — и зачем? И да — сегодня будет прямой эфир, где в том числе поговорим про эффективность и коммуникации в реальной календарной жизни. 😂👍👍❤️👌😅😊😊😍😘 26 февраля, 18:00 ч. (мск) Регистрация тут

😂👍👍❤️👌😅😊😊😍😘 26 февраля, 18:00 ч. (мск) Приглашаю вас на новый эфир: «Когда коммуникации решают: эффективность команд в эпоху ИИ» Сегодня AI-инструменты становятся умнее, а скорости — выше. Но эффективность команд по-прежнему ломается не в коде, а в коммуникациях. И об этом крайне важно говорить! У меня в гостях: ➡️ Катя Лысенко — техпродакт кипрских финтех-компаний, 15+ лет строит платформенные команды и решения (процессинги, кошельки, онбординги, AML), спикер ArchDays, TeamLead++, Highload, DevOps, автор канала «ITKatya. Культурные паттерны в Айти». ➡️ Кирилл Поляков — предприниматель и продуктовый лидер с 15-летним опытом, руководит компанией по цифровой трансформации и внедрению ИИ, экс-CPO Догма, Иннотех/Т1, ДИТ Москвы, CTO RUSSPASS, co-founder Tech Week. Обсудим: ❓ почему с ростом инструментов и автоматизации коммуникаций становится больше, а ясности — меньше? ❓ как состояние людей влияет на то, как они слышат задачи и принимают решения и почему это критично именно сейчас? ❓ как меняется роль лидера в коммуникациях, когда часть решений и аналитики берёт на себя ИИ? Эфир уже завтра — значит, самое время пройти РЕГИСТРАЦИЮ, чтобы получить свою ссылку на участие в zoom-встрече. «Эмоции успеха» | Елена Логачева

Завтра позвали на прямой эфир! Присоединяйтесь! Давно не говорили «словами через рот»!

Аргументы против мультиков! Продолжем тему прошлой недели. Когда предлагаешь разрешить мультики, почти сразу слышишь набор аргументов «почему так нельзя». Вот самые частые — и что с ними делать, если вы все-таки хотите жить «честно»! 🚓 «Это фрод» Мультиаккаунт ≠ мошенничество. Фрод — это поведение. Решение: считать риск на уровне человека, а не аккаунта. Мультик — сигнал. Фрод — вывод. 💸 «Лимиты разъедутся» Разъедутся, если они считаются на аккаунт! Это архитектурная задача, а не запретительная. Решение: — лимиты на сущность человека — явная агрегация — разделение продуктовых и юридических ограничений 🤔 «Антифрод и AML не поймут» Не поймут, если вы скрываете логику/связи/сущности. Решение: — хранить связь аккаунтов явно — строить профиль риска на человека — не делать вид, что это независимые сущности 😓 «Слоооожнааа и дорого» На старте — сложнее. Но модель «один аккаунт = один человек» плохо масштабируется. Решение с контролем почти всегда выигрывает в долгую. 🚫 «Регулятор не разрешит» Регулятору важно: — кто человек — как считаются лимиты — есть ли аудит Решение: разделите домены, очистите сущности и сдавайте регулятору то, что он хочет и как написано в документах, а не то, как прочитали. Если принять, что мультики: — неизбежны — легитимны — будут всегда вопрос меняется. Не «как запретить?», а «как безопасно с этим жить?». И это уже честная архитектура, а если порыться на просторах интернета или взять консультации, то выяснится, что еще и практически все проблемы уже решены и они не проблемы, а паттерны! 💬 А вы какие «против» встречали или почему «против» сами?

Полезняшка выходного дня 🧠⌨️ Нашла (и уже активно пользуюсь) штуку, которая внезапно сильно упростила жизнь — приложение с AI по горячим клавишам, которое работает прямо поверх любых программ. Без переключений между окнами. Без «ой, тут нет встроенного AI». Вызвал хоткей → применил свой привычный промпт → получил результат. Где мне зашло больше всего: — переводы в Slack и Telegram (греческий, привет 🇬🇷) — быстрые форматирования текста в Confluence — работа с определениями и формулировками (да, тот самый промт под определения) — любые повторяющиеся промпты (написать, переписать, структурировать) Фактически это AI как системная функция, а не как отдельный чат. Отдельное ❤️ — потому что сделал это человек, с которым мы когда-то вместе работали в Яндексе. Миша Степанов сейчас живет в Эстонии и уже много лет учит маленьких роботов кататься, а параллельно пилит такие удобные тулзы. Не реклама — реально пользуюсь и кайфую. Если вы, как и я, уже не представляете рабочий день без своих промптов — очень советую попробовать: 🔗 https://www.producthunt.com/products/ai-hotkeys И да — мир бывших индексоидов все еще регулярно поставляет что-то очень классное 🙂 А вот линк Миши, если хотите к нему с ОС или посмотреть что он еще придумал!

Мультиаккаунтинг — за и против. Тема, вокруг которой обычно сразу начинается спор! Мультиаккаунтинг — это когда один и тот же человек легитимно или фактически имеет несколько аккаунтов в одной системе. Самый банальный пример — аккаунты Google. Личный. Рабочий. Проектный. Мы спокойно переключаемся между ними десятки раз в день — это тот случай, когда мультиаккаунтинг — офигенно классная штука! Пример боли с мультиками — банк (а какой еще у меня может быть пример 🤣). Два аккаунта одного человека. Но: — разные балансы — но должны быть общие лимиты — разные счета — но хотелось бы общего управления И вот тут пользователь внезапно оказывается в аду. Личная история. Лет 12 назад я пыталась в Сбере разобраться с пачкой своих учеток. Исторически они появились в разные моменты жизни, под разные продукты и открыты были в разных районах СПб. А дальше началось классическое: «идите в то отделение, где открывали». И это мы сейчас говорим только про пользовательскую сторону. Почему для компаний мультик чаще геморрой? Потому что: — лимиты начинают считаться неправильно — риск-профиль размазывается — антифрод видит «разных» пользователей — KYC дублируется — поддержка не понимает, с кем именно она разговаривает Добавьте сюда: — регуляторные требования — отчетность — аудит — санкционные и AML-проверки — кросбордер (когда пользователь может в нескольких странах в рамках одного сервиса работать)… И мультиаккаунт перестает быть «просто дублем». Он становится отцом критического риска! ИМХО (и с ним можно не соглашаться) Я считаю, что любой мультиаккаунтинг проще разрешить, чем запрещать! А контроль должен быть вынесен на уровень сущности человека, а не аккаунта. Да, на первый взгляд это: — дороже — сложнее — требует архитектурной дисциплины Но в долгую такое решение выигрывает. Почему: — аккаунты можно доклеивать по мере роста экспертизы — лимиты можно держать общими — риск можно считать на человека — продукты можно разделять по ролям И самое главное — вы перестаете врать себе, что в системе «нет повторных аккаунтов». Потому что, как мы уже знаем по предыдущим постам, какую бы систему вы ни построили — кейсы, которые ее обойдут, будут всегда! Вопрос не в том, будут ли мультиаккаунты. Вопрос в том, признаете ли вы их существование архитектурно или продолжаете бороться с реальностью. А реальность всегда побеждает 😭! 💬 А вы за или против мультиков?

🔥 Go в Go 🔥 (да, снова — ищу, и тот случай, когда ОЧЕНЬ НАДО) Мы в inDrive расширяемся и ищем Backend Engineers (Middle / Senior / Staff) на Go — и особенно я ищу человека в KYC / Compliance Platform. А там, где про KYC — это ко мне ❤️ 🧩 Compliance как платформа, а не набор проверок — архитектура — data flows — интеграции — автоматизация — AI верификация ⚙️ Техвызовы, от которых не скучно — highload — distributed systems — system design — предсказуемость изменений в регуляторке (да-да 🙂) 🌍 Международный продукт, где твой код = безопасность миллионов пользователей. 👥 Команда — любовь — сильная инженерная культура, — думающие архитекторы, — вменяемые стейкхолдеры (это важно!), — продуктовый майндсет. ☀️ Казахстан яркий, современный и очень рабочий и родной. Что нужно — уверенный Golang — опыт со scalable distributed systems — желание думать, а не просто писать код Если хочется: 💥 сложного 💥 веселого 💥 продуктового 💥 и на Go Go к нам 🙂 Мне в прошлый раз невероятно помог ваш шеринг с поиском аналитика — надеюсь, в этот раз случится так же 🫶 📩 Можно писать: — в личку — в комментарии под постом И позовите своих гошников, если знаете тех, кто хочет в highload + сложный домен + глобальный продукт. Подробнее вакансия Очень жду своего человека 💚