Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе

в 13:54, , рубрики: big data, Блог компании Сбербанк, машинное обучение, нейросети, Программирование, Сбербанк, Сбертех, хакатон

Мы регулярно проводим внешние хакатоны на разные темы. Но этим летом мы решили дать возможность проявить себя и сотрудникам – ведь наверняка им хочется порешать задачки на имеющихся данных. Что получилось у коллег в СберТехе — рассказывает samorlov, главный руководитель разработки в Отделе разработки лабораторного кластера супермассивов.
Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 1
Участникам предложили разработать решения на Machine Learning, которые помогали бы предсказывать сроки выполнения доработок и критичность багов. Эти решения могли бы повысить эффективность разработки в СберТехе, в том числе:

  • лучше планировать загрузку команд в ходе исправлений на разных этапах разработки;
  • формировать структуру релизов в части hot fix;
  • планировать работу в спринтах — определять story points, зарезервированные для исправления проблем;
  • в целом снижать количество багов в программном коде;
  • сократить время выхода продуктов на рынок;
  • увеличить предсказуемость решений и эффективность тестирования.

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

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

Исходные данные

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

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

Железо

Если в знаниях и навыках коллег мы почти не сомневались, то мощность настольных компьютеров, мягко говоря, не запредельна. Поэтому дополнительно по запросу предоставлялся небольшой Hadoop-кластер. Конфигурация кластера (80 CPU, 200 ГБ, 1,5 ТБ) напоминает одноюнитовый сервер с упором на вычисления, но нет, это все-таки кластер, развернутый в Openstack-е.

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

В Лаборатории Данных был задействован JupyterHUB, создававший отдельные инстансы JupyterNotebook. А чтобы можно было работать с параллельными вычислениями, с помощью Cloudera parcels мы добавили в Jupyter несколько вариантов kernel-ов с разными наборами python-библиотек.

В итоге на входе мы получили независимую работу N пользователей с возможностью использовать нужные версии библиотек, никому не мешая. Кроме того, без особой головной боли можно было запустить параллельные вычисления (мы знаем, что существует Data Science Workbench от Cloudera, и уже пробуем с ним работать, но на момент проведения хакатона этот инструмент еще не был доступен).

I место — автообработка багов

Цель: Создание pipeline автообработки багов в проектах Сбербанк-Технологии.
Авторы решения: Анна Рожкова, Павел Швец и Михаил Баранов (Москва)

В качестве исходных данных команда использовала отзывы клиентов мобильного приложения Сбербанк Онлайн из Google Play и AppStore, а также информацию о багах из Jira.

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 2

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

  • обновления
  • антивирус (рут, прошивка)
  • смс и платежи

В отдельную категорию попали люди, писавшие, что «все плохо».

С помощью агломеративной иерархической кластеризации команда разделила отзывы по клиентским проблемам (преимущество такого подхода — возможность добавления экспертного мнения, к примеру, когда отзывы о целях и вкладах можно отнести к одному кластеру). Так, например, один из выделенных кластеров объединил проблемы со входом на устройстве Asus Zenfone 2 (период между появлением первых отзывов о проблеме и регистрацией бага в Jira составил 16 дней).

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 3

Участники предложили максимально сократить время реагирования на проблемы пользователей, сделав онлайн-обработку отзывов с автосозданием багов по выделенным кластерам, используя преимущество банка — большое количество неравнодушных клиентов (1500 отзывов в день). В ходе работы удалось добиться accuracy = 86% и precision = 88% при определении негативных отзывов.

Еще одно решение команды — визуализация процессов в разработке. Кейс был разобран на примере Сбербанк Онлайн Android (ASBOL).

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 4

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

Дополнительно участники попробовали разобрать проблему автоматической приоритизации багов с использованием логистической регрессии и наивного байесовского классификатора. Для этого была определена важность бага по его описанию, наличию вложений и другим характеристика. Однако модель показала результат accuracy = 54% при кросс-валидации на 3-х фолдах – на момент сдачи работ не пригодный для внедрения прототип.

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

Презентация команды

II место — оптимизация производственных процессов

Автор решения: Антон Баранов (Москва)
Задачи:

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

Антон работал с багами из Jira. Дата-сет включал информацию о более чем 67 000 багов в статусе «завершен» с 2011 по 2017 год. Поиск решения поставленных задач он вел с помощью библиотек языка Python и других ML-библиотек.

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 5

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

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 6

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

Презентация участника

III место: прогнозирование рисков

Автор решения: Николай Желтовский (Иннополис)

Цель: Создание системы прогнозирования на основе нейронной сети для минимизации рисков при управлении ИТ-проектами.

Из предложенных организаторами наборов исходных данных участник выбрал выгрузку списка задач из Jira. Задача — это отдельное задание на разработку компонента ПО. Каждая задача в процессе своего жизненного цикла проходит различные состояния: создание, разработка, различные виды тестирования и согласования, закрытие. Таких состояний может быть несколько десятков.

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

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 7

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

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 8

Нейронная сеть предсказывает некоторые критические события с точностью 91-94%. Например, повторное открытие задачи. Дата закрытия задачи предсказывается с отклонением от 0 до 37 дней сразу после её создания. На более поздних этапах, когда проведены какие-либо работы по задаче, максимальное отклонение составляет не более недели.

Три идеи, как повысить эффективность разработки: итоги хакатона по Machine Learning в СберТехе - 9

Презентация участника

Автор: Sberbank

Источник

Поделиться

* - обязательные к заполнению поля