Описание клиента

  • 7 мин

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

Важные ограничения

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

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

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

Согласование с целевыми зонами Azure

Команды по операциям и разработке платформы утвердили следующее согласование:

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

Отклонение от рекомендаций по стандартной целевой зоне Azure

Далее описаны ограничения, из-за которых компания Tailwind Traders не смогла реализовать определенные принципы проектирования для целевых зон Azure, а также результаты каждого решения:

  • Управление на основе политик: компания Tailwind Traders ранее не автоматизировала корпоративные политики. Ввиду необходимости быстрой миграции центра обработки данных компания решила сократить объем управления, включая начальное развертывание целевой зоны.

    Также компания обязалась пройти модуль Learn по методологии управления Cloud Adoption Framework после настройки начальной среды. Важным фактором для такого отклонения стали ограниченные возможности ИТ-специалистов, которым поручена миграция в облако. Это отклонение дополнительно мотивировано нежеланием бизнес-подразделений и ИТ-команд создавать полноценную облачную систему управления (Azure Ops).

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

    Если команде по рабочим нагрузкам потребуется отклонение, главная операционная команда может выделить целевую зону для конкретных рабочих нагрузок на индивидуальной основе. Во всем остальном компания Tailwind Traders твердо намерена сохранить централизованные операции, выделяя ограниченное количество экземпляров рабочих нагрузок в изолированные рабочие среды (или целевые зоны приложений).

  • Модель служб, ориентированная на приложения: процессы, связанные со сбоями, могут учитывать особенности рабочих нагрузок, особенно для ресурсов, которые поддерживают критически важные рабочие нагрузки. Но, помимо сбоев, главная операционная команда не учитывает в процессах управления особенности рабочих нагрузок или приложений. Основные процессы команды реализуют управление, вносят изменения и оптимизируют ресурсы одинаково, без учета границ или архитектур рабочих нагрузок. Учитывая ограничения времени для этой миграции, Tailwind Traders не может определить границы приложений и создать модель служб, ориентированную на приложения.

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

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

Командам Tailwind Traders потребуется пройти модули Learn об управлении, безопасности и системе управления Cloud Adoption Framework после развертывания начальной среды.

Дополнительные ограничения

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

Операции

Центральный отдел эксплуатации разработал набор процессов и мер контроля для управления общим набором услуг. Команда зависит от System Center Operations Manager и Microsoft Configuration Manager для базовых показателей операций.

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

Операционные инструменты

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

Операционные процессы

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

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

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

Соглашение об уровне обслуживания

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

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

Инновации в розничной торговле

Группа розничных инноваций была первоначально стартапом, который Tailwind Traders приобрел. Первоначальный генеральный директор стартапа теперь является главным техническим директором (CTO) Tailwind. Технический директор по-прежнему управляет этим подразделением как стартапом, уделяя приоритетное внимание экспериментам и инновациям.

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

Управление удостоверениями

Доменные службы Active Directory — это хранилище идентификационных данных и основной инструмент для аутентификации и контроля доступа в центрах обработки данных Tailwind Traders. Компания использовала несколько лучших в своем классе систем, чтобы расширить идентификацию до решения для многофакторной аутентификации. Компания также имеет федеративные удостоверения для развертывания своего решения Microsoft 365. Но даже с этим доменные службы Active Directory — это то, как Tailwind Traders управляет идентификацией.

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

Топология сети и подключения

Tailwind Traders использует линии многопротокольной коммутации по меткам (MPLS) для соединения своих центров обработки данных и физических магазинов. Весь интернет-трафик проходит через основной центр обработки данных. Из-за конфликтов интернет-протокола (IP) между двумя центрами обработки данных трафик изолирован, а маршрутизация зависит от сложных таблиц маршрутизации. Внешнее подключение к центру обработки данных или корпоративному офису осуществляется через виртуальную частную сеть. Эта возможность подключения ограничена и не рекомендуется.

Основной и дополнительный центры обработки данных имеют единообразные схемы IP-адресов, которые хорошо организованы и понятны. Третий центр обработки данных включает 50 различных и плохо согласованных блоков IP-адресов без четкого плана по организации или сегментации. Циклы непрерывных инноваций ограничены третьим центром обработки данных, но могут представлять проблемы с определением топологии сети и маршрутизации в облаке.

Организация ресурсов

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

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

Для менее критических рабочих нагрузок указанным владельцем нередко является бывший сотрудник Tailwind Traders. Часто сопоставление конфигурации ссылается на уже завершенные виртуальные машины. Точно так же более 30 процентов поддерживаемых активов не привязаны к одной рабочей нагрузке. Во время миграции компании потребуется практическое обучение, чтобы обеспечить правильный анализ зависимостей и организацию ресурсов.