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

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

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

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

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

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

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

• Стратегические приоритеты или мотивы. Каждая операционная модель предоставляет типичные стратегические мотивы для внедрения облака. Но некоторые операционные модели упрощают конкретные мотивы.

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

Согласование ответственности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Преимущества операций предприятия

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

Недостатки операций предприятия

• Управление затратами. Центральные группы более зависимы от команд, ответственных за рабочие нагрузки, при внесении изменения в целевых зонах. Это создает риск потенциального перерасхода бюджета и более медленного определения размера фактических затрат. Во избежание непредвиденных расходов требуются процессы контроля затрат, четко определенные бюджеты, автоматизированные элементы управления и регулярные проверки.
• Обязанности. Операции предприятия предъявляют более высокие требования к культуре и организации. Эти требования обеспечивают ясность в сферах ответственности центральной команды и команд, ответственных за рабочие нагрузки.
• Традиционные процессы управления изменениями или советы по изменениям могут не обеспечивать нужную скорость и баланс для этой операционной модели. Эти процессы отражаются в автоматизации процессов и процедур безопасного масштабирования внедрения облака.
• Отсутствие приверженности переменам материализуется в первую очередь в переговорах и согласовании обязанностей. Невозможность согласовать перенос обязанностей указывает на то, что в краткосрочной перспективе в ходе внедрения облачных технологий могут потребоваться операционные модели, предусматривающие централизацию ИТ.
• Стандартизация. Недостаток инвестиций в централизованные ограничения или автоматизацию создает риски для стандартизации, которые еще сложнее устранить посредством процессов проверки вручную. Операционные зависимости между рабочими нагрузками в целевых зонах и общих службах создают еще большие риски. Эти риски начинаются со стандартизации во время циклов обновления или выпуска будущих версий базовых средств. Во время пересмотра базовой платформы требуется улучшенное или даже автоматизированное тестирование для всех поддерживаемых целевых зон и размещенных в них рабочих нагрузок.
• Поддержка операций. Базовые показатели операций, предоставляемые посредством автоматизации и централизованных операций, могут быть достаточными для рабочих нагрузок с низким уровнем влияния или низкой критичностью. Но для сложных или критически важных рабочих нагрузок могут потребоваться команды рабочей нагрузки или другие формы выделенных операций. Если это так, это может привести к сдвигу в операционных бюджетах, требуя, чтобы подразделения предоставляли операционные расходы этим формам расширенных операций. Если центральные ИТ-отделы должны поддерживать единоличную ответственность за затраты на операции, корпоративные операции могут оказаться трудными для реализации.
• Опыт. Для разработки опыта в автоматизации центральных элементов управления, ранее предоставляемых с помощью ручных процессов, может потребоваться специалисты центральных ИТ-групп. Кроме того, этой команде может быть необходимо повысить квалификацию в области подходов "инфраструктура как код" к определению среды и изучить принципы работы конвейеров ветвления, слияния и развертывания. По крайней мере, команде автоматизации платформы могут потребоваться навыки принятия решений, чтобы понять решения, принятые облачным центром передового опыта или центральными операционными группами. Командам, ответственным за рабочие процессы, может потребоваться расширить свои знания, касающиеся элементов управления и процессов, которыми они руководствуются при принятии решений.
• Проектирование целевой зоны. Структура целевых зон зависит от базового оборудования. Команды рабочей нагрузки должны понимать, что входит в проект и что запрещено включать. Такое понимание может помочь избежать дублирования усилий, ошибок или конфликтов. Для обеспечения гибкости можно учитывать процессы исключений в проектах целевых зон.
• Базовые служебные программы. Централизация базовых служебных программ требует времени. В итоге необходимо рассмотреть различные варианты и разработать решения, которые могут масштабироваться в соответствии с различными планами внедрения. На ранних этапах внедрения возможны задержки. Они могут быть скомпенсированы в долгосрочной перспективе благодаря ускорению процессов и устранению препятствий на более поздних этапах.
• Разделение обязанностей. Для четкого разделения обязанностей требуются развитые процессы управления идентификацией. Возможно, будет выполняться дополнительное обслуживание, связанное с правильным согласованием пользователей, групп, а также действиями по подключению и отключению. Возможно, потребуется внедрить новые процессы, чтобы обеспечить JIT-доступ с помощью повышенных привилегий.

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

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

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

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

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

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

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

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