Дискуссии по теме импортозамещения в ИТ-сфере продолжаются, хотя, надо сказать, ответственные представители правительственных структур заметно дистанцируются от таких разговоров, поскольку понимают, что вопрос этот не только сложный, но и обоюдоострый.
Как уже сообщалось, 22 августа произошла авария при выводе ракетоносителем «Союз-СТ-Б» на околоземную орбиту спутников Galileo FOC. (Кстати, вот характерный пример эффективной международной системы разделения труда: ракета — российского производства, стартовала она с космодрома Европейского космического агентства (ЕКА), а Galileo — совместный проект спутниковой системы навигации ЕC и ЕКА при участие еще ряда стран — Китая, Южной Кореи, Израиля, Украины). В первых сообщениях говорилось об удачном запуске (он показывался в прямом эфире по телевидению), но потом выяснилось, что ракета не вышла на расчетную орбиту, спутники оказались «потерянными» для работы. Из-за этой неудачи полномасштабный запуск сервисов Galileo отложен на более поздний срок. В публикациях по этому поводу нигде не называется «цена вопроса», но понятно, что Россия будет вынуждена поучаствовать в финансовых компенсация (хотя, скорее всего, запуск был застрахован) и ее имиджу космического лидера нанесен удар (с возможными деловыми потерями).
Внешняя причина неудачи была установлена и признана российской стороной практически сразу: проблема оказалась в разгонном блоке. Но что именно с ним произошло? Комиссия Роскосмоса уже определилась с наиболее вероятной версией, о которой, как это уже стало принято в нашем сегодняшнем медиапространстве по гостематике, первыми общественности сообщили «Известия»: «Сбой в работе разгонного блока „Фрегат-МТ“, из-за которого космические аппараты оказались на нерасчетной орбите, произошел из-за некорректной работы системы управления, изготовленной московским ФГУП „Научно-производственный центр автоматики и приборостроения имени академика Пилюгина“ (НПЦАП)... Скорее всего, нештатная работа интегрированной системы управления стала результатом ошибки в программном обеспечении, заложенном на борт. В результате разгонный блок получил неправильное полетное задание и, отработав в полном соответствии с заложенной программой, доставил аппараты не по адресу». ПО было разработано также в НПЦАП.
Сразу нужно сказать: данный случай сам по себе совершенно ни о чем не говорит. С точки зрения оценки надежности любой вещи (в том числе и ПО) единичный пример не имеет никакого значения. Нужна статистика испытаний, желательно достаточно представительная. Проблема импортозамещения тут тоже никак не присутствует: в целом российская ракетная техника является не просто конкурентоспособной, а лидирующей в мире. То, что для запуска европейских спутников был выбран «Союз», а не, скажем, французская «Ариан», говорит сам за себя. То, что в качестве ПО использовалось разработка отечественно института — это тоже абсолютно нормально. Скорее всего, тут зарубежной альтернативы и не было. Да, и проблема, как можно предположить, вообще не в ПО, а неправильных данных (полетном задании), которые в нее заложили. Но, тем не менее, этот инцидент содержит аспекты, на которые хотелось бы обратить внимание.
Технологическая безопасность — это не только и не столько независимость от того или иного поставщика, а в первую очередь — надежность. А уровень надежности продукта самым прямым образом коррелирует с его массовостью. В общем случае, надежность тиражного ПО всегда выше заказной разработки, а надежность крупнотиражного — выше, чем малотиражного. Объяснение тут очень простое: чем больше людей (пользователей) участвуют в тестировании продукта, тем больше ошибок в нем устраняется. Чем больше продукт продается, тем больше его разработчик может тратить (и тратит) на повышение качества, тестирование, отладку. Всем также хорошо известно, что, в среднем, надежность, версии x.1 выше, чем x.0, а версии x+1.0 — выше, чем x.0. При этом совсем не является секретом, что не каждый продукт 1.0 доживает до возраста 2.0.
Есть и другой важный аспект технической безопасности: деловая устойчивость поставщика и его готовность к поддержке и развитию своего продукта. Конечно, к встроенным программам управления полетом ракеты это имеет малое отношение (это все же вещи, скорее, одноразового применения), а вот для обычных информационных систем — это очень актуальных вопрос. ПО — это хоть и «мягкая» вещь, но весьма и весьма «долгоиграющая». Меняются аппаратные средства, порой весьма радикально, а выбранное когда-то ПО функционирует порой десятилетиями, причем не просто функционирует, а живет, постоянно модернизируясь, обрастая новым функционалом и интегрируясь в деятельность организации. Выбирая программные решения долгосрочного и критически важного для предприятия назначения, заказчик непременно должен задавать себе вопрос: сможет ли поставщик обеспечить поддержку этого продукта как в ближайшей, так и в отдаленной перспективе, будут ли выходить следующие версии продукта, что будет с самим разработчиком этого ПО через
И все же один важный аспект темы «технологической независимости» в случае с российской космической техникой имеется. Правда, это было весной, когда на одиннадцать часов вышли из строя все аппараты ГЛОНАСС, причем причиной были тоже ошибки в ПО. Но только сейчас стали известны любопытные нюансы этой истории. Оказывается (об рассказали те же «Известия»), «программные коды для обеспечения ГЛОНАСС сделаны на собственной программной платформе, чтобы исключить возможность внешнего воздействия. Однако в нашей оригинальной программной среде недостаточно средств разработки. Поэтому изначально программы пишутся в среде операционной системы Windows, а затем их перегоняют с помощью компиляторов в оригинальный продукт. Ошибка в уравнении, которая привела к сбою в системе, появилась как раз в процессе перевода программного кода из одной среды в другую».
То есть получается так. Из соображений «внешнего воздействия» для управления группировкой ГЛОНАСС используется некая собственная ОС. Но средства разработки в ней слабы и, по сути, представлены лишь компилятором и компоновщиком. Поэтому используется кросс-платформенная методика, когда разработка и отладка выполняется в одной ОС, а потом отлаженный исходный код перегоняется в другую ОС (не будем гадать, на базе чего сделана «оригинальная программная среда», хотя вариант тут виден только один). Не надо быть большим знатоком программирования, чтобы понять, насколько это не простая и даже рискованная операция (это можно легко понять на примере трансформации Windows-программ в Linux-среду). Таким образом, получается, что обеспечив «исключение возможности внешнего воздействия» (исключено ли на самом деле — это отдельный вопрос) авторы этой идеи пошли на серьезный риск работоспособности ПО в целом.
Вот тут и встает вопрос: что же нам нужно — обеспечение работоспособности важных систем в обычное, мирное время или в «особый период времени»? Впрочем, будет ли это работать в «особый период», тоже никто гарантировать не может.
