Сервисы

Предисловие

Знаю, что хабра-народ сейчас очень негодует, что стало очень мало технических статей, Хабр не торт и т.п. поэтому напишу сразу это не техническая статья.

Цель статьи поделиться удобным бесплатным сервисом хранения ссылок.

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

Вступление

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

Был проект. Построенный на IIS + ASP.NET + MVC. Время шло. Появлялись новые версии MVC. Проект переезжал с версии на версию. Проект использовал достаточно специфическую внутреннюю архитектуру, поэтому MVC обрастал всё новыми костылями.

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

Честно сказать по прошествии времени можно сделать вывод.

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

Так вот. По мере написание своего web-стека встал вопрос о тестировании.

А как тестировать web стек? Разумеется, нужно повесить какой-нибудь тестовый сайт. В результате быстрого мозгового штурма, что бы не писать коня в вакууме, было решено сделать какой-нибудь простенький полезный сервис.

И этот сервисом оказался сервис хранения ссылок. Более того этот сайт оказался отличным тестовым полигоном для отработки различных web идей. И по мере своего существования обрастал всё новым функционалом. Который тестировался, уходил в другие проекты, но и оставался в сервисе.

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

Было решено написать документацию к нему. Нуднейшее дело я вам скажу. Ну и поделится с другими.

Описание сервиса

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

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

Далее ссылка передаётся на сервер. Там подвергается проверке работоспособности. Проверяется доступ по протоколам http/https. Проверяется редирект ссылки. При необходимости производится промежуточное сохранение и отправка cookies. После всех проверок сохраняется конечный вариант.

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

В конце всей процедуры сохраняется правильная ссылка и её заглавие. Это информация и заносится в каталог.

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

У каждой добавленной ссылки есть меню настройки. Для вызова меню для ссылки надо нажать на иконку в виде квадрата слева от ссылки. При нажатии появляется меню управления ссылкой. Меню состоит из 5 кнопок

• Удаление ссылки

• Добавление иконки

• Перемещение ссылки в другую группу подгруппу

• Редактирование заголовка ссылки

• Редактирование URL ссылки

Иконки

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

По умолчанию сервис пытается скачать для изображения иконки картинку с именем logo по адресу иконки либо скриншот. Иногда, если url иконки не доступен картинка не устанавливается. В таких случаях картинку для иконки можно загрузить вручную. Для этого есть меню настройки картинки. Так же в меню можно удалить ранее установленную картинку. При наведении на иконку - слева становятся видимыми 2 кнопки. Верхняя квадратная - меню. Нижняя треугольная - размер. Зажимая нижнюю кнопку можно изменять размер. Зажимая саму иконку можно менять местоположение.

Меню иконок

• Положение заглавия иконки. Верх, середина, низ, нету заглавия.

• Редактировать заглавие иконки

• Меню настройки картинки иконки. Можно загрузить картинку из интернета или с компьютера.

• Фиксировать иконку. Запретить перетягивание.

Группы

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

Кнопки групп можно двигать. Слева каждой кнопки есть полоса для перетягивания. Самая первая кнопка меню это кнопка открытия вашего каталога ссылок в виде оглавления.

Это список всех групп/подгрупп с активными линками. Щелчок мыши быстрый переход в нужную категорию.

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

Подгруппы

Группы делятся на подгруппы. Внутри подгруппы можно установить способ сортировки ссылок.

• Сортировка ссылок по названию. Сверху-вниз.

• Сортировка ссылок по названию. Снизу-вверх.

• Сортировка по дате добавления ссылки. Сверху-вниз.

• Сортировка по дате добавления ссылки. Снизу-вверх.

Подгруппы можно перемещать между группами. Последовательность подгрупп меняется. Щелчок по заглавию подгруппы выделяет её. Новая добавленная ссылка будет добавлена в эту подгруппу.

Подгруппы также имеют страницу настроек. Вход - маленький крест в левой-нижней части поля иконок. Страница настроек повторяет страницу настроек групп.

Backup всех ссылок

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

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

• Загрузка всех ссылок в текстовом формате

• Загрузка всех ссылок в виде html страницы. Можно либо сохранить файл, либо сразу открыть в браузере.

• Загрузка всех ссылок в виде JSON кодировки. Предназначен для автоматизированных систем.

• Загрузка всех ссылок в виде XML кодировки. Предназначен для автоматизированных систем.

Разделы сайта

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

Список разделов.

Ваши ссылки.

Это первый и основной раздел сайта. Это собственно основной формируемый каталог ссылок. Каталог имеет широчайшие возможности по настройке отображения и управления добавленными ссылками.

Шифрованные ссылки.

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

Раздел по предоставляемым функциям аналогичен разделу Ваши ссылки. Но ссылки хранятся на сервере в зашифрованном виде.

Для этого при добавлении новой ссылки пользователем - ссылка шифруются на стороне клиента (в браузере) и передаётся и хранятся на стороне сервера только в зашифрованном виде. При просмотре ссылок пользователем скаченные зашифрованные ссылки с сервера расшифровываются на стороне клиента. Т.е. данные в не зашифрованном виде находятся только на стороне клиента. На стороне сервера - данные находятся только в зашифрованном виде. Крипто-операции происходят только на стороне клиента. Крипто-ключ никогда не покидает сторону клиента.

Короткие ссылки

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

Друзья

Раздел друзья предоставляет 2 функции:

• Кинуть ссылку другу. Получить ссылку от друга

• Открыть другу для просмотра любую группу из раздела Ваши ссылки

Т.е. этот раздел по функциям напоминает почту. Но только для ссылок. Последовательность действий следующая.

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

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

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

Боксы ссылок

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

Интерфейс аналогичен остальным разделам. Каждая группа в разделе Бокс ссылок это отдельная страница который имеет самостоятельный адрес.

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

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

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

Публичные ссылки

Раздел по функционалу аналогичен разделу Ваши ссылки, но все добавленные ссылки становятся публичными. Это значит, что на вас могут подписаться другие пользователи, в разделе Лента и просматривать ваши публичные ссылки.

Лента

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

Лента новых публичных ссылок пользователей, на которых вы подписаны

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

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

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

Поиск публичных пользователей

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

Темы, языки

Сайт доступен в 2 языках en/ru и в 2 темах тёменая/светлая.

Ссылка на сервис

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

Представьте ситуацию: вам нужно воспользоваться оплаченным (как вы думаете) сервисом и вдруг оказывается, что он отключен за неуплату. Такая неприятность портит впечатление от бренда, снижая поток прибыли, а внезапно отключенный клиент может не вернуться к сервису. К старту курса о глубоком и машинном обучении делимся переводом о том, как эту проблему решили в Dropbox, где обнаружили, что внедрение ML в обработку клиентских платежей помогает пользователям оставаться довольными и работает лучше внедрённых за 14 лет политик биллинга.

Платежи в Dropbox

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

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

Продление подписки и сбои

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

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

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Сбои в оплате могут произойти по ряду причин. Среди них:

• нехватка средств;

• карта с истекшим сроком действия;

• заблокированная карта возможно, сообщается о потере или краже;

• непредсказуемые сбои обработки.

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

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

Команда платежей должна была вручную разделить пользователей на группы в зависимости от их признаков типа подписки, географического местоположения и т. д., а затем выполнить A/B-тест наших десяти или около того различных жёстко закодированных наборов правил, чтобы определить, какие из них лучше всего подходят для этих признаков. Затем команда платежей сохраняла оптимальный вариант политики для этой группы выставления счетов по умолчанию. Периодически команда проводила повторное тестирование, чтобы узнать, изменились ли для разных пользователей лучшие решения.

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

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

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

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

• устранение ручного вмешательства и сложной логики на основе правил;

• например, Повторяйте каждые X дней или Избегайте попыток оплаты в выходные;

• глобальная оптимизация множества параметров для конкретных сегментов клиентов;

• устойчивость к изменениям клиентов и рынка;

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

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

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

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

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

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

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

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

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

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

2. Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.

3. Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.

4. Генерация прогноза. Модель возвращает ранжированное наилучшее время оплаты. Этот прогноз отправляется обратно в модуль Predict, в свою очередь, результаты в биллинговую политику.

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

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

ML-операции

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

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

Бизнес-метрики

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

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

Внутренний мониторинг модели

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

• Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.

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

• Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

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

• свежесть и задержки в конвейерах данных признаков;

• доступность и задержка сервиса Predict;

• доступность EdgeStore.

Для мониторинга нашей модели и метрик инфраструктуры мы используем дашборды Grafana и Vortex. Для бизнес-метрик мы используем Superset. Все эти живые метрики и дашборды помогают нам проактивно отслеживать ожидаемое поведение модели, позволяя принимать соответствующие меры, когда оно отклоняется.

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

Дальнейшие шаги

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

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

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

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

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

Как выбирал

Вы удивитесь, но поиском. Погуглил Kubernetes в облаке, пролистал пару страниц. Так и нашёл семь компаний, которые наиболее активно продвигают эту услугу: Mail.ru Cloud Solutions, Cloud4Y, CloudMTS, Yandex.Cloud, КРОК, DataLine, Selectel.

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

Про субъективность

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

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

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

Знакомство

Звонить и писать сразу всем компаниям гиблое дело, особенно если не готов покупать, а хочешь лишь проверить, как оно работает. Поэтому я потихоньку запрашивал тестовый доступ у каждой компании по очереди. Быстрее всех ответили Selectel, Cloud4Y и MCS, а вот Крок и DataLine оказались не столь быстрыми. Мне даже пришлось несколько раз ментально их пнуть напоминать о себе, чтобы получить какой-то ответ.

И уже на этом этапе круг подопытных кроликов провайдеров сузился. DataLine вообще никак не захотел со мной общаться. Письма ушли в молоко. Ну и ладно, подумал я. И нечего нас дёргать со всякими глупостями, подумал неизвестный мне менеджер DataLine. КРОК вежливо извинился и сообщил, что мелочь вроде меня им не интересна. Неприятно, но честно. Спасибо за это. Лучше честный отказ, чем игнор или затягивание времени.

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

Чуть забегая вперёд скажу, что поскольку компаний стало меньше, а я вошёл во вкус, то в процессе тестирования сервисов Kubernetes вспомнил и про Яндекс. А не позвонить ли мне им?, подумалось мне. Как оказалось, не зря у этих ребят оказалось не самое плохое решение из тех, что мне удалось посмотреть.

Тестирование

Теперь давайте посмотрим, чего я натестировал.

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

Также провайдеры используют стек технологий виртуализации VMwarevSphereиNSX-T. NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). VMware платный, но зато предлагает гарантированную поддержку от вендора с ответами на сложные вопросы и кейсы. И специалистов по VMware найти проще.

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

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

Облачные балансировщики нагрузки

Если говорить про балансировщик, распределяющий нагрузку, то в Selectel он создаётся вместе с кластером. Автоматическое создание балансировщика вместе с кластером предлагает Mail.ru, у него возможно автоматическое и быстрое масштабирование до 1000 узлов. А вот МТС удивил. Да, балансировщик создаётся автоматически при создании кластера. Но умолчанию открыты только 80 и 443 порты. Дополнительные порты можно открывать только через поддержку. Яндекс и Cloud4Y тоже предлагают создание дополнительного балансировщика. На этот случай есть специально написанные инструкции, ссылку на которые они мне заботливо прислали.

Управление

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

Mail.ru предлагает варианты управления кластером как через Kubernetes Dashboard, так и через kubectl. Web/API возможны в Cloud4Y и Selectel. У МТС только API. К тому же, управление docker-контейнерами из интерфейса не предусмотрено. В интерфейсе происходит управление кластерами Kubernetes. Яндекс пошёл своим путём. У них предлагается Web и Console Yandex.Cloud. Мне показалось не очень удобным и логичным, когда для работы требуется специальная яндексовая консоль. Может, есть и какой-то другой способ, только я его не нашёл.

Хранилища данных

Persistent Volumes можно считать аналогом нод в самом кластере Kubernetes. Зачем вообще нужна эта штука? Допустим, у вас есть несколько разных хранилищ. К примеру, одно быстрое на SSD, а другое медленное на HDD. Вы можете создать два Persistent Volumes в соответствии с этим, а затем выделять подам место в этих томах. Kubernetes поддерживает огромное количество подключаемых томов с помощью плагинов.

Вот тут у провайдеров используются разные решения. Cloud4Y и Selectel поддерживают как блочные, так и сетевые устройства NFS. И это хорошо. У Mail.ru блочное устройство накладывается на ограничения по ReadWriteMany(RWX). В документации указано, что механизм Persistent Volume позволяет подключить существующий Cinder Volume, находящийся на кластере Ceph в качестве постоянного хранилища данных к подам. Хранилище на базе Ceph обеспечивает сохранность данных за счёт трёхкратной репликации. У МТС Cloud Persistent Volumes тоже идёт через блочное устройство, что накладывается на ограничения по ReadWriteMany. Можно только одной ноде писать на него. В Yandex.Cloud блочные устройства могут работать только в ReadWriteOnce(RWO).

Контроллеры Ingress

У Selectel в версии Managed Kubernetes Ingress Controller не предустанавливаются в кластеры. Для создания объектов Ingress потребуется самостоятельно установить Ingress Controller. Обратите внимание, что при создании Ingress Controller у вас, вероятнее всего, будет создан Service с типом LoadBalancer помимо самого приложения Ingress Controller. В таком случае в вашем проекте будет автоматически создан дополнительный балансировщик нагрузки, который отобразится в разделе Балансировщики нагрузки.

Mail.ru позволяет выбрать Ingress при создании кластера. Кластеры Kubernetes, устанавливаемые в MCS содержат преднастроенный Ingress Controller на базе балансировщика нагрузки Nginx, который может обеспечить доступ к вашим сервисам, используя один и тот же выделенный балансировщик нагрузки OpenStack. МТС позволяет добавить/убрать Ingress при создании кластера. В документации МТС сразу говорится, что NGINXIngress разворачивается в стандартной настройке при запуске кластера при выборе соответствующего параметра. У Яндекса Ingress построен на базе LoadBalancer. Cloud4Y предлагает разворачивать Ingress в ручном режиме при необходимости.

Масштабирование

У Селектела и МТС нет автоматического масштабирования. Работайте ручками, господа! Надо уточнить, что в МТС автоскейлинг будет добавлен в этом (2021)году. Яндекс и Майл предлагают более удобные условия. У них есть autoscaling по определенным параметрам загрузки нод, добавляется и убавляется автоматически. Cloud4Y предлагает автоскейлинг на уровне pod который определяется на основании конфигурации k8s. Autoscaling на уровне воркеров\нод на лету отсутствует, но можно зайти в vCloud и докинуть ноду или написать скрипты, которые делают то же самое, только запрограммированно

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

Мониторинг

Мониторинг это неотъемлемая часть любой инфраструктуры. Правильно настроенный мониторинг четко отражает здоровье ИТ-системы и про активно диагностирует её состояние. В данном случае все используют стандартное решение для VMware в виде плагина. У него есть свои ограничения, 1 мастер нода и 5 воркеров.

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

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

Персональные данные

ФЗ-152 сейчас в тренде, и провайдеры активно развивают это направление. Selectel, Mail.ru Cloud, Cloud4Y обещают, что их решения соответствуют требованиям закона о персональных данных. С Yandex.Cloud я не понял, есть ли такая штука. Похоже, что нет, ведь иначе об этом где-нибудь, да говорилось бы. МТС Cloud пока лишь дорабатывает свою систему.

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

Оплата

Тут, наверное, и говорить нечего. Особых нововведений в плане оплаты нет.

Отличия от конкурентов

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

Mail.ru делает упор на тройную репликацию данных и отказоустойчивость, Selectel на привычный типовой формат работы с Kubernetes, Cloud4Y обещает мощную техническую поддержку и развитую документацию в базе знаний. МТС подчёркивает преимущества VMware в плане отказоустойчивости, а Яндекс порадовал формулировкой. Их сервис хороший, и это его ключевое отличие от остальных.

Выводы

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

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

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

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

Пост написан по мотивам доклада Антона Губарева @antgubarev, бывшего тимлида команды Teachers он готов ответить на ваши вопросы в комментариях.

Преподаватели Skyeng не сразу попадают на передовую для начала они проходят отбор и обучение. Направление найма и онбординга преподавателей появилось в 2015 году тогда же был сделан первый коммит в наш (уже бывший) легаси-монолит. Прежняя команда активно его поддерживала и старалась развивать, но в один момент ей стало объективно сложно справляться со всеми проектами. Так появилась моя команда.

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

Наши продукты

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

Исторически сложилось, что для ведения сделок используется внешний Мегаплан, который интегрирован с нашей TRM (Teachers Relations Management, внутри ее еще ласково зовут Tramway) системой, в которой хранятся данные по конкретным преподавателям и которую мы дополнительно используем при поиске учителя по узкому запросу.

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

Осенью 2019-го компания активно взялась за развитие этих систем, и за 2,5 месяца нам предстояло:

• реализовать новые фичи. Школа росла: если раньше требовалось 100 преподавателей в месяц, то теперь 1000, и от нас во многом зависело, захлебнется или же выстоит подбор при масштабировании (кстати, те наработки здорово помогли в период карантина, когда многие педагоги решили попробовать онлайн-преподавание);

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

• отделить свою работу от другой команды.

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

Какие были варианты

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

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

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

Мы взяли последнюю на тот момент LTS версию Symfony и принялись за работу.

Детали реализации

Структура папок. Все независимые сервисы-продукты мы стали складывать в папку modules. У нас получились выделить такие сервисы:

• интеграция с Мегапланом;

• бэкенд календаря тренировочных уроков преподаватель асессор;

• бэкенд онбординга;

• и несколько прикладных проектов: работа с очередями, декораторы, http-клиенты, мониторинг, метрики, логирование.

Общие пакеты положили в папку packages: в основном это клиенты для различных API, внешних и внутрикомпанейских сервисов, а также общая структура данных и DTO, которая используется для межмодульного взаимодействия.

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

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

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

Например, преподаватель записался на тренировочный урок и нам нужно записать это в карточку (она же сделка) в CRM. Модуль онбординга, используя пакет megaplan-client, положит в очередь сообщение, что нужно изменить конкретное поле. Модуль Мегаплана содержит в себе консьюмеры, которые разгребают эту очередь. Работает и в обратную сторону. Мегаплан пошлет нам веб-хук, когда что-то изменилось, мы положим его в сыром виде в очередь, а онбординг эту очередь вычитает и что-то поменяет. Да, тут есть задержка, но она не критична, а данные точно сохранны.

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

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

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

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

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

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

Что получилось в итоге

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

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

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

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

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

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