Почему нельзя полагаться на пользовательские отчёты об ошибках

Мы в Parallels достаточно внимательно анализируем пользовательские отчёты об ошибках. У нас на этот счет внедрена автоматизированная система учета и обработки данных. Специально обученные люди работают с информацией и лечат болячки у пользователей. Однако, не все разделяют нашу философию. Под катом интересное мнение Ника Харли ^[1] на портале Medium. В комментариях можно отлично подискутировать на заданную тему.

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

Разработчики ПО большую часть своего времени тратят на задачи, не связанные с созданием. Они проводят встречи, обсуждают спецификации, планируют и наводят порядок в существующем коде. И, конечно же, их «любимая работа» — фиксить баги.

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

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

Какую версию браузера вы используете? Какую ОС? Вы можете сказать точно, куда вы кликнули? И что потом произошло? На какой странице вы были перед этим? Как вы попали на этот экран? Так много вопросов и так мало (полезных) ответов. Отладка проблемы может занять вечность!

Полагание на пользовательские отчёты об ошибках

Многие команды разработчиков до сих пор полагаются на пользовательские отчёты. Сегодня это настоящее безумие. Это как в сетевых фаст-фуд-забегаловках просят посетителей самих убирать за собой со стола и очищать подносы. Еда может быть ужасной, но люди послушно относят свои подносы к урнам, опустошают их и уходят. Если никто не жалуется, то персонал считает, что все довольны. Но люди больше не возвращаются.

Некоторые разработчики считают, что пользователи сами могут о себе позаботиться при использовании их приложений. Если никто не сообщает о проблемах, значит их нет, верно? Неправильно возлагать на пользователей обязанность сообщать о проблемах, с которыми они сталкиваются. Из-за этого вы получите данные примерно об одном проценте всех установленных копий, а технические подробности будут скудны и неконсистентны.

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

Ваше приложение не такое хорошее, как вам кажется

Как-то я разговаривал со своим другом, который работает на большого онлайн-ретейлера. Он рассказал, как они нашли большую проблему в их системе онлайн-заказов, о которой никто не знал.
Спустя несколько дней разбирательств они не смогли найти причину проблемы. Тогда они решили попробовать определить и диагностировать ошибки в своих приложениях с помощью отдельного инструмента. То, что они обнаружили, внушало тревогу.

Оказалось, что на одном из восьми серверов кончилась память и он кидал ошибки. Из-за этого полностью стопорился процесс обработки пользовательских заказов. Одна из восьми сессий обработки заказа оказывалась битой. Обнаружение и решение этой проблемы немедленно привело к росту продаж на $20 000 в месяц! Клиенты больше не сталкивались с трудностями при покупках.

В компании подсчитали, что баг повлиял примерно на 5 000 пользователей — но за всё это время было всего два обращения в службу поддержки. Этот факт стал большим разочарованием, хотя команда и радовалась решению проблемы. Общие потери дохода из-за бага составили около $100 000.

Отправлять себе письмо при возникновении ошибок — дурацкая идея

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

Кажется до тех пор, пока вы её не реализуете.

Вы можете сделать что-то подобное:

Но это может привести к новым проблемам.

Генерировать письма при возникновении ошибок может быть удобно на маленьких побочных и личных проектах. Но с ростом размера проекта ситуация будет ухудшаться. Сильно ухудшаться:

• Мало подробностей для диагностики
• Трудно настроить правила уведомлений, поэтому вас будет заваливать событиями
• Исключение, пойманное в бесконечном цикле, может за ночь сгенерировать вам 50 000 писем
• Ошибки не делятся по приоритетности или заметному влиянию на пользователей, все они выглядят равноценными
• Когда вам начинает приходить больше ста писем, вы перестаёте их читать

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

ELMAH  — журналируем исключения

ELMAH (Error Logging Modules and Handlers) это подключаемый модуль для журналирования ошибок. Его можно динамически добавлять к работающему ASP.NET ^[2] веб-приложению, или даже ко всем ASP.NET веб-приложениям на машине, без перекомпилирования или переразвёртывания.

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

По сути, ELMAH — NuGet-пакет для .NET веб-приложений. Он журналирует в выбранном вами хранилище все исключения, возникающие на одном и более веб-сайтах. В отличие от других подобных фреймворков, ELMAH автоматических журналирует каждое исключение, будучи сконфигурированным в своём простейшем виде. Конечно, для журналирования специфических ошибок доступен API, но многие используют только автоматизированную часть. Давайте её рассмотрим.

Отличное руководство по началу работы ^[3].

Отдельные инструменты для генерирования отчётов об ошибках и падениях

Если вы серьёзно подходите к вопросу обработки ошибок и падений вашего приложения, то используйте специализированный инструмент мониторинга ^[4]. Это позволит автоматически определять и диагностировать проблемы, влияющие на ваших пользователей, за счёт добавления провайдера в код вашего приложения. Всего несколько строк кода.

Это поможет вам:

• Отфильтровать незначительные исключения и сфокусировать на действительно важных проблемах.
• Настроить конфигурируемые уведомления через почту, Slack или HipChat.
• Использовать один инструмент для отслеживания нескольких языков и платформ.
• Применять группирование ошибок.
• Держать всю команду в курсе ошибок и их решений.

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

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

Будьте проактивны и пожинайте плоды этого подхода

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

Можно внедрить в рабочие процессы мониторинговые инструменты, чтобы облегчить процедуру исправления багов. Но поступающие данные зачастую оказываются «загрязнёнными» и отделёнными от контекста в других системах.

Будущее мониторинга ошибок заключается в том, чтобы все команды — фронтенда, бэкенда, управления и поддержки — имели исчерпывающее представление о каждой проблеме, с которой сталкиваются пользователи. И могли сразу приступить к её решению. Это относится и к грядущим тенденциям в сфере непрерывной доставки и развёртывания. Вы можете применять фиксы и отправлять в production в течение минут после идентификации проблемы. Не нужно ждать недели до развёртывания следующей минорной версии.

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

З.Ы. В Parallels все немного иначе. Как все работает мы писали тут ^[5] и тут ^[6].

Автор: Дмитрий Смиркин

Источник ^[7]