Текущая версия на 16:37, 3 января 2021

Вспоминая прошедший год, обнаружил, что забыл перенести в блог посты с конференции ArchDays. Конференция получилась интересной. ScrumTrek, пользуясь своими связями вытащил архитекторов рассказать про работу с архитектурой во многих крутых компаниях, причем не только российских. И не только на уровне процессов, но и на техническом, что лично мне было интересно, я больше ходил именно на технические доклады. Моим личным открытием был доклад Ильи Волынкина об получении поведенческой аналитики по сотрудникам через анализ переписки в таск-трекере, мессенджерах и других источниках с использованием AI и ML — вовлеченность, выгорание, неформальные лидеры, узкие места, точки роста.

Сам я выступал с докладом Модели приложения для разных парадигм программирования, развивая свои предыдущие доклады этой осени. Доклад технический, и это оказалось неожиданностью для некоторых участников — в Agile-сообществе я больше известен как специалист по Agile-методам, а не по технической архитектуре. Кстати, ArchDays самая первая опубликовала видео моего доклада наряду с другими на своем Youtube-канале.

А пока — обзор выступлений.

Александр Бындю. Скрытые расходы при переходе на микросервисы

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

Дальше было про технические особенности. Тотально логировать вызовы микросервисов друг из друга. Надо восстанавливать требуемую скорость ответов под нагрузкой для каждого сервиса — внутри монолита мы имеем только интегральную скорость отклика, а тут надо знать показатели по микросервисами и вести мониторинг. Стабильная система, fault tolerance: разработчики должны уметь вкладывать, тестировщики — тестировать. Реорганизация команд под микросервисы. Организация репозитория: монорепо где все, или репозиторий под продукт, или отдельно под каждый микросервис. Это — вопрос выбора, отдельный. У каждого есть свои плюсы и минусы. Если отдельные — то как шарить код и брать пакеты.

И надо учитывать, что монолит и новая микросервисная система долго живут вместе. Минимум 6-8 месяцев. Поэтому нужна совместимость в обе стороны. Включая ситуации, что надо вернуться в монолит.

Филипп Уваров. Краткая история Event Delivery в Spotify

Пост на FB Филипп Уваров. Краткая история Event Delivery в Spotify. Это рассказ о реинжиниринге сервиса логгирования эвентов для дальнейшей аналитики. Логирование событий — общая инфраструктура, для 1500+ микросервисов от 280 команд разработки. Более 1.5 трлн/сутки, 8 млн/сек. Инфраструктура существовала 10 лет, накопились проблемы. Они успешно переписали, был технический рассказ.

События:

• Clickstream — прокрутка экрана и т. п. Полное логирование
• События АБ тестирования — при запуске тебя кидают в группу тестирования.
• Монетарные события. Отслеживать, сколько раз проиграли песню, чтобы платить деньги исполнителям.

Старая архитектура.

• Логирование запросов: сервис пишет в syslog, демон читает и отправляет в event receiver — анонимизация — BigQuery+GCS
• C мобилок — в access point, и там проплиетарный протокол, потому что когда spotify начинался, http не вывозил музыкальный стриминг по скорости.

Проблемы

• Запись на диск — скорость записи в syslog.
• Масштабирование. Куча инстансов на наплыв трафика, трафик упал — мы не можем снести, потмоу что события лежат на диске.
• Нет типизации событий. Только строки, формат tsv — проблемы с качеством данных
• Низкое качество метаданных. Андроид и iPhone — есть набор полей, который хотят видеть, но не класть в тело (timestamp, installation id, модель телефона и т. п. — инфраструктурная информация). Все работает с мобильных устройств — там все есть. А тут мы хотим писать с браузера. Что такое installation id? А еще появляются колонки и девайсы с музыкой — там совсем тяжело. Например, размер экрана — что там. Итого пустые поля или странно заполненные.
• Сложность поддержки событий.
  • Схема, описание события
  • Какой команде принадлежит событие? Некоторая аналитика требует прохода по многим датасетам, и для этого надо знать расшифровку события
  • Как событие доставлять инфраструктурной команде? Дедупликация события, например, like event — чтобы однократно приходил ваш лайк. Для правильного обучения сетки предпочтений. Важна не для всех
  • Партиции событий. Как мы хотим потреблять — за час, за день, непрерывный стриминг.
  • SLO — service level objective. Если что-то не так, надо реагировать сейчас, в 4 ночи, или ждет рабочего дня? События like может подождать, а деньги надо чинить немедленно
  • В старой пардигме жило в разных местах: схема отдельно, конфиг в другом, SLO в админке

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

Первое — сделали типы. Каждой платформе сделали отдельный sdk. До этого было две: для мобилок и для остального. И это позволили сделать ориентированную на платформу систему типов. Protobuf. Для мобильных http

Конфигурация одним файлом. Yaml.

• Схема как набор полей: имя + описание + тип (простые + map и array) + индекс (для protobuf, версия описания)
• Кому принадлежит событие,
• Приоритет доставки (low/normal/high = 72/24/7 часов на fix),
• state enable
• environment — с какой платформы событие уходит. Включение дополнительных полей для платформы.

Низкое качество metadata. Тоже решается в Yaml — environment. А еще — минимализм метаданных, только то, что точно полезно для всех, а не для одного кейса.

Конфиг для доставки. Делают jar в artifactory. Клиенты могут его использовать. Мобильные клиенты — репозиторий как git submodule. И генерация кода по yaml-файлу для каждой платформы, в зависимости от ее кода. Для всяких экзотических клиенты, типа rust или php — просто пакуют файлы, и дальше можете разбираться сами. При этом Protobuf — есть под ВСЕ платформы.

Как поддержать 8 млн запросов в секунду? За счет облака Google, используем их решения. Облако это обеспечивает — контейнирезация, автоскейлинг. Не сосредотачиваемся на том, что можно обеспечить внешними средствами.

Дизайн новой системы.

• В центре — event receiver service — он принимает события по protobuf. Конвертирует в avro — бинарный формат от апача для хорошего хранения данных и использования, в частности scala.
• Дальше pub sub топик
• анонимизация, дедубликация, convertasion
• BigQuery GCS

Конвертация в avro — меняется автоматически по каждому merge

Им как команде надо отлаживаться, в том числе считать потери событий. У каждого события в протоколе есть secviceid и seqid и др., сервер дает ответы, и только по квитанции кидается локально — мы видим потери, смотрим баги. При дедубликации эта часть записывается во внутреннюю BigQuery GCS команды, а в чистый отправляется с дедубликацией, очищенные.

Что получилось классно

• Конфиг Yaml вместо простой схемы события. Он — шире простой схемы событий, расширяемое. Например, через него можно добавить стриминг
• Разделение данных на внутренние и клиентские форматы. Защита от misinterpretation клиентской аналитики
• минималистичный дизайн метадаты

А что — не очень

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

События за 10 лет — лежат в датасетах. Это — просто. А есть еще старые клиенты, например, старые колонки — они никогда не обновляются. А андроиде люди примерно год переходят на новые версию. Для них надо сделать форвардинг в новый формат, это делает отдельная инфораструктура. И это — сложно.

Добавление полей — хорошо. А вот смена типизации, например long -> string. ОБсуждают, либо старые данные нельзя использовать, либо добавляем новое поле.

В вопросах: зачем конфиг? Может protobuf и custom options? Просто у них не везде protobuf, jscript и web — просто json. Поэтому yaml развязывает проблему.

Илья Волынкин. Как сделать SaaS для анализа переписки, который не страшно использовать

Пост на FB Илья Волынкин. Как сделать SaaS для анализа переписки, который не страшно использовать. Обалдеть! Стартап Yva.ai поведенческой аналитики на основе AI и ML. Исходные данные — из корпоративной коммуникации: почта, таск-трекеры, комменты в коде, мессенджеры и так далее. На ее основе еще делают активную аналитику — таргетированные опросы для каждого человека, а не общие. В режиме реального времени, реалтайм анализ группы людей — вовлеченность, выгорание, неформальные лидеры, узкие места, точки роста.

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

Дальше была история развития проекта. И там был очень интересный момент: оказывается, одна из сложных задач — удержать решение как поставку информации для принятия конечных решений человека, объяснить клиентам, то технологии AI и ML принципиально могут ошибаться. Клиенты часто хотят переложить решение на машину, мир черного зеркала и матрицы с захватом власти машинами почему-то кажется им привлекательным.

Да, начиналось это все в Abbyy, а потом вышло в отдельный проект.

Denis Salnikov. Architecture follows structure: 4 истории из жизни европейских стартапов

Пост на FB Denis Salnikov. Architecture follows structure: 4 истории из жизни европейских стартапов. Я пришел не с начала, на вторую историю. Она интересна. Монолит делала аутсорсиновая компания, и в какой-то момент решили из монолита выносить микросервисы. В результате каждый из разработчиков начал делать свой собственный микросервис, как-то выпиливая его из монолита. Как ему нравится. Выпилили 30+ микросервисов, которые покрыли всего 10 % монолита. Эту конструкцию обнаружили, сочли неправильной. И попробовали привести в порядок жесткими методами, через назначение архитекторов. И столкнулись с тем, что при аутстаффе жесткие методы не работают: разработчики просто начали менять проект. И пришлось действовать иначе. Наняли хорошего техлида, который начал работать с разработчиками, убеждать их объединять микросервисы, выносить их по плану, держать целостную архитектуру. В целом получилось, хотя финал истории спикер не застал.

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

Четвертая история, по сути тоже про закон Конвея — это на мой взгляд. Был монолит, финансовый продукт, 70к клиентов, 10 команд, монолит с логическими блоками. Департаменты — фронт, бэк, тестировщики, мобильная разработка. Регресс шет вручную два дня, требовал codefreeze и там был долгий и сложный процесс планирования и согласования релизов. А еще — все падало, там был реально монолит, когда изменения сайта могли положить core-функционал. А поскольку куча клиентов в ЮВА, а сервис в Берлине, то чинить это все приходилось в 4 ночи.

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

Евгений Истомин. Психбольница в руках архитекторов

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

На мой взгляд, основное сообщение доклада было в попытке поменять мышление технарей, которые в зале. Потому что технари топят за технику, и у них «все хорошо» — техника развивается. А думать надо про мир, про его социальную систему. Ведь тренд диджитал — как раз о том, что техника, IT-системы сольются с бизнесовыми и социальными, и потому мир будет таким, которыми мы его сделаем. Сделаем удобным и социально-ориентированным — будет таким, сделаем жестким и механическим — будет таким. Проблема в том, что IT-шники, которые этот мир фактически делают — не думают об этом, они принимают технические решения как им удобно. Ну и с большой вероятностью результат будет таким, как были UI до появления специализаций UI-Usability-UX, пока их делали разработчики. Поэтому и коннотации идут на книгу «Психбольница в руках пациентов», которая поставила этот вопрос.

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

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

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