Обратный визит-эффект

Визит-эффект это феномен, когда некая система, ранее работавшая безукоризненно, вдруг выходит из строя ровно в тот момент, когда её работу надо продемонстрировать начальству или аудитории. Бывалые IT-шники могут вспомнить знаменитую презентацию на выставке COMDEX в Чикаго весной 1998 года, когда бета-версия Windows 98 упала в «синий экран» прямо на сцене.

Но существует и более редкая разновидность визит-эффекта, известная как обратный визит-эффект.

Отец в 1980-х руководил отраслевой лабораторией киевского политеха, которая занималась разработкой тепловизоров для военных, а конкретно — проектировал вертолётные тепловизионные прицелы.

Как-то раз приезжает туда инспекция в ранге целого замминистра, причём он был не просто бюрократом, а человеком с инженерным опытом и образованием и хорошо понимал, что и зачем тут делается. Лаборатория находилась на 7-м этаже корпуса, стендовый образец включили и направили в открытое окно на проходящую рядом трамвайную линию. Ну как рядом, там метров 700 было до трамваев.

И вот на экране видно проезжающий трамвай, на лобовом стекле которого отчётливо заметен стеклоочиститель. В инфракрасном диапазоне и с 700 метров! У всех присутствующих разом отвисли челюсти — такое было невозможно! Уровень технологий 1980-х ещё не позволял достичь такой чёткости изображения а зачастую ещё и требовал криогенных условий (которых тут тоже не было — обычный германиевый объектив на почти стоковой телекамере с пировидиконом), и поэтому операторов тепловизионных прицелов в армии специально обучали распознавать цели: размытое пятно примерно такой формы это танк такой-то модели, а вот это размытое пятно чуть-чуть другой формы это уже другая модель танка.

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

Но, к сожалению, последствия обратного визит-эффекта оказались более печальными, чем прямого. Финансирование работ было увеличено и сразу же нашлись люди, не имеющие никакого отношения к разработке, но готовые присвоить себе должности, славу и премии. А тот тепловизор больше никогда так и не смог выдать ничего подобного, как его ни крутили. Это послужило благодатной почвой для конфликтов и, в конечном итоге, тема была со скандалом закрыта вместе с лабораторией.

Магия vs технология

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

Технология — любая, от каменных инструментов до космических кораблей — работает на основе принципа причинности. Это значит, что в любой технологической системе можно проследить путь от начального воздействия на входе, через определённые этапы взаимодействий внутри системы (где каждый этап заранее задан, это важно) и до результата на выходе. И не особо влияет тут тот факт, что мы можем не понимать некоторые детали реализации системы, например в случае с человеческим мозгом или достаточно развитой нейросетью. Суть одна — результат определён архитектурой и она известна.

Магия же работает по принципу целеполагания (в английском есть более подходящий термин «purpose-driven», но я не знаю, как его точнее перевести). Это значит, что результат воздействия заранее и строго обусловлен, а сверхъестественные механизмы преобразования задачи в результат, которые задействованы для его достижения, могут быть даже и полностью непонятными (либо в принципе непознаваемыми) для пользователя.

Если это слишком сложно звучит, представьте себе условную задачу — наполнить водой стакан. Технологический подход предполагает, что вода будет транспортирована от источника к стакану одним из многих способов (поставить стакан под кран с водой, кинуть шланг, добыть воду из колодца, зачерпнуть из реки etc.) Все промежуточные этапы воды от крана к стакану понятны и наглядны.

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

Подытоживая, если путь решения задачи (путь воздействия в системе) доступен для понимания — это технология. Если нет — это магия. Именно поэтому третий закон Артура Кларка и опирается на понятие «развитой технологии», которое является относительным к развитию самого понимающего. То есть, чем менее он интеллектуально развит, тем большее количество технологий будут казаться ему магическими. Хорошо иллюстрируют этот вывод так называемые «культы карго». Аборигены не могли понять, как работает логистика и пытались воспроизвести результат магическими средствами, т.е. имитацией действий уже успешных «магов» — формулируя сразу желаемый результат.

Null pointer dereference

Есть ли место магии в IT? Иногда мне кажется, что есть, когда я сталкиваюсь с её проявлениями с неожиданной стороны. Например, сейчас я настраиваю на своём рабочем компе Gentoo Linux в дуалбуте. Обнаружил неприятный эффект, когда примерно 9 из 10 попыток загрузки ядра заканчиваются паникой и зависанием намертво, а на 10-ю попытку оно вдруг решает загрузиться как положено и работает безукоризненно сколько нужно.

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

И ситуация кардинально изменилась — теперь уже ядро те же самые 9 из 10 раз загружается и работает успешно и лишь один раз (примерно) изволит паниковать и виснуть. Как? Что? Почему? И главное — за что мне всё это?

Не пора ли поженить третий закон Кларка с основами теории систем и вывести какое-нибудь следствие, в соответствии с которым любая достаточно сложная технологическая система начинает проявлять магические свойства?