Нашли скрипт без комментариев, который держит продажи: что делать

MAATRIX

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

Сначала — оценка реального влияния, а не догадки

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

Начните с того, кто и что его запускает:

# кто и когда его вызывает по расписанию
crontab -l
systemctl list-timers --all
grep -r "имя_скрипта" /etc/cron.d/ /etc/systemd/system/ 2>/dev/null

# кто держит с ним активные соединения прямо сейчас
ss -tnp | grep <порт_или_pid>
lsof -p <PID>

Дальше — куда уходит его результат. Если скрипт пишет файл, найдите, кто его читает:

# кто в системе обращается именно к этому файлу
grep -rl "имя_выходного_файла" /opt /srv /etc 2>/dev/null
lsof | grep имя_выходного_файла

Если он пишет в базу — посмотрите, какие таблицы он трогает (grep -i "INSERT\|UPDATE\|SELECT" script.py) и кто ещё читает эти же таблицы через pg_stat_activity или логи медленных запросов. Отдельно стоит поговорить с людьми — бухгалтерией, складом, поддержкой: часто именно они первыми заметят, что «отчёт не пришёл», и знают о зависимости больше, чем любой лог. Составьте короткий список: что скрипт делает, кто полагается на результат, что случится в первый час после сбоя и через сутки. Для скрипта, который раз в неделю дублирует отчёт, план один, для того, что стоит между заказом и списанием денег, — совсем другой.

Снимок «как есть» и версионирование до единой правки

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

# копия с сохранением метаданных, отдельно от рабочей директории
cp -p /opt/scripts/process_orders.sh /root/legacy-backup/process_orders.sh.$(date +%Y%m%d)

# контрольная сумма — чтобы позже доказать, что файл не менялся
sha256sum /opt/scripts/process_orders.sh > /root/legacy-backup/process_orders.sh.sha256

# и сразу в git, даже если это единственный файл в репозитории
mkdir -p /root/legacy-repo && cp /opt/scripts/process_orders.sh /root/legacy-repo/
cd /root/legacy-repo && git init && git add . && git commit -m "Снимок скрипта до исследования, автор неизвестен"

Если скрипт — это не один файл, а директория с зависимостями (конфиги, модули, cron-обвязка), заархивируйте всё целиком с правами и владельцем (tar --same-owner -czvf), а копию унесите за пределы того же сервера — если причина проблемы окажется в диске, локальная копия рядом с оригиналом не спасёт. С этого момента у вас есть контрольная точка: что бы ни случилось дальше при экспериментах, всегда можно свериться с sha256sum и убедиться, что рабочая версия на проде не тронута.

Тестовое окружение, где можно ломать без последствий

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

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

# посмотреть, куда скрипт лезет по сети, не запуская его вслепую
grep -oE "https?://[^\"' ]+" process_orders.sh
grep -iE "curl|wget|requests\.|psycopg2|mysql|smtp" process_orders.sh

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

Только после того, как тестовое окружение изолировано от прод-зависимостей, есть смысл запускать скрипт руками и наблюдать за поведением — это следующий шаг.

Логируем каждый вызов, прежде чем читать код построчно

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

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

# process_orders.sh -> process_orders.real.sh (оригинал не тронут)
mv /opt/scripts/process_orders.sh /opt/scripts/process_orders.real.sh

cat > /opt/scripts/process_orders.sh << 'EOF'
#!/usr/bin/env bash
LOG="/var/log/legacy-audit/process_orders.log"
mkdir -p "$(dirname "$LOG")"
echo "[$(date '+%F %T')] CALL args=$* env_user=$(whoami) cwd=$(pwd)" >> "$LOG"

/opt/scripts/process_orders.real.sh "$@"
STATUS=$?

echo "[$(date '+%F %T')] EXIT status=$STATUS" >> "$LOG"
exit $STATUS
EOF
chmod +x /opt/scripts/process_orders.sh

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

strace -f -tt -e trace=network,file -o /tmp/trace.log ./process_orders.real.sh
grep -E "connect|open|unlink" /tmp/trace.log

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

Читаем код методично: что можно восстановить без автора

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

Практический порядок разбора:

1. Точки входа и выхода. Что скрипт принимает на вход (аргументы, переменные окружения, файлы, стандартный ввод) и что отдаёт на выходе (файл, код возврата, запись в базу, HTTP-запрос). Это даёт контракт, даже если внутренняя логика непонятна.
2. Внешние вызовы. grep по ключевым словам обращения наружу — curl, requests, psql, smtplib, системные вызовы subprocess/os.system. Каждый такой вызов — это точка, где скрипт что-то меняет вне себя, и именно эти точки стоит понять в первую очередь, а не внутреннюю арифметику.
3. Магические числа и захардкоженные значения. ID склада, курс пересчёта, таймаут, лимит — если такое число встречается без объяснения, ищите его в базе или в других системах: возможно, это внешний идентификатор, который просто скопировали в код в момент написания.
4. Ветвления с редкими условиями. Блоки if, которые срабатывают только в специфических случаях (конец месяца, определённый регион, конкретный статус заказа), — обычно самые непрозрачные и самые рискованные места: именно там чаще всего прячется бизнес-правило, которое никто не помнит, зачем добавили.

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

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

Постепенная замена вместо резкого переписывания

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

Теневой запуск (shadow mode). Новая реализация запускается параллельно со старой на тех же входных данных, но её результат никуда не идёт — он только логируется и сравнивается с результатом оригинала:

# оба варианта получают одни и те же данные,
# но в дело идёт только результат старого скрипта
OLD_RESULT=$(./process_orders.real.sh "$@")
NEW_RESULT=$(./process_orders_v2.sh "$@")

if [ "$OLD_RESULT" != "$NEW_RESULT" ]; then
    echo "[$(date '+%F %T')] DIFF old='$OLD_RESULT' new='$NEW_RESULT'" >> /var/log/legacy-audit/shadow-diff.log
fi

echo "$OLD_RESULT"

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

Замена по частям, а не целиком. Если скрипт делает несколько независимых вещей (например, сначала пересчитывает остатки, потом формирует отчёт, потом отправляет уведомление), переносите на новую реализацию только один шаг за раз, оставляя остальные на старом коде. Так при проблеме откат затрагивает одну функцию, а не весь процесс целиком.

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

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

Когда оставить как есть, а когда переписывать

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

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

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