Просмотр и сравнение распространенных облачных операционных моделей

Статья
03/22/2023

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

Сравнение операционных моделей

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

Диаграмма, показывающая степени сложности операционной модели.

Приоритеты или область

Облачная операционная модель в основном обусловлена двумя факторами:

Стратегические приоритеты или мотивации
Область управления портфелем

	Децентрализованные операции	Централизованные операции (ops)	Корпоративные операции (операции компании)	Распределенные операции (ops)
стратегические приоритеты или мотивации	Нововведение	Контроль	Демократизация	Интеграция
объем портфеля	Загруженность	Посадочная зона	Облачная платформа	Полный портфель
среда рабочей нагрузки	Высокая сложность	Низкая сложность	Средняя сложность	Средняя или переменная сложность
посадочная зона	N/A	Высокая сложность	Средняя и низкая сложность	Низкая сложность
Служебные программы Foundation	N/A	N/A или низкая поддержка	Централизованная и дополнительная поддержка	Большая поддержка
Основа облачных технологий	N/A	N/A	Гибридные, специфичные для поставщиков или региональные основы	Распределено и синхронизировано

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

Важный

Внедрение облака часто активирует отражение текущей операционной модели и может привести к переходу от одной общей операционной модели к другой. Но внедрение облака не является единственным триггером. Бизнес-приоритеты и область внедрения облака могут изменить способ поддержки портфеля. Кроме того, могут быть другие сдвиги в наиболее подходящей операционной модели. Когда совет или другие исполнительные группы разрабатывают 5-10-летние бизнес-планы, эти планы часто включают требование (явное или подразумеваемое) для настройки операционной модели. Операционные модели — это хорошая ссылка на руководящие решения. Эти модели могут изменяться или настраиваться в соответствии с вашими требованиями и ограничениями.

Выравнивание подотчетности

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

	Децентрализованные операции	Централизованные операции	Корпоративные операции	Распределенные операции
согласование бизнеса	команда рабочей нагрузки	центральная облачная стратегия	CCoE	Переменная — сформировать обширную команду по облачным стратегиям?
Облачные операции	команда рабочей нагрузки	Центральный ИТ	CCoE	На основе анализа портфеля — см. выравнивание бизнеса и бизнес-обязательства
управление облаком	команда рабочей нагрузки	Центральный ИТ	CCoE	несколько уровней управления
облачная безопасность	группа рабочей нагрузки	центр управления безопасностью (SOC) / функция DevSecOps	CCoE + SOC	Смешанная — см. раздел Определение стратегии безопасности
Автоматизация облаков и DevOps	команда рабочей нагрузки	центрального ИТ- или N/A	CCoE	На основе анализа портфеля, см. выравнивание бизнеса и обязательства по бизнесу

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

Как описано в разделе Определениеоперационной модели, каждая методология Cloud Adoption Framework предоставляет структурированный путь для разработки операционной модели. Эти методологии могут помочь вам преодолеть блокировщики, которые связаны с пробелами в внедрении облачной операционной модели.

В следующей таблице описаны способы ускорения реализации операционной модели.

	Децентрализованные операции	Централизованные операции	Корпоративные операции	распределенные операции
начальной точки	Azure Well-Architected Framework (WAF)	Зоны развертывания Azure: вариантов начать с малого	Целевые зоны Azure: CAF корпоративного масштаба	Согласование бизнеса
итерации	Фокус на рабочих нагрузках позволяет команде проводить итерации в рамках WAF.	Для варианта 'начать с малого' требуется больше итерации в каждой методологии, но его можно реализовать по мере созревания усилий по внедрению облачных технологий.	Как показано в эталонных реализациях, будущие итерации обычно сосредоточены на дополнительных дополнениях конфигурации.	Просмотрите варианты реализации зоны высадки Azure, чтобы начать с варианта, который лучше всего соответствует вашим базовым операционным процессам. Следуйте пути итерации, определенному в принципах проектирования этого параметра.

Децентрализованные операции

децентрализованные операции

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

Приоритеты: Ваша команда ставит измерение инноваций выше, чем централизованный контроль или стандартизацию в ряде рабочих нагрузок.
четкое преимущество. Максимальное ускорение инноваций путем предоставления рабочим нагрузкам и бизнес-командам полного контроля над проектированием, сборкой и операциями.
Явный недостаток: сокращение стандартизации между рабочими нагрузками, экономия от масштаба за счет общих служб и последовательные усилия по централизованному обеспечению соблюдения.
Риск: Этот подход создает риск при управлении портфелем рабочих нагрузок. Группы рабочей нагрузки могут иметь специализированные группы, предназначенные для центральных ИТ-функций. Эта операционная модель рассматривается как вариант с высоким риском для некоторых организаций, особенно для компаний, которым необходимо соблюдать требования стороннего соответствия.
руководство. Децентрализованные операции сводятся к решениям, принимаемым на уровне загрузки работы. Microsoft Azure Well-Architected Framework поддерживает решения, принятые в этой области. Процессы и рекомендации в Cloud Adoption Framework могут добавлять дополнительные расходы, которые не требуются децентрализованными операциями.

Преимущества децентрализованных операций

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

Недостатки децентрализованных операций

управление затратами: затраты предприятия сложнее вычислить. Отсутствие централизованных команд управления затрудняет реализацию единого контроля затрат или оптимизации. В большом масштабе эта модель может быть дорогостоящей, так как каждая нагрузка может иметь дублирование в развернутых ресурсах и назначениях персонала.
Обязанности: Отсутствие централизованной поддержки означает, что группа рабочей нагрузки полностью отвечает за управление, безопасность, операционные процессы и управление изменениями. Отсутствие поддержки проблематично, если эти задачи не были автоматизированы в конвейерах проверки кода и выпуска.
стандартизации. Стандартизация в портфеле рабочих нагрузок является переменной и несогласованной.
поддержка операций: Эффективность масштабирования часто упускается при создании лучших практик для нескольких рабочих нагрузок.
Экспертность. Члены команды несут большую ответственность за принятие мудрых и этических решений по управлению, безопасности, операциям и управлению изменениями в проектировании и конфигурировании приложений. Чтобы улучшить необходимый опыт, часто обращайтесь к Microsoft Azure Well-Architected Обзору и Azure Well-Architected Структуре.
Проектирование зоны посадки: Зоны посадки не являются специфичными для рабочей нагрузки и не учитываются в этом подходе.
основополагающие утилиты: немногие, если такие имеются, основополагающие службы разделяются между рабочими нагрузками, что снижает эффективность масштабирования.
Разделение обязанностей. Более высокие требования к командам DevOps и командам разработчиков повышают использование повышенных привилегий этими командами. Если требуется разделение обязанностей, может потребоваться значительно инвестировать в зрелость DevOps для работы с этим подходом.

Централизованные операции

централизованные операции

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

приоритеты. Приоритеты являются центральным контролем над инновациями и измеряют существующие операционные процессы в условиях культурного перехода к современным облачным операциям.
Явное преимущество: централизация представляет экономию за счет масштаба, лучшие методы управления и стандартизированные процессы и лучше всего работает в облачной среде. Эти среды нуждаются в конкретных конфигурациях для интеграции облачных операций в существующие операции и процессы. Централизация является наиболее выгодной с портфелем из нескольких сотен рабочих нагрузок с скромной архитектурной сложностью и требованиями соответствия.
различные недостатки. Масштабирование в соответствии с требованиями большого портфеля рабочих нагрузок может существенно наложить нагрузку на централизованные команды, которые принимают операционные решения для рабочих нагрузок. Если технические ресурсы ожидают масштабирования до 1000 виртуальных машин, приложений или источников данных, можно рассмотреть корпоративную модель в течение 18–24 месяцев.
риск: этот подход ограничивает централизацию меньшего количества подписок (часто одна рабочая подписка). Значительный риск связан с рефакторингом на более поздних этапах вашей облачной трансформации и может повлиять на ваши планы по внедрению. Чтобы избежать повторной работы, попробуйте сосредоточиться на сегментации, границах среды, инструментах идентификации и других базовых элементах.
Рекомендации. Варианты реализации зоны посадки Azure, которые соответствуют темпам разработки "начать с малого и расширяться", создают надежную отправную точку. Эти варианты можно использовать для ускорения усилий по внедрению. Для достижения успеха создайте четкие политики для управления усилиями по раннему внедрению в пределах приемлемого уровня риска. Управление методологиями помогает параллельно создавать процессы для зрелых операций. Следуя этим шагам, необходимо пройти контрольные этапы, которые должны быть завершены, прежде чем разрешать повышенный риск по мере созревания операций.

Преимущества централизованных операций

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

Недостатки централизованных операций

управление затратами: центральные команды не всегда понимают архитектуры рабочей нагрузки для создания влияющих оптимизаций на уровне рабочей нагрузки. Это недостаток понимания ограничивает степень экономии затрат, получаемой от хорошо настроенных процессов управления рабочей нагрузкой. Не полностью понимание архитектуры рабочей нагрузки может повлиять на централизованную оптимизацию затрат, которая влияет на производительность, масштабирование и другие компоненты хорошо спроектированной рабочей нагрузки. Прежде чем применять изменения затрат на уровне предприятия к значимым рабочим нагрузкам, центральная ИТ-группа должна изучить и завершить проверку Microsoft Azure Well-Architected.
обязанности: централизованная поддержка производства и доступ к ней возлагают большое рабочее бремя на несколько человек и более сильное давление на каждого отдельного человека. Давление, наложенное на этих лиц, приводит к тому, что необходимо выполнить более глубокие проверки развернутых рабочих нагрузок, которые проверяют соблюдение подробных требований к управлению безопасностью и соответствию требованиям.
стандартизации: централизованные ИТ-подходы затрудняют масштабирование стандартизации без линейного масштабирования центрального ИТ-персонала.
поддержка операций: наибольшие недостатки этого подхода связаны со значительным масштабом и изменениями, которые направлены на измерение инноваций.
опыт: эксперты в области разработки и DevOps рискуют быть недооцененными или слишком ограниченными в этой среде.
проектирование целевой зоны: проекты центров обработки данных основаны на ограничениях предыдущих подходов, которые не всегда относятся к облаку. Следование этому подходу сокращает возможности для переосмысления сегментации среды и расширения возможностей для инноваций. Отсутствие сегментации зон размещения увеличивает потенциальные последствия нарушения безопасности, осложняет управление и соблюдение требований, а также может создавать препятствия на пути к облачным технологиям. См. приведенный выше раздел о рисках.
базовые служебные программы: во время цифрового преобразования облако может стать основной операционной моделью. Центральные инструменты, созданные для локальных операций, сокращают возможности модернизации операций и повышают эффективность работы. Выбор не модернизации операций в начале процесса внедрения также является вариантом. Модернизация может быть достигнута путем создания подписки на платформу в пути внедрения облака. Эти усилия могут быть сложными, дорогостоящими и трудоемкими без расширенного планирования.
разделение обязанностей: центральные операции обычно следуют одному из двух путей и оба могут препятствовать инновациям.
- вариант 1: Командам за пределами центральной ИТ-службы предоставлен ограниченный доступ к средам разработки, которые имитируют рабочую среду. Этот параметр препятствует экспериментации.
- вариант 2: Teams разрабатывает и тестирует в не поддерживаемых средах. Этот параметр препятствует процессам развертывания и замедляет тестирование интеграции после развертывания.

Корпоративные операции

корпоративные операции

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

приоритеты. Приоритеты — это демократизация технических решений. Демократизация технических решений перекладывает обязанности, ранее удерживаемые центральным ИТ-отделом, на команды по управлению рабочей нагрузкой. Чтобы достичь этого сдвига в приоритетах, решения становятся менее зависимыми от проверок, проводимых людьми. Этот подход поддерживает автоматизированную проверку, управление и принудительное применение с помощью облачных средств.
Уникальные преимущества: сегментация сред и разделение обязанностей позволяют балансировать между контролем и инновациями. Централизованные операции поддерживают рабочие нагрузки, требующие усиленного соблюдения нормативных требований и стабильных операций, или представляют повышенные риски безопасности. И наоборот, этот подход поддерживает сокращение централизованного контроля над рабочими нагрузками и средами, требующими больше инноваций. Более крупные портфели могут бороться с балансом между контролем и инновациями. Эта гибкость упрощает масштабирование тысяч рабочих нагрузок с сокращением операционных проблем.
Явный недостаток: то, что работало локально, может не работать в условиях корпоративной облачной среды. Этот подход к операциям требует изменений во многих фронтах. Культурные сдвиги в контроле и ответственности часто являются самой большой проблемой. Операционные сдвиги, которые следуют за культурными сдвигами, требуют времени и целенаправленных усилий для их реализации, созревания и стабилизации. Изменения архитектуры могут потребоваться в стабильных рабочих нагрузках, а смены инструментов необходимы для расширения возможностей и поддержки культурных, операционных и архитектурных сдвигов. Эти сдвиги могут потребовать обязательств к основному поставщику облачных служб. Усилия по внедрению, сделанные до этих изменений, могут потребовать значительных изменений, которые выходят за рамки типичных усилий рефакторинга.
риск: Этот подход требует руководящей приверженности стратегии изменений. Кроме того, он требует от технических команд обязательство преодолеть кривые обучения и обеспечить необходимые изменения. Долгосрочное сотрудничество между бизнесом, CCoE и центральным ИТ-отделом, а также группами рабочей нагрузки требуется, чтобы увидеть долгосрочные преимущества.
руководство. Параметры целевой зоны Azure определяются как корпоративного масштаба. Эти настройки предоставляют образцы реализации для демонстрации того, как технические изменения осуществляются с использованием облачно-нативных инструментов в Azure. Подход корпоративного масштаба направляет команды через операционные и культурные сдвиги, необходимые для полного использования возможностей этих внедрений. Этот же подход может адаптировать эталонную архитектуру для настройки среды в соответствии с стратегией внедрения и ограничениями соответствия. При реализации корпоративного масштаба методологии управления и администрирования могут помочь определить процессы. Эти процессы могут расширить возможности соответствия требованиям и операций в соответствии с вашими операционными потребностями.

Преимущества корпоративных операций

управление затратами: центральные команды осуществляют оптимизацию в рамках всех портфелей и обеспечивают ответственность отдельных команд за более глубокую оптимизацию их собственной рабочей нагрузки. Группы, ориентированные на рабочую нагрузку, могут принимать решения и обеспечивать ясность, когда эти решения имеют негативный эффект затрат. Центральные команды и команды по управлению рабочими нагрузками разделяют ответственность за решения о затратах на надлежащем уровне.
Ответственность: центральные команды используют облачные нативные инструменты для определения, принудительного применения и автоматизации ограничений. Усилия команды по управлению рабочей нагрузкой ускоряются с помощью автоматизации и методов CCoE. Команды по рабочей нагрузке наделены полномочиями для продвижения инноваций и принятия решений в рамках этих рамок.
стандартизация: централизованные ограничители и основные услуги создают последовательность во всех средах.
поддержка операций. Рабочие нагрузки, требующие централизованной поддержки операций, разделяются на среды со стабильными элементами управления. Сегментация и разделение обязанностей позволяют группам рабочей нагрузки принимать ответственность за поддержку операций в собственных выделенных средах. Автоматизированные облачные собственные средства обеспечивают минимальные базовые показатели операций для всех сред с централизованной операционной поддержкой.
опыт: централизованные основные службы, такие как безопасность, риск, управление и операции, обеспечивают надлежащий центральный опыт. Четкие процессы и ограничения обучают и дают возможность командам по рабочей нагрузке принимать более подробные решения. Эти решения расширяют влияние централизованных экспертов, не требуя линейного масштабирования персонала с помощью технологии.
проектирование посадочной зоны: проектирование посадочной зоны учитывает потребности портфеля, создавая четкие границы безопасности, управления и подотчетности. Эти границы необходимы для работы рабочих нагрузок в облаке. Методы сегментации вряд ли будут похожи на ограничения, созданные предыдущими проектами центров обработки данных. В корпоративных операциях дизайн целевой зоны менее сложный, что ускоряет масштабирование и снижает барьеры для возможности самообслуживания.
Базовые утилиты: Базовые утилиты размещаются в отдельных централизованно контролируемых подписках, известных как основа платформы. Затем центральные инструменты подаются в каждую посадочную зону в качестве служебных служб. Разделение основных утилит от посадочных зон обеспечивает максимальную согласованность и экономию масштаба. Эти служебные программы также создают четкие различия между централизованно управляемыми обязанностями и обязанностями, связанными с уровнем рабочей нагрузки.
Разделение обязанностей: четкое разделение обязанностей между базовыми коммунальными услугами и целевыми зонами является одним из самых больших преимуществ в подходе к операциям. Облачные инструменты и процессы поддерживают доступ и надлежащий баланс управления между централизованным командам и командами рабочей нагрузки. Этот подход основан на требованиях отдельных посадочных зон и рабочих нагрузок, размещенных в сегментах этих зон.

Недостатки корпоративных операций

управление затратами: центральные команды более зависимы от команд, отвечающих за рабочие нагрузки, чтобы вносить изменения в рабочие зоны. Этот сдвиг создает риск для потенциальных перерасходов бюджета и замедления изменения размера фактических расходов. Процессы контроля затрат, четкие бюджеты, автоматизированный контроль и регулярные проверки должны быть внедрены с самого начала, чтобы избежать неожиданных расходов.
Обязанности. Операции предприятия требуют более высоких культурных и операционных стандартов. Эти требования обеспечивают четкость обязанностей и подотчетности между центральными и рабочими группами.
Традиционные процессы управления изменениями или советы по оценке изменений (CABs) могут не поддерживать темп и баланс, необходимые для этой операционной модели. Эти процессы отражаются в автоматизации процессов и процедур, которые безопасно масштабируют внедрение облака.
Отсутствие приверженности изменению материализуется в первую очередь в переговорах и выравнивании обязанностей. Неспособность выравнивать изменения ответственности является признаком того, что центральные ИТ-операционные модели могут потребоваться во время краткосрочных усилий по внедрению облака.
стандартизации: отсутствие инвестиций в централизованные ограничения или автоматизацию создает риски для стандартизации, что становится труднее преодолеть с помощью процессов ручной проверки. Операционные зависимости между рабочими нагрузками в платформах развертывания и общих службах создают более высокий риск. Эти риски расширяются от стандартизации во время циклов обновления или будущих версий базовых служебных программ. Во время пересмотра фундамента платформы требуется проведение усовершенствованных или даже автоматизированных тестов для всех поддерживаемых целевых площадок и размещаемых на них рабочих нагрузок.
поддержка операций. Базовые показатели операций, обеспечиваемые через автоматизацию и централизацию, могут быть достаточными для рабочих нагрузок с низкой степенью воздействия или низкой критичностью. Но команды рабочей нагрузки или другие формы выделенных операций могут потребоваться для сложных или критически важных рабочих нагрузок. Если это так, это может создать сдвиг в бюджетах операций, требуя от бизнес-подразделений предоставить операционные расходы этим формам расширенных операций. Если от центрального ИТ-отдела требуется поддерживать единоличную ответственность за затраты на операции, может быть сложно реализовать корпоративные операции.
Экспертиза: Членам центральной ИТ-команды может потребоваться развивать экспертизу в автоматизации центральных элементов управления, которые ранее выполнялись вручную. Кроме того, эти команды могут разработать навыки для подходов инфраструктуры как кода к определению среды, а также понять ветвление, слияние и конвейеры развертывания. Как минимум, команде автоматизации платформы могут потребоваться навыки принятия решений, чтобы понять решения, принятые облачным центром превосходства или центральными операционными группами. Командам, работающим с рабочей нагрузкой, может потребоваться разработка более глубоких знаний, связанных с элементами управления и процессами, управляющими их решениями.
проектирование посадочной зоны: проектирование посадочной зоны зависит от базовых утилит. Команды по нагрузке должны понять, что входит в проектирование, а что запрещено включать. Это понимание может помочь избежать дублирования усилий, ошибок или конфликтов. Чтобы создать гибкость, вы можете включать процессы исключений в проекты целевой площадки.
Фундаментальные утилиты: Централизация фундаментальных утилит требует времени. Эти служебные программы в конечном итоге рассматривают варианты и разрабатывают решения, которые могут масштабироваться в соответствии с различными планами внедрения. Возможны задержки в начале внедрения. Задержки в долгосрочной перспективе могут быть компенсированы благодаря ускорению и предотвращению блокировки на более поздних этапах процесса.
Разделение обязанностей. Обеспечение четкого разделения обязанностей требует зрелых процессов управления идентификацией. Возможно потребуется больше работы по обслуживанию, связанной с правильным согласованием пользователей, групп, процессами присоединения и отключения. Возможно, потребуется внедрить новые процессы для поддержки доступа в режиме Just-In-Time через предоставление повышенных привилегий.

Распределенные операции

распределенных операций

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

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

Приоритеты: Интеграция нескольких существующих операционных моделей.
Переходное состояние с акцентом на перемещение всей организации в одну из ранее упомянутых операционных моделей.
Долгосрочный операционный подход, когда организация слишком велика или слишком сложна для соответствия одной операционной модели.
Уникальные преимущества: интеграция общих элементов операционной модели из каждого подразделения. Этот подход создает механизм для группировки операционных единиц в иерархию, которая помогает им делать операции более зрелыми с использованием последовательных повторяющихся процессов.
Явный недостаток: Согласованность и стандартизация среди нескольких операционных моделей трудно поддерживать на протяжении продолжительного времени. Этот операционный подход требует глубокого понимания портфеля и того, как работают различные сегменты портфеля технологий.
риск: отсутствие приверженности основной операционной модели может привести к путанице между командами. Используйте эту операционную модель, когда невозможно согласовать с единой операционной моделью.
Руководство. Начните с тщательного обзора портфеля, который использует подход, описанный в статьях бизнес-ориентации. Попробуйте сгруппировать портфель по операционной модели государства (децентрализованной, централизованной или корпоративной).
Разработка иерархии групп управления, которая отражает группировки операционных моделей. Это расположение включает другие организационные шаблоны для региона, бизнес-единицы или других критериев, которые отображают кластеры рабочих нагрузок от наименее к наиболее распространенным категориям.
Оцените согласование рабочих нагрузок с операционными моделями, чтобы найти наиболее подходящий кластер операционных моделей для начала работы. Следуйте указаниям, сопоставленным с операционной моделью для всех рабочих нагрузок в иерархии узлов и групп управления.
Используйте методики управления и управления, чтобы найти общие корпоративные политики, включая необходимые методики управления операционными ресурсами в различных точках иерархии. Применение общих политик Azure для автоматизации общих корпоративных политик.
При тестировании политик Azure с различными развертываниями попытайтесь переместить их выше в иерархии групп управления. Политики можно применять ко многим рабочим нагрузкам, которые могут находить общие и различные потребности в операциях.
С течением времени этот подход может помочь определить модель, масштабируемую в различных операционных моделях. Этот подход также может объединить команды с помощью набора общих политик и процедур.

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

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

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

терминология операционной модели

Узнайте, как посадочная зона предоставляет основной строительный блок для любой среды адаптации облака.

Что такое посадочная зона?

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