Как компании, стремящейся к успеху клиентов, для нас важно выявлять и решать проблемы как можно быстрее, в идеале до уведомления клиентов. Написание идеального кода, вероятно, невозможно, но каждый разработчик стремится к тому, чтобы отловить в нашем коде исключения до того, как они повлияют на клиентов.
Установка трекера исключений - отличный первый шаг к раннему обнаружению проблем. Однако существует большая разница между сообщением о каждой ошибке и сообщением о важных исключениях. Если вы когда-либо проходили вводный курс психологии, вы, возможно, слышали о Избирательном внимании и Невнимательной слепоте, где психологи изучают, как человеческий мозг выбирает сосредоточиться на определенных стимулах, когда несколько из них возникают в однажды. Здесь, в Olark, мы обнаружили, что без точно настроенного процесса создания отчетов и обработки исключений у нас иногда возникали проблемы с выделением сигнала из шума.
Согласно Sentry, системе отслеживания ошибок в реальном времени, мы регистрировали 91 событие в минуту. Стартапу очень легко увязнуть в суматохе, толкая платформу вперед и отмахиваясь от ошибок, связанных с длинным хвостом, которые могут накапливаться на заднем плане. Имея такое количество стимулов, мы обнаружили, что фокусируем наше внимание на чем-то другом.
К счастью, мы знали, что большинство из этих 91 события в минуту не оказали прямого влияния на наших клиентов, но все же это было далеко не идеально. Как разработчики, мы знали, что можем добиться большего и сделать наш трекер ошибок полезным инструментом в процессе отладки и достойным маркером качества кода в целом.
Мы решили копнуть глубже и посмотреть, что можно сделать, чтобы снова обратить внимание на значимые исключения.
Вот что мы обнаружили:
Мы регистрировали слишком много ошибок
Ограничение скорости - отличная вещь. Когда у нас действительно время простоя и одно и то же не работает для всех, действительно нет необходимости получать сотни уведомлений, сообщающих об одном и том же исключении. Но если вы регистрируете так много нерелевантных исключений, что постоянно ограничиваете скорость, вы рискуете случайно отфильтровать уникальные исключения.
Мы решили, что нашей основной мерой успеха этого проекта будет снижение процента наших исключений с ограничением скорости. Мы посмотрели на некоторых из наших сильных нападающих: исключения, которые бросали тысячи раз в месяц. Что-то действительно не так? Правильно ли мы выдавали ошибку, и если да, то почему мы выдавали ее так часто? Можем ли мы вместо этого использовать другой метод, например ранний возврат, чтобы выйти из рабочего процесса?
В конце концов мы решили, что правильно выкидываем ошибки. У нас было несколько случаев, например, при вводе неправильного адреса электронной почты или информации о кредитной карте, когда была допущена ошибка, но не исключение. Проблема заключалась не в том, что мы выдавали ошибки, проблема в том, что мы сообщали об этом как об исключениях. Уменьшив количество исключений, о которых мы сообщали, мы освободили гораздо больше места для того, чтобы важные из них поднялись наверх.
Необычные исключения
К счастью, Сторожевые клиенты предоставляют нам настройку конфигурации, позволяющую игнорировать определенные исключения по умолчанию. Вместо того, чтобы использовать общую Ошибка и регистрировать почти все из них, мы начали подклассифицировать все наши ошибки и регистрировать только те, о которых, как нам казалось, нам больше всего хотелось бы знать (например, ошибки сервера).
Мы также обнаружили еще один потенциальный способ устранить некоторые бессмысленные исключения. По умолчанию Sentry устанавливает глобальный обработчик ошибок, который перехватывает любые ошибки в браузере, включая те, которые не имеют ничего общего с нашим веб-сайтом - например, исключение расширения браузера. Sentry позволяет игнорировать исключения из определенных URL-адресов или, в качестве альтернативы, заносить в белый список некоторые URL-адреса для эксклюзивного прослушивания. Мы создали пакет npm под названием Lumberjane, который содержит наши настройки игнорирования для всех наших интерфейсных приложений, что помогло уменьшить шум.
После успешного игнорирования этих ожидаемых ошибок и сосредоточения нашего внимания на реальных исключениях наша статистика начала очень быстро улучшаться. Вскоре скорость ограничивалась только во время простоев, и когда мы действительно посмотрели на Sentry, мы действительно обнаружили новые исключения, которых не видели раньше, которые проливают свет на проблемы, которые мы уже изучали.
Отсутствующие контексты
Расследование исключения, произошедшего несколько недель назад, может быть непростым делом. Обычно мы развертываем код несколько раз каждый день. Если вы не очень хорошо знакомы с конкретной ошибкой, если до развертывания осталось больше нескольких дней, потребуется серьезное копание, чтобы выяснить, какое развертывание было источником ошибки. К счастью, это простое решение, поскольку Sentry’s Release Feature помечает каждое исключение коммитом git.
Мы также не в полной мере использовали тот факт, что Sentry позволяет помечать исключения с помощью дополнительного контекста, например идентификатора пользователя или адреса электронной почты. Благодаря тому, что мы прилагаем такие важные детали, легче увидеть, сколько и каких клиентов затронуло данное исключение, и, что еще лучше, позволяет нам напрямую связываться с клиентами, если мы заметим что-либо касающееся.
Иногда контекст исключения был нечитаемым
Даже когда мы знали, что возникает проблема, наши разработчики интерфейса часто тупо смотрели на минифицированный код. Минифицирующий код отлично подходит для быстрой загрузки приложений, но человеческий глаз практически не может увидеть его.
Более того, в наших тестовых средах исключения нашего внешнего интерфейса были еще более загадочными, поскольку у Sentry не было доступа к нашим файлам, защищенным VPN. Все, что нам нужно было сделать, это то, что где-то в гигантском конкатенированном файле javascript произошло исключение.
К счастью, Sentry позволяет нам выгружать исходные карты на их серверы напрямую. Благодаря этому процессу мы можем видеть соответствующие файлы как часть трассировки стека, точно такими, какими они были, когда мы писали код, без минификации, и до того, как они были перенесены из ES6 или Coffeescript.
Мы не определили четкую стратегию приоритизации исключений с низким уровнем серьезности
Последним, но не менее важным был вопрос о процессе. Хотя исключения с высокой степенью серьезности легко оправдать, тратя время на работу над проектами, мы, как команда, не всегда знали, что делать с ошибками низкой серьезности. В то время как Olark как компания очень доверяет инженерам, которые работают над тем, что они считают важным, инженеру не всегда легко понять, сколько усилий нужно приложить для устранения ошибок низкой серьезности. Я считаю, что с трудными решениями я по умолчанию откладываю. Небольшие ошибки, которые мы могли устранить за несколько часов, просто оставались в очереди, и на нее становилось все сложнее смотреть.
Мы все еще проверяем, какой процесс лучше всего работает для нас как команды и для компании в целом. Одна из идей, которую мы пробуем, - поручать каждому разработчику одну ошибку в неделю исследовать в дополнение к их обычной работе. Это та сумма, которую мы в любом случае могли бы сделать самостоятельно, но в этом случае это формализованный процесс, который служит одновременно разрешением и поощрением сосредоточиться на мелкой картошке.
Выявив эти проблемы и изучив передовые методы их решения, мы перешли с 91 события в минуту до 1–3 событий в минуту, от почти всегда ограниченного по скорости Sentry до ограничения по скорости только во время фактических простоев. . Мы определенно можем вносить улучшения, и мы все еще учимся, но мы прошли долгий путь в создании инфраструктуры и процессов, которые будут поддерживать инженеров в создании высококачественного кода, что, мы надеемся, приведет к упрощению и плавности работы для наших клиентов. .
Об авторе: Сара Зингер - обработчик обратных вызовов в Olark. Она живет в Нью-Йорке и любит научную фантастику, долгие прогулки по городу и волонтерство, чтобы сделать техническую сцену Нью-Йорка более привлекательной.
Хотите прочитать больше подобных статей?
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсуждать рекламные и спонсорские возможности.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
