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



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



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

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

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

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



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

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


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

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

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

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


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

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

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

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

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


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

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

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

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

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

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



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

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


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

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



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

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

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


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

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

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



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

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

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


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

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

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

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

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

    Метки:
    Parallels 232,45
    Мировой лидер на рынке межплатформенных решений
    Поделиться публикацией
    Комментарии 17
    • +4
      Почему то сразу вспомнил Хауса:
      Д-р Хаус: Все лгут.
      Д-р Кэмерон: Доктор Хаус не любит общаться с пациентами.
      Д-р Форман: Разве лечение пациентов не то, зачем мы стали врачами?
      Д-р Хаус: Нет, лечение заболеваний — вот почему мы стали врачами.
      • +1
        Генерировать письма при возникновении ошибок может быть удобно на маленьких побочных и личных проектах. Но с ростом размера проекта ситуация будет ухудшаться. Сильно ухудшаться:

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

        Пришло письмо, открыл, разобрался, исправил. Больше писем по этой проблеме не приходило. ЧЯДНТ?
        • 0

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

          • 0
            Такие ошибки обычно отлавливаются тестированием. Или у вас ежедневных пользователей миллион, а тысяча — это капля в море, поэтому не словили вовремя, или баг воспроизводится раз в, скажем, 5-10 попыток, что уже говорит о действительно плохом коде.

            У меня был опыт агрегирования нескольких уведомлений в один емейл. Как пример — слать не менее 10 (20 или 100, на ваш вкус) сообщений в одно письмо или не чаще раза в те же 10 минут — внутри будете видеть всё те же сообщения, но писем меньше. Это по крайней мере решит проблему тонны писем.
          • 0
            даже если пользователь программы один, то все равно не так. исправление, отправка исправленной версии, установка этой версии пользователем — все это требует времени, в течение которого могут приходит письма с одной и той же ошибкой, которую «да я в курсе, уже исправляю».
          • +2
            Когда я увидел картинку с ошибкой — стало понятно, почему багов становитЬся больше.
            • +1
              Какую версию браузера вы используете? Какую ОС?

              Браузер сообщил это автоматически вашей форме обратной связи. Или по вашему человек в винду перегрузился чтобы в Word скриншот вставить, а так-то он исключительно из-под Centos покупки делает?
              • 0
                Почему средство для уведомления об ошибках не может быть умнее? Не может быть реализовано, как самостоятельно действующий отдельный маленький сервис. Ну например, не слать по одному письму на каждую ошибку, а собирать дайджест. Не слать больше 5 штук писем в день, а скромно одним письмом сообщить, что там прилетело 50 тыс. ошибок, и похоже это одна и та же ошибка в цикле? :)
                • +1
                  Это потому что разработчики неграмотные. Тся.
                  • +2
                    У нас все логи которые получаются при прогоне автотестов по системе, хранятся в базе, которая с помощью эвристик находит повторяющиеся ошибки, и заводит баг, и можно посмотреть те логи в которых ошибка была обнаружена, и кроме этого все тэги которые предположительно связаны с появлением этой проблемы.

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

                    А ошибки находит четырехступенчатый контроль качества, тестировщики в команде разработки, тестировщики на стороне заказчика тестирующие сборку на стендах, отдел контроля качества концерна который делает системные тесты через HIL, и приемочные тесты всей системы в тестировочной фабричной сборке.
                    • +1
                      Зачем обсуждать грамотность разрабов? Причем тут это, опечатка может быть у каждого.
                      • 0

                        Каждый найденный в моем коде баг просто орет: "ТЫ БЫЛ НЕПРАВ, ЭТО ТВОЯ ОШИБКА, ТВОЙ КОСЯК, ТЫ ВИНОВЕН, ТЫ ПОДВЕЛ КОМАНДУ И КЛИЕНТОВ!". В общем, именно поэтому мне не нравится искать и фиксить баги. Дзен позволяет держать покер фейс или даже шутить на эту тему, но это приобретенное умение. А высший шик это когда ты говоришь: "хочу больше багов, найдите мне больше багов!"

                        • 0

                          Согласен с автором, по поводу логирования всех ошибок, такой подход возможно использовать только на dev сервере так как при нагрузке за ночь вы можите получить лог в ~8MB из-за 1 одинаковой некритычной ошибкой, но с парой критичных ошибок которые попросту в ней потеряються.

                          • 0
                            ошибок которые попросту в ней потеряються.

                            Поэтому нужно логи/креши заливать куда-нибудь в эластик и группировать в кибане. Дальше достаточно просмотреть по парочке из каждой группе.

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

                              Именно поэтому у вас уже больше года нет движения по весьма неприятному багу с камерой в parralels на macOS?
                              kb.parallels.com/en/124015
                              • 0
                                Здесь засада в особенности работы macOS Sierra на определённых моделях Mac (Macbook Pro 2012 года в основном). Проблема выявлена при работе Parallels, VMWare и Virtualbox. Затык не на нашей стороне. Работаем над решением. К сожалению в новом релизе эта болячка пока сохраняется. Ребята обещают ее полечить в ближайших обновлениях. Скорость будет зависеть от взаимодействия с нашими партнерами.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.