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

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

Важно!

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected . Если вы не знакомы с этой серией, рекомендуем начать с критически важной рабочей нагрузки?

Эти критически важные принципы проектирования резонируют и расширяют основные принципы качества платформы Azure Well-Architected: надежность, безопасность, оптимизация затрат, эффективность работы и эффективность производительности.

надежность;

Максимальная надежность — фундаментальное стремление к наиболее надежному решению, гарантирующее правильное понимание компромиссов.

Принцип проектирования	Рекомендации
Проектирование "активный/активный"	Чтобы обеспечить максимальную доступность и обеспечить отказоустойчивость в регионе, компоненты решения должны распределяться по нескольким регионам Зоны доступности и Azure с помощью модели активного и активного развертывания, где это возможно.
Уменьшение радиуса взрыва и изоляция сбоя	Сбой невозможно избежать в высокораспределённой мультитенантной облачной среде, такой как Azure. Прогнозируя сбои и коррелированные последствия , от отдельных компонентов до целых регионов Azure, решение можно разработать и разработать устойчивым образом.
Наблюдение за работоспособностью приложений	Прежде чем устранить проблемы, влияющие на надежность приложений, их необходимо сначала обнаружить и понять. Отслеживая работу приложения относительно известного работоспособного состояния, можно обнаруживать или даже прогнозировать проблемы с надежностью, что позволяет выполнять быстрые действия по исправлению.
Автоматизация дисков	Одной из основных причин простоя приложения является человеческая ошибка, связанная с развертыванием недостаточно протестированного программного обеспечения или неправильной настройкой. Чтобы свести к минимуму вероятность и влияние человеческих ошибок, крайне важно стремиться к автоматизации во всех аспектах облачного решения для повышения надежности; автоматическое тестирование, развертывание и управление.
Разработка для автоматического восстановления	Самовосстановление описывает способность системы автоматически устранять сбои с помощью предварительно определенных протоколов исправления, подключенных к режимам сбоя в решении. Это расширенная концепция, требующая высокого уровня зрелости системы с мониторингом и автоматизацией, но с самого начала она должна быть стремлением к максимальной надежности.
Избегание сложности	Избегайте ненужных сложностей при проектировании решения и всех рабочих процессов, чтобы повысить надежность и эффективность управления, сводя к минимуму вероятность сбоев.

Уровень производительности

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

Принцип проектирования	Рекомендации
Проектирование для горизонтального увеличения масштаба	Горизонтальное масштабирование — это концепция, которая фокусируется на способности системы реагировать на спрос за счет горизонтального роста. Это означает, что по мере роста трафика все больше единиц ресурсов добавляются параллельно, а не увеличивают размер существующих ресурсов. Способность системы обрабатывать ожидаемое и неожиданное увеличение трафика с помощью единиц масштабирования имеет важное значение для общей производительности и надежности за счет дальнейшего снижения влияния сбоя одного ресурса.
Автоматизация для гипермасштабирования	Операции масштабирования в решении должны быть полностью автоматизированы, чтобы свести к минимуму влияние на производительность и доступность от неожиданного или ожидаемого увеличения трафика, гарантируя, что время, необходимое для выполнения операций масштабирования, будет понято и согласовано с моделью работоспособности приложений.
Непрерывная проверка и тестирование	Автоматическое тестирование должно выполняться в процессах CI/CD, чтобы обеспечить непрерывную проверку для каждого изменения приложения. Необходимо включить нагрузочное тестирование на основе базовых показателей производительности с синхронизированными экспериментами с хаосом для проверки существующих пороговых значений, целевых показателей и предположений, а также для быстрого выявления рисков для устойчивости и доступности. Такое тестирование должно выполняться в промежуточной и тестовой средах, а также при необходимости в средах разработки. Также может быть полезно выполнить подмножество тестов в рабочей среде, особенно в сочетании с сине-зеленой моделью развертывания для проверки новых меток развертывания перед получением рабочего трафика.
Сокращение накладных расходов с помощью управляемых служб вычислений	Использование управляемых вычислительных служб и контейнерных архитектур значительно сокращает текущие административные и операционные затраты на проектирование, эксплуатацию и масштабирование приложений за счет переноса развертывания и обслуживания инфраструктуры на поставщика управляемых служб.
Базовая производительность и определение узких мест	Тестирование производительности с подробными данными телеметрии из каждого системного компонента позволяет выявить узкие места в системе, включая компоненты, которые необходимо масштабировать по отношению к другим компонентам, и эти сведения должны быть включены в модель емкости.
Емкость модели	Модель емкости позволяет планировать уровни масштабирования ресурсов для заданного профиля нагрузки и дополнительно показывает, как системные компоненты работают друг с другом, что позволяет планировать распределение ресурсов на уровне системы.

Эффективность операционных процессов

Операции по проектированию — благодаря надежному и надежному оперативному управлению.

Принцип проектирования	Рекомендации
Слабосвязанные компоненты	Слабая связь обеспечивает независимое тестирование, развертывание и обновление компонентов приложения по запросу, минимизируя зависимости между командами для поддержки, служб, ресурсов или утверждений.
Автоматизация процессов сборки и выпуска	Полностью автоматизированные процессы сборки и выпуска сокращают сложности и повышают скорость развертывания обновлений, повышая повторяемость и согласованность в разных средах. Автоматизация сокращает цикл обратной связи от разработчиков, которые отправляют изменения для получения аналитических сведений о качестве кода, охвате тестов, устойчивости, безопасности и производительности, что повышает производительность разработчиков.
Гибкость разработчика	Автоматизация непрерывной интеграции и непрерывного развертывания (CI/CD) позволяет использовать кратковременные среды разработки с жизненным циклом, привязанным к жизненным циклам связанного ветвь компонента, что повышает гибкость разработчика и позволяет выполнять проверку как можно раньше в рамках цикла разработки, чтобы свести к минимуму затраты на проектирование ошибок.
Количественное определение работоспособности операций	Полное диагностическое инструментирование всех компонентов и ресурсов обеспечивает постоянную наблюдаемость журналов, метрик и трассировок, а также упрощает моделирование работоспособности для количественной оценки работоспособности приложений в контексте требований к доступности и производительности.
Отработка восстановления и сбоя	Планирование непрерывности бизнес-процессов (BC) и аварийное восстановление (DR) имеют важное значение и должны выполняться часто, так как обучение может итеративно улучшать планы и процедуры, чтобы обеспечить максимальную устойчивость в случае незапланированного простоя.
Непрерывное улучшение операционных процессов	Приоритезируйте регулярное улучшение системы и взаимодействия с пользователем, используя модель работоспособности, чтобы понять и измерить эффективность работы с помощью механизмов обратной связи, чтобы позволить командам приложений понять и устранить пробелы в итеративном режиме.

Безопасность

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

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

Оптимизация затрат

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

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

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

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

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

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

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

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

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

Изучите сквозные проблемы, связанные с критически важными рабочими нагрузками.

Сквозная функциональность