Not a kernel guy

… in the Windows kernel team

Friday, April 27, 2007

Как послать баг-репорт в Microsoft? Часть II.

Литературное «отчет о программной ошибке» конечно правильнее, но «баг-репорт» в три раза короче и в сто раз привычнее.

Предыдущий пост про отправку баг-репортов в Microsoft хотя и написан дурака валяючи, однако содержит в себе рациональное зерно. На данный момент нет никакого другого официального способа сообщить о найденной ошибке в Windows, кроме как сделать это через службу поддержки. Нельзя, например, просто послать письмо на какой-нибудь bugs@microsoft.com. Более того, обращение в службу поддержки – это платная услуга в общем случае. И не смотря на то, что Microsoft не возьмет деньги в случае, если наличие ошибки или недокументированного поведения будет подтверждено, сам факт отпугивает многих. «Я оказываю им услугу и я ещё должен за это платить? Ни за что!»

Имеет ли смысл подобная практика? Как это ни странно такая практика может иметь рациональное объяснение.

Disclaimer: Я понятия не имею, какова на этот счет официальная позиция Microsoft. Всё нижесказанное – сугубо моё личное мнение.

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

Косвенным подтверждением этой теории может быть тот факт, что большинство продуктов, для которых можно отправить баг-репорт через страницу MSDN Product Feedback предназначены для разработчиков. Ожидаемый процент хороших баг-репортов от них должен быть заметно выше, чем в случае «обычного пользователя».

В таком случае обращение через службу поддержки выступает в роли дополнительного барьера, который должен повысить качество получаемых баг-репортов:

  • Во-первых если уж пришлось связаться с поддержкой, отчет должен быть весьма подробным;
  • Во-вторых, платить за то, чтобы исправлять чужие ошибки не хочется. Следовательно отчет должен быть еще более подробным.
Posted at 11:57 am •

RSS feed | Trackback URI

11 Comments »

Comment by Alexey. — April 28, 2007 @ 12:33 am

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

 
Comment by Dron — April 28, 2007 @ 1:35 am

Разгребать кучу багов - это святая обязанность девелопера (в глобальном смысле этого слова). Можно не разводить баги кучами. Тогда и количество багрепортов будет меньше.

Кстати вот я подумал… В системе Windows есть служба, которая пытается посылать багрепорты в Майкрософт. Их кто нибудь разгребает или они сразу фильтруются? :D

 
Comment by Александр — April 28, 2007 @ 3:51 am

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

Посчитаем: с миллиона пользователей, с вероятностью отказа 1 за 10^5 часов (один отказ в 10 лет. Стандартная цифра для потока отказов серийного коммерческого оборудования без дублирования) будем иметь порядка 10 отказов в час. Объем внедрения винды я оцениваю в 100-300 миллионов (вероятно, больше). Таким образом, каждый час происходит не менее 1000-3000 отказов из-за сбоев железа. Рассчитывая по минимуму 15 минут работы человека хотя бы на классификацию отказа, получим что для обработки только отказов из-за сбоев оборудования понадобится от 750 до 2250 квалифицированных специалистов, занятых на полный рабочий день только этим. Более того, эти специалисты будут очень часто уходить, потому что такая работа - это мучение.
Такие расходы не может себе позволить НИКТО. Поэтому максимум, что мы можем иметь от производителя с объемом внедрения в 100 миллионов, это автоматизированную систему сбора статистики и пирамидальную систему сбора информации о отказах, при этом нижнюю часть пирамиды должны оплачивать сами пользователи.
Что, собственно, мы и наблюдаем.

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

 
Comment by Not a kernel guy — April 28, 2007 @ 12:21 pm

 

Этим самым вы подтверждаете свое нежелание работать (разгребать кучу баг репортов).

Почему? Отчеты фильтруются в зависимости от их “полезности”, если полезностью считаь вероятность исправления багов. Правило 20% отчетов приведет к исправлению 80% багов здесь работает.

Этим самым вы подчеркиваете свое интелектуальное превосходство.

Господи, а это здесь каким боком?

Кстати вот я подумал… В системе Windows есть служба, которая пытается посылать багрепорты в Майкрософт. Их кто нибудь разгребает или они сразу фильтруются? :D

Они сортируются автоматически (определяется модуль в котором произошла ошибка, находятся дубликаты и т.п.), а потом разгребаются руками. Наиболее “горячие” баги исправляются в первую очередь.

 
Comment by Not a kernel guy — April 28, 2007 @ 12:28 pm

 

Поэтому максимум, что мы можем иметь от производителя с объемом внедрения в 100 миллионов, это автоматизированную систему сбора статистики и пирамидальную систему сбора информации о отказах, при этом нижнюю часть пирамиды должны оплачивать сами пользователи.

Да. Реальная картина наверняка отличается в деталях. Но в целом скорее всего так и есть.

 
Comment by timothy — May 3, 2007 @ 12:50 am

 

Этим самым вы подтверждаете свое нежелание работать (разгребать кучу баг репортов).

Скорее невозможность разгрести такую кучу плохих багрепортов с приемлемыми затратами.

Этим самым вы подчеркиваете свое интелектуальное превосходство. (они такие тупые.

Даааа! Мы, девелоперы, ужасно умные! А поскольку закон о запрете дискриминации за тупость так и не приняли, мы всех гнобим как можем :-)!

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

Даже собственные тестеры пишут много плохих багрепортов. Про юзеров и говорить нечего. Люди просто не умеют описать баг как следует. Тут очень специфичные требования, нужно описать ВСЕ, что-бы девелоперы смогли воспроизвести сбой. Для этого крайне желательно повторить баг несколько раз и определить, что действительно важно для того что-бы он повторился, а что нет. Описания типа “когда я вставляю в ворде большую картинку он виснет” - это не баг, а мусор. Но разгребать этот мусор очень тяжело.

PS. Я не работал в МС, но работал в большой команде разрабатывающей продукт с большим количеством пользователей.

 
Comment by Neandertalets — May 3, 2007 @ 6:41 am

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

 
Comment by Neandertalets — May 3, 2007 @ 7:03 am

Исходя из прочитанного можно предположить, что мс просто не выгодно не только разбирать багрепорты (это указано четко), но и написание системы создания/обработки багрепортов.
Естественно: создание этой системы денег не принесет, а вот деньги стричь с пользователей - вполне! Как за информацию о собственных багах, так и за за исправление этих же багов: http://thevista.ru/page.php?id=8217.
Тут в одном комментарии прочитал:
“Тотальная распространенность винды в данном случае играет против нее, т.к. многократно (на порядки) возрастает цена ЛЮБОЙ ошибки”.
Разница только в том, что ЦЕНА ОШИБКИ возрастает для ПОЛЬЗОВАТЕЛЕЙ, а для мс это и лишний повод подзаработать.

 
Comment by Alexey. — May 3, 2007 @ 7:26 am

 

Даже собственные тестеры пишут много плохих багрепортов. Про юзеров и говорить нечего. Люди просто не умеют описать баг как следует. Тут очень специфичные требования, нужно описать ВСЕ, что-бы девелоперы смогли воспроизвести сбой. Для этого крайне желательно повторить баг несколько раз и определить, что действительно важно для того что-бы он повторился, а что нет. Описания типа “когда я вставляю в ворде большую картинку он виснет” - это не баг, а мусор. Но разгребать этот мусор очень тяжело.

Только не надо мне это объяснять.
Это ваша работа - разгребать мусор возникший из-за ваших писулек.
Понапишут сперва говна всякого, а потом - им видити ли тяжело разгребать мусор.
В зеркало посмотрись, программист хренов.

 
Comment by Not a kernel guy — May 3, 2007 @ 8:27 am

 

Исходя из прочитанного можно предположить, что мс просто не выгодно не только разбирать багрепорты (это указано четко), но и написание системы создания/обработки багрепортов.

Написание системы создания и обработки багрепортов - вполне себе выгодно. Более того, такая система существует. DrWatson или ProblemReports and Solutions Service (Vista) - это оно и есть. Страницу MSDN Product Feedback тоже никто не отменял.

 
Comment by vladygin — October 26, 2007 @ 9:54 am

Premier Support Stats: 2000/xp и выше

Blue screens из 10 :

8 - драйвера, железо

1 - софт 3d party, фильтр драйвера антивирусов, фаерволов и т.п.

1 - потенциально сбой самой Windows.

Дальше веселее

Практически для всех продуктов по которым мы имеем много hotfix решений для инцидентов,
есть соотв. connect.microsoft.com, где можно оное отправить напрямик.

Для стабильных продуктов нахождение бага без написанного хотфикса или описания оного в KB(как минимум в SR базе поддержки с Workaround или Fix) за год работы не встретил ни разу. :)

 

Your Comment (smaller | larger)

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress