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

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

  • Статья

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

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

Внимание

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

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

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

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

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

Ключевые обязанности

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

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

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

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

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

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

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

Риски, связанные с Центральной ИТ-командой

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

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

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

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

Исключения

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

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

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

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

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

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

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

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

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

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

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

  4. Автоматизация: принципы автоматизации являются еще одним признаком зрелости для этой команды. Команда использует Политику Azure, чтобы автоматизировать принудительное применение политик. Кроме того, они используют инфраструктуру в качестве кода (IaC) для автоматизации развертывания общих компонентов платформы и обеспечения соблюдения определенных базовых показателей удостоверений. Политики и шаблоны немного отличаются для этой подписки и для всех остальных в новой группе управления. Политики, которые блокируют пропускную способность входящего трафика, удаляются. Затем политики заменяются требованиями для маршрутизации трафика через подписку общих служб, например трафик входящего трафика, чтобы обеспечить изоляцию трафика. Так как локальные средства управления операциями не могут получить доступ к этой подписке, агенты для этого средства больше не требуются. Все остальные меры управления, необходимые для других подписок в иерархии групп управления, по-прежнему применяются, что обеспечивает достаточное количество охранников.

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

Следующие шаги

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

См. также: