Привет, Хабр! Меня зовут Александр Коротков, я — тимлид продуктовой команды в Т-Банк и член программного комитета конференции DevOps Conf. Разрабатывал системы автоматизации тестирования, пять лет посвятил работе над IDP, лидировал разработку бизнесовой платформы. Эта статья родилась из моего доклада для DevOps Conf. Но, если честно, тема давно сидела в голове. Я много раз наблюдал в индустрии один и тот же сценарий: платформы начинают строить с амбициями, но потом что-то ломается — развитие замирает, платформа превращается в тяжёлую обузу или её и вовсе переписывают с нуля. Почему так происходит? Где те самые «невидимые грабли», на которые снова и снова наступают разные команды?
Будет полезно не только тем, кто строит платформы напрямую — CTO, Head of Platform, DevOps-инженерам и разработчикам платформенных решений, но и всем, кто сталкивается с инфраструктурой и хочет заранее видеть потенциальные проблемы.
Я достаточно долго работал в платформенной команде, а сейчас лидирую продуктовую команду, которая пользуется различными внутренними платформами, благодаря чему имею насмотренность в этом вопросе. Как представитель програ��много комитета часто общаюсь со спикерами различных компаний, и узнаю, что происходит в индустрии. Перед подготовкой к докладу пообщался с разными компаниями — от совсем небольших в 100−150 человек в разработке до крупнейших с 5−7 тысячами разработчиков. Провёл интервью, постарался выделить возникающие проблемы, уточнить нюансы, а затем собрал всё это воедино. В статье будут ссылки на статьи, исследования, книги, записи выступлений с различных конференций и вебинаров. Всё это я тоже постарался проанализировать и встроить в общую картину.
Дисклеймер: в статье не будет готовых решений, зато будет разбор проблематики. Приведу примеры как успешных, так и неуспешных решений без указаний на конкретных людей или компании.
Что значит «взлетают»?
Для начала, решил составить критерии успешной платформы, для меня они такие:
Охват пользователей. Успешная платформа должна быть востребована. Чем больше команд и специалистов используют её решения в ежедневной работе, тем выше её ценность для всей компании.
Удовлетворенность пользователей. Пользователи должны хотеть работать с платформой. Если основной фидбек — постоянный негатив, сопротивление и обходные пути, это быстро блокирует развитие: платформу будут игнорировать, внедрение станет болезненным, а ценность — сомнительной. Успешная платформа — та, которую не заставляют использовать, а выбирают добровольно.
Развитие платформы. Платформа должна эволюционировать вместе с потребностями бизнеса. Если развитие останавливается, со временем платформа перестанет закрывать новые задачи и быть актуальной, и постепенно тормозит развитие компании.
Платформа приносит пользу. Это звучит как сферический конь в вакууме: мы за всё хорошее против всего плохого. Но суть в том, что за каждой платформой должен стоять понятный и измеримый эффект: экономия времени команд, ускорение релизов, повышение стабильности или упрощение разработки. Не просто «хорошо, что она есть», а ощутимый вклад в эффективность бизнеса и разработчиков.
Я назвал четыре классных критерия, но как понять, что платформа действительно им удовлетворяет?
Platform Engineering Maturity Model
Не будем изобретать велосипед. Примерно два года назад члены сообщества CNCF (достаточно сильные платформенные инженеры из крупных компаний) собрались, подумали на эту тему и разработали Platform Engineering Maturity Model.
Эта модель включает пять аспектов (качеств, присущих платформе):
Investment — не только про деньги, с помощью которых мы оцениваем пользу от нашей платформы, но и про то, как формируется и финансируется команда, как вообще выстроена работа.
Adoption — как пользователи узнают о нашей платформе, внедряют её и используют её преимущества.
Interfaces — как пользователи взаимодействуют с платформой. Здесь возможны различные варианты, например, CLI, UI, API и пр.
Operations — как планируются, приоритезируются, разрабатываются и поддерживаются возможности платформы. То есть, как в нашу команду поступают задачи, как мы определяем, что важно, а что нет, на чём фокусируемся.
Measurement — как выстроен процесс сбора обратной связи, как мы снимаем метрики, чтобы понять, что всё работает, пользователи — удовлетворены, а мы не деградируем по качеству предоставления услуг.
У каждого из этих аспектов есть уровни зрелости. Каждый может находиться на своей стадии, но взаимосвязи между ними есть. Если один из аспектов сильно проседает, то может утянуть за собой и другие.
Теперь к делу. Расскажу, как появляются внутренние платформы.
С чего начинается платформа: поддержка C-Level
Чтобы начать разработку внутренней платформы, необходимо заручиться поддержкой на уровне топ-менеджмента компании. Это не всегда исключительно зона ответственности технического директора (CTO). В зависимости от структуры компании и масштаба платформы, в процесс согласования часто вовлекаются и другие стейкхолдеры: директор по продукту (CPO), финансовый директор (CFO), а иногда и сам генеральный директор (CEO). Их участие важно, поскольку разработка платформы затрагивает бюджет, стратегические приоритеты компании, организационные ресурсы и сроки.
Принять решение о запуске платформы без согласования с ключевыми заинтересованными сторонами можно только в рамках очень небольших автономных команд. Но в большинстве случаев такие самовольные инициативы либо не получают нужного уровня поддержки и финансирования, либо стал��иваются с организационными препятствиями уже на ранних этапах развития. Поэтому формальное одобрение и согласованность с основными бизнес-заказчиками критичны для устойчивого старта и последующего развития платформы.
Теперь разберёмся, как зарождаются платформы внутри компании. Есть две стратегии: снизу вверх (bottom-up) и сверху вниз (top-down). Рассмотрим, какие проблемы возникают в каждой из них.
Как появляется платформа: bottom-up
В этом кейсе есть неравнодушные разработчики и Ops-инженеры. Разработчики разрабатывают для себя инструменты. Если они получаются хорошими, то делятся ими с другими разработчиками, которые тоже начинают их использовать. Ops-инженеры пишут скрипты автоматизации, выкладки и так далее.
Когда набирается критическая масса пользователей этих инструментов, как раз и появляется MVP-версия платформы, то есть минимальная жизнеспособная версия, которую нужно собрать воедино.
Дальше принимается высокоуровневое решение, что платформу пора развивать. Здесь и нужно получить одобрение от руководства. Но ещё до его получения, часто всплывают вполне практические проблемы.
Не определено место платформы в организационной структуре компании. На старте, когда всё начинается с отдельных тулзов и скриптов, никакой структуры попросту нет. Кто-то из разработчиков или DevOps-инженеров написал скрипт, чтобы упростить себе работу. Скрипт оказался полезным — им начали пользоваться коллеги. Но официально за эти решения никто не отвечает, в штатном расписании команды платформы нет, а платформа формально ещё не существует. Всё держится на энтузиазме отдельных инженеров.
Не разделены зоны ответственности. Непонятно, кто этим будет заниматься дальше и отвечать за это решение. Например, инженер написал в библиотеку для Python или Go полезное общее решение, а затем покинул компанию. Всё! Экспертизы нет, поддержки нет., Непонятно, кто за это ответственен и что с этим делать.
Не очевидно, как считать P&L. На уровне СТО непонятно, как собрать разрозненные тулзы, скрипты и микросервисы в единый продукт, чтобы посчитать экономический эффект от платформы: на чём экономим, сколько времени и денег экономит бизнес, сколько людей пользуются, где рост производительности. Собрать эти данные внятно и верифицируемо на ранней стадии сложно. В итоге защищать инвестиции становится тяжело — ни перед CFO, ни перед CPO, ни тем более перед CEO.
Как появляется платформа: top-down
Теперь разберёмся с проблемами стратегии «сверху вниз», когда решение принимается на C-уровнеи после его принятия, надо сформировать команду под задачу.
Здесь какие-то проблемы повторяются, но возникают и новые:
Нужно убедить: СРО, CFO, CIO. Теперь нужно убедить остальных руководителей C-level, что такая платформа действительно нужна, важна и принесёт профит.
Разобраться, с чего начать. Даже если все нужные люди наверху согласились и поддержку мы получили, следующий шаг — дизайн команды. И тут начинается самое интересное: надо очень чётко ответить себе, кто нужен в эту команду, какая экспертиза критична на старте, кого посадить в роли тимлида или платформенного продакта, каким опытом он должен обладать. Ошибка на этом этапе может дорого обойтись — если собрать «не тех» людей или неправильно расставить акценты в компетенциях, то дальше платформа может просто не взлететь или заглохнуть ещё на старте.
Проблемы имплементации. Даже если мы собрали команду, продумали структуру и нарисовали красивую архитектуру, на этапе реализации всё может пойти не туда. Можно запилить такую платформу, которая формально работает, но при этом неудобна для пользователей: неудобный интерфейс, сложный онбординг, неинтуитивные флоу — и вместо пользы платформа начнёт только раздражать. В таком виде она не взлетит: команды не будут её использовать, начнут городить свои костыли, и вся история закончится довольно быстро.
Само по себе существование платформенных команд в организации не гарантирует успеха ни компании, ни самой платформы (Puppet’s State of DevOps Report 2021, p.4). Мало просто собрать команду, она должна быть с правильными майндсетом и установками, чтобы всё это запустить.
Майндсет и культура
Создаём платформу для всех!
Платформа должна быть для всех, и эта мысль очень важная, с ней согласилось большинство людей, которых я опрашивал, тоже самое сказано в литературе.
На одном из круглых столов мы как раз обсуждали эту проблему на конкретном примере. В компании может быть ключевой бизнес-заказчик — его продукт приносит основную часть выручки. Такой заказчик регулярно приходит к платформенной команде с новыми запросами: «Сделайте вот такую фичу, она даст прирост прибыли для моего продукта ещё на 5–10%». В этой ситуации всегда есть соблазн пойти навстречу — реализовать то, что он просит, закрыть его потребности и получить быстрый финансовый результат. Но здесь возникает риск: платформа постепенно превращается в команду заказной разработки, которая работает исключительно на одну бизнес-линию.
При этом не факт, что решения, которые были сделаны под конкретного крупного заказчика, можно потом масштабировать и использовать в других продуктах или командах. Если масштабируемость есть — хорошо. Если её нет — мы теряем универсальность платформы, что в перспективе бьёт по всей компании.
Иногда в такой ситуации разумнее отказаться от индивидуального запроса крупного клиента и сконцентрироваться на разработке общей функциональности, которая будет полезна широкому кругу пользователей внутри компании. Даже если каждое отдельное подразделение получит от этой фичи не такой большой выигрыш, в сумме это ускорит работу множества небольших команд, которые только формируются и запускают свои продукты. Благодаря платформенным возможностям они смогут стартовать быстрее и проверять больше гипотез, а отдельные из этих новых продуктов могут вырасти, дать кратный рост бизнеса и стать новыми ключевыми направлениями..
Стандартизация или гибкость
Как и в большинстве платформенных вопросов — всё зависит от компании, её текущей зрелости, структуры и бизнес-задач. Но именно в теме стандартизации почти всегда возникает противоречие, с которым приходится разбираться.
С одной стороны, по данным последней редакции State of Platform Engineering Report 2024 (Vol 3, 2024, p. 20), стандартизация и автоматизация — одни из основных драйверов создания внутренних платформ. Более половины опрошенных назвали это ключевой целью. Это понятный мотив: за счёт унификации стеков, процессов и подходов можно снизить вариативность, упростить поддержку, сократить издержки и повысить безопасность.
Но есть и обратная сторона. Авторы Accelerate, опираясь на результаты своих исследований, показывают, что чрезмерная стандартизация и жёсткое ограничение свободы выбора инструментов могут привести к снижению эффективности команд. Если разработчиков и продуктовые команды лишают возможности выбирать оптимальные технологии и инструменты под конкретные задачи, их скорость и качество работы начинают падать. Унификация в ущерб гибкости оборачивается замедлением разработки и накоплением неудовлетворённости. (N.Forsgren, J.Humble, G.Kim - Accelerate! Build and Scailing High Performing Technology Organizations, 2018, p. 102)
Именно поэтому важно на старте платформенной стратегии определить: где стандартизация действительно приносит пользу, а где нужна вариативность. Например, в банках или высокорегулируемых отраслях — стандарты часто идут в приоритете. А в продуктовых стартапах — гибкость и возможность экспериментов важнее. И платформа должна учитывать этот контекст.
Грегор Хопу, который работал в Amazon платформенным архитектором, отмечает, что ключ к успешной платформы лежит не в выборе между контролем/стандартами и скоростью/удобством, которые может предоставить гибкость. Надо задизайнить платформу таким образом, чтобы предусмотреть гармоничную реализацию того и другого, и встраиваимость.
Во время одного из проводимых мной интервью коллега озвучил следующую мысль, она мне очень отзывается:
«Бытие системы определяет сознание разработчика».
Как мы задизайним платформу, так наши разработчики будут жить и мыслить. Если мы закручиваем всё стандартами, то и разработчики теряют гибкость мышления в поиске нестандартных решений. Если нам это не критично для бизнеса (скажем, из-за отсутствия регуляций), то, наверное, от жёстких стандартов можно чуть-чуть отступить.
Принятие решений
Эта проблема в той или иной степени встречается почти везде, но в платформенной разработке её влияние особенно заметно. Здесь легко впасть в крайности.
Первая крайность — чрезмерно затяжные процессы согласования. Например, собирается архитектурный комитет, на котором каждое изменение нужно обсудить со всеми заинтересованными сторонами, получить одобрение от каждого, учесть все риски и мнения. В результате вместо того, чтобы за месяц запустить нужную фичу, команда два месяца принимает решение, как её делать. Итог — потерянное время и постоянное отставание от потребностей пользователей.
Вторая крайность — авторитарные, но спорные или даже непопулярные решения. Когда команда или отдельный руководитель принимают решение сверху: «Делаем так, всем внедрить». В каких-то случаях без таких решений не обойтись, но надо объяснить командам и пользователям, зачем это нужно, какую пользу принесёт, и сопровождать процесс внедрения.
Пример из практики — собственная система контрактов в одной из компаний. Сама по себе идея была полезной, но её внедрение шло тяжело: требовалась плотная работа с пользователями, разъяснение, обучение, доработка по обратной связи. Зато когда adoption достиг 100%, система начала реально приносить эффект.
Есть обратная сторона этой медали: если вы приняли непопулярное авторитарное решение и оно оказалось неверным, то вы породите техдолг продуктовым командам, хорошо, если только на месяц или два работы. Такое тоже может быть, и это надо понимать.
Стратегия
Очень важно держать в фокусе стратегию платформенной команды.
Платформа — это игра вдолгую
Платформенная разработка — история НЕ на несколько месяцев. Да, мы можем быстро показать первые результаты, например, запустить базовые сервисы или автоматизировать пару ключевых процессов. Но реальный экономический эффект появится после того, как всё больше команд начнёт активно пользоваться платформой и получать от неё выгоду.
В этой связи очень важен фактор преемственности. А с этим, как показывает практика, часто возникают проблемы. Если руководитель платформенной команды меняется каждый год-два, почти неизбежно возникает следующая картина: новый руководитель приходит, смотрит на текущую реализацию, видит несовершенства (которые всегда есть), говорит: «Что за ерунду вы тут понастроили?», выкидывает старое и запускает всё заново — под своё видение. В итоге цикл повторяется. Вместо поступательного движения мы каждый раз откатываемся к стартовой точке.
При такой динамике выйти на стабильные положительные показатели по эффекту платформы почти невозможно: команда тратит ресурсы не на развитие, а на постоянный «перезапуск». Поэтому удержание лидеров, долгосрочная стратегия и непрерывное развитие — одни из ключевых факторов в платформенной работе.
Sridhar Kotagiri — Platform Product Principal и Ajay Chankramath — Head of Platform Engineering из ThoughtWorks провели исследование, как составлять value proposition и рассчитывать P&L для платформы.
В этом графике они опирались на то, что adoption rate конкретной платформы изначально был 100%. Естественно, 100% adoption rate на старте вряд ли будет, даже с авторитарным решением. И если в этом примере окупаемость составляет год, то приземлив на реальные цифры, получим гораздо больший срок. Как это всё рассчитать, можно прочитать в статье «Sridhar Kotagiri, Ajay Chankramath – Measuring the value of your internal development platform investments: The Enterprise Technology Leadership Journal Spring 2024 Volume 1, Issue 1, p. 102».
Проблемы долгостроя
Поскольку платформа строится долго, ей присущи все проблемы долгостроя.
Нет постоянного лидера. Я уже отмечал, что при отсутствии постоянного лидера могут возникать проблемы. Не достигнув положительного результата за первый год, мы меняем Head of Platform, и опять начинаем всё сначала.
Размытие фокуса. Даже имея перспективу на год, и долгосрочную стратегию, часто непонятно, как принести пользу прямо сейчас, в моменте.
Команда не понимает, зачем она нужна. Всё вышеперечисленное не очень положительно сказывается на команде. Она не понимает, нужные ли фичи делает. Может случиться кризис самоопределения.
Не определён клиент
Одна из типичных ошибок, с которой сталкиваются команды при запуске платформы, — отсутствие чёткого понимания, для кого платформа строится. Кто наш целевой пользователь? Это разработчики продуктовых команд? DevOps-инженеры? Архитекторы? Безопасники? CTO? Или вообще сразу все?
Если этот вопрос не решить на старте, то в процессе работы платформа начнёт развиваться реактивно — под каждую текущую боль или запрос. Придёт одна команда — «сделайте нам вот эту фичу». Потом другая — «а нам нужно вот то». В итоге команда платформы постоянно будет дергаться между разными задачами, не имея единого фокуса. Поэтому лучше всего определить основного пользователя и его потребности максимально рано — желательно до старта активной фазы разработки. Тогда появится возможность выстроить понятный value proposition, отсечь второстепенные хотелки и двигаться в сторону системного, а не хаотичного развития.
Реактивное развитие
Тушение пожаров. Одна из классических ловушек — попытка совмещать тушение операционных пожаров и параллельную разработку платформы в одной команде. Сценарий обычно выглядит так: мы начали делать одну фичу для одной команды, потом прилетел запрос от другой — сделали для неё. Где-то что-то поломалось — пошли срочно чинить. Постепенно начинается постоянная беготня между разными задачами и инцидентами.
Команда, которая занята оперативной поддержкой и разбором инцидентов, физически не может параллельно проектировать сложную платформенную архитектуру. Контексты слишком разные: здесь — быстрый локальный фикс, там — продуманная инженерная работа в долгую. Результат обычно один — страдают оба направления: и пожары продолжают гореть, и платформа не двигается.
По сути, есть только одна рабочая стратегия: разделять потоки.
Бесполезные фичи. Отдельная проблема — разработка функциональности, которая в итоге оказывается невостребованной. Пример из практики: один из технических лидеров регулярно предлагал сделать централизованное управление Cron Jobs — как в проде, так и на dev и тестовых стендах. Идея выглядела разумно: единый инструмент для администрирования всех шедулеров.
Мы потратили на реализацию 1–2 месяца, выкатили фичу в прод. Через месяц после релиза посмотрели статистику использования. По логам оказалось, что за всё время ручки управления вызывались всего 3 раза. При этом ресурсов на разработку ушло заметно больше, чем пользы, которую мы в итоге получили.
Отставание от реальных потребностей Одним из признаков того, что мы отстаем от потребностей клиентов, может быть:
«Очень большой бэклог накопился – даже непонятно, с чего сейчас начать».
За бэклогом нужно следить. Если у вас определён конкретный потребитель, то и бэклог будет направлен в первую очередь на него, а всё остальное отправится в корзину или отложенное.
Разобрались с тем, как и куда идти, что делать. Переходим к последнему этапу, но не по значению.
Реализация
Проблемы здесь нас могут подстерегать на каждом шагу.
Наследие
Первое, с чем я столкнулся в интервью о реализации — у компании может быть наследие, огромный legacy.
Организационные договоренности. Legacy могут выражаться в организационных договоренностях. Поясню на примере: есть процесс получения доступов или ресурсов. Изначально это реализовывалось через заявки в JIRA. Начали стандартизировать флоу, автоматизировать его, но этот процесс никак не изменили и не переработали, просто вместо JIRA-тикетов появились MR в GitLab, а сам процесс с апрувами остался таким же — от тех же людей и с теми же сроками. То есть мы просто переложили процесс из одного ресурса в другой и никакого профита из этого не извлекли. В результате, это может серьёзно тормозить работу — процессы тоже нужно пересматривать.
Legacy-системы. Одна из типовых сложностей — наличие legacy-систем, например, монолитов или старых сервисов, которые не вписываются в архитектурное видение новой платформы. Обычно приходится выбирать: либо сосредотачиваться на поддержке и доработке существующего legacy, либо строить среду для правильной разработки новых сервисов с прицелом на будущее и уже затем постепенно мигрировать старые компоненты.
Попытки одновременно полноценно развивать и поддерживать старое, и строить новое, как правило, приводят к распылению ресурсов и замедлению обеих инициатив. Поэтому здесь критично заранее определить приоритет — в зависимости от бизнес-задач компании и горизонта планирования. Выбор остаётся за компанией — в зависимости от того, что важнее.
Технический долг. Строя платформу, на её adoption и внедрение продуктовыми командами, скорее всего, потребуется какое-то время. Но если команда и так захлебывается в продуктовых задачах и техдолге, внедрение будет очень медленным. Это будет тормозить adoption платформы в целом.
Обширный стек. В компании могут быть все присутствующие на рынке технологии, и все их придётся поддерживать. Далеко не факт, что получится. Возможно, стоит посмотреть на это с другой стороны — не стандартизировать работу с текущими решениями, а упростить и автоматизировать процесс добавления новых инструментов, миграции с одной системы на другую и вывод их из эксплуатации.
С наследием разобрались, выбрали, куда идём — поддерживаем legacy системы или строим новые сервисы и постепенно затаскиваем в них старые. На этом этапе появляются проблемы во взаимодействии с платформой.
Взаимодействие с платформой
Когда мы строим платформу, важно, чтобы разработчику было удобно с ней работать. Одна из основных целей — снизить лишнюю когнитивную нагрузку: чтобы разработчику не приходилось разбираться в большом количестве внутренних деталей и процессов. В Team Topologies это называют Extraneous cognitive load — отдельная категория нагрузки, которую стоит учитывать при проектировании платформы (M. Skelton, M. Pais - Team Topologies, 2019, p.71).
Low-level-абстракции протекают ДО пользователя. Иногда разработчику приходится работать с низкоуровневыми деталями платформы, которые ему вообще знать не обязательно. Например, писать манифесты под Kubernetes, разбираться с Helm и внутренними настройками кластера. При этом у него и так есть своя основная работа — следить за бизнес-логикой, обновлениями языка, библиотек и собственного продукта. Чем больше низкоуровневых деталей вынесено «на поверхность», тем выше когнитивная нагрузка и тем меньше ценность платформы. Задача платформенной команды — максимально закрывать такие детали внутри себя.
Долгий и сложный онбординг в платформу. Одним из индикаторов, что с вашей платформой не очень удобно взаимодействовать, может быть долгий и мучительный онбординг новичков. Мэтью Скелтон в Team Topologies выделяет легкий и быстрый онбординг как один из признаков хорошей платформы. (M. Skelton, M. Pais - Team Topologies, 2019, p.149)
«Некоторые разработчики даже не знают, что такое под, и это никак не мешает им приносить пользу».
Хорошая платформа должна снимать лишнюю техническую нагрузку с разработчика. Те вещи, которые не входят в его зону ответственности, он вообще не должен держать в голове. Чем меньше он думает о деталях инфраструктуры, тем больше может сосредоточиться на бизнес-логике своего продукта.
Отсутствие продуктового подхода
Мэлори Хай, эксперт по разработке платформ и консультант Platform Engineering.org, на недавнем вебинаре обозначила четыре проблемы:
чрезмерное усложнение;
фокус только на технических аспектах и реализации;
разработка бесполезных фич;
считаем, что DevEx только про разработчиков.
Отсутствие продуктового подхода приводит к перекосу в сторону технической реализации. Часто платформенные команды начинают с того, что стараются сделать «идеальную» архитектуру: детально прорабатывают схемы, рисуют сложные диаграммы, выстраивают долгосрочные планы. При этом реальных, полезных для пользователей фич может долго не появляться. В результате за несколько лет разработки тратятся значительные ресурсы — время команды, бюджет, внимание стейкхолдеров — а работающей платформы, которой реально пользуются разработчики, по-прежнему нет. Такие истории заканчиваются тем, что проект замораживают или пересобирают с нуля уже с другим составом команды.
Что касается применения продуктового подхода при разработке платформ, есть хорошие разборы этой темы. На YouTube можно найти интервью и доклад Мэтью Скелтона (одного из авторов Team Topologies), где он подробно объясняет, как переносить принципы продуктовой разработки на платформенные команды: на чем фокусироваться, как определять пользователей, какие метрики отслеживать. Кроме того, на DevOpsConf 2025 было несколько докладов, которые подробно рассматривали продуктовый подход в платформенной разработке. В частности, доклады Владимира Утратенко «А это платформа» и Марии Летта «Как найти пользователей в платформе и что с ними делать». Эти материалы дают практическое представление о том, как именно строить платформу как продукт.
Важный поинт: «Платформа должна быть лучше, чем разработчики могут сделать сами»
Если платформа получается менее удобной или менее эффективной, чем те решения, которые разработчики или Ops-инженеры могут сделать для себя вручную, то пользоваться ею никто не будет. В результате каждый начнёт разрабатывать собственные обходные решения и инфраструктурные костыли. В такой ситуации лучше всего подключиться к этим инициативам: взять успешные внутренние решения под контроль, доработать их до нужного качества и включить в общий стек платформенных сервисов. Это позволит сохранить инициативу внутри компании и снизить разрозненность инструментов.
Вместо заключения
«Истинный результат оценки по модели зрелости — это не ваш уровень, а список того, над чем вам нужно работать, чтобы улучшиться».
Мартин Фаулер
В процессе подготовки я собрал перечень проблем, которые чаще всего звучали в интервью, обсуждались на конференциях и упоминались в профессиональном сообществе. Именно из-за них платформы либо не взлетают, либо стагнируют, либо откровенно проваливаются. Для наглядности я сгруппировал их в таблицу по ключевым аспектам зрелости платформы — чтобы было видно, на какие области каждая проблема оказывает наибольшее влияние.
Когда вы создаёте платформу или проектируете работу платформенной команды, на эти проблемы имеет смысл опираться как на чеклист. Можно соотнести их с аспектами зрелости вашей платформы — и, если окажется, что по каким-то из них возникают сложности, это хороший повод проверить: не столкнулись ли вы с одной из типичных проблем, которые мешают платформам развиваться.
Если вам близки вопросы — как строить платформы, как не угробить их в самом начале и как вообще делать всё по-настоящему работающим — присоединяйтесь к сообществу DevOpsConf. Мы разбираем ошибки и обсуждаем реальные кейсы компаний, где эти проблемы уже решают. Всегда интересно пообщаться с тем, кто уже решил проблему, над которой ты ещё ломаешь голову.
Все имеющиеся вопросы по содержанию статьи можно задать автору в Telegram. И конечно, присоединяйтесь к следующей конференции DevOpsConf в 2026 году!