#lafest Бунто Татьяна. ETL-интеграции без валидола. Хороший доклад про разработку надежно работающей интеграции между разными системами. Про особенности и распространенные грабли, которые надо учитывать. Дальше - содержание в тезисах.
* ETL: Extract - Transform - Load. Разобраться надо со всеми тремя частями. И нужны команды, готовые отвечать.
* Надо всегда рассчитывать, что после загрузки будут корректировочные инкременты, до нескольких лет.
* Перелив данных может идти долго, у них было до 20 дней. Исправление и полная перегрузка при этом тоже 20 дней, полезна точечная перегрузка.
* В реальном мире часто интегрируют сразу на продах. Или Prod->Test. Потому что тестовые контура могут отсутствовать или не содержать репрезентативных данных. И это требует заранее проработать доступы, и дает требования на нагрузку.
* Сделайте чек лист условий для запуска: реализованы представления, открыты каналы, установлены нужные релизы и так далее.
* Трассируем бизнес-данные на их хранение в системах источниках. Например, где правильные телефоны и емейлы для юриков и физиков - это может быть в разных местах.
* Фильтры отбора: только клиентов с контрактами, или не грузите технических абонентов, или не грузите если есть признак устаревшего. Все это надо перевести в технические условия и посмотреть, что получается.
* Система-приемник. Там таблицы, ключи, обязательные поля, которые могут быть пустыми в источнике - что делать.
* Совместимость типов, особенно с датами и часовыми поясами. Что делать, когда строки не лезут в приемнике.
* Протокол системы-приемника. Например, система модет быть рассчитана только на ежедневные инкременты, а может быть на нумерацию.
* Ключи. Бывает, что в системе-источнике контактные лица юрика - вообще не отдельные сущности-люди, а в системе-приемнике есть таблица физ-лиц контактов с идентичностью.
* Событийная модель. Не только создание или изменение, а с учетом фильтров. Например, абонент стал анонимным, которого не грузим.
* Логирование. Чтобы интеграция записывала, что сделала, и почему упала, и фиксировала - что там было, и в каком сообщении это пришло.
* Срочные догрузки: я нашел карточку, и срочно загрузите. Да еще со связанными сущностями. И это задача точечной перегрузки.
В том числе - перегрузка пула ошибочных записей, которые нашли.
* Сверки могут быть, но они дорогие для нагруженных базах. Поэтому это обычно не регулярная процедура, а разовая.
* На начальной стадии нужно тестирование, в том числе через сверку на репрезентативных кейсах.
* Все учесть невозможно. Надо мониторить и быть готовым ко всему. Например, прилетит огромный инкремент, потому что в системе-источнике решили что-то глобально обновить.

#lafest Презентация моего доклада - на моем сайте https://mtsepkov.org/DDD-LAF2023

#lafest Андрей Василевский. Мысли как архитектор. Распиливаем монолит с помощью шаблонов DDD. В докладе - конкретная методика. Сначала Event Storming для выявления групп процессов. Добавляем набор объектов, с которыми эти процессы работают. Кластеризуем процессы по их общему, визуально группируем. Границы кластеров - размыты. Если просто использовать эти группы для разрезания монолита, получится микролит - сильно связанные сервисы.

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

Дальше - доменная модель в каждом контексте, агрегаты и сущности, их инварианты. И начинаем писать код и рефакторить.

#lafest Евгений Скориков. Нефункциональные требования? Модели обеспечения качества! Очень хороший доклад, о том, что нефункциональные требования в их привычном виде "отказоустойчивость 99.5%" или "отклик системы 5 секунд" - совершенно бесполезная вещь: непонятна осмысленность, способы удовлетворения и тестирования и риски. 99.5% - это 0.5% сбоев, если система не работает в год 1.5 суток подряд - это как, нормально? Для многих - ненормально, хотя в норматив формально укладывается. В общем, эта критика - понятная, эти требования часто берут произвольно. Например, по производительности, кстати, нет достоверных исследований: как именно скорость работы сайта влияет на бизнес. Понятно, что если ваш сайт жутко тормозит, и есть сайт конкурента, который делает все тоже самое и быстро, то люди уйдут туда. Но в реальной жизни сайт конкурента делает НЕ тоже самое, там есть чего-то меньше и чего-то больше, у него есть другая эргономика. И как это влияет? Исследований нет. Честное исследование - замедлить сайт для части клиентов и сравнить, но на это ни один бизнес не пойдет.

Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.
1) Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2) Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчисовти смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности - деградацию на выполнении различных функций. И так далее.
3) Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится - каковы последствия, потери для бизнеса.
4) Для проблем - есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5) Выбор решения - по балансу потерь против стоимости.
6) Проектируем тест выбранного решения.

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

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

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

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

#lafest Ирина Баржак. Как вытащить требования из заказчика без гипноза (и без паяльника)? Я слушал только вторую половину доклада, потому что он пересекался с докладом Жени Скорикова. Поэтому кратко. Ирина рассказывала модель GROW структурирования встречи и задавания вопросов, которая разработана в коучинге. Встреча делится на четыре части
1) Goal - Цели, зачем почему и что мы хотим сделать
2) Reality - реальность сейчас, как это устроено, какие с этим проблемы, почему они появились и так далее
3) Options - возможности по решению проблем: какие вы видите, чтобы вы посоветовали в такой ситуации другу и так далее
4) Way Forward - как приступить к действиям - какой первый шаг, что надо предусмотреть и так далее
К каждой части на слайде было больше десятка вопросов, которые могут помочь вытащить информацию. вопросы - нетривиальные, участники придумывали свои с интересными формулировками. Например, "как наши действия помогут вам достичь наших целей?" - это про цели.

Модель совершенно общая, не только с заказчиком. Можно с детьми и близкими. Ирина готовит журналистские интервью по модели. И в общении с заказчиками тоже помогает. Люди любят когда их спрашивают про их деятельность, слушают ответы, когда они сами предлагают и решают. Конечно, коучинговый источник накладывает свой отпечаток, коуч не предлагает решения, а выводит на него, в то время как от ИТ-специалистов обычно ожидают предложений. Но и предложения можно облекать в форму вопросов: А что вы думаете вот о таком варианте? Так что модель полезна - в дополнение к другим, профессиональные списки вопросов не отменяются. Но, кстати, и в них вопросы о целях, проблемах, средствах достижения и первом шаге - обязательны, так что модели сопрягаются. А эта модель позволяет задать нетривиальные вопросы, которые дают много информации о нюансах, которые иначе всплывают потом, на внедрении.

#lafest Михаил Рейнганд. Как придумать фичу, отталкиваясь от проблем пользователей. Клиентский опыт - все взаимодействие, включая маркетинг - это ваш клиентский опыт. Отличается от пользовательского опыта, которые про взаимодействие с конкретным продуктом, который уже предоставлен. Михаил в Альфа-банке Отвечает за клиентский опыт по безопасности в розничном бизнесе. В основном это фрод-мониторинг и блокировка подозрительных операций по алертам, после которых следует звонок сотрудника безопасности банка, который должен удостовериться, что это - добровольная операция и разблокировать, либо подтвердить блокировку и заодно заблокировать все остальное. Для этого взаимодействия был проработан Customer Journey Map, выписаны проблемы взаимодействия. Источником были реальные записи разговоров с клиентами, и всякие опросы. Проблемы - приоритизированы с учетом масштаба и ущерба.

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

Дальше был рассказ про технику - чтобы раскатить фичу без обновления приложения, потому что AppStore заблокирован, для этого использовали SDUI - управление с мидла фронтом, тогда присылают json, который фронт отрисовывает. В идеальном мире сокращается фронт-разработка. Но есть недостатки. Андроид и iOS - разные компоненты, зависят от версии. Получилось не очень хорошо по эргономике, ну, что поделать. Фича в обычном состоянии выключена, включается безопасником через push-уведомление с нулевым приоритетом, в уведомлении - сразу ссылка на конкретный экран приложения. Может не сработать в конкретной версии и на конкретном устройстве - там содержательное сообщение об ошибки.

Показали клиентам, сделали широкую рекламную компанию. Решение взлетело. Собирают регулярную обратную связь - ежемесячно общаются с сотрудниками, после каждой верификации сотрудник пишет обратную связь, и должен указать успех-не успех - тех.ошибка. Пока операторы еще учатся разбираться с ошибками. Фичу выкатили в конце апреля, за май примерно 5 фродов предотвратили. Есть техническое ограничение: интернет вместе со звонком невозможен в 3G и если звонок и инет на разных картах. Это - одна фича, по проблемам CJM планируются и другие, например, подтверждение без звонка.

#lafest Высотина Александра. Vision recognition: как работает распознавание образов/лиц. Идентификация по лицу сейчас встроена во множество банковских и других коммерческих систем. Особенность момента - 572-ФЗ, который регулирует работу с биометрическими данными и дальше ты должен либо передать всю свою базу в Единую биометрическую систему и за распознаванием обращаться к ней на платной основе, либо пройти аккредитацию для собственной коммерческой системы. Аккредитация требует 300м на счету и прохождение аудита по безопасности хранения и шифрования данных. И поэтому сейчас будет довольно много проектов перехода.

Дальше был обзор-ликбез. Различие биометрических и не-биометрических персональных данных. Биометрические:
* все изображения на документах, которые позволяют куда-либо пройти - паспорт, водительское, пропуск
* все 3d модели, в том числе медицинские снимки
* все фото-видео, приобщенное к материалам дела
Все остальное - просто персональные данные. Съемки в публичных местах, их выкладка в инет и обработка - возможны, здесь российское правовое поле свободнее западного.

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

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

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

А еще были всякие интересные кейсы. Например, сеть научили не путаться распознавать толпу - и пропускает людей с майками, где фото с толпой. Был кейс, когда они предлагали свое решение в Штатах и обломилось на том, что сеть была необучена на неграх, и она не смогла вообще опознать потенциального партнера. При умирании лицо сильно меняется, был проект для МВД по опознанию трупов - результаты не достигнуты. А вообще лицо успешно опознается 6-7 лет. Но вот сезонные изменения лиц - очки и кепки летом, маски при пандемии и так далее - нарушают распознавание, получаются ошибки первого рода. Правда у Apple распознавание дообучается, узнает тебя в очках - но тут вопрос про ошибки второго рода.

#lafest Андрей Зеров. Chatgpt: победит ли аналитик в борьбе с ИИ? Выводы доклада: в противопоставлении нет смысла, наоборот, стоит использовать ChatGPT как помощника в работе - он классно порождает многие документы, да еще в нужном стиле. Например, может написать письмо в деловом стиле, смысл которого ты ему объясняешь в запросе. Может сделать таблицу с заданными колонками, описать структуру базы данных, сделать диаграммы на PlantUML. При этом ты ставишь ему задачу в достаточно общем виде, абзацем текста, а потом - уточняешь. Ну а потом сам дорабатываешь результат. И вот для оценки результата важен собственный опыт, потому что он отвечает в любом случае, додумывая относительно произвольно - как поисковый запрос всегда выдает ответ, но далеко не всегда - с нужной информацией. Начинающий аналитик оценить ответ не сможет, у него не хватит опыта и знаний. О том, как формулировать запросы Андрей подробно не рассказывал, он сослался на доклад Юры Куприянова "ChatGPT в работе аналитика" на весенней AnalystDays, их можно посмотреть в презентации, которая уже опубликована на сайте конференции. У меня тут возникает вопрос: как скоро умение работать с ChatGPT появится в требованиях к компетенции аналитика и будет проверяться на собеседованиях? Или оно не появится, как нет требования к умению искать информацию в интернете - хотя далеко не каждый умеет делать это эффективно, и это напрямую влияет на освоение аналитиком новых областей.

#lafest Мария Старостина. Не провал, а ценный опыт: как избежать ошибок в продуктовой разработке. У компании Кошелек есть команда, которая занимается созданием и тестированием новых фич. Мария рассказывала об одном из их проектов, который не взлетел, но ретроспектива позволила получить ценный опыт. Проект был масштабный и его принес бизнес - позволить через Кошелек заказывать товары с доставкой, надо было протестировать идею. Для пилота выбрали ВкусВилл, это давний партнер и он был заинтересован в функционале, а при успехе было бы распространение на крупные сети, у которых тоже был интерес.

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

Они, тем не менее, решили не останавливать эксперимент, и сильно урезали сценарий первой версии, включая работу с адресами доставки и оплатой. И пошли на реализацию. Развитие событий показало, что это было ошибкой: сокращенный сценарий сценарий для начала тоже надо было протестировать - тогда бы был шанс выяснить, что местами урезано было недопустимо сильно. И еще - пересмотреть ожидания от будущих пользователей, которые были рассчитаны из полного сценария. А так после запуска получилось, что пользователей за первый месяц - на порядок меньше ожидаемого, в том числе из-за неудачного размещения точки входа и ряда других причин. Точку входа спрятали в меню, и обзвон показывал, что первый раз войдя через ссылку из push-уведомления, разосланного своим пользователем, они потом точку входа вообще не находят. Часть проблем они устранили, точку входа сделали на странице Каталога, сделали рекламку на приветственном экране и так далее. Число пользователей росло, но не быстро и в декабре все-таки руководство решило остановить проект, признать эксперимент неудачным. Они провели большое ретро и появился чек-лист, 11 пунктов которого были в презентации, а остальные - доступны по ссылке.

В ходе конференции ЛАФ сделал наблюдение, которое, на мой взгляд, заслуживает отдельного обсуждения. У многих аналитиков неявно есть "учебный" взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка "по умолчанию" считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

И все это не лишено оснований в реальной жизни: оценки проекта основываются на следовании правилам и процедурам, а не на реальном результате внедрении системы или отдельных фич, и методика ведения проекта это предполагает. Проблема в том, что реально это плохо работает: сначала по известным методикам пишут постановки, потом их реализуют, а потом оказывается, что результат плохо применим на практике. Но в объяснении говорят "вы плохо следовали методике", не оценивая пригодность методики как таковой. То есть учебный подход, сформированный в школе и институте - поддерживается. Я вижу проявления этого не только на конференциях.

Чтобы перейти от такого подхода к реальной работе на достижение результата надо менять мышление. Такие тренинги есть для руководителей, это переходе понимания ответственности от responsibility к accountability, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

Собрал заметки по докладам и опубликовал отчет о ЛАФ-2023 https://mtsepkov.org/LAF-2023, которая прошла в середине июня. Было много интересных докладов и много общения, это - фишка формата конференции, которая проходит два дня в доме отдыха, и при этом стоит очень демократично. Понял, что надо это сделать до питерских Highload и Teamlead, в которых я участвую на следующей неделе. Так что я уже в Питере.

Сегодня в Питере на #highload. Первый доклад - Андрей Тимофеев Групповые чаты в Одноклассниках. Доклад про архитектуру: в одноклассниках были диалоги между участников, задача была сделать групповые чаты, по-возможности, использовав уже разработанное. Реализация - кассандра для хранения и собственная очередь, когда начинали разработку, Кафка была не очень хорошей. Казалось бы, нет проблем - вместо композитного ключа чата из ключей двух участников делаемшь отдельную базу участников чатов, и все начинает работать. Однако, это не так. Дело в том, что есть задача показа главной страницы чатов, где отображаются последние изменения. Ее невозможно посчитать на лету, поэтому для каждого пользователя хранится история его чатов. В случае диалогов посылка одного сообщения меняет историю только для двух участников, а в случае групповых чатов сообщение меняет столько историй, сколько участников у чата. А их можно быть много, десятки тысяч. При этом история у пользователя - длинная. И поэтому было ряд архитектурных решений:
* Деление истории у пользователя на активные - первые 50 и архивные, которых может быть много, до 10к - мы проигрываем когда чат поднимается из архива или выталкивается, но в 10 раз выигрываем при обновлении среди активных чатов.
* Двухфазная обработка сообщений: одна очередь пишет сообщения в чат, и обработчик ставит отдельные очереди по обновлению истории для каждого получателя. Если обновлять истории вместе с записью сообщения, то возникают коллизии, так как одна история может обновляться из многих активных групповых чатов, а такая архитектура позволяет обновлять очереди индивидуально в пакетном режиме без коллизий.
* Отмена readmarks для чатов, где больше 100 участников, так как они распространяются квадратично. Узнать кто прочитал по-прежнему можно, но это - специальный механизм.
* Утолщение клиента - раньше он каждый раз запрашивал историю с сервера по push-уведомлению об изменении, теперь он сам хранит сообщения и получает все обновления через push без запроса.
В результате они успешно держат нагрузку с групповыми чатами, в презентации были характеристики откликов и железа, и нагрузка на БД даже снизилась.

#highload Максим Павлов. Совмещаем потоковые и пакетные процессы в Camunda BPM. Доклад был про архитектурные шаблоны использования Комунды для оркестрации работы сервисов. Embeded версия, хранение в PostgreSQL, интеграция с внежними системами через Kafka. Две задачи вокруг кредитов: обработка потока заявок на кредиты, которая идет в автоматическом режиме с точечным включением импортных операций; подготовка предодобренных заявок на кредиты по большому количеству данных ежемесячно в пакетном режиме. Задачи разные, но в обоих - сложная схема обработки из полутора десятков шагов, которые выполняются параллельно, но есть зависимости. В докладе были базовые шаблоны: вычислительный элемент, сообщения, конструкции управления процессами, тайминг и ожидание событий и более сложные элементы из них: запуск параллельных процессов, синхронизация потоков для обработки зависимостей, шаблоны для обработки ошибок - экземпляр не прерывается. а приостанавливается и может быть продолжен после решения проблемы, например, если интеграция почему-то приостановилась и ее запустили, шаблоны для включения ручных шагов, исполняемых пользователями. Примеры - со схемками, скриптами.

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

#highload Анастасия Тушканова из Ozon. Feature store: как мы совместили высокую производительность и безграничные потребности data scientist’ов. Рассказ про доработку архитектуры для обеспечения производительности и обеспечения A/B-тестирования. Feature store - хранилище характеристик, которые используются поиском для сортировки товаров после того, как нижний поиск выдал 2000 товаров, релевантных текстовому запросу. Сортировка учитывает характеристики товаров, включая популярность в заказах и предпочтения конкретного пользователя. Эти характеристики считают аналитики в Hadoop, а дальше их надо переложить в redis для эффективной сортировки.

Проблемы были с производительностью, увеличением числа нод и реплик они не решались. Поэтому пошли на доработку архитектуры, в докладе было несколько решений. Во-первых, сделать шардирование товарных характеристик по категориям товаров, потому что шардирование по товару приводило к тому, что 2000 товаров каждого запроса распределены по всем нодам, а если будет лежать по категориям, то нод будет мало. Но управление надо делать вручную, так как категории содержат разное число товаров, надо разложить равномерно. При этом потребовалось отдельный механизм обновления категорий на Kafka - категории у товара меняются. Во-вторых, сделали отдельное холодное хранилище на реляционке, в которое перенаправили запросы сервисов, которым время ответа не критично, и на котором работают аналитические запросы. Оптимизация запросов позволило уменьшить число реплик с 18 до 3, необходимых для устойчивости работы. И это позволило сделать несколько экземпляров для A/B тестов. И не только для аналитиков, но и для самих моделей приоритизации.

#highload Андрей Парамонов из Додо. Use actors, Luke. На мой взгляд, очень хороший доклад. В нем - интересный обзора концепции и истории Акторной модели. Потому что модель появилась давно, в 1970-х. Андрей говорит про статью 1973 года Carl Hewitt, Peter Bishop и Richard Steiger "A Universal Modular Actor Formalism for AI", и там - теоретическое обоснование, которое дальше было развито в нескольких научных работах.

Замечу, что если смотреть от практики, то может быть другой взгляд - что акторная модель была реализована в Smalltalk, который вышел на год раньше и среди авторов которого был Ален Кей. Его высказывание, что основой замысла ООП были именно акторы как изолированные объкты, а пошла развивать наследование и полиморфизм, тоже было в докладе. Так или иначе, модель опередила время, акторы стали востребованными в современной архитектуре мультиядерных процессовров, исполняющих множество потоков. А история развития ООП пошла от C к С++ и далее к Java и C#, где многопоточность не была реализована на уровне языка совсем. Хотя в 1986 появился Erlang с легковесными потоками, которые очень удачно реализуют акторную модель. Как сказал Андрей, интересно, авторы не были знакомы с научными работами по подходу, хотя фактически его реализовали. Но все равно, это было вне основного пути.

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

Модель отношений акторов: иерархическая и одноранговая. В иерархической - родитель создает, решает что делать при ошибке, можно восстановить, в том числе с сохранением очереди. В одноранговой акторами управлет run-time, создавая акторы по необходимости для обработки сообщений и удаляя при отсутствии активности.

Usecase: pipeline proicessing, transaction application, стриминг данных (реактивные системы, event-based, чаты), multi-user concurency, приложения с распределенным состояниям, для которых не хватает одной машины, IoT - сообщения от датчиков и состояния, Timers - много таймеров по разным условиям.

И дальше был их пример. Dodo работает в 20 странах и в каждой надо интегрироваться с местным эквайрингом для приема платежей, никакого стандарта нет. Они использовали Microsoft Orleans, фреймворк появился в 2015, потом заснул и перспективы были неясны, но сейчас вроде проснулся и будет развиваться. Дальше было ряд рекомендаций: не забыть про observability (логи метрики трейсы); помнить что ресурсы не бесконечны, хотя актор и легковесен, и mailbox не бесконечный. Продумать восстановление состояния и балансировку нагрузки. А еще написание в синхронном стиле async/await приводит к тому, что между потоками могут возникать deadlock.

И выводы: акторы - простая абстракция, сильно упрощает код, хорошо масштабируется. Уместность - решаем конкретно, простые приложения с crud - не нужно. Что есть: Akka, Orleans, Proto.Actor, Darp (распределенные акторы). И был слайд со списком книг.

#highload Станислав Богатырев из YADRO. Как мы переживаем сплит-брейн и продолжаем писать данные по S3-протоколу. Доклад был про архитектуру FrontFS. Это объектное хранилище, рассчитанное на установку по всему миру в интернете, вне защитных контуров. При такой установке нет гарантий связности между узлами сети. И им важно, чтобы узлы продолжали работать в этом случае на чтение и запись данных, а после восстановления связи решение конфликтов происходило без участия человека. Следствем этого требования является работа без какого-либо центрального узла хранения метаданных. В самом хранилище объекты являются неизменными и адресуются собственным хэшем. И с этим нет особых проблем.

Но для удобной работы необходимо поддержать адресацию по протоколу S3, в котором объекты раскладываются в аналог файловой системы и при этом разрешена их модификация через порождение новых версий. И если при нарушении связности в разных частях системы были созданы новые версии объектов, то надо уметь определить последнюю версию. При этом модификация, в том числе, предполагает перемещение объекта по иерархии - как файлы перекладываются в другую папку. И о том, как обеспечить связь имен с объектами и был доклад. Для этого используют технологию блокчейн, которая заодно дает локальное время в системе, измеряемое номерами блоков. Он обеспеивает распределенное хранение без центрального узла и слияние с разрешением конфликтов с упорядочиванием по локальному времени, а при совпадении - по возрастанию хэша версии объекта. Основой послужила статья про CRDT-дерево Martin Kleppmann, который обосновывает, что дерево может быть описано как последовательность операций добавления и перемещения узлов, при чем они являются коммуникативными, что как раз дает возможность слияние. Реально задача нетривиальная, в докладе было несколько простых вариантов, которые не работают. И было на примерах показано, как работает их алгоритм в сложных случаях решения конфликтов. Тот же алгоритм можно было сделать на распределенной БД, но у нас открытый интернет, распределенная БД не дает защищенности.

FrontFS можно пользоваться, исходный код выложен в git, есть enterprise-версия Tatlin.Object в несколько меньшим масштабированием, но большей управляемостью, она платная.

#highload Павел Велихов из TigerGraph. Распределенные графовые СУБД — будущее для аналитики на Больших Данных? В докладе был верхнеуровневый обзор - что такое графовые базы данных, чем отличаются от реляционных, и для каких задач применяются. Лично мне в докладе не хватило глубины, получалось, то графовые базы данных - это тоже самое, что реляционные, только эффективно работает большое количество join, и это - чисто техническая разница, она под капотом и от пользователя скрыта. У меня есть подозрение, что это - не так, что есть какая-то более глубокая разница. Во всяком случае, был пример, что свертка аналитики по графамм устроена как-то иначе, чем агрегация с group by в sql, но на уровне принципов эта разница, к сожалению, развернута не было. А может быть, и нет особой разницы, о всяком случае, в моем представлении - потому что я всегда смотрел на написание join в SQL как на путешествие по графу ER-диаграммы. Но это - мое мышление, из общения с людьми я знаю, что так мыслят далеко не все, и в учебниках по SQL учат не так. И, вполне возможно, что такое поверхностное изложение было адекватно аудитории, во всяком случае, реакция была заинтересованная и позитивная.

Был интересный пример антифрода - прослеживание путей перевода денег по транзакциям для отмывания. На чистой реляционке это делается действительно сложно, если пути длинные. Впрочем, для графовой БД, запрос со всеми условиями нам не показали, отослали к книге. И это - один из примеров алгоритмов, которые на графовой базе решаются лучше, чем в реляционной. В TigerGraph, где работал Павел, есть открытая библиотека из 50 алгоритмов, которые можно использовать для прикладных своих задач: кратчайшие пути, community detection, кластеризация. Но на другие БД ее надо портировать, так как, к сожалению, единого стандарта на на язык запросов к графовым БД нет, стандарт ожидается в 23-24 годах, при этом уже понятно, что туда войдет небольшое ядро, а у каждой БД будут свои расширения. Помимо алгоритмов, способ применения - ML на графах, там это получается проще, чем на реляционке, как раз потому что можно легче вытаскивать объекты по связям. Области применения: finantial fraud, risk, monitoring, customer journey, рекомендации, supply chain analysis, energy management (трубопроводы и электросети), network resource optimization...

По имеющимся БД обзора не было, в основном рассказ был про TigerGraph, которая закрытая и работает в американских облаках, но с которой можно бесплатно поиграться. Neo4j - открытая, но есть ограничения по производительности. Впрочем, это - старое сравнение от Tiger, так что надо смотреть конкретные цифры, эти ограничения могут быть несущественны для вашей задачи. Еще есть NebulaDB - китайский open source, она послабее Tiger, но интенсивно развивается. Почему-то не упомянул ArangoDB.

И сейчас есть тренд на гибридные базы данных, встраивание графового движка в реляционки. Павел считает, что это - более перспективно, чем развитие чисто графовых до соразмерных с реляционками объемов и функций. Выходит расширение SQL/PGQ для работы с графами, драйвит это Oracle, у которого, кстати, уже очень давно есть конструкция start with - connect by, позволявшая ходить по деревьям в реляционке, в частности, задача нахождения цепочки транзакций для антифрода через нее решается. Так что. возможно, гибриды действительно будут эффективнее. Посмотрим.

#highload Сергей Прийменко. Продуктовая платформа исполнителей в Яндекс Go. Рассказ был про приложение Яндекс Про, которое родилось из приложения для таксистов, в котором водитель принимал заказ. В ковид интенсивно пошла Яндекс-доставка и Яндекс Еда и было решено использовать для курьеров доработанное приложение. Все делали быстро, и в целом оно работало, но появился ряд проблем
* Фейковые сущности. Например, ровер на велосипеде, фейковые машины и водительские удостоверения для пеших курьеров.
* Не все сервисы из коробки понимали расширения: на заказ такси приезжает велокурьер, или в чеки заказа таксиста попадают чеки курьеров.
* Сильная функциональная связность. Например, от профиля водителя-курьера все зависит. При этом профиль используется в критических точках.
* Множество интерфейсов сервиса с нюансами. Например, смена водительского удостоверения для водителя такси и для курьера доставки.
* При увеличении трафика от сторонних сервисов возникает вопрос - а кто платит за масштабирование.
* Стабильность. Если проводим учения - ломаются все сервисы, и это усложнение процесса.
* Любая ошибка, случайный скрипт может поломать соседний сервис, потому что не учитывает особенности.

Поэтому была идея сделать реинжиниринг. Они посмотрели на опыт Uber, который проходил аналогичные проблемы в 2018, и их решение - domain oriented microservice architecture: разложить сервисы по доменам, и дальше разлить домены по слоям. Слои Presentation - Product - Business platform - Microservice infrastructure - Low-level infrastructure. Если взглянуть через эту схему, то получается что они развивали слой Product, смешивая в одних сервисах много продуктов, вместо того, чтобы выделить общие части в слое Business platform и над ними - настройки с точками кастомизации. И они пошли этим путем, но постепенно, то что работает, пока оставлено. Первый шаг был с Яндекс-маркетом, были выделены сервисы профилей пользователей и авторизация, при этом профили имеют кастомизацию для разных продуктов. Workflow выполнения задачи пока обобщить не получается, там различается набор статусов и логика, при этом часть статусов может приходить от сервиса. Хотя лично я не очень понимаю, в чем проблема. Может, там бизнес-логика местами сильно повторяется, а местами - наоборот, различается, и хочется больше повторного использования, и требуется сильная реструктуризация кода (но это - чисто моя гипотеза).

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

#highload Андрей Комягин из STM Labs. Квест по синхронизации аналитического и оперативного хранилищ в реальном времени без потерь, когда у тебя сотни терабайт данных. Рассказ о том, как выносили отдельно аналитическое хранилище и налаживали перегрузку в него оперативных данных. Логистика, трекинг движения товаров. Оперативные системы - на MongoDB. И первоначально аналитические запросы и отчеты писали прямо на ней. Смесь OLAP и OLTP нагрузку держала плохо, с заказчиком договорились про отдельное аналитическое хранилище. А в него надо перегружать.

Начали с ETL, помучались с ними, потому что ориентировались на бизнес-дату операции, а не на реальную дату изменения, и не видели удаления, поэтому перегрузка была с ошибками, данные сверялись, расползались и перегружались вручную. Поэтому решили сделать на CDC, у Mongo это oplog, есть API MongoDB Change Stream и есть готовый Mongo Connector, который позволяет читать CDC и писать в Kafka. Они Mongo Connector, потому что он дает много функционала из коробки, в докладе было много подробностей настройки.За Kafka стоит CDC processing, который делает преобразования и пишет в Kafka потребителям, которые забирают online и пишет в аналитическую MongoDB. Сделана дополнительная штука для ручных перегрузок - необходимость не пропала, но их можно сделать технологично, перечитав СDС с заданного места.

Вслед за #highload - #teamlead. Богдан Гаркушин. Эволюция управления в зависимости от размера команды и масштаба проекта. Интересный доклад про управления командами от 2 до 40 человек. Про большие он тоже говорил, но сослался, что нет опыта руководства, только наблюдение. А вот на начальном этапе - интересная эволюция того, как меняется управление по мере роста команды. Про привязку решений к конкретному числу людей можно поспорить, ко пункты - важны.
* Внушить, вновь приходящим, которые говорят, что надо все переделать и именно они знают, что нужно пользователю, что команда - тоже пользователь и именно от работы на команду ты получаешь зарплат. Но про пользователя тоже не забывать.
* Будут приходить с доп.задачами - чтобы отвлекался максимум один, а лучше решать силами смежных команд. Но я бы тут дополнил, что не надо превращать задачи в пинг-понг на смежников, это аукнется.
* С 5 человек должна быть полноценная замена. Ему - операционку, вам - развитие. Страх - а вдруг он займет ваше место - лишний, да, человек займет, а вы пойдете дальше. И далее надо поделить: 5 человек ведут основной поток, core-часть, а вы с 2-3 - делаете перспективные проекты. Вы руководите меньше частью команды.
* Команда 12-17 человек еще остается цельной, но появляются уже отдельно продукт и проджект с разными фокусами управления, делим Discovery и Delivery. Меньшая часть - discovery, product, а большая часть delivery, project. Важно их разделить. Очень большой соблазн, когда product вмешивается в текучку project. И задачами в Jira должен управлять project, чтобы не ломалось планирование. В докладе было жестче - ставить, но это вопрос workflow, буфер будущих работ можно формироdать, важен момент запуска.
* А потом команды делятся. Важно, чтобы команды были самостоятельными рабочими единицами, которые должны запускать функционал. Нанимать продуктов и проджектов: человек, который умеет работать с аудиторией и человек, который умеет вести проекты технологично. Надо сохранить эффективность, а она зависит не только от вас, но и от тимлидов: они должны подруливать там, где ты не рулишь. Схема - матричная, есть продукты и есть лиды front-back и другие.

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

Инструменты:
* Цели - горизонт год, называться моет по-разному, например, инициативы. Изменение некоторого параметра
* Роадмап - способ достижения цели
* Проекты/фичи - Это то, чем идем по роадмапу. Scrum или Kanban - не важно.
* Daily/Weekly - единственный плюс от стендапа - чтобы собирались к 12 на работе, остальное - через чатики. А вот еженедельно - надо. Фокусировка, проблемы, обратная связь что делает. Каждый пишет мини-отчет - это дает взаимную ответственность.

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

Про удаленку. Для некоторых команда - семья, работа в офисе - способ получить общение. Надо кому-то удаленка - хорошо, кому-то - нет, учитывайте это, не ориентируйтесь только на себя.