Почему 85% компаний не смогут перенести инфраструктуру в облако самостоятельно07.07.2021 11:33

ИТ-инфраструктура для бизнеса стала слишком тяжелой ношей. Покупать и содержать — дорого, а переносить в облака — непросто. А если компания решилась на это, как избежать подводных камней? Например, понять, что хранение резервных копий нужно организовать иначе, потому что при рекомендованном провайдером дешевом тарифе будет невозможно ими воспользоваться (просто не позволят каналы связи). Или заранее увидеть, что производительность системы в защищенном контуре для размещения персональных данных окажется ниже. Как предвидеть подобные проблемы?  

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

Сложностей при этом может возникнуть много. И что дальше? Оставить мысль об облаке и сидеть на классической ИТ-инфраструктуре? Непопулярный выбор. По данным IDC, в 2020 г. впервые затраты на облачную инфраструктуру превысили инвестиции в собственную, традиционную. На последнюю компании потратили $61 млрд, тогда как на частные и публичные облака — $73,9 млрд. Годом ранее инвестиции в свою инфраструктуру были больше, чем затраты на облачную. IDC прогнозирует, что в 2024 г. объем облачного сегмента достигнет 63,6% от всего инфраструктурного рынка.

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

Сценарии разные, но для каждого из них верно одно — переезду в облака нужна серьезная подготовка. Поэтому в тренде не только облака, но и облачные консультанты. Спрос на услуги облачного консалтинга и внедрения достигнет своего пика в течение следующих пяти лет. Именно такой прогноз дает Gartner. По мнению аналитиков, к 2025 г. более 75% крупных организаций будут обращаться к внешним консультантам для разработки своей облачной стратегии. В 2019 г. к их помощи прибегали меньше половины — лишь 40%. Более 85% организаций будут привлекать внешних поставщиков услуг для переноса приложений, данных и хранилищ в облако. Gartner считает, что причина такого повышенного спроса на экспертное сопровождение — особенности подобных проектов, с которыми сложно управиться самостоятельно.

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

Тесты и еще раз тесты

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

«Например, в проекте для крупного ритейлера мы проанализировали инфраструктуру и выделили четыре типа систем. Самые требовательные к инфраструктуре и ее надежности должны размещаться только on-premise. Но были и приложения, которые могли быть легко переразвернуты и не предъявляли особых требований к надежности и доступности, поэтому их стоило перевести на IaaS-платформу, — рассказывает Вячеслав Медведев.— Систем первого типа в инфраструктуре заказчика всего 15%, а значит, можно смело переносить большую часть компонентов в облако. Когда все это разложили на виртуальные машины, то оказалось в облака могли переселиться больше половины виртуальных машин. Получилось сэкономить 50% бюджета на создание Active-Active кластера между двумя ЦОДами».

Потом появляется техническое задание и проект размещения систем в облаке. Последним этапом становится разработка плана-графика переноса с учетом взаимной зависимости систем.

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

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

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

Живем на два дома

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

Пример из сферы торговли: крупный ритейлер, у которого в связи с развитием бизнеса постоянно росла инфраструктура, докупал и докупал новое оборудование. Но потребности все равно опережали возможности по закупкам. На старом «железе» держали, в основном, множество тестовых сред. Их было решено отправить в облако, где появилась возможность более гибко работать в них, не поддерживая постоянно. Заодно ритейлер отказался и от устаревшего оборудования.

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

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

На первый взгляд предложения облачных провайдеров похожи, особенно в части IaaS-сервисов. Наиболее важные различия: каталог услуг, используемые гипервизоры и платформы виртуализации, возможности использовать программно-определяемую сеть и СХД. Такая информация обычно доступна. Однако есть нюансы, которые не бросаются в глаза.

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

Компании, конечно же, могут сами отфильтровать все предложения на рынке, составить для себя план работ, провести аудит, перевести сервисы в облачный вид. Но удобнее передать это внешним экспертам с нужным опытом и знаниями. Это не только сэкономит время, но и предостережет от ошибок, проведя по кратчайшей дороге.

Представитель крупного российского банка так обосновывает передачу проектирования облачной инфраструктуры во вне: «История со снижением стоимости off-site хранения резервных копий у нас тянулась очень долго. Для длительного хранения использовались дополнительные ленточные библиотеки, установленные за пределами основных дата-центров. По политикам жизненного цикла отдельные резервные копии после записи в основное хранилище дублировались на отдельную площадку и записывались на ленты. С учетом объемов поддержка такой инфраструктуры хранения оборачивалась огромными затратами. Тем более что сами библиотеки требовали постоянной модернизации, а ленточные накопители — замены. Когда мы, наконец, озаботились этой проблемой и пригласили экспертов извне, мы быстро смогли перейти к реализации. Нам предложили использовать облачное S3-хранилище. Итогом перевода туда резервных копий стало не только снижение стоимости хранения, но и трансформация затрат на копии — мы заменили бюджеты на закупку библиотек ежемесячными платежами. Наконец-то расходы подразделений банка на хранение данных стали прозрачными. Могли бы мы проделать это сами? Да, у нашей команды достаточно экспертизы. Но практика показывает, что она всегда востребована в более приоритетных задачах».

Полный текст статьи читайте на CNews