Resource as a Strategy: как управлять облачными ресурсами на уровне бизнеса, безопасности и инфраструктуры

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

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

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

В статье разберем, какие задачи входят в управление ресурсами в корпоративном облаке и какими инструментами они закрываются в Cloud X: от квотирования, лимитов и ресурсных политик до тегирования, аудита изменений, визуализации зависимостей и Infrastructure as Code.

Привет, Хабр! Меня зовут Владимир Швец, я ведущий архитектор Cloud X. Уже несколько лет мы активно работаем над развитием облачной экосистемы Cloud X. Сегодня в портфеле платформы более 20 сервисов, которые помогают управлять ресурсами, контролировать потребление, автоматизировать развертывание и обеспечивать соответствие инфраструктуры требованиям бизнеса и регуляторов.

Что на самом деле нужно бизнесу от управления облачными ресурсами

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

Потребности бизнеса можно сгруппировать в несколько направлений.

Финансовый контроль

Бизнес хочет платить ровно за те ресурсы, которые потребляет. Модель pay-as-you-go хорошо работает только тогда, когда есть механизмы контроля: квоты, лимиты, теги, связь ресурсов с расчетными счетами и возможность анализировать потребление в разрезе команд, проектов и сред.

Без такого контроля облако может превратиться в источник непредсказуемых расходов.

Скорость вывода продуктов на рынок

Для многих компаний важен time-to-market. Команды должны быстро получать инфраструктуру для прототипов, тестовых сред и production-сервисов. Если компания не оказывает ИТ-услуги напрямую, эта же задача формулируется иначе: быстрее поставлять ценность внутренним пользователям и бизнес-подразделениям.

Облако должно помогать запускать инфраструктуру быстрее, но без потери контроля.

Масштабируемость

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

Отказоустойчивость и защита от ошибок

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

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

Безопасность и комплаенс

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

Но в инфраструктурном управлении эти задачи проявляются конкретно:

• защита от ошибок пользователей и администраторов;

• поддержание консистентной конфигурации распределенной и геораспределенной инфраструктуры;

• соответствие требованиям ГОСТ, ФСТЭК и другим регуляторным нормам;

• подотчетность и возможность показать историю действий;

• гранулярное управление в соответствии со сложной корпоративной иерархией.

Какие требования предъявляют к управлению инфраструктурой

Если перевести бизнес-потребности на язык облачной платформы, получится набор конкретных требований к управлению ресурсами.

Облачный провайдер должен предоставлять инструменты для:

• квотирования ресурсов;

• управления лимитами;

• проверки соответствия ресурсным политикам;

• контроля требований безопасности;

• контроля регуляторных требований;

• сегментации ресурсов в соответствии с оргструктурой;

• привязки ресурсов к разным расчетным счетам;

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

• защиты критичных ресурсов от изменения или удаления;

• миграции ресурсов между логическими и физическими контурами;

• тегирования;

• визуализации ресурсов и зависимостей;

• аудита изменений;

• управления инфраструктурой как кодом;

• ограничения доступа к управляющим операциям через частные ссылки;

• управления троттлингом запросов;

• планирования отложенных и регулярных заданий.

В Cloud X эти требования закрываются набором сервисов, которые образуют единый контур управления ресурсами.

Финансовый и ресурсный контроль

Сервис квотирования

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

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

В портфеле Cloud X для этой задачи предусмотрен сервис квот. Он работает на уровне облака и региона и позволяет выставлять квоты на регион и расчетный счет.

Практический эффект простой: команда не сможет случайно потребить больше ресурсов, чем предусмотрено ее бюджетом или архитектурной моделью.

Сервис лимитов

Если квоты отвечают на вопрос «сколько ресурсов в сумме можно выделить», то лимиты отвечают на вопрос «какие параметры может иметь конкретный ресурс».

Сервис лимитов устанавливает ограничения для атрибутов ресурсов. Например, лимит может определять допустимый диапазон параметров сервиса, максимальное значение конкретной характеристики или предельные значения, которые нельзя превысить при создании или изменении ресурса.

Лимиты бывают мягкими и жесткими.

Мягкие лимиты могут быть изменены администратором платформы Cloud X. Как правило, изменение выполняется через заявку в поддержку и последующее согласование.

Жесткие лимиты не регулируются администратором. Для них все параметры всегда совпадают.

Параметры лимита:

• значение лимита по умолчанию;

• установленное значение лимита;

• предельное значение лимита:

  • верхнее;

  • нижнее.

Квоты и лимиты решают разные задачи. Квоты ограничивают объемы ресурсов, которые может выделить клиент определенного типа. Лимиты ограничивают параметры конкретного ресурса.

Например, квота может ограничивать общий объем vCPU в облакое и регионе, а лимит —допустимый диапазон значений его параметра.

Governance, политики и соответствие требованиям

Сервис ресурсных политик

Сервис ресурсных политик помогает обеспечивать соблюдение организационных стандартов и проверять ресурсы на соответствие заданным требованиям.

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

Сервис помогает приводить ресурсы в соответствие с установленными правилами и автоматически исправлять несоответствия для новых ресурсов.

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

Сервис контроля требований по безопасности

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

Механизмы контроля позволяют сравнивать существующие конфигурации облачных ресурсов с установленными требованиями.

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

Сервис контроля исполнения регуляторных требований

Сервис контроля исполнения регуляторных требований — это сертифицированная и аттестованный сервис облака для аудита и контроля исполнения регуляторных требований по безопасности.

Она позволяет автоматически проверять созданную облачную инфраструктуру, помогать приводить ее в соответствие с требованиями и формировать доказательную базу для регулятора.

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

Организационная модель ресурсов

Сервис управления группами управления

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

В Cloud X можно создавать до 10 тысяч групп управления. Они могут быть выстроены в иерархическую модель с высотой дерева до 8 узлов.

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

Сервис управления облаками

Сервис управления облаками позволяет ассоциировать ресурсы с разными расчетными счетами.

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

На практике это упрощает chargeback и showback-сценарии: можно видеть, какие команды и направления потребляют ресурсы и какие расходы с этим связаны.

Сервис управления группами ресурсов

Сервис управления группами ресурсов позволяет группировать ресурсы по жизненному циклу, региональной принадлежности и логике конкретного приложения или проекта.

Группы ресурсов помогают отделять dev, test, stage и production-среды, объединять ресурсы одного сервиса и управлять ими как единым логическим набором.

Это снижает операционную сложность: администратору или архитектору проще понимать, какие ресурсы относятся к конкретной системе, среде или этапу жизненного цикла.

Защита критичных ресурсов и миграция

Защита от изменений или удаления

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

В системе предусмотрены два типа блокировок:

• блокировка на удаление;

• блокировка на любые управляющие воздействия, то есть перевод объекта в режим только чтение.

Этот механизм особенно важен для production-инфраструктуры, критичных сетевых компонентов, баз данных, хранилищ и других ресурсов, ошибка при изменении которых может привести к простою.

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

Миграция ресурсов

Сервис для миграции ресурсов позволяет перемещать ресурсы:

• в другую группу управления;

• в другое облако;

• в другую группу ресурсов;

• между регионами.

Таким образом, сервис поддерживает как логическое, так и физическое перемещение ресурсов.

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

Тегирование и управление затратами

Тегирование ресурсов

Сервис тегов позволяет гибко управлять ресурсами, операциями, затратами, политиками безопасности и процессами оптимизации.

В Cloud X используется классический подход: у каждого тега есть наименование и значение.

Теги помогают описывать ресурсы через дополнительные признаки:

• владелец;

• проект;

• среда;

• cost center;

• SLA;

• критичность;

• жизненный цикл;

• региональная принадлежность;

• назначение ресурса.

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

Например, с помощью тегов можно:

• рассчитывать потребление по ресурсам, относящимся к конкретному проекту;

• применять ресурсные политики;

• автоматически проставлять теги на новые ресурсы согласно политикам;

• находить ресурсы без владельца;

• оптимизировать полезную нагрузку;

• разделять расходы по командам и бизнес-направлениям.

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

Визуализация ресурсов, зависимостей и аудит изменений

Визуализация ресурсов

Для визуализации ресурсов в Cloud X предусмотрен инструмент витрины данных.

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

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

Визуализация зависимостей

Для визуализации зависимостей используется граф ресурсов.

Сервис отображения графа ресурсов показывает физические зависимости между ресурсами, логические включения одних ресурсов в другие и связи, которые важно учитывать перед изменением инфраструктуры.

Граф ресурсов позволяет увидеть:

• какие ресурсы связаны между собой;

• какие объекты входят в состав других объектов;

• какие ресурсы зависят от конкретного компонента;

• какие изменения могут затронуть соседние элементы инфраструктуры;

• где нельзя выполнять управляющее воздействие на один ресурс без учета другого.

Это дает пользователям два уровня видимости.

Первый — общее отображение имеющихся ресурсов.

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

Аудит изменений

Сервис учета действий над ресурсами показывает полную историю изменений спецификации ресурсов.

Сервис позволяет увидеть, что именно изменилось, кто был инициатором изменения и когда оно произошло.

При выборе конкретной записи можно сравнить предыдущее и текущее состояние ресурса. Это полезно для расследования инцидентов, анализа ошибочных изменений, контроля действий администраторов и восстановления причинно-следственной связи после сбоев.

Для production-среды история изменений — один из ключевых элементов операционной надежности. Она помогает отвечать на вопрос не только «что сломалось», но и «что изменилось перед тем, как это произошло».

Инфраструктура как Код

В Cloud X реализована поддержка Terraform, так как этот канал доступа давно используется многими представителями бизнеса и инженерных команд.

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

Помимо поддержки Terraform, в Cloud X реализован собственный синтаксис — CX Formation 2.0.

CX Formation 2.0 — внутренний сервис, который получает шаблон конфигурации развертывания с определенными параметрами и на выходе формирует готовый стек. Стеком в Cloud X называется инфраструктура, развернутая из такого шаблона.

Infrastructure As Code-подход важен не только для скорости. Он обеспечивает воспроизводимость, проверяемость и управляемость инфраструктуры. Если окружение описано кодом, его проще проверить, согласовать, повторить в другом регионе или восстановить после сбоя.

Другие важные возможности

Помимо основных сервисов управления ресурсами, в Cloud X есть ряд дополнительных инструментов, которые закрывают важные эксплуатационные сценарии.

Частные ссылки

Сервис частных ссылок помогает ограничить доступ к управлению ресурсами через частный endpoint.

Это важно для компаний, которым нужен персональный контроль доступа к выполнению операций над ресурсами и снижение зависимости от публичных сетевых контуров.

Контроль тротлинга

Сервис контроля тротлинга предназначен для управления параметрами троттлинга REST-запросов клиентов или систем.

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

Бета-тестирование

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

Реестр типов ресурсов

Сервис управления ресурсными провайдерами и типами.

Он отображает общий список доступных ресурсных типов и позволяет включать ресурсный провайдер на облако.

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

Планирование заданий

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

Реестр локаций

Сервис учета локаций предназначен для учета оборудования пользователя.

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

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

Пример: как может выглядеть управляемая модель ресурсов в крупной компании

Рассмотрим типовой сценарий.

У компании есть несколько бизнес-направлений, несколько продуктовых команд, dev/test/prod-среды и отдельные расчетные счета для разных подразделений.

В такой модели можно выстроить управление ресурсами следующим образом:

• Имеются лимиты по умолчанию, которые содержатся в сервисе лимитов;

• На верхнем уровне создаются группы управления под бизнес-направления через сервис управления группами управления;

• С группами управления ассоциируются облака через сервис управления облаками;

• Каждое облако в каждом регионе имеет квоты по умолчанию, учёт которых ведётся в сервисе квот;

• Внутри облаков создаются группы ресурсов под продукты, среды и регионы через сервис управления группами ресурсов;

• Через сервис политик создаётся политика об обязательных тегах на всех ресурсах каждой конкретной группы ресурсов;

• Благодаря политике сами теги устанавливаются при развёртывании ресурсов в сервисе тегов;

• Production-ресурсы защищаются от удаления через сервис управляемых блокировок.

• Каждое управляющее воздействие проверяется через сервис контроля требований по безопасности и сервис контроля исполнения регуляторных требований;

• Зависимости между ресурсами анализируются через сервис графа ресурсов;

• Изменения расследуются через сервис истории изменений ресурсов;

• Новые окружения разворачиваются через Terraform или CX Formation 2.0.

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

Чек-лист для оценки зрелости управления ресурсами

При выборе облачного провайдера или аудите собственной облачной модели полезно проверить, есть ли в платформе следующие возможности:

• есть ли возможность ограничивать потребление через квоты;

• есть ли лимиты на параметры ресурсов;

• можно ли строить иерархию управления в соответствии с оргструктурой;

• поддерживается ли группировка ресурсов по проектам, средам и регионам;

• можно ли привязывать ресурсы к разным расчетным счетам;

• можно ли тегировать ресурсы;

• есть ли обязательный контроль соответствия политикам ресурсов;

• можно ли проверять ресурсы на соответствие требованиям безопасности;

• есть ли механизмы контроля регуляторных требований;

• можно ли защитить production-ресурсы от удаления или изменения;

• поддерживается ли миграция ресурсов между логическими и физическими контурами;

• есть ли визуализация ресурсов и зависимостей;

• ведется ли история изменений;

• поддерживается ли Infrastructure as Code;

• можно ли ограничивать доступ к управляющим операциям через частные endpoint;

• есть ли управление троттлингом запросов;

• можно ли автоматизировать регулярные и отложенные задания.

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

Заключение

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

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

В Cloud X этот подход реализуется через набор сервисов управления ресурсами: квоты, лимиты, политики, группы управления, облака, ресурсные группы, теги, блокировки, миграцию, визуализацию, аудит изменений и Infrastructure as Code.

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