SmirkinDA Aug 17 2017 at 18:14

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

5 min

8.7K

Parallels corporate blogIT systems testing*Programming*Client optimization*Debugging*

+24

Comments 17

zerg59 Aug 17 2017 at 20:44

Почему то сразу вспомнил Хауса:
Д-р Хаус: Все лгут.
Д-р Кэмерон: Доктор Хаус не любит общаться с пациентами.
Д-р Форман: Разве лечение пациентов не то, зачем мы стали врачами?
Д-р Хаус: Нет, лечение заболеваний — вот почему мы стали врачами.

xavier87 Aug 17 2017 at 20:55

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

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

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

Rambalac Aug 18 2017 at 08:51

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

xavier87 Aug 18 2017 at 11:40

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

У меня был опыт агрегирования нескольких уведомлений в один емейл. Как пример — слать не менее 10 (20 или 100, на ваш вкус) сообщений в одно письмо или не чаще раза в те же 10 минут — внутри будете видеть всё те же сообщения, но писем меньше. Это по крайней мере решит проблему тонны писем.

denzabenza Aug 18 2017 at 22:41

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

sim-dev Aug 17 2017 at 21:02

Когда я увидел картинку с ошибкой — стало понятно, почему багов становитЬся больше.

Busla Aug 17 2017 at 21:21

Какую версию браузера вы используете? Какую ОС?

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

posledam Aug 17 2017 at 21:35

Почему средство для уведомления об ошибках не может быть умнее? Не может быть реализовано, как самостоятельно действующий отдельный маленький сервис. Ну например, не слать по одному письму на каждую ошибку, а собирать дайджест. Не слать больше 5 штук писем в день, а скромно одним письмом сообщить, что там прилетело 50 тыс. ошибок, и похоже это одна и та же ошибка в цикле? :)

AlexeyGorovoy Aug 17 2017 at 22:26

Это потому что разработчики неграмотные. Тся.

lxsmkv Aug 18 2017 at 00:27

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

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

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

x3DekMs Aug 18 2017 at 08:51

Зачем обсуждать грамотность разрабов? Причем тут это, опечатка может быть у каждого.

Nakosika Aug 18 2017 at 12:56

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

alexdin Aug 18 2017 at 22:41

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

RPG18 Aug 18 2017 at 23:50

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

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

dimkrayan Aug 18 2017 at 22:41

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

MgmZog Aug 18 2017 at 22:58

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

Именно поэтому у вас уже больше года нет движения по весьма неприятному багу с камерой в parralels на macOS?
kb.parallels.com/en/124015

SmirkinDA Aug 22 2017 at 15:35

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