Софтверное импортозамещение: какова цена вопроса?

Автор: Андрей Колесов, обозреватель PCWEEK

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

Как уже сообщалось, 22 августа произошла авария при выводе ракетоносителем «Союз-СТ-Б» на околоземную орбиту спутников Galileo FOC. (Кстати, вот характерный пример эффективной международной системы разделения труда: ракета — российского производства, стартовала она с космодрома Европейского космического агентства (ЕКА), а Galileo — совместный проект спутниковой системы навигации ЕC и ЕКА при участие еще ряда стран — Китая, Южной Кореи, Израиля, Украины). В первых сообщениях говорилось об удачном запуске (он показывался в прямом эфире по телевидению), но потом выяснилось, что ракета не вышла на расчетную орбиту, спутники оказались «потерянными» для работы. Из-за этой неудачи полномасштабный запуск сервисов Galileo отложен на более поздний срок. В публикациях по этому поводу нигде не называется «цена вопроса», но понятно, что Россия будет вынуждена поучаствовать в финансовых компенсация (хотя, скорее всего, запуск был застрахован) и ее имиджу космического лидера нанесен удар (с возможными деловыми потерями).

Внешняя причина неудачи была установлена и признана российской стороной практически сразу: проблема оказалась в разгонном блоке. Но что именно с ним произошло? Комиссия Роскосмоса уже определилась с наиболее вероятной версией, о которой, как это уже стало принято в нашем сегодняшнем медиапространстве по гостематике, первыми общественности сообщили «Известия»: «Сбой в работе разгонного блока „Фрегат-МТ“, из-за которого космические аппараты оказались на нерасчетной орбите, произошел из-за некорректной работы системы управления, изготовленной московским ФГУП „Научно-производственный центр автоматики и приборостроения имени академика Пилюгина“ (НПЦАП)... Скорее всего, нештатная работа интегрированной системы управления стала результатом ошибки в программном обеспечении, заложенном на борт. В результате разгонный блок получил неправильное полетное задание и, отработав в полном соответствии с заложенной программой, доставил аппараты не по адресу». ПО было разработано также в НПЦАП.

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

Технологическая безопасность — это не только и не столько независимость от того или иного поставщика, а в первую очередь — надежность. А уровень надежности продукта самым прямым образом коррелирует с его массовостью. В общем случае, надежность тиражного ПО всегда выше заказной разработки, а надежность крупнотиражного — выше, чем малотиражного. Объяснение тут очень простое: чем больше людей (пользователей) участвуют в тестировании продукта, тем больше ошибок в нем устраняется. Чем больше продукт продается, тем больше его разработчик может тратить (и тратит) на повышение качества, тестирование, отладку. Всем также хорошо известно, что, в среднем, надежность, версии x.1 выше, чем x.0, а версии x+1.0 — выше, чем x.0. При этом совсем не является секретом, что не каждый продукт 1.0 доживает до возраста 2.0.

Есть и другой важный аспект технической безопасности: деловая устойчивость поставщика и его готовность к поддержке и развитию своего продукта. Конечно, к встроенным программам управления полетом ракеты это имеет малое отношение (это все же вещи, скорее, одноразового применения), а вот для обычных информационных систем — это очень актуальных вопрос. ПО — это хоть и «мягкая» вещь, но весьма и весьма «долгоиграющая». Меняются аппаратные средства, порой весьма радикально, а выбранное когда-то ПО функционирует порой десятилетиями, причем не просто функционирует, а живет, постоянно модернизируясь, обрастая новым функционалом и интегрируясь в деятельность организации. Выбирая программные решения долгосрочного и критически важного для предприятия назначения, заказчик непременно должен задавать себе вопрос: сможет ли поставщик обеспечить поддержку этого продукта как в ближайшей, так и в отдаленной перспективе, будут ли выходить следующие версии продукта, что будет с самим разработчиком этого ПО через 5–10 лет? В этом плане хотелось бы напомнить, что при приобретении «серьезного» ПО давно существует неформальное, но общепринятое правило: продукт можно приобретать, только если он имеет номер версии не ниже 3.0 — этот тот «возраст» ПО, когда оно достигает нужного уровня зрелости по надежности и функционалу, а главное — показывает, что продукт вышел на стабильный режим развития в будущем.

И все же один важный аспект темы «технологической независимости» в случае с российской космической техникой имеется. Правда, это было весной, когда на одиннадцать часов вышли из строя все аппараты ГЛОНАСС, причем причиной были тоже ошибки в ПО. Но только сейчас стали известны любопытные нюансы этой истории. Оказывается (об рассказали те же «Известия»), «программные коды для обеспечения ГЛОНАСС сделаны на собственной программной платформе, чтобы исключить возможность внешнего воздействия. Однако в нашей оригинальной программной среде недостаточно средств разработки. Поэтому изначально программы пишутся в среде операционной системы Windows, а затем их перегоняют с помощью компиляторов в оригинальный продукт. Ошибка в уравнении, которая привела к сбою в системе, появилась как раз в процессе перевода программного кода из одной среды в другую».

То есть получается так. Из соображений «внешнего воздействия» для управления группировкой ГЛОНАСС используется некая собственная ОС. Но средства разработки в ней слабы и, по сути, представлены лишь компилятором и компоновщиком. Поэтому используется кросс-платформенная методика, когда разработка и отладка выполняется в одной ОС, а потом отлаженный исходный код перегоняется в другую ОС (не будем гадать, на базе чего сделана «оригинальная программная среда», хотя вариант тут виден только один). Не надо быть большим знатоком программирования, чтобы понять, насколько это не простая и даже рискованная операция (это можно легко понять на примере трансформации Windows-программ в Linux-среду). Таким образом, получается, что обеспечив «исключение возможности внешнего воздействия» (исключено ли на самом деле — это отдельный вопрос) авторы этой идеи пошли на серьезный риск работоспособности ПО в целом.

Вот тут и встает вопрос: что же нам нужно — обеспечение работоспособности важных систем в обычное, мирное время или в «особый период времени»? Впрочем, будет ли это работать в «особый период», тоже никто гарантировать не может.

Полный вариант статьи

Комментарий Александра Савельева, заместителя генерального директора компании «ИнтерТраст» по разработке программного обеспечения:

Как бы это не звучало банально, но разработчику ПО на своем рабочем месте удобней работать в среде одной какой-то ОС, с определенным набором фреймворков и компиляторов (как продуктов). Если ПО должно работать в мультиплатформенной среде, то это исходное требование не может не выполняться разработчиком и свой код он будет писать так, чтобы не использовать специфические свойства определенной платформы. Иначе первый же тестовый прогон системы на другой платформе даст сбой, если система вообще сможет стартовать.

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

В этом смысле я не понимаю, почему автор связывает надежность ПО и отечественные корни этого ПО. Российское ПО вполне может быть очень надежным и конкурентноспособным, как в "мирное время", так и в "особый период времени", если подойти к вопросу надежности серьезно и отвественно.

Перейти к разделу "Строим  открыто"