Стандартизировали инструменты Linux-инженеров ITfresh: ящик 2026

Помните прошлый год? Для нашего клиента из Подольска, производственной компании 47 РМ, он точно был полон сюрпризов. Особенно на серверах Proxmox с Ubuntu 24.04. Каждый наш инженер привык к своему набору утилит. Но когда в три часа ночи случается ЧП, и дежурный понимает, что на этом конкретном сервере нет нужных ему инструментов — это же катастрофа, согласитесь? Вот почему в феврале 2026 года я решил покончить с этим хаосом. Я собрал и описал наш собственный «ящик инструментов ITfresh». Это 12 обязательных утилит, которые мы теперь централизованно устанавливаем на каждый клиентский сервер, используя нашу ansible-роль. Что именно вошло в этот список? Чем мы заменили старые, неэффективные решения? И какие команды наши инженеры теперь используют каждый день? Об этом я и расскажу дальше.

Зачем вообще стандарт инструментов

Какое-то время назад, ещё в 2020 году, у нас в ITFresh вполне себе прижился принцип «каждому своё». Один из наших инженеров обожает vim и mc, другой не представляет работы без emacs и ranger, а третий — и вовсе фанат VS Code Remote с tmux. На личных ноутбуках — да ради бога! Но вот на клиентских серверах это обернулось настоящим беспорядком. Представьте: заходишь по SSH, а там — ни mc, ни ranger, ни привычного nano! Приходится ставить apt install mc. Потом другой коллега ставит mcabber. И что в итоге? Через год клиент звонит с вопросом: откуда на root-партиции вдруг взялся лишний гигабайт «непонятно чего»? А это мы сами и "намусорили".

А что самое важное, когда глубокой ночью на сервере что-то пошло не так? У дежурного инженера нет времени на раскачку, ни минуты, чтобы привыкать к новому. Ему надо здесь и сейчас: взглянуть в лог, быстро подправить конфиг, перезапустить службу. Но если нет привычных инструментов, что он будет делать? Начинается паника. Инженер лихорадочно ищет или устанавливает нужное, теряя бесценные 15-20 минут. А ведь вы сами понимаете, каждая минута простоя — это прямые убытки для клиента. В копеечку, как говорится!

Поэтому в феврале 2026 мы зафиксировали стандарт. У каждого нашего клиента на каждом сервере (физическом или виртуальном) развёрнут одинаковый набор инструментов через ansible-роль itfresh.toolbox. По нашим замерам после стандартизации среднее время восстановления на инцидентах MTTR упало с 47 минут до 19. Это и есть главный аргумент для ввода стандарта.

Что в нашем ящике 2026 года

Итак, вот они — наши 12 утилит. Мы их отбирали по простому принципу: чтобы работали у нас без сбоев, не падали и активно поддерживались своими авторами. И, конечно, я расскажу, почему именно эти.

1. f4 — файловый менеджер (асинхронный клон Far Manager на Go)

Наше главное открытие (и приобретение!) 2026 года? Без сомнений, это f4! В апреле Иван Сорокин, знакомый многим как автор far2l, представил свою новую разработку: двухпанельный файловый менеджер, полностью переписанный с нуля на Go. Всего 15 МБ бинарника, никаких зависимостей. Работает везде: Linux, macOS, Windows, даже на ARM-устройствах! А плагины? Через RPC поверх MessagePack. Просто мечта.

Ну хорошо, спросите вы, чем же f4 так уж лучше того же mc? А вот чем: здесь реализована настоящая, полноценная асинхронность! Представьте: вы копируете 80-гигабайтный бэкап на NFS, и при этом можете спокойно продолжать работать с другими файлами, открывать редактор, просматривать каталоги. mc в такой ситуации просто замирает. А если сравнивать с Far Manager на Windows? Главное — f4 кроссплатформенный. Плюс те же самые привычные горячие клавиши (F3/F4/F5/F8), но теперь все это великолепие отлично работает в нативном Linux-окружении. Разве не здорово?

# Установка f4 на Ubuntu/Debian
wget https://github.com/elfmz/f4/releases/download/0.1.1-alpha/f4-linux-amd64
chmod +x f4-linux-amd64
sudo mv f4-linux-amd64 /usr/local/bin/f4

# Запуск, как Far Manager
f4

# Сжать UPX-ом до 4-5 МБ — если важна экономия места
upx --best /usr/local/bin/f4

# Edit (F4) использует встроенный редактор PieceTable — справляется с 80MB логом
f4 /var/log/syslog

Мы уже проверили f4 на практике: на моих 14 клиентских серверах он стабильно работает с апреля, ни единого сбоя. А mc? Его пока держим как запасной вариант, буквально на одной-двух машинах. Так, для сравнения или для тех коллег, кто пока не готов переучиваться.

2. btop — мониторинг в терминале

Забудьте про top, htop, glances! Наш выбор — btop. Он собирает в одном окне вообще всё: CPU по ядрам, оперативку, своп, диски, сетевую активность, все процессы. И это всё с потрясающей визуализацией в Unicode! Просто запускаешь на сервере — и буквально за 5 секунд ты уже в курсе, что там происходит. Ничего лишнего, только суть.

# Установка
apt install btop  # Ubuntu 24.04+
# Или из исходников для свежих фишек:
# https://github.com/aristocratos/btop

# Запуск с пресетом для серверов
btop --preset 0

# Цветовая схема "matrix" для тёмных терминалов клиентов
btop --tty_on
# В btop: F2 → Theme → matrix

3. fzf — fuzzy finder

Универсальный поисковик, который ускоряет всё. Ctrl+R в bash — поиск по истории команд с интерактивным фильтром. fzf в pipe — выбор из любого списка. fd | fzf — найти файл в дереве за 2 секунды.

# В .bashrc у каждого инженера
source /usr/share/doc/fzf/examples/key-bindings.bash
source /usr/share/doc/fzf/examples/completion.bash

# Лучший хоткей: Alt+C — переход в любой подкаталог
# Лучший хоткей #2: Ctrl+T — вставить путь к файлу из текущего дерева

# Использование в скриптах
service_to_restart=$(systemctl list-units --type=service \
  | awk '{print $1}' | fzf --header="Выбери сервис")
systemctl restart "$service_to_restart"

4. ripgrep (rg) — быстрый grep

А ripgrep (rg)? Это же просто ракета! Он в 30-50 раз быстрее, чем привычный GNU grep, особенно когда работаешь с огромными каталогами. Почему? Потому что параллельный, написан на мощном Rust и, что очень удобно, автоматом игнорирует .gitignore. Лично я с тех пор, как начал использовать rg, про старый grep вообще забыл.

# Найти все упоминания "TimeoutError" в логах за последние 7 дней
rg "TimeoutError" /var/log/ -t log

# Поиск с контекстом (5 строк до и после)
rg "OOM" /var/log/syslog -C 5

# Поиск по типам файлов и исключение
rg "password" --type-not log -g '!*.bak' /etc/

# Замена sed на проде с проверкой
rg "old_db_host" --files-with-matches | xargs -I{} cp {} {}.bak
rg "old_db_host" -l | xargs sed -i 's/old_db_host/new_db_host/g'

5. eza — современный ls

Замена ls с цветами, иконками, древовидным выводом и информацией про git. Алиас l='eza -la --icons --git' у каждого нашего инженера в .bashrc.

# Стандартный длинный листинг
eza -la --icons --git --time-style=long-iso

# Древовидно с глубиной 2
eza -T -L 2 /etc/

# Сортировка по размеру (находит большие файлы)
eza -la --sort=size --reverse --total-size /var/log/

# Только директории
eza -lD /home/

6. bat — cat с подсветкой синтаксиса

Bat — это по сути супер-версия cat, less и more в одном флаконе. Представьте: подсветка синтаксиса для более чем 200 языков, удобная нумерация строк, плюс классная интеграция с git diff. Читать конфиги и код становится в разы быстрее и приятнее.

# Просто cat
bat /etc/nginx/nginx.conf

# Без подсветки, как чистый cat
bat -p /etc/hosts

# Показать diff в репозитории
git diff --name-only | xargs bat --diff

# Заменяет man (но man оставляем тоже)
export MANPAGER="sh -c 'col -bx | bat -l man -p'"
man systemd

7. just — task runner вместо Makefile

Простой и понятный аналог make без unix-overhead. У каждого нашего проекта в репозитории клиента есть justfile с командами «как развернуть», «как почистить», «как сделать бэкап». Новый инженер открывает just без аргументов — видит список задач.

# Пример justfile из проекта парсера прайсов
default:
  just --list

backup:
  restic -r /mnt/backup/parser backup /var/lib/parser \
    --tag daily --tag $(date +%Y-%m-%d)

clean-logs:
  find /var/log/parser -name "*.log" -mtime +30 -delete

restart-cron:
  systemctl restart parser-cron.service
  journalctl -u parser-cron.service -n 50 --no-pager

deploy version="latest":
  git pull
  poetry install --no-dev
  systemctl restart parser-cron.service
  echo "Deployed {{version}}"

8. nushell — структурированный шелл

Из всего нашего набора Nushell, пожалуй, самый радикальный отход от привычного. Нет, мы, конечно, не заставляем инженеров писать на нём скрипты — bash на проде всё так же в почёте. Но вот для интерактивной работы Nushell — это настоящая революция! Только представьте: вывод абсолютно любой команды автоматически преобразуется в таблицу, и вы можете работать с ней, как с базой данных, используя SQL-подобные операторы. Это меняет всё!

# Войти в nushell
nu

# Все процессы с памятью больше 500 MB, отсортированные по CPU
ps | where mem > 500MB | sort-by cpu --reverse | first 10

# Прочитать JSON-лог и отфильтровать ошибки за последний час
open /var/log/llm/server.log
  | lines
  | each { |line| $line | from json }
  | where level == "error" and timestamp > (date now) - 1hr

# Скрестить df с inodes — найти диск, где кончились inodes
df -i | from ssv | where IUse% > 80%

# CSV прайса от поставщика — выкинуть строки без цены
open prices.csv | where price != null | sort-by price --reverse | first 50

9. zellij — терминальный мультиплексор (замена tmux)

Zellij — это современный мультиплексор, который мы выбрали за его интуитивно понятный интерфейс, поддержку плагинов и удобные сессии. Tmux, признаюсь, я и сам люблю, но вот у новичков он часто вызывает какой-то необъяснимый страх. А Zellij? Он сам показывает подсказки прямо внизу экрана: что нажать, куда двигаться. Благодаря этому, наши инженеры осваивают его в три раза быстрее! Разве не прорыв?

# Запуск с подключением к сессии (или созданием)
zellij attach itfresh-debug --create

# Создать layout файл для типового сценария "проверка сервера"
cat > /etc/itfresh/zellij/server-check.kdl <<'EOF'
layout {
    pane split_direction="vertical" {
        pane command="btop"
        pane split_direction="horizontal" {
            pane command="journalctl" args=["-fu" "1c-server.service"]
            pane command="watch" args=["-n" "1" "ss -tlnp"]
        }
    }
}
EOF

# Запуск с этим layout
zellij --layout /etc/itfresh/zellij/server-check.kdl

10. frida-trace — динамическая трассировка

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

# Установка
pip install frida-tools

# Трассировка всех open() и openat() от процесса
frida-trace -p $(pgrep my-app) -i 'open*'

# Трассировка сетевых вызовов
frida-trace -p $(pgrep nginx) -i 'connect' -i 'sendto' -i 'recvfrom'

# Реальный кейс: 1С-клиент падал на старте
# frida-trace -p $(pgrep 1cv8) -i 'open*' выявил
# попытку открыть несуществующий /opt/1c/license.dat
# Решение: cp /opt/1c/license.dat.real /opt/1c/license.dat

# Аналогично можно через strace, но frida удобнее на Java/Go-приложениях

11. restic — бэкап

Restic — это наша рабочая лошадка для бэкапов. В нём есть всё, что нужно: дедупликация данных, надёжное шифрование, а ещё он поддерживает кучу бэкендов: локальный диск, S3, SFTP, REST. Мы используем Restic абсолютно у всех наших клиентов, чтобы каждые 6 часов снимать бэкапы 1С, файловых шар и AD. При этом храним их по чёткой политике retention: 30 дней, 12 недель и 6 месяцев. Мы не рискуем данными клиентов.

# Инициализация репозитория на нашем FTP-сервере (Veeam ESXi)
export RESTIC_REPOSITORY="sftp:itfreshftp:/backup/client-trade-corp"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

restic init

# Бэкап каждые 6 часов через cron
restic backup /var/lib/1c-app /etc/1c-app \
  --tag 1c \
  --tag $(hostname) \
  --exclude-file=/etc/restic/excludes

# Retention policy
restic forget --tag 1c \
  --keep-hourly 24 \
  --keep-daily 30 \
  --keep-weekly 12 \
  --keep-monthly 6 \
  --prune

# Восстановление на тестовый стенд
restic restore latest --target /tmp/test-restore --tag 1c

12. dust — du с человеческим лицом

И, наконец, dust. Когда нужно моментально понять, куда же «улетел» весь свободный объем на диске, вместо du или ncdu мы используем его. Это просто идеальная замена: наглядный цветной вывод, удобное древовидное представление, а размеры отображаются настолько понятно, что сразу видно, кто сколько съел. Больше никаких догадок!

# Где на сервере занято
dust -d 3 /var

# Топ-10 каталогов по размеру
dust -n 10 /home

# С учётом скрытых
dust -d 2 /etc

Как мы это раскатываем на серверы клиентов

Не вручную. У нас ansible-роль itfresh.toolbox, которая ставится за 90 секунд при первичной настройке любого нового сервера. Кратко содержимое:

# roles/itfresh.toolbox/tasks/main.yml
- name: Установка пакетов из репозитория
  ansible.builtin.apt:
    name:
      - btop
      - fzf
      - ripgrep
      - bat
      - mc
      - tmux
      - jq
    state: present
    update_cache: yes

- name: Установка eza
  ansible.builtin.apt:
    deb: https://github.com/eza-community/eza/releases/download/v0.18.0/eza_0.18.0-1_amd64.deb

- name: Установка f4
  ansible.builtin.get_url:
    url: https://github.com/elfmz/f4/releases/download/0.1.1-alpha/f4-linux-amd64
    dest: /usr/local/bin/f4
    mode: '0755'

- name: Установка zellij
  ansible.builtin.unarchive:
    src: https://github.com/zellij-org/zellij/releases/latest/download/zellij-x86_64-unknown-linux-musl.tar.gz
    dest: /usr/local/bin/
    remote_src: yes

- name: Установка nushell (как доп. шелл, не системный)
  ansible.builtin.apt:
    deb: https://github.com/nushell/nushell/releases/download/0.95.0/nu_0.95.0-1_amd64.deb

- name: .bashrc для admin-учётки
  ansible.builtin.template:
    src: bashrc.j2
    dest: /home/{{ admin_user }}/.bashrc
    owner: "{{ admin_user }}"
    group: "{{ admin_user }}"

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

Что мы выкинули из ящика

vim и emacs больше не дефолт

Я не хочу, чтобы дежурный инженер залипал, когда пользователь привычный к nano или micro. На всех серверах ставим micro как редактор по умолчанию (alias edit, EDITOR=micro), vim/emacs остаются для тех, кто их любит — они всё равно есть в репозиториях. Но в фокусе обучения новых сотрудников теперь micro.

htop — необязательно

Знаете, btop умеет абсолютно всё, что привычный htop, и даже больше! Мы решили оставить htop для наших инженеров со стажем — не хочется ломать их давние привычки, верно? Зато всех новичков сразу же обучаем работе с btop.

find заменили на fd

fd быстрее, синтаксис человечнее, по умолчанию игнорирует .git. fd '\.log$' /var/log вместо километровой find /var/log -type f -name '*.log'.

Реальные сценарии, где стандарт спасает

Ночной инцидент: 1С падает на проде у клиента

3:14 утра, дежурный получает алерт от Wazuh. Подключается через SSH к серверу клиента. На сервере уже стоит наш стандартный набор: btop показывает 100% CPU на одном процессе mariadb, rg "ERROR" /var/log/mariadb/error.log -t log -A 3 | tail -20 — последние ошибки. Видит Out of memory на запросе. Дальше journalctl -fu mariadb в одной панели zellij, btop в другой, frida-trace -p $(pgrep mariadbd) -i 'mmap' в третьей. За 11 минут понятно: один тяжёлый отчёт сожрал кэш. Перезапуск, отчёт обновляем потом отдельно.

Перенос проекта между клиентами

Юрфирма попросила парсер прайса развернуть и у себя, и у дочерней структуры. У них на сервере наш стандартный justfile, инженер делает just deploy — за 90 секунд проект на новом сервере, потому что все скрипты построены на одинаковых утилитах.

Контр-нарратив: «не надо выпендриваться, есть же coreutils»

Слышал такое возражение от старшего инженера: «зачем 12 экзотических утилит, есть классические grep/awk/sed/find, чему ты учишь молодых?» По моему опыту это устаревшая позиция. Время новых инструментов экономит часы в неделю на инженера. ripgrep против grep на каталоге /var/log — это не «удобнее», это в 30 раз быстрее по факту замеров. nushell против цепочки ps aux | grep | awk | sort — это не «попугайничанье», а человеческий тип данных вместо парсинга строк регулярками.

Не волнуйтесь, классические coreutils никуда не денутся, они по-прежнему в строю. Но вот что изменилось: именно это новое поколение утилит теперь стало основным инструментом для наших инженеров. Мы уверены, всего через 2-3 года эти инструменты будут стандартом для большинства дистрибутивов. А мы? Просто оказались на полшага впереди, вот и всё.

FAQ: что чаще всего спрашивают клиенты

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

Представьте: три часа ночи, дежурный инженер мчится исправлять критическую проблему на чужом сервере. Есть ли у него время разбираться в чьих-то незнакомых алиасах или непривычных редакторах? Конечно, нет! Что же для нас в ITfresh означает 'стандарт'? Всё просто: это набор утилит, который обязательно есть абсолютно на каждом сервере клиента, настроен точно так же, как у соседа, и работает всегда предсказуемо. И благодаря такой стандартизации, мы добились по-настоящему крутых результатов: среднее время восстановления (MTTR) на инцидентах сократилось с 47 минут до невероятных 19. Понимаете, это ведь не просто сухие цифры. Это реальная, осязаемая выгода, которую ваш клиент, может быть, и не видит напрямую, но чувствует благодаря нашей молниеносной скорости восстановления.

Чем f4 лучше mc и Far Manager?

А вы уже слышали про f4? Это же клон Far Manager, который Иван Сорокин переписал с нуля на Go — и это круто! По сравнению с mc, у f4 есть настоящая асинхронность: представьте, вы копируете огромный файл и спокойно открываете другие, и при этом интерфейс совсем не виснет. А если сравнить его с Far Manager на Windows? Здесь мы получаем кроссплатформенность, лёгкий нативный бинарник всего в 15 МБ (без всяких зависимостей!), плюс возможность писать плагины через RPC поверх MessagePack на чём угодно. Мы планируем установить f4 на все сервера клиентов уже в 2026 году. Почему? Он стабилен, начиная с версии 0.1.1-alpha, и при этом намного легче, чем mc.

Стоит ли переучивать инженеров с bash на nushell?

Полностью? Нет, конечно. Для продакшн-скриптов мы по-прежнему используем bash — куда без него? Но вот для интерактивной работы каждого нашего инженера мы оснащаем nushell, который ставится как пользовательский шелл. Что он умеет? У него встроенная работа с JSON/CSV, SQL-подобные пайпы, а ещё парсеры для ps, df, du, которые выдают данные в удобном табличном формате! И это, знаете ли, фантастически ускоряет разбор инцидентов. Вместо того чтобы писать целую страницу регулярок, вы просто набираете: `ps | where memory > 500MB | sort-by cpu desc` — и моментально видите нужный ответ. При этом на обучение инженера, который десятилетиями сидел на bash, уходит всего пара недель.

Когда применяется frida-trace в работе с клиентом?

Знакомая ситуация, правда? Бывает у клиента какой-нибудь "чёрный ящик". Это серверное приложение, которое или давно не поддерживают, или его поставщик просто пропал, не отвечает. И вот нам нужно срочно, прямо сейчас, понять: какие системные вызовы оно делает на продакшене? Мы столкнулись с таким случаем: у одной юридической фирмы старая версия сертификационного клиента для 1С постоянно вылетала с совершенно непонятной ошибкой. Мы взяли frida-trace, запустили его с `frida-trace -p PID -i 'open*'` — и что вы думаете? Буквально за 10 минут увидели, что приложение пытается открыть файл лицензии, которого просто нет! Вопрос решился мгновенно: мы поставили симлинк и двинулись дальше. А без frida? Мы бы потратили на эту проблему целый день, если не больше!

Что точно не нужно ставить в продакшене у клиента из этого списка?

Хочу сразу прояснить один важный момент: frida-trace, strace и tcpdump — это чисто диагностические инструменты. Они нам постоянно на продакшене не нужны! Мы храним их в специальной ansible-роли, "накатываем" только в случае какого-то серьёзного инцидента и, как только проблема решена, сразу же удаляем. Ещё один важный принцип: мы никогда не оставляем debug-сборки nushell на продакшене, только проверенные release-версии. И вот ещё что крайне важно, прямо критически важно: mc и f4 мы ни в коем случае не устанавливаем от имени root! На клиентских серверах они всегда работают под отдельной учёткой администратора. Зачем так строго? Чтобы никто случайно, нажав F8, не снёс случайно важные production-данные. Все эти тонкости мы обязательно проговариваем с каждым клиентом ещё до старта проекта.

Итог

Стандартизация "ящика инструментов" для наших Linux-инженеров в 2026 году — это, поверьте, не просто наша прихоть. Это конкретная, чётко просчитанная экономия! Вот наш набор из 12 крутых утилит: f4, btop, fzf, ripgrep, eza, bat, just, nushell, zellij, frida-trace, restic, dust. Знаете, его можно развернуть на каждом клиентском сервере всего за 90 секунд при помощи нашей ansible-роли! И главное, что это даёт? Мы сокращаем время восстановления на инцидентах в 2,5 раза! Только вдумайтесь: в два с половиной раза! А если в вашей инфраструктуре каждый инженер продолжает тащить "своё" на серверы, будьте готовы: вы будете расплачиваться за это бессонными ночами. И, конечно же, нервами ваших клиентов.