Грядет апокалипсис программного обеспечения

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

Переводчица — Мария Бикбулатова

Ночью 10 апреля 2014 года на протяжении шести часов все население штата Вашингтон не имело доступа к службе 911. Звонившие слышали только короткие гудки. Одна женщина из Сиэтла набрала 911 по меньшей мере 37 раз, пока преступник пытался проникнуть в ее дом.

Незадолго до полуночи 10 апреля это значение было превышено, что вызвало хаос. Так как алгоритм подсчета генерировал уникальный идентификатор для каждого звонка, новые отклонялись. И поскольку программисты не предвидели эту проблему, они не создали никаких сигналов тревоги, которые сообщали бы о ней. Никто не понимал, в чем дело. Диспетчерские центры в Вашингтоне, Калифорнии, Миннесоте, Южной и Северной Каролине, обслуживающие 11 миллионов американцев, отчаянно пытались разобраться, почему звонящие на номер 911 слышали короткие гудки. Только к утру стало понятно, что все дело было в программном обеспечении Intrado. Чтобы исправить ситуацию, понадобилась лишь одна цифра.

Говорят, что программное обеспечение «съедает мир». Все больше важных систем, которые раньше контролировались либо механически, любо людьми, становятся зависимыми от кода. Никогда это не было столь очевидно, как летом 2015 года, когда всего за один день произошло следующее: United Airlines посадили весь свой флот из–за проблем с системой менеджмента вылетов; торговля на Нью-Йоркской бирже была остановлена после апгрейда; заглавная страница веб-сайта The Wall Street Journal обвалилась; а система 911 Сиэтла снова зависла, на этот раз из–за проблем с другим роутером. Одновременную поломку стольких систем ПО сперва приняли за скоординированную кибератаку. Но еще более пугающим стало осознание того, что все это — просто совпадение.

«Когда у нас были электромеханические системы, мы могли тщательно их проверять», — говорит Нэнси Ливсон, профессор аэронавтики и астронавтики в Массачустетском технологическом институте, исследующая безопасность программного обеспечения последние 35 лет. Она обрела известность после доклада о Therac-25, аппарате для лучевой терапии, который убил шесть пациентов из–за ошибки программного обеспечения. Электромеханическую систему можно было целиком описать на нескольких листах бумаги, можно было продумать все ситуации и состояния, в которых она могла оказаться. Когда она была построена и протестирована, персонал точно знал, с чем имеет дело.

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

Стандарты, существовавшие до прихода ПО, предполагали следующее: чтобы сделать что-то надежным в целом, нужно сначала сделать надежными его части. Например, вы строите мотор, который способен выдержать 40 000 циклов взлетов и приземлений, и вместе с этим предусматриваете возможность его поломки (поэтому у вас есть два мотора).

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

Проблема с программным обеспечением — это прежде всего проблема понимания и воображения.

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

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

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

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

Программистам сложно поспевать за своими творениями. С восьмидесятых годов работа программистов и инструменты, которые они используют, практически не изменились, в то время как компьютеры удваивали свои мощности каждые 18 месяцев. «Даже очень хорошим программистам сложно понять систему, с которой они работают», — говорит Крис Грэнджер, разработчик программного обеспечения, который работал руководителем отдела Visual Studio в Microsoft, линейки продуктов, включающих интегрированную среду разработки ПО — она используется почти третью профессиональных программистов. Во время работы в Microsoft Крис организовал исследование: месяц он наблюдал за программистами, которые работают с Visual Studio, за тем, как они сидят за компьютером, какие инструменты используют. Он выяснил, что 98% Visual Studio, одного из самых больших программных обеспечений, включающего в себя 55 миллионов строк кода, абсолютно бесполезно. В него было вложено огромное количества труда, но эта работа не учитывала самых главных проблем, с которыми сталкиваются люди. В конечном итоге, программисты были похожи на игроков в шахматы с завязанными глазами: они тратили так много ментальной энергии на то, чтобы понять, где находятся необходимые им элементы, что у них уже не оставалось внутренних ресурсов, чтобы думать о самой игре.

Джон Резиг — известный программист JavaScript, чье программное обеспечение снабжает больше половины всех веб-сайтов, — заметил сходное явление среди своих студентов. По его мнению, научиться программировать сложно потому, что код очень абстрактен. Чтобы «сделать» программу, нужно набирать слова. А чтобы ее изменить, нужно менять уже целый текст. Поэтому лучше всего справлялись те студенты Резига, которые каждый раз, запуская новую команду, прослеживали в уме все промежуточные вычисления, то есть думали как компьютер.

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

Потом появилась такая вещь, как WYSIWYG (расшифровывается как What you see is what you get — «Ты получаешь то, что ты видишь»). WYSIWYG — это свойство прикладных программ или веб-интерфейсов, в которых содержание отображается в процессе редактирования и выглядит максимально похожим на конечную продукцию: печатный документ, веб-страницу или презентацию. Если ты хочешь изменить границу, то просто тянешь внешнее поле наверху экрана и сразу видишь эффект этого изменения. Таким образом, документ ощущается как нечто реальное.

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

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

Виктор создал показательный ролик на примере игры «Марио»: на одной стороне экрана был код, контролирующий игру, а на другой — сама игра. Это позволило наглядно показать, какие изменения происходят в игре, когда в код вносятся поправки.

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

Работавший в Visual Studio в Microsoft Крис Грэнджер был также воодушевлен тем, что сделал Виктор, и в течении нескольких дней создал прототип системы программирования, в которой разработчик получает незамедлительный фидбэк на то, что делает. Как ведет себя система, можно было наблюдать прямо рядом с кодом, который эту систему контролирует, — как если бы программист наконец снял повязку с глаз.

Французская компания Esterel Technologies, производящая ПО с особыми требованиями к обеспечению безопасности, в числе первых ввела в использование «модельно-ориентированный код». Основатель компании Эрик Бантени утверждает, что другие способы программирования давно устарели. Ведь никто не делает машины вручную, а код до сих пор является преимущественно ручной работой. Набрать 10 000 строк кода от руки еще представляется возможным, но если речь идет о 30 млн, как в Airbus, или 100 млн, как в высокотехнологичных машинах Tesla, задача становится невероятно трудной.

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

Перевод осуществлен на пожертвования пользователей. Вложиться в гонорарный фонд сайта syg.ma можно здесь.