Создание для бизнес-потребностей

  • Статья

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

Должно ли ваше приложение поддерживать миллионы пользователей или несколько тысяч? Есть ли большие всплески трафика или стабильная рабочая нагрузка? Какой уровень сбоя приложения допустим? В конечном счете, бизнес-требования управляют этими рекомендациями по проектированию.

Ниже приведены рекомендации по проектированию и созданию решений в соответствии с бизнес-требованиями.

  • Определите бизнес-цели , такие как целевое время восстановления (RTO), целевая точка восстановления (RPO) и максимально допустимый сбой (MTO). Эти значения и станут критериями при выборе архитектуры.

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

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

  • Документирование соглашений об уровне обслуживания (SLA) и целей уровня обслуживания (SLO), включая метрики доступности и производительности. Например, предлагаемое решение может обеспечить доступность на 99,95 %. Соответствует ли это SLO соглашения об уровне обслуживания, является бизнес-решением.

  • Моделировать приложения для вашей бизнес-области. Проанализируйте бизнес-требования и используйте их для моделирования решения. Рассмотрите возможность использования подхода к проектированию на основе предметной области (DDD) для создания моделей предметной области, отражающих бизнес-процессы и варианты использования.

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

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

  • План роста. Решение может поддерживать текущие потребности в количестве пользователей, объеме транзакций и хранении данных, но оно также должно обрабатывать рост без серьезных изменений архитектуры. Кроме того, учитывайте, что бизнес-модель и бизнес-требования могут со временем измениться. Трудно разработать решение для новых вариантов использования и сценариев, если модель службы и модели данных приложения слишком жесткие.

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

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

Дальнейшие действия