{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged Product",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/product\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/product\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "282",
            "url": "https:\/\/gavrilov.info\/all\/open-source-portaly-razrabotki-i-chto-takoe-idp\/",
            "title": "Open Source порталы разработки и что такое IDP",
            "content_html": "<p>На рынке внутренних порталов разработчика существует один явный лидер в категории open source — <b>Backstage<\/b>. Большинство других популярных решений, таких как Port, являются коммерческими (SaaS) продуктами, хотя они и могут предлагать open source компоненты для интеграции <a href=\"https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/\">https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/<\/a><\/p>\n<p>Поэтому основной фокус в open source сегменте приходится именно на Backstage, который был создан в Spotify и позже передан в Cloud Native Computing Foundation (CNCF).<\/p>\n<h5><b>Ключевое решение: Backstage<\/b><\/h5>\n<p>Backstage — это не готовый продукт, а <b>фреймворк<\/b> для создания собственного портала разработчика <a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/.\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/.<\/a> Это его главное преимущество и одновременно главный недостаток. Он предоставляет базовые строительные блоки и архитектуру, на основе которых компании могут построить портал, идеально соответствующий их процессам и инструментам.<\/p>\n<p>Кстати очень интересная статья про порталы, платформы и их различия.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png\" width=\"2084\" height=\"1010\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Картинка от портала  Cortex – ну прям огонь сайт у них <a href=\"https:\/\/www.cortex.io.\">https:\/\/www.cortex.io.<\/a><\/div>\n<\/div>\n<p><a href=\"https:\/\/a.gavrilov.info\/data\/posts\/Cloudomation%20Guide%20-%20Building%20Internal%20Developer%20Platforms.pdf\">Cloudomation Guide – Building Internal Developer Platforms.pdf<\/a> есть еще гайд обобщенный.  А основная концепция конечно тут <a href=\"https:\/\/internaldeveloperplatform.org\">https:\/\/internaldeveloperplatform.org<\/a><\/p>\n<p><b>Основные компоненты Backstage:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Software Catalog:<\/b> Единый реестр для всех программных активов компании (микросервисы, библиотеки, веб-сайты, ML-модели и т.д.). Позволяет централизовать метаданные, информацию о владельцах, зависимостях и состоянии.<\/li>\n<li><b>Software Templates (Scaffolder):<\/b> Инструмент для создания новых проектов по заранее подготовленным шаблонам. Это стандартизирует первоначальную настройку сервисов, CI\/CD пайплайнов, репозиториев и т.д.<\/li>\n<li><b>TechDocs:<\/b> Решение для создания, поддержки и отображения технической документации по принципу “docs-as-code”, когда документация хранится вместе с кодом.<\/li>\n<li><b>Плагины:<\/b> Экосистема Backstage строится вокруг плагинов. Существует огромное количество готовых плагинов для интеграции с AWS, Kubernetes, GitHub, CI\/CD системами, системами мониторинга и многими другими. Если нужного плагина нет, его можно разработать самостоятельно.<\/li>\n<\/ol>\n<h4>Сравнение подходов: Build vs. Buy<\/h4>\n<p>Поскольку настоящий open source конкурент у Backstage практически отсутствует, наиболее корректно сравнить его не с другим open source решением, а с подходом использования коммерческих SaaS-платформ, ярким представителем которых является Port.<\/p>\n<ul>\n<li>Port** — это коммерческий продукт, который предлагает готовый к использованию портал. Его философия заключается в гибкой модели данных на основе “blueprints” (шаблонов сущностей) и взаимосвязей между ними. Port позволяет быстро агрегировать данные из различных источников и построить каталог без необходимости развертывания и поддержки сложной инфраструктуры <a href=\"https:\/\/www.qovery.com\/blog\/10-best-internal-developer-portals-to-consider\/\">10-best-internal-developer-portals-to-consider<\/a>. Хотя ядро продукта закрыто, его интеграции и экспортеры данных являются открытыми [internaldeveloperplatform.org](<a href=\"https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/).\">https:\/\/internaldeveloperplatform.org\/developer-portals\/port\/).<\/a><\/li>\n<\/ul>\n<h4>Сравнительная таблица: Backstage vs. Коммерческие IDP (на примере Port)<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Критерий<\/td>\n<td style=\"text-align: center\">Backstage (Open Source)<\/td>\n<td style=\"text-align: center\">Коммерческие решения типа Port (SaaS)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Модель лицензирования<\/b><\/td>\n<td style=\"text-align: center\">Open Source (Apache 2.0). Бесплатно.<\/td>\n<td style=\"text-align: center\">Коммерческая (SaaS). Платная подписка.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Философия \/ Подход<\/b><\/td>\n<td style=\"text-align: center\">Фреймворк для <b>создания<\/b> портала. “Построй свой дом”.<\/td>\n<td style=\"text-align: center\">Готовый продукт для <b>настройки<\/b> портала. “Купи и настрой квартиру”.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Сложность внедрения<\/b><\/td>\n<td style=\"text-align: center\"><b>Высокая.<\/b> Требуется разработка, развертывание и поддержка. Есть кривая обучения [cloudomation.com](<a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/).\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/).<\/a><\/td>\n<td style=\"text-align: center\"><b>Низкая \/ Средняя.<\/b> Быстрый старт, не требует своей инфраструктуры.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Требования к команде<\/b><\/td>\n<td style=\"text-align: center\">Нужна выделенная команда платформенных инженеров для разработки и поддержки портала.<\/td>\n<td style=\"text-align: center\">Может управляться одним или несколькими DevOps-инженерами. Не требует навыков фронтенд-разработки.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: right\"><b>Гибкость и кастомизация<\/b><\/td>\n<td style=\"text-align: center\"><b>Максимальная.<\/b> Можно изменить и доработать абсолютно все, создать уникальные плагины и логику.<\/td>\n<td style=\"text-align: center\"><b>Высокая, но ограничена<\/b> возможностями платформы. Кастомизация интерфейса и логики возможна в рамках, заданных вендором.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Инфраструктура<\/b><\/td>\n<td style=\"text-align: center\">Требует собственной инфраструктуры для хостинга (обычно Kubernetes), базы данных, CI\/CD для самого портала.<\/td>\n<td style=\"text-align: center\">Не требует. Хостится и управляется вендором.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Экосистема и интеграции<\/b><\/td>\n<td style=\"text-align: center\">Огромная, управляемая сообществом. Большое количество open source плагинов.<\/td>\n<td style=\"text-align: center\">Управляется вендором. Интеграции создаются вендором, но часто есть открытые API и экспортеры данных.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Общая стоимость владения (TCO)<\/b><\/td>\n<td style=\"text-align: center\"><b>Скрытая и высокая.<\/b> Лицензия бесплатна, но основные затраты — это зарплаты команды разработки и поддержки, а также стоимость инфраструктуры.<\/td>\n<td style=\"text-align: center\"><b>Прозрачная и предсказуемая.<\/b> Основные затраты — стоимость подписки.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Поддержка<\/b><\/td>\n<td style=\"text-align: center\">Сообщество (Slack, GitHub Issues).<\/td>\n<td style=\"text-align: center\">Коммерческая поддержка от вендора (SLA, выделенный менеджер).<\/td>\n<\/tr>\n<\/table>\n<p>Выбор между open source фреймворком вроде `Backstage` и коммерческим продуктом — это классический выбор между <b>“Build” (создавать)<\/b> и <b>“Buy” (покупать)<\/b>.<\/p>\n<ol start=\"1\">\n<li><b>`Backstage` — это стратегическая инвестиция.<\/b> Это мощное решение для крупных или технологически зрелых компаний, у которых уже есть выделенная платформенная команда и которые готовы вкладывать ресурсы в создание идеально подогнанного под себя инструмента. `Backstage` дает полный контроль, избавляет от зависимости от вендора (vendor lock-in) и позволяет решать уникальные задачи, которые не могут покрыть коробочные продукты.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Коммерческие IDP (такие как Port) — это тактическое решение для быстрого результата.<\/b> Они идеально подходят для малых и средних компаний, или для крупных организаций, которые хотят быстро запустить портал и проверить гипотезы, не формируя для этого отдельную команду разработки. Этот подход обеспечивает быстрый старт, предсказуемые затраты и перекладывает всю головную боль по поддержке и развитию платформы на плечи вендора.<\/li>\n<\/ol>\n<h5>Рекомендации<\/h5>\n<p><b>Выбирайте `Backstage`, если:<\/b><\/p>\n<ul>\n<li>У вас есть (или вы готовы создать) выделенная команда платформенных инженеров.<\/li>\n<li>У вас есть уникальные и сложные внутренние процессы, которые не укладываются в рамки готовых решений.<\/li>\n<li>Вы хотите максимальной гибкости для интеграции со своими самописными инструментами.<\/li>\n<li>Вы — крупная организация, для которой затраты на команду разработки портала оправданы в долгосрочной перспективе.<\/li>\n<li>Принципиально важно избежать зависимости от стороннего вендора.<\/li>\n<\/ul>\n<p><b>Рассмотрите коммерческие решения (типа Port), если:<\/b><\/p>\n<ul>\n<li>Вам нужен результат “здесь и сейчас” с минимальными первоначальными усилиями.<\/li>\n<li>У вас нет ресурсов на формирование команды для разработки собственного портала.<\/li>\n<li>Стандартного или предложенного вендором функционала достаточно для решения ваших задач.<\/li>\n<li>Вы предпочитаете прозрачную модель оплаты (SaaS-подписка) вместо скрытых затрат на разработку и поддержку.<\/li>\n<li>Вам важна гарантированная коммерческая поддержка с четким SLA.<\/li>\n<\/ul>\n<p>Вне зависимости от выбора, начинать следует с определения ключевых проблем разработчиков, которые должен решить портал. Инструмент — это лишь средство для достижения цели, будь то упрощение создания новых сервисов, централизация знаний или автоматизация рутинных задач.<\/p>\n<p>Ниже небольшой гайд на основе дока выше Cloudomation Guide – Building Internal Developer Platforms.pdf<\/p>\n<h4>Руководство<\/h4>\n<h2>Создание внутренних платформ для разработчиков: лучшие практики, инструменты и стратегические выводы для технических лидов<\/h2>\n<p>***<\/p>\n<h4>Кратко о чем все это?<\/h4>\n<p>Ниже представлен обзор внутренних платформ для разработчиков (Internal Developer Platforms, или IDP). Поскольку инженерные команды сталкиваются с растущей сложностью, IDP становятся решением для снижения разногласий между разработкой и эксплуатацией.<\/p>\n<p>Независимо от того, оцениваете ли вы готовые платформы или создаете собственное решение, этот документ предлагает ценные сведения и тщательно подобранные ресурсы, которые помогут вам эффективно пройти путь внедрения IDP.<\/p>\n<p><b>Основные тезисы:<\/b><\/p>\n<ul>\n<li><b>IDP<\/b> — это платформы самообслуживания, созданные инженерами платформ для оптимизации разработки программного обеспечения за счет автоматизации развертываний, конфигураций и управления средами.<\/li>\n<li><b>Преимущества:<\/b> Сокращение времени, затрачиваемого на настройку и отладку, снижение когнитивной нагрузки на разработчиков, повышение надежности и соответствия требованиям, а также более высокая операционная эффективность.<\/li>\n<li>Каждая IDP уникальна, но обычно состоит из фронтенда, бэкенда и других интегрированных инструментов.<\/li>\n<li><b>Ключевые возможности IDP<\/b> должны включать: API, пользовательский интерфейс, автоматизацию, механизмы ограничений (например, политики), документацию и возможность обнаружения сервисов (discoverability).<\/li>\n<li>Для создания по-настоящему целостной IDP необходимо сосредоточиться на интеграции всех необходимых инструментов и сервисов.<\/li>\n<li>При внедрении IDP могут возникнуть следующие <b>проблемы:<\/b> попытка сделать все сразу (и не достичь ничего), нехватка ресурсов и бюджета, невозможность поддерживать каталог программного обеспечения в актуальном состоянии и недостаток коммуникации между людьми.<\/li>\n<li>Обосновывая необходимость внедрения IDP, подкрепляйте свои аргументы данными и связывайте их с рисками и результатами, которые больше всего волнуют ваше руководство.<\/li>\n<\/ul>\n<p>***<\/p>\n<h4>Содержание<\/h4>\n<ol start=\"1\">\n<li>Что такое IDP?<\/li>\n<li>Зачем нужны IDP?<\/li>\n<li>Как работают IDP?<\/li>\n<li>Обоснование необходимости IDP для бизнеса<\/li>\n<li>Лучшие практики для создания IDP<\/li>\n<li>Инструменты платформенной инженерии для создания IDP<\/li>\n<li>3 проблемы при создании IDP<\/li>\n<li>Ресурсы<\/li>\n<\/ol>\n<hr \/>\n<h4>1. Что такое IDP?<\/h4>\n<p>Внутренние платформы для разработчиков (IDP) лежат в основе дисциплины платформенной инженерии (Platform Engineering).<\/p>\n<blockquote>\n<p><b>Пояснение:<\/b><br \/>\nВнутренняя платформа для разработчиков — это, по сути, продукт, предназначенный для разработчиков внутри организации. Она предоставляет им доступ по принципу самообслуживания к технической инфраструктуре и рабочим процессам, таким как конвейеры развертывания или облачные ресурсы. <a href=\"https:\/\/dev.to\/e77\/what-is-an-internal-developer-platforms-17o9\">пост на dev.to<\/a>. Ключевая идея — относиться к своей внутренней платформе как к продукту, а к разработчикам — как к клиентам. <a href=\"https:\/\/dev.to\/akshaymittal143\/from-cloud-chaos-to-developer-delight-your-practical-guide-to-building-an-internal-developer-3o7n\">еще пост с dev.to<\/a>. Это позволяет им не ждать выполнения заявок в отдел эксплуатации и не нести полную ответственность за инфраструктуру, как в модели «you build it, you run it».<\/p>\n<\/blockquote>\n<p>IDP призваны решить вечную проблему, которая преследует всех разработчиков ПО: программное обеспечение чрезвычайно сложно, и ни один человек не может знать всего, что требуется для создания целого программного продукта.<\/p>\n<h5>Понимание внутренних платформ для разработчиков<\/h5>\n<p>На схеме ниже показаны ключевые концепции, лежащие в основе IDP.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.46.02.png\" width=\"996\" height=\"796\" alt=\"\" \/>\n<\/div>\n<ul>\n<li><b>Подходы «Инфраструктура как код» (As-Code Approaches):<\/b> Акцент на автоматизацию и документирование через код.<\/li>\n<li><b>«Золотые пути» (Golden Paths):<\/b> Предоставление заранее определенных, проверенных и поддерживаемых путей для выполнения типовых задач (например, создание нового сервиса, развертывание в среде). Разработчики могут легко следовать этим путям, будучи уверенными в результате.<\/li>\n<li><b>Самообслуживание (Self-Service):<\/b> Позволяет разработчикам самостоятельно использовать платформу без необходимости обращаться в другие команды.<\/li>\n<li><b>Управление как продуктом (Managed like a product):<\/b> У платформы есть свой жизненный цикл выпуска, владелец продукта и дорожная карта развития.<\/li>\n<li><b>Инженеры платформы (Platform Engineers):<\/b> Создают и поддерживают IDP, фокусируясь на ценности для разработчиков.<\/li>\n<li><b>Разработчики ПО (Software Developers):<\/b> Основные пользователи, которые взаимодействуют с IDP.<\/li>\n<\/ul>\n<h5>Функции IDP<\/h5>\n<p>IDP предоставляют функции, которые являются центральными в повседневной работе разработчиков программного обеспечения.<\/p>\n<p>Это лишь примеры функций, которые может иметь IDP. Каждая IDP уникальна для организации, которая ее использует. Часто они создаются с нуля или сильно кастомизируются под нужды компании.<\/p>\n<hr \/>\n<h4>2. Зачем нужны IDP?<\/h4>\n<p>По мере усложнения процесса поставки ПО организации сталкиваются с фрагментированными практиками DevOps, несогласованными рабочими процессами и операционной неэффективностью. От разработчиков ожидают, что они будут управлять инфраструктурой, конвейерами CI\/CD, политиками безопасности и мониторингом, что часто приводит к когнитивной перегрузке и снижению производительности. Именно здесь на помощь приходят платформенная инженерия и IDP.<\/p>\n<h5>Раскрывая мощь IDP<\/h5>\n<ol start=\"1\">\n<li><b>Ускорение циклов разработки:<\/b> Оптимизированное развертывание сокращает время, затрачиваемое на настройку и отладку.<\/li>\n<li><b>Снижение когнитивной нагрузки на разработчиков:<\/b> Упрощенное управление инфраструктурой позволяет сосредоточиться на написании кода.<\/li>\n<li><b>Повышение надежности и соответствия требованиям (Compliance):<\/b> Обеспечивает последовательное применение политик безопасности и соответствия во всех развертываниях.<\/li>\n<li><b>Повышение инженерной эффективности:<\/b> Автоматизирует управление ресурсами, повышая операционную эффективность.<\/li>\n<\/ol>\n<hr \/>\n<h4>3. Как работают IDP?<\/h4>\n<p>Каждая IDP уникальна, но есть некоторые общие характеристики, присущие большинству из них. В самом простом виде каждая IDP состоит примерно из трех «частей»:<\/p>\n<ul>\n<li>Фронтенд IDP<\/li>\n<li>Бэкенд IDP<\/li>\n<li>Множество других инструментов, интегрированных с IDP<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.44.01.png\" width=\"1062\" height=\"432\" alt=\"\" \/>\n<\/div>\n<ul>\n<li><b>Фронтенд:<\/b> Пользовательский интерфейс для доступа разработчиков к IDP. Часто это внутренний портал разработчика (Internal Developer Portal).<\/li>\n<li><b>Бэкенд:<\/b> Управляет интеграцией и автоматизацией с другими инструментами. Эту роль часто выполняет оркестратор платформы.<\/li>\n<li><b>Интегрированные инструменты:<\/b> Различные инструменты, которые работают с IDP для выполнения ключевых процессов (CI\/CD, мониторинг, безопасность и т.д.).<\/li>\n<\/ul>\n<h5>Архитектура<\/h5>\n<p>Следующая диаграмма архитектуры, основанная на модели CNOE (Cloud Native Operational Excellence), дает более детальное представление.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.39.52.png\" width=\"972\" height=\"368\" alt=\"\" \/>\n<\/div>\n<p><a href=\"https:\/\/gavrilov.info\/all\/rainbond-oblachnaya-platforma-dlya-upravleniya-prilozheniyami\/\">Ранее писал про Rainbond китайский, там немного другой акцент, но их архитектура тоже интересная, а так как это опенсорс, то можно свой такой запилить, но переводить придется :) <\/a><\/p>\n<p>В этой диаграмме «Портал разработчика» (`Developer Portal`) является фронтендом IDP. Компонент «Оркестрация рабочих процессов» (`Workflow Orchestration`) будет бэкендом.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.40.18.png\" width=\"946\" height=\"674\" alt=\"\" \/>\n<\/div>\n<p>Ниже приведен более подробный пример архитектуры, показывающий, какие типы инструментов и сервисов могут быть частью IDP, сгруппированные по функциональным уровням (плоскостям).<\/p>\n<h5>Ключевая функциональность IDP<\/h5>\n<p>Основная идея IDP — объединить инструменты, сервисы, конфигурации и другую информацию в одном месте. Инженеры-программисты, а также другие заинтересованные стороны (например, команды эксплуатации) должны иметь возможность использовать IDP как единую точку входа для обнаружения и взаимодействия с приложениями и инфраструктурой компании.<\/p>\n<p>Таким образом, бэкенд IDP, как правило, должен быть сильным в двух типах функциональности: <b>№1 Интеграция<\/b> и <b>№2 Автоматизация<\/b>.<\/p>\n<ul>\n<li><b>Интеграция:<\/b> Объединение разнообразных инструментов и сервисов в единую систему.<\/li>\n<li><b>Автоматизация:<\/b> Связывание и оркестрация существующих конвейеров автоматизации.<\/li>\n<\/ul>\n<hr \/>\n<h4>4. Обоснование необходимости IDP для бизнеса<\/h4>\n<p>По мере того как организации масштабируют и модернизируют поставку своего программного обеспечения, сложность управления инфраструктурой, рабочими процессами разработчиков и управлением (governance) растет экспоненциально.<\/p>\n<p>Внутренняя платформа для разработчиков (IDP) предлагает стратегический ответ на этот вызов, обеспечивая более быструю доставку, более сильное управление и снижение операционных рисков. Однако, чтобы получить одобрение руководства, крайне важно сформулировать преимущества IDP в терминах бизнеса.<\/p>\n<p>Вот как можно обосновать необходимость IDP, обращаясь к четырем ключевым проблемам руководителей: <b>Масштаб, Затраты, Риски и Управление.<\/b><\/p>\n<h5>1. Масштаб: Предоставление организации возможности двигаться быстрее<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как мы можем масштабировать наши инженерные команды и поставку ПО без узких мест?<\/li>\n<li><b>Обоснование IDP:<\/b> IDP повышает производительность, абстрагируя повторяющиеся, низкоценные задачи. Она дает командам приложений возможность самостоятельно обслуживать инфраструктуру, CI\/CD, тестирование и развертывание стандартизированным и безопасным способом.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Повышение скорости работы команд приложений и организации в целом.<\/li>\n  <li>Быстрая доставка большей бизнес-ценности, поскольку команда разработки может сосредоточиться на коде.<\/li>\n  <li>Возможность масштабирования без линейного увеличения найма DevOps-инженеров.<\/li>\n<\/ul>\n<\/li>\n<li><b>Как это сделать:<\/b> Оцените, сколько времени команды приложений тратят на борьбу с инфраструктурой и инструментами развертывания, и сколько — на работу над своим основным приложением. Используйте эти данные, чтобы обосновать необходимость IDP и показать, как она может высвободить время для основной задачи, что напрямую влияет на бизнес-ценность. Визуализируйте это, чтобы подчеркнуть, каким объемом инфраструктуры приходится управлять командам приложений, и сравните это с тем, как это могло бы выглядеть.<\/li>\n<\/ul>\n<p>*(В оригинальном документе здесь показаны два слайда из презентации PlatformCon23, представляющие “текущее состояние” и “будущее состояние”. Текущее состояние показывает, как команда из 50 разработчиков приложений вынуждена вручную взаимодействовать с разрозненным набором инструментов. Будущее состояние показывает, как команда платформы предоставляет единый, унифицированный слой, который абстрагирует эту сложность, позволяя командам приложений работать более эффективно.)*<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.42.47.png\" width=\"1008\" height=\"1222\" alt=\"\" \/>\n<\/div>\n<p>Обратите внимание сколько кубиков вверху, а сколько внизу. В России кстати очень быстро вырывается вперед разработка на фреймворках streamlit, они почти ничего не делают повторно, если развернули хоть раз его с авторизацией и ипишками – в основном только ui колбасят. Но часто такие инициативы не вырастают сильно, их обычно давят в зародыше, так как они не соответствуют общему формату и не хотят делать все остальные кубики или не умеют – в общем похожи они на shadow it. Но если же им каким, то образом это удалось, то потом их не остановить и придя к ним через год, можно увидел второй прод, полностью зеркальный :) и сделал его кто-то один вечерами.<\/p>\n<h5>2. Затраты: Оптимизация за счет масштабирования и повторного использования<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как нам контролировать растущие расходы на облако и инженерию?<\/li>\n<li><b>Обоснование IDP:<\/b> Платформенная инженерия сокращает дублирование усилий и консолидирует управление инфраструктурой. IDP способствует экономически эффективному масштабированию, обеспечивая прозрачность и контроль на протяжении всего жизненного цикла ПО. Централизация позволяет совместно использовать ресурсы, проактивно отслеживать затраты и автоматически высвобождать неиспользуемые активы (например, тестовые среды).<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Улучшенная прозрачность и предсказуемость затрат.<\/li>\n  <li>Снижение общей стоимости владения (TCO) за счет оптимизации ресурсов.<\/li>\n  <li>Большая рентабельность инвестиций (ROI) в облачную инфраструктуру.<\/li>\n<\/ul>\n<\/li>\n<li><b>Важный момент:<\/b> Команды платформы могут отслеживать метрики использования и отключать неиспользуемые среды.<\/li>\n<\/ul>\n<h5>3. Риски: Сокращение точек отказа и операционных угроз<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Какие риски угрожают нашей способности поставлять продукт надежно и безопасно?<\/li>\n<li><b>Обоснование IDP:<\/b> IDP минимизирует операционные риски и риски безопасности путем стандартизации процессов по всем направлениям — конвейеры CI\/CD, развертывание, наблюдаемость (observability), оповещения и аутентификация.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Снижение риска сбоев в продакшене.<\/li>\n  <li>Централизация ключевых сервисов, таких как развертывание, управление идентификацией и логирование.<\/li>\n  <li>Принудительное применение политик безопасности и соответствия на уровне платформы.<\/li>\n<\/ul>\n<\/li>\n<li><b>Примеры устраняемых рисков:<\/b>\n<ul>\n  <li>Задержки в поставке из-за нестабильных конвейеров.<\/li>\n  <li>Утечки данных из-за неверно настроенных систем аутентификации.<\/li>\n  <li>Непрохождение аудита из-за несогласованного логирования или дрифта соответствия требованиям.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>4. Управление (Governance): Обеспечение согласованности и соответствия требованиям в масштабе<\/h5>\n<ul>\n<li><b>Проблема руководителя:<\/b> Как нам поддерживать контроль, не замедляя команды?<\/li>\n<li><b>Обоснование IDP:<\/b> С IDP управление становится встроенным. От шаблонов до API, команды платформы могут кодировать стандарты и лучшие практики непосредственно в опыт разработчика.<\/li>\n<li><b>Бизнес-результаты:<\/b>\n<ul>\n  <li>Проактивное управление и применение политик.<\/li>\n  <li>Улучшенная аудитопригодность и соответствие нормативным требованиям.<\/li>\n  <li>Формирование культуры инженерного совершенства.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Подкрепление доводов данными<\/h5>\n<p>Ключевым фактором для вашего бизнес-обоснования являются данные. Проведите опрос в вашей инженерной организации, чтобы собрать информацию, например, о времени, затрачиваемом на инфраструктурные задачи по сравнению с разработкой новой функциональности.<\/p>\n<p><b>Итоговые мысли: Что не дает спать руководителям?<\/b><\/p>\n<p>При формировании своего предложения обращайтесь непосредственно к рискам и результатам, которые больше всего волнуют ваших руководителей. Например:<\/p>\n<ul>\n<li><b>Скорость выхода на рынок (Speed to market):<\/b> Сможем ли мы поставлять продукт быстрее конкурентов?<\/li>\n<li><b>Надежность:<\/b> Выдержат ли наши системы нагрузку?<\/li>\n<li><b>Безопасность и соответствие требованиям (Security & Compliance):<\/b> Уязвимы ли мы для взломов или аудитов?<\/li>\n<li><b>Масштабируемость:<\/b> Сможем ли мы расти, не теряя контроля?<\/li>\n<\/ul>\n<p>Внутренняя платформа для разработчиков — это не просто технический инструмент, это стратегический актив. С правильной постановкой вопроса, данными и видением вы можете продемонстрировать, как хорошо реализованная IDP поддерживает не только инженерию, но и весь бизнес.<\/p>\n<hr \/>\n<h4>5. Лучшие практики для создания IDP<\/h4>\n<p>Этот раздел основан на идеях, вдохновленных видео Виктора Фарчича «От нуля до полностью работающей платформы для разработчиков за 5 шагов!». Он описывает не столько шаги, сколько ключевые возможности, которые должна иметь IDP, чтобы быть полезной.<\/p>\n<p><b>5 ключевых возможностей IDP (по версии Виктора Фарчича):<\/b><\/p>\n<ol start=\"1\">\n<li>API<\/li>\n<li>Управление состоянием (State management)<\/li>\n<li>Одноразовые действия \/ Рабочие процессы (One-shot actions \/ Workflows)<\/li>\n<li>RBAC и Политики (RBAC & Policies)<\/li>\n<li>Пользовательские интерфейсы (опционально)<\/li>\n<\/ol>\n<p><b>Наш взгляд на ключевые возможности (немного измененный и дополненный):<\/b><\/p>\n<ol start=\"1\">\n<li><b>API:<\/b> Программный интерфейс для взаимодействия с платформой.<\/li>\n<li><b>Пользовательские интерфейсы (не опционально):<\/b> Удобный способ для разработчиков взаимодействовать с платформой.<\/li>\n<li><b>Автоматизация:<\/b> Включает как одноразовые действия (например, запуск сборки), так и управление состоянием (например, поддержание среды в нужном состоянии).<\/li>\n<li><b>Ограничения (Constraints):<\/b> Политики, управление доступом на основе ролей (RBAC) и т.д.<\/li>\n<li><b>Документация и обнаруживаемость (Discoverability):<\/b> Возможность легко находить сервисы, их владельцев и документацию.<\/li>\n<\/ol>\n<h5>Как это поможет мне построить платформу?<\/h5>\n<p>Если вы подумаете о проблемах, с которыми вы недавно сталкивались как инженер платформы или DevOps-инженер, вы, вероятно, сможете соотнести их с одной из описанных возможностей.<\/p>\n<p><b>Некоторые примеры:<\/b><\/p>\n<ul>\n<li>Если у вас проблемы с простоями инстансов или случайными высокими затратами из-за оставленных облачных ресурсов, у вас недостаточные возможности по <b>управлению состоянием<\/b>.<\/li>\n<li>Если у вас проблемы с тем, что у инженеров-программистов нет доступа к нужной им инфраструктуре, или с тем, что младшие инженеры вмешиваются в развертывания, в которые им не следует вмешиваться, вы плохо управляете <b>ограничениями<\/b>.<\/li>\n<li>Если ваши разработчики не могут самостоятельно запустить систему на основе feature-ветки или запустить сборку и тест для определенного коммита, вам нужно взглянуть на ваши возможности <b>автоматизации одноразовых действий<\/b>.<\/li>\n<li>Если ваши инженеры-программисты просто не используют предоставляемые вами API и сервисы, вам, вероятно, следует взглянуть на предоставляемые вами <b>пользовательские интерфейсы<\/b> или проверить, <b>обнаруживаемы \/ документированы<\/b> ли ваши сервисы.<\/li>\n<\/ul>\n<p>Цель и ценность этих ключевых возможностей — помочь вам понять, почему вы продолжаете терпеть неудачи в некоторых вопросах, и как вы можете начать исправлять ситуацию таким образом, чтобы это было долговечно и устойчиво управляемо.<\/p>\n<hr \/>\n<h4>6. Инструменты платформенной инженерии для создания IDP<\/h4>\n<p>В этой статье рассматривается, как структурировать IDP, с разбивкой по ключевым компонентам и с примерами инструментов, которые вы можете использовать.<\/p>\n<h5>Категоризация инструментов и компонентов<\/h5>\n<p>Мы классифицируем эти инструменты, используя «референсную архитектуру», популяризированную `platformengineering.org`. Эта структура разбивает экосистему на пять основных компонентов, известных как «плоскости» (`planes`):<\/p>\n<ul>\n<li><b>Плоскость управления разработчика (`Developer Control Plane`):<\/b> Все компоненты, через которые разработчики взаимодействуют с платформой. Обычно включает GUI\/порталы, контроль версий, облачные среды разработки (CDE), а также стандарты конфигурации, которые разработчики поддерживают сами.<\/li>\n<li><b>Плоскость интеграции и доставки (`Integration & Delivery Plane`):<\/b> Здесь происходит вся автоматизация. Инструменты CI\/CD, автоматизация инфраструктуры и другие оркестраторы платформы обычно являются частью этой плоскости.<\/li>\n<li><b>Плоскость мониторинга и логирования (`Monitoring & Logging Plane`):<\/b> Как следует из названия, здесь находятся все инструменты наблюдаемости (observability).<\/li>\n<li><b>Плоскость безопасности (`Security Plane`):<\/b> Управление секретами, инструменты политик и другие инструменты безопасности.<\/li>\n<li><b>Плоскость ресурсов (`Resource Plane`):<\/b> Вычислительные ресурсы и хранилища.<\/li>\n<\/ul>\n<h5>Пример: Создание внутренней платформы для разработчиков<\/h5>\n<p>Вот разбивка инструментов, которые вы могли бы использовать для создания IDP. Важное замечание: существует множество доступных инструментов. Упомянутые здесь — лишь примеры.<\/p>\n<h5>Плоскость управления разработчика<\/h5>\n<p><b>№1 Портал разработчика (`Developer Portal`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Внутренние порталы разработчиков служат единым интерфейсом и позволяют разработчикам, командам и инженерам-менеджерам обнаруживать сервисы, отслеживать владение, применять стандарты и улучшать программное обеспечение.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Backstage:<\/b> Популярный open-source фреймворк для создания порталов разработчиков, созданный Spotify.<\/li>\n  <li><b>Port:<\/b> Платформа для создания внутреннего портала разработчика с no-code подходом, что облегчает быстрый старт.<\/li>\n  <li><b>Cortex:<\/b> Корпоративный внутренний портал разработчика, созданный для ускорения пути к инженерному совершенству. [cloudomation.com](<a href=\"https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/)\">https:\/\/cloudomation.com\/cloudomation-blog\/5-internal-developer-portals-and-what-software-engineers-say-about-them\/)<\/a><\/li>\n  <li><b>Atlassian Compass:<\/b> Компонентный каталог для отслеживания компонентов и команд, которые за ними стоят.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№2 Облачные среды разработки (`Cloud Development Environments, CDEs`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> CDE — это удаленные среды разработки, размещенные в облаке или локально. CDE позволяют разработчикам работать в согласованных, стандартизированных средах, что устраняет проблемы «у меня на машине все работает».<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Gitpod:<\/b> Позволяет запускать безопасные, контекстно-насыщенные среды для разработчиков в корпоративном масштабе.<\/li>\n  <li><b>Coder:<\/b> Предоставляет безопасные среды разработки для разработчиков и их агентов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость интеграции и доставки<\/h5>\n<p><b>№1 Конвейер CI (`CI Pipeline`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Автоматизирует проверку кода, тестирование и обеспечивает более быстрые циклы обратной связи.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>GitHub Actions:<\/b> Нативный CI для GitHub с настраиваемыми рабочими процессами.<\/li>\n  <li><b>CircleCI:<\/b> Высокомасштабируемый CI с поддержкой расширенного параллелизма.<\/li>\n  <li><b>Buildkite:<\/b> CI, ориентированный на разработчиков, с масштабируемой инфраструктурой.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№2 Конвейер CD (`CD Pipeline`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Конвейеры CD автоматизируют безопасное, повторяемое развертывание программного обеспечения.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Argo CD:<\/b> GitOps-ориентированная доставка для Kubernetes.<\/li>\n  <li><b>Flux:<\/b> Контроллер GitOps для Kubernetes.<\/li>\n  <li><b>Octopus Deploy:<\/b> Подходит для мультиоблачных и локальных (on-prem) сред.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><b>№3 Оркестратор платформы (`Platform Orchestrator`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Инструменты оркестрации предоставляют логику для связывания рабочих процессов между различными инструментами и сервисами.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Humanitec:<\/b> Оркестратор платформы, предоставляющий динамические среды. Является лидером рынка IDP. [internaldeveloperplatform.org](<a href=\"https:\/\/internaldeveloperplatform.org\/)\">https:\/\/internaldeveloperplatform.org\/)<\/a><\/li>\n  <li><b>Собственные решения\/фреймворки:<\/b> Многие команды используют общие инструменты, такие как <b>Argo Workflows<\/b> или пишут собственные скрипты на Python\/Go для объединения своих процессов.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость мониторинга и логирования<\/h5>\n<p><b>№1 Наблюдаемость (`Observability`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Инструменты наблюдаемости обеспечивают видимость состояния, производительности и надежности приложений и инфраструктуры.<\/li>\n<li><b>Инструменты для рассмотрения:<\/b>\n<ul>\n  <li><b>Prometheus:<\/b> Набор инструментов для мониторинга и оповещения, особенно для Kubernetes.<\/li>\n  <li><b>Grafana:<\/b> Инструмент для создания дашбордов, часто используемый в паре с Prometheus.<\/li>\n  <li><b>Datadog:<\/b> Облачный мониторинг и аналитика.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Плоскость безопасности<\/h5>\n<p><b>№1 Менеджер секретов (`Secret Manager`)<\/b><\/p>\n<ul>\n<li><b>Почему это важно:<\/b> Менеджеры секретов безопасно хранят и распространяют учетные данные, ключи API и другие конфиденциальные данные.<\/li>\n<li>Инструменты для рассмотрения:**\n<ul>\n  <li><b>HashiCorp Vault:<\/b> Ведущее в отрасли решение для управления секретами.<\/li>\n  <li><b>AWS Secrets Manager \/ Azure Key Vault \/ GCP Secret Manager:<\/b> Решения от крупных облачных провайдеров.<\/li>\n  <li><b>Sealed Secrets (Bitnami):<\/b> Шифрует секреты для Kubernetes.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h5>Вывод: Строительные блоки, а не список покупок<\/h5>\n<p>Если из этой главы и стоит что-то вынести, так это то, что платформенная инженерия — это не выбор самых модных инструментов с полки, а подбор правильных строительных блоков для создания бесшовного опыта для разработчиков. Думайте меньше о том, «какой инструмент мне выбрать?», и больше о том, «как я могу спроектировать платформу, которая будет незаметной и мощной для моих разработчиков и принесет пользу бизнесу?»<\/p>\n<p>Настоящая магия происходит тогда, когда эти инструменты перестают быть отдельными частями пазла и становятся частью целостной платформы для разработчиков, где разработчики едва замечают лежащую в основе сложность, потому что платформа работает с ними, а не против них.<\/p>\n<hr \/>\n<h4>7. 3 проблемы при создании IDP<\/h4>\n<p>Этот раздел основан на идеях Гая Менахема (Guy Menahem), архитектора решений в Amazon.<\/p>\n<p><b>Проблема 1: Попытаться поймать всех зайцев одним выстрелом<\/b><\/p>\n<p>Многие команды платформенной инженерии пытаются сделать все сразу и в итоге не достигают ничего. Объединение всех инструментов в единое решение может привести к тому, что вы упустите основной рабочий процесс пользователя, что приведет к отказу от платформы. Вместо этого оттачивайте свои продуктовые навыки, чтобы понять, какую пользу пользователи извлекут из платформы, даже если на начальном этапе она будет включать всего несколько инструментов.<\/p>\n<p><b>Проблема 2: Оценка затрат на создание и эксплуатацию<\/b><\/p>\n<p>Создание ценной платформы требует ресурсов, включая выделенную команду платформенной инженерии, бюджет на облачную инфраструктуру и сотрудничество. Также необходимо учитывать операционные расходы, такие как обновления и патчи безопасности. Оценивайте ресурсы, определяя размер и продолжительность работы команды, сосредотачиваясь на минимально жизнеспособном продукте (MVP) и рассчитывая облачные и операционные затраты.<\/p>\n<p><b>Проблема 3: Создание и управление каталогом программного обеспечения<\/b><\/p>\n<p>Управление каталогом программного обеспечения, который представляет собой сложную базу данных ПО, систем и документации, может быть непростой задачей. Вовлечение всех команд в обновление и поддержание каталога имеет решающее значение для его качества и принятия. Упростите управление каталогом, автоматизировав сбор информации, принудительно обновляя его в процессах CI\/CD и поощряя ежедневное использование платформы.<\/p>\n<h5>Наш взгляд<\/h5>\n<p>Проблемы, которые описывает Гай, реальны. Однако одна фундаментальная истина, которую он не упоминает, заключается в том, что <b>большинство проблем при создании IDP не являются техническими.<\/b><\/p>\n<p>Вместо этого наиболее распространенные проблемы возникают из-за <b>недостатка коммуникации между людьми.<\/b> Это типично для многих инженерных инициатив, поскольку инженеры, как правило, имеют очень специфический взгляд на инструменты, которые они создают, и этот взгляд часто сильно отличается от точки зрения их пользователей.<\/p>\n<p>То же самое часто происходит и в командах платформенной инженерии: они могут создавать ценную автоматизацию и сервисы, но если их нелегко использовать, в них отсутствуют ключевые функции, необходимые инженерам-программистам, или они просто не решают самые большие проблемы, с которыми сталкиваются разработчики, то они просто не будут использовать IDP.<\/p>\n<p>Самое важное, что вы должны делать как инженер платформы, — <b>регулярно спрашивать своих инженеров-программистов!<\/b> Просите их протестировать то, что вы создаете, сказать, полезно ли это для них, и если ответ «нет», то изменяйте то, что вы создаете, чтобы ваши инженеры-программисты захотели это использовать.<\/p>\n<p>В конце концов, в этом и заключается вся суть IDP: она должна быть полезной для инженеров-программистов.<\/p>\n<hr \/>\n<h4>8. <b>Ресурсы и ссылки<\/b><\/h4>\n<ul>\n<li><a href=\"https:\/\/platformengineering.org\">https:\/\/platformengineering.org<\/a><\/li>\n<li><a href=\"https:\/\/internaldeveloperplatform.org\">https:\/\/internaldeveloperplatform.org<\/a><\/li>\n<li><a href=\"https:\/\/www.infoq.com\/platformengineering\">https:\/\/www.infoq.com\/platformengineering<\/a><\/li>\n<\/ul>\n<p><b>Сообщества<\/b><\/p>\n<ul>\n<li>Reddit – <a href=\"https:\/\/www.reddit.com\/r\/platform_engineering\">https:\/\/www.reddit.com\/r\/platform_engineering<\/a><\/li>\n<li>Platformers – <a href=\"https:\/\/platformers.community\">https:\/\/platformers.community<\/a><\/li>\n<\/ul>\n<p><b>Рассылки<\/b><\/p>\n<ul>\n<li><a href=\"https:\/\/platformweekly.com\">https:\/\/platformweekly.com<\/a><\/li>\n<\/ul>\n<hr \/>\n<p>Ранее еще писал немного на другую тему, но про разработку и стандарты апишек,интересно, мало у кого они есть, выглядят вот так: <a href=\"https:\/\/gavrilov.info\/all\/analiz-zalando-restful-api-and-event-guidelines\/\">https:\/\/gavrilov.info\/all\/analiz-zalando-restful-api-and-event-guidelines\/<\/a><\/p>\n",
            "date_published": "2025-09-24T23:12:48+03:00",
            "date_modified": "2025-09-24T23:36:23+03:00",
            "tags": [
                "Dev",
                "Management",
                "Product",
                "Programming"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png",
            "_date_published_rfc2822": "Wed, 24 Sep 2025 23:12:48 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "282",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.11.04.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.46.02.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.44.01.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.39.52.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.40.18.png",
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-09-24-v-22.42.47.png"
                ]
            }
        },
        {
            "id": "95",
            "url": "https:\/\/gavrilov.info\/all\/otlichnaya-mentalnaya-karta-po-razvitiyu-produkta-ot-figma\/",
            "title": "Отличная ментальная карта по развитию продукта от Figma",
            "content_html": "<p>Смотрим тут:<br \/>\n<a href=\"https:\/\/www.figma.com\/file\/SABujfIEwzpa1NuWiVS3RR\/The-Product-Map-3.0?type=whiteboard&node-id=111-1506\">https:\/\/www.figma.com\/file\/SABujfIEwzpa1NuWiVS3RR\/The-Product-Map-3.0?type=whiteboard&node-id=111-1506<\/a><\/p>\n",
            "date_published": "2023-12-10T22:21:42+03:00",
            "date_modified": "2023-12-10T22:21:37+03:00",
            "tags": [
                "Product"
            ],
            "_date_published_rfc2822": "Sun, 10 Dec 2023 22:21:42 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "95",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}