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

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

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

Ещё в 2020 году у нас в команде нормально жили под девизом «у каждого свои привычки». Один инженер — фанат vim и mc, второй — emacs и ranger, третий — VS Code Remote и tmux. На своих ноутбуках это нормально. На серверах клиентов это превращалось в хаос: захожу в ssh — а там ни mc, ни ranger, ни даже nano. Ну ставлю себе apt install mc, потом другой инженер ставит mcabber. Через год клиент жалуется на внезапный 1 GB занятой root-партиции «непонятно чем» — мы же сами и насорили.

Главное, в инциденты ночью у дежурного инженера времени привыкать к чужому окружению нет. Ему надо посмотреть лог, поправить конфиг, перезапустить службу. Если на сервере нет привычных ему утилит — он тратит на это 15-20 минут. А клиент платит за каждую минуту простоя.

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

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

12 утилит, которые мы выбрали по принципу «у нас работают, не падают, поддерживаются автором». Привожу с обоснованием.

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

Главное приобретение 2026 года. Иван Сорокин (автор far2l) выкатил в апреле f4 — переписанный с нуля на Go двухпанельный файловый менеджер. Бинарь 15 МБ без зависимостей, под Linux/macOS/Windows/ARM, плагины через RPC поверх MessagePack.

Чем он лучше mc: настоящая асинхронность. Копирую 80-гигабайтный backup на NFS — и параллельно работаю с другими файлами, открываю редактор, лажу по дереву. mc на этом фризится. Чем лучше Far Manager на Windows: кроссплатформенный с теми же привычными хоткеями (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

На моих 14 клиентских серверах f4 работает с апреля без сбоев. mc держим как fallback на 1-2 машинах для сравнения и для тех инженеров, кто не хочет переучиваться.

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

Замена top, htop, glances. У btop в одном экране CPU per-core, RAM, swap, диски, сеть, процессы — и при этом красивая визуализация в 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

В 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 с подсветкой синтаксиса

Замена 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 — структурированный шелл

Самый радикальный из стандарта. Я не заставляю инженеров переходить на него для скриптов — 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)

Современный мультиплексор с понятным интерфейсом, плагинами и сессиями. 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 и вижу, какие системные вызовы делает процесс в реальном времени.

# Установка
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 — бэкап

Утилита бэкапа с дедупликацией, шифрованием и поддержкой backend'ов: локальный диск, S3, SFTP, REST. У всех клиентов мы делаем бэкапы 1С, файловых шар и AD через restic — каждые 6 часов с 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 с человеческим лицом

Замена 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 — это переписанный с нуля на Go клон Far Manager от Ивана Сорокина. По сравнению с mc у него настоящая асинхронность: вы можете копировать большой файл и одновременно открывать другие, без зависаний интерфейса. По сравнению с Far Manager на Windows — кроссплатформенность, нативный binar 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 и видите ответ. На обучение инженера с 5+ лет bash уходит две недели.

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

Когда у клиента появляется чёрный ящик: серверное приложение, которое поставщик не поддерживает или не отвечает в рабочее время, и нужно понять, какие системные вызовы оно делает на проде. Например, у юрфирмы у нас был случай — старая версия сертификационного клиента в 1С падала с непонятной ошибкой. Через 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 раза. Если у вас в инфраструктуре каждый инженер ставит своё — вы платите за это ночными часами и нервами клиентов.