Критичность бизнес-задач в управлении облаком

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

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

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

Шкала критичности

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

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

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

Важность точной оценки критичности

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

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

Выбор уровня критичности по умолчанию

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

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

Проверка требований по соответствию для эксплуатации

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

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

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

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

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

Использовать шаблон

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

1. Запишите уровень критичности в книге Scale.
2. Обновите каждую рабочую нагрузку в книге Example или Clean Template, чтобы отразить уровень критичности по умолчанию в столбце Criticality.
3. Организации важно вносить сюда правильные значения, отражая любые отклонения от уровня критичности по умолчанию.

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

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