Пару лет назад я руководил группой из примерно сорока разработчиков, и мы дошли до точки, когда инфраструктурная команда из трёх человек стала узким горлышком всего процесса. Любой новый сервис начинался с тикета, ожидания и переписки в мессенджере, а к моменту, когда окружение наконец поднималось, у автора уже пропадало желание что-то писать. Именно тогда мы впервые всерьёз заговорили про внутреннюю платформу разработчика, или, как это модно называть, Platform Engineering.
Честно скажу: первый заход был провальным. Мы нарисовали красивую архитектуру, выбрали модный портал, полгода строили, а получили инструмент, которым пользовались два с половиной человека. Главная ошибка была в установке «построим, и они придут»: мы делали платформу для себя, а не для разработчиков, и не спрашивали их, что именно болит. Никакой окупаемости в такой схеме не бывает, потому что ценность создаёт не количество кластеров, а количество людей, которым стало проще работать.
Второй заход мы начали с разговоров. Я прошёл по командам и просто спросил: что отнимает у вас больше всего времени не по делу? Ответы оказались скучными и предсказуемыми: настройка CI, окружения, доступы, секреты, наблюдаемость, стандартный шаблон сервиса. Никто не просил единую панель управления всем на свете. Тогда мы сформулировали для себя простой критерий: платформа окупается там, где она превращает типовой сценарий из многочасового квеста в одну команду или один клик.
Дальше мы отказались от мысли делать всё сразу и пошли дорогой «золотого пути». Один способ создать сервис, один способ задеплоить, один способ увидеть логи и метрики, и всё это по умолчанию, а не по принуждению. Мы не запрещали ходить в обход, но обход перестал быть единственным входом. Ключевой сдвиг в мышлении был в том, что платформенная команда стала не инфраструктурным отделом с большими полномочиями, а продуктовой командой со своими внутренними пользователями, метриками и даже роадмапом.
Где это реально окупилось на цифрах у нас: время от идеи до первого деплоя нового сервиса сократилось примерно с трёх дней до сорока минут, частота релизов выросла в разы, а доля времени, которую продуктовые команды тратили на инфраструктуру вместо фич, упала с четверти до однозначных процентов. Но важнее другое: исчезли очереди в инфраструктурную команду, а вместе с ними и постоянное чувство вины у всех участников. Люди начали выпускать, а не договариваться.
Но я честно скажу и обратное: Platform Engineering не окупается автоматически. Если вас меньше пятнадцати-двадцати инженеров, если процессы меняются каждую неделю, если нет повторяющихся болей, а есть просто желание иметь красивое слово в резюме, то внутренняя платформа превратится в дорогую игрушку. Мы однажды посчитали: содержать даже небольшую платформенную команду стоит примерно как два-три полноценных инженера, и эти люди обязаны экономить больше, чем стоят сами. Иначе вы просто перекладываете ручную работу из одного места в другое, только теперь ещё и с абстракциями.
Что я советую коллегам, которые думают о таком проекте. Начните с одной самой больной боли и доведите её до состояния «работает само», а не с плана на три года. Считайте деньги и время: время онбординга, время до первого деплоя, время простоя из-за инфраструктуры. Относитесь к платформе как к продукту, с документацией, поддержкой и обратной связью, а не как к внутреннему проекту на энтузиазме. И держите обратный путь открытым: если разработчик может сделать что-то руками лучше и быстрее, платформа обязана быть настолько хорошей, чтобы он сам захотел ей пользоваться.
А теперь интересно ваше мнение. Строил ли кто-то из вас внутреннюю платформу у себя, и в какой момент вы поняли, что она наконец начала окупаться — по цифрам, по настроению команды или по тому, что про неё перестали вспоминать как про проблему? Делитесь опытом, буду рад поспорить и сравнить подходы.
Честно скажу: первый заход был провальным. Мы нарисовали красивую архитектуру, выбрали модный портал, полгода строили, а получили инструмент, которым пользовались два с половиной человека. Главная ошибка была в установке «построим, и они придут»: мы делали платформу для себя, а не для разработчиков, и не спрашивали их, что именно болит. Никакой окупаемости в такой схеме не бывает, потому что ценность создаёт не количество кластеров, а количество людей, которым стало проще работать.
Второй заход мы начали с разговоров. Я прошёл по командам и просто спросил: что отнимает у вас больше всего времени не по делу? Ответы оказались скучными и предсказуемыми: настройка CI, окружения, доступы, секреты, наблюдаемость, стандартный шаблон сервиса. Никто не просил единую панель управления всем на свете. Тогда мы сформулировали для себя простой критерий: платформа окупается там, где она превращает типовой сценарий из многочасового квеста в одну команду или один клик.
Дальше мы отказались от мысли делать всё сразу и пошли дорогой «золотого пути». Один способ создать сервис, один способ задеплоить, один способ увидеть логи и метрики, и всё это по умолчанию, а не по принуждению. Мы не запрещали ходить в обход, но обход перестал быть единственным входом. Ключевой сдвиг в мышлении был в том, что платформенная команда стала не инфраструктурным отделом с большими полномочиями, а продуктовой командой со своими внутренними пользователями, метриками и даже роадмапом.
Где это реально окупилось на цифрах у нас: время от идеи до первого деплоя нового сервиса сократилось примерно с трёх дней до сорока минут, частота релизов выросла в разы, а доля времени, которую продуктовые команды тратили на инфраструктуру вместо фич, упала с четверти до однозначных процентов. Но важнее другое: исчезли очереди в инфраструктурную команду, а вместе с ними и постоянное чувство вины у всех участников. Люди начали выпускать, а не договариваться.
Но я честно скажу и обратное: Platform Engineering не окупается автоматически. Если вас меньше пятнадцати-двадцати инженеров, если процессы меняются каждую неделю, если нет повторяющихся болей, а есть просто желание иметь красивое слово в резюме, то внутренняя платформа превратится в дорогую игрушку. Мы однажды посчитали: содержать даже небольшую платформенную команду стоит примерно как два-три полноценных инженера, и эти люди обязаны экономить больше, чем стоят сами. Иначе вы просто перекладываете ручную работу из одного места в другое, только теперь ещё и с абстракциями.
Что я советую коллегам, которые думают о таком проекте. Начните с одной самой больной боли и доведите её до состояния «работает само», а не с плана на три года. Считайте деньги и время: время онбординга, время до первого деплоя, время простоя из-за инфраструктуры. Относитесь к платформе как к продукту, с документацией, поддержкой и обратной связью, а не как к внутреннему проекту на энтузиазме. И держите обратный путь открытым: если разработчик может сделать что-то руками лучше и быстрее, платформа обязана быть настолько хорошей, чтобы он сам захотел ей пользоваться.
А теперь интересно ваше мнение. Строил ли кто-то из вас внутреннюю платформу у себя, и в какой момент вы поняли, что она наконец начала окупаться — по цифрам, по настроению команды или по тому, что про неё перестали вспоминать как про проблему? Делитесь опытом, буду рад поспорить и сравнить подходы.