На вопросы редакции IT-World к отвечает директор технического департамента Смарт Текнолоджис Денис Хориков
Как компании подходят к сборке отечественного ИТ-стека?
На практике импортозамещение редко выглядит как простая замена одного продукта другим. Обычно работа начинается с анализа существующей инфраструктуры: необходимо понять, какие системы являются ключевыми, как между ними организовано взаимодействие и какие зависимости нельзя нарушить.
После этого формируется целевая архитектура и уже в ее рамках принимаются решения о постепенной замене отдельных компонентов. Именно постепенной — заменить весь ИТ-ландшафт одновременно практически невозможно. При этом даже обновление операционной системы или другого инфраструктурного компонента требует отдельной проверки, поскольку способно неожиданно повлиять на работу прикладных сервисов.
Кроме того, отечественный рынок пока не предлагает полностью готовых экосистем, поэтому совместимость компонентов приходится подтверждать инженерной практикой.
Где чаще всего возникают конфликты между отечественными решениями?
Наибольшее количество проблем возникает именно в местах взаимодействия различных продуктов, в частности при интеграции.
Каждый компонент может корректно работать сам по себе, но при взаимодействии с другими, например, с операционной системой, базой данных, системой хранения или средствами интеграции начинают проявляться несовместимости. Особенно это характерно для современных модульных архитектур, где количество взаимодействующих компонентов постоянно растет.
Поэтому важнейшая инженерная задача состоит в проверке всей цепочки совместной работы отдельных решений на отсутствие конфликтов.
Чем отличается заявленная совместимость от проверенной в эксплуатации?
Заявленная совместимость — это лишь заявление, не прошедшее полного цикла тестирования в эксплуатируемой инфраструктуре. Подтвердить ее можно только в ходе практических испытаний.
Нередко оказывается, что отдельные функции работают лишь при определенных условиях или требуют дополнительной настройки. Поэтому сертификаты, письма вендоров и перечни совместимых продуктов являются необходимым, но не достаточным основанием для внедрения. Окончательные выводы можно сделать только после испытаний на тестовом стенде или в пилотном проекте, воспроизводящем условия эксплуатации у заказчика.
Опыт Смарт Текнолоджис подтверждает этот подход: в ряде проектов заявленная совместимость отдельных решений потребовала инженерной доработки перед вводом в эксплуатацию. Именно поэтому компания придерживается принципа обязательного тестирования на собственных стендах с моделированием реальных сценариев работы инфраструктуры.
Как строится тестирование связок перед промышленным запуском?
Наша команда внедрения оценивает не только корректность установки решений, но и их работу в типовых сценариях эксплуатации, влияние изменений на смежные компоненты и устойчивость всей инфраструктуры. Это позволяет устранить потенциальные проблемы еще до ввода системы в промышленную эксплуатацию.
Полноценное внедрение включает несколько последовательных этапов: проектирование, создание тестовой среды, проведение испытаний, опытную эксплуатацию и лишь затем — переход в промышленную среду.
Оптимально использовать отдельные контуры разработки, тестирования и приемки, максимально приближенные к промышленной среде. При этом соответствие системы бизнес-требованиям должен подтверждать не только исполнитель проекта, но и сам заказчик.
В ходе испытаний оценивается работоспособность каждого компонента, корректность их взаимодействия и поведение всей инфраструктуры под рабочей нагрузкой. Такой подход позволяет выявить риски, которые невозможно обнаружить при проверке отдельных продуктов в изоляции.
Как распределяется ответственность между заказчиком, интеграторами и поставщиками? Как управлять обновлениями?
Если инфраструктура состоит из продуктов разных производителей и в проекте участвуют несколько интеграторов, определить источник проблемы бывает крайне сложно. Каждая сторона может считать, что причина находится за пределами ее ответственности.
Поэтому критически важными становятся централизованное логирование, мониторинг и фиксация всех взаимодействий между компонентами. Только на основании этих данных можно объективно установить источник сбоя.
Такого же подхода требуют и обновления. Даже незначительное обновление операционной системы или другого инфраструктурного компонента может повлиять на работу прикладных сервисов, поэтому любые изменения желательно предварительно проверять в тестовой среде. Правильное построение процесса управления обновлениями требует прямого участия заказчика.
Как меняется роль интегратора?
Сегодня роль системного интегратора значительно шире, чем простое внедрение отдельного продукта. Если раньше многие решения поставлялись в составе уже протестированных зарубежных экосистем, то теперь приходится самостоятельно формировать работоспособную инфраструктуру из компонентов разных производителей. Требуется проектирование архитектуры, оценка совместимости, комплексное тестирование, контроль и анализ корректной работы всей системы.
Смарт Текнолоджис сопровождает проекты от разработки архитектурных решений и инженерной проверки оборудования и ПО до комплексных испытаний с подготовкой к вводу в промышленную эксплуатацию.
Именно системный интегратор превращает набор разрозненных продуктов в единую и устойчиво работающую ИТ-инфраструктуру заказчика.
Нужны ли компаниям внутренние матрицы совместимости?
Да, нужны, особенно если речь идет о крупных организациях. Внутренние базы знаний позволяют фиксировать уже проверенные конфигурации, версии ПО, архитектурные решения, выявлять ограничения и способы устранения типовых проблем. Формирование баз знаний значительно упрощает дальнейшее развитие инфраструктуры и снижает вероятность повторения уже известных ошибок.
Такие базы ведут не только заказчики, но и интеграторы. Дополнительно в них фиксируются особенности настроек ИБ, поскольку ограничения сетевого взаимодействия нередко становятся причиной проблем совместимости.
По мере накопления подобных данных возрастает ценность применения инструментов на базе искусственного интеллекта. ИИ способен анализировать накопленный опыт, находить связи между похожими инцидентами и предлагать решения даже в тех случаях, когда инженер не может точно сформулировать запрос или не знает, какой именно прецедент использовать. При этом ИИ не заменяет эксперта, а помогает быстрее находить релевантные варианты применения решений, которые затем оценивает и подтверждает инженер.
Что делать с legacy-системами?
Единого рецепта здесь нет — все определяется конкретной инфраструктурой, отсутствием или наличием у заказчика исходного кода и документации, технической и финансовой возможности замены решения.
Полная замена устаревших систем зачастую требует слишком больших затрат времени и ресурсов, поэтому чаще применяется постепенная модернизация отдельных компонентов. Если прикладная и системная логика задокументированы, можно относительно безболезненно заменить отдельные элементы инфраструктуры, например базу данных или сервер приложений.
Однако рассчитывать на перенос «в один клик» не приходится. Практически любая миграция требует переработки архитектурных решений, проверки совместимости и повторного тестирования всей системы перед вводом в эксплуатацию.
Как компании подходят к сборке отечественного ИТ-стека?
На практике импортозамещение редко выглядит как простая замена одного продукта другим. Обычно работа начинается с анализа существующей инфраструктуры: необходимо понять, какие системы являются ключевыми, как между ними организовано взаимодействие и какие зависимости нельзя нарушить.
После этого формируется целевая архитектура и уже в ее рамках принимаются решения о постепенной замене отдельных компонентов. Именно постепенной — заменить весь ИТ-ландшафт одновременно практически невозможно. При этом даже обновление операционной системы или другого инфраструктурного компонента требует отдельной проверки, поскольку способно неожиданно повлиять на работу прикладных сервисов.
Кроме того, отечественный рынок пока не предлагает полностью готовых экосистем, поэтому совместимость компонентов приходится подтверждать инженерной практикой.
Где чаще всего возникают конфликты между отечественными решениями?
Наибольшее количество проблем возникает именно в местах взаимодействия различных продуктов, в частности при интеграции.
Каждый компонент может корректно работать сам по себе, но при взаимодействии с другими, например, с операционной системой, базой данных, системой хранения или средствами интеграции начинают проявляться несовместимости. Особенно это характерно для современных модульных архитектур, где количество взаимодействующих компонентов постоянно растет.
Поэтому важнейшая инженерная задача состоит в проверке всей цепочки совместной работы отдельных решений на отсутствие конфликтов.
Чем отличается заявленная совместимость от проверенной в эксплуатации?
Заявленная совместимость — это лишь заявление, не прошедшее полного цикла тестирования в эксплуатируемой инфраструктуре. Подтвердить ее можно только в ходе практических испытаний.
Нередко оказывается, что отдельные функции работают лишь при определенных условиях или требуют дополнительной настройки. Поэтому сертификаты, письма вендоров и перечни совместимых продуктов являются необходимым, но не достаточным основанием для внедрения. Окончательные выводы можно сделать только после испытаний на тестовом стенде или в пилотном проекте, воспроизводящем условия эксплуатации у заказчика.
Опыт Смарт Текнолоджис подтверждает этот подход: в ряде проектов заявленная совместимость отдельных решений потребовала инженерной доработки перед вводом в эксплуатацию. Именно поэтому компания придерживается принципа обязательного тестирования на собственных стендах с моделированием реальных сценариев работы инфраструктуры.
Как строится тестирование связок перед промышленным запуском?
Наша команда внедрения оценивает не только корректность установки решений, но и их работу в типовых сценариях эксплуатации, влияние изменений на смежные компоненты и устойчивость всей инфраструктуры. Это позволяет устранить потенциальные проблемы еще до ввода системы в промышленную эксплуатацию.
Полноценное внедрение включает несколько последовательных этапов: проектирование, создание тестовой среды, проведение испытаний, опытную эксплуатацию и лишь затем — переход в промышленную среду.
Оптимально использовать отдельные контуры разработки, тестирования и приемки, максимально приближенные к промышленной среде. При этом соответствие системы бизнес-требованиям должен подтверждать не только исполнитель проекта, но и сам заказчик.
В ходе испытаний оценивается работоспособность каждого компонента, корректность их взаимодействия и поведение всей инфраструктуры под рабочей нагрузкой. Такой подход позволяет выявить риски, которые невозможно обнаружить при проверке отдельных продуктов в изоляции.
Как распределяется ответственность между заказчиком, интеграторами и поставщиками? Как управлять обновлениями?
Если инфраструктура состоит из продуктов разных производителей и в проекте участвуют несколько интеграторов, определить источник проблемы бывает крайне сложно. Каждая сторона может считать, что причина находится за пределами ее ответственности.
Поэтому критически важными становятся централизованное логирование, мониторинг и фиксация всех взаимодействий между компонентами. Только на основании этих данных можно объективно установить источник сбоя.
Такого же подхода требуют и обновления. Даже незначительное обновление операционной системы или другого инфраструктурного компонента может повлиять на работу прикладных сервисов, поэтому любые изменения желательно предварительно проверять в тестовой среде. Правильное построение процесса управления обновлениями требует прямого участия заказчика.
Как меняется роль интегратора?
Сегодня роль системного интегратора значительно шире, чем простое внедрение отдельного продукта. Если раньше многие решения поставлялись в составе уже протестированных зарубежных экосистем, то теперь приходится самостоятельно формировать работоспособную инфраструктуру из компонентов разных производителей. Требуется проектирование архитектуры, оценка совместимости, комплексное тестирование, контроль и анализ корректной работы всей системы.
Смарт Текнолоджис сопровождает проекты от разработки архитектурных решений и инженерной проверки оборудования и ПО до комплексных испытаний с подготовкой к вводу в промышленную эксплуатацию.
Именно системный интегратор превращает набор разрозненных продуктов в единую и устойчиво работающую ИТ-инфраструктуру заказчика.
Нужны ли компаниям внутренние матрицы совместимости?
Да, нужны, особенно если речь идет о крупных организациях. Внутренние базы знаний позволяют фиксировать уже проверенные конфигурации, версии ПО, архитектурные решения, выявлять ограничения и способы устранения типовых проблем. Формирование баз знаний значительно упрощает дальнейшее развитие инфраструктуры и снижает вероятность повторения уже известных ошибок.
Такие базы ведут не только заказчики, но и интеграторы. Дополнительно в них фиксируются особенности настроек ИБ, поскольку ограничения сетевого взаимодействия нередко становятся причиной проблем совместимости.
По мере накопления подобных данных возрастает ценность применения инструментов на базе искусственного интеллекта. ИИ способен анализировать накопленный опыт, находить связи между похожими инцидентами и предлагать решения даже в тех случаях, когда инженер не может точно сформулировать запрос или не знает, какой именно прецедент использовать. При этом ИИ не заменяет эксперта, а помогает быстрее находить релевантные варианты применения решений, которые затем оценивает и подтверждает инженер.
Что делать с legacy-системами?
Единого рецепта здесь нет — все определяется конкретной инфраструктурой, отсутствием или наличием у заказчика исходного кода и документации, технической и финансовой возможности замены решения.
Полная замена устаревших систем зачастую требует слишком больших затрат времени и ресурсов, поэтому чаще применяется постепенная модернизация отдельных компонентов. Если прикладная и системная логика задокументированы, можно относительно безболезненно заменить отдельные элементы инфраструктуры, например базу данных или сервер приложений.
Однако рассчитывать на перенос «в один клик» не приходится. Практически любая миграция требует переработки архитектурных решений, проверки совместимости и повторного тестирования всей системы перед вводом в эксплуатацию.