Навыки multi-cloud-architecture
☁️

multi-cloud-architecture

Безопасно

Проектирование мульти-облачных архитектур для AWS, Azure и GCP

Также доступно от: wshobson

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

Поддерживает: Claude Codex Code(CC)
📊 71 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «multi-cloud-architecture». Сравнить варианты serverless-вычислений между облаками

Ожидаемый результат:

AWS Lambda: Функции, управляемые событиями, с 15-минутным таймаутом, обширные интеграции. Azure Functions: Тесная интеграция с экосистемой Microsoft, Durable Functions для stateful-рабочих процессов. GCP Cloud Functions: Простое ценообразование, нативная интеграция с BigQuery. Рекомендация: Используйте Lambda для сложных workflows событий, Azure Functions для стеков Microsoft, Cloud Functions для конвейеров данных.

Использование «multi-cloud-architecture». Спроектировать гео-распределённую архитектуру для глобальных пользователей

Ожидаемый результат:

Архитектура: Используйте GCP Cloud CDN для статических ресурсов, AWS CloudFront для динамического контента, Azure Front Door для API-шлюза. Разверните stateless-сервисы в GKE, AKS и EKS в ближайших регионах. Используйте Cloud Spanner или Cosmos DB для глобально распределённых данных. Маршрутизируйте трафик через DNS-based гео-маршрутизацию с проверками работоспособности и автоматическим переключением.

Аудит безопасности

Безопасно
v1 • 2/25/2026

All static analyzer findings are false positives. The SKILL.md file is pure documentation containing markdown tables, text descriptions, and architecture diagrams. No executable code or command injection vectors exist. External command references are documentation text pointing to other files, not actual shell execution.

1
Просканировано файлов
192
Проанализировано строк
0
находки
1
Всего аудитов
Проблем безопасности не найдено
Проверено: claude

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
31
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Корпоративная мульти-облачная стратегия

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

Планирование миграции в облако

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

Архитектура аварийного восстановления

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

Попробуйте эти промпты

Сравнение облачных сервисов для рабочей нагрузки
Мне нужно развернуть высокодоступное веб-приложение с автоматическим масштабированием. Сравните эквивалентные сервисы в AWS, Azure и GCP для вычислений, хранения, баз данных и сетей. Рекомендуйте лучший вариант для каждой категории на основе стоимости и функций.
Проектирование облачно-агностической архитектуры
Спроектируйте облачно-агностическую архитектуру для микросервисного приложения, которое может работать на любом облачном провайдере. Включите конкретные технологии для оркестрации вычислений, хранения данных, обмена сообщениями и мониторинга, которые работают одинаково в AWS, Azure и GCP.
План аварийного восстановления для мульти-облака
Создайте архитектуру аварийного восстановления с использованием AWS в качестве основного и Azure в качестве вторичного. Включите стратегию репликации базы данных, автоматизацию переключения, целевые показатели RTO/RPO и пошаговые процедуры восстановления.
План выполнения миграции в облако
Мы мигрируем с AWS на GCP в течение 6 месяцев. Создайте детальный план миграции, используя четырёхфазный подход. Включите критерии оценки рабочих нагрузок, выбор пилотного проекта, последовательность миграции, снижение рисков и метрики успеха для каждой фазы.

Лучшие практики

  • Используйте инфраструктуру как код (Terraform) для согласованного управления ресурсами во всех облачных провайдерах
  • Проектируйте с учётом отказов, предполагая, что любой отдельный регион облака или провайдер может стать недоступным
  • Реализуйте комплексный мониторинг с облачно-агностическими инструментами, такими как Prometheus и Grafana

Избегать

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

Часто задаваемые вопросы

Когда следует использовать мульти-облако вместо единого облака?
Используйте мульти-облако, когда вам нужно снижение рисков поставщика, соответствие нормативным требованиям в разных регионах, выбор лучших сервисов или улучшение переговорных позиций. Единое облако проще и часто достаточно для стартапов или приложений без строгих требований к доступности.
Какая самая большая проблема с архитектурами мульти-облака?
Операционная сложность является основной проблемой. Командам нужна экспертиза на нескольких платформах, мониторинг становится фрагментированным, а отладка проблем между облаками требует дополнительных инструментов и процессов.
Как избежать зависимости от поставщика при использовании облачных нативных сервисов?
Используйте слои абстракции, такие как Kubernetes для вычислений, совместимые с PostgreSQL базы данных, совместимые с S3 API хранения и инфраструктуру как код. Избегайте проприетарных сервисов, если их преимущества явно не перевешивают риски зависимости.
Какой рекомендуемый паттерн аварийного восстановления для мульти-облака?
Паттерн основной-вторичный: Запустите продакшен в одном облаке с асинхронной репликацией во вторичное облако. Используйте автоматические проверки работоспособности и процедуры переключения. Тестируйте переключение ежеквартально для обеспечения выполнения целей восстановления.
Какой экономии затрат можно ожидать от мульти-облака?
Прямая экономия затрат сильно варьируется, но обычно составляет от 10-30% благодаря конкурентному ценообразованию и оптимизации рабочих нагрузок. Большая ценность часто заключается в снижении рисков и переговорных позициях, а не в прямом сокращении затрат.
Следует ли начинать с мульти-облака или мигрировать позже?
С самого начала проектируйте облачно-агностическую архитектуру с использованием переносимых технологий, но изначально развертывайтесь в едином облаке. Добавляйте дополнительных провайдеров, когда бизнес-потребности оправдывают добавленную сложность и операционные накладные расходы.

Сведения для разработчиков

Автор

sickn33

Лицензия

MIT

Ссылка

main

Структура файлов

📄 SKILL.md