На первый взгляд, вы можете не подумать, что машинное обучение (ML) и изменение поведения идут рука об руку, и мы тоже. Изменение человеческого поведения требует влияния и убеждения. Существует множество исследований и рецептов изменения человеческого поведения, каждое со своими оговорками. Здесь мы хотели использовать наши данные Jira, чтобы понять текущее поведение людей, стоящее за ошибочной классификацией ошибок. Мы использовали этот подход после того, как нас вдохновило то, как Сет Стивенс-Давидовиц смотрел на тенденции поиска в Google, стратегию, в которой вместо того, чтобы спрашивать людей об их поведении, он сначала смотрел на их действия. Мы разработали модель машинного обучения (с точностью 94%), которая может сказать нам, является ли данный тикет Jira ошибкой.

Зная это, мы проанализировали тикеты Jira, которые не классифицируются как ошибки, чтобы выяснить, должны ли они быть такими. Благодаря Стивену Дж. Дабнеру / Freakonomics Radio мы стремились получить большую отдачу от малого мышления. Вместо тщательно продуманного упражнения по изменению поведения мы приложили минимум усилий и разослали опросы группе людей, которые ошибочно классифицировали ошибки как не-ошибки. Идея этого небольшого опроса принесла большую прибыль, поскольку с тех пор мы заметили сокращение ошибочно классифицированных ошибок. Когда люди перестают ошибочно классифицировать ошибки, вы быстрее устраняете проблемы клиентов. Если вы решите проблемы клиентов быстрее, вы сэкономите деньги и сделаете клиентов счастливыми. Вместо того, чтобы полагаться на человека для проверки ошибок, наша модель теперь может проверять тысячи заявок Jira за считанные секунды. Благодаря этому теперь мы можем добавить автоматический контроль качества ко всему, что мы делаем: автоматизируем удовлетворение потребностей клиентов.

В апреле 2018 года наша недавно основанная команда Site Reliability Engineering: Actionable Insights (или SRE-AI для краткости, иронично, верно?) Искала нашу первую проблему, которую нужно было решить. Мы изучили наши данные Jira, которые считаются как «чистыми», так и «темными», то есть не тронутыми наукой о данных и волшебными палочками машинного обучения, а также данными высокого качества. Сначала мы попытались понять, что значит «быстрее устранять ошибки». Мы знали, что если мы сможем сократить среднее время до решения (MTTR), то порадуем множество людей: товарищей по команде кол-центра, инженеров технической поддержки, SRE, владельцев продуктов и, возможно, даже некоторых руководителей.

Мы рассмотрели некоторые общие постановки задач, которые мы могли бы проверить.

Приоритетная проблема

У нас есть удобная матрица, интегрированная в наш портал отправки сообщений о проблемах SRE (SISP), поэтому мы довольно хорошо умеем приблизительно рассчитывать последствия проблемы. Как и в жизни, несчастные случаи случаются, и некоторые проблемы могут быть ошибочно классифицированы как менее важные. Проблемы с более высоким приоритетом связаны с более быстрым ожидаемым временем для решения соглашения об уровне обслуживания (SLA). Если мы ошибаемся в расстановке приоритетов, на осознание и исправление может уйти некоторое время.

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

Проблема переназначения

В дополнение к назначению приоритета, инструмент SRE Issue Submission Portal также направляет проблемы командам, но маршрутизация зависит от того, кто отправляет запрос, чтобы выбрать правильный продукт или услугу. Во многих продуктах или услугах мы неизбежно видим ошибки, которые неправильно направляются - и у вас всегда есть сценарий «Я не уверен, в каком продукте проблема».

Мы провели некоторый анализ T-теста студента (мы говорим о p = 0,000), чтобы показать, что одно переназначение может добавить дни к нашему среднему времени на решение проблемы. На приведенном выше рисунке вы увидите, что когда нет изменения назначения, наш MTTR близок к нулю, но когда ошибка переназначается, наше MTTR больше. В настоящее время у нас есть несколько идей по решению этой проблемы - впереди еще одно сообщение в блоге!

Проблема классификации

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

Звонок всем экспертам!

Вместо того, чтобы вручную проверять каждую функцию или улучшение, мы пошли по маршруту контролируемого обучения, попросив трех доблестных SRE помочь нам решить, после прочтения комментариев и ключевых деталей для каждой заявки, следует ли классифицировать эту функцию или улучшение как ошибку. После того, как 100 билетов были промаркированы, мы обнаружили, что случайный Лесной классификатор дал нам оценку точности F1 0,88.

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

Вот где это становится интересным - опрос

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

Выглядело это примерно так:

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

Этот подход Slack позволил 66 людям заполнить опрос в течение 24 часов по сравнению с 46 ответами на опрос по электронной почте за один месяц, включая электронное письмо с напоминанием.

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

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

да.

  • И для контроля, и для эксперимента: t = 6,816, p = 0,0000000, мы называем это «эффектом ореола» нашего исследования. И контрольная группа, и экспериментальная группа были ощутимо лучше.
  • Для людей, прошедших опрос: t = 5,686, p = 0,0000001, получение опроса изменило поведение ошибочной классификации.
  • Для людей, ответивших на опрос: t = 4,719, p = 0,0000106, ответ на опрос также изменил поведение ошибочной классификации, но с немного меньшей уверенностью, чем люди, которые прошли только опрос.

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

В общем, мы увидели:

  1. Меньше ошибок остается открытыми: 26% ошибок, неправильно перенесенных в улучшение, или функция все еще открыты, по сравнению с 7% ошибок, которые остались открытыми.
  2. На 4% меньше ошибок было неправильно классифицировано как функции или улучшения после эксперимента.
  3. Ошибки с более низким приоритетом перемещались в исправление или реже после эксперимента.
  4. Мы посмотрели на MTTR всех закрытых заявок, перемещенных от ошибки к улучшению или неправильно до временного окна нашего эксперимента, и сравнили ее с MTTR всех закрытых заявок, которые остались ошибкой в ​​том же временном интервале. Используя наши показатели изменения поведения, мы рассчитали снижение MTTR как миллионы доходов, сэкономленных за 1 год. Подробнее об этой математике ниже.

Расчет экономии

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

Мы применили нашу модель машинного обучения с ошибками / без ошибок к данным Jira за 5 месяцев до того, как разослали опросы, которые привели к изменению поведения. Мы собрали MTTR для ошибок, которые были неправильно переведены в категорию non-bug, и сравнили их с ошибками, которые были закрыты как ошибки.

Для наших расчетов мы предположили, что наше изменение поведения было успешным, и ошибки больше не будут неправильно классифицироваться как функции. Кроме того, если мы применим нашу модель в реальном времени к Jira, мы всегда будем отлавливать ошибки, классифицированные неправильно. Ниже показано сравнение MTTR по приоритету. Ошибки P0, которые остаются ошибкой, устраняются на 11% быстрее, чем ошибка P0 (наивысший приоритет и наименее распространенная), которая была неправильно перенесена в функцию. Мы устраняем ошибки P1 и P2 на 68% и 61% быстрее, чем если бы они были функциями.

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

Наш главный вывод

Мы смогли внести изменения в культуру, не отправляя электронные письма, а собирая данные, используя экспертов, разрабатывая контроль / эксперимент, получая обратную связь и используя Slacking. Такой подход, основанный на данных, лежит в основе нашего процесса принятия решений в PayPal. Мы работали вместе с экспертами, чтобы пометить билеты Jira как ошибку / не ошибку, поскольку мы добавили контролируемое машинное обучение, чтобы это решение могло масштабироваться. Добавление к этому процессу опроса, хотя и не требующего особого внимания, обеспечило человеческий фактор и большую отдачу от мышления о мелочах (концепция Стивена Дж. Дубнера / Freakonomics Radio за концепцию) удивила нашу команду. Мы также удивили нашу патентную команду этой концепцией и уже представили эту идею в ВПТЗ США с датой публикации 4 июня 2020 года (US20200175391A1).

Спасибо всем причастным

Мы были бы никуда без наших экспертов, которые помогали маркировать данные: Шива Гуджаварти, Джоша Хардисона, Уткарша Сурядевара. Нилеш Вяс добровольно поделился своим плотным графиком, чтобы организовать все это за кулисами во время ротации TLP.

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

Что дальше?

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