Компания Embrace спонсировала этот пост.
Категория наблюдаемости программного обеспечения возникла на пике цифровой трансформации, когда серверные службы масштабировались и переходили к микросервисам, системы становились все более распределенными, и ключевой задачей было отслеживание коренных причин задержек, сбоев и ошибок в разросшейся инфраструктуре. Если вызов API не удался или служба замедлилась, инженеры хотели знать, почему.
Такое мышление привело к гонке телеметрических вооружений. Собирайте все, храните все, запрашивайте все и надейтесь, что ответы появятся через трассировки, журналы и показатели.
Но эта структура, хотя и актуальна для многих серверных систем, в корне не соответствует сегодняшней реальности: пользователи не взаимодействуют с вашей инфраструктурой; они взаимодействуют с вашим продуктом.
На мобильных устройствах и в Интернете проблемы с производительностью связаны не только с циклами процессора или утечками памяти. Они о человеческом восприятии, принятии решений и взаимодействии. Это более сложный и менее детерминированный мир. И это то, для чего традиционная наблюдаемость просто не предназначена.
Производительность имеет влияние на человека
В мире внешнего интерфейса отключение может произойти задолго до того, как будет выдана ошибка или обнаружен сбой. Когда задержка увеличивается, даже незначительно, пользователи воспринимают ваше приложение как неработающее. Они подпрыгивают. Они прекращают совершать сделки. Они отказываются от потоков.
Возьмем, к примеру, приложение авиакомпании: если оно не загружается быстро, путешественник может сдаться и позвонить в ваш колл-центр, что увеличит эксплуатационные расходы и ухудшит качество обслуживания клиентов. Или они найдут другого оператора. Или возьмем приложение для социальных сетей: если временная шкала не отображается мгновенно, пользователь выходит и переходит к следующему приложению, работающему в режиме реального времени, и вы теряете вовлеченность, доход и показы рекламы.
Тем не менее, менеджеры по продуктам и дизайнеры часто не понимают, как время загрузки или незначительные сбои в UX влияют на вовлеченность. Результат? Слепые зоны. Регресс производительности проникает в производство. Уведомления приходят слишком медленно. Смена планировки вызывает разочарование. И единственный сигнал, который кто-то видит, — это падение уровня удержания, которое они не могут объяснить (или, что еще хуже, отсутствие сигнала вообще).
Бинарная ловушка: почему фронтенд-команды остаются в неведении
Большинство фронтенд-команд не выработали культуру детального измерения и итерации производительности. Они часто рассматривают производительность как двоичную: либо она «в порядке», либо «полностью испорчена».
Но это не то, как пользователи это воспринимают. Производительность существует в широком спектре, и большая часть разъединения происходит в серой зоне, когда все происходит достаточно медленно, чтобы разочаровывать, но не настолько плохо, чтобы инструменты мониторинга могли это заметить.
Это фундаментальный недостаток сегодняшних методов наблюдения: компании создали инструменты, которые сообщают им, не удалось ли выполнить запрос, но не сообщают о том, сдался ли пользователь на полпути процесса бронирования. Они могут измерять продолжительность трассировки, но не могут измерить, упала ли скорость реагирования пользовательского интерфейса ниже порога, из-за которого пользователи остаются на месте.
Пришло время для нового определения наблюдаемости, которое фокусируется на том, как производительность влияет на опыт и поведение конечных пользователей.
Подход, ориентированный на пользователя, исключает догадки
Настоящая наблюдаемость, ориентированная на пользователя, задает простые вопросы, например: «Может ли ваша команда уверенно измерить, как время загрузки и задержка влияют на реальное взаимодействие пользователей в ключевых потоках?» и «Знаете ли вы, как отслеживать техническую производительность наиболее важных и влияющих на прибыль точек взаимодействия вашей компании на вашем сайте и в мобильном приложении?»
Для большинства организаций ответ — нет. Это огромная возможность стать лучше.
Используя стандартизированную телеметрию, потоки пользователей и поведенческие сигналы, команды могут начать соотносить производительность с фактическими результатами: выполняют ли пользователи запланированное действие? Они выпадают? После релиза они ведут себя по-другому?
Например, при запуске новой функции в производство команды должны иметь возможность видеть, взаимодействуют ли с ней пользователи, надежно ли она работает, а если нет, то почему. Была ли это задержка рендеринга? Запутанный интерфейс? Регресс во времени загрузки? Это нехорошо иметь; это ключ к созданию продуктов, которые пользователи действительно хотят использовать.
Переосмысление наблюдаемости в отношении путешествий пользователя
Подумайте о концепции временной шкалы сеанса. Это полезно, но это лишь часть картины. Что нам нужно, так это пути пользователя — карты, которые объединяют ключевые шаги, точки входа, выхода и точки трения. Эти путешествия позволяют командам визуализировать, как производительность, ошибки или несоответствия дизайна снижают вовлеченность.
Например, мы видели, как критические точки отказа возникают из-за таких мелочей, как соглашения об именах или выбор формулировок. Когда эти детали сочетаются с задержкой, они создают серьезные проблемы, однако традиционные инструменты наблюдения редко выявляют эти нюансы.
Вместо того, чтобы спрашивать: «Вернул ли сервер статус 200?» мы должны спросить: «Действительно ли пользователь выполнил действие?» А если нет, «Какие сигналы могут объяснить почему?»
Понимание того, как производительность влияет на вовлеченность
Нам нужно выйти далеко за рамки того, что предоставляют аналитика продуктов, отчеты о сбоях и инструменты ведения журналов. Мы должны решить фундаментальную, но часто упускаемую из виду проблему: предоставить командам по работе с клиентами и продуктам возможность понять, как производительность влияет на вовлеченность пользователей.
Да, мы должны заботиться о сбоях и проблемах, когда приложения не отвечают (ANR). Но это верхушка айсберга. Мы должны понимать длинный хвост проблем, которые незаметно подрывают доверие и использование: повторные попытки, вызывающие пульсирующие загрузочные экраны, незначительные изменения макета, которые расстраивают пользователей, или снижение производительности, которое остается незамеченным до тех пор, пока рост не остановится.
Инструменты продуктовой аналитики могут показывать тепловые карты и гневные клики для продуктовых и маркетинговых команд, но они не говорят инженерам, почему. Чрезмерно упрощенные решения могут показать уровень ошибок, но не влияние на удержание пользователей. Нам необходимо преодолеть этот разрыв.
Будущее: измерение того, что важно
Мы считаем, что инженерные группы не должны спрашивать: «Какой у нас показатель ANR?» во время стендапов. Им следует спросить: «Показывают ли какие-либо из наших ключевых потоков ухудшение поведения пользователей со времени последнего выпуска?»
Это сдвиг. И в Embrace мы создаем инструменты для его поддержки. Связывая телеметрию с сигналами взаимодействия, объединяя действия пользователей и делая надежность видимой (а не просто отслеживаемой), мы надеемся помочь командам быстрее принимать более разумные решения.
Чтобы узнать больше о том, как наблюдение, ориентированное на пользователя, может повысить производительность и надежность вашего пользовательского опыта, ознакомьтесь с тем, что мы создаем в Embrace.
Embrace — это ориентированная на пользователя платформа наблюдения, которая связывает техническую производительность с воздействием на конечного пользователя. Embrace, основанный на OpenTelemetry, обеспечивает реальный мониторинг пользователей на мобильных устройствах и в Интернете, поэтому инженерные группы могут быстрее решать проблемы, повышать производительность и предоставлять исключительные цифровые возможности. Узнайте больше Последние новости от Embrace TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Эндрю Таналл — президент и директор по продуктам Embrace. До Embrace он был вице-президентом по продуктам в New Relic, где он разработал практику облачной наблюдения New Relic, включая разработку бессерверной наблюдения. До выхода New Relic…. Подробнее от Эндрю Таналла
