Разработка спецификации проектирования архитектуры

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

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

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

Мы рекомендуем выровнять проект с основным руководством по Azure Well-Architected Framework, включающим принципы проектирования и рекомендации, и признать компромиссы.

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

Техническая спецификация

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

В этой спецификации содержатся такие элементы, как:

• Технологические решения, включая: покупку, сборку, повторное использование, расширение или вывод из эксплуатации.
• Контракты API и данных (схемы), включая стратегию реализации обратной совместимости
• Сведения о реализации развертывания и откате
• Уникальный жизненный цикл безопасной разработки (SDL) и реализация конфиденциальности
• Тестовый план
• Ключевые источники сигналов мониторинга и оповещения
• Альтернативные проекты, которые были рассмотрены

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

Планы аварийного восстановления (ПАВ)

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

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

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

Документация по безопасности и соответствию требованиям

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

Согласованность

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

Убедитесь, что спецификации имеют поля ключевых метаданных, такие как:

• Состояние: состояние " Черновик", "В обзоре" и " Утверждено".
• Ссылка на рабочий элемент: ссылка на основной рабочий элемент в невыполненной работе команды.
• Ключевые перекрестные ссылки: ссылки на связанные спецификации или другую документацию, которая поддерживает спецификацию.
• Ключевые лица: место для перечисления имен ключевых лиц, участвующих в принятии решений. Этот список может включать такие роли, как бизнес-аналитик, бизнес-партнер, технический руководитель, владелец продукта или ведущий, который подписал спецификацию.

Дальнейшие шаги