Блог

5% всех установленных Windows "падают" два или более раз в сутки, заявил Билл Гейтс в интервью New York Times -- правда, было это в 2003 году. Какова же интенсивность программных крэшей спустя 10 лет?

[spoiler]Не изменилось ничего, а на фоне определенного развития методологий программной инженерии, ситуация не улучшается, а ухудшается, потому что грамотных разработческих компании фактически становится меньше. Посмотрим только на нынешнее лето.

Баг в обновленном антивирусном Symantec Endpoint Protection 12.1 вывел из строя немало ПК с Windows XP -- клерки увидели синий экран смерти, причем восстановление системы потребовало немалых усилий.

12 июля Skype внезапно принялся рассылать отправляемые текстовые сообщения не только адресату, но и случайным пользователям.

Корректировка мирового времени на секунду вывела из строя немало систем -- похоже, даже побольше, нежели в период Y2K. Например, отказали многие Java-программы, включая Hadoop, в результате засбоили Reddit, Mozilla, LinkedIn и даже Amazon Web Services.

В обновленной iOS из-за бага в Apple FairPlay DRM для App Store отказались работать самые разные приложения -- от Ski Safari и Yahoo Search до Angry Birds Space.

На MacBookPro/Air под Apple OS X 10.7.4 программа Adobe InDesign привела к краху -- оказалась, что Apple внезапно изменила внутренний API, не слишком озаботясь информированием разработчиков.
Неработоспособной оказалась и связка MacBookAir + Google Chrome -- при попытке закрыть табы браузер перезагружал ОС. Причина оказалась в конфликтах с драйверами, используемыми Хромом для аппаратного ускорения.

Из-за программного бага стремительно разряжаются аппаратики Samsung Galaxy S III -- система настройки ошибочно задает ток в 34 mA, хотя должно быть 3,4 mA.

В Лондоне в результате наплыва туристов к Олимпиаде посыпались местные социальные сервисы и форумы.

Королевский банк Шотландии 19 июня испытал один из крупнейших ИТ-сбоев, в учетный хаос оказались втянуты Ulster Bank и Nat West. Последствия "разгребались" около месяца. Причина как выяснилось, в том, что ради экономии банк зааутсорсил собственные крупные ИТ-проекты в Индию (примерно в три раза сэкономив на зарплатном фонде), ну и получил "индийское качество". Журналисты выяснили, что это массовая практика английских банков! Причем нередки случаи, когда разработчики из развивающихся стран ничтоже сумняшеся коннектятся по Интернету к внутренним рабочим базам банков…

Не помогает даже дублирование систем: длиннейший в истории Твиттера двухчасовой останов 21 июня был связан с тем, что в ЦОДе почти одновременно отказали обе системы, и основная, и дублирующая, причем по разным причинам. Просто случайность.

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

С какой стати разработчики софта перекладывают всю ответственность на нас, записывая в лицензионные соглашения немыслимые страховочные формулировки, и в погоне за профитом выпуская совершенно сырые продукты?

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

В качестве примера можно привести схему создания игр для приставок: японские заказчики предъявляют к ним крайне высокие требования, сами жестко и придирчиво тестируют создаваемые для них продукты (в результате слабых вещей практически не появляется), а проекты надо реализовать в сжатые сроки. И хотя оплата за приставочные игры очень хорошая, успешные исполнители фактически единичны. Потому что становящиеся все более массовыми "индийские методы разработки" тут не прокатывают -- исполнитель рискует собственными деньгами, и пару раз не уложившись в сроки и качество, обанкротится.