Легендарные костыли в продакшене

в 9:01, , рубрики: ruvds_статьи, windows, костыли, ПО, продакшн, разработка, сервер, системное администрирование, управление разработкой
Легендарные костыли в продакшене - 1

Нет ничего более постоянного, чем временное решение. Любой айтишник хоть раз лепил костыль на скорую руку — потом перепишем, потом сделаем нормально. Но «потом» обычно не наступает, и в итоге времянка живёт в продакшене годами, переживает релизы и смену команд, а иногда становится частью продукта. У индустрии полно баек о том, как костыли превращались в легенды. В этой статье собрал самые интересные случаи из истории ИТ. Приглашаю под кат. 

Windows 9 и старый код

Начнём с легенды из мира больших корпораций. Почему так и не появилось Windows 9? Одна из самых популярных версий объясняет это костылями в старом коде. 

В 90-е многие приложения определяли версию ОС предельно примитивно: искали в строке «9» и считали, что перед ними Windows 95 или 98. Если бы Microsoft выпустила «Windows 9», такие программы легко приняли бы её за Windows 95/98, и последствия предсказать было бы сложно.

Легендарные костыли в продакшене - 2

Microsoft всегда трепетно относилась к обратной совместимости, поэтому версия про «костыльный» код звучала правдоподобно. Официально в компании объясняли пропуск «девятки» маркетингом и желанием подчеркнуть разрыв поколений. Но факты подтверждали миф: в открытых репозиториях реально находили куски кода на Java, где проверка шла именно по названию ОС, а не по номеру версии.

То есть такие костыли действительно существовали. Ирония в том, что из-за них у нас нет Windows 9, а «десятка» стала новой точкой отсчёта для всей планеты.

Фантомная дата в Excel

Другой из классических примеров «вечного костыля» — история с високосным 1900 годом в Microsoft Excel. Если ввести в таблицу дату 29 февраля 1900-го, программа примет её как корректную, хотя в календаре такого дня никогда не существовало (если что, 1900-й год не был високосным).

И это не случайный баг, а вполне осознанное решение разработчиков. Дело в совместимости с легендарным табличным процессором Lotus 1-2-3. Когда-то его создатели решили считать 1900-й високосным, чтобы не усложнять расчёт дат. Microsoft, создавая Excel, пошла на хитрость — скопировала логику Lotus вместе с ошибками. Так Excel стал считать 1900 год високосным, чтобы пользователи без проблем импортировали таблицы из Lotus, даже если даты там изначально были неправильными.

Легендарные костыли в продакшене - 3

Разумеется, со временем костыль обернулся проблемами. Формально в Excel появилось смещение. Microsoft знает об этом и прямо говорит, что исправлять баг слишком дорого. Любая попытка «починить» приведёт к тому, что миллионы старых файлов окажутся сдвинутыми на один день, формулы перестанут работать, а совместимость разрушится.

В итоге компания оставила всё как есть. Пострадала только одна функция — вычисление дня недели для дат до 1 марта 1900 года. Но такие экзотические значения почти никто не использует, поэтому аномалия живёт, а фантомный 29 февраля 1900-го превратился в мем. 

Тестерский чит, ставший традицией

↑↑↓↓←→←→ B A — узнаёте? Это Konami Code, пожалуй, самый известный чит-код в истории. И начался он как обычный костыль для тестеров.

В 1986 году разработчик Кадзухиса Хасимото портировал аркадную Gradius на NES и понял, что проходить игру во время отладки невозможно — слишком сложно. Чтобы упростить жизнь, он добавил секретную комбинацию, которая сразу выдавала все бонусы. Обычно такие тулы удаляли перед релизом, но в этот раз код в игре остался — то ли по забывчивости, то ли из осторожности.

Легендарные костыли в продакшене - 4

Игроки быстро нашли комбинацию. Но настоящую славу Konami Code получил годом позже в Contra — заветная последовательность давала 30 жизней. Геймеры были в восторге, а Konami сделала код своей фишкой и начала встраивать его в другие игры. Уже осознанно, как пасхалку.

Так простой костыль для разработчика превратился в культурный феномен. Сегодня Konami Code встречается не только в играх, но и на сайтах, вроде Google.

Космический костыль для памяти

В 2014 году инженерам NASA пришлось изобретать настоящий костыль, чтобы продлить жизнь марсохода Opportunity. По плану он должен был работать 90 дней, но к тому моменту бороздил Марс уже одиннадцатый год. Научная аппаратура оставалась в строю, а вот компьютер начал «забывать».

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

Легендарные костыли в продакшене - 5

Поменять микросхему на Марсе невозможно, зато можно обмануть софт. Сначала инженеры перевели ровер в режим без флэш-памяти: всё писалось только в оперативку и срочно передавалось на Землю до наступления марсианской ночи. 

После NASA пошло дальше. В прошивку внесли изменения так, чтобы компьютер просто «забыл» про сбойный банк памяти. Opportunity стал считать, что у него шесть банков вместо семи, и больше не пытался писать в проблемный участок. Команда отправила патч на Марс, ровер переразметил флэш — и проблема исчезла.

Костыль оказался идеальным: Opportunity продолжил сохранять данные уже на шести банках и проработал ещё несколько лет, вплоть до 2018 года. 

Специальный код для SimCity

Когда Microsoft готовила Windows 95, под Windows 3.x накопились тысячи программ, и пользователи не простили бы, если бы любимые приложения вдруг перестали запускаться.

Самый известный костыль той эпохи — история с SimCity. Культовая игра для Windows 3.x имела баг: при старте она случайно читала память, которую только что сама освободила. На старой архитектуре это не мешало, так как система держала память чуть дольше, и игра работала. Но в Windows 95 менеджер памяти стал 32-битным и вёл себя иначе. В бета-версиях новая ОС просто роняла SimCity.

Легендарные костыли в продакшене - 6

Исправить игру было невозможно — код уже устарел, да и нельзя требовать от пользователей покупать «правильную» версию. Тогда в Microsoft пошли на радикальное решение — прямо в ядро Windows 95 встроили проверку. Если запускалась SimCity, система переключала менеджер памяти в особый режим и задерживала освобождение памяти, чтобы игра не падала.

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

SimCity была не единственной. В Windows 9x и NT подобных хаков набралось немало. Microsoft действительно была одержима обратной совместимостью и тратила ресурсы на то, чтобы старый софт жил дальше. 

Глобальный замок на 30 лет

Один из самых известных «вечных костылей» в разработке — это GIL в Python. Global Interpreter Lock появился в начале 90-х как простой способ добавить многопоточность. Для того времени это был разумный компромисс. Python управлял памятью через подсчёт ссылок, а синхронизировать каждую операцию было бы слишком сложно. Да и язык в основном использовался в однопоточных задачах, про многоядерные процессоры мало кто думал.

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

Легендарные костыли в продакшене - 7

Сообщество спорило об этом десятилетиями. Появлялись патчи, форки вроде PyPy или GIL-less Python, но официальный интерпретатор оставался однопоточным. Лишь в 2023 году PEP 703 предложил собрать Python без глобальной блокировки. И всё же в 2025-м стандартный Python всё ещё живёт с GIL.

Жить в костылях или исправлять?

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

С железом у админов таких историй хватает. Кто-то подвешивал диски на кабелях в серверах, потому что не хватало места, кто-то крепил SSD на липучку или просто вставлял его в картонную коробку. Другие «чудеса инженерной мысли» описал тут

В софте всё то же самое. Вместо поиска утечки памяти или настоящей причины зависания некоторые ставили ночной ребут и даже Docker «лечили» перезагрузкой. Кто-то умудрялся автоматизировать развёртывание VDS на VMware, где не поддерживалась AlmaLinux через смену названия на CentOS. А другие вовсе «убирали» ограничения совместимости с помощью эмулятора для ретро-игр. 

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

А какие костыли встречались у вас? Делитесь историями в комментариях.

© 2025 ООО «МТ ФИНАНС»

Автор: SrvTrantor

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js