«Я всегда был очарован тем, как много мы, люди, работаем на автопилоте», — говорит Миа Баджич в интервью по электронной почте. Итак, в прошлом месяце для Pycon US 2025 года вице -председатель Общества Европитон определил «самые странные программные ошибки в истории».
И иногда они были даже восхитительно иллюстрированы фигурами палки …
Но Баджич, который также является инженером-программистом на платформе управления данными Ataccama, говорит, что большая цель была не только для того, чтобы пересказать все ошибки, но и «понять, чему нас нас научили», о том, как мы можем создавать более устойчивые системы, и как мы можем писать лучший код. Это галерея ужасов, наполненная каскадными неудачами, непредвиденными краями, ужасно ошибочными предположениями и катастрофическими опасностями недостаточного интеграционного тестирования.
Если мантра для программистов всегда учиться — то что нужно учиться на самых странных программных ошибках истории?
Опасность сложных систем
Баджич начал с ужасной истории о смертельной аварии Boeing 737 Max 8 в Джакарте в 2018 году. Пилоты не боролись с турбулентностью, но «несколько строк кода», как говорит Баджич. Boeing написал программное обеспечение для автоматического исправления для плоскости погружения, которая затем была ошибочно тригена от неисправного датчика — и пилоты не знали, как его отключить. Среди уроков, которые следует извлечь: программное обеспечение не должно делать то, о чем пользователи не знают …
Но позже в выступлении Баджич подчеркнул, что, хотя одиночные точки отказа опасны — и предположительно протестированы — что сложнее определить, так это эти цепные реакции, каскадная серия неудач.
«Это никогда не только одна вещь, которая вызывает неудачу в сложных системах». В управлении рисками это известно как модель швейцарского сыра, где недостатки, которые происходят в одном слое, не так опасны, как более глубокие недостатки, перекрывающиеся через несколько слоев. И как доказывает авария Боинга, «когда все они выровняются, это то, что сделало его таким смертельным».
Трудно проверить каждый сценарий. В конце концов, чем больше у вас входов, тем больше возможных выходов — и «все это предполагает, что ваша система детерминированная». Сегодняшние кодовые базы огромны, со многими различными участниками и целыми стеками инфраструктуры. «От написания куска кода локально до запуска его на производственном сервере, есть тысяча вещей, которые могут пойти не так».
Но, сказав это, история также показывает нам, что все еще существуют ситуации, когда отсутствие тестирования становится явно очевидным…
Протестировано в производстве?
Баджич попросил аудиторию представить, что они инженер Google, который в 2009 году обновил службу безопасного просмотра компании (которая предупреждает о небезопасных веб -сайтах до того, как браузеры посещают их). «А потом вы понимаете, что каждый веб -сайт в Google помечен как опасный — включая сам Google!»
Да, независимо от того, что вы искали в Google, каждый результат пришел с предупреждением о том, что «этот сайт может повредить вашему компьютеру».
Проблема? Инженер Google напечатал прямую черту — сам по себе, который, по -видимому, отметил каждый отдельный файл под домашним каталогом. «Из этого мы можем извлечь уроки, так это то, что опечатки случаются — а иногда и тестирование — это ответ».
Но еще одна странная ошибка водит точку домой: эти ужасные вещи случаются, когда вы не тестируете достаточно. В 1999 году НАСА потеряло орбитаж Марса в 125 миллионов долларов, который был «размером с маленький автомобиль», наполненного «много датчиков и много электроники», чтобы дать Марсу вид погодного спутника.
После 10 месяцев межпланетного космического полета он пришел к его великолепному прибытию на Марс. Но когда контроллеры миссий ждали на Земле его сигнал: «Вместо этого было молчание… прошло минуты. Часы — и все еще ничего».
В конце концов они поняли, что произошло. В то время как зонд предназначался для орбиты на 110 километров над поверхностью Марса, «вместо этого они обнаружили, что он упал до 57 километров… и на этой высоте марсианская атмосфера разорвала ее». Орбитр никогда не завершал свою схему вокруг дальней части Марса, и на самом деле никогда не орбит.
CNN сообщила, что ошибка произошла «потому что инженерная команда Lockheed Martin использовала английские единицы измерения, в то время как команда агентства использовала более обычную метрическую систему…». Одна команда измерила импульсы стрельбы в секундах в рамках фунта, в то время как другая использовала эквивалентную единицу из метрической системы, известной как Newton-Seconds.
И Баджич снова иллюстрирует эту проблему с фигурами палки.
Очевидно, что это был провал связи, «потому что навигационная команда НАСА предположила, что все было в метрике». Но вам также необходимо проверить общение, которое происходит между двумя системами. «Если две системы взаимодействуют, убедитесь, что они согласны с форматами, единицами и общими предположениями!»
Но есть еще один еще более важный урок. «Данные показали несоответствия за несколько недель до неудачи», — говорит Баджич. «НАСА видело небольшие ошибки навигации, но они не были полностью исследованы». Это специально указывает на важность интеграционных тестов. «Если бы НАСА моделировало навигацию с фактическими устройствами данных, они могли бы поймать расхождение перед запуском…»
На положительной ноте, это приводит к Баджичу к урокам из того, как НАСА справилось с отчетом о последующем инциденте. Они учились из этого и улучшили свои процессы.
«После этой катастрофы НАСА стандартизировали подразделения по всей организации, обеспечили более строгие проверки и улучшенные протоколы связи между командами».
Что в имени?
Баджич также рассказывает о легендарной сказке о сотруднике Sun Microsystems, который загадочно исчезал из баз данных компании в середине 1990-х годов. «Люди начали исследовать, только чтобы обнаружить, что проблема не была сбоем системы. Это было его имя». И аудитория засмеялась, когда сказали, что имя сотрудника было…
Стив Нулл.
«И оказывается, что некоторые системы тогда не обработали строку NULL должным образом…»
Проходя лишнюю милю, Баджич даже попытался воссоздать проблему в Postgres здесь, в 2025 году. «Это работает нормально — но вы все равно можете найти такие ошибки в различных системах». (Bajić обнаружил аналогичную ошибку Open/неразрешенной для комплекта разработки программного обеспечения Apache Flex.)
И к концу Баджич воспроизводит знаменитый комикс XKCD о ученике государственной школы, чьи родители назвали его Робертом »); Студенты сброса стола; —
Конечно, код проверки данных может иметь свои ошибки. «Некоторые автоматизированные системы удалят все записи, которые начинаются с теста или ABCDE, потому что они предполагают, что они тестовые данные…»
Но затем Баджич выкладывает слайд, отмечая, что более 300 детей действительно были названы ABCDE в период с 1990 по 2020 год. Business Insider отмечает, что 32 ребенка были названы ABCDE только в 2009 году, а другие сайты предполагают, что это популярно среди родителей,-которые рассматривают унисекс или не гнуйдированные детские имена ».
Урок? При обращении с вводами пользователей рассмотрим краевые случаи-«потому что реальные данные могут вас удивить».
Предположения — и электронные таблицы
А какая странная ошибка вызвала список учебников на Amazon 23,7 миллиона долларов? Баджи объясняет, что автоматические инструменты для установки цен Amazon, которые непреднамеренно вызвали бесконечную петлю увеличения.
«Один продавец установил, что их правило всегда на 0,07% дешевле, чем следующая самая низкая цена. У другого продавца было правило, всегда было 27% дороже, чем самый низкий вариант». Но только с двумя списками для книги, вскоре цена первого продавца увеличилась на 26,93%, что увеличило более высокую цену продавца на 53,93%, «а их алгоритмы ценообразования застряли в цикле… пока книга не была указана за 23,7 миллиона долларов.
Урок? Будьте осторожны с вашими предположениями.
И знаете ли вы, что есть гены с именами сентября 15 и 5 марта? Microsoft Excel не сделал этого. Настройки по умолчанию в 2016 году автокорретировали эти текстовые строки в формат даты. Одна команда исследователей обнаружила, что в лучших журналах по геномике «приблизительно одна пятая бумаги с дополнительными списками генов Excel содержат ошибочные преобразования имени гена».
Excel просто старался быть полезным, предлагает Баджич — шутя, что «иногда трудно сказать, что такое ошибка, а что такое особенность». Но в других случаях это довольно очевидно. В 2012 году Баджич говорит, что ошибка электронной таблицы в конечном итоге стоила JP Morgan 6 миллиардов долларов, «потому что кто -то добавил два числа вместе вместо того, чтобы усреднить их».
Урок здесь? Электронные таблицы тоже должны быть отладки-как и любой код готового производства…
Худшая ошибка из всех
Возможно, Ultimate ошибка произошла в 2011 году, когда пользователи Linux установили демон шмеля для управления чипсетами NVIDIA Optimus. Сценарий установки должен был удалить конкретный каталог, а команда Linux для удаления файлов — RM. (И добавление флагов -RF делает удаление повторяется рекурсивным -удаление файлов во всех подкатариях -при выполнении этого без подсказки пользователя для подтверждения.)
Итак, вы можете найти разницу между этими строками кода?
rm -rf/usr/lib/nvidia -current/xorg/xorg rm -rf/usr/lib/nvidia -current/xorg/xorg
Конечно же, еще в 2011 году одно недостающее пространство (после /usr) привело к гневным проблемам на GitHub, как «совершенно не крутой чувак !!! Сценарий удаляет все под /usr. Мне просто нужно было переустановить Linux на моем компьютере, чтобы восстановиться».
Баджич понравился делиться некоторыми из 884 саркастических комментариев, которые приветствовали извинения сопровождающего …
«Сейчас больше не хватает пространства диска».
«Мне все равно не нравилась эта папка».
Но, в конце концов, Баджи сказал мне, что у ее разговора было конкретное сообщение для других разработчиков Python. «Мир сложный, как и системы, которые мы строим.
«Когда что -то идет не так, это редко только одна вещь. Обычно это цепь мелких вещей, выстраивающихся в толкование неправильно».
«Иногда лучшее тестирование может поймать его. Иногда это не может».
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид Кассель — гордый житель района залива Сан -Франциско, где он освещал технологические новости более двух десятилетий. За эти годы его статьи появлялись повсюду от CNN, MSNBC и The Wall Street Journal Interactive … Подробнее от Дэвида Касселя
