Откуда взялось слово «баг»? От истории одной моли до ошибок ценой в миллиарды

Это одно из самых частых слов в лексиконе программиста: баг (bug). Дословно — «жук», «насекомое». Но ни один программист не говорит о насекомых — имеется в виду ошибка в коде.

Так почему же «жук»? Действительно ли из-за моли, застрявшей внутри компьютера? Или это история, которая от бесконечных пересказов превратилась в легенду?

Ответ лежит посередине — и он куда интереснее, чем можно подумать.

1. Происхождение слова: до насекомого было пугало

Древнейшее значение английского слова bug — вовсе не «насекомое».

В среднеанглийском «bugge» означало «пугало, призрак, домовой». Вероятно, оно было родственно валлийскому bwg (призрак, пугало). Живущие в английском по сей день слова bugbear («то, что пугает без причины») и bogeyman («бука») происходят от этого же корня.

То есть bug сначала нёс значение «невидимое, необъяснимое, изводящее тебя нечто». Значение «насекомое» появилось позже — вероятно, по ассоциации с «мелким существом, которое незаметно пробирается и досаждает».

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

2. Томас Эдисон, 1878: «баг» входит в язык инженеров

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

В письме 1878 года, описывая процесс изобретательства, Эдисон писал (по сути): появляется идея, затем начинаются трудности — одно отказывает, другое не работает, — и вот тогда дают о себе знать мелкие неполадки и затруднения, которые мы называем «Bugs». По Эдисону, придёт ли изобретение к «коммерческому успеху или провалу», зависит от того, удастся ли вычистить эти баги.

Эдисон употребил это слово не один раз: оно повторяется в его записных книжках и переписке. В 1888 году специалист по телеграфу Уильям Мейвер, рассуждая об известной склонности квадруплексной телеграфной системы к сбоям, писал, что её называют «bug» — и что первым так назвал её именно Эдисон.

«Баг» телеграфистов

К концу XIX века термин прочно закрепился в мире телеграфа. Настолько, что полуавтоматические телеграфные ключи для быстрой передачи азбукой Морзе назывались «bug keys» — на ключах марки Vibroplex и сегодня красуется логотип с насекомым.

Иными словами, к 1940-м годам «баг» был уже устоявшимся инженерным жаргоном. И это полностью меняет смысл знаменитой истории, о которой пойдёт речь дальше.

3. 9 сентября 1947 года: та самая моль

Вот самая пересказываемая история в истории технологий.

Место: Гарвардский университет, вычислительная лаборатория.

Машина: Harvard Mark II Aiken Relay Calculator — огромный электромеханический компьютер на реле.

Дата: 9 сентября 1947 года.

Машина выдавала неверные результаты. Команда принялась искать неисправность и обнаружила моль, застрявшую в реле №70 на панели F. Моль извлекли пинцетом, приклеили скотчем в лабораторный журнал и подписали рядом:

«First actual case of bug being found.» («Первый реальный случай обнаружения бага».)

Эта страница журнала — с той самой молью, всё ещё приклеенной к ней — сегодня хранится в коллекции Национального музея американской истории Смитсоновского института.

Легендарная часть истории — и как было на самом деле

Обычно событие пересказывают так: «Первым компьютерным багом было настоящее насекомое, и нашла его Грейс Хоппер. Отсюда и пошло слово „баг“».

С этим три проблемы:

1. Слово уже существовало. Мы видели выше — Эдисон употреблял его в 1878 году. Сама надпись выдаёт это: «first actual case» — «первый реальный случай». Такая формулировка смешна лишь в том случае, если команда уже использовала слово «баг» в переносном смысле. Запись — не объявление об открытии, а шутка: «Мы годами говорим „баг“, а в этот раз это и правда оказался жук!»

2. Грейс Хоппер, скорее всего, не была тем, кто нашёл моль. Хоппер в то время работала в команде Mark II и годами с большим удовольствием пересказывала эту историю — поэтому событие и связали с её именем. Однако почерк в журнале не её, и достоверных свидетельств, что в тот момент она была в лаборатории, нет. Хоппер — рассказчица легенды, а не её героиня.

3. Это не было «первым». Сбои из-за насекомых были известной проблемой релейных машин; это самый известный задокументированный случай — но не самый ранний.

Значит ли это, что история ничего не стоит? Отнюдь. Та моль дала абстрактному инженерному термину физическое тело. Если вы хотите объяснить, почему слово не умирает вот уже 80 лет, вот ответ: люди забывают определения, но не забывают истории.

4. Откуда взялось слово «debug»?

Приставка de- в английском означает «удалять, устранять» (de-ice — удалять лёд, de-frost — размораживать). Debug = «вычистить баги».

Интересно, что и «debugging» появилось раньше компьютеров: есть свидетельства, что в 1940-х этот термин использовали в авиации применительно к устранению неполадок в авиадвигателях. В компьютерном же контексте он широко закрепился в 1950-х.

По-русски прижилась прямая транслитерация: баг, дебаг, отладка. Официальный термин — «отладка» (debugging) и «ошибка ПО» (bug), но в живой речи разработчики почти всегда говорят «баг» и «дебажить». В турецком, для сравнения, перевели по смыслу: hata ayıklama — буквально «извлечение ошибки».

5. Терминология: баг, ошибка, дефект и отказ — не одно и то же

В обиходе мы всё называем «багом». Но в литературе по программной инженерии (стандарты ISTQB и IEEE) это разные слои:

• Error / Mistake (ошибка человека) — Неверное действие человека (Разработчик пишет `<=` вместо `<`)

• Defect / Fault / Bug (дефект) — Эта ошибка, воплощённая в коде (Цикл проходит на одну итерацию больше)

• Failure (отказ) — Проявление дефекта во время выполнения (Приложение падает в конце списка)

Почему это важно? Потому что не всякий дефект превращается в отказ. Баг может годами сидеть в коде и рвануть только при одном очень специфическом вводе. Именно поэтому знаменитая фраза Эдсгера Дейкстры не теряет силы:

«Тестирование показывает наличие ошибок, но не их отсутствие».

И ещё одно разграничение: баг ≠ отсутствующая функция. Если продукт ведёт себя ровно так, как задумано, но вам это не нравится — это не баг, а feature request. Команды, которые не проводят эту границу, превращают баг-трекер в ящик пожеланий.

6. Виды багов: техническая классификация

6.1. Классические категории

• Синтаксическая ошибка (syntax error): код даже не компилируется. Самый безобидный вид — компилятор сразу вас предупреждает.

• Логическая ошибка (logic error): код работает, но выдаёт неверный результат. Самый коварный вид.

• Ошибка времени выполнения (runtime error): деление на ноль, обращение по null, файл не найден.

• Ошибка на единицу (off-by-one): цикл проходит на одну итерацию больше или меньше. Самый классический баг в программировании. («В информатике есть две сложные вещи: инвалидация кеша, именование и ошибки на единицу».)

• Состояние гонки (race condition): два потока обращаются к одному ресурсу одновременно; результат зависит от порядка. Воспроизводить — сущий ад.

• Утечка памяти (memory leak): выделенная память не освобождается; приложение разбухает за часы.

• Переполнение (overflow): число выходит за границы типа данных и «заворачивается».

• Регрессия (regression): то, что раньше работало, ломается после нового изменения.

• Уязвимость (vulnerability): эксплуатируемый баг. Всякая уязвимость — баг, но не всякий баг — уязвимость.

6.2. Забавные имена, позаимствованные у физиков

Программисты дали некоторым типам багов прозвища, отсылающие к физикам:

• Гейзенбаг (Heisenbug): баг, который исчезает, стоит попытаться его изучить. Подключаете отладчик — ошибка пропадает; отключаете — возвращается. Назван по принципу неопределённости Гейзенберга и эффекту наблюдателя. (Обычно вызван различиями в тайминге, раскладке памяти или оптимизациях.)

• Борбаг (Bohrbug): полная противоположность гейзенбагу — «добротный, послушный» баг. Воспроизводится одинаково при одних и тех же условиях. Отсылка к предсказуемой модели атома Бора. Любимый тип бага любого разработчика, ведь воспроизводимый баг — это уже почти решённый баг.

• Мандельбаг (Mandelbug): причины настолько сложны и запутаны, что поведение выглядит хаотичным и даже недетерминированным. Отсылка к фракталам Мандельброта. Выглядит как гейзенбаг, но на деле это крайне сложный борбаг.

• Шрёдинбаг (Schrödinbug): баг, который проявляется ровно в тот момент, когда кто-то читает код и говорит: «как это вообще работало? Оно не должно было работать». До этой секунды всё функционирует; как только это замечено — ломается у всех. Отсылка к коту Шрёдингера.

• Хинденбаг (Hindenbug): баг с катастрофическими последствиями. Стирает базу данных, кладёт сервер. От катастрофы дирижабля «Гинденбург».

Эти названия выглядят шуткой, но у них есть реальная функция: правильная классификация бага определяет, как на него охотиться. Гейзенбаг не поймать отладчиком — нужны логирование и анализ таймингов. А борбаг можно спокойно пройти по шагам.

7. Баги, вошедшие в историю

Большинство багов просто раздражают. Некоторые вошли в историю человечества.

Mariner 1 (1962) — одна пропущенная черта

Зонд NASA, направлявшийся к Венере, вскоре после старта сошёл с курса, и его пришлось уничтожить. В качестве причины называли пропущенный символ надчёркивания в рукописной записи уравнений системы наведения. Артур Кларк назвал это «самым дорогим дефисом в истории».

Therac-25 (1985–1987) — случай, когда баги убивали

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

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

Pentium FDIV (1994) — процессор, который не умел делить

Процессор Intel Pentium выдавал неверный результат при некоторых операциях деления с плавающей запятой. Дефект заметил профессор математики. Intel сначала преуменьшала проблему, но под давлением общественности была вынуждена пойти на отзыв — расходы около 475 млн долларов.

Ariane 5, полёт 501 (1996) — катастрофа копипаста

Новая ракета Европейского космического агентства разрушилась через 37 секунд после старта. Причина: программа инерциальной навигации, перенесённая без изменений с Ariane 4. Ariane 5 набирала высоту гораздо быстрее; значение горизонтальной скорости переполнилось при преобразовании из 64-битного числа с плавающей запятой в 16-битное целое. Хуже того, поскольку резервный блок работал на том же ПО, резерв отказал в ту же секунду. Ущерб: около 500 млн долларов.

Вывод: резервирование защищает только от другого отказа. Запустить одну и ту же программу дважды — это не резервирование.

Mars Climate Orbiter (1999) — путаница в единицах

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

Y2K (2000) — несостоявшаяся катастрофа или предотвращённая?

Страх, что старые системы, хранящие год двумя цифрами, примут 2000-й за 1900-й. По всему миру были проведены работы по исправлению на сотни миллиардов долларов, и 1 января 2000 года ничего существенного не произошло. Спорят до сих пор: это была раздутая паника — или катастрофа, оставшаяся невидимой именно потому, что её успешно предотвратили? Знакомая ирония в разработке: наградой за хорошо сделанную профилактику становится то, что ничего не случилось.

Knight Capital (2012) — 440 млн долларов за 45 минут

Американская финансовая компания развернула новое ПО лишь на семи из восьми серверов. На восьмом старый тестовый код, выведенный из употребления годами ранее, был случайно снова активирован перепрофилированным флагом. Система начала безумно торговать. За 45 минут потеряно 440 млн долларов; компания оказалась на грани банкротства и была продана.

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

Heartbleed (2014) — две строки, открывшие полинтернета

Отсутствие проверки границ в библиотеке OpenSSL позволяло атакующим читать произвольные фрагменты памяти сервера — пароли, приватные ключи. Затронута была огромная часть интернета. Ключевой момент: OpenSSL — проект, на который полагались миллиарды устройств, но который почти никто не финансировал и который поддерживала горстка волонтёров.

CrowdStrike (июль 2024) — одно обновление, глобальный паралич

Ошибочное обновление контента в защитном ПО отправило миллионы Windows-машин по всему миру в «синий экран». Авиакомпании отменяли рейсы, больницы переносили приёмы, банки останавливались. Сама ошибка в коде была небольшой; разрушительным оказалось то, что механизм доставки не был поэтапным — обновление ушло всему миру одновременно.

Вывод: масштаб бага не определяет его последствий. Их определяет скорость распространения.

8. Жизненный цикл бага: что происходит после обнаружения

В профессиональных командах баг проходит такой путь:

• 1. Регистрация — сообщает пользователь, тестировщик или система мониторинга.

• 2. Воспроизведение — самый критичный шаг. Невоспроизводимый баг — это неисправимый баг. Хороший отчёт содержит: шаги, ожидаемый результат, фактический результат, сведения об окружении, логи/скриншоты.

• 3. Триаж — оценивается по двум независимым осям:

• Severity (серьёзность): насколько велико техническое воздействие? (Потеря данных или опечатка?)

• Priority (приоритет): насколько срочно нужно чинить? (С точки зрения бизнеса)

Их часто путают, но это разное: неверно написанное название компании на главной странице — баг низкой серьёзности, но высокого приоритета.

• 4. Назначение и анализ первопричины — ищут причину, а не симптом.

• 5. Исправление

• 6. Регрессионное тестирование — убеждаются, что исправление не сломало что-то другое. Пропустите этот шаг — и правка породит новые баги.

• 7. Закрытие — и в идеале добавляется автоматический тест, не дающий тому же багу вернуться.

Инструменты: Bugzilla (1998, открытый код, задал стандарт жанра), Jira, GitHub Issues, Linear, Sentry (автоматический перехват ошибок).

9. Цена багов и миф о «нуле багов»

Один из старейших выводов программной инженерии таков: стоимость исправления дефекта растёт экспоненциально в зависимости от стадии, на которой он обнаружен. Дефект, пойманный на этапе требований, стоит почти ничего; тот же дефект, пойманный в продакшене, обходится в десятки и сотни раз дороже — потому что чинить приходится уже не только код, но и испорченные данные, репутацию и отношения с клиентом.

Именно поэтому современные практики стремятся «сдвинуть влево» (shift left): код-ревью, статический анализ, юнит-тесты, системы типов, проверки в CI/CD.

Так возможен ли ноль багов? На практике — нет.

• Теорема Райса и проблема остановки показывают, что автоматическая проверка определённых свойств программы в общем случае теоретически невозможна.

• Тестирование покрывает лишь выборку из бесконечного пространства входных данных.

• ПО «портится» вместе с изменениями железа, ОС и сети под ним — даже если сам код не менялся.

Есть одно исключение: формальная верификация. Этот метод математически доказывает определённые свойства кода и применялся в таких проектах, как микроядро seL4 или компилятор CompCert. Но он крайне дорог и экономически оправдан лишь там, где права на ошибку нет: авиация, космос, атомная энергетика, медтехника.

Поэтому индустрия строится не на «нуле багов», а на приемлемом риске. Вопрос не в том, «есть ли дефекты?», а в том, «какие дефекты допустимы, а какие — никогда?»

10. «Это не баг, это фича» — классика культуры

Самая известная шутка в мире разработки: «Это не баг, это фича».

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

Один из самых известных примеров — Space Invaders: пришельцы ускоряются по мере того, как их становится меньше. Это не было дизайнерским решением — просто железо успевало быстрее перерисовывать меньшее число объектов. Но игрокам нарастающее напряжение так понравилось, что оно стало одной из самых узнаваемых механик в истории игр.

С этим связан и закон Хайрама: при достаточном числе пользователей API уже неважно, что вы обещали в контракте; любое наблюдаемое поведение вашей системы обязательно станет для кого-то зависимостью. А значит, исправление бага может означать поломку чужого продукта.

11. Программы вознаграждений за баги (bug bounty)

В 1995 году Netscape запустила одну из первых программ, выплачивающих вознаграждение тем, кто сообщал об уязвимостях в её браузере. Сегодня Google, Apple, Microsoft, Meta и государства платят шестизначные суммы за критические уязвимости.

Логика проста и сильна: у уязвимости есть цена и на чёрном рынке. Если легальный канал предлагает лучшую оплату и публичное признание, вы перетягиваете большинство находящих уязвимости людей на правильную сторону.

Платформы вроде HackerOne и Bugcrowd институционализировали эту экосистему. Так слово «баг», бывшее в XIX веке названием неисправности, в XXI стало профессией.

12. Баги в эпоху искусственного интеллекта

Последние несколько лет добавили понятию новые слои:

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

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

Появился новый класс багов. В классическом ПО баг живёт в коде. В системах машинного обучения дефект может жить в обучающих данных, в весах модели, в дрейфе данных (data drift) или в дизайне промпта. Ни одно из этого нельзя пройти по шагам в отладчике. Индустрия всё ещё ищет общий язык для этих проблем — используемые сегодня термины «галлюцинация», «джейлбрейк», «prompt injection» и есть «баг» 2020-х.

Возможно, через несколько десятилетий кто-то напишет статью о том, откуда взялись эти слова.

13. Часто задаваемые вопросы

Первый компьютерный баг действительно был насекомым?

Нет — но насекомое действительно нашли. Моль 1947 года была не источником слова, а самой знаменитой его иллюстрацией. Слово использовалось с 1878 года.

Грейс Хоппер придумала слово «баг»?

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

Чем баг отличается от ошибки?

Error — это неверное действие человека, bug (дефект) — это действие, воплощённое в коде, а failure (отказ) — результат, проявляющийся во время выполнения.

Как это называется по-русски?

Официально — «ошибка ПО» и «отладка» (для debugging). В живой речи почти всегда говорят «баг» и «дебажить».

Можно ли написать ПО без багов?

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

14. Заключение: 150-летний путь одного слова

История слова «баг» — это маленькая модель истории самой технологии.

В средневековой Англии это было невидимое привидение. В 1878 году в лаборатории Эдисона оно стало мелкой неполадкой, с которой инженер не мог совладать. В 1947 году в Гарварде обрело физическую форму — настоящей моли, приклеенной в лабораторный журнал. В 1996-м оно разорвало ракету в воздухе, в 2012-м прикончило компанию за 45 минут, в 2024-м остановило аэропорты по всему миру. А сегодня существует индустрия, платящая шестизначные суммы тем, кто их находит.

Но главное значение слова так и не изменилось: баг — это то, что прячется внутри системы, чего вы не видите и что вас изводит. Ровно тот же страх, что и у привидения XIV века.

А работа программиста — найти это привидение и вынести его на свет.

Источники

• Log Book With Computer Bug — Smithsonian National Museum of American History

• Did You Know Edison Coined the Term "Bug"? — IEEE Spectrum

• The Bug in the Computer Bug Story — JSTOR Daily

• Heisenbug — Wikipedia

• List of software bugs — Wikipedia

• 11 of the most costly software errors in history — Raygun

• The Most Expensive Software Bugs in History — Techfellow

• The First Computer Bug: How A Moth Became A Tech Legend — Quantum Zeitgeist