Вы видите процесс на сервере, но не понимаете, кто его поднял. Обычно на это уходит 20–40 минут ручной проверки. Новый инструмент witr сводит поиск причины к одной команде.
Он не просто показывает, что работает. Он объясняет цепочку причин: от systemd до конкретного скрипта и порта. Причем сразу в читаемом виде.
Боль админов и разработчиков закрыли одной идеей: не «что», а «почему»
Большинство утилит показывают состояние. Например, ps, top, lsof и systemctl. Но потом вы сами склеиваете куски информации и ищете виновника.
witr делает наоборот. Он строит причинную цепочку автоматически и показывает, почему процесс живет прямо сейчас. Это экономит десятки минут при каждом инциденте.
- Показывает родительские процессы до самого источника запуска.
- Объясняет, какой сервис, контейнер или shell (оболочка терминала) запустил задачу.
- Показывает рабочую директорию, пользователя, порт и команду запуска.
- Умеет выводить коротко, деревом или в JSON (структурированный формат данных).
Что реально изменилось в работе, если вы поддерживаете прод
Раньше вы искали причину через 4–6 инструментов. Теперь часто хватает одной команды вида witr --port 5000. Ответ приходит сразу с цепочкой родителей.
Есть и интерактивный режим TUI (текстовый интерфейс в терминале). Он показывает процессы в реальном времени, сортировку, фильтры и действия с процессами. Можно быстро найти «шумный» сервис и погасить его без прыжков между окнами.
- Live list (живой список) процессов с обновлением в реальном времени.
- Port view (просмотр портов): кто занял порт и зачем.
- Process tree (дерево процессов): родитель, дети, связи до 10 дочерних задач.
- Сигналы процессу: kill, terminate, pause, resume (остановить, завершить, пауза, продолжить).
Для дежурного инженера это значит меньше паники ночью. Для разработчика, который «просто деплоил», это минус один длинный разбор.
Почему это важно бизнесу, а не только DevOps-команде
Каждая лишняя минута простоя стоит денег. Если сервис упал или завис, бизнес платит за задержки заказов и недовольство клиентов. witr сокращает путь от «что случилось» до «кто виноват».
Инструмент кроссплатформенный: Linux, macOS, FreeBSD и Windows. Ставится как один бинарник, а значит внедряется быстро даже в смешанной инфраструктуре.
- Установка через Homebrew, Conda, Winget, npm и другие менеджеры пакетов.
- Есть .deb, .rpm и .apk для популярных Linux-дистрибутивов.
- Можно запускать без установки через nix run (запуск из Nix) или pixi exec (временный запуск).
Это снижает порог входа для маленьких команд. Не нужно строить сложный стек наблюдаемости, чтобы решить базовую проблему «почему это работает».
Как применить прямо сегодня: 3 быстрых сценария
Сценарий 1. Порт 5000 занят, релиз не стартует. Запускаете witr --port 5000 и видите точную цепочку до процесса-владельца.
Сценарий 2. На сервере странный node/python процесс. Даете witr node или witr --pid 14233 и сразу понимаете источник запуска.
Сценарий 3. Нужен отчет для автоматизации. Используете --json и отправляете результат в скрипт или мониторинг.
- Для DevOps: быстрее разбор инцидентов и меньше ручной рутины.
- Для backend-разработчиков: проще дебажить после деплоя.
- Для CTO и техлидов: меньше времени команды уходит в «слепой поиск».
- Для агентств и SaaS: быстрее восстановление после сбоев у клиентов.
Если хотите начать за 2 минуты, берите пакетный менеджер. Это безопаснее для обновлений и проще в поддержке версий.
Главный сдвиг здесь простой: мы переходим от мониторинга симптомов к мониторингу причин. И именно это отличает «тушение пожаров» от зрелой инженерии.
Ссылка на репозиторий: github.com/pranshuparmar/witr