Интерпретация

Признаюсь честно – я не особо сильно последнее (длительное) время интересуюсь политикой и социальными вопросами. Да, происходит множество событий – человечество бурлит, начинаются и прекращаются войны, политики брызжут слюной с трибун, народ мудро их выбирает, происходят какие-то реформы, по кругу повторяются слова про мир, труд, свободу, братство, конокрадство, перераспределяются капиталы. Всё со страшной силой развивается, и каждый новый правитель обещает стать лучше предыдущего. Но я смотрю на все на это и вижу карусель с привинченными пластиковыми лошадками, на которой катается человечество. Единственное, что действительно подвержено поступательному развитию, так это технологическая база. Карусель постепенно совершенствуется, и крутиться на ней становится удобнее – появляются мягкие сиденья, электронная продажа билетиков, очки виртуальной реальности, штырь-фиксатор в жопу, чтоб не упали, не дай бог, и т.п.

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

Что такое интерпретация? Это преображение одного объекта в другой по неким правилам. С интерпретацией мы сталкиваемся постоянно – перевод с русского на английский переводчиком, интерпретация линейным менеджером того, что сказал начальник, для декомпозиции его общей задачи на своих подчиненных, перевод описания на естественном языке в формальный язык программистом, компиляция программного кода в машинный код компилятором и т.п.

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

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

1. Бизнес-требования,

2. Интерфейсные прототипы,

3. Дизайн-макеты,

4. Формальная нотация, формируемая бизнес-аналитиком,

5. Микросервисная архитектура, проктируемая архитектором,

6. Декомпозиция общей задачи в технически обоснованную последовательность подзадач техническим лидом,

7. Формализация подзадач на уровне описания обработчиков системным аналитиком,

8. Написание кода программистом,

9. Обращение в этом коде к функциям операционной системы и сторонних библиотек (далеко не все пишется с нуля),

10. Компиляция кода, написанного программистами в машинный код,

11. Интерпретация машинного кода системой виртуализации (в современных реалиях редко какой серверный код выполняется на голом железе, обычно все-таки эмулируется фиксированная среда),

12. Интерпретация системы виртуализации реальным железом, на котором она установлена.

Слои 1.-8 . – это последовательность интерпретаций задачи, находящаяся в ведении команды разработки. На этом этапе возможны (и постоянно имеют место быть) совершенно чудовищные искажения, приводящие к значительной итеративности разработки, невероятно раздувающей трудоемкость, срок и стоимость реализации технических задач. Но дальше все становится еще хуже.

Слои 9.-12 . – это то, что лежит уже вне ведения команды разработки. Никто не пишет самостоятельно все используемые библиотеки – они написаны «кем-то», и зачастую даже недоступны в исходном коде. Что они делают? Даже если библиотека доступна в исходном коде, то, как правило, аудит этого кода никто не проводит, и он может содержать любые закладки. Все программные продукты пользуются функционалом операционных систем. Операционные системы огромны и в них можно закопать вообще все что угодно. Далее компиляторы и интерпретаторы – никто себе компилятор сам не пишет, это высоко специализированное ПО, которое все берут и используют as is. Компилятор же точно все скомпилирует как надо без подстав. Система виртуализации – до недавних пор все пользовались VMWare, сейчас, в рамках импортозамещения появилось множество разных «своих» решений. Ну и, наконец, железо – то, что производить сложнее всего и пока даже предварительно нельзя сказать, когда мы научимся производить чипы по современным техпроцессам.

Близки ли мы к тому, чтобы обеспечить суверенный контроль всех этих уровней интерпретации? Пока не очень. Главное – нам надо отдавать себе отчет в том, что скоро мы столкнемся не с гипотетическими, а с вполне реальными рисками использования махинаций с правилами интерпретации нашими конкурентами. В самых разных целях – контролируемый саботаж работы АПК, слив данных, подлог, внесение в работу систем сложно отслеживаемой стохастики и т.п. Если об этом думаю я, а я об этом думаю, то об этом думают и «другие».

Все знают, что у нас есть и свои операционные системы и свои системы виртуализации и даже, вроде, есть свои производители систем хранения и процессоров, да? Да, вот только если разобраться, то  та же Astra Linux – это зафиксированная версия Debian . Насколько качественно был проведен аудит кода, учитывая то, что только в ядре Linux более 25 млн строк очень специфичного кода, а сам Debian это еще 60 млн строк кода, сложно сказать. Ладно, предположим, что в этом плане все хорошо. Думает ли кто-то о контроле используемых интерпретаторов и компиляторов кода? Если кто-то и думает, то я с ними не знаком . А импортозамещающие системы виртуализации у нас свои? Условно да, но самая, наверное, крупная из них «Брест» сделана на базе испанского продукта OpenNebula , другие на базе какого-нибудь OpenStack и т.п. Системы хранения от Yadro – это IBM , чипы Эльбрус производятся в Китае (да, они тоже наши конкуренты). Короче, перед нами еще долгий путь, который необходимо пройти, если в светлом технологическом будущем мы не хотим быть уязвимы.

Чтобы обеспечить реальную технологическую безопасность, в любом случае необходимо обеспечивать производство всех средств технологической интерпретации в некоей «доверенной зоне». И тут могу передать привет параноикам и тем, кто очень переживает о контроле со стороны государства – что для вас «доверенная зона»? Кому вы  можете доверять? Если только себе, то едва ли вы сможете обеспечить производство и контроль всего мной перечисленного. А, значит, заниматься этим будет государство – только у государств, причем далеко не у всех, будет достаточный ресурс для обеспечения необходимого комплекса производственно-контрольных мер. И государство точно позаботится о том, чтобы комплекс средств тотального контроля был реализован на всех уровнях интерпретации задачи в итоговый аппаратно-программный комплекс. Чтобы обойти эти средства контроля у нас ну совсем никак не получилось. И это хорошо – будем в полной безопасности