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

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

Упрощение и стандартизация

Инфраструктура как код (IaC) и средства автоматизации можно объединить с шаблонами для стандартизации инфраструктуры и развертывания приложений. Чтобы облегчить восприятие специфики платформ для конечного пользователя, можно абстрагировать детали платформы, представив варианты в виде понятных соглашений об именовании, например:

• Категории типов ресурсов (высокий объем вычислительных ресурсов, высокая память)
• Категории размера ресурсов (например, размер футболки в небольших, средних и больших размерах)

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

Вы можете отслеживать изменения с помощью средств IaC с функциями обнаружения смещения, которые могут автоматически устранять смещение (GitOps). Примерами этих инструментов являются средства Terraform и облачные средства IaC (например, API кластера, кроссплане, оператор службы Azure версии 2). Вне обнаружения смещения инструментов IaC существуют облачные средства настройки, которые могут запрашивать конфигурации ресурсов, например Azure Resource Graph. Они могут служить двумя преимуществами; для отслеживания изменений за пределами кода инфраструктуры и проверки измененных предварительно настроенных конфигураций. Чтобы избежать слишком жестких ограничений, также можно внедрять допуски в развертывания с заранее определенными пределами. Например, политику Azure можно использовать для ограничения количества узлов Kubernetes, которые может иметь развертывание.

Самоуправляемые или управляемые?

В общедоступных облаках вы можете использовать программное обеспечение как услуга (Saas), платформу как службу (PaaS) или инфраструктуру как услугу (IaaS). Дополнительные сведения о SaaS, PaaS и IaaS см. в обучаемом модуле "Описание типов облачных служб". Службы PaaS предлагают упрощенные возможности разработки, но их модели приложений более жёстко регламентированы. В конечном счете, существует компромисс между простотой использования и контролем, которые необходимо оценить.

Во время разработки платформы оцените и определите приоритеты потребностей вашей организации в службе. Например, независимо от того, создаете ли приложения непосредственно в службе Azure Kubernetes (AKS) или с помощью приложений контейнеров Azure , зависит от ваших требований к службе и от собственного набора возможностей и навыков. То же самое касается служб в стиле функций, таких как Функции Azure или Служба приложений Azure. Контейнерные приложения, функции и служба приложений снижают сложность, а AKS обеспечивает большую гибкость и управление. Более экспериментальные модели приложений, такие как проект инкубации Radius OSS , пытаются обеспечить баланс между двумя, но обычно находятся на более ранних стадиях зрелости, чем облачные службы с полной поддержкой и присутствием в установленных форматах IaC.

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

Общие и выделенные ресурсы

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

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

Реализация стратегий управления

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

• Соответствие начальному развертыванию (справа от начала): Это можно сделать с помощью стандартных шаблонов IaC, доступных через каталоги, с помощью управления разрешениями и политик, чтобы обеспечить развертывание только разрешенных ресурсов и конфигураций.
• Поддержание соответствия требованиям (действуйте правильно): Инструменты управления политиками могут предотвратить или оповещать вас при любых изменениях ресурсов. Помимо основной инфраструктуры, рассмотрите возможность поддержки соответствия требованиям в таких ресурсах, как Kubernetes, вместе с ОС, используемой в контейнерах или виртуальных машинах. Например, может потребоваться применить заблокированную конфигурацию ОС или установить средства программного обеспечения безопасности, такие как групповая политика Windows, SELinux, AppArmor, политика Azure или Kyverno. Если разработчики имеют доступ только к репозиториям IaC, можно добавить рабочие процессы утверждения для просмотра предлагаемых изменений и предотвращения прямого доступа к плоскостям управления ресурсами, таким как Azure.

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

Хотя политики могут обеспечить соблюдение требований, они также могут неожиданно вывести приложения из строя. Поэтому стоит рассмотреть внедрение практики «политика как код» (PaC) при работе в крупном масштабе. В качестве ключевой части вашего подхода правильного начала и поддержания на правильном пути PaC предоставляет:

• Централизованно управляемые стандарты
• Управление версиями для политик
• Автоматическое тестирование и проверка
• Сокращение времени развертывания
• Непрерывное развертывание

PaC может помочь свести к минимуму радиус взрыва потенциально плохой политики с такими возможностями, как:

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

Реализация наблюдаемости для конкретных ролей и ведения журнала

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

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

Чтобы устранить эти проблемы, рассмотрите следующее:

• Стандарты: Применяйте стандарты ведения журнала, чтобы упростить создание и дальнейшее использование стандартных панелей мониторинга, а также упростить процесс интеграции с помощью фреймворка наблюдаемости OpenTelemetry.
• Разрешения: Предоставьте панели мониторинга уровня приложения или группы приложений, используя что-то подобное Grafana , чтобы предоставить свернутые данные для всех заинтересованных лиц, а также средства для доверенных членов групп приложений, чтобы безопасно получить доступ к журналам при необходимости.
• Удерживание: Сохранение журналов и метрик может быть дорогостоящим и может создавать непредвиденные риски или нарушения соответствия требованиям. Задайте значения хранения по умолчанию и опубликуйте их как часть руководства по правильному началу.
• Мониторинг ограничений ресурсов: Группы операций должны иметь возможность определять и отслеживать любые ограничения для заданного типа ресурса. Эти ограничения следует учитывать в шаблонах или политиках IaC с помощью таких средств, как Политика Azure. Затем операции должны проактивно мониторить с помощью панелей мониторинга в таких программах, как Grafana, и развернуть общие ресурсы, там где автоматическое масштабирование невозможно или не включено. Например, отслеживайте количество узлов кластера Kubernetes для определения емкости по мере подключения и изменения приложений со временем. Требуется оповещение, и эти определения должны храниться в виде кода, чтобы их можно было программным способом добавлять в ресурсы.
• Определите ключевые метрики емкости и работоспособности: Мониторьте и оповещайте по ОС и общим ресурсам (например, ЦП, памяти и хранилищам) на предмет нехватки ресурсов, с использованием сбора метрик такими инструментами, как Мониторинг Prometheus или Мониторинг Kubernetes в Azure Monitor. Вы можете отслеживать использование сокетов и портов, потребление пропускной способности сети для чатовых приложений и количество приложений с отслеживанием состояния, размещенных в кластере.

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

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

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

Чтобы устранить проблемы в этой области, вам потребуются средства для оценки средств, которые работают в системах инженерии и приложениях, ресурсах и службах в облаках и гибридных средах (например, в Microsoft Defender для облака). Помимо безопасности приложений, оцените:

• Управление внешней поверхностью угроз с помощью таких решений, как Microsoft Defender External Attack Surface Management (Defender EASM).
• Сетевые службы безопасности. Защита приложений и облачных рабочих нагрузок от кибератак на основе сети с помощью таких приложений, как Безопасность сети Azure.
• Интеллектуальная аналитика безопасности с помощью решения для управления сведениями о безопасности и событиями (SIEM), например Microsoft Sentinel.
• Способы управления, защиты, визуализации и безопасного ведения инфраструктуры данных, таких систем управления данными, как Microsoft Purview.
• Способы сканирования кода для потенциальных уязвимостей безопасности, обнаружения секретов, проверки зависимостей, таких как GitHub Advanced Security и GitHub Advanced Security для Azure DevOps.
• Управление цепочкой поставок программного обеспечения, особенно для контейнеров. Например, примените платформу безопасной цепочки поставок контейнеров.

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

Управление доступом к идентификационным данным для служб, приложений и инфраструктуры в крупных масштабах может оказаться сложной задачей. Поставщики удостоверений создают, поддерживают и управляют сведениями об удостоверениях. План должен включать службы проверки подлинности для приложений и сервисов, которые должны масштабно интегрироваться с системами авторизации на основе ролей (RBAC). Например, можно использовать идентификатор Microsoft Entra для предоставления проверки подлинности и авторизации в масштабе для таких служб Azure, как Служба Azure Kubernetes, без необходимости настраивать разрешения непосредственно в каждом отдельном кластере.

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

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

Управление затратами является еще одной частью разработки платформы. Чтобы правильно управлять платформой приложений, необходимо определить владельцев рабочих нагрузок. Вы хотите получить список ресурсов, которые сопоставляют владельцев определенного набора метаданных. Например, в Azure можно использовать метки AKS, теги Azure Resource Manager, а также такие понятия, как проекты в средах развертывания Azure , чтобы сгруппировать ресурсы на разных уровнях. Чтобы это работало, выбранные метаданные должны включать обязательные свойства (например, с помощью политики Azure) при развертывании нагрузок и ресурсов. Это помогает с выделением затрат, сопоставлением ресурсов решения и владельцами. Рекомендуется выполнять регулярные отчеты для отслеживания потерянных ресурсов.

Помимо отслеживания, вам может потребоваться назначить затраты отдельным группам приложений для использования ресурсов, используя эти же метаданные с системами управления затратами, такими как Microsoft Cost Management. Хотя этот метод отслеживает ресурсы, подготовленные командами приложений, он не покрывает затраты на общие ресурсы, такие как поставщик удостоверений, ведение журнала и хранилище метрик, а также потребление пропускной способности сети. Для общих ресурсов можно разделить операционные затраты по отдельным командам или предоставить выделенные системы (например, хранилище ведения журнала), где есть неравномерное потребление. Некоторые общие типы ресурсов могут предоставлять аналитические сведения о потреблении ресурсов. Например, Kubernetes имеет такие средства, как OpenCost или Kubecost и может помочь.

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

Определите, когда и где инвестировать

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

Question	Советы
Вы хотите адаптировать существующую платформу приложений, начать новую версию или использовать сочетание этих подходов?	Даже если вы довольны тем, что у вас есть сейчас, или начинаете с нуля, вам стоит подумать о том, как адаптироваться к изменениям со временем. Немедленные изменения редко работают. Платформы приложений — это движущаяся цель. Ваша идеальная система изменяется по мере прохождения времени. Вы хотите учесть эти соображения и любые связанные планы миграции в вашу будущую проектную конструкцию.
Если вы хотите изменить то, что вы делаете сегодня, какие продукты, услуги или инвестиции вы довольны?	Как говорится, "если это не сломано, не исправьте его". Не изменяйте вещи без причины сделать это. Тем не менее, если у вас есть какие-либо домашние решения, рассмотрите, пришло ли время перейти к существующему продукту, чтобы сэкономить на долгосрочном обслуживании. Например, если вы работаете с собственным решением для мониторинга, вы хотите удалить это бремя из команды ops и перейти на новый управляемый продукт?
Где с течением времени происходит наибольшее изменение? Существуют ли какие-либо из этих областей, которые являются общими для всех (или большинства) типов приложений вашей организации?	Области, с которыми вы или ваши внутренние клиенты не довольны и вряд ли изменятся часто являются отличными местами для начала. Они имеют большую отдачу от инвестиций в долгосрочной перспективе. Это также поможет вам проработать, как вы можете способствовать миграции на новое решение. Например, модели приложений, как правило, являются гибкими, но средства анализа журналов, как правило, имеют более длительный срок хранения. Вы также можете сосредоточиться на новых проектах и приложениях, с которых можно начать, пока вы подтверждаете, что изменение направления приносит желаемые результаты.
Вы инвестируете в индивидуальные решения в областях с наибольшей добавленной стоимостью? Вы чувствуете, что уникальная платформа инфраструктуры приложений является частью вашего конкурентного преимущества?	Если вы определили пробелы, прежде чем разрабатывать индивидуальные решения, рассмотрите, какие области, в которые поставщики, скорее всего, будут инвестировать, и направьте свои усилия по разработке индивидуальных решений в другое место. Начните с того, чтобы думать о себе как об интеграторе, а не как о поставщике инфраструктуры приложений или разработчике моделей приложений. Все, что вы строите, необходимо поддерживать, и затраты на это значительно превышают первоначальные расходы в долгосрочной перспективе. Если вы ощущаете срочную необходимость построить решение в области, которую вы подозреваете, будет охвачена поставщиками в долгосрочной перспективе, планируйте выведение из эксплуатации или долгосрочную поддержку. Ваши внутренние клиенты, как правило, будут довольны стандартным продуктом так же, как и с индивидуальным решением, если не больше.

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

Связанный контент

• Разработка основы самообслуживания разработчика