![](https://habrastorage.org/web/d66/a42/e0d/d66a42e0d01e4317b2f8af93fa536027.png)
Участникам предложили разработать решения на 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.
![](https://habrastorage.org/web/3b0/5b2/16e/3b05b216ed2b424abfa1a0b939616516.png)
Сначала участники решили проблему разбивки отзывов на положительные и отрицательные с помощью классификатора на основе дерева. Затем, используя негативные отзывы, выделили основные темы, вызвавшие недовольство пользователей. Это, например:
- обновления
- антивирус (рут, прошивка)
- смс и платежи
В отдельную категорию попали люди, писавшие, что «все плохо».
С помощью агломеративной иерархической кластеризации команда разделила отзывы по клиентским проблемам (преимущество такого подхода — возможность добавления экспертного мнения, к примеру, когда отзывы о целях и вкладах можно отнести к одному кластеру). Так, например, один из выделенных кластеров объединил проблемы со входом на устройстве Asus Zenfone 2 (период между появлением первых отзывов о проблеме и регистрацией бага в Jira составил 16 дней).
![](https://habrastorage.org/web/1bb/3c0/2bb/1bb3c02bb6984a17bc49f2b3ef115b0f.png)
Участники предложили максимально сократить время реагирования на проблемы пользователей, сделав онлайн-обработку отзывов с автосозданием багов по выделенным кластерам, используя преимущество банка — большое количество неравнодушных клиентов (1500 отзывов в день). В ходе работы удалось добиться accuracy = 86% и precision = 88% при определении негативных отзывов.
Еще одно решение команды — визуализация процессов в разработке. Кейс был разобран на примере Сбербанк Онлайн Android (ASBOL).
![](https://habrastorage.org/web/bae/fa4/21d/baefa421d3ae4510b7eb8f209ddf771f.png)
Участники посчитали количество переходов статусов багов между членами команды и отрисовали их в виде графа. С этим инструментом проще принимать управленческие решения и равномерно распределять нагрузку внутри команды. Кроме того, наглядно видно, кто является ключевым участником команды и где есть узкие места проекта. На основе этой информации предлагается автоматически назначать баги на конкретных участников команды, учитывая их загрузку и критичность бага.
Дополнительно участники попробовали разобрать проблему автоматической приоритизации багов с использованием логистической регрессии и наивного байесовского классификатора. Для этого была определена важность бага по его описанию, наличию вложений и другим характеристика. Однако модель показала результат accuracy = 54% при кросс-валидации на 3-х фолдах – на момент сдачи работ не пригодный для внедрения прототип.
По мнению участников команды, плюсы их моделей в простоте, хорошей интерпретации результата и быстрой работе. Это шаг к real-time обработке отзывов пользователей при помощи машинного обучения, позволяющий в реальном времени взаимодействовать с пользователями, выявлять и устранять проблемы, повышая лояльность клиентов.
Презентация команды
II место — оптимизация производственных процессов
Автор решения: Антон Баранов (Москва)
Задачи:
- предсказать итоговый приоритет бага, используя информацию о нем. Например: описание, этап обнаружения, проект и др.
- на основе данных о распределении багов во времени предсказать число багов определенного типа, системы, этапа и т.д., в прогнозный период.
Антон работал с багами из Jira. Дата-сет включал информацию о более чем 67 000 багов в статусе «завершен» с 2011 по 2017 год. Поиск решения поставленных задач он вел с помощью библиотек языка Python и других ML-библиотек.
![](https://habrastorage.org/web/a1e/529/aa7/a1e529aa765f4f40b44cdd12b0567104.png)
Антон проанализировал и отобрал признаки, влияющие на итоговый приоритет бага, и на их основе построил модель предсказания итогового приоритета. Кроме того, проведя анализ и поиск особенностей различных временных рядов, он построил модели прогноза числа багов. Предложенные решения будут полезны в тестировании.
![](https://habrastorage.org/web/cb5/26b/191/cb526b191eba4ab8917b03d91e76848b.png)
В Agile результат предсказания количества дефектов по данной модели можно учитывать при планировании работ в будущих спринтах. Решение Антона поможет точнее определять время, необходимое на исправление проблем, что скажется на итоговой производительности.
Презентация участника
III место: прогнозирование рисков
Автор решения: Николай Желтовский (Иннополис)
Цель: Создание системы прогнозирования на основе нейронной сети для минимизации рисков при управлении ИТ-проектами.
Из предложенных организаторами наборов исходных данных участник выбрал выгрузку списка задач из Jira. Задача — это отдельное задание на разработку компонента ПО. Каждая задача в процессе своего жизненного цикла проходит различные состояния: создание, разработка, различные виды тестирования и согласования, закрытие. Таких состояний может быть несколько десятков.
Николай построил и обучил нейронную сеть, способную предсказывать переходы задач в определенные состояния и прогнозировать даты этих событий, сообщать о возможных критических событиях или отклонениях от плановых значений — важных функциях для процесса управления.
![](https://habrastorage.org/web/b4e/4b9/98b/b4e4b998bb3f495bb1ef22310e50a7b5.png)
Для обучения нейронной сети Николай восстановил по журналу событий последовательность промежуточных состояний для каждой задачи. На вход нейронной сети было подано одно из промежуточных состояний задачи, на выход – конечное, таким образом сеть обучалась предсказывать события. Дополнительно для обучения использовались производные данные — например, таблица с временной разницей между всеми событиями в прошлом; учитывалась гипотеза о том, что задачи, по которым работы ведутся в выходные дни, могут быть проблемными.
![](https://habrastorage.org/web/568/ff5/a91/568ff5a914e94b1eaa3a061d06ed599d.png)
Нейронная сеть предсказывает некоторые критические события с точностью 91-94%. Например, повторное открытие задачи. Дата закрытия задачи предсказывается с отклонением от 0 до 37 дней сразу после её создания. На более поздних этапах, когда проведены какие-либо работы по задаче, максимальное отклонение составляет не более недели.
![](https://habrastorage.org/web/ae4/118/57e/ae411857e6bd4a7daa9451dfc0e55618.png)
Презентация участника
Комментарии (4)
MakarkinPRO
22.09.2017 14:33Вопрос по сбербанк, возможно API сбербанк. А то меня тех. поддержка игнорирует)
Задача:
Интегрировать оплату СберБанкОнлайн (не интернет Эквайринг) с сайтом, где:
1) Клиент попадаю на страницу оплаты, вводит свой номер телефона, и ему в его мобильное приложение в раздел Платежи->Выставленные счета ( а лучше если ему еще придет PUSH уведомление) появится запрос от меня, где он может нажать Принять / Отклонить.
2) Если нажимает Принять, то моему сайту возвращается запрос «ВСЕ ОК» деньги пришли.
2.1) Если Отклонить, значит «Ошибка» и я его на нужную страницу перекидываю.
ps: я видел нужный мне алгоритм работает с ЯндексКассой. Но там чтобы пользоваться СберБанкОнлайн нужно покупать кассу.
А я знаю что вышло письмо от МинФина, в котором говорить что если бы как ИП выслал физЛицу PDF счет и он оплатил по реквизитам, то чек электронный ему печатать не надо.
Отсюда и вопрос, можно ли мою транзакцию которую я описал выше в п.1- п.2.(2.1) проводить как такого своего рода выставленный PDF счет, но автоматизированный за счет API?
QtRoS
А я где-то сполгода использую раскидывалку багов по разработчикам. То есть историю багтрекинговой системы рассматриваю как исходные данные, а классом является разработчик. На аккуратно заведенных ошибках (ранние стадии тестирования) что-то вроде 75% accuracy. Если брать топ 3, то порядка 95%.