Создание облачных решений

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

Разработка новых облачных решений

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

Применение принципов Well-Architected Framework во время разработки

Облачное решение дает преимущества от применения принципов Well-Architected Framework (WAF). Платформа Well-Architected предоставляет принципы эффективной облачной разработки. Интеграция этих пяти основных компонентов для создания надежных приложений, которые хорошо работают в рабочей среде.

Разработка решений в непроизводственных средах

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

2. Используйте реалистичные наборы данных, представляющие объемы рабочих данных. Проверьте данные, соответствующие размеру и сложности рабочих нагрузок. Большие наборы данных выявляют узкие места производительности и проблемы масштабирования, которых нет в небольших тестовых наборах данных. Анонимизируйте рабочие данные или создавайте искусственные данные, которые сохраняют статистические свойства реальных данных.

3. Реализуйте элементы управления затратами для непроизводственных сред. Используйте Azure DevTest Labs или планирование ресурсов для автоматического запуска и остановки ресурсов, если они не используются. Примените соответствующие уровни служб для рабочих нагрузок разработки и реализуйте ограничения расходов, чтобы предотвратить непредвиденные затраты при сохранении эффективности тестирования.

Дополнительные сведения см. в разделе "Настройка тестовой среды в WAF".

Внедрение изменений с помощью системы управления версиями и CI/CD

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

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

3. Автоматизируйте сборки и тесты при каждом изменении кода. Настройте конвейеры CI/CD для автоматической компиляции кода, выполнения тестов и развертывания в непродуктивных средах при внесении изменений. Быстрые циклы обратной связи помогают разработчикам быстро перехватывать и устранять проблемы.

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

Реализация мониторинга во время разработки

1. Интеграция Azure Monitor и Application Insights в код приложения. Добавьте сбор данных мониторинга для отслеживания ключевых метрик производительности, взаимодействия с пользователем и индикаторов работоспособности системы. Настройте эти средства во время разработки, чтобы обеспечить правильную работу перед рабочим развертыванием.

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

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

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

Дополнительные сведения см. в статье "Проектирование системы мониторинга и инструментирование приложения в WAF".

Проверка облачных решений с помощью тестирования

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

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

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

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

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

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

6. Поддержка автоматизированных модульных и интеграционных тестовых наборов. Создайте комплексные автоматизированные тесты, которые проверяют отдельные компоненты и их взаимодействие с внешними зависимостями. Выполните эти тесты в рамках конвейера CI/CD и после каждого исправления ошибок, чтобы предотвратить регрессию. Надежный набор автоматизированных тестов обеспечивает надежную непрерывную доставку в облачных средах.

Создание повторно используемых инфраструктур

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

1. Создайте шаблоны IaC для проверенных конфигураций. Выполните окончательную архитектуру тестовой среды (которая отражает то, что требуется в prod) и кодифицируйте ее. Используйте Bicep, Terraform или Azure Resource Manager шаблоны для определения инфраструктуры. Параметризуйте эти шаблоны, чтобы их можно было повторно использовать для различных этапов, таких как разработка, тестирование, с небольшими настройками, такими как имена или размеры. Эта настройка гарантирует, что созданная рабочая среда соответствует тестируемой среде. Это позволяет избежать человеческих ошибок при ручной навигации по порталу Azure для создания ресурсов. Это также означает, что если вы когда-либо хотите повторно создать среду, например для аварийного восстановления или развертывания в новых регионах, у вас будет готово развертывание инфраструктуры. Дополнительные сведения см. в разделе CAF Manage - Управление кодовыми развертываниями.

2. Храните шаблоны в элементе управления версиями. Проверьте код инфраструктуры в репозитории Git (наряду с кодом приложения или в отдельном репозитории). Используйте GitHub или Azure DevOps для управления ресурсами IaC с соответствующим управлением версиями. Управление версиями включает проверки кода, поддерживает совместную работу команды и поощряет повторное использование шаблона в проектах. Этот подход обеспечивает полную отслеживаемость изменений в инфраструктуре и поддерживает возможность отката при возникновении проблем.

3. Автоматизация установки и настройки зависимостей. Создайте скрипты или задачи конвейера для развертывания этих шаблонов, а также обработайте все необходимые задачи конфигурации или заполнения. Используйте Azure Pipelines, GitHub Actions для выполнения заданий развертывания, которые принимают шаблон IaC и развертывают в целевой подписке или группе ресурсов. Автоматизация установки зависимостей приложений, настройки параметров и управления секретами. Цель — это настройка среды в один щелчок (или однокомандный процесс): с нуля до полностью работающей среды, которая соответствует ранее протестированной.

4. Протестируйте IaC и автоматизацию от начала до конца. Используйте отдельную Azure подписку или группу ресурсов в качестве песочницы и практики развертывания всей среды с нуля с помощью шаблонов и сценариев. Проверьте, что шаблоны, конвейеры и скрипты IaC могут создавать полный стек инфраструктуры из ничего. Проверьте различные сценарии развертывания, включая начальное развертывание, обновления конфигурации и процедуры отката, чтобы убедиться, что автоматизация работает правильно.

Дополнительные сведения см. в статье "Проектирование цепочки поставки разработки нагрузки " и "Инфраструктура как код" в WAF.

Создание документации по развертыванию

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

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

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

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

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

Развертывание облачных решений