Как тестируются программы, от которых зависит жизнь людей?

Недавно появилась статья, чем-то напоминающая много кем известную "Они пишут правильную вещь" (оригинал).

Мне кажутся интересными ряд моментов для передачи свойств предметной области. А вместо их выделения проще привести и перевести все целиком. Ниже мой перевод.

---

Как правило, обычный писатель программ-скриптов скорее всего не приводит полный пакет доказательств со всей строгостью формальной верификации. Это хорошо потому, что средний программист также не пишет программы для реактивных самолетов или атомных станций, или для роботов-хирургов. Но кто-то же пишет — и когда ваша жизнь окажется в руках его программы, то хорошо бы иметь высокую вероятность безошибочной её работы. И в тот момент, как вы можете быть уверенным в том, что этот человек, — не бездарность?

А никак. Что ставит другой вопрос: как этот тип программ тестируется?

Это было в небольшом посте блога, написанном Gene Spafford, профессором информатики в Purdue University, написанным на волне ответа на этот конкретный вопрос. Он ссылается на историю об истоках кокпитов, где началась применятся проводная связь — такие самолеты управляются в полете электроникой, внедрение чего случилось непосредственно в конце 1980х. Мы уже привыкли к таким самолетам, но тогда это был большой скачок вперед: прямой контроль был убран и передан в руки программного обеспечения, которое было разработано для телеуправления механическими приводами из кокпита. С того момента компьютер мог разбить самолет.

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

Spafford пишет:

В конце 1980х, где-то когда аэробус A340 был представлен (1991), тем из нас, кто работал над разработкой программного обеспечения, критичного к безопасности, рассказывали историю (возможно апокрифическую). Эта история о том, как программное обеспечение электронной авионики тестировалось на основных коммерческих авиалайнерах. Согласно истории, инженеры аэробуса реализовали и верифицировали согласно последним самым сильным формальным методам, предоставляли результаты проверки моделей и формального доказательства всего кода авионики. В то же время, согласно истории, Боинг выполнял обширное тестирование и рецензию кода, и принуждал всех своих инженеров программного обеспечения участвовать в первых полетах самолетов. Основным результатом истории было то, что для большинства из нас (как казалось) было то, что всем нам было более комфортнее лететь на самолете Боинга (было бы интересно посмотреть осталось ли таким же мнение сообщества программистов).

Таким образом, программисты Боинга имели дополнительную мотивацию потому, что им в будущем приходилось отдать свою жизнь в руки своего же программного обеспечения. Там, на высоте 9 000 метров, нет возможности что-то исправить — оно должно просто работать. И с чем вы будете более комфортно чувствовать: имея чей-то личный подход к верификации программного обеспечения (прим. оценка эксперта, рецензия), или, с другой стороны, имея кучу формальных доказательств и результатов имитационных испытаний?

Я бы предпочел и то и другое, но вопрос как тестируется это все интересен сам по себе. Ветка Stack Exchange 2011-го года предоставляет много интересного внутренней кухни данного процесса и его эволюции. Для начала, подход Боинга выходит из моды и в основном вышел из моды, согласно сообщению гуглера Uri Dekel:

Там серьезный шаг вперед в плане формальной верификации по сравнению со случайным функциональным тестированием. Государственные агенства, такие как НАСА и некоторые военные ведомства, тратят больше и больше денег на развитие этих технологий. Решение задач такого уровня все ещё PITA (pain in the ass — боль в заднице) для среднего программиста, но они намного более эффективны в тестировании систем, критичных по безопасности.

Scott Whitlock, инженер-программист, который поддерживает свою библиотеку для автоматического тестирования FluentDwelling, смотрит глубже, разьясняя проектные требования для безопасных трансляторов, являющихся системами промышленного применения для мониторинга оборудования, который передает сигналы предупреждения и может остановить сложное оборудование в случае необходимости. Они включают в себя, согласно Whitlock'y, "Два резервированных процессора, которые обычно запистываются от независимых источников питания, и выполненных конструкционно по-разному. Код, работающий на каждом процессоре, разработан двумя раными командами программистов, выполнивших свою работу в изолорованных друг от друга условиях. Результат вычислений обеих процессоров должен быть одинаков, иначе срабатывает реле безопасности."

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

Но что насчет космического корабля? В терминах критичности, космический корабль приблизительно как самолет, плюс система жизнеобеспечения и плюс сложнейшие математические проблемы аэронавтики.

"Это программное обеспечение никогда не падает" — пишет Charles Fishman. "Оно никогда не требует перезагрузки. Это програмное обеспечение без багов. Оно совершенно настолько, насколько это возможно из всего того, что было создано человеком. Посмотрите на эту статистику: как минимум три версии программы — каждая по 420 000 строк кода, имело только по одной ошибке. Последний 11 версий имели в общей сложности 17 ошибок. Типичные программы на рынке такой сложности будут иметь 5000 ошибок."

Как программисты НАСА все это делают? Ну, в основном им просто приходится. Малейший баг создает риск потери миллиардов доллагоров и жизней людей. И все это под пристальным вниманием публики.

Для кода как такового, идаельность приходит как результат в основном засчет прямой противоположности тому, что обычно ассоциируется под словом "программист". Креативность в команде Шаттла не приветствуется; работа в режиме 9х5; хитрый код и программисты-суперзвезды не приживаются; более половины команды женщины; отладка (debugging) практически отсутствует, так как ошибки являются редчайшим явлением. Программирование стало продуктом не кодеров и инженеров, а Процесса.

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

И далее:

Группа разработки должна предоставить код, который полностью лишен ошибок, настолько идеальным, что тестировщики не должны ничего найти. Группа тестирования должна идти далеко во множестве сценариев полетов и моделирования, и стараются выявить настолько много недостатков, насколько это возможно. Результат — то, что Tom Peterson называет "дружественно-враждебные отношения". "Они соревнутся в том, что найдет ошибки." говорит Keller. "Иногда они дерутся как кошки и собаки. Разработчики хотят поймать все свои ошибки. Верификаторы возмущаются, что это забирает их время, выделенное на проверку программного обеспечения."

Итак, что вы думаете, астронавт будущего? Программист, который летит на орбиту под контролем своего программного обеспечения, или программист из группы НАСА?

Алхимики современности или неразрешимые проблемы

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

Но алхимики никуда не исчезли. Они до сих пор среди нас, только декорации изменяются.

Здесь хочу выделить отдельный класс т.н. неразрешимых проблем и описать пару их свойств.

Современные примеры

Поиск серебряной пули

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

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

Поиск элексира вечной молодости

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

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

В этом контексте можно провести аналогию с автомобилем. Нет одного способа сделать так, чтобы машина всегда ездила исправно и без проблем (кроме как заменить все). Нужно регулярно проводить осмотр, менять масло и фильтры, ездить по правилам, не выходить за нормы эксплуатации, использовать качественное топливо и т.д.. Остается только представить, что человечество если что может починить автомобиль, так как оно его понимает, а биотехнологии ещё не дошли до того, чтобы понимать все в человеке. И даже когда мы будем все понимать, то будет существовать вероятность трагедии.

Знание языка

Имеется ввиду человеческого языка общения.

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

Легко обратить внимание, что на данном поле многие предлагают легкие пути освоения языка. Но царского пути нет, и использовать надо все доступные способы. Мы быстро учимся говорить когда нужно общаться вживую, быстро пополняем лексику если читаем книги, быстро учимся правильно писать если пишем и наши ошибки исправляют, мы можем научиться слышать язык только прослушав множество его носителей. Для результата надо использовать весь комплекс методов и средств.

General Problem Solver

Это мое прогностическое мнение. Не существует универсального AI, решающего любую проблему. Есть много разных AI с разной эффективностью, и естественный интеллект не исключение.

Было и будет много разных интеллектов. Много предлагателей универсальных интеллектов. Много попыток его построить с провалом, но с косвенными плюшками.

Свойства

Все свойства расписаны выше, но здесь их явная систематизация.

Кроме того, мое контекстное определение. Неразрешимая проблема — такая проблема, которая решается частично, но не может быть решена полностью, либо полное её решение слишком затратно; мы можем решить её частично, и улучшить результат, но полного решения нет.

Полезность и бесполезность попыток

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

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

Множество предложений простого способа

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

Нет простого способа

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

Оптимизм

Есть вещи, которые не таковы, какими мы хотели бы их видеть. Очень хочется иметь философский камень, универсальный молоток, элексир молодости и пр.. Но реальность не такова.

Заключение

Когда каркас данного сообщения был готов, то перечитал Брукса (его Мифический человеко-месяц, где есть No Silver Bullet с историей 10 и 20 лет спустя). И с восхитительным удивлением нашел там следующую цитату:

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

Turski W. M. And no philosophers’ stone, either // Kugler H. J. (Ed.). Information Processing 86. Amsterdam : Elsevier Science, North Holland, 1986. P. 1077-1080.

Что такое человеческий фактор

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

В будущем на автоматизированном заводе не должно быть кроме роботов никого, только один человек и собака. Зачем человек? Чтобы кормить собаку. Зачем собака? Чтобы смотрела за тем, чтобы человек ничего не трогал.

Сейчас обнаружил более оригинальное высказывание (в книге Fatal Defect, 1995), которое походу имеет также корни ещё на лет 10-15 глубже. Итак, шутка, которая ходит среди инженеров-разработчиков автоматизированных систем авионики:

Future automated airplanes will have only a pilot and a dog in the cockpit. The pilot will be included to reassure the passengers while the computers fly the plane. The dog is there to bite the pilot in case he or she touches anything.

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

Здесь выражается одна из идей автоматизации, что когда процессы становятся все более отлаженными и автоматическими, то это приводит к тому, что от человека ничего не зависит, и вообще он становится не нужным и даже вредным.

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

Приведенная цитата из книги принадлежит Nancy Leveson, она не является её автором, но от себя продолжает её так:

The pilot will also be there so that there's someone to blame in case of an accident.

Пилот также будет тем, кого можно будет обвинить в случае какого-либо происшествия.

Зачастую в случае различных происшествий называется человеческий фактор, формулируясь под видом «чего-то недосмотрели», «чего-то не учли», «не услышали сигнала» и пр.. Пара примеров.

Первый. Более подробное рассмотрение происшествия, описанного ранее. Во время снижения A320 получилось так, что пилоты задали слишком быстрое снижение и из-за этого врезались в гору. Однако за всем этим стоит нечто большее. В авионике за 20 лет до происшествия сделали обязательное правило для установки подсистемы, которая оповещает пилотов об опасности слишком низкой высоты полета. Эти подсистемы автоматически посылают звуковые сигналы с громкостью и частотой в зависимости от высоты полета. Однако в рассматриваемом деле на возможность исправить ситуацию с помощью их сыграло дополнительно два фактора. Во-первых, исторически получилось так, что зачастую реализация данных устройств оповещения была такой, что система до неприличия часто давала ложные срабатывания и поэтому пилоты привыкали к данным звукам и не обращали на них особого внимания. Со временем система улучшалась, но сотрудники авиакомпаний по-прежнему считали, что оповещения часто подвержены ошибкам. Во-вторых, для внутренних авиалиний Франции администрацией было принято решение, что раз это внутренние, то пилоты хорошо знают местность и для них такую систему можно просто не устанавливать. Таким образом получается, что на факт катастрофы повлияло как инженерное решение (слишком часто ложные срабатывания), так и административное (отсутствие оценки реальной опасности). Но в протоколах записано, что виноваты пилоты.

Второй. Нам на лекции как-то Анатолий Коврига рассказывал об одной из схем управления ж.д. стрелками. Со временем эксплуатации выяснился один дефект, который мог приводить (и привел) к опасному отказу (переводу стрелки в случае занятой секции, т.е. потенциально под поездом). Фактически это был инженерный просчет. После происшествия (аварии) схема была пересмотрена и в неё добавлен ещё один элемент — конденсатор, который был призван исключить возможность опасного отказа. Но особенность была в том, что конденсатор в этой схеме был с такими параметрами, что требовал очень аккуратного и регулярного обслуживания. В корпусе проблема была решена, но в реальности получалось так, что если происходит что-то страшное, то оказывался виноватым не разработчик, и не начальник станции, а электромеханик, который обслуживал данную схему и якобы забыл обслужить конденсатор.

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

Для решения есть ряд путей:

• Обучение обслуживающего персонала — лучшее понимание как работает система у тех, кто с ней работает.
• Создание более дружественного интерфейса и общая минимизация трудностей общения людей и системы — более человеческий интерфейс, разработчики должны писать код для людей (с обратной связью) а не чтобы просто написать и сдать.
• Создание системы принятия решений — для чрезвычайных ситуаций создание БД того, что если что-то произошло, то надо делать так-то.
• Отработка чрезвычайных ситуаций на симуляторе/имитаторе — например в авионике пилотов тренируют на разных сиутациях (отказали закрылки, ушли в штопор, внезапная потеря высоты) и потом они это уже делают более интуиутивно.
• Разработка более корректной и надежной системы как таковой.

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

Баг, о котором услышал весь мир (The "BUG" heard 'round the world)

10 апреля 1981 года, приблизительно за 20 минут до запланированного запуска первой американской космической транспортной системы, астронавты и технические сециалисты попробовали активизировать программную систему, выполненную с 4-хкратным резервированием и дополнительным запасным компьютером… но не смогли. Фактически, у них не было никакой возможности это сделать, так как компьютер просто не воспринимал команды… Это был баг, очень маленький, очень неуловимый, очень замысловатый и очень древний — это была ошибка в логике инициализации резервной системы. Это была ошибка, которая является кошмаром для программистов и руководителей, из разряда тех, которые «не могут произойти», даже если вы будете следовать всем правилам хорошего проектирования и разработки.

Самые глубокие секреты программной инженерии часто запрещаются к публикации и выявление причин проявления множества ошибок является чрезвычайно сложной задачей. Кроме того, корректную интерпретацию произошедшего может дать очень малое количество людей. Чаще всего получаются обрывочные факты, или множество несвязанных между собой или даже противоречащих друг другу фрагментов, а получить хорошо документированную историю крайне сложно. Peter G. Neumann говорит о том, что за годы его опыта самым эффективным способом является поиск ключевого инженера-разработчика всей системы или ответственного узла и попытка уговорить рассказать о том, что произошло.

Одним из самых известых багов в истории, которые при этом были документированы по описанному сценарию, является подготовка первого полета Шаттла 10 апреля 1981 года, когда контроллеры отменили запуск в космос шаттла Колумбия всего за 20 минут до намеченного времени. По этой причине на это обратила внимание мировая общественность и почувствовалось давление на то, чтобы подробности были раскрыты. Это был баг, который моментально стал извествен всему миру. Через некоторое время после проишествия Neumann нашел одного из разработчиков программного обеспечения, Jack'a Garman'a, и уговорил его раскрыть детали прозошедшего — именно так появилась эта публикация.

Для повышения надежности шаттл использует 4 идентичных компьютера, работающих по одной и той же программе, включенных в мажорирующую схему 2+2 с сильными связями, функционируя в горячем резерве. Это означает, что 4 компьютера разбиты на 2 пары, каждая из которых синхронизируется со своим «напарником». Если состояния пары одинаковы, то это считается корректной работой системы. Если одна из пар расходится во мнениях, то вся пара считается сломанной и управление переходит на вторую пару компьютеров. Синхронизация между парами происходит на каждом цикле внутренних часов. Данная организация позволяет защищаться от аппаратных проблем — например в случае сбоев из-за электромагнитного излучения.

Кроме описанных 4-х компьютеров в системе присутствует также 5-й компьютер, являющийся резервным. Его ПО обладает такой же функциональностью, но написано другими программистами и работающее под другой операционной системой — для обеспечения более высокого диверситета на программном уровне (в данном шаттловом случае компилятор и железо были одинаковыми с основной системой). Данный компьютер включается только в случае, когда обе пары из основной системы 2+2 выходят из строя, при этом резервная система управление и всю ответственность берет полностью на себя. Резервный компьютер программно призван отличаться от основного и в этом плане его назначение — избежать программных ошибок.

В описанной истории инженеры обнаружили баг временной синхронизации между описываемыми компьютерами. С вероятностью 1/67, которая срабатывает на каждом запуске системы, могло получится так, что часы синхронизации пары 2+2 и резерва окажутся на 1 такт впереди общих тактов синхронизации. Именно это произошло на реальной системе при пробной попытке запуска челнока за 30 часов до предполагаемого старта. В случае рассинхронизации получалось так, что старта основной системы не было, а резервный компьютер никогда бы не получил сигнала о том, что 2+2 вышли из строя. Следует заметить, что тысячи часов тестирования не смогли выявить описанную проблему.

В комплексе имелось три ленты времени — данные телеметрии, время для основной системы и время резервной. При подготовке к запуску заранее стартовала телеметрия (как обратный отсчет) и относительно её синхронизировались обе системы (основная и резервная), но время самого запуска в них системе вычислялось математически и по общим тактам. Далее, если происходила рассинхронизация, то получалось так, что время, которое оставалось до старта по расчету во время ожидания сигнала, становилось отрицательным (пришло время старта, ожидаем sync, а его нет). Число беззнаковое, поэтому оно становилось равным FF, т.е. конечному числу, а по меркам реальной системы — равному бесконечности.

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

В описанном я бы назвал несколько причин:

1. Синхронизация между двумя разными системами (основная работала в виде асинхронной с приоритетами (fixed priority executives), а резервная периодическая синхронная (cyclic executive)).
2. Разница сред тестирования и эксплуатации (таймеров).
3. Отстутствие аналитической проверки при внесении изменений, влияющих на время синхронизации.

И да, доказательство корректности имело все шансы поразить проблему точно в цель (;

В тюрьму из-за ошибки в программе?

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

Почта UK, работающая с ~11500 отделениями, в которых задействовано ~68000 сотрудников, по результатам ожесточенного спора с некоторыми из них признала то, что имеется дефект в её центральной системе. Более сотни людей говорили о том, что их преследовали по ошибке в судебном порядке для того, чтобы они выплатили деньги за то, что компьютер выполнил несуществующие транзакции. Часть из них потеряла репутацию, а несколько из них попало по этой причине в тюрьму.

В течение последнего года независимые расследователи, которые были наняты Почтой UK, проверяли несколько претензий от сотрудников. Несмотря на то, что они не нашли свидетельств систематических проблем в ядре ПО, они нашли баги (программные ошибки) в нем. Но вместе с этим было отмечено два проишествия в 2011 и 2012 годах, когда сам почтампт идентифицировал сбои (и полагаю, исправлял баланс) на сумму 9000 фунтов в 76 разных узлах.

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

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

Картина из новости №1: Jo Hamilton по итогам недели рассчитал, что должен оплатить 2000 фунтов по обороту. Звонит в офис, а ему говорят, что вы должны 4000. После выяснения оплачивает, и тут оказывается, что он должен уже 9000!

Картина из новости №2: один из сотрудников проработал на королевскую почту 40 лет, а сейчас ему 60 и он празднует свой день рождения за решеткой.

Независимые расследования продолжаются, а народ требует справедливости.

Fatal Defect & Computer Related Risks

Читаю сейчас книги Fatal Defect и Computer Related Risks. Сначала планировал по отдельности, но придется читать вместе.

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

Книги написаны в одно время и на одну тему, и, более того, основаны на очень похожем материале. Однако внутри имеют разные приближения к одной и той же проблематике. Computer Related Risks — весьма научная, где изложено все по полочкам и темам, по большей части сухая статистическая информация и тематический и факторный анализ. Fatal Defect — напротив, это книга для рядового читателя, где рассказывается множество различных случаев и историй, а сама книга читается как детектив и является хорошим кандидатом на то, чтобы вдохновить людей в или на данную область (Safety-Critical Systems).

Источники для книг основаны в первую очередь на Computer Risks Forum — это онлайновый ресурс, действующий с 1985 года. Его назначение — оповещение и обсуждение любых проблем, связанных с компьютерными рисками, но в первую очередь фокус ставится на больших системах автоматизации процессов, на системах, проблемы в которых могут приводить к большим экономическим потерям и угрожать здоровью и жизни людей. C самого начала существования форума его модератором является активист Peter G. Neumann (Harvard ph.D., длительное время работал в Bell Labs и ACM), занимающийся им в свое свободное время, — он же автор второй книги на моей картинке.

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

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

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

French Air Inter Airbus A320 crash

A French Air Inter Airbus A320 crashed into Mont Sainte-Odile (at 2496 feet) on automatic landing approach to the Strasbourg airport on a flight from Lyon on January 20, 1992. There were 87 people killed and 9 survivors. A combination of human factors (the integration of the controller and the humanmachine interface, and lack of pilot experience with the flightdeck equipment), technical factors (including altimeter failings), and somewhat marginal weather (subfreezing temperature and fog) was blamed. There was no warning alarm (RISKS 13, 05; SEN17, 2; 18, 1, 23; 19, 2, 11).

Крушение французского аэробуса A320 компании Inter Airline

Аэробус A320 французских авиалиний компании Inter Airline потерпел крушение в Mont Sainte-Odile (на высоте 2496 футов) при автоматической посадке в аэропорте Strasbourg во время рейса из Lyon'a 20 января 1992 года. Погибло 87 пассажиров и спаслось 9. Сочетание человеческого (интеграция контроллера и человеко-машинного интерфейса, недостаточный опыт пилотов с новым оборудованием самолета), технического (включая ошибку высотомера) и погодного факторов (температура ниже нуля и туман) объявлены причиной катастрофы. При этом во время происшествия не было сигнала тревоги.

Inside Risks

Slumping with age, the rounded, heavily wooded peaks of the Vosges massif in northeastern France bear their long history with stolid fortitude. Castles, monasteries, and ancient fortifications guard the heights; medieval towns and patchworks of vineyards crouch in verdant valleys opening onto the plains of Alsace, adjacent to the Rhine River. In this part of France, summers tend toward the warm and sunny, though winters in the highlands can be markedly snowy and severe.

Near the nothern tip of the Vosges, Mont Sainte-Odile rises to height of nearly 2500 feet above sea level. Pilgrims flock to the cluster of buildings that crown the peak to pay homage to Sainte Odile, who founded a convent on this site in the eighth century. Tourists trek the serpentine road to its summit for the magnificent view. On a clear day, they can glimpse the city of Strasbourg, about thirty-five miles to the northeast, and the Black Forest in neighboring Germany.

On January 20, 1992, a jet airliner plowed into a pine forest in the highlands near Mont Sainte-Odile. Just seven minutes away from the airport serving Strasbourg, the sleek Airbus A320 aircraft should have being flying at an altitude of nine thousand feet and descending slowly. Instead, it was at roughly twenty-four hundred feet when impact occured at 7:45 in the evening. The airliner sent out no distress signal before the crash. It simply broke radio contact and abruptly vanished from radar. The nine passengers who survived the crash reported they had noticed nothing out of the ordinary until the moment of impact.

Eighty-seven people died in the crash. Darkness, freezing temperatures, thick fog, gusty winds, and deep snow hindered rescue efforts. It took more than two hours for a relief party to locate the wreckage and begin ministering to the survivors. By that time, news of the disaster was already spreading throughout the world by way of a vast electronic web of telephone lines, radio links, microwave transmitters, and the rest of the paraphernalia that constitutes our communal nervous system. As details of the crash emerged, radio and television reports, followed by newspaper articles, conveyed to a receptive audience the raw material to feed an age-old, ghoulish fascination with disaster and tragedy.

The next morning in Washington, D.C., James H. Paul, a staff member of the investigation and oversight subcommittee of the U.S.House of Representatives, noticed a report of the crash distributed by the Reuters news agency. The story bore the provocative headline: "Latest Crash Heightens Controversy over Airbus A320".

The A320's notoriety stems from the innovative technology incorporated in the airliner. Built be a consortium of French, German, British, and Spanish firms working together as Airbus Industrie, this narrow-bodied, twin-engine, 150-seat aircraft was the first of a new breed of airliner in which pilots control the airplane entirely through computers.

Paul's interest in the A320 crash arose in part from his role as one of the authors of a 1990 study called Bugs in Program: Problems in Federal Goverment Computer Software Development and Regulation and in part from a concern he shared with others in the computer world about the difficulties of coping with the faults, or bugs, that plague just about any computer system.

Paul activated his computer's link with the Internet, a labytinthine, worldwide network of computer networks and communications lines that can pass messages — electronic mail — from one computer user to another throughout the system. Using the address RISKS@CSL.SRI.COM, he sent out a copy of the Reuters article. giving his message the title: "Another A320 crash in France." Moments later, the missive arrived at a computer at SRI International, a high-technology research center in Menlo Park, California. There it remained stored until Peter G.Neumann, a principal scientist in the computer science laboratory at SRI, found a moment in his busy day to check the accumulated messages, which he fashions into the frequent reports of the Forum on Risks to the Public in Computers and Related Systems. Neumann made Paul's submission the first item in the report he distributed electronically on January 22, two days after the A320 crash.

Though novel in commercial aviation, the use of sophisticated computer systems to operate and keep high-performance jets in the air is essential for several types of military aircraft. The experimental X-29 military jet, with an unconventional, swept-forward wing design that makes it appear to be flying backward, is aerodynamically unstable, and no human pilot can fly it unaided. Only a computer can make adjustments quickly enough to keep the plane in the air. Already in service or being tested, the F-117A Stealth fighter, B-2 Stealth bomber, and F-22 advanced tactical fighter don't even have mechanical systems to act as backups for their computer controls.

The mechanics of steering an airplane and keeping it aloft were much simpler and more direct in the early days of powered flight. When Orville Wright coaxed the Wright Flyer into the air on December 17, 1903, near kitty Hawk, North Carolina, his whole body came into play to control the plane. Lying prone beside the engine on the lower of a pair of cloth-draped wings, with his feet hooked over a spar, Wright used his arms to raise or lower the flying machine's horizontal front rudder to keep the plane at the proper angle. Cradled in a wooden yoke, his hips controlled wires that warped the wing tips for lateral balance. These hip movements also deflected the aircraft's vertical rear rudder to steer the plane.

The same fundamental principles underlie control of today's highly automated aircraft, but the link between a pilot and the consequences of his or her actions has become much less direct. Even with mechanical controls in a large, modern airliner, there's really no direct connection between the pilot's hand and the airplane's behavior. In a fly-by-wire arrangement, when pilot pushes the plane's control stick to either side to turn the plane left or right, electronic sensors send signals to a set of flight-control computers. Instructions in the form of a computer program allow the computers to calculate what adjustments to make to the plane's rudder, flaps, or wing surfaces called ailerons. The computers, in turn, relay commands via an extensive network of electrical wiring to mechanical devices installed in the wings and tail to make the required changes in position of the movable parts. The plane then banks left or right. The pilot feels a comfortable amount of resistance in the control stick, just as if he or she were maneuvering the plane directly, but it's all a sham. A computer adjusts actuators in the stick to create the illusion of direct control.

In the Airbus A320, flight computers go so far as to tell the pilot how to fly the airplane, for example, by restricting how quickly or how far he or she can bank the airplane to the left or right. That's because the engineers who designed the aircraft gave the flight-control computers full authority to operate the airplane and override a pilot's actions when these actions force the plane into a situation that exceeds its capabilities and structural limitations. Faced with a sudden, wind-induced, stomach-churning drop in altitude, a pilot can react instantly by pulling all the way back on the control stick to nose the plane up, fully confident that the flight-control computers will ensure that the plane doesn't lurch into a deadly stall. At least, that's the theory.

Numerous pilots have complained that such delegation of authority to computers restricts their actions in an emergency. The pilots believe that a flight crew should be able to take any action deemed necessary to avoid crashing into a mountain or collinding with another aircraft — even if it means stressing the plane beyond its tolerances or flying it in an unconventional manner. Ironically, the computer-massaged A320 flies so smoothly and quietly under normal circumstances that both passengers and pilots have little sense that they are flying, and that in itself poses a risk of pilot overconfidence or complacency.

Reliance on computers for such critical functions as flight control also worries some computer professionals, whose experiences with a wide variety of computer systems have invariably demonstrated that no computer operates flawlessly all the time. Bev Littlewood, a professor of software engineering at City University in London, England, has long argues that because it's impossible to guarantee a sufficiently high level of reliability, the use of computers may be inappropriate for critical functions in aircraft, medical equipment, nuclear power plants, emergency communications systems, and other situations in which human life can be placed in jeopardy as a result of a computer failure.

Внутренние риски

Утопая со временем, круглые, поросшие густым лесом пики горного массива Вогезы на северо-востоке Франции несут свою давнюю историю флегматичной силы духа. Замки, монастыри и древние укрепления охраняют высоты; средневековые городки и полосы виноградников покрывают зеленые долины, простирающиеся на равнине Эльзаса, прилегающей к реке Рейн. В этой части Франции летом тепло и солнечно, а зимы в горах могут быть ощутимо снежными и суровыми.

Рядом с северной вершиной Вогезы гора Сент-Одиль поднимается на высоту 2500 футов над уровнем моря. Паломники стекаются в несколько зданий, окружающих пик горы, чтобы воздать должное святой Одили, которая основала женский монастырь в этом месте в VIII веке. Туристы едут по серпантину на вершину, чтобы там насладиться великолепным видом. В ясный день они могут увидеть город Страсбург, который находится в тридцати пяти милях на северо-восток, а также город Шварцвальд в соседней Германии.

20 января 1992 года реактивный пассажирский самолет врезался в сосновом лесу в горах рядом с Монт-Сент-Одиль. Всего семи минутах от принимающего аэропорта в Страсбурге, гладкий аэробус A320 должен был лететь на высоте в 9 тысяч футов и медленно снижаться. Вместо этого, он был на высоте около двадцати четырех сотен футов тогда, когда столкновение произошло вечером в 7:45. Лайнер не посылал ни одного сигнала о бедствии до катастрофы. Он просто потерял радиосвязь и моментально исчез с радаров. Девять пассажиров, которые выжили, сообщили в дальнейшем о том, что они не заметили ничего необычного до момента удара.

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

Следующим утром в Вашингтоне, округе Колумбия, James H.Paul, один из сотрудников подкомитета по следствиям и надзору палаты представителей США, заметил отчет о крушении, распространяемого агенством Reuters. История несла провокационный заголовок: «Последняя авария усиливает полемику вокруг аэробуса А320».

A320 известен своим происхождением от инновационных технологий, которые были заложены в авиалайнере. Построенный консорциумом французских, немецких, британских и испанских фирм, работающих вместе под маркой Airbus Industrie, это узкофюзеляжный, двухмоторный, 150-местный самолет, являющийся первым из нового поколения авиалайнеров, которым пилоты управляют полностью посредством компьютеров.

Интерес Paul'a к катастрофе A320 возник отчасти из-за того, что он был одним из авторов расследования 1990 года под названием «Ошибки в программе: проблемы правительственной компьютерной разработки программного обеспечения и его регулирование» и частично потому, что он поделился своей озабоченностью с остальным компьютерным миром сложностями преодоления отказов и ошибок, которые мешают работе практически любой компьютерной системы.

Paul активировал в своем компьютере связь с Интернетом, с лабиринтом, мировой сетью коммуникационных линий между компьютерами, которая может обмениваться сообщениями — электронными письмами — от одного компьютера к другому по всей системе. Используя адрес RISKS@CSL.SRI.COM он отправил копию статьи Reuters со следующим заголовком: «Ещё одна катастрофа А320 во Франции». Моментом позже, сообщение прибыло на компьютер SRI International, высокотехнологичный центр в Menlo Park, штат Калифорния. Там оно хранилось до тех пор, пока Peter G.Neumann, главный научный сотрудник, работающий в научной компьютерной лаборатории в SRI, нашел момент в своем загруженном графике и проверил пришедшие сообщения, которые он в дальнейшем привел к формату форума о компьютерных рисках, работающего в открытом доступе и связанного по теме с надежными системами. Neumann внес как первое сообщение в своем докладе то, что прислал Paul, и отправил отчет 22 января, через два дня после крушения A320.

Хотя повествование идет о коммерческой авиации, использование сложных компьютерных систем для эксплуатации высокопроизводительных реактивных самолетов в воздухе также важно для нескольких типов военных самолетов. Экспериментальный реактивный военный самолет X-29 имеет нестандартный дизайн с обратной геометрией крыла, из-за которого по форме кажется, что он летит назад, он аэродинамически чрезвычайно неустойчив и без посторонней помощи ни один человек не справится с его управлением. Только компьютер может вносить коррективы в полет так быстро, чтобы самолет удержался в воздухе. Уже находятся на вооружении или проходят испытания истребитель F-117A Stealth, бомбардировщик B-2 и многоцелевой истребитель F-22, которые даже не имеют механических систем в качестве резервного способа управления, отличного от компьютерного.

Механика управления самолетом и удержанием его в воздухе была намного более простой и директивной на ранних этапах истории управляемого полета. Когда Орвилл Райт уговорил братьев Райт подняться в воздух в 17 декабря 1903 года, рядом с Kitty Hawk, Северная Королина, их тело полностью было включено в действие по управлению самолетом. Лежа ничком рядом с двигателем на нижней паре крыльев, обытых тканью, с захваченными ногами за перекладину, Райт использовал свои руки чтобы поднимать или опускать передние горизонтальные рули для того, чтобы держать самолет под нужным углом. Качающиеся в деревянном коромысле, его бедра контролировали канаты, которые изменяли окончания крыльев для поддержания бокового равновесия. Эти движения бедрами также влияли на вертикальный задний руль, который направлял движение самолета.

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

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

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

Доверие компьютерам в таких критичных функциях как управление полетом самолета также беспокоит некоторых специалистов в IT, опыт которых в работе с широким спектром компьютерных систем определенно показал, что ни один компьютер не работает безупречно все свое время. Bev Littlewood, профессор программной инженерии в City University Лондона (Англия) уже давно утверждает, что невозможно гарантировать дотаточно высокий уровень надежности, а использование компьютеров может быть неподходящим в таких областях, как управление самолетами, медицинским оборудованием, ядерной энергетикой, в системах аварийной связи, и в других ситуациях, в которых жизнь человека может оказаться под угрозой в результате отказа компьютера.