Любопытные извращения из мира ИТ — 5

История первая. Роковые буквы

[Оригинал]

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

Это было обширное пространство, а Джордж находился на том этапе своей карьеры, когда ему полагался отдельный офис с видом на переулок.

Его первой задачей стало устранение проблемы в Mac-версии программного обеспечения компании. В Windows она выглядела идеально, но на OSX появлялись баги рендеринга шрифтов. Подобный баг трудно найти, но Джордж, вероятно, был в прошлой жизни детективом, поэтому оказался готов к этому испытанию.

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

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

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

Разочарованный Джордж решил подойти к ней с другой стороны. На экранах с багами рендеринга всегда были один или два специализированных шрифта. Джордж загрузил шрифты в утилиты проверки шрифтов Adobe и Microsoft, и увидел отчёты о целой куче ошибок.

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

На следующий день начальник подошёл к Джорджу: «Президент хочет с тобой встретиться, срочно».

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

«Что не так с вами двоими? Джордж, ты здесь меньше четырёх месяцев, и уже транжиришь моё время — ты транжиришь мои деньги на какую-то бредовую идею о проблеме в шрифтах?»

«Но так и есть. Я могу показать».

«В версии для Windows шрифт работает отлично! Проблема должна быть в коде, чёрт возьми. Я знаю, сколько тебе платят. Может, мне стоит взять калькулятор и подсчитать, сколько стоила компании эта охота за призраками?» Он стукнул кулаком по столу так, что калькулятор рядом с клавиатурой немного подпрыгнул.

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

После короткого неоплачиваемого отпуска Джордж устроился на другую работу. Шли годы, и он уже начал забывать о времени, проведённом в Initech. Но однажды он увидел сообщение о выпуске критического патча уязвимости Microsoft Windows. Как оказалось, «код обработки шрифтов сторонних компаний» мог вызывать произвольное выполнение кода в некоторых библиотеках Windows. Проведя небольшое исследование, Джордж подтвердил свою догадку: именно код Initech вызывал проблему. Более того, последний двоичный файл Initech был выпущен ещё в 2008 году — спустя месяц после его ухода из компании.

История вторая. Работа по процессу, а также под и над ним

[Оригинал]

Когда Кевин получил в конце 1980-х работу в Townbank, он попал в ту же ситуацию, что и тысячи других новоиспечённых программистов до и после него: корпоративный программист не просто пишет код — ему нужно придерживаться процесса.

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

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

Фактор Шивы

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

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

Серьёзный бизнес!

Не то чтобы Шива был некомпетентным или неопытным системным администратором – ни в коем случае. На самом деле, когда в Townbank было принято решение о миграции с мейнфрейма на VAX, имя Шивы было в начале очень короткого списка людей, способных справиться с такой инфраструктурной миграцией. Шива взялся за дело со всей ответственностью, введя собственные политики, способные помочь в устранении изъянов процесса. Например, каждое утро все разработчики, аналитики или сотрудники отдела контроля, прежде чем войти в среду, должны были в буквальном смысле расписаться на доске в офисе Шивы, чтобы подтвердить своё физическое присутствие. Кроме того, чувствуя, что отслеживание действий разработчика реализовано с недостаточной степенью детализации, он ввёл защиту контроля версий: для каждого изменения кода и переноса между средами требовалась служебная записка. А все изменения должны были вноситься по его идентификатору пользователя. И с его терминала.

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

Массы роптали и проклинали судьбу, но вместо того, чтобы восстать, свергнуть Шиву и покончить с его жестоким правлением, все смирились и продолжили работу. Несмотря на помехи и усилия Шивы процесс продолжался, однако была одна ситуация, которой Шива, похоже, пренебрёг — что если он сам окажется недоступен?

Маленький помощник программиста

Хотя терминал Кевина показывал, что он работал в клоне среды продакшена, имена клиентов «Nosmo King» и «Joe Blow» дали ему понять, что он совершил грубый недочёт — приложение ошибочно подключалось к базе данных среды разработки, а после обеда его должен был тестировать отдел контроля качества. В обычной ситуации исправить ошибку было бы проще простого — внести изменения в файл конфигурации в среде разработки и возобновить работу, но судьбе было угодно, чтобы Шива оказался на длительном совещании и должен был появиться только на следующий день.

Надеясь, что Шива мог вернуться раньше, Кевин подошёл к его столу, но увидел только пустой стул. Однако его внимание привлекла клавиатура Шивы. Буквы A, S, V, H и I были стёрты больше остальных. Кевин знал, что Шива опьянён властью, но неужели он настолько нарциссичен, что готов печатать своё имя снова и снова? …А может быть, это подсказка? Ради забавы Кевин перешёл в командную строку и ввёл «shiva» в качестве имени пользователя и пароля. Ожидая, что Шива может в любой момент войти в кабинет, Кевин нажал на «Ввод» и был потрясён тем, что ему удалось выполнить вход.

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

Оказалось, что комбинация имени пользователя и пароля Шивы была любимым «секретом» Townbank, который был известен ещё со времён, когда Шива работал администратором мейнфрейма.

«Чтобы Шива не узнал, — объяснил Кевину другой, ещё более опытный разработчик, — мы играем в эту игру при каждом новом его повышении».

«Кстати, на будущее, — продолжил он, — если не хочешь, чтобы тебя поймали и испортили жизнь всем остальным, то стоит входить со своего терминала, а НЕ из его кабинета».

История третья. Говори со мной на греческом

[Оригинал]

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

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

Однажды Гас получил электронное письмо от неизвестного ему профессора из колледжа в Аризоне. Он услышал от начальника Гаса о чудесной, мифической программе. Можно ли и ему получить её?

Гас с радостью бы согласился, но возникла проблема. Его программа предназначалась для предыдущей версии операционной системы VAX/VMS и компилятора Pascal, а выводила текст она на один конкретный принтер VERSAMOD-200, который можно было перевести в матричный режим, и в конкретный драйвер печати, который был аккуратно пропатчен двоичным кодом, чтобы не портить матричные изображения. Гас сомневался, что профессор обладает достаточными техническими знаниями, чтобы оценить его объяснение, поэтому ответил вежливо и не вдаваясь в технические подробности: простите, но программа просто не будет работать ни на какой другой машине.

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

«Ты же гений, Гас! Я уверен, ты что-нибудь придумаешь. Заранее спасибо!», — удовлетворённый собственным оптимизмом, начальник ушёл.

Гас начал думать, как же он сможет выполнить, или хотя бы наполовину выполнить просьбу босса. Наконец, у него появилась идея. Он ввёл в командную строку своего компьютера: DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200.

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

«О!», — начальник казался удивлённым, но понимающим.

«Если у них возникнут какие-нибудь проблемы с установкой, то пусть свяжутся со мной и я помогу», — сказал Гас.

«Отлично! Большое спасибо!», — начальник бросил взгляд на стол, ища подходящий почтовый конверт.

Чуть позже ещё одному из наших уважаемых коллег-айтишников в Аризоне передали и поручили установить этот распечатанный на бумаге дамп. Он, должно быть, испытал достаточно шокирующий момент «WTF», но, очевидно, успешно справился с задачей. По крайней мере, с того времени прошло уже тридцать лет, а Гас так и не услышал никаких вопросов от профессора или других сотрудников колледжа. Возможно, кто-то просто заключил сделку с Аидом или попросил Кроноса перенести его в то время, когда печать специальных символов перестала быть таким сизифовым трудом.

История четвёртая. Аварийные факсы

[Оригинал]

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

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

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

«Что если пользователь не сидит рядом с факсом в ожидании сообщения?», — задумался он. «Что если факс-машина отправителя не обнаружит проблему? Мы должны отправлять ему по факсу отчёт об ошибках!»

Хотя беспокойство аналитика было обоснованным, Том и его группа возражали, что отправка сообщения о сбойном факсе необязательно упростит всем жизнь.

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

«Это нормально, — ответил аналитик, — наше ПО может отправлять и получать факсы параллельно. Эта идея — лучшее, что появилось после iPod! Она абсолютно надёжна!»

Но споры были бессмысленны: в глазах руководства бизнес-аналитики всегда правы, и эту функцию в срочном порядке реализовали. Программу назвали «FaxBack», и она выполняла соответствующую названию функцию: передавала сбойную передачу обратно отправителю (определённому по Caller ID) через короткий промежуток времени после возникновения сбоя.

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

Вскоре офицеры уехали, но рано утром следующего дня к офису стремительно подъехали два других полицейских автомобиля. Никакого ЧС снова не было и никто не звонил по 911, поэтому они спокойно покинули офис.

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

Потратив остаток дня и часть вечера на отслеживание телефонных звонков внутри компании, Том выяснил, что вызовы на номер 911 идут из дата-центра, а конкретнее от FaxBack.

Факсимильные машины как и офисные телефоны, для выхода на внешнюю линию должны были набирать «9». Поэтому когда FaxBack отвечал на сбойный факс из Нью-Дели, набирая девятку за ней следовал международный код Индии — 11, и срабатывало «особое правило» телекоммуникационной системы.

Тому, кто устанавливал телекоммуникационную систему, пришла в голову светлая идея обрабатывать «911» как особый случай, потому что звонящий мог и не додуматься в случае чрезвычайной ситуации сначала набрать ещё одну девятку. Особое правило применялось и к линиям в пуле факсов, даже если вызывающий был всего лишь компьютером.