Общие сведения о функциях центральной ИТ-команды

  • Статья

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

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

Внимание!

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

Следующие дисциплины и структуры охватывают требования для настройки централизованных ИТ-функций:

  • Имеющаяся центральная ИТ-команда
  • Корпоративные архитекторы
  • ИТ-операции
  • система управления ИТ;
  • ИТ-инфраструктура;
  • сеть;
  • Идентификация
  • Виртуализация
  • Непрерывность бизнес-процессов и аварийное восстановление
  • Владельцы приложений в сфере информационных технологий

Предупреждение

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

Основные обязанности

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

Как правило, ваша команда регулярно выполняет следующие задачи:

Стратегические задачи

Технические задачи

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

Частота собраний

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

Риски, с которыми может столкнуться центральная ИТ-команда

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

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

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

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

Исключения

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

Работа в исключительных случаях

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

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

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

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

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

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

  1. Классификации: Так как команда по внедрению облака находится на ранних стадиях создания нового решения и не имеет конфиденциальных данных или критически важных потребностей в поддержке, они классифицируют ресурсы в среде как ресурсы с низким риском и некритические. Эффективная классификация показывает зрелость в центральной ИТ-команде. Классификация всех ресурсов и сред позволяет определять политики более четко.
  2. Согласование. Только классификации недостаточно. Компания реализует общие службы для согласованной работы с конфиденциальными и критически важными ресурсами. Изменение правил ставит под угрозу политики управления и соответствия требованиям, предназначенные для активов, которым требуется дополнительная защита. Расширение возможностей внедрения не должно происходить ценой стабильности, безопасности и управления. Это приводит к переговорам с командой по внедрению, чтобы ответить на конкретные вопросы. Может ли команда DevOps под руководством бизнеса обеспечить управление операциями для этой среды? Требуется ли этому решению прямой доступ к другим внутренним ресурсам? Если команда по внедрению облачных технологий устраивает компромиссы, может быть возможен входящий трафик.
  3. Изоляции: Так как бизнес обеспечивает собственное текущее управление операциями, а решение не зависит от прямого трафика к другим внутренним ресурсам, решение затем оцепляется в новой подписке. Эта подписка также создается на отдельном узле в иерархии новой группы управления.
  4. Автоматизация. Другой признак зрелости в этой команде — принципы автоматизации. Команда использует Политику Azure, чтобы автоматизировать принудительное применение политик. Она также пользуется Azure Blueprints, чтобы автоматизировать развертывание общих компонентов платформы и принудительно применять определенный план использования удостоверений. Политики и шаблоны для этой подписки и для любых других в новой группе управления немного отличаются. Политики, блокирующие пропускную способность входящего трафика, отменяются. Они заменяются требованиями к маршрутизации трафика через подписку общих служб, как и любой входящий трафик, чтобы обеспечить изоляцию трафика. Эта подписка недоступна для средства управлении локальными операциями, поэтому для него больше не нужны агенты. Все другие проверочные механизмы для управления, требуемые другими подписками в иерархии групп управления, по-прежнему принудительно применяются, чтобы обеспечивать необходимый уровень проверки.

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

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

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

Дополнительные сведения