Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Самообслуживание при помощи ограничений является принципом предоставления командам разработчиков возможности принимать собственные решения в рамках набора хорошо определенных параметров или ограничений. Ограждения установлены и согласованы ключевыми заинтересованными сторонами. Заинтересованные лица могут включать в себя группы безопасности, операции, архитектуры в организации.
При использовании самообслуживания с ограничениями, команды разработчиков сохраняют автономию для независимого принятия решений о разработке. Автоматизация и политика помогают заинтересованным лицам обеспечить правильное управление безопасностью, соответствием, операциями, стандартами и затратами. Включение этой автоматизации требует совместной работы между командами, чтобы разработчики, операторы и специалисты могли сделать больше, не жертвуя необходимым управлением. Затем разработчики могут сосредоточиться на предоставлении бизнес-ценности как можно быстрее.
[Мы говорим разработчикам,] не беспокойтесь о том, как все работает, просто включите или выключите их, заполните поля, вставьте строку в нужное поле, и это в основном самообслуживание в этом отношении, где у них есть файл README, и они имеют входные и выходные данные, и могут ввести любые данные, которые им нужны. - Даниэль, облачный инженер, медийная компания из списка Fortune 500
Цель предоставления самообслуживания для ваших проложенных путей заключается в сокращении нагрузки разработчика, а также обеспечении видимости для команд разработки, операций и управления. Идея заключается в том, что вы создаете интерфейс для данной задачи, которая имеет минимальную кривую обучения, благодаря отчасти ее базовым возможностям автоматизации и агрегирования данных. Помимо таких действий, как подготовка инфраструктуры, эти возможности могут обеспечить доступ к критически важным возможностям для наблюдения, политики, управления инцидентами и многое другое. Идея распространяется на обнаружение и совместное использование внутренних API, пакетов SDK, а также общих средств и служб. Эти возможности снижают нагрузку, чтобы команды разработчиков могли сосредоточиться на том, чтобы сделать все возможное.
Внутренние платформы разработчиков позволяют разработчикам действовать как клиенты цифрового магазина
Внутренние платформы разработчиков предоставляют возможности, аналогичные цифровым магазинам бизнес-бизнеса. Цифровые магазины по сути предназначены для самостоятельного обслуживания своих клиентов. Они могут обрабатывать больше объема операций, чем традиционные магазины, потому что предоставляют способы поиска и покупки товаров, которые интересны, без необходимости общаться с кем-либо. Используя эту аналогию, разработчики являются клиентами, и внутренняя платформа разработчиков предоставляет аналогичные возможности самообслуживания. Операторы, инженеры платформы и другие специалисты затем настраивают каталог элементов, которые разработчики могут запрашивать, предназначенных для учета организационных рамок.
Например, вы можете подумать о разработчике, запрашивающего доступ к новому инструменту, как если бы они делали цифровой заказ на магазин. Как и заказ, после отправки запроса разработчик хочет иметь возможность отслеживать ход выполнения и знать, когда оно завершено. В фоновом режиме запрос должен автоматически направляться к правильному поставщику услуг по исполнению, чтобы удовлетворить потребность. Вы можете рассматривать одну из систем непрерывной интеграции и доставки (CI/CD) в качестве одного поставщика услуг, инструмента GitOps или предписывающей платформы приложений как второго, а также средства автоматизации рабочих процессов для ручных процессов в качестве третьего. Во всех случаях разработчик может самостоятельно обслуживать элементы из четко определенного каталога так же.
Используйте паттерн "всё как код"
Использование инфраструктуры как кода (IaC) через конвейеры непрерывной доставки (CD) и инструменты GitOps является важной частью предоставления возможности самообслуживания. IaC с CD позволяет использовать Bicep, Terraform, Helm диаграммы и другие средства для создания и уничтожения облачных ресурсов по требованию. Так как конфигурация облачной инфраструктуры управляется так же, как код в репозитории исходного кода, вы можете применить все преимущества репозитория Git, такие как безопасность и аудит.
Подготовка общей инфраструктуры и инструментов не является единственным преимуществом подхода IaC. Вы можете адаптировать шаблон IaC для других сценариев, включая безопасность как код и политику в виде кода (с помощью таких средств, как Политика Azure и агент Open Policy). После этого метода файл конфигурации, обычно YAML или JSON, отправляется в репозиторий, который запускает рабочий процесс, обрабатывающий файл. Эти файлы могут быть репозиторием приложений, например dependabot.yml или CODEOWNERS, или они могут храниться в отдельном центральном репозитории. Вы даже можете расширить это в собственных сценариях, чтобы действительно сделать все как код (EaC) реальностью.
Разработчики могут ссылаться на каждый из этих шаблонов EaC с центральным каталогом, который обеспечивает возможности самообслуживания и рекомендует рекомендации по умолчанию.
Создание правильных шаблонов запуска и обеспечение правильного управления
В разработке программного обеспечения мы стремимся к инкапсуляции, модульности и композируемости при проектировании приложений. Вы должны применить эту же линию мышления к проектированию платформы с помощью шаблонов. Например, можно создать и использовать набор централизованно защищенных шаблонов IaC в качестве стандартных блоков инфраструктуры.
Мы создадим модули для наших [разработчиков]... поэтому вместо того, чтобы писать или беспокоиться о любой серверной части, все, что им нужно сделать, это беспокоиться о коде приложения. - Даниэль, облачный инженер, компания из списка Fortune 500 в сфере медиа
Объедините IaC, EaC и шаблоны приложений в индивидуально разработанное решение "всё как код" (EaC), которое охватывает и другие действия, такие как создание репозитория исходного кода, заполнение примером кода или предоставление конфигурации и примеров кода для рекомендованных инструментов наблюдаемости. Затем эти шаблоны IaC, EaC и приложений можно хранить или ссылаться из центрального, защищенного расположения, такого как репозиторий, каталог в средах развертывания Azure или реестр контейнеров Azure для cloud-native.
При правильном начале шаблоны объединяются с автоматизированным управлением, сканированием и конфигурацией политики, разработчики остаются на правильном пути с первого дня.
Шаблоны упрощают разработку с помощью автоматизированных, безопасных методик
Используйте шаблоны приложений для инициализации определённых путей развития для нескольких ключевых решений и действий, которые принимают разработчики в процессе проекта. Правильные шаблоны запуска обеспечивают безопасные, управляемые методики разработки и позволяют разработчикам быстро начать работу, включает автоматизацию, которая предоставляет доступ к необходимым инструментам, настраивает конвейеры CI/CD, провизирует инфраструктуру и стек приложений, а также настраивает репозиторий с исходным кодом, который содержит необходимые пакеты SDK или ссылки на API.
Если эти шаблоны приложений ссылаются на другие централизованные шаблоны (например, IaC), каждая из этих отдельных стандартных блоков становится оптимальным отправным шаблоном собственным. Эти шаблоны являются центральными для обеспечения самостоятельного взаимодействия, так как они не только определяют выходные данные, но и доступные варианты, которые разработчики выбирают.
Шаблоны обеспечивают управление, безопасность и оптимизацию затрат
Однако шаблоны должны делать больше, чем просто инициирование процессов разработки. Они также должны установить контроль и управление с помощью политики и проверки безопасности, необходимых для соответствия на протяжении всего жизненного цикла проекта. В качестве другого примера шаблоны могут настраивать правила защиты ветви, предотвращающие несанкционированное слияние в рабочую ветвь. Так как шаблоны фиксируют рекомендации и распространенные конфигурации, они являются одним из ключевых методов оптимизации затрат в средствах, поставщиках и командах.
Запуск правильных кампаний для создания двусторонней связи
Наконец, по мере повышения достоверности проложенных путей можно использовать базовые отдельные стандартные блоки, собранные в шаблоны приложений, чтобы переместить существующие приложения на проложенный путь. Так как внутренние клиенты уже увидят ценность ваших пилотных решений, вы можете запустить внутреннюю кампанию, чтобы установить двусторонний диалог с другими командами приложений. Разработчики могут узнать, как перенести свое приложение, пока команда разработчиков платформы одновременно узнает больше о том, как улучшить платформу для них.
Диаграмма собственного пути
Учитывая широкий спектр опыта, который может охватить ваша система самообслуживания, важно сосредоточить ваши инвестиционные усилия и планировать и расставлять приоритеты, чтобы внутренняя платформа разработчиков постепенно предоставляла ценность. Путь каждой организации в создании внутренней платформы разработчиков уникален, и следование продуктово ориентированному подходу помогает сфокусироваться на наиболее критически важных областях, где в первую очередь необходимы возможности самообслуживания.