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

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

Обязательства по обеспечению стабильной работы бизнеса за счет технической устойчивости или другое воздействия соглашения об уровне обслуживания (SLA) — это решение для экономического обоснования. Для большинства рабочих нагрузок в среде достаточно базового уровня управления облаком. Для других рост затрат в 2–4 раза легко обосновать из-за потенциального воздействия любых простоев бизнеса.

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

Определение надлежащего обязательства вместе с бизнес-подразделениями

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

Так как вы определяете обязательства с бизнес-подразделениями, необходимо согласовать несколько ключевых аспектов:

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

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

Необходимые условия для ИТ-операций

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

Совет

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

Совет

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

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

Ответственность за управление

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

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

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

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

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

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

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

Какое подразделение будет отвечать за повседневное управление операциями для этой рабочей нагрузки?

Облачная аренда

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

Будет ли эта рабочая нагрузка размещена в одном клиенте Azure вместе со всеми другими рабочими нагрузками?

Факторы, связанные с нематериальными затратами

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

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

Ниже приведены несколько примеров использования факторов, связанных с нематериальными затратами.

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

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

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

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

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

Соглашается ли бизнес на инвестиции в базовый план для удовлетворения минимальных стандартов облачных операций?

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

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

Повышенные уровни управления: принципы проектирования и каталог услуг

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

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

Совет

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

Предполагаемый простой (часов в год)

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

предполагаемый простой = (1 - процент доступности по составному соглашению об уровне обслуживания) × число часов в году

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

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

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

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

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

Влияние составного соглашения об уровне обслуживания

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

влияние составного соглашения об уровне обслуживания = предполагаемый простой × влияние временной величины

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

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

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

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

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

рентабельность предотвращения убытков = (базис сравнения - (месячные расходы × 12)) ÷ (месячные расходы × 12))

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

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

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

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

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

Варианты инвентаризации и визуального контроля