Что происходит с отчетами об ошибках?

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

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

1) выполнить в командной строке операцию chkdsk /r для любого несистемного диска.

В связи с тем, что воспроизвести проблему не составляет труда, информация о ней быстро расползлась по сети. Последующие публикации и комментарии к ним показали, что эта проблема проявилась у многих, при этом проблема проявлялась у пользователей в двух видах: a) потреблении большого количества памяти и б) аварийном завершении работы Windows Explorer.

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

Как вы, наверное, догадались, я был не первым в Microsoft, кто увидел это сообщение. Команда File System незамедлительно приступила к расследованию проблемы. Однако, им тоже не удалось выявить аварийное завершение работы. Что до растущего потребления памяти, то, по их мнению, так и было задумано (флаг /r осуществляет блокировку и восстанавливает диск, поэтому мы думали, что перед тем, как приступить к выполнению работу, необходимо восстановить битые сектора - некоторые авторы нашумевших статей в результате тоже пришли к такому выводу). Мы решили подробнее изучить дампы и отчеты. Как сказано выше, в нашем распоряжении было и есть предостаточное количество необходимых инструментов.

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

Следует отдельно рассказать о том, что происходит, когда мы получаем отчет об аварийном завершении работы. Давным давно мы обходились всего двумя вариантами: 1) поднять руки и сдаться, если бы мы потеряли надежду отыскать причину ошибки или 2) приостановить работу и отправить сотрудников с терминальными отладчиками к пользователям в надежде найти воспроизводимый случай. Ни один из этих вариантов не эффективен, а второй к тому же, как бы героически это ни звучало, не приносит ожидаемых результатов. Даже если сбой имел место, мы не могли определить, был ли это единичный случай или с проблемой сталкивались многие пользователи. Нам приходилось принимать решения, не имея нужной информации.

С распространением Интернета и появлением в наших продуктах телеметрии (не только в Windows 7) сегодня у нас довольно-таки четкое представление об состоянии наших продуктов. Когда мы впервые слышим об аварийном завершении работы, мы проверяем, не зарегистрирован ли подобный сбой на миллионах других компьютеров. Это позволяет собрать статистику, но совершенно бесполезно, если сбой имеет место в одной конкретной конфигурации. Однако, сбой в данной конфигурации, проявившийся на статистически релевантной выборке, является причиной задуматься. Мы, к примеру, можем опросить все стэки вызовов, чтобы понять, была ли в момент сбоя в памяти та или иная программа.

В случае, если зафиксирован сбой, в нашем распоряжении есть широкий перечень инструментов. Вы могли видеть их работу в случае сбоя. Мы можем увеличить количество необходимых данных. Мы можем разместить статью в базе знаний в качестве ответа на конкретную ошибку (и вы будете уведомлены об этом через Windows 7 Action Center). Мы можем даже сказать "эй, позвоните нам". Как бы странно это не звучало, в большинстве случаев это помогает. Если же обнаружена ошибка в уже завершенном продукте, тогда ситуация меняется — причиной ошибки может быть новое устройство, новый драйвер или иной программный продукт. Как правило, обычное подтверждение изменений помогает нам диагнозировать проблему. Помню, как однажды у многих пользователей Word стал завершать работу с ошибкой. Мы ничего не меняли. Оказалось, что была выпущена новая версия популярного дополнения и именно она стала причиной сбоя, но пользователи винили в ошибке Word. Мы быстренько разместили инструкции по удалению дополнения и начали работу с авторами дополнения над исправлением. Это умение видить меняющееся окружение, диагнозировать и отвечать на проблему кардинальным образом изменило наш подход к устранению ошибок в продукте.

Мы в непрерывном режиме изучаем новые и часто повторяющиеся проблемы (включая сбои, зависания, неудавшиеся установки, потенциальные уязвимости и т.д.). На самом деле, в течение каждого месяца мы обрабатываем сотни отзывов, получаемых от наших корпоративных клиентов и OEM-партнеров (и IHV, и ISV). Мы часто видим, что проблемы решаются изменениями вне ядра Windows (например, в драйверах, прошивках или приложениях). Мы не перекладываем ответственность и помогаем компаниям устранять причины ошибок. Мы также вносим многочисленные изменения в код Windows, выпуская ежемесячные обновления, хотфиксы и пакеты сервисных обновлений. Львиная доля изменений неприменима ко всем компьютерам, поэтому мы не торопимся с их распространением. Однако, если проблема носит массовый характер, мы стремимся распространить обновление как можно скорее. Очень важно понимать, со сколь серьезно ответственностью мы подходим к вопросу обеспечения комфортной работы основной массы пользователей, стараясь сбалансировать объем изменений, применимых для этих пользователей.

Для того, чтобы вернуться к разговору об утилите chkdsk, давайте окунемся в события, произошедшие за последние пару дней в нашем подразделение. Для начала мы скурпулезно просмотрели данные телеметрии на наличие информации о сбоях (на уровне пользователей и уровне "синих экранов") и не обнаружили ни одного сбоя, вызванного утилитой chkdsk. Мы также внимательно просмотрели существующие отчеты, собранные в ходе разработки Windows 7, но и здесь мы не обнаружили ничего похожего. Мы изучили стэки обращений существующих отчетов об ошибках (различных ошибок, зафиксированных с момента появления информации об этой) и не обнаружили ни одного сбоя, произошедшего в тот момент, когда была запущена утилита chkdsk.exe. Затем мы приступили в автоматизированным тестам на широком перечне конфигураций, продолжавшимся в течение 2 последующих дней. Мы виделы отчеты, связанные с конкретной аппаратной конфигурацией, поэтому мы подготовили свыше 40 компьютеров на базе того чипсета, с различными вариантами драйверов и прошивок, и снова запустили автоматизированные тесты. Никаких сбоев обнаружено не было (об увеличении потребления памяти мы говорили выше). Поскольку некоторые пользователи говорили о зависаниях, мы провели тесты с оператором и вновь не обнаружили проблем в работе ОС. Мы расширили тестирование, попросив других сотрудников Microsoft по всему миру (знаете, в нашей компании громадное число конфигураций, поскольку офисы находятся в различных уголках мира) провести тесты. Несколько отчетов о сбое упоминали об появлении сбоя при отсутствии виртуальной памяти, но это не могло являться причиной, поскольку эта утилита, как и любая иная программа, требующая памяти больше, чем физически доступно, могла привести к подтормаживаниям и поэтому не рекомендована к использованию (нарушение этих рекомендаций является одной из наиболее распространенных проблем, которые невозможно воспроизвести). Тем, кому интересно, рекомендую ознакомиться со статьей в блоге Марка Руссиновича о файлах подкачки. Несмотря на то, что нам не удалось ничего обнаружить, это вовсе не отрицает возможности существования ошибки, но это является свидетельством того, что шансы наличия ошибки на большинстве используемых систем крайне малы.

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

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

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

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

Стивен Синофски (Steven Sinofsky)


Источник: http://blogs.msdn.com/e7ru
Перевод: deeper2k