Блог компании учи.ру

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

Меня зовут Роман Литвинов, я разработчик в команде Учи.ру. Хочу вам рассказать именно о такой истории из практики и о нашем сервисе под названием Butler, о дворецком, через которого проходит каждый пользователь, прежде чем зайти на платформу.

Итак, овсянка, сэр.

По мере роста популярности платформы система аутентификации перестала соответствовать нашим требованиям, как и некоторые другие части нашей архитектуры. Когда весной 2020 года в базе Учи.ру стало больше 11 млн активных пользователей (8 млн учеников, примерно 350 тыс. учителей и около 3,5 млн родителей), существующая реализация стала медленной, непрозрачной и потребляла слишком много памяти. Мы решили ее обновить.

Поставили перед собой следующие цели:

• повысить производительность;

• внедрить новые технологии защиты учетных данных;

• выделить аутентификацию из монолита в микросервис;

• подключить мобильное приложение.

При этом хотелось иметь возможность поддерживать функции, которые до этого не реализовывались.

В список новых функций попали:

• принудительное отключение пользователя;

• блокировка аккаунта;

• верификация;

• шифрование паролей учеников;

• поддержка jwt-токенов и двухфакторной аутентификации;

• интеграция с социальными сетями;

• обеспечение единой точки входа для множества сервисов с защитой от брутинга.

Сложности работы с таблицами. Роли пользователей

Долгая аутентификация

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

Проблема уникальности почты и логина

Если родитель одновременно является учителем и хочет зарегистрироваться на Учи.ру, он должен завести две учетные записи. Это значит, что его e-mail будет числиться в двух разных таблицах. Та же история может происходить, если один человек является и сотрудником, и родителем или и сотрудником, и учителем и т. д. Если e-mail один, то сложно определить, какого именно пользователя нужно аутентифицировать.

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

Теперь мы используем Butler

Чтобы исправить ситуацию, мы решили вынести аутентификацию в отдельный сервис. Для этого был создан Butler. Саму аутентификацию было решено проводить на базе открытой библиотеки Ruby под названием rodauth. Ее, конечно, пришлось немного доработать, но в целом решение подходило. Параллельно с улучшением своего продукта мы внесли небольшой вклад в развитие open source-сообщества.

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

Всех пользователей перенесли из нескольких таблиц в единую базу данных. Принадлежность к разным таблицам в прошлом позволила определить роли и записать их в отдельный столбец.

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

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

Небольшой тюнинг решения

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

К тому же у подразделения мобильной разработки был запрос сделать пару токенов с временем жизни в 14 дней, потому что от пользователя на мобильном устройстве скрыты реквизиты доступа (процесс логина происходит сложнее). Да и с одного смартфона, как правило, в систему заходит один и тот же человек. А у детей младшего возраста иногда бывают сложности со входом.

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

Обновление камень преткновения

Обновлять исходный код open-source компонента нужно аккуратно, потому что в открытых проектах вопросы обратной совместимости не всегда оказываются решены полностью. Так, нам нужно было установить обновление, которое требовалось для внедрения очередной фичи. Но с этим обновлением возникал обязательный параметр связи между access-токеном и refresh-токеном. Раньше он был необязательным и от нашего внимания ускользнул. Это значит, что все выданные токены перестали бы работать разом, если бы мы накатили это обновление. То есть, если бы мы сразу обновили всю систему, это привело бы к сбросу всех активных сессий.

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

Криптография и защита от брутинга

Хранить логины и пароли в новой базе данных было решено в зашифрованном виде. Тогда дополнительным тормозом стал один из наиболее используемых алгоритмов в экосистеме Ruby BCrypt.

Его реализация на Ruby отнимала слишком много процессорного времени, затрачивая 250 мс на создание хеша со стандартным костом, равным 12. Зачастую подобную операцию необходимо проводить дважды в течение цикла вопрос-ответ, поскольку требуется проверка на использование этого же пароля пользователем прежде. Вкупе со множественным использованием колбеков в монолите ситуация стала приводить к большому времени ожидания внутри транзакций БД (idle in transaction), что начало сказываться на производительности системы. На этих самых колбеках висело слишком много бизнес-логики, что не позволило свести проблему к простому рефакторингу.

Выходом из положения стала смена алгоритма шифрования на более гибкий, который поддерживает конфигурацию как по затрачиваемой памяти, так и временному ресурсу. Мы взяли открытый алгоритм Argon2 и постепенно мигрировали пользователей с одного на второй, благо в rodauth имелись зачатки функционала для осуществления плавного перехода. Для этого потребовалось внести изменения в саму библиотеку rodauth. К счастью, Jeremy Evans ее автор оказался очень открытым человеком, пошел нам навстречу.

В сервисе rodauth также нашлось встроенное решение по защите от брутинга паролей. После определенного количества попыток аккаунт блокируется на некоторое время. Разблокировку можно провести за счет подтверждения через e-mail или вручную.

Перенос аккаунтов

Данные о пользователях были разнесены по нескольким таблицам для каждой роли. Их все потребовалось уместить в одну базу данных, чтобы гарантировать уникальность логина (будь то почта или телефон), а также упростить процесс выбора нужной записи.

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

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

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

Результаты

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

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

Меня зовут Денис Власов, я Data Scientist в Учи.ру. С помощью моделей машинного обучения из записей онлайн-уроков мы сделали гифки последовательность из нескольких кадров с наиболее яркими эмоциями учеников. Эти гифки получили их родители в e-mail-рассылке. Вместе с Data Scientist @DariaV Дашей Васюковой расскажем, как без экспертизы в Computer Vision, а только с помощью открытых библиотек и готовых моделей сделать MVP, в основе которого лежат low-res видео. В конце бонус виджет для быстрой разметки кадров.

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

Если у вас, как и у нас, не стоит задача RealTime определения эмоций, можно пойти простым способом: анализировать записи уроков.

Маркеры начала и конца урока

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

Для этого мы соотнесли записи с камер учеников и учителей. Учительские видео помогли обозначить период урока: он начинается, когда включены обе камеры одновременно, и заканчивается, когда хотя бы одна камера отключается совсем.

Разбили видео на кадры

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

Научились детектировать детские улыбки (и не только)

На каждом кадре необходимо обнаружить лицо. Если оно там есть, проверить, родитель это или ученик, а также оценить эмоции на лице. И тут возникло несколько нюансов, которые пришлось учитывать.

Проблема 1. Распознавать лица на картинках низкого качества сложнее

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

Стандартный детектор DNN Face Detector из библиотеки OpenCV, который мы сначала взяли за основу, на наших данных давал неточные результаты. Оказалось, что алгоритм недостаточно хорошо справляется с реальными кадрами из видеочатов: иногда пропускает лица, которые явно есть в кадре, из двух лиц находил только одно или определял лица там, где их нет.

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

Размечали итеративно: после добавления новой порции размеченных кадров мы заново обучали модель. А после проверки ее работы сохраняли разметку для новых кадров, наращивая обучающую выборку. Всего мы разметили 2624 кадра из 388 видеозаписей, на которых в сумме было 3325 лиц.

Таким образом удалось обучить более чувствительный в наших условиях детектор. В валидационной выборке из 140 кадров старый детектор нашел 150 лиц, а пропустил 38. Новый же пропустил только 5, а 183 обнаружил верно.

Проблема 2. В кадре присутствует не только ребенок

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

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

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

• возраст людей на кадре с низким разрешением становится неочевидным;

• дети присутствуют в кадре практически весь урок, а взрослые минуты.

В процессе разметки мы заметили, что очень часто родитель присутствует на уроке плечом или локтем. Так мы назвали тип кадров, когда камера направлена на ученика, но видно, что рядом сидит родитель. Обычно на таких уроках видно плечо сидящего рядом взрослого или только локоть.

Вторая модель должна была находить именно такие родительские плечи. Очевидно, что в этой задаче детектор лиц не применим, поэтому надо обучаться на кадрах целиком. Конечно, таких датасетов мы не нашли в публичном доступе и разметили около 250 000 кадров, на которых есть часть родителя, и кадры без них. Разметки на порядок больше, чем в других задачах, потому что размечать гораздо легче: можно смотреть не отдельные кадры, а отрезки видео и в несколько кликов отмечать, например, что вот эти 15 минут (900 кадров!) родитель присутствовал.

На дашборде урока с аналитикой доступны графики присутствия родителями по мнению обеих моделей. Они помогают понять, когда родитель просто интересуется процессом урока, а когда скорее общается с преподавателем.

Проблема 3. Дети улыбаются по-разному

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

За основу классификатора настроения мы взяли предобученную модель ResNet34 из библиотеки fast.ai. Эту же библиотеку использовали для дообучения модели в два этапа: сначала на публичных датасетах facial_expressions и SMILEsmileD с веселыми и нейтральными лицами, потом на нашем размеченном вручную датасете с кадрами с камер учеников. Публичные датасеты решили включить, чтобы расширить размер выборки и помочь модели более качественными изображениями, чем кадры видео с планшетов и веб-камер наших учеников.

Размечали с помощью кастомного виджета. Все изображения подвергались одной и той же процедуре предобработки:

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

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

3. Аугментация. Позволяет в разы увеличить эффективный размер выборки и учесть особенности данных.

4. Нормализация цветов с помощью CLAHE normalizer из библиотеки OpenCV. По ощущениям, такая нормализация лучше других вытягивает контраст на пересвеченных или темных изображениях.

Дообучаем модель для распознавания улыбок

1. Аугментации

При дообучении мы использовали достаточно жесткие аугментации:

• Отражали изображение по горизонтали.

• Поворачивали на случайную величину.

• Применяли три разных искажения для изменения контраста и яркости.

• Брали не всю картинку, а квадрат, составляющий не менее 60% от площади исходного изображения.

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

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

# ! pip freeze | grep fastai# fastai==1.0.44import fastaiimport matplotlib.pyplot as pltfrom matplotlib import cmfrom matplotlib import colorsimport seaborn as sns%matplotlib inlinefrom pylab import rcParamsplt.style.use('seaborn-talk')rcParams['figure.figsize'] = 12, 6path = 'facial_expressions/images/'def _side_cutoff(    x,    cutoff_prob=0.25,    cutoff_intensity=(0.1, 0.25)):    if np.random.uniform() > cutoff_prob:        return x    # height and width    h, w = x.shape[1:]    h_cutoff = np.random.randint(        int(cutoff_intensity[0]*h), int(cutoff_intensity[1]*h)    )    w_cutoff = np.random.randint(        int(cutoff_intensity[0]*w), int(cutoff_intensity[1]*w)    )        cutoff_side = np.random.choice(        range(4),        p=[.34, .34, .16, .16]    ) # top, bottom, left, right.    if cutoff_side == 0:        x[:, :h_cutoff, :] = 0    elif cutoff_side == 1:        x[:, h-h_cutoff:, :] = 0    elif cutoff_side == 2:        x[:, :, :w_cutoff] = 0    elif cutoff_side == 3:        x[:, :, w-w_cutoff:] = 0    return x# side cutoff goes frist.side_cutoff = fastai.vision.TfmPixel(_side_cutoff, order=99)augmentations = fastai.vision.get_transforms(    do_flip=True,    flip_vert=False,    max_rotate=25.0,    max_zoom=1.25,    max_lighting=0.5,    max_warp=0.0,    p_affine=0.5,    p_lighting=0.5,        xtra_tfms = [side_cutoff()])def get_example():    return fastai.vision.open_image(        path+'George_W_Bush_0016.jpg',    )def plots_f(rows, cols, width, height, **kwargs):    [        get_example()        .apply_tfms(            augmentations[0], **kwargs        ).show(ax=ax)        for i,ax in enumerate(            plt.subplots(                rows,                cols,                figsize=(width,height)            )[1].flatten())    ]plots_f(3, 5, 15, 9, size=size)

2. Нормализация цвета

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

# pip freeze | grep opencv# > opencv-python==4.5.2.52import cv2import matplotlib.pyplot as pltfrom matplotlib import cmfrom matplotlib import colorsimport seaborn as sns%matplotlib inlinefrom pylab import rcParamsplt.style.use('seaborn-talk')rcParams['figure.figsize'] = 12, 6path = 'facial_expressions/images/'imgs = [    'Guillermo_Coria_0021.jpg',    'Roger_Federer_0012.jpg',]imgs = list(    map(        lambda x: path+x, imgs    ))clahe = cv2.createCLAHE(    clipLimit=2.0,    tileGridSize=(4, 4))rows_cnt = len(imgs)cols_cnt = 4imsize = 3fig, ax = plt.subplots(    rows_cnt, cols_cnt,    figsize=(cols_cnt*imsize, rows_cnt*imsize))for row_num, f in enumerate(imgs):    img = cv2.imread(f)    col_num = 0        img = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)    ax[row_num, col_num].imshow(img, cmap='gray')    ax[row_num, col_num].set_title('bw', fontsize=14)    col_num += 1    img_normed = cv2.normalize(        img,        None,        alpha=0,        beta=1,        norm_type=cv2.NORM_MINMAX,        dtype=cv2.CV_32F    )    ax[row_num, col_num].imshow(img_normed, cmap='gray')    ax[row_num, col_num].set_title('bw normalize', fontsize=14)    col_num += 1        img_hist_normed = cv2.equalizeHist(img)    ax[row_num, col_num].imshow(img_hist_normed, cmap='gray')    ax[row_num, col_num].set_title('bw equalizeHist', fontsize=14)    col_num += 1        img_clahe = clahe.apply(img)    ax[row_num, col_num].imshow(img_clahe, cmap='gray')    ax[row_num, col_num].set_title('bw clahe_norm', fontsize=14)    col_num += 1        for col in ax[row_num]:        col.set_xticks([])        col.set_yticks([])plt.show()

В итоге мы получили модель, способную отличить улыбку от нейтрального выражения лица в с качеством 0.93 по метрике ROC AUC. Иными словами, если взять из выборки по случайному кадру с улыбкой и без, то с вероятностью 93% модель присвоит большую вероятность улыбки кадру с улыбающимся лицом. Этот показатель мы использовали для сравнения разных вариантов дообучения и пайплайнов. Но интуитивно кажется, что это достаточно высокий уровень точности: даже человек не всегда может определить эмоцию на лице другого человека. К тому же в реальности существует гораздо больше выражений лиц кроме однозначной радости и однозначной печали.

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

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

3. Увеличение объема выборки

На этом этапе у нас было около 5400 размеченных кадров, нам хотелось понять: достаточно ли такого объема для обучения. Мы разделили кадры на две подвыборки: половина для оценки качества (валидация), другая для обучения (трейн). Каждая группа состояла из кадров с разными учениками: если бы одни и те же лица попали в разные выборки, результаты оценки качества были бы завышены.

Мы несколько раз дообучили модель на публичных датасетах и подвыборках разного размера из трейна и проверили качество на валидационной выборке. На графике видно, что качество растет по мере увеличения объема подвыборки, поэтому мы разметили дополнительно еще 3 тыс. кадров: финальную модель обучали на выборке из 8500 кадров. Скорее всего и при таком объеме данных качество еще не начало выходить на плато, но перепроверять это мы не стали.

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

4. Картинки Google для обогащения выборки

Мы пробовали спарсить первые 1000 результатов картинок по запросам в духе happy, unhappy, smiling, neutral и т. д. Не ожидали получить данные высокого качества, поэтому планировали потом просмотреть их глазами и удалить совсем неподходящие. В итоге мы быстро поняли, что никакая фильтрация эти картинки не спасет, поэтому отказались от этой идеи совсем.

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

• есть ли в кадре лицо;

• с какой вероятностью этот человек улыбается;

• ребенок это или взрослый;

• есть ли в кадре взрослый, даже если мы не нашли лица.

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

Собрали гифку

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

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

Что мы в итоге получили?

Исследование и эксперимент показали, что можно быстро и без глубокой экспертизы в Computer Vision научиться различать пользователей и их эмоции по видео (даже если оно плохого качества) на основе открытых библиотек и моделей.

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

Например, можно посмотреть количество отключений, которые происходили в процессе урока. Подобную информацию можно использовать, чтобы рекомендовать учителю или ученику более стабильное подключение.

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

Виджеты

Все данные мы размечали сами и делали это довольно быстро (примерно 100 кадров в минуту). В этом нам помогали самописные виджеты:

1. Виджет для разметки кадров с улыбками.

2. Виджет для разметки кадров с детьми и взрослыми.

3. Виджет для разметки кадров с плечом или локтем родителя.

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

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

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

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

import pandas as pdimport numpy as npimport datetimeimport randomimport osimport ipywidgets as widgetsfrom IPython.display import displayfrom pathlib import Pathclass BulkLabeler():    def __init__(self, frames_path, annotations_path,                 labels = ['0', '1'],                 predict_fn = None,                 frame_width=120,                 num_frames = 27,                 face_width = 120,                 num_faces = 27,                 myname = '?',                 ):        self.predict_fn = predict_fn        self.labels = labels        self.frames_path = frames_path        self.frame_width = frame_width        self.num_frames = num_frames        self.face_width = face_width        self.num_faces = num_faces        self.myname = myname        self.faces_batch = []                # get annotations        self.annotations_path = annotations_path        processed_videos = []        if annotations_path.exists():            annotations = pd.read_csv(annotations_path)            processed_videos = annotations.file.str.split('/').str[-3].unique()        else:            with open(self.annotations_path, 'w') as f:                f.write('file,label,by,created_at\n')                # get list of videos        self.video_ids = [x for x in os.listdir(frames_path)                           if x not in processed_videos]        random.shuffle(self.video_ids)        self.video_ind = -1                self._make_video_widgets_row()        self._make_frames_row()        self._make_range_slider()        self._make_buttons_row()        self._make_faces_row()        self._make_video_stats_row()                display(widgets.VBox([self.w_video_row,                              self.w_frames_row,                              self.w_slider_row,                              self.w_buttons_row,                              self.w_faces_row,                              self.w_faces_label,                              self.w_video_stats]))        self._on_next_video_click(0)            ### Video name and next video button        def _make_video_widgets_row(self):        # widgets for current video name and "Next video" button        self.w_current_video = widgets.Text(            value='',            description='Current video:',            disabled=False,            layout = widgets.Layout(width='500px')            )                self.w_next_video_button = widgets.Button(            description='Next video',            button_style='info', # 'success', 'info', 'warning', 'danger' or ''            tooltip='Go to the next video',            icon='right-arrow'        )                self.w_video_row = widgets.HBox([self.w_current_video, self.w_next_video_button])                self.w_current_video.observe(self._on_video_change, names='value')        self.w_next_video_button.on_click(self._on_next_video_click)                        def _on_next_video_click(self, _):        while True:            self.video_ind += 1            current_video = self.video_ids[self.video_ind]            if next(os.scandir(self.frames_path/current_video/'student_faces'), None) is not None:                break        self.w_current_video.value = current_video                    def _on_video_change(self, change):        self.video_id = change['new']        self.frame_nums_all = sorted(int(f.replace('.jpg',''))                                      for f in os.listdir(self.frames_path/self.video_id/'student_src'))        start, stop = min(self.frame_nums_all), max(self.frame_nums_all)        self.w_range_slider.min = start        self.w_range_slider.max = stop        step = self.frame_nums_all[1] - self.frame_nums_all[0] if len(self.frame_nums_all)>1 else 1        self.w_range_start.step = step        self.w_range_stop.step = step        # change to slider value will cause frames to be redrawn        self.w_range_slider.value = [start, stop]               # reset faces        self.faces_df = None        self._reset_faces_row()        self.w_video_stats.value = f'Video {self.video_id}  no annotations yet.'                def _close_video_widgets_row(self):        self.w_current_video.close()        self.w_next_video_button.close()        self.w_video_row.close()        ### Video frames box        def _make_frames_row(self):        frame_boxes = []        self.w_back_buttons = {}        self.w_forward_buttons = {}        for i in range(self.num_frames):            back_button = widgets.Button(description='<',layout=widgets.Layout(width='20px',height='20px'))            self.w_back_buttons[back_button] = i            back_button.on_click(self._on_frames_back_click)            label = widgets.Label(str(i+1), layout = widgets.Layout(width=f'{self.frame_width-50}px'))            forward_button = widgets.Button(description='>',layout=widgets.Layout(width='20px',height='20px'))            self.w_forward_buttons[forward_button] = i            forward_button.on_click(self._on_frames_forward_click)            image = widgets.Image(width=f'{self.frame_width}px')            frame_boxes.append(widgets.VBox([widgets.HBox([back_button, label, forward_button]),                                              image]))                    self.w_frames_row = widgets.GridBox(frame_boxes,                                             layout = widgets.Layout(width='100%',                                                                     display='flex',                                                                     flex_flow='row wrap'))            def _on_frames_back_click(self, button):        frame_ind = self.w_back_buttons[button]        frame = int(self.w_frames_row.children[frame_ind].children[0].children[1].value)        start, stop = self.w_range_slider.value        self.w_range_slider.value = [frame, stop]            def _on_frames_forward_click(self, button):        frame_ind = self.w_forward_buttons[button]        frame = int(self.w_frames_row.children[frame_ind].children[0].children[1].value)        start, stop = self.w_range_slider.value        self.w_range_slider.value = [start, frame]            def _close_frames_row(self):        for box in self.w_frames_row.children:            label_row, image = box.children            back, label, forward = label_row.children            image.close()            back.close()            label.close()            forward.close()            box.close()        self.w_frames_row.close()                    ### Frames range slider                        def _make_range_slider(self):        self.w_range_start = widgets.BoundedIntText(                                        value=0,                                        min=0,                                        max=30000,                                        step=1,                                        description='Frames from:',                                        disabled=False,                                        layout = widgets.Layout(width='240px')                                    )        self.w_range_stop = widgets.BoundedIntText(                                        value=30000,                                        min=0,                                        max=30000,                                        step=1,                                        description='to:',                                        disabled=False,                                        layout = widgets.Layout(width='240px')                                    )        self.w_range_slider = widgets.IntRangeSlider(            value=[0, 30000],            min=0,            max=30000,            step=1,            description='',            disabled=False,            continuous_update=False,            orientation='horizontal',            readout=True,            readout_format='d',            layout=widgets.Layout(width='500px')        )        self.w_range_flip = widgets.Button(description='Flip range',            button_style='', # 'success', 'info', 'warning', 'danger' or ''            tooltip='Invert frames selection',            layout = widgets.Layout(width=f'{self.frame_width}px'),            icon='retweet'                                          )                self.w_range_slider.observe(self._on_slider_change, names='value')        self.w_range_start.observe(self._on_range_start_change, names='value')        self.w_range_stop.observe(self._on_range_stop_change, names='value')        self.w_range_flip.on_click(self._on_range_flip)        self.w_slider_row = widgets.HBox([self.w_range_start,                                          self.w_range_slider,                                          self.w_range_stop,                                          self.w_range_flip])        def _close_range_slider(self):        self.w_range_start.close()        self.w_range_stop.close()        self.w_range_slider.close()        self.w_range_flip.close()        self.w_slider_row.close()            def _on_range_flip(self, _):        start, stop = self.w_range_slider.value        left, right = self.w_range_slider.min, self.w_range_slider.max        if start==left and right==stop:            pass        elif start - left > right - stop:            self.w_range_slider.value=[left, start]        else:            self.w_range_slider.value=[stop, right]                                                   def _on_range_start_change(self, change):        new_start = change['new']        start, stop = self.w_range_slider.value        self.w_range_slider.value = [new_start, stop]                    def _on_range_stop_change(self, change):        new_stop = change['new']        start, stop = self.w_range_slider.value        self.w_range_slider.value = [start, new_stop]                    def _on_slider_change(self, change):        start, stop = change['new']        # update text controls        self.w_range_start.max = stop        self.w_range_start.value = start        self.w_range_stop.min = start        self.w_range_stop.max = self.w_range_slider.max        self.w_range_stop.value = stop        # show frames that fit current selection        frame_nums = [i for i in self.frame_nums_all if i>=start and i<=stop]        N = len(frame_nums)        n = self.num_frames        inds = [int(((N-1)/(n-1))*i) for i in range(n)]        # load new images into image widgets        for ind, box in zip(inds, self.w_frames_row.children):            frame_num = frame_nums[ind]            filename = self.frames_path/self.video_id/'student_src'/f'{frame_num}.jpg'            with open(filename, "rb") as image:                f = image.read()            label, image = box.children            label.children[1].value = str(frame_num)            image.value = f            ### Buttons row        def _make_buttons_row(self):        labels = list(self.labels)        if self.predict_fn is not None:            labels.append('model')        self.w_default_label = widgets.ToggleButtons(options=labels,                                                      value=self.labels[0],                                                      description='Default label:')                self.w_next_batch_button = widgets.Button(description='New batch',            button_style='info', # 'success', 'info', 'warning', 'danger' or ''            tooltip='Show next batch of faces from current frame range',            icon='arrow-right'        )        self.w_save_button = widgets.Button(description='Save labels',            button_style='success', # 'success', 'info', 'warning', 'danger' or ''            tooltip='Save current labels',            icon='check'        )        self.w_buttons_row = widgets.HBox([self.w_default_label, self.w_next_batch_button, self.w_save_button])        self.w_next_batch_button.on_click(self._on_next_batch_click)        self.w_save_button.on_click(self._on_save_labels_click)                def _close_buttons_row(self):        self.w_default_label.close()        self.w_next_batch_button.close()        self.w_save_button.close()        self.w_buttons_row.close()                def _on_next_batch_click(self, _):        if self.faces_df is None:             self._create_faces_df()        # select a sample from faces_df        start, stop = self.w_range_slider.value        subdf = self.faces_df.loc[lambda df: df.frame_num.ge(start)&                                             df.frame_num.le(stop)&                                             df.label.eq('')]        num_faces = min(len(subdf), self.num_faces)                if num_faces == 0:            self.faces_batch = []            self.w_faces_label.value = 'No more unlabeled images in this frames range'            self.w_faces_label.layout.visibility = 'visible'            for box in self.w_faces_row.children:                box.layout.visibility = 'hidden'        else:            self.w_faces_label.layout.visibility = 'hidden'            self.faces_batch = subdf.sample(num_faces).index            # if we have a model then we use it to sort images            if self.predict_fn is not None:                probs, labels = self._predict()                # sort faces according to probability                ind = sorted(range(len(probs)), key=probs.__getitem__)                self.faces_batch = [self.faces_batch[i] for i in ind]                labels = [labels[i] for i in ind]            # create labels for each face            if self.w_default_label.value != 'model':                labels = [self.w_default_label.value]*len(self.faces_batch)            # update faces UI            for facefile, label, box in zip(self.faces_batch, labels, self.w_faces_row.children):                image, buttons = box.children                with open(self.frames_path/facefile, "rb") as im:                    image.value = im.read()                buttons.value = label                box.layout.visibility = 'visible'            if len(self.faces_batch) < len(self.w_faces_row.children):                for box in self.w_faces_row.children[len(self.faces_batch):]:                    box.layout.visibility = 'hidden'        def _predict(self):        probs = []        labels = []        for facefile in self.faces_batch:            prob, label = self.predict_fn(self.frames_path/facefile)            probs.append(prob)            labels.append(label)        self.faces_df.loc[self.faces_batch, 'prob'] = probs        return probs, labels                    def _on_save_labels_click(self, _):        self.w_save_button.description='Saving...'                        with open(self.annotations_path, 'a') as f:            for file, box in zip(self.faces_batch, self.w_faces_row.children):                label = box.children[1].value                self.faces_df.at[file,'label'] = label                print(file, label, self.myname, str(datetime.datetime.now()),sep=',', file=f)                # update current video statistics        stats = self.faces_df.loc[self.faces_df.label.ne(''),'label'].value_counts().sort_index()        stats_str = ', '.join(f'{label}: {count}' for label, count in stats.items())        self.w_video_stats.value = f'Video {self.video_id}  {stats_str}.'                self.w_save_button.description = 'Save labels'        # ask for next batch        self._on_next_batch_click(0)            ### Faces row        def _make_faces_row(self):        face_boxes = []        for i in range(self.num_faces):            image = widgets.Image(width=f'{self.face_width}px')            n = len(self.labels)            toggle_buttons_width = int(((self.face_width-5*(n-1))/n))            toggle_buttons = widgets.ToggleButtons(options=self.labels,                                                    value=self.w_default_label.value,                                                    style=widgets.ToggleButtonsStyle(button_width=f'{toggle_buttons_width}px'))            face_boxes.append(widgets.VBox([image, toggle_buttons]))                    self.w_faces_row = widgets.GridBox(face_boxes,                                            layout = widgets.Layout(width='100%',                                                                    display='flex',                                                                    flex_flow='row wrap'))        self.w_faces_label = widgets.Label()        self._reset_faces_row()            def _close_faces_row(self):        for box in self.w_faces_row.children:            image, buttons = box.children            for w in [image, buttons, box]:                w.close()        self.w_faces_row.close()        self.w_faces_label.close()            def _reset_faces_row(self):        for box in self.w_faces_row.children:            box.layout.visibility = 'hidden'        self.w_faces_label.layout.visibility = 'visible'        self.w_faces_label.value = 'Press "New batch" button to see a new batch of faces'        self.faces_batch = []            ### Video statistics row        def _make_video_stats_row(self):        self.w_video_stats = widgets.Label('No video currently selected')        def _close_video_stats_row(self):        self.w_video_stats.close()                def _create_faces_df(self):        folder = Path(self.video_id,'student_faces')        df = pd.DataFrame({'file':[folder/f for f in os.listdir(self.frames_path/folder)]})        df['frame_num'] = df.file.apply(lambda x: int(x.stem.split('_')[0]))        df['label'] = '' #TODO maybe existing annotations?        df['prob'] = np.nan        df = df.sort_values(by='frame_num').set_index('file')        self.faces_df = df                    def close(self):        self._close_video_widgets_row()        self._close_frames_row()        self._close_range_slider()        self._close_buttons_row()        self._close_faces_row()        self._close_video_stats_row()

За время пандемии работы у разработчиков Учи.ру только прибавилось: по данным SimilarWeb за апрель, платформа стала вторым по популярности образовательным сайтом в мире. А вот сконцентрироваться на ней из дома получается с переменным успехом. Мы проверили на себе самые разные лайфхаки и хотим поделиться результатами. Сегодня разбираемся с одним из самых многообещающих способов музыкой.

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

При опросе коллег мнения разделились: примерно по 40% из них для лучшей концентрации выбирают тишину и любимую музыку. Еще у 15% есть специальные плейлисты или приложения именно на тот случай, когда необходима максимальная сфокусированность. Еще 4% и 3% соответственно слушают белый шум и звуки природы.

Интерес к влиянию музыки на концентрацию породил огромное количество исследований, мифов и коммерческих проектов. Миллионы людей ищут способ борьбы с прокрастинацией в аудио. Одно лишь приложение Endel, которое обещает генерировать звуки для концентрации внимания пользователя, скачали в общей сложности более 2 млн раз. А YouTube-канал ChilledCow с самыми популярными стримами лоу-фай хип-хопа насчитывает уже больше 7 млн подписчиков.

Главный миф музыкальной терапии

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

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

Приятный джаз или тяжелый рок?

Исследователи изучали влияние на продуктивность не только произведений великого австрийского композитора. Так какую же музыку выбрать? Есть ли универсальные рецепты?

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

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

Такие разные виды музыки, как техно, классика и бразильский поп, могут оказывать похожий эффект. Дело в различимой речи: она способствует рассеянности внимания, а ее отсутствие может стать одним из критериев при выборе фона для продуктивного дня (конечно, если вы не знаете португальский язык).

Шум: проблема или решение

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

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

Однако эти исследования показывают и обратную сторону шума. Он снижает показатели интровертов в сравнении с работой в тишине и отвлекает внимательных детей.

Громкий продолжительный шум наносит вред организму этот факт давно изучен и подтвержден опытами. Длительное воздействие шума негативно воздействует на вегетативную и центральную нервные системы: ухудшает психическое состояние и повышает тревожность. С громким шумом на фоне мы устаем быстрее на 1525%, чем обычно. По данным Роспотребнадзора, уровень шума не должен превышать 68 дБ. Для сравнения: в жилых домах мы слышим примерно 40 дБ, в офисах, в которые вернемся нескоро, 5565 дБ. Поэтому так тяжело работать удаленно родителям младенцев: плач ребенка звучит на уровне 7682 дБ.

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

Что слушать

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

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

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

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

My Noise еще одно аудиокафе. Система позволяет смешать звуки прямо в браузере, в отличие от Coffitivity, здесь все делается прямо на первой странице сервиса, без загрузок и регистраций.

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

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

A Soft Murmur еще одна система для индивидуального смешивания фоновых звуков. Можно настроить уменьшение звука до тишины к нужному времени.

Расскажите: вы слушаете музыку во время учебы или работы? Помогает ли это вам?

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

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

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

Шаг 1. Оценить себя

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

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

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

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

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

Шаг 2. Удерживать фокус

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

Поэтому самый главный навык для эффективной учебы (да и работы!) это, пожалуй, управление вниманием. Умение фокусироваться и глубоко погружаться в дело можно тренировать. Поначалу сконцентрироваться будет сложно: постоянно будет возникать желание проверить мессенджер, ленту с мемами, погладить кота.

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

Шаг 3. Поддерживать интерес

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

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

Также необязательно начинать с начала: часто то, с чего принято погружаться в тему, бывает скучным или оторванным от реальности. Я начинаю сразу с интересного, постепенно возвращаюсь к пропущенным урокам.

Шаг 4.1. Учиться на работе

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

Например, при поиске нетривиального решения можно рассказать о нем команде, представить альтернативу и объяснить плюсы и минусы разных подходов.

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

Результаты показали, что точность ответов на вопросы теста была выше у той группы, которая должна была объяснять свои действия во время решения задач: Почему вы выбрали этот метод?, Почему вы считаете, что здесь должно быть число 7? и так далее. Объяснение после теста тоже хорошо сказалось на итогах. Подробнее об этом можно почитать в статье.

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

Шаг 4.2. Учиться вне работы. Когда?

После работы нет сил, а выходные время для семьи и друзей. Когда же учиться? К интересному выводу пришли авторы статьи в журнале Nature. Они провели масштабное исследование онлайн-курсов в области начальной психологии (именно в таком формате сейчас учится большинство людей). Оказалось, что большое влияние на результаты итоговых тестов среди прочего оказала свобода в выборе перерывов между блоками и элементами учебной программы.

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

Расскажите, получается ли у вас постоянно учиться чему-то новому. Как вы решаете проблему прокрастинации и концентрации?

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

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

• Разделение ответственности в ряде случаев ответственность за деплой оказывается высокой.

• Необходимость в дополнительных навыках обычно нужно неплохо знать платформу, через которую происходит деплой, или хотя бы разбираться в скриптах вроде Capistrano.

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

Как это происходит у нас

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

Немного истории

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

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

Да придет спаситель

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

А что делать, если тебе нужно поднять копию среды для тестирования второго релиза? Не создавать же всю связку целиком заново? А если ее незначительно видоизменить? Для подобного в Шамане есть возможность создать шаблон конфигурации, в котором с помощью YAML описана вся россыпь машин, сервисов и эндпоинтов. В результате, если ваша команда поддерживает свой шаблон, поднятие нового инстанса развесистой связки сервисов становится тривиальной задачей.

И, кажется, коллеги со мной согласны:

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

Схема связи Шамана с кодом

На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше Шаман подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?

И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в Шаман чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!

Когда что то идёт не так

Понятное дело, что после выкатки кода на прод надо убедится, что он ведёт себя так, как задумано. И тут у нас чуть хуже с автоматизацией, но тем не менее всё под контролем. Для мониторинга мы используем сервис Sentry, который нотифицирует как о новых индивидуальных ошибках, так и об изменениях общего фона. Ну и продуктовые дашборды с метриками никто не отменял. А Шаман, в свою очередь, быстро и непринужденно позволяет откатить бажную версию фронтового приложения в случае серьезных проблем.

Так нужно ли деплоить разработчику?

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

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

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

• Сервисы приходят и уходят, соответственно, шаблон связки сервисов нужно держать актуальным, иначе поднятие новых тестовых стендов превратится в боль.

• Стоит держать в голове, что мы работаем с in-house-решением со всеми вытекающими: оно может сломаться. Поэтому здесь нужно быть достаточно открытым и помогать коллегам чинить проблему, а не бранить решение.

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

Как происходит деплой в вашей компании? Считаете ли вы наш подход с одной кнопкой оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.

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

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

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

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

И для разработчика, и для дизайнера

Создавая UI-кит, мы постарались сделать так, чтобы дизайнер мог участвовать в развитии интерфейса, не привлекая разработчиков. Он выбирает размер, цвет, шрифт, поведение компонентов прямо из Figma для этого там есть отдельная доска, на которой задаются дизайн-токены. Например, дизайнер может обозначить основной цвет (color-primary) как фиолетовый, тогда для визуальных компонентов будет использоваться именно он.

Разработчики применяют UI-кит при создании сервисов. Теперь не нужно писать компоненты заново достаточно обратиться к общей библиотеке.

Выбираем основу библиотеки

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

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

Также мы хотели оставить себе пространство для маневра, чтобы не быть привязанными к определенному фреймворку. Отчасти потому, что несколько решений уже развивались не на рекомендуемом в компании стеке (React). Но в большей степени из-за нежелания безусловно завязываться на одной технологии. Учитывая скорость развития отрасли, мы должны были обеспечить командам возможность экспериментировать с технологиями без отказа от базы готовых UI-элементов.

Библиотек и фреймворков для создания веб-компонентов много. Например, ресурс WebComponents.dev, кроме предоставления исчерпывающего списка вариантов, обновляет их и информацию об их характеристиках. Мы составили свой топ-3: связку lit-element + lit-html и фреймворки Stencil, Hybrids выделили наиболее значимые критерии и сравнили по ним. На момент выбора это было в начале июня 2020 года получили такую картину:

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

Если у вас похожий стек, можете посмотреть нашу таблицу.

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

Когда мы выбирали инструменты, оценивали, насколько изменится размер бандла сайта и на React, и на Vue. Сначала все было не очень хорошо, потому что демосайт на React весил без библиотеки 2,5 Мбайт, а с библиотекой 5 Мбайт. Бандл оказался таким большим потому, что по умолчанию Stencil предоставляет библиотеку с полифилами с поддержкой старых браузеров. Чтобы уменьшить размер бандла, мы использовали решение для выгрузки компонентов в виде отдельных файлов, с которыми очень хорошо работают фреймворки. Также мы отдельно вынесли шрифты и подключаем их по URL так мы добились, чтобы с библиотекой на Stencil сайт весил 3 Мбайт. Это хорошо, хотя уже сейчас понятно, что можно еще поработать над размером дополнительных компонентов.

От Figma до готового компонента

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

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

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

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

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

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

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

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

Добрая четверть моего рабочего времени за последний год ушла на обновление архитектуры Учи.ру. С ростом продуктов и количества пользователей увеличился и клубок зависимостей в монолите. Выделяя из него части и набивая на этом пути шишки, я не раз задумывался о том, как мы к этому пришли. Волей-неволей вспоминаешь, с чего все начиналось.

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

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

Артур Чарльз Кларк. 2001: Космическая одиссея (1968)

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

Начиналось же все с маленького сайта около десяти лет назад.

С чего все начиналось

Эра мини-монолитов

Первые версии Учи.ру появились в начале второго десятилетия ХХI века. Это были очень простые сайты с отдельными базами данных, образовательным контентом и менеджментом: старая платформа Учи.ру с уроками, Учи.ру Столбики и Учи.ру Колонки. Спустя десятилетие они выглядят немного старомодно, но все равно мило мы храним их во внутреннем музее славы Учи.ру и публичный доступ к ним не предоставляем.

В Столбиках уже можно было получать ачивки за учебу.А список уроков на старой платформе Учи.ру выглядел довольно просто.

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

Эра зарождения первого монолита

До 2012 года сайты существовали обособленно. Затем мы создали новую платформу с единой точкой входа Login, которая поглотила старую Учи.ру и Колонки. Столбики ждало скорое забвение.

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

Эра CMS

Через два года системная архитектура выглядела скромно: CMS, основная платформа, а также разные прикладные модули, например, для аудита, управления персоналом, временного трекинга.

Довольно простая CMS помогала в совместном создании и версионировании контента для пользователей, основу которого составили интерактивные карточки (задания) для детей, разработанные совместно с методистами.

Расширение функционала основного модуля

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

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

Из-за сложностей с любыми модификациями в монолите в начале 2019 года мы работали с устаревшими версиями Rails (4.1) и Ruby (2.1.5). Webpack с небольшими вкраплениями React-компонентов не позволял легко обновить зависимости без существенных рисков отказа в обслуживании. Нужно было что-то делать

Выделение функций из состава монолита

Чтобы прощупать возможности разделения, мы начали проводить эксперимент по разъединению фронтенда и бэкенда. К этому моменту интерфейс представлял собой классические Rails-шаблоны с примесью старого Webpack. И хотя мы не ставили глобальной задачи по переходу на микросервисы, этот опыт все же стал большим шагом для нашей команды сразу в техническом, инфраструктурном и организационном плане. Но самое главное, мы начали выделять компоненты из uchiru-login. Стало понятно, что обуздать монолит реально. Отправной точкой стало выделение откровенно обособленного функционала с минимальной степенью связности. На подобных некорневых блоках мы и сосредоточили усилия.

1. Генератор PDF-сертификатов. Попрактиковались мы на микросервисе, который должен выдавать готовый документ по входным параметрам. Фактически мы сделали классический распределенный монолит с синхронным сетевым взаимодействием.

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

3. Развивающие игры. Используя опыт олимпиадников, мы создавали игры как отдельный компонент, связанный с монолитом авторизацией, но способный развиваться самостоятельно.

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

   Сначала монолит и новый сервис использовали общую базу данных. Мы старались по возможности переносить операции записи ответственных данных в новые БД, а из монолита использовать их в режиме чтения.

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

   Для разработки этого модуля мы использовали библиотеку JSONAPI Resources, которая сочетает в себе гибкость, низкую скорость и синтаксис, очень похожий на классический ActiveRecord. Залогом успеха стало стремление группы энтузиастов, которые во что бы то ни стало хотели достичь нужного эффекта.

Справляемся с высокими нагрузками

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

1. Кеширование. Это было первое, что пришло в голову. В качестве инструмента мы использовали Redis. Чтобы не заниматься поддержкой кластера в облаке, мы решили заменить его урезанной версией Redis от Envoy с шардированием по ключу хранения. В результате система стала держать нагрузку лучше, но это было только начало.

2. Реплики БД. После очередного скачка трафика мы уперлись в лимит пула соединений с БД. Теоретически работа с микросервисами должна была помочь в масштабировании самых нагруженных частей системы или вовсе избежать этой проблемы. Но это в идеальном мире.

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

3. Octopus. К счастью, на помощь нам пришел Octopus, но и он не обрабатывал все случаи, особенно те версии, которые были совместимы с устаревшей платформой. Например, мы обнаружили, что запись в режиме реплики тянет за собой все ассоциативные связи в том же режиме. Это порождает конфликты, связанные с попытками записи в read-only-транзакциях. Пришлось заниматься monkey-патчингом ORM-компонентов. Методом проб и ошибок проблему решили.

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

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

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

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

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

Разделение на микросервисы действительно возможно

Но ведь верилось же! Казалось, еще немного усилий и то самое светлое будущее, которое каждый представлял себе по-разному, в зависимости от воспитания и фантазии, обязательно наступит.

Артур Чарльз Кларк. 2001: Космическая одиссея (1968)

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

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