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

Я около 20 лет работаю в сфере создания и внедрения тиражируемых программных продуктов для крупного бизнеса: от СУБД до платформ управления данными и ML. В этой статье хочу описать типовые требования, которые предъявляют организации к вендорским продуктам. Чем большему количеству требований удовлетворяет продукт, тем выше вероятность продаж, но и выше расходы на разработку и поддержку. 

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

В основном все требования связаны с обеспечением надежности и безопасности. Особенно, если ваше ПО относится к бизнес-критичным системам.

1. Установка в контур компании

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

Рынок on-premise очень силен в России. Около 90% софта размещается именно в контуре. В свою очередь размещение ПО внутри компании приводит к остальным требованиям и появлению ряда стейкхолдеров, с которыми не сталкиваются облачные сервисы. Это, например, департамент кибербезопасности, департамент инфраструктуры и эксплуатации ИТ-систем. 

2. Присутствие в реестре российского ПО

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

3. Поставка в виде релизов и патчей 

Разработка тиражируемого софта для установки в контур компаний сильно отличается от развития облачного сервиса. Вместо одной инсталляции приходится иметь дело с многими копиями системы. У разработчиков не будет возможности свободно доставлять обновления в режиме Rolling update. Это приводит к необходимости фиксировать версии ПО и выпускать стабильные релизы.  Со временем у разных заказчиков версии ПО обязательно разойдутся. При этом каждый клиент будет требовать SLA на исправление багов, следовательно нужно выпускать патчи для разных версий. Также почти каждый крупный заказчик будет активно генерить запросы на изменения именно для своей версии. Чем критичнее и крупнее система, тем меньше заказчики будут готовы устанавливать обновления. Каждое обновление может нести риски простоя и требовать значительных ресурсов. Слепое следование всем запросам и неудачная релизная политика может убить продукт и свести его к отдельным кастомным проектам под отдельных клиентов, требующих отдельных команд разработки и поддержки. Рынок знает такие примеры. Поэтому важно тщательно продумать релизную политику продукта: определить частоту релизов, готовность выпускать патчи, количество одновременно поддерживаемых версий, политику продаж и поддержки предыдущих версий, меры мотивации клиентов по переходу на новые версии.

4. Требования к безопасности дистрибутива

Многие клиенты имеют ряд требований безопасности к дистрибутиву:

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

• Если при разработке использовались open-source проекты или библиотеки, заказчики будут требовать проведения статического и динамического анализа кода. В целом наблюдается тренд на ужесточение требований к безопасной разработке. Некоторые особо тревожные клиенты могут накладывать ограничения на использование любых версий открытого софта (в том числе Python-библиотек), выпущенных после февраля 2022. 

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

5. Поддержка различного «железа»

Если ПО устанавливается на «голое» железо, а не в среду контейнеризации или виртуализации, от вас запросят лист совместимого оборудования. Чтобы гарантировать работоспособность на определенном «железе», необходимо регулярно тестировать софт на указанном оборудовании. Причем, это может быть как ранее закупленные организациями DELL-ы, так и новые российские «Ядро», «Аквариус», «Дельта», «Крафт вей» и т.п.

Кстати, в ряде случаев кроме x86 могут встречаться требования поддержки архитектур ARM или Power.

6. Поддержка операционной системы заказчика

У крупных компаний обычно есть whitelist из 2-3 операционных систем, которые разрешены регламентами. Остальные - запрещены. В этих ОС в компании есть экспертиза эксплуатации, зеркала репозиториев, автоматизация установки, обновления и проверки ИБ. Поэтому клиенты крайне неохотно внедряют ПО на базе других ОС, так как это приводит к «зоопарку» систем и усложняет эксплуатацию. Раньше компании эксплуатировали в основном Ubuntu или Centos/RHEL. Сейчас после 2022 года рынок сильно фрагментировался. Регулируемые и госкомпании внедряют российские операционные системы: Alt Linux, Astra Linux, Red OS, и т.п. Другие менее регулируемые компании эксплуатируют Ubuntu, Debian, Rocky linux… Есть даже крупные клиенты, которые разрабатывают и внедряют у себя СВОЮ собственную ОС и требуют от вендоров ее поддержки. Кстати, требование к поддержке определенной ОС может касаться не только хостовой системы, но и гостевой внутри docker-контейнеров. Поддержка каждой новой ОС для продукта — это всегда затраты. Затраты на сопровождение отдельной ветки сборки, тестирование совместимости и т.п. Важно иметь возможность оценить эти затраты и сопоставить с потенциальной выручкой.

7. Поддержка корпоративного платформенного софта заказчика

Если в состав продукта входят распространенные системные компоненты (например, СУБД, очереди и брокеры сообщений, реестры артефактов, хранилища секретов и др.), многие крупные клиенты захотят заменить их на аналоги, которые уже эксплуатируются в организации. Например, вместо инсталляции вашего Postgres, клиент попросит использовать уже существующий свой платформенный сервис. Это связано с тем, что существующий Postgres уже обслуживается в компании, уже настроена его отказоустойчивость, мониторинг, резервное копирование, установлены окна техобслуживания, компонент проверен службой безопасности и внесен во все регламенты. Используя свои системные компоненты, клиент рассчитывает на оптимизацию затрат на эксплуатацию вашего ПО. В свою очередь это может порождать ряд проблем для вендора, так как продукт будет «завязан» на конкретные версии системного софта. Помимо версий могут быть отличия в настройках, конфигурации, режиме работы, что приведет к дополнительным расходам на поддержку совместимости. При этом вендор теряет свободу в выборе компонент, так как после первого внедрения уже не просто будет заменить тот же Postgres на другую СУБД. Первый очевидный вариант для вендора - отказать клиенту и использовать только свои компоненты. Это исключает рост затрат на обеспечение совместимости с ПО заказчика, но приводит к конфликтам на этапе продаж. Второй вариант - согласиться на использование компонент клиента и попасть в зависимость. Третий промежуточный - вынести участки взаимодействия с системными компонентами на определенный уровень абстракции, учесть в архитектуре возможность их замены, реализовать в виде коннекторов/адаптеров. В этом случае можно даже передать разработку и поддержку коннектора на сторону интегратора или клиента, сохранив границы ключевого функционала продукта.

8. Автоматизированная установка в контуре без доступа в интернет

Как оказалось, для многих вендоров, не очевидный пункт. Обычно у крупной компании есть сформированные регламенты по управлению жизненным циклом ПО, которому все должны следовать. Для каждой системы используется минимум два окружения: DEV/TEST и PROD. Сначала софт должен быть установлен на DEV/TEST среде. После проведения необходимых тестов и согласований новая (или первая) версия ПО может «дойти» до PROD-а. Окружений в общем случае может быть и больше (UAT, PREPROD и т.п.). Ниже опишу несколько типовых требований, связанных с поддержкой процесса управления жизненным циклом ПО в крупных компаниях:

• Необходима полная автоматизация установки. Ручные действия должны быть исключены. Любые операции должны быть описаны кодом, в соответствии с Infrastructure-as-a-Code подходом.

• Должны быть предусмотрены как шаги по установке/обновлению, так и шаги по откату на предыдущую версию в случае сбоя обновления.

• Установка без доступа в интернет. В закрытом контуре компании не получится установить какие-либо пакеты из источников в интернете. Дистрибутив должен содержать все необходимое для установки софта или инсталлятор должен уметь работать с разрешенными зеркалами внутри компании. Кстати, наличие, доступность и состав таких зеркал необходимо выяснить заранее. Часто бывает, что зеркало есть, но содержит не все нужные пакеты и библиотеки. 

• Часто требуется встроиться в CI/CD пайплайны заказчика. Для этого полезно иметь типовые наработки (плейбуки, чарты) на своей стороне. 

9. Требования к безопасному запуску приложений

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

Общие требования:

• поддержка ряда требований к аутентификации/авторизации;

• поддержка ролевого доступа к функциям и данным;

• аудит действий пользователя;

• шифрование данных;

• шифрование сетевого трафика (внутреннего и внешнего) ;

• поддержка сертификатов клиента;

• отсутствие неиспользуемых объектов в системе;

• поддержка антивирусных систем клиента;

• отсутствие hardcoded или дефолтных паролей.

Для работы поверх операционной системы:

• запуск от имени определенного пользователя с определенным набором прав (root исключается);

• поддержка selinux;

• поддержка установки и работы только в определенных каталогах ОС.

Для работы поверх среды контейнеризации:

• загрузка контейнеров только из доверенных репозиториев;

• запуск контейнеров с минимальными привилегиями;

• контроль входящего/исходящего трафика;

• отсутствие прямых сетевых доступов к контейнерам;

• отсутствие persistent volumes;

• соответствие политикам контейнерной безопасности, принятым в компании. 

10. Интеграции с ИТ-ландшафтом клиента

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

• Система аутентификации и контроля доступа. В этой системе содержатся все корпоративные учетные данные, актуализируются права, учитываются увольнения и т.п. Сейчас помимо Microsoft Active Directory внедряется ряд аналогов на базе FreeIPA, Avanpost, Samba DC и др. Интеграция с такой системой позволяет службе ИТ централизованно управлять доступами до всех систем в компании и обеспечивать единство и безопасность хранения учетных данных и паролей

• Система мониторинга. Обычно требуется интеграция с системами на основе Zabbix или Prometheus, но могут встречаться и другие. Интеграция с системой мониторинга позволит встроить ПО в единый корпоративный процесс поддержки непрерывности работы ИТ-систем

• Система аудита безопасности (SIEM). Обязательное требование со стороны ИБ - выгрузка событий аудита в SIEM-систему. Обычно требуется выгрузка в формате syslog определенного набора событий. Важно протоколировать не только успешные действия пользователей, но и попытки. Некоторые заказчики могут требовать, чтобы система останавливала работу в случае обрыва соединения с SIEM-системой.

• Система логирования. В крупных компаниях для упрощения разбора инцидентов используются централизованные хранилища логов ИТ-систем.

11. Отказоустойчивость

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

Это приводит к необходимости проектирования системы с дублированием узлов и поддержкой работы в кластерном режиме. Это актуально для всех компонент, из которых состоит система. Так, например, СУБД разворачивают в режиме мастера и нескольких реплик, сервисы - на нескольких хостах с балансировкой. Хорошим подходом является изначальное проектирование приложения, как Cloud Ready или Cloud Native . В этом случае большую часть работы по обеспечению отказоустойчивости можно передать среде контейнеризации.    

12. Катастрофоустойчивость

Если система имеет высокую критичность для бизнеса, то она должна поддерживать требования катастрофоустойчивости. Такую систему строят в двух и более ЦОД-ах в режиме растянутого кластера или репликации. Если софт работает поверх системы виртуализации или контейнеризация, возможно, DR уже реализуется средствами среды функционирования. Если софт устанавливается поверх операционной системы на железные сервера, то организация катастрофоустойчивости ложится на плечи вендора и/или интегратора. Также, если софт использует системные сервисы (СУБД, очереди) или СХД заказчика для хранения данных, то у них уже может быть проработан вопрос репликации данных в другой ЦОД. Останется только организовать схему переключения.

13. Сопровождение без оперативного доступа к самой системе

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

14. Техническая документация 

Так как за работоспособность системы будут отвечать различные службы у заказчика, возрастают требования к документированию, по сравнению, например, с облачными сервисами. 

Клиенты обычно требуют:

• Руководство по установке;

• Руководство пользователя;

• Руководство администратора;

• Руководство по диагностике и устранению неполадок;

• Руководство по организации катастрофоустойчивости;

• Руководство по обновлению и откату;

• Руководство по проектированию (включая требования к инфраструктуре) ;

• Руководство по безопасности.

Также при внедрении системы будут появляться такие документы, как:

• Техническое задание на поставку и внедрение;

• Программа и методика испытаний;

• Паспорт инсталляции (описание текущей инсталляции, настройки, доступы, интеграции, схемы, диаграмма развертывания и т.п.).

15. Сертификация ФСТЭК

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

Заключение

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

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

Желаю удачи всем разработчикам тиражируемого софта!