Проект перерос одного человека: признаки, которые видно по истории деплоев

MAATRIX

«Вроде справляюсь» — самая ненадёжная метрика в инфраструктуре, потому что она измеряет не состояние проекта, а личный запас терпения конкретного человека, и у этого запаса нет фиксированной единицы измерения. Гораздо честнее спросить не «тяжело ли мне», а «что показывает история деплоев за последние три месяца». Ответ на этот вопрос лежит в git log, в трекере задач и в календаре релизов — и его можно посчитать, не дожидаясь, пока усталость перерастёт в ошибку в проде в три часа ночи.

Почему субъективное ощущение — плохой сигнал

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

Есть и обратный эффект: человек может годами держать высокий темп на энтузиазме и ответственности, и субъективно ему «нормально», а объективные метрики при этом уже несколько месяцев показывают тревожную динамику. Оба искажения — и заниженная, и завышенная самооценка нагрузки — устраняются одним способом: смотреть не на ощущения, а на артефакты, которые проект оставляет сам по себе в процессе работы. Git не умеет врать себе, в отличие от человека, который хочет верить, что ещё немного продержится.

Дальше — четыре конкретных сигнала, которые можно достать из истории деплоев, git log и трекера задач буквально несколькими командами, без опросников и субъективных оценок.

Сигнал 1: интервал между деплоями растёт не из-за нехватки изменений

Первое, что стоит проверить — растёт ли пауза между релизами из-за того, что писать стало нечего, или из-за того, что готовый код физически не успевают выкатить. Это принципиально разные ситуации, и их легко перепутать, если смотреть только на календарь релизов, не сверяясь с git log.

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

# список тегов релизов с датами, от старых к новым
git tag --sort=creatordate --format='%(creatordate:short) %(refname:short)'

# число коммитов в main между двумя релизами
git log v1.4.0..v1.5.0 --oneline | wc -l
git log v1.5.0..v1.6.0 --oneline | wc -l

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

Полезно дополнительно построить график интервалов между тегами релизов по месяцам — тренд виден нагляднее, чем голые цифры:

git log --tags --simplify-by-decoration --pretty="format:%ai %d" | grep tag

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

Сигнал 2: доля экстренных деплоев вне расписания растёт

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

Если релизы помечены отдельно (например, тег hotfix-* или коммиты с префиксом fix:/hotfix: по Conventional Commits), посчитать долю несложно:

# все теги релизов за период
git tag --sort=creatordate | grep -E "v[0-9]" | wc -l

# из них hotfix-релизы
git tag --sort=creatordate | grep -i hotfix | wc -l

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

# коммиты по часам суток — видно, есть ли ночная активность
git log --since="3 months ago" --date=format:'%H' --pretty=format:'%ad' | sort | uniq -c | sort -rn

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

Сигнал 3: время между «код готов» и «код в проде» растёт

Третий сигнал — самый прямой индикатор bottleneck именно в развёртывании, а не в разработке. Если задачи в трекере закрываются («готово к релизу», код смержен в основную ветку) быстро, а время от мержа до фактического появления в проде растёт — узкое место не в том, как быстро пишется код, а в том, что дальше с ним некому вовремя разобраться.

Если в трекере фиксируются даты смены статусов, разница между «готово к релизу» и «в проде» — прямая метрика лид-тайма выкатки:

# дата мержа в main для каждого коммита в диапазоне
git log main --since="2026-06-01" --pretty=format:'%H %ad %s' --date=short

# сопоставить с датами деплой-тегов на этот коммит
git log --tags --pretty=format:'%H %ad %D' --date=short | grep tag:

На практике проще всего вести это не вручную, а через CI/CD-систему, если она уже есть: у GitHub Actions, GitLab CI и большинства пайплайнов в логах есть время старта и завершения деплоя, а время мержа — в истории PR. Разница между «PR смержен» и «деплой начался» — и есть тот самый лаг, накопление которого прямо указывает на нехватку рук на этапе развёртывания.

Важный нюанс: сам по себе рост этого лага на день-два в отдельные недели — это нормальная вариативность, не сигнал. Сигнал — устойчивый тренд на протяжении двух-трёх месяцев подряд, а не разовые всплески перед отпуском или праздниками.

Сигнал 4: тикеты «нужно бы настроить X» копятся и не закрываются

Четвёртый сигнал ищется не в git log, а в трекере задач — и он касается не текущих проблем, а тех улучшений инфраструктуры, которые постоянно откладываются. Типичная формулировка: «нужно бы настроить мониторинг», «стоит автоматизировать бэкапы», «пора вынести конфиг из ручных правок» — задачи, которые не блокируют работу здесь и сейчас, поэтому легко переносятся на следующий спринт, а потом на следующий.

Проверка простая: отфильтруйте в трекере задачи с тегом вроде infra, tech-debt, chore и посмотрите на возраст открытых задач и динамику их числа за последние полгода.

• Растёт ли число открытых задач этой категории быстрее, чем закрывается?
• Какой у них средний возраст с момента создания? Если счёт идёт на месяцы, а не на недели — это не приоритет, а фоновый шум, который никто никогда не разгребёт при текущей нагрузке.
• Сколько раз задача переносилась из спринта в спринт без единого комментария по существу?

Если у трекера есть API или экспорт, накопление легко визуализировать без ручного пересчёта:

# пример для Jira: экспорт задач с меткой infra и датами создания/закрытия
# (замените на реальный запрос под свой трекер)
curl -s -u "$JIRA_USER:$JIRA_TOKEN" \
  "https://your-domain.atlassian.net/rest/api/2/search?jql=labels=infra&fields=created,resolutiondate&maxResults=200" \
  | jq '.issues[].fields'

Здесь работает та же логика, что и с техническим долгом инфраструктуры в целом: он не исчезает сам, а копится тихо, пока не сработает — в виде инцидента, который можно было предотвратить той самой отложенной задачей. Разница в том, что здесь долг накапливается не потому что о нём не знают, а потому что единственный ответственный человек физически не успевает добраться до улучшений между текущими пожарами: любая задача «сделать лучше» проигрывает по приоритету задаче «прод не работает прямо сейчас».

Как посчитать всё вместе, а не по отдельности

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

Практический подход — свести все четыре метрики в одну простую таблицу по месяцам и смотреть на тренд, а не на абсолютные цифры одного месяца:

(Цифры в таблице — иллюстрация метода, а не ориентир «нормы»: у каждого проекта своя базовая скорость релизов и свой допустимый уровень экстренных деплоев, поэтому важна не абсолютная цифра, а собственная динамика проекта во времени.)

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

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

Честный вывод: откладывание найма обходится дороже зарплаты

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

Цена откладывания складывается не из одной статьи, а из нескольких, которые редко считают вместе:

• Упущенные фичи. Каждый час, потраченный единственным администратором на тушение пожара, — это час, не потраченный на развитие продукта. При растущей доле экстренных деплоев эта цена растёт нелинейно, потому что пожаров становится больше, а времени на плановую работу — меньше.
• Риск инцидента без резерва. Пока в проекте один человек, у компании нет плана Б на случай его недоступности — отпуска, болезни, ухода. Это ровно та же логика, что разобрана в статье про bus factor, равный единице: риск не исчезает сам, он просто остаётся неоценённым, пока не реализуется в худший момент.
• Накопленный технический долг. Каждая отложенная задача по инфраструктуре — это будущий инцидент, который обойдётся дороже, чем стоило бы её вовремя закрыть. Долг в инфраструктуре, в отличие от долга в коде, растёт не только от бездействия, а ещё и от внешнего давления — устаревающих версий, заканчивающейся поддержки, новых уязвимостей.
• Выгорание единственного ответственного. Это самая недооценённая статья расходов, потому что она реализуется не сразу: человек может продержаться месяцы на энтузиазме, а потом уйти резко, забрав с собой знания, которые нигде не задокументированы, — и тогда компания одновременно теряет специалиста и получает груду непрозрачной инфраструктуры.

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

Частые вопросы