ПО для импортозамещения: как не ошибиться с выбором?

Не будет преувеличением сказать, что поворот к импортозамещению вызвал замешательство не только у разработчиков ПО и системных интеграторов, но и у организаций, которым действующая нормативная база предписывает переходить на незнакомые ИТ-решения, построенные на совершенно неизвестном ПО. Впрочем, не следует думать, будто замешательство охватило всех без исключения заказчиков. Еще в середине этого года в некоторых регионах стартовали тщательно подготовленные пилотные этапы крупных проектов импортозамещения с ожидаемыми сроками завершения в первом квартале 2017 года. Однако для подавляющего большинства организаций пока не совсем ясно, как подготовиться к такому внедрению, какие неочевидные моменты необходимо учесть, где существуют скрытые риски и можно ли, только приступая к внедрению, быть уверенным в его успехе? Этим вопросам и посвящена статья.

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

Проблема технологической зависимости России в области ИКТ, в частности программного обеспечения, осознана уже давно. Были приняты поручения Президента и решения Совета Безопасности и Правительства. Большой резонанс вызвало Распоряжение Правительства 2299-р об использовании свободного ПО в госорганах, а в госпрограмму «Информационное общество» был включен раздел по разработке НПП — Национальной Программной Платформы. К сожалению, все эти решения так и остались не выполненными, и я связываю это с тем, что в них не был предусмотрен механизм реализации. Но изменение политической обстановки резко обострило вопрос о технологической независимости. В итоге появился целый ряд решений по поддержке отечественного ПО.

Так, принятый в июле 2015 года Федеральный закон № 188-ФЗ от 29.06.2015 «О внесении изменений в статью 14-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» предоставил преференции при госзакупках отечественному программному обеспечению. Во исполнение этого закона было принято Постановление Правительства РФ № 1236 от 16.11.2015 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд».

В соответствии с имевшимися поручениями Президента РФ аналогичное изменение должно было быть внесено в 223-ФЗ, регламентирующий закупки госкорпорациями. Но государство пошло иным путем, и 11 июля 2016-го была отправлена Директива представителям государства в советах директоров госкомпаний голосовать за внесение изменений в положения о закупочных процедурах компаний, аналогичных Постановлению № 1236.

Согласно этим документам, при Минкомсвязи создан Реестр отечественного ПО, в который заносятся решения, отвечающие определенным критериям. Теперь при проведении конкурса покупатель обязан не допускать к конкурсу ПО, не входящее в Реестр. Исключение составляют ситуации, когда в Реестре нет решений соответствующей категории и когда имеющееся в Реестре ПО не соответствует требованиям конкурсной документации. В последнем случае организатор конкурса обязан опубликовать обоснование в составе конкурсной документации.

Наконец, 27 июля было принято Распоряжение Правительства № 1588 «Об утверждении плана перехода органов исполнительной власти и государственных внебюджетных фондов на использование отечественного программного обеспечения», которое предписывает всем ФОИВ перейти на использование отечественного ПО на рабочих станциях к концу 2018 года.

Таким образом, для огромного круга потребителей возникли обязательства по выбору при закупках отечественного программного обеспечения из Реестра. Однако занесение того или иного продукта в Реестр лишь удостоверяет его отечественное происхождение, но ничего не говорит о его функциональных возможностях. Поэтому в рамках выполнения Распоряжения 1588 был подготовлен проект требований, предъявляемых к офисному ПО, предназначенному для использования в ФОИВ. В частности, от прикладного ПО требуется совместимость с операционными системами на базе ядра Linux.

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

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

Сегодня к компонентам, формирующим инфраструктуру и обеспечивающим ее управляемость в большинстве организаций, относятся служба каталогов (Microsoft AD), средства организации коллективной работы (MS Exchange), средства виртуализации и управления облачными структурами. Без их замены невозможна миграция сложных распределенных систем в рамках импортозамещения. Найти замену этим системам крайне непросто. Важно выбирать решения, которые позволяют осуществлять мягкую миграцию без разовой замены инфраструктуры, но с возможностью длительной работы гетерогенной системы, в которой узлы можно заменять покомпонентно. Этим критериям наилучшим образом отвечают системы с открытым кодом Samba DC (для замены Microsoft AD) и SOGo (для замены Microsoft Exchange). Инфраструктурные компоненты обычно достаточно тесно интегрированы с операционными системами, и очень удобно, когда они предусмотрены в составе дистрибутива на базе ядра Linux. Это ключевое требование к системообразующей серверной ОС уровня предприятия для проектов импортозамещения. Важна и возможность быстрой интеграции рабочих станций в реализованную на серверах инфраструктуру — данное условие должно поддерживаться версией ОС для рабочих станций.

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

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

А как это происходит сегодня? Система ГАС Управление Казначейства РФ. Экспортирует данные якобы в формат Excel, на самом деле файл выглядит как кусок email, с вложением, закодированным по алгоритму base64. Если его раскодировать, внутри лежит обычная HTML-страничка с нарисованной таблицей. При попытке открыть ее с помощью MS Excel, программа сообщает, что расширение не соответствует формату, но все же открывает файл. НО! Ни один офис, кроме MS Office, этого не открывает. И данный пример не единичный.

Странности с форматами не просто создают неудобства. Они до сих пор являются инструментом манипулирования госзакупками через тендерные задания.

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

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

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

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

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

Замечу, что в принятом еще в 2011 году ГОСТ Р 54593-2011 «Информационные технологии. Свободное программное обеспечение. Общие положения» предусмотрено наличие для свободного ПО инфраструктуры разработки и инфраструктуры поддержки.

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

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

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

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

___________________________________________________

Рекомендации по проектам импортозамещения

1. Вектор развития задан. Примите за данность, что все ваши ИТ-проекты должны полностью отвечать требованиям нормативной базы. Лучше учитывать не только уже действующие, но и ожидаемые положения.

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

3. Запускайте сразу крупный проект перехода на реестровое ПО и начинайте с замены системообразующего. Лучше начать с ИТ-инфраструктуры: во-первых, это меньше влияет на пользователей; во-вторых, в силу большей универсальности инфраструктурные продукты будут внедряться во многих организациях и, соответственно, будут лучше проверены, раньше получат качественную поддержку.

4. Тщательно готовьте такие проекты. Выбирайте такие, которые предоставят заказчику эшелонированную защиту от проблем за счет сочетания высокого технического уровня, методической базы гарантированной технической поддержкой на основе жестких количественных SLA, причем сразу во всех нужных вам регионах. Все три линии такой поддержки должны быть масштабируемыми.

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

6. Начните взаимодействовать с разработчиками ПО, прошедшего селекцию по всем критериям. Убедитесь, что они смогут неограниченно долго развивать свой продукт, поддерживать его жизненный цикл. Имеют ли они все необходимые технологии? Коллектив? Видение перспективы? Они действительно создали и развивают весь свой продукт или только «перелицовывают» или переупаковывают чью-то разработку, на направление развития которой не влияют?

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