Всем привет! Павел Ступко, которого я знаю достаточно долго, проводит вебинар на интересную тему. Он и его коллеги используют при внедрении 1С практики бирюзовых организаций. И Павел хочет поделиться этим опытом на бесплатном вебинаре завтра 25.05 в 16:00 https://sites.google.com/iteal.expert/vebinar-25-05 Думаю, будет интересно.

Проходя учебник по курсу онтологики Школы системного менеджмента Анатолия Левенчука, вспомнил альтернативные базовые (foundation) онтологии, которые мне рассказывали давным-давно на курсе философии в МФТИ и о которых читал в разных книгах. И мне показалось интересным написать о них https://mtsepkov.org/AltFndOntology А вам, возможно, любопытно будет почитать.

В своей работе часто вижу, как налаживание реальных бизнес-процессов подменяют налаживанием процессов согласования документов. А ведь это – симуляция: цель бизнес-процесса – технологичное создание ценности, а согласование внутреннего документа ценности не несет, а наоборот, замедляет процесс ее создания. Проблема распространенная, и потому написал об этом отдельную статью https://vc.ru/hr/716180 Потому что в организациях часто уверены, что хотя их конкретный процесс имеет недостатки, в целом процесс согласования документов – штука нужная и правильная.

#lafest Сегодня на ЛАФ-2023, это интересная и содержательная конференция. Первый доклад Сергей Нужненко. Занимательная картография и археология для аналитиков. По системам часто нет документов или громадное количество доков с инкрементом без целостного описания. Это может быть и с легаси, и с относительно свежей системой - пара студентов за год могут очень многое написать. И получается змея, кусающая хвост: бизнес спрашивает у аналитиков, аналитики - у бизнеса. Реверс за 10% затрат для системы которую 6-10 человек писали 10 лет - не реалистичен. Надо уметь понять существующее относительно дешево. Как сделать обрывочную, неточную, но полезную карту. Часто именно такую задачу ставят аналитикам. Об этом - доклад, это и есть картография и археология. Проблема типична, потому что постоянная актуализация - она тяжелая.

Что нам надо картировать, описывает V-модель, к которой сейчас наверху надо достроить бизнесовую часть. И дальше был краткий рассказ про карты, которые прижились.
* Короткая бизнес-модель
* Карта деятельности: CJM + Service, BluePrint, Карта процессов; Value stream maping. B все это - на встречах
* Карта пользователей историй Story map
* Карта системного ландшафта - потоки данных
* Карты систем: функциональная; информационная; развертывания доступа и обслуживания -- это архитектура

Бизнес-модель схематезирована по Остервальдеру, хотя Сергей на него не ссылалася.
* Какую ценность несем, кому несем, в каких юридических отношениях мы с ними находимся.
* Клиентский путь: узнать, пройти воронку продаж, подключиться (попал в систему) - дает доходы
* Кто помогает нам: тоже юридические отношения - дает расходы

Карты деятельности: Карта процессов и Цепочка прибавленной стоимости; Customet Journey Map + Service BluePrint - что за сценой.

Из CJM получается Story map. Есть еще Impact Mapping: цели, деятельность. Но на ней можно потерять важное.

Раньше аналитик описывал поведение системы в целом, и команде было достаточно для разработки. А сейчас требуется перевести это во взаимодействие сервисов, фронта и бэка. Это DataFlow диаграмма. Что сервис хранит, что он получает, что выдает другим. Форматы, что передается, интерфейсы.

Археология выкопать как сейчас - это будет на мастер-классе.
* Потоки данных между системами
* Контейнерный уровень - отдельно развернутые приложения (сервер, броузер и т.п.). И потоки данных между ними.
* Компоненты.
* Код.
Постепенное погружение по уровням.

Функциональные карты: use case, DFD, User story mapping, Sequence, Robustness...
Информационная карта. Функции меняются, информация живет годами.

Получаем карту с белыми пятнами: здесь копали, здесь не копали. Но она - корректная.

Я отмечу, что тут все равно много получается. Но! Это дешевле, чем полное описание "по старым канонам", и реально можно делать неполно.

#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 в несколько меньшим масштабированием, но большей управляемостью, она платная.