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

Метрики качества

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

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

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

Значительные сбои обычно идентифицируются и исправляются на оперативном уровне SRE и владельцами сервиса. Но что делать с менее заметными проблемами? Если 0,1% ошибок допустимы в каждом сервисе, то сколько процентов допустимо для всего продукта, в котором взаимодействует двадцать разных сервисов? Можно сложить все ошибки, но сложнее со скоростью работы продукта, где разброс для каждого сервиса может быть достаточно большим. А еще ошибки могут быть не критичными с точки зрения доступности сервиса, но важными, когда мы говорим о клиентском качестве.

С точки зрения управления качеством продукта возникают вопросы:

• Как пользовательский опыт связан с доступностью и скоростью работы каждого отдельного сервиса?

• Каковы требования к надежности и скорости работы каждого сервиса продукта?

• Как приоритизировать работы по повышению технического качества сервисов среди всех остальных продуктовых инициатив?

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

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

При этом сам продукт «Секретарь Олег» не критический, поэтому требования к части сервисов далеки от доступности 99,99%. Да и само понятие допустимого качества может отличаться для Секретаря и других продуктов, использующих те же самые сервисы. Для некоторых сервисов допустимое время ответа — 1 секунда, но если мы отправим запросы в три такие системы, то получится задержка при ответе Секретаря в 3 секунды, что уже неприемлемо с точки зрения пользовательского опыта.

Единая метрика технического качества

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

Основная работа происходит во время разговора абонента с Секретарем. Процесс состоит из ряда последовательных событий:

• поступает звонок на телефонию;

• запускается сессия распознавания речи;

• диалог запускается на диалоговой платформе;

• запускается сценарий разговора;

• Секретарь отвечает на каждую реплику абонента;

• после разговора текстовая расшифровка и аудиозапись направляется клиенту.

Процент технически успешных звонков мы определили так:

• обработка звонка прошла через все обязательные этапы: телефония → диалоговая платформа → сценарий → отправка расшифровки;

• на каждом этапе не было зафиксировано критических ошибок;

• задержки для пользователя на каждом этапе укладывались в допустимые; интервалы: до 2 секунд — время ответа Секретаря Олега, до 1 минуты — время получения расшифровки после завершения разговора.

Получилась вот такая метрика:

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

Вместе с метрикой у всех появился ряд вопросов. 

Какое значение должно быть у метрики? Ответ: мы не знаем. Метрику нельзя напрямую сравнивать с некими стандартными SLA, она спроектирована для одного флоу именно нашего продукта.

Это не метрика доступности, где мы ожидаем "три девятки". Здесь гораздо более жесткие требования - к скорости ответа, к отсутствию даже минорных ошибок. Если снизить требования к скорости ответа Секретаря, значение метрики будет выше, а если повысить требования, метрика заметно просядет. Важнее не абсолютное значение, а тренд и анализ причин, влияющих на снижение метрики. А также текущие продуктовые цели.

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

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

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

Как отделить естественную волатильность метрики от реальных проблем или тренда? Мы пробовали примерить несколько эвристических подходов, но они не увенчались успехом.

Нас выручил ML — применили разработку Тинькофф ETNA для анализа временных рядов. Система обучается на наших же данных и начинает предсказывать интервал допустимого значения для следующего дня. 

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

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

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

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

Наш опыт и советы

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

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

На будущее я сделал два вывода:

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

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

Надеюсь, статья была полезна и вы дочитали ее до конца. Еще я делюсь заметками и кейсами о работе в телеграм-канале «Чуть больше продакта», а если у вас есть вопросы — жду в комментариях!