← Назад в блог

Что я смотрю за первые 15 минут на проекте, который уже горит

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

За восемь лет я выработал один рефлекс: первые 15 минут на чужом проекте — самые честные. Потом привыкаешь. Появляется контекст, начинается самообман, глаза замыливаются. Через час ты уже мыслишь категориями человека, который это написал.

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

Почему первые 15 минут — самые честные

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

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

Поэтому я открываю таймер и работаю по протоколу. 15 минут. Потом записываю первое впечатление — до того, как начну «понимать».

Первый экран: до кода

Я не открываю IDE первым делом. Три вещи, которые видны без credentials.

curl -I https://site.ru. Смотрю, что отдаёт сервер: версия PHP, тип сервера, наличие X-Powered-By. Если PHP 7.4 в 2026 году — это уже вопрос. Если версия CMS в заголовках — кто-то не читал базовые security checklist'ы.

robots.txt и sitemap. Есть ли они вообще. Закрыты ли admin-панели от индексации. Не SEO-вопрос — вопрос про внимание команды к деталям.

Как деплоят. Если есть CI/CD, смотрю pipeline. Если нет, спрашиваю. «FTP вручную» — один тип проекта. «Скрипт на сервере» — другой. «Не знаем» — третий.

За три минуты эти три экрана дают первое ощущение зрелости процессов.

Репозиторий: три сигнала за 60 секунд

Если есть доступ к репозиторию, открываю и смотрю три вещи в этом порядке.

composer.lock в репозитории? Если нет — зависимости не фиксированы. composer install в production может дать другой результат, чем в staging. Это источник «но у меня работало».

Секреты в git-истории. git log --oneline --all | head -20 плюс поиск .env в коммитах. Если .env с настоящими credentials когда-либо попадал в репо — вопрос безопасности открыт, даже если сейчас файл в .gitignore.

Дата и частота последних коммитов. Если последний коммит три месяца назад, а проект «горит» — горел давно, просто никто не чинил. Если коммиты хаотичные, без конвенции сообщений — команда работала без дисциплины.

60 секунд — и понятно, есть ли базовые инженерные практики.

Production-конфигурация: четыре маркера

Следующие пять минут — production-сторона.

Сессии. PHP-проекты на Bitrix — в первую очередь смотрю, где хранятся. Файловые сессии под нагрузкой = заблокированные FPM-воркеры. Я видел, как сервер ложился в 23:00 именно из-за этого. Один grep -r "session" /etc/php* или взгляд в php.ini — сразу понятно.

OPcache. Включён ли вообще. Что в opcache.revalidate_freq и opcache.validate_timestamps. Если validate_timestamps=1 и revalidate_freq=0 в production — кэш проверяет каждый файл на каждый запрос. Классика разработчика, который забыл, что он в production.

Логи ошибок. tail -100 /var/log/php_errors.log. Если там 400 строк за час — что-то стабильно сломано и работает «вопреки». Если логов нет вообще, скорее всего display_errors = On и log_errors = Off. Разработка без логирования.

Cron. crontab -l. В горящих проектах cron часто умер тихо: задачи в crontab есть, но скрипты давно падают с ошибками, и никто не замечал. Особенно если email-уведомления шли на уволившегося разработчика.

Пять минут — и понятно, работает ли production или просто не падает.

Один вопрос команде

После технической части — разговор с человеком, который ближе всего к проекту. Владелец, PM, последний разработчик.

Один вопрос: «Что вы точно знаете, что работает — и чего боитесь сломать?»

Если называют конкретную функцию или интеграцию — она критичная. Если говорят «не знаем» — либо нет документации, либо никто не разбирался достаточно глубоко. «Не знаем» от владельца — это тоже диагноз.

Второй вопрос, если есть время: «Когда последний раз это работало нормально?» Это даёт точку отсчёта.

Больше не спрашиваю. Два вопроса — максимум. Каждый следующий даёт меньше сигнала и больше контекста, который начнёт влиять на восприятие.

Что это говорит о цене ремонта

К концу 15 минут у меня есть не оценка, а сигнал.

Хороший сигнал: composer.lock есть, Redis-сессии, OPcache настроен, логи пишутся, cron мониторится. Починить конкретную проблему — посильно.

Плохой сигнал: файловые сессии, нет composer.lock, display_errors = On, логи пустые или переполнены ошибками, cron умер. Здесь «починить одно» означает вскрыть несколько смежных. Оценка умножается на 2-3.

Очень плохой сигнал: секреты в репозитории, PHP 7.2, нет git-истории, владелец не знает, что работает. Здесь разговор не про ремонт, а про то, стоит ли браться. Я вычисляю трудных клиентов до старта — то же умение применяется к проектам. Иногда правильный ответ — не брать.

Автомеханик смотрит на машину перед покупкой: 15 минут внешнего осмотра дают 80% информации. Остальное — в разборке, и она стоит денег.

Если интересно, как выглядит pre-project checklist до того, как принять горящий проект — для случая, когда ещё есть время на оценку, — смотри три проверки до любого headless-проекта. Здесь — то, что делаешь, когда времени уже нет.

Чек-лист: 15 пунктов за 15 минут

До кода (3 мин):

  1. curl -I — версия PHP, заголовки, X-Powered-By
  2. robots.txt — закрыт ли admin
  3. Как деплоят (CI/CD, скрипт, FTP?)

Репозиторий (2 мин):

  1. composer.lock в репо — да/нет
  2. Секреты в git-истории — поиск .env
  3. Дата и частота последних коммитов

Production (5 мин):

  1. Где хранятся сессии — файлы или Redis
  2. OPcache — включён, validate_timestamps, revalidate_freq
  3. Логи ошибок — есть, пустые или переполнены
  4. crontab -l — что запущено, уведомления куда идут
  5. df -h — место на диске (горящий проект часто = диск 99%)
  6. free -m — сколько памяти, что ест

Команда (5 мин):

  1. «Что точно работает и чего боитесь сломать?»
  2. «Когда последний раз было нормально?»
  3. Записать первое впечатление — до обсуждения деталей

Протокол не отвечает на все вопросы. Он даёт первичный сигнал — до того, как начнётся привыкание. Дальше — закрываем риски, а не тикеты. Но сначала надо понять, какие риски есть.

Решение принимается в первые 15 минут. Потом ты уже внутри — и выйти сложнее.