Как убедиться, что сервис правда никому не нужен, прежде чем его гасить

MAATRIX

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

Почему «его полгода никто не трогал» — это не доказательство

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

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

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

Смотрим логи за длительный период, а не за последнюю неделю

Первый практический шаг — поднять историю обращений на максимально доступную глубину, а не за последние сутки. Для веб-сервиса это access-лог nginx или Apache:

# ищем обращения к пути сервиса за всё время, что хранят логи, включая архивы
zgrep -h "/legacy-report/" /var/log/nginx/access.log* 2>/dev/null | tail -50

# то же, но с сортировкой по дате первого и последнего обращения
zgrep -h "/legacy-report/" /var/log/nginx/access.log* | awk '{print $4}' | sort | uniq -c | sort -k2

Для systemd-сервиса — журнал systemd, но учтите, что journald по умолчанию хранит логи ограниченное время и объём (подробно о том, как это устроено и где строки теряются, разбирали в статье про журналирование systemd):

journalctl -u legacy-report.service --since "2026-01-01" | less

# сколько раз сервис вообще запускался за год
journalctl -u legacy-report.service | grep -c "Started"

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

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

Полезно проверить и косвенные признаки активности, а не только прямые обращения:

# кто и когда последний раз логинился под сервисным пользователем
lastlog -u service_user

# активные и недавние сетевые соединения к порту сервиса
ss -tnp | grep :8080

# записи в crontab, которые дёргают сервис по расписанию
crontab -l -u service_user
grep -r "legacy-report" /etc/cron.d/ /etc/crontab 2>/dev/null

Если находите cron-задачу с периодом 0 3 1 * * (раз в месяц, первого числа в 3 ночи) — это прямой сигнал, что «отсутствие активности» за последние две недели ничего не значит.

Спросите команду, прежде чем спрашивать `systemctl stop`

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

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

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

1. Спросите в общем канале команды, а не только у того, кто дежурит сейчас. Формулировка вроде «нашёл процесс X на сервере Y, порт Z, последнее обращение — дата. Кто-нибудь знает назначение? Планирую отключить через неделю, если возражений не будет» — это письменное подтверждение с дедлайном, а не тихое действие.
2. Проверьте историю тикетов и коммитов, если есть трекер задач и репозиторий. Поиск по имени сервиса, порту или пути часто находит issue двухлетней давности с объяснением, зачем его вообще завели.
3. Спросите не только техническую команду, но и бизнес-стороны — бухгалтерию, отдел продаж, поддержку. Технически незаметный сервис (внутренний отчёт, экспорт для банка, вебхук для партнёра) может быть критичным именно для них, а разработчики о нём не думают, потому что не они им пользуются.
4. Проверьте владельца по метаданным, если люди не отвечают: кто последний коммитил конфиг, кто создавал systemd unit-файл (stat на файл покажет дату, но не автора — тут поможет git blame, если конфиги версионируются), чей API-ключ или токен используется в конфигурации сервиса.

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

Технический чек-лист: что проверить перед тем, как трогать сервис

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

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

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

Мягкое отключение вместо немедленного удаления

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

Практическая последовательность из четырёх стадий:

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

# nftables: логируем и дропаем попытки достучаться до порта извне
nft add rule inet filter input tcp dport 8080 log prefix "legacy-report-blocked: " drop

# iptables-вариант
iptables -I INPUT -p tcp --dport 8080 -j LOG --log-prefix "legacy-report-blocked: "
iptables -I INPUT -p tcp --dport 8080 -j DROP

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

Стадия 2 — если тишина, останавливаете процесс, но не удаляете unit-файл и не чистите конфиги:

systemctl stop legacy-report.service
# specifically НЕ disable и НЕ mask на этом шаге — оставляем возможность быстро вернуть

Стадия 3 — через ещё 2-4 недели без обращений и жалоб — disable, но с сохранением файлов на диске:

systemctl disable legacy-report.service

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

Если сервис имеет отношение к персональным или финансовым данным, удаление данных и копий в бэкапах — отдельный процесс со своими сроками хранения по закону, а не просто rm -rf. Разбор того, как это делать правильно, — в статье про регламент удаления данных и копий в бэкапах.

Почему именно четыре стадии, а не сразу stop + rm? Потому что каждая стадия обратима за секунды-минуты, а не за часы. Убрать правило firewall — 10 секунд. Сделать systemctl start после stop — тоже секунды, если конфиги и бинарники на месте. А вот восстановить удалённые файлы, если их не было в бэкапе (а у забытого сервиса бэкап часто тоже забыли настроить), может быть невозможно в принципе.

План отката: как быстро вернуть сервис, если ошиблись

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

Минимальный набор, который стоит подготовить перед стадией 1:

# снимок текущего состояния конфигурации и unit-файла
cp -r /etc/legacy-report /root/rollback-legacy-report-$(date +%Y%m%d)
cp /etc/systemd/system/legacy-report.service /root/rollback-legacy-report-$(date +%Y%m%d)/

# если сервис работает в контейнере — сохраняем образ и volume, а не полагаемся на registry
docker commit legacy-report legacy-report:before-shutdown-$(date +%Y%m%d)

Запишите отдельным файлом (или в тикет) сам план возврата — конкретные команды, а не «в целом понятно, как поднять»:

Откат legacy-report.service:
1. iptables -D INPUT -p tcp --dport 8080 -j DROP  (снять блокировку)
2. systemctl enable --now legacy-report.service
3. Проверить: curl -I http://localhost:8080/health
4. Сообщить в канал #ops, что сервис восстановлен, время простоя: <указать>

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

И держите этот план не только на бумаге, но и физически рядом с системой — если единственная копия плана отката лежит в конфлюенсе, к которому не будет доступа в момент инцидента (например, упал VPN, а конфлюенс во внутренней сети), от плана мало толку. Простой текстовый файл на самом сервере или в общем репозитории runbook’ов надёжнее.

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