Операции платформы при управлении облаком
Базовый план управления облаком, распространяющийся на инвентаризацию и видимость, соответствие операционным требованиям и защиту и восстановление, может обеспечить достаточный уровень управления облаком для большинства рабочих нагрузок в портфеле ИТ-услуг. Но этого базового показателя редко бывает достаточно для поддержки полного портфеля. Эта статья посвящена наиболее распространенному следующему этапу управления облаком — операциям с портфелем.
При быстром изучении ресурсов в портфеле ИТ выделяются существующие шаблоны для поддерживаемых рабочих нагрузок. В этих рабочих нагрузках существуют общие платформы. Платформы могут сильно различаться в зависимости от прошлых технических решений в компании.
В некоторых организациях существует большая зависимость от SQL Server, Oracle или других платформ данных с открытым кодом. В других организациях общей может быть приверженность платформам размещения виртуальных машин или контейнеров. Третьи могут иметь общую зависимость от приложений или систем планирования ресурсов предприятия (ERP), таких как SAP или Oracle.
Когда вы понимаете эти общие особенности, ваша команда управления облаком может специализироваться на более высоких уровнях поддержки этих приоритетных платформ.
Создание каталога услуг
Цель операций платформы — создать надежные и повторяемые решения, которые будут использоваться командой по внедрению облачных технологий. Затем команда по внедрению облачных технологий может предоставить платформу, которая обеспечивает более высокий уровень бизнес-обязательств. Эти обязательства могут снизить вероятность или частоту возникновения простоев, что повышает надежность. Если произошел сбой системы, обязательство также может помочь уменьшить объем потери данных или время восстановления. Такие обязательства часто включают в себя непрерывные централизованные операции для поддержки платформы.
Поскольку команда управления облаком устанавливает более высокий уровень операционного управления и специализации, связанные с конкретными платформами, они добавляют платформы в растущий каталог служб. Каталог служб обеспечивает самостоятельное развертывание платформы в определенной конфигурации, которая соответствует текущим операциям платформы. Во время беседы по согласованию бизнес-процессов команды по управлению облачными решениями и облачной стратегии могут предложить решения каталога служб для бизнеса. Решения каталога служб повышают надежность, время бесперебойной работы и обязательства по восстановлению в рамках управляемого повторяемого процесса.
Для справки: некоторые организации называют каталог услуг, находящийся на раннем этапе создания, утвержденным списком. Основное отличие заключается в том, что каталог услуг поставляется с текущими операционными обязательствами из облачного центра компетенции (CCoE). Утвержденный список аналогичен. Он предоставляет предварительно утвержденный список решений, которые команда может использовать в облаке. Но обычно не существует операционного преимущества, связанного с приложениями в списке утвержденных.
Как и в споре между централизованным ИТ-отделом и центром CCoE, разница заключается в приоритетах. Каталог услуг создан с благими намерениями, но накладывает операционные, управленческие ограничения и ограничения безопасности, которые ускоряют внедрение инноваций. Утвержденный список препятствует инновациям до тех пор, пока не будут переданы операции, соответствие требованиям и шлюзы безопасности для решения. Оба решения работоспособны, но требуют от компании принятия взвешенных решений по расстановке приоритетов: инвестировать больше в инновации или в соответствие нормативным требованиям.
Создание каталога услуг
Управление облаком редко бывает успешным при формировании каталога услуг в изолированном режиме. Для правильной разработки каталога требуется взаимодействие с централизованной ИТ-командой или центром CCoE. Этот подход, как правило, является наиболее успешным, когда ИТ-организация достигает уровня зрелости CCoE, но его можно будет реализовать раньше.
Когда команда по облачной платформе создает каталог служб в модели CCoE, она создает платформу требуемого состояния. Команды по облачной безопасности и управлению облаком проверяют систему управления и соответствие нормативным требованиям в рамках развертывания. Команда по управлению облаком определяет текущие операции для этой платформы. А команда по автоматизации в облаке упаковывает платформу для масштабируемого и повторяемого развертывания.
После упаковки команда по управлению облаком может добавить платформу в постоянно расширяющийся каталог услуг. После этого команда по внедрению облачных технологий использует пакет или другие элементы в каталоге во время развертывания. После запуска решения в производственной среде компания получает дополнительные преимущества в виде улучшенного операционного управления и сокращения сбоев в работе.
Примечание
Создание каталога услуг требует значительного объема времени и усилий со стороны нескольких команд. Использование каталога служб или утвержденного списка в качестве механизма ограничения замедляет инновации. Если инновации являются приоритетом, разрабатывайте каталоги служб параллельно с другими усилиями по внедрению.
Определение собственных операций платформы
Хотя средства и процессы управления могут улучшить операции платформы, этого часто недостаточно для достижения требуемого состояния стабильности и надежности. Реальные операции платформы требуют сосредоточения внимания на принципах совершенства архитектуры. Когда платформа оправдывает значительные инвестиции в операционную деятельность, рассмотрите следующие пять принципов, прежде чем включать платформу в любого каталог услуг.
- Надежность. Разрабатывайте системы, способные к восстановлению и возобновлению работы после сбоев.
- Безопасность. Обеспечьте защиту приложений и данных от угроз.
- Оптимизация затрат: Управляйте затратами, чтобы повысить рентабельность.
- Эффективность операционных процессов. Придерживайтесь рабочих процессов, обеспечивающих функционирование системы в рабочей среде.
- Уровень производительности. Масштабируйте системы в соответствии с изменениями нагрузки.
Microsoft Azure Well-Architected Framework предоставляет подход к оценке конкретных рабочих нагрузок для соблюдения этих принципов, чтобы улучшить общую работу. Эти принципы можно применять как к операциям платформы, так и к операциям рабочей нагрузки.
Начало работы с конкретными платформами
Платформы, рассматриваемые следующих разделах, являются общими для типичных клиентов Azure, и они могут легко обосновать инвестиции в операции платформы. Когда команды по управлению облаком разрабатывают требования к операциям платформы или полный каталог услуг, они обычно начинают именно с этих платформ.
Операции с данными PaaS
Данные часто являются первой платформой, требующей инвестиций в операций платформы. Когда данные размещаются в среде платформы как услуги (PaaS), заинтересованные лица, как правило, запрашивают целевую точку восстановления (RPO) с низким значением, чтобы минимизировать потерю данных. В зависимости от характера приложения они могут также запросить сокращение времени восстановления (RTO). В любом случае архитектура, поддерживающая решения для работы с данными на основе PaaS, может легко обеспечить некоторый повышенный уровень поддержки управления.
В большинстве сценариев затраты на улучшение обязательств по управлению легко оправданы, даже для приложений, которые не являются критически важными. Это усовершенствование операций платформы настолько распространено, что многие команды по управлению облаком рассматривают его скорее как улучшение базовых показателей, а не как истинное улучшение операций платформы.
Операции с данными IaaS
Если данные размещаются в традиционном решении "инфраструктура как услуга" (IaaS), усилия по улучшению RPO и RTO могут быть более высокими. Однако желание заинтересованных лиц добиться более высоких обязательств по управлению редко зависит от решения о выборе PaaS или IaaS. В любом случае, понимание фундаментальных различий в архитектуре может побудить организации запросить решения PaaS или обязательства, которые соответствуют возможностям, доступным в решениях PaaS. Рассмотрите возможность модернизации любых платформ данных IaaS в качестве первого шага в работе платформы.
Когда модернизация не представляется возможной, команды по управлению облаком обычно отдают предпочтение платформам данных на базе IaaS в качестве первой необходимой услуги в каталоге услуг. Предоставление организации возможности выбора между автономными серверами данных и кластерными решениями с высокой доступностью данных значительно упрощает процесс принятия деловых обязательств. Базовое понимание операционных улучшений и увеличения затрат помогает бизнесу принимать наилучшее решение для своих бизнес-процессов и вспомогательных рабочих нагрузок.
Другие общие операции платформы
Помимо платформ данных, распространенной платформой для улучшения операций обычно являются компьютеры виртуальных машин. Команды по управлению облачными платформами и облачными решениями чаще всего инвестируют в улучшения узлов VMware или контейнерных решений. Это может повысить стабильность и надежность компьютеров, поддерживающих виртуальные машины, которые, в свою очередь, обеспечат эффективное выполнение рабочих нагрузок. Правильные операции на одном компьютере или контейнере могут улучшить RPO или RTO нескольких рабочих нагрузок. Такой подход создает улучшенные бизнес-обязательства, но распределяет инвестиции. Улучшение обязательств и снижение затрат в совокупности значительно облегчает обоснование совершенствований, касающихся управления облаком и операций платформы.
Дальнейшие действия
Одновременно с улучшением операций платформы команды по управлению облаком также уделяют внимание совершенствованию операций рабочих нагрузок для 20 или менее процентов производственных рабочих нагрузок.