Примеры: три реализации проектирования платформы

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

Новые новаторы: Страховая компания

Сегмент клиента	Фокус-области	Размер команды	Признаки организации	Частота
Новые новаторы	Быстрая разработка продуктов, автоматизация ручных процессов, решение неэффективных процессов	1–5 (от DevOps или команд облачной инфраструктуры)	Определяет узкие места для улучшения доставки, начиная с реализации потребности в решениях на уровне организации	Второй наиболее распространенный

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

Переломный момент был весьма однозначным. Учитывая, что у нас есть несколько инженерных платформ, несколько инфраструктурных сред, включая гибридные, отсутствуют возможности портала самообслуживания для разработчиков, и в нашей архитектуре имеются три огромных и разных стека, мы должны были внедрить что-то вроде Terraform или решение уровня предприятия, например GitLab или GitHub. Для управления сквозными контейнерными платформами мы рассмотрели такие решения, как OpenShift, Ansible для автоматизации рабочих процессов и Backstage для внутренней платформы разработчика (IDP). Мы провели масштабную оценку, чтобы обеспечить синергию в таком большом технологическом стеке... Это очень простой случай затрат при небольшом сокращении персонала или численности разработчиков на 30%. - Главный архитектор, страховая компания.

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

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

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

Принятие: Существует значительное внутреннее сопротивление внедрению новых методик. Разработчики не хотят переходить от традиционных методов к новым платформам и наборам инструментов. Чтобы преодолеть это, руководство организации толкает разработку платформы, привязав ее к преимуществам производительности и сделав ее частью целей сотрудников.

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

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

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

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

Стратегический строитель: Финансовое учреждение

Сегмент клиента	Фокус-области	Размер команды	Признаки организации	Частота
Стратегический архитектор	Совместная работа, сокращение избыточных усилий, общих решений, стандартизация, управление затратами	1–15 технических экспертов (разработчики и специалисты по инфраструктуре)	Руководство рассматривает разработчиков как клиентов, частично интегрированы функции инженерии платформ (самообслуживание еще не полностью внедрено).	Наиболее распространенные

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

"Таким образом, идея была в том, что мы будем показывать им [разработчиков], что этот [золотой путь] является одним из способов сделать то, что улучшит вашу производительность, но это не единственный способ. Правильно? Поэтому мы хотели дать разработчикам возможность почувствовать, что они уполномочены вносить изменения в тот путь, который мы им предлагаем. Так что, когда пути определяются в команде CTO, всегда встает вопрос: какие из них будут работать для большинства сотрудников банка? Как я сказал, мы очень сложны. Есть тысячи инструментов, используемых по всему банку. "Поэтому подход «один размер подходит всем» всегда был самой большой проблемой," — генеральный директор финансового учреждения.

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

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

Инвестиция: Финансовое учреждение имеет центральную инженерную группу с 120 человек, распределенных по нескольким местам по всему миру. Команда центра передового опыта (COE) состоит примерно из 20 человек. Команда COE развертывает рекомендации по проектированию, платформу и методики DevOps во всех других бизнес-подразделениях.

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

Управление: Решение для проектирования платформы — это внутренний разработанный портал, который выступает в качестве центрального центра для разработчиков, предлагая инструменты, руководства, стандарты программирования и видео. Это решение включает тест по минимальным корпоративным требованиям (MERS), чтобы обеспечить соответствие требованиям перед началом написания кода. На портале представлена версия Stack Overflow для поддержки, сертифицированных профилей инженеров и пути адаптации для ознакомления новых разработчиков со стандартами и инструментами. Компания планирует оптимизировать управление ресурсами и интегрировать управление жизненным циклом разработки, удаляя узкие места и привлекая лучших технических талантов с помощью современного набора инструментов.

Настройка: Команда COE создала "оптимальные маршруты" для разработчиков, чтобы повысить их производительность и при этом сохранить гибкость. Цель — предложить эффективный путь, разрешая настройку. При проектировании этих путей команда CTO стремится удовлетворить большинство разработчиков, но сложность банка, с тысячами инструментов, используемых, делает реализацию стандартизованного подхода. Чтобы масштабировать платформу, организация планирует реализовать автоматическую подготовку ресурсов в соответствии с различными потребностями многих инженерных групп.

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

Измерения и отзывы: Команда COE открыта для отзывов и активно запрашивает ее от инженерных команд. Адвокаты разработчиков и послы также собирают отзывы от имени команды COE. Процесс обратной связи в основном неформальный.

Пионер платформы: компания-разработчик программного обеспечения

Сегмент клиента	Фокус-области	Размер команды	Признаки организации	Частота
Пионер платформы	Отношение к разработчикам как к клиентам, управление платформой, как продуктом, сильный опыт разработчика	16+ со специализированными группами	Подчеркивает подотчетность, расширение возможностей и инновации, способствует самообслуживанию и минимальному переключению контекстов	Наименее распространенный

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

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

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

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

Инвестиция: Платформа финансируется и поддерживается через совместную работу между офисами CTO и CFO. Выделенная команда платформы, сформированная путем перераспределения ресурсов, включает в себя 250 до 280 членов, таких как архитекторы и инженеры. Команда контролирует вычислительные ресурсы, среду выполнения, CI/CD, средства и наблюдаемость с акцентом на экономичность. Они изучают генерированный ИИ для масштабируемости инфраструктуры, но признают, что необходимы дальнейшие исследования и инвестиции.

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

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

Подготовки: Группа платформы предоставляет централизованную и гибкую платформу для создания ресурсов, развертывания и управления. Платформа основана на Kubernetes и использует Argo CD для CI/CD. Средство предлагает настраиваемые шаблоны и предопределенные рабочие процессы. Платформа включает в себя дом разработчика, где пользователи могут управлять жизненным циклом инфраструктуры от подготовки к развертыванию. Teams вносит вклад в специализированные подключаемые модули для улучшения функциональности. Цель заключается в том, чтобы легко управлять инфраструктурой с несколькими облаками с помощью масштабируемой платформы.

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

Измерения и отзывы: Организация собирает отзывы с помощью опросов и использует такие метрики, как DORA (частота развертывания, время выполнения, скорость сбоя и среднее время восстановления) для оценки эффективности платформы. Эти метрики классифицируются как гибкость и стабильность, чтобы определить узкие места и улучшить результаты.