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

Пользователи образования, такие как учащиеся Codecademy, не являются исключением. Мы видели, как люди вообще отказывались от обучения программированию из-за одной-единственной ошибки в образовательном продукте. Поэтому создание дружественной и стабильной среды для нас еще важнее.

В Codecademy мы поэтапно переносили наш основной веб-сайт на новую систему Next.js, интегрированную с Datadog для телеметрии. В этом сообщении в блоге рассказывается, как мы используем панели мониторинга, мониторы и запросы Datadog в Codecademy, чтобы свести к минимуму сбои интерфейса.

Ошибки веб-интерфейса Цели

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

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

  1. Классификация: знание того, что уже существует на сайте, знание того, что критично, а что нет для исправления, и связывание этих предупреждений для постоянного повышения прав.
  2. Сокращение: сокращение количества основных сбоев путем их исправления или переклассификации по мере необходимости.

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

Классификация ошибок

Обычно мы считаем, что существует три класса ошибок, при этом ошибки по умолчанию имеют статус 🔥 Действующие до тех пор, пока они не будут понижены:

  • 🔥 Действенный: реальные сбои в коде, которые мы должны рассматривать как ошибки и исправлять
  • 🤷 Все: как 🔥 требующие принятия мер ошибки, так и те, которые обычно находятся вне нашего контроля, но мы хотели бы знать о всплесках, таких как сбои при загрузке ресурсов.
  • 🙈 Игнорируется: те, которые полностью находятся вне нашего контроля, например, из-за сбоев браузера и расширений браузера.

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

Единая информационная панель

Мы настроили центральную панель управления Datadog, содержащую визуализацию запросов по 🔥 действующим и 🤷 недействующим ошибкам. Панель инструментов начинается со ссылки на нашу центральную страницу документации Notion. Каждому запросу присваивается строка с таблицей, показывающей самые высокие ошибки попадания, а также красивая цветная диаграмма временных рядов, отображающая те же самые ошибки:

Каждый запрос также имеет краткое объяснение справа со ссылкой на связанный с ним монитор Datadog, который использует тот же запрос для запуска предупреждения, если счетчик превышает пороговое значение в течение 5 минут.

Запросы, объяснение

Резервный запрос для 🤷 Все ошибки выполняется для всех ошибок, о которых сообщает Datadog его пакет browser-logs в производстве, с визуализацией, учитывающей уникальные сообщения об ошибках. Запрос поддержки отфильтровывает несколько известных причин внешних проблем, используя примерно такой синтаксис поиска по журналу:

*codecademy* -"*chrome-extension*" -"*ChunkLoadError*"

Объяснение каждой части:

  • *codecademy*: включать только стеки ошибок, которые называются нашим сайтом (таким образом, исключайте расширения браузера, которые не имеют к нам никакого отношения)
  • -*chrome-extension*: также исключите расширения Chrome, так как они очень распространены и иногда охватывают глобальные API, которые вызывает наш код.
  • -*ChunkLoadError*: игнорировать ошибки, вызванные падением сети в середине загрузки страницы, из-за которых Webpack не может загрузить фрагмент

Запрос поддержки для 🔥 Действующих ошибок аналогичен. Он также исключает известные 🤷 все ошибки. Например, исключая известную ошибку Chrome с приложениями React: -"Failed to execute '*': The node to be * is not a child of this node".

Сокращение ошибок

Наблюдение за ошибками — это здорово, но это не очень полезно, если разработчики не знают, как исправить эти ошибки и активно используют эти знания. Любая хорошая система нуждается в нескольких слоях документации, чтобы объяснить ее и вызвать интерес.

Для этой работы с ошибками внешнего интерфейса мы использовали:

  • Страница сводных документов в нашей команде Notion с более подробными подстраницами.
  • Презентация «коричневой сумки» для всей команды, когда она была выпущена
  • Heads-up и демонстрация в нашей ежемесячной инженерной синхронизации «все руки»
  • Серия неформальных пар в стиле «толпы», в которых мы вместе исправили главную ошибку и объяснили процесс отладки.

Отладка ошибок

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

Но! С помощью инструментов Datadog, исходных карт JavaScript и общих знаний о причудах браузеров мы можем превратить расследование ошибок в забавную загадку. Наши исследования ошибок, как правило, идут примерно по следующему пути:

  1. Определение контекста.Некоторые ошибки уникальны для конкретной пользовательской ситуации, что часто намекает или даже указывает на первопричину.
  2. Понимание стеков вызовов. Использование исходных карт для точного определения того, где в коде возникает ошибка и из какой цепочки вызовов функций.
  3. Локальное воссоздание: использование контекста и источника, чтобы попытаться воспроизвести сбой локально для отладки, если это возможно.

Определение контекста ошибки

Табличные представления запросов на информационной панели включают в себя действие контекстного меню при ошибках Query in RUM, которое приводит к странице Datadog RUM Analytics для поиска сообщения об ошибке.

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

  • Имя браузера: некоторые ошибки уникальны для одного браузера, например уникальные и мощные элементы управления конфиденциальностью и безопасностью Firefox.
  • Версия браузера: некоторые ошибки возникают только в старых или новых версиях, например, старые версии Chrome имеют пограничные случаи при обработке this области действия.
  • Язык: некоторые ошибки возникают только в определенных локалях, таких как необычные или недопустимые часовые пояса, установленные пользователями или их настройками конфиденциальности.
  • URI: некоторые ошибки возникают только на определенных страницах и/или запросах страниц.

🐛 Пример прошлой ошибки:TypeError: Illegal Invocation. Фасеты RUM показали, что ошибка уникальна для версий Chrome двухлетней давности. Это помогло сузить результаты поиска в Google до navigator.sendBeacon проблем с областью действия.
Решение: Codecademy/client-modules/pull/7.

Понимание стеков вызовов

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

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

🐛 Пример прошлой ошибки: Cannot read property 'style' of null. Карты исходного кода показали, что это было в коде, вызываемом старыми компонентами класса React, использующими устаревшие обратные вызовы ref с трудной для понимания обработкой асинхронной логики. Решение: мы провели рефакторинг, сделав хуки React более понятными и понятными.

Локальное воссоздание

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

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

🐛 Пример прошлой ошибки:Unable to fetch data from progress. Локальное воссоздание этого работало только при анонимном просмотре сайта, что намекало на то, что анонимным пользователям не удавалось получить данные из службы «прогресс».
Решение: мы запретили анонимным пользователям получать данные о прогрессе пользователя.

Заключительные мысли

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

Если вас интересует создание стабильных и приятных веб-приложений, мы нанимаем! codecademy.com/about/careers ✨

Большое спасибо моей отличной коллеге Мелани Мон за корректуру!