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

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

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

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

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

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

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

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

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

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

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

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

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

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

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