Частное облако: как не попасть пальцем в небо

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

О преимуществах облаков сказано уже очень много, поэтому неудивительно, что предприятия из различных отраслей в последнее время активно инвестируют в облачную инфраструктуру, а сам рынок облаков растет быстрыми темпами. По оценкам iKS-Consulting, объем российского облачного рынка в 2017 г. составил 54,6 млрд руб., показав рост на 28,4% к предыдущему году. В 2018 г. рынок достиг отметки 68,4 млрд рублей, или $1,1 млрд. Согласно базовому сценарию, объем российского рынка облачных услуг к 2022 г. увеличится более чем в два раза и превысит 155 млрд руб. Рынок будет расти минимум на 23% ежегодно.

Но, как показывает опыт, недостаточно просто принять решение о переходе на облачную инфраструктуру. Более того, даже осознанный выбор в пользу одного из вариантов облака — частного, публичного или гибридного — не является гарантией успеха проекта и его легкой реализации. Есть множество аспектов, которые надо учесть, причем многие — еще до начала проекта. Тот факт, что я работал с облаками на стороне как заказчика, так и системного интегратора, позволяет мне видеть подводные камни всего процесса, которые могут привести к разочарованиям и потере инвестиций. Я не буду пытаться объять необъятное, поэтому разберемся сначала с частным облаком и основными моментами, которые могут привести к краху надежд ИТ-руководства на спокойную и быструю миграцию в private cloud.

Мы делили апельсин, много наших полегло

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

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

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

Когда можно сложить все яйца в одну корзину

Почему я призываю отказаться от закупок инфраструктуры под каждую вводимую ИТ-систему? Закупка неизбежно подстраивается под одну бизнес-задачу и зачастую вынуждена ограничиваться рамками бюджета конкретного бизнес-подразделения. Когда одна ИТ-система требует больших объемов "медленных" дисков, а другой нужно любой ценой обеспечить производительность, приходится приобретать несколько разных СХД (иногда даже от разных вендоров), потому как универсальный и современный массив позволить себе может не каждый. Не говоря уже о том, что в крупных компаниях процесс закупки часто занимает слишком много времени, что сокращает time-to-market итогового решения.

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

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

А что будет, если нам все это не понадобится?

Логично, что в облачную инфраструктуру закладывать ресурсов нужно больше, чем требуется для текущих ИТ-нужд. В таких случаях руководство задает логичный вопрос: "А что будет, если нам все это не понадобится?". Конечно, можно следовать принципу: "если бизнес развивается, то облачные ресурсы будут использоваться". Но бизнес общается языком цифр, причем экспертно обоснованных. Так что наращивать мощности облака нужно, основываясь не на интуиции, а на аналитике — сначала текущей, а после начала использования облака — прогнозной. Если такой подход не будет обеспечен, то и все преимущества использования облака быстро сведутся на нет, когда закончатся его мощности.

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

In-House или Outsource

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

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

Проблемы cloud-native

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

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

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

Командная работа

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

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

Окно возможностей

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

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