«Подводные камни» при внедрении ПО: чего ждать на каждом этапе проекта

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

От чего зависит сложность проекта

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

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

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

1. Полная изоляция системы от ресурсов, размещенных в сети Интернет;
2. Катастрофоустойчивое решение;
3. Использование Kubernetes;
4. Собственное (брендированное) приложение;
5. Особенные требования или ограничения в части ИБ;
6. Требование по наличию TLS-ГОСТ шифрования.

Вам также может быть интересен материал Компас CIO:

Как ОТП Банк построил эффективную PaaS платформу на базе Deckhouse

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

Какие сюрпризы могут ждать на разных стадиях проекта

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

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

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

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

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

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

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

ТОП-5 причин, по которым опытная эксплуатация может пойти не по плану:

1. Не все порты открыты, или они оказываются закрыты в процессе развертывания;
2. В ИТ-инфраструктуре используются нестандартные решения или подходы;
3. Несвоевременное подключение службы информационной безопасности и, как следствие, появление ранее не выявленных требований ИБ;
4. Появление новых требований к наличию функциональности «как в нашей старой системе»;
5. Неожиданный профиль нагрузки.

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

Новый взгляд на внедрение ПО через призму ИБ

В последнее время у российских заказчиков существенно изменился подход к информационной безопасности. Еще недавно бизнес переживал уход MS Teams и других иностранных мессенджеров, а уже сегодня предъявляет отечественным вендорам требования в части ИБ, которым западные решения никогда не соответствовали. Это касается, например, шифрования канала связи, возможности управления потоками данных и полного контроля над серверной частью системы. Причина не только в новых требованиях российских регуляторов. Раньше заказчики были вынуждены использовать готовые решения мировых вендоров ввиду отсутствия адекватных аналогов, а теперь могут строить безопасную коммуникационную платформу под собственные бизнес-задачи. И в этом им хорошо помогают отечественные разработчики, которые всегда готовы прислушиваться к потребностям каждого заказчика.