tmate — мгновенный совместный доступ к терминалу, как Google Docs для Shell

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

Проведение живых демонстраций, совместная отладка и оперативный helpdesk перестают быть проблемой синхронизации экранов.

➤ Вариант 1 (Мгновенный сеанс помощи): вместо того чтобы просить коллегу «посмотри в логи на сервере X», вы запускаете tmate на проблемной машине, получаете ссылку и отправляете её в чат. Коллега подключается и видит ту же самую сессию.

tmate
# В выводе появится строка вида:
# SSH: ssh bG9jYWxob3N0IHBvcnQ...
# Веб: https://tmate.io/t/bG9jYWxob3N0...

➤ Вариант 2 (Демонстрация без подготовки): идеально для быстрого показа работы скрипта, настройки конфига или странного поведения в реальной среде. Не требует установки дополнительного ПО у зрителя — только SSH-клиент или браузер.

➤ Вариант 3 (Read-only режим): при создании сессии можно сразу указать режим только для чтения (tmate -R), чтобы зрители не могли вводить команды, что важно для безопасности при демонстрации на продакшене.

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

Это не инструмент для постоянного использования, а цифровой «аварийный люк» или «инструмент для презентации», который всегда под рукой.

P.S. Критически важно для безопасности: ссылка tmate предоставляет полный доступ к сессии. Отправляйте её только доверенным лицам и помните, что сессия живёт, пока активна. Для чувствительных операций используйте одноразовые сессии и завершайте их сразу после работы.

🌐 @helcode

cronic — умная обёртка для cron, которая не спамит почтой

Скрипт в cron завершился с ненулевым кодом возврата? Демон cron немедленно шлёт письмо на MAILTO. Если скрипт запускается часто и имеет ожидаемые, некритичные ошибки (например, временная недоступность сети), почтовый ящик превращается в свалку. cronic — это маленький bash-скрипт, который подавляет вывод задачи, если она завершилась успешно, и показывает его только в случае ошибки.

Правило хорошего тона: автоматизация должна молчать, когда всё хорошо, и говорить, когда есть проблема.

➤ Вариант 1 (Прямое использование в crontab): обернуть любую команду в cronic.

# Вместо этого:
# * * * * * /opt/scripts/healthcheck.sh
# Использовать это:
* * * * * /usr/bin/cronic /opt/scripts/healthcheck.sh

➤ Вариант 2 (Суть логики): cronic — это, по сути своей, умный перенаправитель вывода. Его можно реализовать своими силами, понимая принцип:

#!/bin/bash
# Упрощенная суть cronic
OUTPUT=$($@ 2>&1)
EXITCODE=$?
if [ $EXITCODE -ne 0 ]; then
  echo "Command failed with exit code $EXITCODE:"
  echo "$OUTPUT"
fi
exit $EXITCODE

➤ Вариант 3 (Использование в CI/CD): аналогичный принцип применяется в пайплайнах: этап считается неудачным и показывает логи только если команда завершилась с ошибкой. cronic формализует этот подход для cron.

cronic — это автоматизация управления уведомлениями. Он встраивает простую логику принятия решения: «стоит ли беспокоить человека этими данными?». Это следующий уровень после простого перенаправления вывода в /dev/null.

Инструмент, который экономит не время процессора, а самое ценное — внимание системного администратора.

P.S. Исходный код cronic умещается на одной странице. Это гениальный пример того, как простая идея, правильно реализованная, решает огромный пласт бытовых проблем.

🌐 @helcode

pip-audit / npm audit / cargo-audit — автоматические детективы уязвимостей в зависимостях

Установка пакетов без проверки на известные уязвимости (CVE) — это игра в русскую рулетку с безопасностью приложения. Современные менеджеры пакетов экосистем получают встроенные или отдельные инструменты аудита, которые сканируют дерево зависимостей, сверяют его с публичными базами уязвимостей и указывают на проблемные версии.

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

➤ Вариант 1 (Локальная проверка): запуск аудита вручную перед деплоем или как часть pre-commit хука.

# Для Python (pip)
pip-audit
# Для Node.js (npm)
npm audit
# Для Rust (cargo)
cargo audit

➤ Вариант 2 (Интеграция в CI/CD): добавление шага аудита в пайплайн сборки. При обнаружении критической уязвимости пайплайн «падает», предотвращая попадание уязвимого кода в репозиторий или на прод.

# Пример для GitHub Actions (Python)
- name: Audit dependencies
  run: pip-audit --strict

➤ Вариант 3 (Автоматическое обновление): инструменты вроде npm audit fix или Dependabot не только находят проблемы, но и автоматически создают Pull Request с обновлением зависимостей до безопасной версии.

Эти инструменты — это автоматизация проактивной безопасности. Они сдвигают безопасность «влево», обнаруживая проблемы на этапе разработки, а не эксплуатации. Это обязательный элемент гигиены современного CI/CD.

Игнорирование их предупреждений — это осознанный выбор в пользу потенциального взлома.

P.S. Помните, что эти инструменты проверяют зависимости только по известным CVE. Они не заменяют ревью кода зависимостей на предмет закладок или анализа их лицензий.

🌐 @helcode

multitail — мониторинг нескольких логов в одном окне, с цветами и правилами

Открытие пяти терминалов с tail -f для слежки за логами nginx, приложения, БД и системного журнала — это бардак на рабочем столе. multitail позволяет отображать вывод нескольких команд (чаще всего tail -f) в одном окне, с разделением на панели, цветовой подсветкой на основе регулярных выражений и даже интерактивным управлением.

Наблюдаемость должна упрощать анализ, а не множить сущности.

➤ Вариант 1 (Базовый мониторинг): запуск с указанием файлов для слежения. Ключ -s задает количество колонок.

multitail -s 2 /var/log/nginx/access.log /var/log/nginx/error.log

➤ Вариант 2 (Цветовые схемы и фильтрация): настройка правил подсветки. Например, выделить ошибки (ERROR) красным, предупреждения (WARN) — желтым, а IP-адреса — синим.

multitail -cS syslog /var/log/syslog
# -cS <схема> применяет предустановленную цветовую схему

➤ Вариант 3 (Мониторинг вывода команд): можно следить не только за файлами, но и за выводом любой команды. Например, совместить логи и метрики vmstat.

multitail -l 'tail -f /app/app.log' -l 'vmstat 1'

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

Это следующий шаг после tail -f, как tmux — следующий шаг после нескольких открытых терминалов.

P.S. multitail умеет намного больше: объединять вывод из нескольких источников в одну панель, выполнять действия по нажатию клавиш, вести session log. Это tmux и tail -f в одном флаконе, заточенный под задачи администрирования.

🌐 @helcode

rclone — rsync для облаков и не только

Копирование файлов между локальным диском, S3-совместимым хранилищем, Google Drive, Dropbox, SFTP-сервером и десятками других бэкендов через разные CLI-интерфейсы — это кошмар. rclone (remote clone) — это единая консольная утилита, которая предоставляет общий интерфейс для работы с 70+ облачными и не только хранилищами.

Автоматизация работы с данными не должна упираться в уникальность API каждого провайдера.

➤ Вариант 1 (Синхронизация с облаком): классический сценарий — зеркалирование локальной директории в облачное хранилище (например, Yandex Disk или Backblaze B2).

rclone sync /backups/data remote:mybucket/data

➤ Вариант 2 (Копирование между облаками): миграция данных из одного облака в другое без промежуточной загрузки на локальный диск (при поддержке провайдера).

rclone copy source:s3-bucket/path dest:google-drive/path

➤ Вариант 3 (Монтирование облака как файловой системы): использование rclone mount для доступа к файлам в облаке как к локальной директории. Полезно для чтения/записи напрямую.

rclone mount remote:mybucket /mnt/cloud --vfs-cache-mode full

rclone — это автоматизация абстракции над хранилищами. Он реализует принцип «единого интерфейса» (unified API) для самых разнообразных сервисов, позволяя писать скрипты, которые будут работать с любым из них без изменений логики.

Это швейцарский армейский нож для данных в гибридном мире, где они живут и на диске, и в десятках «облаков».

P.S. rclone обладает всеми функциями rsync (дельта-копирование, проверка хэшей, --dry-run) и многими другими: шифрование на лету, обрезка версий, веб-интерфейс для управления. Это проект, в который влюбляешься по мере изучения.

🌐 @helcode

websocat — netcat для эпохи WebSockets

Простые TCP-сокеты уступают место WebSockets в современных API и стриминговых сервисах. websocat — это CLI-инструмент, который соединяет мир командной строки с миром WebSockets. Он может выступать как клиент, сервер, прокси или мост между WS и стандартными потоками stdin/stdout.

Тестирование, отладка или автоматизация взаимодействия с WebSocket-сервисом не должны требовать написания скрипта на Python или Node.js.

➤ Вариант 1 (Интерактивный клиент): подключение к WebSocket-эндпоинту и интерактивный обмен сообщениями, как с telnet для TCP.

websocat ws://echo.websocket.org
# Вводите строки, получаете эхо-ответ.

➤ Вариант 2 (Автоматизация в скриптах): отправка заранее подготовленного JSON и чтение ответа, перенаправляя потоки.

echo '{"event":"subscribe"}' | websocat ws://api.example.com/stream

➤ Вариант 3 (Создание простого сервера или моста): запуск локального WebSocket-сервера, который перенаправляет сообщения в локальную программу или файл.

# Сервер, который всё записывает в файл
websocat -s 8080 tee logs.txt

websocat — это автоматизация доступа к современным сетевым протоколам из арсенала Unix. Он расширяет философию «всё — файл/поток» на мир WebSockets, позволяя использовать мощь пайпов, grep, jq и других утилит для работы с данными, передаваемыми по этому протоколу.

Это пример того, как классические Unix-принципы адаптируются к новым технологиям, а не отмирают.

P.S. websocat написан на Rust, самодостаточен (статически линкованный бинарник) и невероятно быстр. Это идеальный кандидат для добавления в Docker-образы для целей отладки и healthcheck'ов.

🌐 @helcode

pgrep и pkill — убийцы, которые знают имена, а не только PID

Поиск PID процесса через ps aux | grep -v grep | grep ... | awk '{print $2}' с последующим kill — это ритуал, достойный редиски. pgrep и pkill делают то же самое за одну команду, используя гибкие шаблоны для поиска по имени процесса, владельцу, аргументам командной строки и другим атрибутам.

Управление процессами должно быть декларативным («заверши все процессы python»), а не императивным («найди, извлеки, убей»).

➤ Вариант 1 (Точный поиск и завершение): завершение всех процессов с точным именем.

pkill -9 nginx

➤ Вариант 2 (Гибкое сопоставление): завершение процессов по шаблону в имени или аргументах. Ключ -f проверяет полную командную строку.

# Убить все процессы python, запущенные из скрипта backup
pkill -f "python.*backup"

➤ Вариант 3 (Сигналы и проверка): pgrep позволяет сначала проверить, какие процессы будут затронуты, прежде чем посылать сигнал. Это безопаснее.

pgrep -u www-data
# Показать PIDs всех процессов пользователя www-data
pkill -SIGTERM -u www-data
# Отправить SIGTERM всем им

pgrep/pkill — это автоматизация паттерна поиска-и-действия для управления процессами. Они инкапсулируют рутинную логику фильтрации вывода ps в простые, надёжные команды, которые меньше подвержены ошибкам (например, случайному попаданию в grep самого процесса grep).

Это не новые инструменты, но их недооценка — распространенная ошибка. Их знание — признак того, что вы работаете с системой, а не боретесь с ней.

P.S. Осторожно с pkill -f, особенно под root. Шаблон .* может совпасть с больше процессов, чем вы ожидаете. Всегда проверяйте список кандидатов через pgrep -a -f <шаблон>.

🌐 @helcode

iperf3 — не гадаем, а измеряем пропускную способность сети

Сетевые приложения тормозят, копирование файлов медленное, а «пинг» вроде нормальный. "Гадания на кофейной гуще" и тесты скорости через загрузку файлов с облака - не метод. iperf3 - это профессиональный инструмент для измерения максимальной пропускной способности сети между двумя хостами, который выдаёт точные цифры: скорость, джиттер, потери пакетов.

Скорость сети - не ощущение, а измеримая величина. Если Вы её не измеряете, Вы ей не управляете.

➤ Вариант 1 (Базовая проверка): запуск сервера на одной машине и клиента на другой.

# На сервере (принимающая сторона)
iperf3 -s

# На клиенте (отправляющая сторона)
iperf3 -c 192.168.1.100

➤ Вариант 2 (Двунаправленное тестирование): ключ -R (reverse) меняет направление, позволяя увидеть асимметрию канала (часто бывает, что загрузка быстрее отдачи).

iperf3 -c 192.168.1.100 -R

➤ Вариант 3 (Параллельные потоки и длительность): имитация реальной многопоточной нагрузки.

iperf3 -c 192.168.1.100 -P 4 -t 30
# -P 4: 4 параллельных потока
# -t 30: тест длится 30 секунд

➤ Вариант 4 (UDP-тест для чувствительных приложений): для VoIP или видеосвязи важны потери и джиттер.

iperf3 -c 192.168.1.100 -u -b 100M
# -u: UDP режим
# -b 100M: пытаемся отправить 100 мегабит/с

iperf3 - это автоматизация объективной сетевой диагностики. Он убирает фактор "кажется" и даёт цифры, на которые можно опираться при общении с провайдером или при поиске узкого места в инфраструктуре.

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

P.S. Версии iperf3 должны совпадать на клиенте и сервере, иначе тест может не работать или выдавать некорректные результаты.

🌐 @helcode

git worktree — параллельная работа без переключения контекста

Нужно срочно исправить баг на продакшене, но текущая ветка с новой фичей не готова к коммиту? git stash, git checkout, а потом обратно - потеря концентрации и времени. git worktree позволяет одновременно иметь несколько рабочих копий одного репозитория, привязанных к разным веткам, на диске.

Переключение контекста в разработке - главный пожиратель продуктивности. git worktree устраняет саму необходимость переключения.

➤ Вариант 1 (Создание нового worktree): добавляем новую рабочую директорию для ветки hotfix.

git worktree add ../project-hotfix hotfix
# Теперь в папке ../project-hotfix лежит код ветки hotfix

➤ Вариант 2 (Работа с несколькими фичами): можно держать отдельные папки для feature-1, feature-2 и main, не трогая основной рабочий каталог.

git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b

➤ Вариант 3 (Просмотр и очистка): увидеть все активные worktree и удалить ненужные.

git worktree list
git worktree remove ../project-hotfix

git worktree - это автоматизация управления рабочим пространством. Он позволяет мозгу не переключаться между задачами, а просто открыть новое окно терминала или редактора с уже готовым контекстом.

Это инструмент для тех, кто часто работает с несколькими ветками параллельно: поддержка старых версий, срочные хотфиксы, code review в другой ветке без потери текущего состояния.

P.S. Worktree не занимают лишнего места на диске (объекты хранятся в оригинальном репозитории), только файлы рабочей директории. Это почти бесплатный параллелизм.

🌐 @helcode

at — одноразовый cron для отложенных задач

Запустить тяжёлый скрипт через 3 часа, когда закончится рабочий день, но не хочется оставлять терминал открытым? Или напомнить себе о чём-то через 15 минут? cron избыточен для одноразовых задач. at - это команда для выполнения задания один раз в указанное время.

Не каждая автоматизация должна быть регулярной. Иногда нужно просто «выстрелить и забыть».

➤ Вариант 1 (Простое выполнение): запуск скрипта в 18:00.

echo "/opt/scripts/backup.sh" | at 18:00

➤ Вариант 2 (Интерактивный режим): можно ввести команду прямо в консоли at.

at 15:30
at> ./long_running_task.sh
at> ./cleanup.sh
at> <Ctrl+D>

➤ Вариант 3 (Относительное время): запуск через 2 часа или завтра в 9 утра.

at now + 2 hours
at 9:00 tomorrow

➤ Вариант 4 (Управление задачами): просмотр и удаление отложенных задач.

atq                  # посмотреть очередь
atrm 12              # удалить задачу с номером 12

at - это автоматизация однократных отложенных действий. Он закрывает нишу между «сделать прямо сейчас» и «сделать регулярно по расписанию», которая часто заполняется костылями вроде sleep 3600 && command в фоне.

В современных системах есть systemd-run с опцией --on-active, но at проще и вездесущ.

P.S. Демон atd должен быть запущен в системе. Проверить можно командой systemctl status atd.

🌐 @helcode

Коллеги, приветствую! Попробуем новостные посты?

Microsoft решила поиграть с Rufus

Наткнулся на интересную историю на днях. Создатель Rufus обнаружил, что Microsoft начала охоту на скрипты автоматизации, которые тянут ISO-образы прямо с их серверов. Модуль Fido, встроенный в Rufus, перестал работать для свежих инсайдерских сборок (Canary и Server Preview).

Разработчик Rufus подозревает, что инженеры Microsoft специально изучили открытый исходный код Fido (он же open source), чтобы написать сигнатуры для его блокировки. Мол, корпорация добра пытается загнать всех в своё кривое творение Media Creation Tool.

Лично моё мнение. Если честно, эта глупость с блокировками выглядит жалко. Вместо того чтобы сделать нормальный инструмент, который люди захотят использовать, они пытаются силой загнать всех в своё корыто (знакомая история, да?). Rufus существует столько лет именно потому, что официальные инструменты Microsoft - неудобно и "больно". И вместо того чтобы сделать их удобнее, они просто режут возможности тем, кто хочет работать с системой по-человечески.

Особенно умиляет момент с открытым кодом. То есть они не придумали ничего лучше, чем изучить код проекта, который сообщество сделало для удобства людей, и написать под него блокировки. Вместо того чтобы сказать "спасибо" за бесплатный пентест своих серверов. Отличненько...

Война с удобным скачиванием - очередной этап закручивания гаек. Видимо, слишком много людей решили, что имеют право устанавливать Windows так, как им удобно. Подобными выпадами они скорее Linux в массы продвинут.

🌐 @helcode

sshfs — монтируем удалённую файловую систему как локальную

Копировать файлы по scp туда-сюда для редактирования, или открывать их через промежуточный sftp в редакторе - это оверхед. sshfs (SSH Filesystem) позволяет смонтировать удалённую директорию по SSH как обычный локальный диск. Можно редактировать файлы прямо на сервере любым локальным редактором, без синхронизации.

Удалённые файлы не должны чувствоваться удалёнными. Инструменты должны стирать границы.

➤ Вариант 1 (Базовое монтирование): монтируем домашнюю директорию сервера в локальную папку.

sshfs user@server:/home/user /mnt/remote-server

➤ Вариант 2 (Монтирование с ключом и опциями): использование SSH-ключа и сжатия для медленных каналов.

sshfs -o Compression=yes,IdentityFile=~/.ssh/id_rsa user@server:/var/www /mnt/www

➤ Вариант 3 (Автоматическое монтирование при доступе): настройка в /etc/fstab с использованием sshfs (потребуется ключ без пароля или sshpass).

user@server:/remote/path /local/mountpoint fuse.sshfs noauto,x-systemd.automount,_netdev,users,identityfile=/home/user/.ssh/id_rsa,allow_other,reconnect 0 0

➤ Вариант 4 (Размонтирование):

fusermount -u /mnt/remote-server

sshfs - это автоматизация прозрачного доступа к удалённым данным. Он основан на FUSE (Filesystem in Userspace) и использует стандартный SSH-протокол, то есть не требует ничего, кроме работающего SSH-сервера на целевой машине.

Это незаменимая вещь для разработки, когда код лежит на сервере, или для администрирования, когда нужно просматривать/редактировать логи и конфиги в привычном редакторе.

P.S. Будьте осторожны с редактированием бинарных файлов или баз данных через sshfs - возможны проблемы с блокировками. Для конфигов и скриптов - идеально.

🌐 @helcode

nethogs — кто съел весь интернет?

iftop показывает общую нагрузку на интерфейс, nload - графики скорости. Но когда трафик неожиданно вырастает, хочется знать не *сколько*, а *кто* именно. nethogs разбивает трафик по процессам: показывает PID, имя программы и скорость загрузки/отдачи для каждого процесса.

Внезапный всплеск трафика на сервере - это либо кто-то скачивает обновления, либо сервер взломан и участвует в DDoS. Разница критическая.

➤ Вариант 1 (Базовый запуск): запуск без аргументов показывает все процессы на всех интерфейсах.

sudo nethogs

➤ Вариант 2 (Выбор интерфейса): следим только за внешним интерфейсом.

sudo nethogs eth0

➤ Вариант 3 (Интервал обновления): медленное обновление для длительного наблюдения.

sudo nethogs -d 5 eth0
# -d 5: обновление каждые 5 секунд

➤ Вариант 4 (Режим просмотра): переключение между суммарным и поточным отображением клавишей m.

nethogs - это автоматизация привязки сетевого трафика к конкретным процессам. Он отвечает на вопрос, на который iftop ответить не может: «Какая программа так активно качает?».

Полезно как для серверов (поиск утекшего трафика, подозрительной активности), так и для рабочих станций (почему тормозит интернет, что за процесс обновляется).

P.S. nethogs требует прав root для просмотра процессов других пользователей. Запускайте через sudo.

🌐 @helcode

script — запись сессии терминала для документации или разбора инцидента

Сделали сложную последовательность действий, которая привела к починке системы. Через месяц потребуется повторить, а Вы уже не помните детали. Или нужно показать коллеге точную последовательность команд и их вывод. script записывает всё, что происходит в терминале - и ввод, и вывод - в файл.

Память человека - ненадёжный носитель. Сессия терминала, записанная в файл, - надёжный.

➤ Вариант 1 (Простая запись): запуск script начинает запись, exit завершает.

script session.log
# ... делаем что-то важное ...
exit
# Всё сохранено в session.log

➤ Вариант 2 (Запись с меткой времени): полезно для расследования инцидентов, чтобы понимать, в какой момент что произошло.

script --timing=timing.txt session.log
# Позже можно воспроизвести сессию с реальными задержками
scriptreplay --timing=timing.txt session.log

➤ Вариант 3 (Тихий режим): запись без сообщений о начале и конце.

script -q session.log

➤ Вариант 4 (Дозапись): добавление к существующему логу.

script -a session.log

script - это автоматизация документирования работы в терминале. Он превращает хаотичную сессию администрирования в структурированный лог, который можно:
➤ Приложить к постмортему.
➤ Использовать для обучения новых сотрудников.
➤ Разобрать, чтобы понять, какая именно команда что-то сломала.
➤ Воспроизвести для демонстрации.

P.S. script записывает даже управляющие последовательности (цвета, позиционирование курсора), поэтому файл может содержать "мусор". Для просмотра лучше использовать cat или less -R, чтобы видеть оригинальное форматирование.

🌐 @helcode

shellcheck — статический анализ для ваших bash-скриптов

Bash-скрипт написан, работает... но почему-то падает на пустых переменных или некорректно обрабатывает пробелы в именах файлов. shellcheck - это линтер для shell-скриптов, который находит сотни потенциальных ошибок, уязвимостей и неэффективностей, объясняя, что именно не так и как это исправить.

Bash - мощный, но коварный язык. Ошибки в нём часто проявляются не сразу, а в самый неподходящий момент.

➤ Вариант 1 (Базовая проверка): просто запустить shellcheck на скрипте.

shellcheck deploy.sh

➤ Вариант 2 (Интеграция в редактор): плагины для VS Code, Sublime, Vim подсвечивают проблемы прямо во время написания кода.

➤ Вариант 3 (Интеграция в CI/CD): добавление шага в пайплайн, который проверяет все .sh файлы. Если скрипт содержит ошибки — пайплайн падает.

# Пример для GitLab CI
shellcheck:
  script:
    - apt-get install -y shellcheck
    - shellcheck *.sh

➤ Вариант 4 (Подавление предупреждений): иногда нужно отключить конкретную проверку, если Вы точно знаете, что делаете.

# shellcheck disable=SC2086
some_command $variable  # SC2086: Double quote to prevent globbing and word splitting

shellcheck - это автоматизация повышения качества и надёжности скриптов. Он превращает написание bash-скриптов из шаманства в инженерную дисциплину с обратной связью от инструмента.

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

P.S. У shellcheck есть онлайн-версия (shellcheck.net), куда можно скопировать код и мгновенно увидеть все проблемы. Полезно, если нет возможности установить локально.

🌐 @helcode

systemd: сервисы, которые умеют себя обслуживать

Писать скрипты на Bash для запуска демонов и их перезапуска при падении — это изобретение велосипеда. systemd — это фреймворк для управления жизненным циклом служб со встроенными возможностями самовосстановления.

Скрипт в /etc/init.d/, который не умеет корректно обрабатывать сигналы и логировать, — это наследие прошлого.

➤ Вариант 1 (Базовая устойчивость): простая конфигурация юнита с Restart=on-failure и RestartSec=5 уже делает сервис намного надежнее.

[Service]
ExecStart=/usr/bin/my_daemon
Restart=on-failure
RestartSec=5
StandardOutput=journal

➤ Вариант 2 (Зависимости и порядок): правильное указание After=network.target и Requires=postgresql.service гарантирует, что сервис запустится только когда его зависимости готовы.

➤ Вариант 3 (Ограничение ресурсов): секция [Slice] и MemoryMax позволяют ограничить потребление памяти, предотвращая «проседание» всей системы из-за одной утечки.

systemd — это автоматизация управления процессами на уровне ОС. Он превращает приложение из «просто исполняемого файла» в управляемый, наблюдаемый и устойчивый сервис.

Какие возможности systemd, помимо простого start/stop, Вы используете чаще всего? Мониторинг через journalctl, cgroups или таймеры?

P.S. Споры о systemd — бесконечны, но его распространенность в современном Linux-мире делает его знание обязательным. Это не всегда выбор, но это реальность.

🌐 @helcode

Git Hooks: Твой личный робот-помощник

Хотите, чтобы код автоматически прогонял тесты перед каждым коммитом? Или чтобы линтер проверял стиль? Или чтобы скрипт развертывания сам запускался после пушa в main? Пора познакомиться с Git Hooks.

Хуки лежат в папке .git/hooks/. Пример пре-коммит хука (.git/hooks/pre-commit), который не даст закоммитить код, не прошедший линтинг:

#!/bin/sh
echo "Запуск линтера..."
if ! eslint --cache --fix .; then
    echo "Линтер нашел ошибки! Коммит отменен."
    exit 1
fi
git add .  # Добавляем исправления, сделанные линтером

Не забудьте дать файлу права на выполнение: chmod +x .git/hooks/pre-commit

Git Hooks — это скрипты, которые Git запускает в ответ на определенные события (commit, push, rebase и т.д.). Они выполняются локально и позволяют автоматизировать рутину и внедрить контроль качества.

Какой самый полезный или безумный Git Hook Вы когда-либо использовали или хотели бы использовать? Поделитесь идеями!

Настроить pre-commit хук — это как нанять очень принципиального секьюрити, который не пустит Вас на работу в пижаме. Иногда раздражает, но в итоге все только выигрывают.

🌐 @helcode

Автоматическое резервное копирование: спим спокойно

Бэкапы — это как страховка: все знают, что нужны, но мало кто их делает. Исправим это одним скриптом.

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

Вариант 1 (Bash-скрипт + Cron):

#!/bin/bash
BACKUP_DIR="/backups"
DATE=$(date +%Y%m%d_%H%M%S)

# Бэкап базы данных
pg_dump mydb > $BACKUP_DIR/mydb_$DATE.sql

# Бэкап важных директорий
tar -czf $BACKUP_DIR/app_$DATE.tar.gz /app/data

# Удаляем старые бэкапы (старше 30 дней)
find $BACKUP_DIR -name "*.sql" -mtime +30 -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete

Вариант 2 (Python-скрипт с отправкой в облако):

import boto3
from datetime import datetime

s3 = boto3.client('s3')
backup_file = f"backup_{datetime.now().strftime('%Y%m%d')}.sql"

# Создаем бэкап и загружаем в S3
subprocess.run(['pg_dump', 'mydb', '-f', backup_file])
s3.upload_file(backup_file, 'my-backup-bucket', backup_file)

Disaster Recovery — автоматизируем процессы восстановления после сбоев. Правило 3-2-1: 3 копии данных, на 2 разных носителях, 1 копия off-site.

А как у вас с бэкапами? Ручные, автоматические, или по принципу "если продакшен упадет, просто найдем новую работу"?

P.S. Есть два типа людей: те, кто делают бэкапы, и те, кто еще будет их делать.

🌐 @helcode