Переход количества в качество
Очень в тему качества программного обеспечения пришлась сегодняшняя презентация по Online Crash Analysis.
Но сначала хочется рассказать историю одного бага.
У нас был баг в обработчике прерывания мыши. В течении 7 (семи!) лет. Вдумайтесь в это: в мире 600 милионов пользоватлей Windows, подавляющее большинство из них активно пользуется мышкой, сколько раз возникает прерывание? Каждый раз когда мы двигаем мышь или нажимаем на кнопку, причем множество раз во время движения. Десятки раз в секунду на сотнях милионов машин в течение 7 лет вызывался один и тот же обработчик прерывания и в нем был баг, приводящий, понятное дело, к синему экрану.
В чем баг?
Обработчик не знает позицию мышки, знает только что что-то изменилось, соответственно он должен спросить мышь о ее текущем положении в некотором смысле.
Он спрашивает - ответа нет. Спрашивает еще - ответа нет. Если в третий раз ответа нет, это занимает слишком долго (в IBM PC пока вы обрабатываете какое-то прерывание, остальные прерывания того же уровня или ниже запрещены, так что это очень плохая практика писать "долгие" обработчики прерываний), соответственно он говорит "ладно, узнаем потом при помощи DPC (defered procedure call)". Баг был в неправильных параметрах DPC, поскольку все это в ядре - синий экран.
Почему не нашли?
Потому что любая мышь, подключенная к компьютеру проводом отвечает с превого раза. Любая беспроводная - максимум со второго. Когда же они не отвечают? Когда у беспроводной мыши сели батарейки _после_ того, как включили компьютер. Кто, скажите мне, будет тестировать с почти севшими батарейками? Как часто они садятся-то вообще? Вот в том-то и дело.
Это все тестировали милионы раз и не нашли.
Как нашли? При помощи Online Crash Analysis (OCA). После того как система упала, при следующей перезагрузке пользователю предлагается послать дамп в Майкрософт. Многие их посылают (это мини-дамп, его даже по модему передать можно очень быстро - 64К всего).
(Отступление про частную жизнь: перед тем как посыалать из дампов удаляют все, что позволило бы идентифицировать пользователя - IP адрес, MAC адрес, BIOS signature, CPU ID и т.д. То есть нам иногда даже и хотелось бы иметь эти данные (чтобы например узнать от того же человека приходит этот краш или нет), но у нас нет такой возможности - в дампах нет ничего, что позволило бы нам узнать, а кто это нам его послал).
Так вот с распространением беспроводных мышей этот баг стал возникать чаще и чаще, его наконец заметили, посмотрели в дамп и нашли. При помощи OCA.
Так вот некоторая статистика с OCA (они получают все эти дампы со свего мира и анализируют их):
Для 32% "синих экранов" мы знаем в чем проблема и у нас есть либо фикс, либо мы знаем у кого фикс (см. ниже). То есть в каждом третьем случае достаточно отправить дамп в Microsoft и проблема разрешится. Это уже не лотерея, это игра в которую можно выиграть. Реальная польза я замечу.
На сегодняшний день наблюдается следующая статистика по "синим экранам":
5% - Microsoft
12% - "железо" (то есть неправильно работающая аппаратура, включая память и прочее)
83% - драйверы третьих фирм
То есть даже если мы бы смогли пофиксить _все_ свои ошибки, насколько это улучшило бы ситуацию с качеством вообще? На 5%.
На пять процентов.
На сегодняшний день нельзя начать распространять новый драйвер так, чтобы мы не узнали о нем в течение 48 часов. Почему? Потому что он будет падать и пользователи будут это репортить нам.
44000 (сорок четыре тысячи) уникальных драйверов для Windows в мире (не считая версий). Более 20 _абсолютно_ новых - каждый день. Более 600 - новых версий каждый день.
Это включает в себя и чисто программные драйверы для антивирусов и т.п.
Из каждых 20 синих экранов - 16 эти самые драйверы. Минимум два - железо. И только один - мы. Ну пофиксим мы свой, а толку-то?
Так вот поинт в том, что для систем такого уровня сложности (современный компьютер вместе со всем установленным на нем железом и софтом) не существует хороших способов добиваться надежности. Те кто говорят про то, что надо тестировать и это решит все проблемы просто не представляют себе в чем собственно состоят проблемы.
Те кто считают что Microsoft must die и где-то лучше просто не представляют себе в чем собственно проблемы.
Драйвер написанный NVIDIA для Линукс (поставляемый в виде бинарника кстати) или для Windows - это драйвер написанный NVIDIA, и он будет рушить систему.
Все, абсолютно все коммерчески успешные операционные системы на сегодня - с монолитным ядром. И Линукс, и NT, и BSD. Даже MacOS, который вроде как должен быть на микроядерном Mach - на самом деле с монолитным ядром (они его сделали таким). Почему? Потому что они коммерчески успешные. Микроядерные технологии не работают достаточно быстро даже на сегодняшний день. А это значит что ошибка любого компонента в пространстве ядра выносит всю систему.
Важно понимать что кто угодно может написать программку в тысячу строк, в которой не будет ни одной ошибки. Можно написать приложение в 10K, в котром не будет ни одной ошибки. Есть методы писать приложения в 100K без ошибок. Однако все это не масштабируется. Не существует методов писать программыне системы в сотни милионов строк - проблемы там совершенно другие.
Да, надо менять подход к разработке софта кардинально, и есть люди (и мы знаем некоторых из них), которые именно этим и занимаются.
Но на сегодняшний день было бы наивно думать что существует способ решить проблемы с качеством индустриального софта. Или что существует промышленный софт, у которого нет проблем с качеством.
Но сначала хочется рассказать историю одного бага.
У нас был баг в обработчике прерывания мыши. В течении 7 (семи!) лет. Вдумайтесь в это: в мире 600 милионов пользоватлей Windows, подавляющее большинство из них активно пользуется мышкой, сколько раз возникает прерывание? Каждый раз когда мы двигаем мышь или нажимаем на кнопку, причем множество раз во время движения. Десятки раз в секунду на сотнях милионов машин в течение 7 лет вызывался один и тот же обработчик прерывания и в нем был баг, приводящий, понятное дело, к синему экрану.
В чем баг?
Обработчик не знает позицию мышки, знает только что что-то изменилось, соответственно он должен спросить мышь о ее текущем положении в некотором смысле.
Он спрашивает - ответа нет. Спрашивает еще - ответа нет. Если в третий раз ответа нет, это занимает слишком долго (в IBM PC пока вы обрабатываете какое-то прерывание, остальные прерывания того же уровня или ниже запрещены, так что это очень плохая практика писать "долгие" обработчики прерываний), соответственно он говорит "ладно, узнаем потом при помощи DPC (defered procedure call)". Баг был в неправильных параметрах DPC, поскольку все это в ядре - синий экран.
Почему не нашли?
Потому что любая мышь, подключенная к компьютеру проводом отвечает с превого раза. Любая беспроводная - максимум со второго. Когда же они не отвечают? Когда у беспроводной мыши сели батарейки _после_ того, как включили компьютер. Кто, скажите мне, будет тестировать с почти севшими батарейками? Как часто они садятся-то вообще? Вот в том-то и дело.
Это все тестировали милионы раз и не нашли.
Как нашли? При помощи Online Crash Analysis (OCA). После того как система упала, при следующей перезагрузке пользователю предлагается послать дамп в Майкрософт. Многие их посылают (это мини-дамп, его даже по модему передать можно очень быстро - 64К всего).
(Отступление про частную жизнь: перед тем как посыалать из дампов удаляют все, что позволило бы идентифицировать пользователя - IP адрес, MAC адрес, BIOS signature, CPU ID и т.д. То есть нам иногда даже и хотелось бы иметь эти данные (чтобы например узнать от того же человека приходит этот краш или нет), но у нас нет такой возможности - в дампах нет ничего, что позволило бы нам узнать, а кто это нам его послал).
Так вот с распространением беспроводных мышей этот баг стал возникать чаще и чаще, его наконец заметили, посмотрели в дамп и нашли. При помощи OCA.
Так вот некоторая статистика с OCA (они получают все эти дампы со свего мира и анализируют их):
Для 32% "синих экранов" мы знаем в чем проблема и у нас есть либо фикс, либо мы знаем у кого фикс (см. ниже). То есть в каждом третьем случае достаточно отправить дамп в Microsoft и проблема разрешится. Это уже не лотерея, это игра в которую можно выиграть. Реальная польза я замечу.
На сегодняшний день наблюдается следующая статистика по "синим экранам":
5% - Microsoft
12% - "железо" (то есть неправильно работающая аппаратура, включая память и прочее)
83% - драйверы третьих фирм
То есть даже если мы бы смогли пофиксить _все_ свои ошибки, насколько это улучшило бы ситуацию с качеством вообще? На 5%.
На пять процентов.
На сегодняшний день нельзя начать распространять новый драйвер так, чтобы мы не узнали о нем в течение 48 часов. Почему? Потому что он будет падать и пользователи будут это репортить нам.
44000 (сорок четыре тысячи) уникальных драйверов для Windows в мире (не считая версий). Более 20 _абсолютно_ новых - каждый день. Более 600 - новых версий каждый день.
Это включает в себя и чисто программные драйверы для антивирусов и т.п.
Из каждых 20 синих экранов - 16 эти самые драйверы. Минимум два - железо. И только один - мы. Ну пофиксим мы свой, а толку-то?
Так вот поинт в том, что для систем такого уровня сложности (современный компьютер вместе со всем установленным на нем железом и софтом) не существует хороших способов добиваться надежности. Те кто говорят про то, что надо тестировать и это решит все проблемы просто не представляют себе в чем собственно состоят проблемы.
Те кто считают что Microsoft must die и где-то лучше просто не представляют себе в чем собственно проблемы.
Драйвер написанный NVIDIA для Линукс (поставляемый в виде бинарника кстати) или для Windows - это драйвер написанный NVIDIA, и он будет рушить систему.
Все, абсолютно все коммерчески успешные операционные системы на сегодня - с монолитным ядром. И Линукс, и NT, и BSD. Даже MacOS, который вроде как должен быть на микроядерном Mach - на самом деле с монолитным ядром (они его сделали таким). Почему? Потому что они коммерчески успешные. Микроядерные технологии не работают достаточно быстро даже на сегодняшний день. А это значит что ошибка любого компонента в пространстве ядра выносит всю систему.
Важно понимать что кто угодно может написать программку в тысячу строк, в которой не будет ни одной ошибки. Можно написать приложение в 10K, в котром не будет ни одной ошибки. Есть методы писать приложения в 100K без ошибок. Однако все это не масштабируется. Не существует методов писать программыне системы в сотни милионов строк - проблемы там совершенно другие.
Да, надо менять подход к разработке софта кардинально, и есть люди (и мы знаем некоторых из них), которые именно этим и занимаются.
Но на сегодняшний день было бы наивно думать что существует способ решить проблемы с качеством индустриального софта. Или что существует промышленный софт, у которого нет проблем с качеством.