Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Проектирование критически важного приложения на любой облачной платформе требует тщательного подхода к проектированию. Существует сложность: понимание возможностей платформы, выбор правильных служб, их правильная настройка, эффективная их эксплуатация и согласование с развивающимися рекомендациями и планами обслуживания.
Чтобы перейти к этой сложности, создайте четкую и простую методологию проектирования, которая соответствует вашим бизнес-требованиям, особенно во время простоя и восстановления. Когда принятие решений становится сложным или вы оказываетесь в состоянии анализа-паралича, вернитесь к своей методологии в качестве точки отсчёта. Это может помочь проверить ваш выбор, сосредоточиться на дизайне и обеспечение соответствия вашим общим целям.
В этой статье описана методология проектирования, которая была проинформирована аналитическими сведениями, полученными при просмотре многочисленных критически важных приложений, развернутых в Azure.
Создавайте проект в соответствии с вашими целями надежности
Понятие "жизненно важный" не одинаково для всех. Архитектура зависит от бизнес-требований рабочей нагрузки и приемлемого времени простоя. Они часто определяются целями уровня обслуживания (SLO), такими как доступность 99.9% и 99.999%. Учитывайте, что цели доступности подразумевают не только время безотказной работы. Они представляют собой согласованную услугу в отношении работоспособного состояния приложения. В качестве отправной точки команды должны определить допустимое время простоя. Используйте калькулятор времени безотказной работы/простоя, чтобы определить допустимое время простоя.
Эта методология проектирования может служить отправной точкой для архитектурных решений и компромиссов после установки целей. Так как проект целевой архитектуры имеет форму и стоимость и сложность становятся более понятными, первоначальные требования могут быть пересмотрены, оспариваются, корректируются или устраняются с помощью альтернативных решений.
Например, в то время как однорегиональная установка с несколькими зонами может быть достаточной для многих критически важных рабочих нагрузок, более высокий уровень надежности требует больше инженерных усилий и сложности. Избегайте использования по умолчанию сложных решений, таких как активные-активные решения для нескольких регионов, если на это нет сильных требований.
RTO (цель времени восстановления) и RPO (цель точки восстановления) также являются ключевыми в определении потребностей надежности. Например, если ваша цель состоит в том, чтобы восстановить приложение в течение минуты, резервные копии или активные пассивные стратегии, скорее всего, не будут достаточно быстрыми.
Рекомендации по определению целевых показателей надежности
Стремиться к комплексной автоматизации
Примите комплексную стратегию автоматизации, которая охватывает как развертывание, так и текущие действия по управлению. Эта методология подчеркивает согласованность, повторяемость и устойчивость с помощью принципов автоматизации.
Типичными областями автоматизации являются стандартные задачи, такие как исправление, масштабирование и мониторинг, сокращение усилий и ошибок вручную. Используйте шаблоны для настройки и развертывания, чтобы обеспечить согласованность и ясность, используя сценарии только в том случае, если шаблоны не являются жизнеспособными.
Проектирование развертываний без простоя
Развертывания без простоя гарантируют, что пользователи не испытывают перебоев во время изменений.
Эта методология требует строгого предварительного тестирования, чтобы обновления не вводят дефекты, уязвимости или нестабильность. Для поддержки этого средства и процессы развертывания должны быть высокодоступны и устойчивы.
Согласованность является ключом. Одни и те же артефакты и автоматизированные процессы должны использоваться во всех средах для устранения любой вероятности ошибок вручную и снижения общего риска. Полная автоматизация не просто предпочтительна; это обязательно для достижения надежных, повторяемых и без прерываний развертываний.
Рекомендации по развертыванию и тестированию
Проектирование для быстрого обнаружения сбоев и восстановления
Быстрое обнаружение сбоев начинается с четко определенной модели работоспособности. Поскольку сбои часто каскадные между компонентами, раннее обнаружение и очистка зависимостей между компонентами рабочей нагрузки являются неотменяемыми для минимизации радиуса взрыва и ускорения восстановления.
Это означает четкое определение работоспособного и неработоспособного вида каждого компонента на основе реальных потоков пользователей и пороговых значений бизнес-процессов для повышения производительности и доступности. Эти определения должны направлять метрики, которые вы отслеживаете, и помогать выявлять первопричину проблем.
Руководство по проектированию для моделирования в области здравоохранения
Развитие с помощью Azure
Разработайте архитектуру, чтобы быть модульной и гибкой, чтобы упростить внедрение новых функций без серьезных изменений. Регулярно просматривайте разработку, чтобы оставаться в курсе развития служб и возможностей Azure. Отдавайте предпочтение управляемым службам, нативным для Azure, благодаря их меньшим операционным затратам и лучшей интеграции. Поскольку обновления Azure выходят часто, приведение вашей архитектуры в соответствие с его дорожной картой поможет обеспечить оптимизацию вашего приложения и его готовность к будущему.
Обратитесь к Evolve with Azure и обновлениям Azure для получения последней информации о новых службах и функциях.
Следующий шаг
Начните ваш путь проектирования, изучите, как столпы Well-Architected Framework применяются к критически важному классу рабочих нагрузок.
Области проектирования связаны друг с другом, поэтому изменения в одной области могут повлиять на другие. Начните с наиболее важной области для вашего бизнеса, а затем просмотрите соображения и рекомендации, чтобы понять, как ваш выбор создает компромиссы в архитектуре.
Ознакомьтесь с этими эталонными архитектурами, описывающими решения по проектированию на основе этой методологии.