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

Война с плавающим багом в CI

Ваш CI-пайплайн падает раз в два дня из-за плавающего теста, и все делают вид, что не замечают? Сегодня объявляем ему войну. Не игнорируем, а автоматизируем поимку.

Это классика: "У меня работает", "Heisenbug*", который исчезает при попытке отладки. Команда привыкает к красному статусу и перестает ему доверять, что убивает саму идею CI. Ручной перезапуск — это не решение, это признание поражения.

➤ Вариант 1 (Bash + Cron): Пишем скрипт, который дергает API вашего CI (например, Jenkins/GitLab), проверяет последний запуск падающего джоба и в случае ошибки автоматически перезапускает его, отправляя уведомление в Slack.

# Пример для GitLab CI с использованием jq и curl
PIPELINE_STATUS=$(curl -s --header "PRIVATE-TOKEN: <your_token>" "https://gitlab.com/api/v4/projects/<project_id>/pipelines/latest" | jq -r '.status')
if [ "$PIPELINE_STATUS" = "failed" ]; then
    curl --request POST --header "PRIVATE-TOKEN: <your_token>" "https://gitlab.com/api/v4/projects/<project_id>/pipelines/latest/retry"
    curl -X POST -H 'Content-type: application/json' --data '{"text":"Плавающий тест снова упал. Автоперезапуск...»"}' $SLACK_WEBHOOK
fi

➤ Вариант 2 (GitHub Actions): используем schedule и джоб с условием для автоматического перезапуска только конкретного флаки-теста.

jobs:
  retry_flaky_test:
    if: failure() && contains(github.event.head_commit.message, 'retry flaky test')
    runs-on: ubuntu-latest
    steps:
      - name: Retry the flaky test suite
        run: |
          echo "Автоматический ретрай запущен"

Речь об устойчивости и проактивном мониторинге. Система не должна полагаться на бдительность человека. Мы встраиваем механизм самовосстановления для известных, но трудноустранимых проблем. Это тот же принцип, что и в livenessProbe в Kubernetes: если система нездорова, ее нужно перезапустить, прежде чем бить в колокола.

А в вашей команде есть "призрачный" баг? Как вы с ним боретесь: пишете сложные логи, ставите ретраи или просто молитесь?

P.S. Автоматический ретрай — это не починка бага, это костыль. Но лучше автоматический костыль, чем кривые костыли ручных ретраев.

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

🌐 @helcode

Сила .gitignore: защита от самого себя

Коммит файлов с паролями, конфигурацией IDE или артефактами сборки — это классическая ошибка, которая случается с каждым. .gitignore — это не список, это оборонительный периметр Вашего репозитория.

Человеческая память ненадежна. Доверить ей решение, что можно коммитить, а что нет — наивно.

➤ Вариант 1 (Глобальный ~/.gitignore_global): для файлов, которые никогда не должны попадать ни в один репозиторий: .DS_Store, Thumbs.db, *.swp, файлы конфигурации Вашего редактора.

# Настройка
git config --global core.excludesfile ~/.gitignore_global

➤ Вариант 2 (Специфичный для языка/инструмента): генерация или использование готовых шаблонов для Python (__pycache__/, *.pyc), Node.js (node_modules/), Java (target/), Go (/vendor/).

➤ Вариант 3 (.gitignore как часть инициализации проекта): автоматическое создание адекватного .gitignore при старте нового проекта через git init или инструменты вроде cookiecutter.

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

Доводилось ли Вам «вычищать» историю репозитория из-за случайно закоммиченного секрета? Или .gitignore всегда стоит на страже?

P.S. Есть сервисы вроде git-secrets или truffleHog, которые сканируют историю на наличие ключей и паролей. Но лучше не допускать их попадания туда.

🌐 @helcode