Спецификация проектирования архитектуры рабочей нагрузки
Спецификация проектирования архитектуры рабочей нагрузки — это подробная спецификация, которая описывает варианты проектирования и сопровождается схемами. Варианты проектирования должны соответствовать функциональным и нефункциональным требованиям и включать положения для обычных, нерегламентированных и чрезвычайных операций.
Дополнительные сведения о схемах см. в схемах проектирования архитектуры.
Архитектура рабочей нагрузки, как правило, расширяемая, начинается с разработки приложений и выполняется выбор облачной службы. Эти этапы взаимно информируют друг друга. Объединенная конструкция приложений и инфраструктуры должна соответствовать всем требованиям.
Достижение решения, удовлетворяющего всем требованиям, — это совместная работа между заинтересованными лицами, разработчиками, тестировщиками, группами операций и владельцами продуктов. Процесс проектирования должен включать уточнение требований с ясностью и согласованием. Процесс является итеративным и часто требует нескольких проверок.
Мы рекомендуем выровнять дизайн с основным руководством по Azure Well-Architected Framework, включающим принципы проектирования и рекомендации, и признать компромиссы.
В конечном счете спецификация проектирования архитектуры рабочей нагрузки реализуется командой разработки рабочей нагрузки, поэтому она должна быть четкой и однозначной. Спецификация должна быть легко доступна и храниться в документации рабочей нагрузки.
Функциональная спецификация
Функциональная спецификация рабочей нагрузки содержит сведения о том, что и почему система или компонент в процессе разработки, но не реализация. Этот документ должен объяснить текущие проблемы, которые существуют, и как эта функция или система будет улучшать этот интерфейс. Этот документ фиксирует большую часть бизнес-требований.
Архитектор может помочь сформировать этот документ, но в первую очередь это функция владения продуктами. Архитектор должен помочь разработать данные, которые записываются в этой спецификации. Это участие обеспечивает эффективное и эффективное техническое проектирование функциональных спецификаций.
Ниже приведены несколько примеров тем, которые должны быть рассмотрены в этой спецификации.
Помимо подробных сведений о том, что находится в области этого проектирования, также следует явно думать о смежных проблемах, которые находятся вне области. Настройка четких областей уменьшает ползут область, определяя границы вокруг функциональных возможностей.
Полезно включить подробные сведения о том, как это изменение будет измеряться. Какие измерения необходимо собирать и какие бизнес-цели поддерживают эти измерения.
Потоки пользователей должны быть четко описаны. Низко-федерализм макетов также может быть полезным. Если ситуации обработки ошибок важны для этих потоков, убедитесь, что ожидаемое поведение описано.
Всегда включать все конкретные требования к специальным возможностям, соответствию требованиям, производительности, конфиденциальности или безопасности.
Включите любую запланированную стратегию развертывания. Например, "Эта функция будет доступна для наших бета-пользователей в течение двух месяцев, прежде чем принимать решение о полном выпуске".
Избегайте конкретных технических сведений о реализации в этой спецификации. Эти функциональные спецификации будут управлять техническими спецификациями, созданными архитектором.
Техническая спецификация
Техническая спецификация описывает, как на основе области и целей, описанных в функциональной спецификации. Эта спецификация предназначена для разработчиков, которые будут использовать в качестве плана записи во время реализации.
В этой спецификации содержатся такие элементы, как:
- Технологические решения, включая: покупку, сборку, повторное использование, расширение или вывод из эксплуатации.
- Контракты API и данных (схемы), включая стратегию реализации обратной совместимости
- Сведения о реализации развертывания и откате
- Уникальный жизненный цикл безопасной разработки (SDL) и реализация конфиденциальности
- Тестовый план
- Ключевые источники сигналов мониторинга и оповещения
- Альтернативные проекты, которые были рассмотрены
Техническая спецификация будет стимулировать инженерные усилия. Инженерные рабочие элементы в основном создаются из содержимого этой спецификации. Команды реализации относятся к рабочим элементам, технической спецификации и функциональной спецификации, чтобы гарантировать, что окончательный результат соответствует как функциональным, так и нефункциональным требованиям.
Планы аварийного восстановления
Чтобы обеспечить соответствие требованиям к надежности рабочей нагрузки, архитектору необходимо разработать систему, которая может восстановиться в рамках целевой цели времени восстановления (RTO) и цели точки восстановления (RPO). Спецификация проектирования архитектуры должна включать план восстановления. Этот план должен охватывать задействованные компоненты архитектуры, механизмы отработки отказа и влияние на поток данных пользователя и поток данных, а также операционные рекомендации. Он должен описать, какие целевые объекты восстановления соответствуют проектированию и каким образом.
Хотя первоначальный план, как ожидается, будет развиваться на основе аналитических сведений о детализации и после инцидентах, это ответственность архитектора по доставке первоначального плана для всей новой архитектуры.
Документация по безопасности и соответствию требованиям
Архитектор отвечает за проектирование решения, которое соответствует соответствующим ограничениям безопасности и соответствия требованиям. Важно, чтобы артефакты дизайна подчеркивали возможности, включенные в проект, для поддержки этих требований, и для выявления любых необходимых компенсирующих элементов управления, когда требования не могут быть выполнены напрямую.
Согласованность
Используйте шаблон для документирования различных спецификаций рабочей нагрузки. Согласованность помогает заинтересованным лицам, ответственным сторонам и группам реализации при чтении спецификации.
Убедитесь, что спецификации имеют поля ключевых метаданных, такие как:
- Состояние: состояние " Черновик", "В обзоре" и "Утверждено".
- Ссылка на рабочий элемент: ссылка на основной рабочий элемент в невыполненной работе команды.
- Ключевые перекрестные ссылки: ссылки на связанные спецификации или другую документацию, которая поддерживает спецификацию.
- Ключевые лица: место для перечисления имен ключевых лиц, участвующих в принятии решений. Этот список может включать такие роли, как бизнес-аналитик, бизнес-партнер, технический руководитель, владелец продукта или ведущий, который подписал спецификацию.