Руководство по именованию ресурсов и присвоению тегов

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

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

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

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

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

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

  • Автоматизации: Правильная организационная схема позволяет воспользоваться преимуществами автоматизации при создании ресурсов, мониторинге операций и создании процессов DevOps. Автоматизация также упрощает управление ресурсами для ИТ-отдела.

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

Рекомендации по принятию решений о тегах

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

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

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

Описание
Основные рекомендации по проектированию Базовые требования к операциям, дополненные дополнительными бизнес-требованиями.
Базовое соглашение об именовании Для развертывания требуется именование ресурсов. Стандартизованная схема именования — это минимальный тег.
Функциональные Теги, описывающие функцию виртуальной машины для легкой идентификации.
Пример: рабочая нагрузка; функция в рабочей нагрузке (приложение, данные и т. д.); среды (например, разработка, промежуточное хранение, рабочая среда).
Классификация Теги, которые классифицируют значение ресурса, могут помочь в принятии решений.
Пример: классификация данных (общедоступных, частных, конфиденциальных и т. д.); Критичность; SLA.
Учет Теги, помогающие отслеживать затраты, связанные с операциями с активами.
Пример: отдел, проект, регион и т. д.
Назначение Теги, которые сопоставляют актив с бизнес-функцией, могут быть полезны при принятии инвестиционных решений.
Пример: бизнес-процесс, критичность бизнеса, влияние на доход.

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

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

Базовое соглашение об именовании

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

Примечание

Правила и ограничения именования зависят от ресурса Azure. Соглашения об именовании должны соответствовать этим правилам.

Шаблоны присвоения тегов ресурсам

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

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

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

  • Нужно ли интегрировать политику именования и присвоения тегов с существующими в компании политиками?

  • Будет ли использоваться система учета с возвратными платежами или виртуальными счетами? Нужно ли связывать ресурсы с учетными данными для отделов, бизнес-групп и команд более подробно, чем предоставляет простая разбивка на уровне подписки?

  • Должны ли теги представлять сведения о ресурсе, например нормативные требования к соответствию? А нужны ли эксплуатационные данные, например требования к времени работы, расписание исправлений или требования к безопасности?

  • Какие теги требуются для всех ресурсов на основе централизованной ПОЛИТИКИ ИТ? Какие теги являются необязательными? Смогут ли отдельные команды применять собственные схемы присвоения тегов?

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

Тип тега Примеры Описание
Функциональные app = catalogsearch1
tier = web
webserver = apache
env = prod
env = staging
env = dev
Классифицирует ресурсы по их целям в рабочей нагрузке, среде, в которой они были развернуты, или по другим функциональным возможностям и сведениям о работе.
Классификация confidentiality = private
SLA = 24hours
Классифицирует ресурс по способу его использования и применяемым к нему политикам.
Учет department = finance
program = business-initiative
region = northamerica
Связывает ресурс с определенными группами в организации для выставления счетов.
Назначение businessprocess = support
businessimpact = moderate
revenueimpact = high
Сопоставляет ресурсы с бизнес-функциями для поддержки решений об инвестициях.

Дополнительные сведения

Дополнительные сведения о присвоении имен и тегов в Azure см. в следующих статьях:

Дальнейшие действия

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