Организация процессов управления операциями

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

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

Организация базового процесса для проверки операционной пригодности

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

Операционная пригодность в корпорации Microsoft

С самого начала многие команды в корпорации Майкрософт принимали участие в разработке платформы Azure. Обеспечить качество и согласованность для проекта такого размера и сложности — задача нетривиальная. Вам нужен надежный процесс для регулярного перечисления и реализации фундаментальных нефункциональных требований.

Процессы, описанные в этой статье, созданы на основе процессов, реализованных корпорацией Майкрософт.

Общие сведения о ролях и рабочих моделях

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

• Центральное ИТ-подразделение/облачный центр инноваций (CCoE). Эта централизованная технологическая функция отвечает за настройку, эксплуатацию, управление и безопасность всех технологических ресурсов в портфеле технологий.
• Операции в облаке. Функция централизованной технологической организации, которая управляет работоспособностью и операциями в портфеле технологий. Она отвечает за то, чтобы процесс выполнялся без сбоев, чтобы каждая смежная роль в процессе располагала необходимыми инструментами и чтобы каждая из последующих ролей несла ответственность за достижение ожидаемых результатов этого процесса.
• Стратегия работы в облаке. Эта группа предоставляет сведения о бизнесе для определения и приоритизации обязательств, чтобы соблюдать операционные требования различных рабочих нагрузок. Носитель этой роли также сравнивает стоимость устранения рисков с влиянием на коммерческую деятельность, принимая окончательное решение по применению мер исправления.
• Группа по обеспечению рабочей нагрузки. Отвечает за разработку и выполнение отдельных рабочих нагрузок, которые сопоставляются с конкретными поддерживающими приложениями, службами и инфраструктурой, локальной или облачной. Для этой роли необходимо отличное знание архитектуры рабочей нагрузки.

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

• Централизованные операции. Центральное ИТ-подразделение несет полную ответственность за операции. Владельцы рабочих нагрузок могут задавать входные данные для операций и настройки, но не имеют доступа для изменения рабочей среды. Только центральное ИТ-подразделение и группа по операциям в облаке могут вносить оперативные изменения для улучшения операционной пригодности.
• Децентрализованные операции. Группы по обеспечению рабочей нагрузки полностью отвечают за операции. Обычно для этого используется сформированный конвейер CI/CD и служба автоматизации DevOps. В этой модели отсутствует централизованная поддержка конфигураций, операций, управления и безопасности. Этот подход к операциям не входит в сферу Cloud Adoption Framework. Руководство по работе с этой операционной моделью см. в разделе Azure Well-Architected Framework.
• Корпоративные операции. Облачный центр инноваций отвечает за операции. Каждая группа по операциям в облаке и по обеспечению рабочей нагрузки несет ответственность за конкретные аспекты операционной пригодности.

Цель проверки

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

• Базовый план операций (или расширенный базовый план). Оценивает операционную пригодность во всех развернутых ресурсах независимо от их функций. Это широкое представление операций позволяет вносить значительные изменения и оказывать большое влияние, но его возможности ограничены из-за невозможности просматривать архитектуру отдельных рабочих нагрузок. Базовый план операций должен охватывать все ресурсы, развернутые в облаке, при условии регулярной поддержки команды по операциям в облаке. В некоторых средах для удовлетворения потребностей расширенного базового плана может потребоваться более высокий уровень операционной поддержки.
• Операции платформы. Эта служба оценивает операционную пригодность централизованных технологических платформ. Это более точное представление операций, так как в нем учитывается архитектура платформы и влияние изменений в решении операционную пригодность. Изменения центральных технологических платформ могут оказать широкое влияние на поддерживаемые рабочие нагрузки. Всем критически важным платформам должна быть обеспечена специальная поддержка центрального ИТ-подразделения.
• Операции рабочей нагрузки. Эта служба оценивает операционную пригодность отдельной рабочей нагрузки. Это наиболее точное представление операций, его следует учитывать при улучшениях операционной пригодности, требующих внесения изменений в архитектуру рабочей нагрузки. Операции рабочей нагрузки должны соответствовать принципам Azure Well-Architected Framework. Всем критически важным рабочим нагрузкам с активным циклом DevOps должна быть предоставлена специальная поддержка от группы по обеспечению рабочей нагрузки.

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

Процесс проверки операционной пригодности

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

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

Этап предварительных требований

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

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

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

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

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

   Следует также учитывать зависимости между локальными службами и службами Azure. В примере с покупательской корзиной службу управления складскими запасами можно разместить локально и настроить ее на прием данных, которые вводят сотрудники реального склада. При этом служба может хранить данные не в локальной среде, а в службе Azure, например в службе хранилища Azure, или в базе данных, например Azure Cosmos DB.

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

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

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

Этап проверки служб

Этап проверки служб лежит в основе проверки операционной пригодности. Он предусматривает следующие этапы.

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

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

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

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

Собрания по проверкам

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

Сам процесс и проведение совещаний следует адаптировать к конкретным потребностям. В качестве отправной точки рекомендуется учитывать следующие моменты:

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

Рекомендуемые ресурсы

• Автоматическое управление Azure. Автоматическое управление Azure автоматически отслеживает операционную пригодность согласно базовому плану операций и автоматизирует применение различных стратегий исправления в портфеле.
• Помощник по Azure. Помощник по Azure предоставляет персонализированные рекомендации на основе использования и конфигураций, позволяющие оптимизировать ресурсы. По умолчанию это средство предоставляет рекомендации в рамках подписки для улучшения базового плана операций. Его также можно использовать более прицельно, чтобы определить возможности по улучшению технических платформ или отдельных рабочих нагрузок.
• Microsoft Azure Well-Architected Framework. Предоставляет рекомендации по улучшению операций рабочей нагрузки или по управлению децентрализованными операциями.