Внутренняя и внешняя настройка отслеживания ошибок

Question

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

Более продвинутая (и прозрачная) версия: Позволяет клиенту регистрировать (и наблюдать за ходом) его ошибки непосредственно в вашем багтрекере. Такие системы, как JIRA, позволяют использовать профили для получения определенных прав доступа и т. Д.

Но теперь вопрос : ошибка, поднятая пользователем, не обязательно преобразуется в 1 ошибку в конкретном модуле / методе / EJB / классе. Версия (вашего) веб-приложения, которое он использует, не переводится в версию класса, которая вызывает ошибку. Как вы поддерживаете внутреннюю часть билета со всеми неприятными подробностями и в то же время с билетом «сделайте так, чтобы пользователь чувствовал себя хорошо» (нужно больше информации, принято, выполняется,…)? Создание 2 билета на внутренний и внешний? Связать их?

Какие-нибудь умные рецепты, чтобы поделиться?

Answer 1

Отделите систему ошибок от системы отслеживания поддержки клиентов и разрешите связи между ними.

• Ошибки могут относиться к нулю, одному или нескольким тикетам в службу поддержки.
• Билеты поддержки клиентов могут относиться к нулю ошибок (например, проблема клиента не имеет никакого отношения к вашему программному обеспечению), одной ошибке (если это действительно проблема в вашем программном обеспечении) или более чем одной ошибке (случается дерьмо).

Выполнять запросы как:

• Какие клиенты ждут решения ошибки X
• Какие клиенты ждут открытых критических ошибок
• С какими ошибками уже столкнулся пользователь Y
• ...

Вы также заметите, что у каждой базы данных будет своя «скорость». В моей ситуации у меня примерно в 4 раза больше обращений в службу поддержки, чем с настоящими ошибками.

Answer 2

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

Подробнее:

http://countersoft.com/downloads/whitepapers/Implementing_an_Issue_Management_Platform.pdf

Answer 3

Каждый комментарий в JIRA имеет поле «Доступно для просмотра», в котором можно указать роль группы или проекта, для которой этот комментарий является видимым. Вы можете использовать это, чтобы скрыть "неприятные подробности".

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

Answer 4

Самый разумный способ - это иметь две системы или альтернативный механизм, позволяющий конечным пользователям отправлять сообщения об ошибках (по электронной почте). Основная проблема не столько в том, что ошибка не обязательно преобразуется в один метод в классе, но в основном в том, что если у вас больше, чем несколько пользователей, peopel не будет читать существующие ошибки и думать дальше, чем «кнопка не работает».

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