Поделиться через

Антишаблоны готовности к работе в облаке

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

Антишаблон: предположение, что релизнутые сервисы готовы для рабочей среды

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

  • Службы предварительной версии обычно не предоставляют соглашения об уровне доступности обслуживания (СУО).
  • А новые службы зачастую не такие зрелые, как уже доступные облачные службы.

Пример: использование предварительной версии службы в рабочей среде

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

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

Предпочтительный результат: необходимо использовать предварительно утвержденные облачные службы в рабочей среде

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

Антишаблон: предполагается повышенная устойчивость и доступность

Облачные вычисления имеют определенные преимущества по сравнению с локальными решениями. Вот некоторые примеры.

  • Повышенная устойчивость: Вы можете противостоять сбоям, ошибкам или локализованным инцидентам инфраструктуры и продолжать работать без видимых пользователем сбоев.
  • Наличие: Работать в исправном состоянии без значительных простоев.

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

Пример: предполагается высокий уровень доступности

Стартап внедряет критически важное приложение на услугах инфраструктуры как услуги (IaaS). Во время запуска разработчики изучили виртуальную машину с соглашением об уровне обслуживания с временем бесперебойной работы на уровне 99,9%. С целью сокращения затрат они использовали одну виртуальную машину и хранилище класса Premium.

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

  • Модели служб (платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS)).
  • Технические архитектуры, такие как наборы доступности с балансировкой нагрузки и зоны доступности.

Предпочтительный результат: сокращение сбоев при обеспечении баланса между устойчивостью и затратами

Рекомендации по созданию архитектуры для уменьшения вероятности сбоев можно найти в проверенных и надежных источниках:

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

  • Одна виртуальная машина может иметь соглашение об уровне обслуживания с гарантированным временем бесперебойной работы 99,9%.
  • Две виртуальные машины, выполняющие одну и ту же рабочую нагрузку, обеспечивают соглашение об уровне обслуживания с временем бесперебойной работы от 99,95 до 99,99%.

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

Антишаблон: станьте поставщиком облачных услуг

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

Пример: предоставление монолитных управляемых облачных служб

ИТ-отдел компании создает облачный центр инноваций (CCoE), который выступает в качестве брокера между ИТ-отделом и другими подразделениями. Для обеспечения соответствия компании облачным стандартам, совет директоров возлагает на Облачный центр передового опыта задачу предоставления монолитных комплексных служб. Облачный центр инноваций настраивает внутренний облачный портал закупок для того, чтобы подразделения могли заказывать полностью управляемую облачную виртуальную машину в качестве службы. ИТ-отдел контролирует, кто может получить доступ и использовать всю платформу. В результате IT активно предотвращает использование бизнес-подразделениями всего спектра служб, предоставляемых Azure. Доступа к облачному порталу у бизнес-подразделений нет. Доступ к желаемому серверу можно получить только через Secure Shell (SSH) и протокол удаленного рабочего стола (RDP).

Облачный центр инноваций сталкивается с трудностями при предоставлении монолитного управляемого сервиса, который охватывает каждую доступную в облаке услугу, по нескольким причинам:

  • В облаке содержится большое количество служб в нескольких областях решения. В отличие от разработки решений IaaS, для проектирования и разработки решений для Интернета вещей (IoT) и искусственного интеллекта необходимы другие знания и навыки.
  • Облачные службы часто изменяются.
  • Попытка предоставить монолитные услуги существенно увеличивает время выхода на рынок, поскольку ИТ-отдел управляет процессом, а не бизнес-подразделениями.

Предпочтительный результат: установите ограничения

При внедрении облачных технологий ИТ-отдел получает опыт работы с облаком, начав с рабочих ИТ-нагрузок. Используя платформу Microsoft Cloud Adoption Framework для Azure, обозначьте первый проект внедрения.

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

Максимально используйте решения SaaS для ИТ-инструментов, таких как:

  • Репозитории кода.
  • Непрерывная интеграция и непрерывная поставка (CI/CD).
  • Системы совместной работы.

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

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

  • Last updated on