Три года назад я собрал небольшую команду внутри компании, чтобы закрыть вечную жалобу: «Чтобы выкатить новый сервис, нужно две недели и восемь согласований». Мы честно хотели как лучше — сделать так, чтобы разработчик получал репозиторий, конвейер, окружение и мониторинг одной кнопкой. Слово «платформа» тогда звучало гордо. Сегодня, когда через неё проходит больше двухсот сервисов, могу сказать одно: построить её несложно, сложно не превратить её в министерство.
Первая версия была классическим провалом. Мы нарисовали портал, добавили четырнадцать обязательных полей в форму заявки, прикрутили три уровня подтверждений и отдельный комитет по архитектуре. Через полгода выяснилось, что половина команд платформой просто не пользуется: они писали скрипты в своих репозиториях, копировали чужие конфиги и обходили портал целиком. Бюрократия рождается там, где платформа становится единственным путём и одновременно самым медленным. Разработчик всегда найдёт обход, если обход быстрее.
Второй подход мы начали с простого правила: платформа — это продукт, а не отдел контроля. Значит, есть пользователи, у которых можно и нужно спрашивать, есть владелец продукта, есть роадмап и есть метрики. Мы отказались от идеи заставить и заменили её идеей соблазнить: сделать так, чтобы по нашему пути было быстрее и спокойнее, чем в обход.
Технически всё свелось к аскетичному набору. Есть шаблон репозитория, есть один небольшой файл описания сервиса, и есть конвейер, который по этому описанию сам собирает образ, поднимает окружения, подключает секреты, алерты и деплой. От идеи до готового скелета в продакшене у новичка уходило минут пятнадцать. Ключевое слово здесь — «по умолчанию», а не «обязательно».
Отдельно скажу про лазейку, которую я считаю главным антибюрократическим механизмом. Если наш шаблон не подходит — например, команде нужен необычный стек — она имеет право сделать всё руками. Мы не блокируем, не требуем объяснительных и не заводим тикет на согласование. Мы только честно предупреждаем: в этом случае поддержку и совместимость команда берёт на себя. Эта честность убрала самое неприятное — ощущение, что тебя принуждают.
Метрики мы тоже выбрали неудобные для самолюбия. Смотрим не на количество фич, а на время до первого деплоя у нового сотрудника, на долю сервисов, живущих на золотом пути, на число ручных согласований в процессе и на время от коммита до продакшена. Если растёт количество функций, а время до первого деплоя не падает, значит, мы занимались не тем. Раз в квартал мы без сожалений выключаем всё, чем не пользуются хотя бы несколько команд: кладбище заброшенных внутренних инструментов — прямая дорога к бюрократии.
Управление изменениями у нас намеренно лёгкое. Любое архитектурное решение оформляется одной страницей: что меняем, зачем, кого затрагивает, как откатить. Ревью — три рабочих дня, и если за это время никто не возразил по существу, решение считается принятым. Дедлайн здесь не формальность, а защита от бесконечного согласования. Никаких комитетов на пять человек и тридцатистраничных регламентов: они не добавляют качества, зато отлично добавляют задержку.
Если сжимать опыт в рекомендации: начинайте с трёх самых болезненных сценариев, а не с красивой архитектуры; не стройте портал, стройте путь по умолчанию; оставляйте людям возможность выйти за его пределы; относитесь к внутренним разработчикам как к клиентам, у которых есть право уйти; измеряйте время, а не количество функций; и не бойтесь выключать собственное творение. А теперь вопрос к вам, коллеги: что в вашей внутренней платформе стало самым неожиданным источником бюрократии — и как вы с этим справились? Расскажите, очень интересно сравнить опыт.
Первая версия была классическим провалом. Мы нарисовали портал, добавили четырнадцать обязательных полей в форму заявки, прикрутили три уровня подтверждений и отдельный комитет по архитектуре. Через полгода выяснилось, что половина команд платформой просто не пользуется: они писали скрипты в своих репозиториях, копировали чужие конфиги и обходили портал целиком. Бюрократия рождается там, где платформа становится единственным путём и одновременно самым медленным. Разработчик всегда найдёт обход, если обход быстрее.
Второй подход мы начали с простого правила: платформа — это продукт, а не отдел контроля. Значит, есть пользователи, у которых можно и нужно спрашивать, есть владелец продукта, есть роадмап и есть метрики. Мы отказались от идеи заставить и заменили её идеей соблазнить: сделать так, чтобы по нашему пути было быстрее и спокойнее, чем в обход.
Технически всё свелось к аскетичному набору. Есть шаблон репозитория, есть один небольшой файл описания сервиса, и есть конвейер, который по этому описанию сам собирает образ, поднимает окружения, подключает секреты, алерты и деплой. От идеи до готового скелета в продакшене у новичка уходило минут пятнадцать. Ключевое слово здесь — «по умолчанию», а не «обязательно».
Отдельно скажу про лазейку, которую я считаю главным антибюрократическим механизмом. Если наш шаблон не подходит — например, команде нужен необычный стек — она имеет право сделать всё руками. Мы не блокируем, не требуем объяснительных и не заводим тикет на согласование. Мы только честно предупреждаем: в этом случае поддержку и совместимость команда берёт на себя. Эта честность убрала самое неприятное — ощущение, что тебя принуждают.
Метрики мы тоже выбрали неудобные для самолюбия. Смотрим не на количество фич, а на время до первого деплоя у нового сотрудника, на долю сервисов, живущих на золотом пути, на число ручных согласований в процессе и на время от коммита до продакшена. Если растёт количество функций, а время до первого деплоя не падает, значит, мы занимались не тем. Раз в квартал мы без сожалений выключаем всё, чем не пользуются хотя бы несколько команд: кладбище заброшенных внутренних инструментов — прямая дорога к бюрократии.
Управление изменениями у нас намеренно лёгкое. Любое архитектурное решение оформляется одной страницей: что меняем, зачем, кого затрагивает, как откатить. Ревью — три рабочих дня, и если за это время никто не возразил по существу, решение считается принятым. Дедлайн здесь не формальность, а защита от бесконечного согласования. Никаких комитетов на пять человек и тридцатистраничных регламентов: они не добавляют качества, зато отлично добавляют задержку.
Если сжимать опыт в рекомендации: начинайте с трёх самых болезненных сценариев, а не с красивой архитектуры; не стройте портал, стройте путь по умолчанию; оставляйте людям возможность выйти за его пределы; относитесь к внутренним разработчикам как к клиентам, у которых есть право уйти; измеряйте время, а не количество функций; и не бойтесь выключать собственное творение. А теперь вопрос к вам, коллеги: что в вашей внутренней платформе стало самым неожиданным источником бюрократии — и как вы с этим справились? Расскажите, очень интересно сравнить опыт.