С июня Orpheus помогает нашей техподдержке и дежурным разработчикам. В августе я посмотрел, что произошло с дежурствами: до разработки стало доходить на 37% меньше обращений, медианное время решения обращения разработчиком снизилось на 27%, среднее — на 40%. За этими числами стоит вполне конкретное изменение работы: поддержку перестал останавливать вопрос, для ответа на который нужно заглянуть в код или логи.
Почему обращения доходили до разработчиков
В RetailCRM есть несколько линий поддержки. Если для ответа клиенту нужны знания и инструменты инженера, вопрос передают в разработку. Для таких обращений у нас организованы дежурства: один из разработчиков на две недели выходит из спринтов и занимается эскалациями. Это отдельная работа, которая конкурирует за время команды с развитием продукта.
Причины эскалации бывают разными. В одном случае достаточно выяснить, как именно работает код, что поменялось в релизе или что записано в логах. В другом за обращением обнаруживается баг, который нужно исправить и выпустить. Время решения второго случая включает существенно больше действий, поэтому смешивать эти ситуации при оценке результата неудобно.
Раньше техническое исследование из первой группы могли выполнить только инженеры. С Orpheus такой анализ стала делать даже первая линия поддержки. Человек по-прежнему разбирается в вопросе клиента, но агент помогает достать сведения из систем, в которых находится ответ.
Агенту нужен доступ к истории работы
Orpheus мы развиваем как сквозного агента компании. В более раннем посте я уже рассказывал, что он участвует в разных бизнес-процессах, включая задачи по улучшению самого Orpheus. Поддержка стала одним из прикладных сценариев.
В нашем случае агент может изучить код, поискать в логах, поднять историю коммитов, прочитать детали задач и посмотреть последние релизы. Эти источники дополняют друг друга. Код показывает текущую реализацию, история изменений помогает понять её происхождение, задача содержит контекст, а логи дают сведения о конкретном событии.
Именно полнота данных сильно влияет на полезность ответа. Если агент видит только текст обращения, ему остаётся рассуждать по описанию симптомов. Доступ к рабочим системам позволяет продолжить исследование. При этом сам факт подключения системы ещё не делает любой ответ правильным: вывод нужно соотнести с найденным кодом, событиями и условиями обращения.
Что изменилось в показателях дежурств
Отчёт мне тоже помог собрать Orpheus. В исходной публикации я привёл три изменения:
| Показатель | Изменение | Что он описывает |
|---|---|---|
| Обращения, дошедшие до разработки | −37% | Нагрузка от эскалаций на дежурных инженеров |
| Медианное время решения разработчиком | −27% | Время решения обращения в середине упорядоченного ряда |
| Среднее время решения разработчиком | −40% | Среднее по обращениям, чувствительное к долгим случаям |
В посте нет размера выборки, абсолютного числа обращений и точных границ базового периода сравнения. Поэтому эти проценты описывают наш внутренний результат в опубликованном виде. По ним нельзя рассчитать, сколько часов мы сэкономили, оценить статистическую устойчивость изменения или пообещать такой же эффект другой компании.
Я связываю улучшение с тем, как Orpheus вошёл в работу поддержки и инженеров. Но это наблюдение за рабочим процессом, без контрольной группы. Оно само по себе не отделяет влияние агента от возможных изменений состава обращений и других условий работы.
Почему среднее снизилось сильнее медианы
После подключения Orpheus до разработчиков всё равно доходят сложные вопросы. Их инженеры тоже исследуют вместе с агентом. Медиана снизилась на 27%, а среднее — на 40%. Для интерпретации этой разницы важен наш способ учитывать решение обращения.
Если причиной оказался баг, вопрос считается решённым после выхода исправления в продакшен. Между найденной причиной и этим моментом проходят постановка задачи, изменение кода, тесты, CI, ревью и выпуск. Долгие случаи сильнее влияют на среднее время, чем на медиану, поэтому ускорение такого пути может заметно сдвинуть среднее.
В исходном посте я отметил и продолжающееся снижение показателя по месяцам. Без полного ряда и описания расчёта превращать это наблюдение в отдельный прогноз было бы преждевременно. Для дальнейшей оценки полезно смотреть и медиану, и среднее, а рядом держать число обращений и долю случаев с исправлением кода.
От исследования до MR в одном рабочем процессе
Разбор обращения теперь может идти так:
- Инженер вместе с Orpheus исследует причину проблемы.
- Когда причина найдена, агент получает поручение оформить задачу.
- Orpheus готовит MR с исправлением.
- Изменение проходит ревью, слияние и выпуск.
- После появления исправления в продакшене обращение отмечается решённым.
Здесь полезна непрерывность работы. Сведения, которые понадобились для исследования, нужны и при постановке задачи, и при подготовке исправления. Агент может участвовать в нескольких последовательных действиях, а инженер ведёт разбор и оценивает результат. Самостоятельное создание MR не отменяет ревью и остальных этапов выпуска.
Такой сценарий отличается по трудоёмкости от подготовки текста ответа. Поэтому оценка только скорости генерации сообщения пропустила бы существенную часть результата. В нашем процессе конечная точка для бага находится в продакшене.
С чего начинать внедрение в своей поддержке
Мой главный вывод из этого опыта связан с данными. Если история задач, изменения кода, релизы и события системы доступны только отдельным людям, агенту будет трудно собрать связную картину. Сначала придётся наладить хранение этих сведений и доступ к ним в рабочем процессе.
Практический старт я бы ограничил одной группой обращений: вопросами, которые сегодня передают инженеру ради чтения кода, логов или истории релизов. Для них можно описать нужные источники, подключить инструменты и посмотреть, помогает ли результат первой линии отвечать клиенту. Затем считать эскалации и время решения, фиксируя период, объём и состав обращений.
Orpheus показал нам, что доступ поддержки к инженерному контексту меняет распределение работы. Часть исследований остаётся у поддержки, а сложные случаи быстрее проходят через разработку. Чтобы оценить этот эффект у себя, нужно измерять весь путь обращения до принятого ответа или выпущенного исправления.
Материал может пригодиться коллегам? Отправьте им ссылку на статью.