Бизнес-обязательства в сфере управления облаком

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

Вы можете иметь обязательства, связанные с стабильностью бизнеса, которые оправдывают бизнес-решения. Обязательства по стабильности могут включать соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания) или определенный уровень технической устойчивости. Для большинства рабочих нагрузок требуется только базовый уровень управления облаком. Для других рабочих нагрузок можно потратить два-четыре раза больше на управление облаком по сравнению с базовым уровнем. Вы можете оправдать эту стоимость из-за потенциального влияния перерывов в бизнесе.

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

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

Определение надлежащей приверженности

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

Когда ваш бизнес устанавливает обязательство, определите, как выровнять следующие аспекты.

• Необходимые условия для ИТ-операций
• Ответственность за управление
• Облачная аренда
• Факторы, связанные с нематериальными затратами
• Рентабельность инвестиций (ROI) избегания потери
• Проверка уровня управления

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

Определение предварительных требований для ИТ-операций

Руководство по управлению Azure описывает средства управления Azure. Прежде чем бизнес принимает обязательства, ИТ-служба должна определить приемлемые базовые показатели управления уровня "стандартный", которые будут применяться ко всем управляемым рабочим нагрузкам. Для каждой управляемой рабочей нагрузки в ИТ-портфеле ИТ-служба может вычислить стандартные затраты на управление, основанные на ядрах ЦП, пространстве на диске и других переменных, связанных с ресурсами. ИТ-служба также может оценить составную цель уровня обслуживания (SLO) для каждой рабочей нагрузки на основе архитектуры.

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

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

Выбор модели ответственности

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

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

Для управления облачной средой можно реализовать различные модели.

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

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

• Централизованная модель ответственности: для бизнеса может потребоваться центральная МОДЕЛЬ ИТ-отдела , если у вас есть требования к соответствию, технические сложности или некоторые модели общих служб. В централизованной ИТ-модели ИТ ит-отдел выполняет свои обязанности по управлению операциями.

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

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

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

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

Управление облачным клиентом

Как правило, можно упростить управление ресурсами при их расположении в одном клиенте. Но вам может потребоваться поддерживать несколько клиентов. Дополнительные сведения о том, почему вам может потребоваться мультитенантная среда Azure, см. в статье "Централизация операций управления с помощью Azure Lighthouse".

Рассмотрите факторы мягкой стоимости

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

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

Ниже приведены некоторые примеры факторов мягкой стоимости:

• Ежедневное использование рабочей нагрузки советом директоров или генеральным директором.

• Использование рабочих нагрузок основными x % клиентов, что приводит к росту дохода в других областях.

• Влияние на удовлетворенность сотрудников.

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

Расчет рентабельности инвестиций в средства предотвращения убытков

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

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

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

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

Повышение уровня управления

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

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

Оценка сбоя

Составной SLO — это соглашение об уровне обслуживания, основанное на развертывании каждого ресурса в рабочей нагрузке. Составное поле SLO приводит к предполагаемому сбою, который помечен Est. Outage в книге. Чтобы вычислить предполагаемый сбой в часах в год без использования книги, примените следующую формулу:

Предполагаемый сбой = (1 - составной процент SLO) × количество часов в год

В книге используется значение по умолчанию — 8760 часов в год.

Влияние стандартных убытков

Стандартное влияние потери прогнозирует финансовое влияние любого сбоя, предполагая, что предполагаемый прогноз сбоя оказывается точным. Стандартное влияние потери отмечено Standard Impact в книге. Чтобы сделать этот прогноз без использования книги, примените следующую формулу:

стандартное влияние = предполагаемый простой при уровне доступности 99,9 × влияние временной величины

Значение служит базовым показателем стоимости, если заинтересованные лица бизнеса инвестируют в более высокий уровень управления.

Влияние составного SLO

Влияние составного SLO обеспечивает обновленное финансовое влияние на основе изменений соглашения об уровне обслуживания об уровне обслуживания. Используйте этот расчет, чтобы сравнить прогнозируемые финансовые последствия обоих вариантов. Влияние составного SLO отмечено Commitment level impact в книге. Чтобы вычислить это прогнозируемую влияние без электронной таблицы, примените следующую формулу:

Влияние составного SLO = предполагаемое сбой × влияние времени на значение времени

Значение представляет потенциальные потери, которые должны предотвратить измененный уровень обязательств и новый составной SLO.

Базис сравнения

Поле "Сравнение" оценивает стандартное влияние и влияние составного SLO, чтобы определить объем возвращаемой прибыли в поле годовой рентабельности .

Рентабельность предотвращения убытков

Если затраты на управление рабочей нагрузкой превышают потенциальные потери, предлагаемые инвестиции в управление облачными клиентами могут не стоить. Чтобы сравнить возвращаемый возврат по избеганию потери, см. метку столбца Annual ROI. Чтобы вычислить этот столбец самостоятельно, используйте следующую формулу:

Возврат к отказу от потери = (база сравнения - (ежемесячная стоимость × 12) ) ÷ (ежемесячная стоимость × 12)

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

Проверка обязательства

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

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

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