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

Применение принципов проектирования и расширенных операций

  • Статья

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

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

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

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

Расширенные операции

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

Усовершенствованные операции

Улучшенный базовый план управления

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

Специализация управления

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

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

Области специализации управления

Существуют две области специализации:

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

Центральное ИТ-подразделение или облачный центр инноваций (CCoE)

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

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

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

Естественное согласование ролей в CCoE происходит следующим образом:

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

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

Процессы специализации управления

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

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

Улучшение проектирования системы

Улучшение проектирования системы — это самый эффективный подход к улучшению операций любой распространенной платформы. Благодаря улучшениям структуры системы можно повысить стабильность и уменьшить количество прерываний бизнес-процессов. Структура отдельных систем выходит за рамки представления среды, рассматриваемого в рамках Cloud Adoption Framework.

Дополнением к этой платформе служит Microsoft Azure Well-Architected Framework. Здесь представлены основные принципы повышения качества платформы или конкретной рабочей нагрузки. Решение ориентировано на улучшение в пяти базовых аспектах эффективности архитектуры:

  • Оптимизация затрат: Управляйте затратами, чтобы повысить рентабельность.
  • Эффективность операционных процессов. Придерживайтесь рабочих процессов, обеспечивающих функционирование системы в рабочей среде.
  • Уровень производительности. Масштабируйте системы в соответствии с изменениями нагрузки.
  • Надежность. Разрабатывайте системы, способные к восстановлению и возобновлению работы после сбоев.
  • Безопасность. Обеспечьте защиту приложений и данных от угроз.

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

Чтобы улучшить структуру систем, ознакомьтесь с дополнительными сведениями о Microsoft Azure Well-Architected Framework. По мере улучшения структуры системы вернитесь к этой статье, чтобы найти новые возможности для улучшения и масштабирования этих улучшений в среде.

Автоматическое устранение

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

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

Рекомендации по автоматическому исправлению см. в статье Use an alert to trigger an Azure Automation runbook (Использование оповещения для активации runbook службы автоматизации Azure).

Масштабирование решения с помощью каталога служб

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

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

Сведения о публикации в каталоге услуг см. в этой серии статей.

Постоянное совершенствование

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