Стандартизируйте один стек, не замедляя маленькую команду

Почему расползание стека возвращается снова и снова

Разрастание стека редко начинается со стратегии. Обычно всё начинается в обычный тяжёлый вторник. Сдвигается срок, одну функцию нужно срочно выпустить, и кто-то говорит: «Я могу собрать это в другом инструменте к пятнице». Команда соглашается, потому что сказать «нет» кажется медленнее.

Новый инструмент часто работает. В этом и ловушка. Временные решения живут намного дольше, чем сам аврал. Через полгода у компании уже два пути сборки, три способа тестирования и ещё одна вещь, за которую никто толком не хочет отвечать.

Небольшие компании попадают в такую ситуацию, потому что на первой неделе всё выглядит дёшево. Настоящая цена проявляется позже — в исправлении багов, найме, онбординге, поддержке и дежурствах по ночам. Новые сотрудники могут раздвигать стек ещё быстрее. У большинства инженеров есть любимые языки, framework'и и cloud-сервисы. Это нормально. Проблемы начинаются тогда, когда у компании нет чёткой базы по умолчанию. Тогда каждый новый сотрудник относится к кодовой базе как к новому голосованию, а не как к работе в уже существующей системе.

Важна и зона ответственности. Продукту нужна скорость. Инженерам нужны знакомые инструменты. Операциям нужно меньше движущихся частей. Все эти цели разумны, но кто-то всё равно должен решить, что команда будет поддерживать, а от чего перестанет зависеть. В маленькой команде это обычно основатель, CTO или Fractional CTO.

Уборка — последнее, куда обычно смотрят команды. После запуска все переходят к следующему дедлайну. «Временный» сервис продолжает работать, начинает хранить данные и превращается во что-то слишком раздражающее, чтобы его удалять. Так расползание и становится нормой.

Простой способ сопротивляться этому — относиться к каждому новому инструменту как к аренде, а не к покупке. Назовите владельца, задайте срок окончания теста и сразу укажите, что именно он заменяет. Если пропустить эти шаги, стек снова начнёт превращаться в хаос.

Сначала определите, что должен делать ваш стек

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

Запишите все продукты и системы, которые вы поддерживаете сегодня. Обычно это не только основное приложение. У вас может быть клиентское web-приложение, API, фоновые задачи, административная панель, внутренние скрипты и, возможно, мобильное приложение. Если пропустить этот список, вы выберете инструменты для продукта, о котором чаще говорят, а не для того, который создаёт больше всего работы в поддержке.

Потом посмотрите на навыки, которые уже есть внутри команды. Эта часть не самая эффектная, но она экономит месяцы боли. Если большинство команды уверенно работает с TypeScript, PostgreSQL и React, это важнее, чем желание одного инженера попробовать новый язык. Небольшим компаниям не нужен «лучший» стек на бумаге. Им нужен стек, с которым текущая команда сможет нормально жить и работать в обычную неделю.

Не менее важны ограничения по стоимости и поддержке. Задайте реальный потолок для хостинга, платных сервисов, времени сборки и усилий на поддержку. Некоторые инструменты кажутся дешёвыми, пока не посчитаешь дополнительные панели, алерты, лицензии и починку в выходные. Работа Oleg Sotnikov в AppMaster.io и в роли Fractional CTO показывает тот же вывод: архитектурные решения могут заметно сократить расходы на cloud, но только если команда с самого начала воспринимает стоимость и поддержку как ограничения дизайна.

Ограничений должно быть немного, и они должны быть понятными. Для большинства небольших команд это значит один backend language, одна основная база данных, один cloud-провайдер и короткие сроки для экспериментов. Если новый инструмент не подходит под ваши продукты, вашу команду и ваш бюджет, его не должно быть в списке утверждённых.

Разделите все инструменты на три группы

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

Самый простой способ — разделить инструменты на три группы и сделать этот список видимым:

• Default — инструмент, который команда использует по умолчанию, если только кто-то не получил одобрение на исключение
• Trial — короткий эксперимент с владельцем, понятной причиной и фиксированной датой окончания
• Banned — инструмент, который команда не будет использовать в новых задачах

Наиболее важна группа Default. Выберите по одному инструменту для каждой частой задачи: frontend, backend, база данных, hosting, testing, monitoring и design system. Одного стандарта на каждую задачу достаточно. Если два инструмента решают одну и ту же проблему, один из них обычно просто добавляет больше поддержки.

Группа Banned не менее важна. Запишите, какие инструменты под запретом и почему. Причина может быть короткой: слишком дорого, сложно нанимать людей, плохо подходит под вашу инфраструктуру или слишком дорого обходится в поддержке. Это сразу гасит бесконечный аргумент «ну только для этого клиента».

Группа Trial помогает команде оставаться любопытной, не вскрывая весь стек заново. Для каждого теста нужны дата начала, дата окончания и один ответственный за результат. Тридцати дней обычно хватает, чтобы понять, экономит инструмент время или создаёт новую работу. Если к сроку ответ всё ещё размытый, уберите его.

Дайте одному человеку право одобрять исключения. Не передавайте это комитету или оживлённому групповому чату. Один владелец может защищать стандартный стек и при этом разрешать редкие случаи, где действительно нужно что-то другое.

Хорошее правило простое: если инструмента нет в списке Default или в активном списке Trial, никто не использует его для новых задач.

Как выбрать стек по умолчанию

Начните с продукта, который приносит деньги. Ваш стек по умолчанию должен делать этот продукт проще в выпуске, поддержке и изменениях. Если ваша компания в основном работает с web-приложением, простым API и обычной бизнес-логикой, вам, скорее всего, не нужны пять вариантов языков и три способа развёртывания.

Выберите по одному стандарту для каждого слоя. Для многих небольших команд это означает один backend language, один UI framework и PostgreSQL, если только нет реального ограничения. Смысл не в моде. Смысл в том, чтобы понятие «норма» было очевидным уже в первый день.

Часто лучший выбор — скучный. Используйте инструменты, с которыми команда может отлаживать, развёртывать и мониторить систему без внешних специалистов каждый раз, когда что-то ломается. Если никто в штате не может уверенно настроить cluster, исправить сбой сборки или обновить runtime, такой инструмент не должен быть стандартом.

Оформите политику как короткий список утверждённых инструментов, а не как длинное эссе. Одна страница, которую можно быстро просмотреть, полезнее, чем wiki, которую никто не читает. Укажите стандартные решения для backend, frontend, данных, инфраструктуры, мониторинга, тестирования и CI. Затем добавьте одно понятное правило исключений: проект может просить что-то другое только тогда, когда стандарт не закрывает жёсткое требование, например ограничение платформы, строгую цель по latency или контракт с клиентом. «Разработчику просто так удобнее» — не причина.

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

Потом проверьте политику на одном реальном проекте. После запуска посмотрите, что шло легко, что замедляло команду и что создавало неожиданную работу в CI, хостинге или поддержке. Один стек не означает один стек навсегда. Это означает один стандарт, пока реальность не покажет обратное.

Пишите правила, которым люди действительно будут следовать

Большинство политик по стеку проваливаются потому, что никто не хочет читать длинный документ перед тем, как выбрать библиотеку. Сделайте политику на одну страницу и положите её туда, где команда уже работает. Она должна легко находиться во время настройки, code review и планирования.

Используйте одни и те же три метки везде: Default, Trial и Banned. Для большинства небольших команд этого достаточно. И это же убирает необходимость превращать каждый выбор инструмента в отдельное совещание.

Рядом с каждым запрещённым инструментом добавьте одну короткую причину. Будьте прямыми и полезными. «Слишком дорого для нашего масштаба», «Нет активного сопровождающего в нашей команде» или «Дублирует инструмент по умолчанию» дают людям контекст и убирают повторяющиеся споры.

У каждого утверждённого инструмента тоже должен быть владелец. Назначьте одного человека, даже если команда очень маленькая. Этот человек следит за обновлениями, проверяет, заслуживает ли инструмент своего места, и отвечает на первый круг вопросов, когда кто-то просит исключение. Не назначайте владельцем «engineering» или «backend team». Общая ответственность обычно означает отсутствие ответственности.

У тестов должны быть жёсткие даты окончания. Если оставить тест открытым, он случайно станет частью стека. Назначьте дату проверки, запишите её и уберите просроченные тесты, если только владелец не сможет коротко обосновать, почему их стоит оставить.

Простой пример показывает, как это работает. Допустим, два разработчика хотят новый инструмент очередей. Пометьте его как Trial, назначьте Nina владельцем и поставьте проверку на 30 мая. Если Nina к этому времени не сможет показать, что инструмент снижает количество сбоев или упрощает поддержку, команда убирает его и оставляет стандарт.

Пример для маленькой команды

Представьте команду из шести человек с одним клиентским web-приложением и одним API. Этого уже вполне достаточно для расползания инструментов, если каждый разработчик строит систему в своём любимом стиле.

Поэтому команда рано проводит жёсткую границу. Большая часть новой работы идёт в один стандартный стек: TypeScript, Node.js, PostgreSQL и один cloud-провайдер. Это не эффектно. Это практично. Все могут читать код, исправлять ошибки, выкатывать изменения и дежурить по поддержке, не изучая второй способ делать ту же работу.

Потом один разработчик предлагает второй frontend framework для части продукта. Аргументы звучат разумно. Этот framework может быть быстрее для одного экрана, и разработчик уже хорошо его знает. Но команда всё равно говорит «нет».

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

Но небольшой и узкий эксперимент команда всё же разрешает, если он в более безопасной зоне. Они хотят протестировать инструмент очередей, поэтому используют его для отложенных email-напоминаний, а не для биллинга или аутентификации. В течение двух недель они смотрят на несколько простых сигналов: может ли та же команда развёртывать и мониторить его без особой помощи, не создаёт ли он новые точки отказа ночью, можно ли объяснить его в короткой внутренней заметке и подходит ли он к текущим настройкам логирования и cloud.

Если ответы остаются положительными, инструмент может перейти из Trial в Default. Если он добавляет ещё одну панель, ещё одно особое правило или ещё одного человека, который «просто знает, как это работает», его убирают.

Так небольшая команда продолжает двигаться вперёд, не позволяя стеку разъехаться в пять сторон. Большая часть работы остаётся скучной — и это сделано намеренно. Новые инструменты зарабатывают своё место в коротком тесте и остаются только тогда, когда поддержка по-прежнему проста.

Ошибки, которые снова запускают спор об инструментах

Политика по стеку редко ломается в один драматический момент. Обычно она расползается через маленькие исключения, которые в тот момент кажутся безобидными.

Одна частая ошибка — позволять каждому проекту выбирать свой framework. Команда убеждает себя, что одно приложение может жить на React, другое на Vue, а третье может попробовать что-то новое, потому что это «всего лишь небольшой проект». На неделю это кажется быстрым решением. Потом компания платит за это онбордингом, code review, общей UI-работой и багфиксами.

Бессрочные тесты создают ту же проблему. Команда говорит, что инструмент временный, но никто не отвечает за пересмотр. Через три месяца тест уже в продакшене, и все считают его утверждённым. У каждого эксперимента должна быть дата начала, один владелец и дата остановки.

Legacy-инструменты создают другой вид путаницы. Некоторые старые системы остаются на месте, потому что заменить их сейчас слишком дорого. Это нормально. Ошибка в другом — считать их подходящими для новых задач. Если база данных, framework или сервис относятся к legacy, так их и помечайте, и не допускайте в новые проекты.

Ещё одна частая ошибка — покупать софт до того, как вы назвали настоящую проблему. «Нам нужен лучший engineering tool» — слишком расплывчато, поэтому все предлагают разное. «Развёртывания занимают 40 минут и падают два раза в неделю» — уже конкретно. Команды принимают лучшие решения, когда сначала формулируют проблему простыми словами, а потом сравнивают продукты.

Скрытые исключения вредят сильнее всего. Если основатель или тимлид в чате говорит одному разработчику «просто используй то, что работает», письменная политика теряет силу. Исключения должны быть видимыми. В короткой записи должно быть указано, что это за исключение, кто его одобрил, почему команда его разрешила и когда его снова пересмотрят.

Для маленькой компании это может звучать жёстко. Но всё равно проще, чем через полгода поддерживать пять разных способов делать один и тот же продукт.

Короткая ежемесячная проверка стека

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

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

Количество инструментов говорит о многом. Если одному продукту нужно восемь сервисов, а другому четыре, спросите почему. Иногда на это есть хорошая причина. Но часто её нет, и лишние части только добавляют настройку, алерты и вещи, которые могут сломаться.

Дубли — это то место, где прячутся расходы. У команды может быть PostgreSQL в одном продукте, MongoDB в другом, Redis для одной очереди и ещё одна очередь в побочном проекте. Каждый выбор добавляет документацию, резервные копии, мониторинг и стресс для поддержки. Не нужно разом убирать все исключения, но нужно их назвать и решить, останутся ли они.

Новые сотрудники — ещё один сигнал. Если двум новым разработчикам нужен целый день, чтобы освоить один странный внутренний инструмент, значит стек уже уходит от того, что команда действительно может хорошо поддерживать. Это не всегда означает, что сотрудник был неудачным. Часто это означает, что правило неясно или команда пропустила обучение.

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

К концу проверки у вас должно быть три результата: что-то убрать, что-то пересмотреть и что-то обучить. Этого достаточно, чтобы держать стек в порядке, не превращая процесс в бюрократию.

Следующие шаги для вашей команды

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

Поставьте дедлайн в 30 дней. За этот месяц владелец должен перечислить инструменты, которые вы уже используете, разделить их на Default, Trial и Banned, написать правила для новых работ и исключений и опубликовать версию 1 политики. Не ждите идеального согласия. Рабочий черновик лучше, чем идеальный документ, который никто не соблюдает.

Используйте следующий проект как проверку. Небольшой внутренний инструмент, новая функция или пилот для клиента подойдут. Смотрите на два момента: сколько времени занимает настройка новой задачи и сколько исключений просит команда. Если оба показателя низкие, политика работает. Если нет, исправьте правила до начала следующего проекта.

Держите первую версию короткой. Для небольшой команды обычно достаточно одной страницы. Люди следуют правилам, которые можно найти за 30 секунд и понять за две минуты.

Если команда всё ещё застряла между двумя или тремя разумными вариантами, может помочь внешний взгляд. Oleg Sotnikov на oleg.is работает Fractional CTO для стартапов и небольших компаний, а его опыт в lean infrastructure и AI first development помогает командам получить практичный взгляд со стороны, когда выбор стека всё время расширяется.