Планируйте облачно-нативные решения

2025-08-01

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

Предварительные требования: посадочная зона Azure

Определение бизнес-целей для облачных решений

Начните с четких бизнес-целей. Определите конкретные результаты, которые должны достичь вашего облачного решения, например включение нового цифрового продукта, ввод нового рынка, улучшение взаимодействия с клиентами или снижение операционных затрат. Используйте измеримые показатели, такие как рост доходов компании, сокращение времени выхода на рынок или объем запросов в службу поддержки, чтобы оценить успех. Для новых функций определите такие цели, как улучшение взаимодействия с клиентами, снижение операционных затрат или увеличение масштабируемости системы.
Определите ограничения и критерии успешности. Задокументируйте все бизнес-ограничения, такие как бюджет, соответствие или временная шкала доставки. Определите, как выглядит успех для каждой цели. Например, "запуск нового клиентского портала к четвертому кварталу" или "уменьшение времени задержки при оформлении заказа на 40%". Эти критерии помогают установить приоритеты и оценить компромиссы в процессе планирования.
Проверка согласования заинтересованных лиц. Убедитесь, что все заинтересованные лица (бизнес и технические) договорились о целях, ограничениях и о том, каким должен быть успешный результат. Это согласование может включать семинары или официальное одобрение. Раннее выравнивание предотвращает последующее недопонимание и избегается дорогостоящая переработка, гарантируя, что все разделяют одинаковые ожидания с самого начала.

Определение требований к облачным решениям

Функциональные требования документа. Задокументируйте возможности и функции системы, необходимые для удовлетворения потребностей пользователей. Каждое требование должно быть привязано к бизнес-цели, гарантируя, что усилия по разработке напрямую поддерживают нужные результаты. Используйте интервью заинтересованных лиц и документы по бизнес-стратегии, чтобы определить высокоценные результаты. Приоритизация функций на основе бизнес-ценности и технической осуществимости. Для того чтобы обосновать включение, трассируйте каждое требование к измеримой бизнес-цели.
Установите нефункциональные требования. Нефункциональные требования определяют технические требования для удовлетворения функциональных требований и управления. Установите атрибуты качества и технические целевые показатели, необходимые для поддержки этих функций. Определите целевые метрики надежности , такие как цели уровня обслуживания (SLOS) для времени простоя, целей точки восстановления (RPOs) и целевых показателей времени восстановления (ОСРВ). Создайте базовые показатели безопасности. Создание модели затрат. Задайте целевые показатели производительности.
Управление областью облачных нативных решений. Четко определите, что входит в рамки и что выходит за рамки первоначального релиза. Соблазнительно добавить больше функций "приятно иметь", но увеличение объема работы может поставить под угрозу сроки и бюджеты. Задокументируйте границы решения и реализуйте процесс управления изменениями для любых новых запросов. Утвердить только изменения, которые напрямую поддерживают определенные цели и которые могут быть доставлены без подрыва расписания или бюджета. Отложить идеи с более низким приоритетом в будущий список задач. Строгое управление областью позволяет команде сосредоточиться на предоставлении наиболее ценных функциональных возможностей в пределах ограничений.

Планирование облачно-нативных архитектур

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

Изучение проверенных облачных архитектур

Ознакомьтесь с основами архитектуры и рекомендациями. Прежде чем придумать архитектуру с нуля, ознакомьтесь с проверенными эталонными архитектурами и основами из Центра архитектуры Azure. Знакомые стили архитектуры включают изучение проверенных эталонных архитектур для распространенных рабочих нагрузок. Эти архитектуры помогают ускорить принятие решений по проектированию и снизить риск.
Выберите соответствующий стиль архитектуры. Выберите стиль архитектуры на основе характеристик рабочей нагрузки и возможностей команды. Стили архитектуры включают N-уровень (монолитный), микрослужбы, управляемые событиями (на основе сообщений), веб-queue-worker. Например, если требуется быстрая разработка относительно простого приложения, может быть достаточно хорошо структурированного монолита уровня N. Для масштабируемого или быстро развивающегося приложения с различными доменами, микрослужбами или подходами на основе событий обеспечивают гибкость (за счет сложности). На практике многие системы оказываются в конечном итоге с гибридным стилем. Например, есть ядро микрослужб с некоторыми общими службами или подсистемой на основе событий. Ключ заключается в понимании компромиссов каждого стиля и выбор подхода, который лучше всего соответствует вашим требованиям масштабируемости, устойчивости и гибкости.
следовать рекомендациям по оформлению; Независимо от того, какой стиль вы выбираете, придерживайтесь принципов облачной архитектуры и рекомендаций. Центр архитектуры Azure предоставляет каталог шаблонов облачной разработки (повторные попытки, разбиение цепи, CQRS), которые устраняют распространенные проблемы в распределенных рабочих нагрузках. Интеграция этих шаблонов в проект может повысить надежность и производительность.
Интеграция пяти основных компонентов в решения по проектированию. Используйте платформуWell-Architected Framework для принятия решений по обеспечению надежности, безопасности, эффективности производительности, оптимизации затрат и эффективности работы. Эти пять основных принципов должны информировать все решения по проектированию. Например, при выборе базы данных рассмотрите надежность (избыточность, резервное копирование), производительность и затраты вместе, чтобы обеспечить правильный баланс. Документ, в котором вы делаете компромиссы между основополагающими элементами, например, больше затрат на более высокую производительность. Эти заметки ценны для будущего управления и проверки.

Планирование интеграции с существующими системами

Инвентаризация всех зависимых систем и служб. Новые облачные нативные решения редко работают в изоляции, если только вы не являетесь молодым стартапом. Рассмотрим, как новая рабочая нагрузка или функция вписываются в среду. Сопоставление потоков данных и обеспечение совместимости с стандартами. Создайте полный список всех систем, с которыми взаимодействует рабочая нагрузка. Этот список включает внутренние API, базы данных, поставщики удостоверений (Идентификатор Microsoft Entra), средства мониторинга, конвейеры CI/CD и локальные системы, доступ к ним через VPN или ExpressRoute. Используйте схемы архитектуры и карты зависимостей для визуализации этих связей.
Классифицируйте типы и протоколы интеграции. Классифицируйте каждую точку интеграции по типам (проверка подлинности, обмен данными, обмен сообщениями) и протоколу (REST, gRPC, ODBC, SAML, OAuth2). Эта классификация помогает определить требования совместимости и потенциальные узкие места.
Проверка идентификации и интеграции доступа. Убедитесь, что ваше решение интегрируется с поставщиком удостоверений организации. Например, используйте идентификатор Microsoft Entra для проверки подлинности и авторизации вместо внедрения новой системы удостоверений. Подтвердите, что поддерживаются единый вход (SSO), управление доступом на основе ролей (RBAC) и политики условного доступа.
Оценка сетевого подключения и безопасности. Узнайте, как рабочая нагрузка подключается к другим системам. Проверьте правила брандмауэра, разрешение DNS и пути маршрутизации. Для гибридных сценариев убедитесь, что конфигурации ExpressRoute или VPN настроены и протестированы. Используйте наблюдатель за сетями Azure для мониторинга и устранения неполадок с подключением.
Обеспечение совместимости потока данных и соответствия требованиям. Сопоставление потоков данных между системами. Подтвердите форматы данных, схемы и требования к преобразованию. Обеспечение соответствия политикам расположения данных, шифрования и хранения.
Тестируйте точки интеграции рано и непрерывно. Выполняйте тестирование интеграции на ранних этапах разработки. Используйте объекты-заглушки или простые имитации для недоступных систем. Автоматизируйте эти тесты в конвейере CI/CD с помощью таких средств, как Azure DevOps или GitHub Actions. Отслеживайте задержку, пропускную способность и частоту ошибок. Например, вы хотите избежать ситуации, когда API, от которого зависит ваше приложение, не поддерживает требуемую нагрузку, или сетевой брандмауэр блокирует вашу службу.
Документируйте контракты интеграции и соглашения об уровне обслуживания. Определите и задокументируйте ожидаемое поведение, доступность и производительность каждой точки интеграции. Включите логику повторных попыток, параметры времени ожидания и резервные механизмы. Согласуйте соглашения об уровне обслуживания (SLA) с зависимыми системами.

Выбор соответствующих служб Azure и уровней служб

Используйте руководства по принятию решений, чтобы выбрать службы, соответствующие требованиям рабочей нагрузки. Azure предоставляет несколько вариантов для запуска кода приложения, каждый из которых содержит плюсы и минусы. Просмотрите общие сведения о вариантах технологий , чтобы определить службы, которые соответствуют вашим функциональным и нефункциональным требованиям. Приоритет вариантов платформы как услуги (PaaS), так как эти службы сокращают операционные издержки путём автоматизации управления инфраструктурой, исправлений и масштабирования.
Определите шаблоны использования и требования к производительности для выбора уровней служб. Выбор уровня служб влияет как на затраты, так и на возможности. Документирует ожидаемые объемы транзакций, одновременные нагрузки пользователей, требования к хранилищу и целевые показатели производительности, такие как время отклика и пропускная способность. Используйте эти метрики для выбора уровня сервисов (SKU), соответствующего базовым требованиям, без значительного чрезмерного резервирования. Планируйте настройку уровней на основе фактических шаблонов использования после развертывания.
Проверка совместимости компонентов между выбранными уровнями служб. Критически важные функции, такие как расширенные возможности безопасности, параметры высокой доступности или API интеграции зависят от уровня служб. Создайте матрицу признаков, которая сопоставляет необходимые возможности с доступными номерами SKU. Убедитесь, что выбранный уровень поддерживает все необходимые функции, чтобы избежать дорогостоящих миграций или изменений архитектуры позже. Справочная документация для конкретной службы для подтверждения доступности и ограничений функций.

Выбор количества используемых регионов

Оцените компромиссы много-региональных развертываний. Архитектура с одним регионом проще и дешевле, но региональный сбой приведет к сбою приложения. Развертывания с несколькими регионами могут обеспечить более высокую доступность (один регион может выйти из строя, и пользователи получают доступ из другого) а также могут повысить производительность, предоставляя доступ пользователям, расположенным в ближайшем регионе. Компромисс увеличивает сложность при развертывании и синхронизации данных. Необходимо обрабатывать репликацию данных в разных регионах с потенциальными проблемами согласованности, глобальной маршрутизацией трафика и более высокими затратами. Пусть ваши требования к надежности управляют этим решением.
Используйте целевые показатели надежности для руководства по региональной стратегии. Определите цели уровня обслуживания (SLO), цели точки восстановления (RPO) и цели времени восстановления (RTO) для определения региональных требований.
Убедитесь в соблюдении правил регулирования хранения данных. Обратитесь к командам по юридическим вопросам и соответствию требованиям, чтобы обеспечить региональный выбор в соответствии с нормативными обязательствами.

Архитектура документов

Создайте подробную схему архитектуры и документ конструктора. Документация поддерживает реализацию, проверку и дальнейшее обслуживание. Включите выбранные службы Azure, SKU, потоки данных и пользовательские взаимодействия. Убедитесь, что схема предоставляет четкое визуальное представление архитектуры для поддержки реализации и проверок.
Записывайте ключевые решения по проектированию и компромиссы. Задокументируйте обоснование архитектуры, включая нефункциональные требования, такие как надежность, безопасность и производительность. Выделите все компромиссы, сделанные для баланса конкурирующих приоритетов.

Планирование стратегии развертывания на основе облака

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

Планирование практик разработки и развертывания

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

Установите методики DevOps для автоматизации развертывания. Методики DevOps выравнивают команды разработки и операций с помощью автоматизации, управления версиями и конвейеров CI/CD. Используйте такие средства, как Azure DevOps или GitHub Actions, для автоматизации рабочих процессов сборки, тестирования и развертывания. Этот подход уменьшает ошибки вручную, ускоряет циклы выпуска и обеспечивает согласованные процессы развертывания в разных средах.
Планируйте операционную готовность для поддержки мероприятий по развертыванию. Готовность к работе включает в себя процедуры мониторинга, оповещения и реагирования на инциденты для сценариев развертывания. Документация по запуску и развертыванию, а также сценарии автоматизации, включающие процедуры отката, проверки работоспособности и шаги по устранению неполадок. Сохраните эти ресурсы в центральном расположении, например Azure DevOps Wiki или GitHub, чтобы обеспечить доступность во время развертывания.
Определите методики разработки , поддерживающие надежные развертывания. Используйте стандарты программирования, проверки одноранговых узлов и автоматическое тестирование для обеспечения качества кода и готовности к развертыванию. Интегрируйте эти методики в конвейер CI/CD для принудительного применения шлюзов качества перед развертыванием. Включите тесты, относящиеся к развертыванию, такие как тесты интеграции, тесты дыма и проверка производительности, чтобы проверить готовность системы к рабочей среде.

Планирование внедрения новых рабочих нагрузок

Используйте прогрессивное воздействие, чтобы ограничить влияние. Для нового приложения (greenfield) без существующих пользователей следует выполнить мягкий запуск. Развернуть в рабочую среду, но изначально открыть доступ только внутренним пользователям или пилотной группе. Этот подход — это канареечное развертывание для новой рабочей нагрузки. Если это действительно новое и изолированное, однократное развертывание до полной рабочей среды возможно, но поэтапный вывод по-прежнему рекомендуется для выявления любых проблем в контролируемых условиях. Не выпускайте систему на 100% пользователей в первый же день без предварительной проверки в реальных условиях. Дополнительные сведения см. в статье WAF. Внедрение прогрессивной модели экспозиции.
Документируйте операционные процедуры и пути эскалации. Создайте четкую документацию для перезапуска служб, доступа к журналам, обработке распространенных проблем и эскалации инцидентов. Сохраните эту документацию в общем репозитории, например SharePoint или GitHub, чтобы обеспечить доступность для групп поддержки.

Планирование развертывания новых функций

Планирование интеграции новых функций с помощью управления изменениями. Следуйте процессу управления изменениями организации, чтобы контролировать и документировать изменения в рабочей среде. Определите процедуры отката, такие как отмена версий приложения или восстановление резервных копий базы данных. Получите одобрение заинтересованных сторон перед развертыванием, чтобы обеспечить соответствие бизнес-целям. Дополнительные сведения см. в разделе "Управление изменениями в CAF".
Используйте локальные обновления для незначительных или обратно совместимых изменений. Развертывайте обновления непосредственно в продуктивной среде с помощью последовательного обновления или флагов функций. Начните с небольшого процента пользователей или экземпляров. Отслеживайте системные метрики и журналы для проверки стабильности до полного развертывания.
Используйте параллельные (сине-зеленые) развертывания для крупных или высокориском изменений. Разверните новую версию в отдельной среде. Перенаправите небольшую часть динамического трафика в новую версию, чтобы проверить поведение. При успешном выполнении переместите весь трафик на новую версию. При возникновении проблем верните трафик к исходной версии, чтобы обеспечить непрерывность.
План введения в эксплуатацию новых рабочих нагрузок. Определите группу, ответственной за работу и поддержку решения после развертывания. Определите модель поддержки (24/7 по телефону или часы поддержки) и убедитесь, что все заинтересованные лица понимают свои роли.
Определите обязанности владения и поддержки. Убедитесь, что группа операций готова поддержать новую функцию. Обновите документацию и пути эскалации для отражения новых обязанностей и обеспечения быстрого реагирования на инциденты.

Определите план отката для облачно-нативных решений

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

Дайте определение неудачного развертывания. Работать вместе с заинтересованными сторонами бизнеса, владельцами рабочих нагрузок и командами операционного управления, чтобы определить, что должно считаться неудачным развертыванием. К примерам относятся неудачные проверки состояния системы, недостаточная производительность, уязвимости системы безопасности или критерии успешности. Это определение гарантирует, что решения по откату соответствуют допустимости рисков вашей организации. Включите определенные условия, которые активируют откат в плане развертывания, такие как ограничения использования ЦП, пороговые значения времени отклика или частоты ошибок. Эта оценка делает решения об откате ясными и согласованными в случае инцидентов.
Автоматизация шагов отката в конвейерах CI/CD. Используйте такие средства, как Azure Pipelines или GitHub Actions , для автоматизации процессов отката. Например, настройте конвейеры для повторного развертывания предыдущей версии, если проверка работоспособности завершается ошибкой.
Создайте инструкции по откату для конкретной рабочей нагрузки. Создайте шаги отката, соответствующие типу рабочей нагрузки, среде и методу развертывания. Например, развертывания инфраструктуры как кода требуют повторного использования предыдущих шаблонов. Откаты приложений предполагают развертывание предыдущего образа контейнера заново. Подключите скрипты отката, моментальные снимки конфигурации и шаблоны инфраструктуры как кода к плану отката. Эти ресурсы позволяют быстро выполнять и уменьшать зависимость от вмешательства вручную.
Тестирование процедур отката. Имитация отказов развертывания в предпродакшн-среде, чтобы проверить эффективность отката. Определение и устранение пробелов в автоматизации, разрешениях или зависимостях. Убедитесь, что откат восстанавливает систему до стабильного, известного состояния.
Улучшайте стратегии отката После каждого события развертывания или отката проводите ретроспективную оценку того, что работало и что не сработало. Обновите критерии отката, процедуры и автоматизацию на основе полученных уроков, изменений архитектуры или новых инструментов. Поддерживайте документацию, чтобы гарантировать, что стратегии отката остаются актуальными и эффективными.

Следующий шаг

Создание нового решения