Частное облако — это способ получить легко управляемую ИТ-инфраструктуру, готовую быстро реагировать на потребности бизнеса. Построить «правильное» частное облако, заточить его под требования конечных пользователей и заложить перспективы для дальнейшего развития ИТ и всей компании — задача не из легких. Обсудим неочевидные нюансы, которые важно понимать на старте проекта.
Бум цифровизации бизнеса и широкие возможности, которые предоставляют современные технологии виртуализации ресурсов, спровоцировали массовый переход в облака. По оценке Gartner, в 2020 году мировой рынок IaaS вырос на 16%, а за 2021 год он увеличится на 27%.
Облачный рынок в России, по нашей оценке, вырос на 40% в 2020 году. Для организации удаленной работы и запуска онлайн-сервисов компаниям потребовались вычислительные ресурсы. Быстрее и проще получить их в облаке. Кроме инфраструктуры, вырос спрос на платформенные сервисы — инструменты, позволяющие ускорить разработку и выкатку цифровых продуктов. Так, по данным «ТМТ Консалтинг», сегмент PaaS в прошлом году вырос на 34%.
Некоторые компании только знакомятся с облачными технологиями, поэтому предпочитают использовать мощности в своем периметре. Иногда ограничения накладывают внутренние политики безопасности. Тогда альтернативой публичному облаку может стать создание частного облака. По нашему опыту, его выбирают 30% крупных заказчиков.
Частное облако не дает практически неограниченной масштабируемости, как публичное. Поэтому возникает вопрос: чем оно отличается от собственной ИТ-инфраструктуры? Оно позволяет автоматизировать и ускорять выделение ресурсов внутри компании, контролировать их использование подразделениями. Создается «внутренний провайдер» ИТ, работающий по принципам публичного облака для своих сотрудников, подрядчиков, партнеров. В частном облаке, в отличие от традиционной инфраструктуры, доступны PaaS-сервисы, которые позволяют отделам быстро получать не просто вычислительные ресурсы и объемы хранения, но готовые к эксплуатации платформы. Это тоже важно для ускорения разработки и вывода новых ИТ-продуктов на рынок.
Частное облако обладает всей функциональностью публичного, но расположено внутри периметра корпоративной сети. Доступ к данным и самой инфраструктуре полностью под контролем самой компании. Это позволяет выполнять самые строгие требования регуляторов и корпоративной безопасности, даже если облако построено на базе не только собственных, но и арендованных дата-центров.
При построении частного облака есть неочевидные нюансы, которые влияют на то, как быстро и успешно будет реализован этот проект и какую пользу принесет он компании в будущем. Расскажу о том, как выглядит этот процесс, из каких этапов он состоит, какие риски могут возникнуть по дороге и какие ошибки чаще всего совершают заказчики.
Анализ потребностей
Принятию решения о внедрении частного облака и переводе на него ИТ-инфраструктуры должен предшествовать серьезный аналитический этап. Необходимо как можно полнее понять суть протекающих в компании бизнес-процессов, выявить все их взаимосвязи между собой и с внешним миром. Сделать это надо именно на языке бизнеса и только затем каждый из элементов получившейся схемы переводить на уровень технических задач.
Часто разные департаменты внутри компании видят одни и те же бизнес-процессы весьма по-разному. Это усложняет как сбор данных, так и их анализ. Решением могло бы стать создание рабочей группы, в которую войдут представители всех затронутых цифровизацией отделов.
Задача развертывания облака с нуля включает в себя множество переменных величин. Будет ли это среда виртуализации ресурсов, система машинного обучения или кластер баз данных — в каждом из этих случаев не обойтись без этапа предварительного анализа. Он нужен для того, чтобы определить реальный потенциал частного облака и составить ТЗ с учетом особенностей ИТ-ландшафта и потребностей компании. На этапе анализа может прийти понимание, что частное облако — это вообще не то решение, которое нужно сейчас.
Правильный и подробный анализ поможет четко понять потребности бизнеса и составить грамотное техническое задание для решения конкретных задач.
Этапы внедрения
В большинстве случаев развертывание частного облака своими силами затруднено из-за отсутствия соответствующих специалистов. Растить их долго, а привлекать на постоянную работу дорого. Кроме того, сложно оценить компетенции соискателя в новой для компании области. В России компании редко строят частные облака своими силами, в основном привлекают подрядчика.
При выборе конкретного решения стоит учесть несколько нюансов. Во-первых, регуляторные, политические и экономические риски. Например, решение от иностранного вендора не подходит для компаний, нацеленных на импортозамещение. Проприетарное ПО ставит в зависимость от поставщика и его политики: вендор может закрыться или уйти из страны, прекратить поддержку продукта. Во-вторых, стоит учитывать возможности кастомизации решения. Более гибким будет облако на основе ПО с открытым исходным кодом. Ключевая проблема Open Source в том, что сложно найти местную компанию, которая гарантированно поддерживает решение — исправляет баги, расширяет функциональность, устраняет неполадки на стороне заказчика.
На следующем этапе разрабатывается дорожная карта частного облака. Даже внедренное решение не является статичным. Перед бизнесом встают новые задачи, растут нагрузки, появляются новые технологии. Это нужно предусмотреть и выбрать правильный вектор развития еще на стадии проектирования.
Далее выбирается один из двух вариантов поставки: стандартное решение с готовым набором функций или кастомизация продукта под конкретные требования. Первый вариант хорош тем, что такое внедрение можно осуществить в очень сжатые сроки. Кастомизация — более сложный и комплексный процесс, состоящий из большого количества подэтапов. Они могут включать в себя заказную разработку недостающих инструментов или средств интеграции, что требует времени и подразумевает постановку отдельного ТЗ.
После подписания договора начинается этап внедрения. Обычно это пилотная инсталляция на стороне клиента, чтобы он мог оценить ее возможности и провести приемо-сдаточные испытания. Конкретный набор сервисов IaaS или PaaS разворачивается в зависимости от потребностей. По нашему опыту, развертывание пилота IaaS в среднем занимает полтора-два месяца, если выбрано стандартное решение.
После испытаний платформа переходит в режим эксплуатации. На этой стадии облачный провайдер обеспечивает экспертную поддержку: техобслуживание, обучение специалистов заказчика, консультации, инструктаж по эксплуатации платформы и разбор типичных кейсов по устранению неполадок.
Типичные ошибки и риски
Путь от идеи до запуска частного облака в эксплуатацию извилист. Есть риски выбрать неоптимальный сценарий реализации проекта или просто не справиться с поставленной задачей. Вот несколько моментов, на которые стоит обратить особое внимание:
Компетенции. На момент принятия решения о создании частного облака у многих компаний отсутствует достаточная внутренняя экспертиза. Необходимо либо вырастить ее внутри компании, либо опереться на экспертизу поставщика. В последнем случае надо внимательно изучить предложение и понять, предоставляет ли поставщик техническую поддержку в должном объеме и имеет ли образовательные программы, чтобы в сжатые сроки передать важные навыки на сторону заказчика.
Платформа. Здесь выбор стоит между закрытой платформой от конкретного вендора и решением на базе ПО с открытым исходным кодом. Недостатком первого варианта является зависимость от поставщика с риском остаться у разбитого корыта. Второй вариант требует более серьезных компетенций.
Кастомизации и интеграции. Есть риск превратить коробочное решение в совершенно другой продукт при неправильном подходе к кастомизации. Например, так происходит, если кастомизировать ядро платформы. В итоге такое решение гораздо сложнее поддерживать и обновлять, чем коробочное ПО.
Неучтенные факторы. Сфокусировавшись на технической стороне вопроса, можно забыть о важных требованиях к решению, которые лежат несколько в стороне от генеральной линии — непосредственного использования вычислительных мощностей. Будете ли вы использовать блокчейн, машинное обучение, обработку больших данных — все это должно быть учтено на стадии проектирования, а не задним числом. Если после начала эксплуатации выяснится, что ваше облако не отвечает каким-то специфическим требованиям конкретных задач, есть риск, что исправить это без полной переделки инфраструктуры окажется проблематично.
Инерция развития. Однажды построенное облако развивается итерационно, путем относительно небольших дополнений и изменений на каждом этапе. Содержащаяся в нем бизнес-логика зашита на уровне глубинной инфраструктуры. Мгновенно сменить курс на 180 градусов и перейти к решению других задач путем точечного воздействия на систему не получится. Часто в таких случаях может потребоваться недешевая заказная разработка или даже переход на другое облако.
Гибкость команды. Частное облако предоставляет широкие возможности по использованию микросервисных архитектур, виртуальных машин, распределенных баз данных и т. д. Но для того чтобы извлекать из этих технологий максимум, нужна команда администраторов, открытых для всего нового и готовых пользоваться этими инструментами для создания новых ценностей. Вендор ПО для построения облака предоставит платформу, но развивать ее, внедрять новую бизнес-логику, искать пути оптимизации заказчику предстоит самостоятельно.
***
Создание собственного приватного облака — сложная задача, требующая специфических компетенций. Но запустить облако мало: придется его развивать и трансформировать под возникающие задачи. Для того чтобы частное облако стало базой для успешной цифровой трансформации, а не обузой, важно понимать нюансы его построения и на старте проекта заложить вектор для его развития.
