Test Your Sysadmin Skills - большая база вопросов для Linux и DevOps!

В этом репозитории собраны сотни вопросов и ответов по Linux, сетям, безопасности, webops, базам данных, системным задачам и диагностике. Материал удобно использовать для самопроверки, подготовки к собеседованиям и поиска тем, которые стоит подтянуть.

Оставляю ссылочку на GitHub

➡️ DevOps Ready | #репозиторий

Знали, зачем перед rsync --delete почти всегда делать dry-run?

rsync часто используют для деплоя, бэкапов и синхронизации директорий. Команда быстрая, удобная и хорошо переносит только изменившиеся файлы.

Ключ --delete полезен, когда целевая папка должна точно совпадать с источником. Например, в dist удалили старый JS-файл, значит на сервере он тоже должен исчезнуть.

Обычный деплой может выглядеть так.

rsync -av --delete ./dist/ server:/var/www/app/

Но именно --delete делает команду опасной. Если перепутать путь, слеш или переменную окружения, можно удалить не те файлы на удалённой стороне.

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

rsync -av ./dist/ server:/var/www/app/
rsync -av ./dist server:/var/www/app/

В первом случае копируется содержимое папки dist. Во втором случае внутрь назначения может попасть сама папка dist.

Перед реальным запуском лучше посмотреть план изменений.

rsync -av --delete --dry-run ./dist/ server:/var/www/app/

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

Для более читаемого вывода можно добавить --itemize-changes.

rsync -av --delete --dry-run --itemize-changes ./dist/ server:/var/www/app/

Так проще увидеть, какие файлы будут добавлены, изменены или удалены. Особенно полезно смотреть строки удаления перед запуском без --dry-run.

Если команда собирается из переменных, dry-run становится ещё важнее.

SRC="./dist/"
DST="server:/var/www/app/"
rsync -av --delete --dry-run "$SRC" "$DST"

Так можно быстро заметить пустую переменную, неправильный путь или неожиданный каталог назначения.

Когда вывод выглядит нормально, можно запустить ту же команду без --dry-run.

rsync -av --delete ./dist/ server:/var/www/app/

В CI/CD удобно делать dry-run отдельным ручным шагом для новых deploy-команд. А для регулярных задач стоит хотя бы использовать его при первом запуске после изменения путей.

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

rsync -av --delete --dry-run --itemize-changes "$SRC" "$DST" | grep "^\*deleting"

Если удалений внезапно слишком много, запуск лучше остановить и перепроверить переменные.

Ещё полезно держать источник и назначение в логах.

echo "SRC=$SRC"
echo "DST=$DST"

Это звучит просто, но в реальном deploy-скрипте такая печать часто экономит много времени при разборе инцидента.

➡️ DevOps Ready | #совет

Запускаем скрипт по расписанию через systemd timer!

Cron удобен, но в systemd есть свой способ запускать задачи по расписанию. Он хорошо дружит с логами journalctl, статусами юнитов и обычной системой сервисов.

Пусть есть простой скрипт обслуживания:

/opt/jobs/cleanup.sh

Сначала сделаем его исполняемым:

sudo chmod +x /opt/jobs/cleanup.sh

Теперь создадим service-unit. Именно он описывает, что запускать:

sudo nano /etc/systemd/system/cleanup.service

Минимально нужен тип oneshot:

Type=oneshot

Команду запуска указываем отдельно:

ExecStart=/opt/jobs/cleanup.sh

Теперь создаём timer-unit:

sudo nano /etc/systemd/system/cleanup.timer

Например, ежедневный запуск можно описать так:

OnCalendar=daily

Если сервер был выключен во время расписания, полезен Persistent:

Persistent=true

После создания файлов перечитываем конфигурацию systemd:

sudo systemctl daemon-reload

Включаем таймер:

sudo systemctl enable --now cleanup.timer

Проверить расписание можно так:

systemctl list-timers cleanup.timer

А логи последнего запуска смотрятся через journalctl:

journalctl -u cleanup.service

Service отвечает за действие, timer отвечает за расписание. Поэтому одну и ту же задачу можно запускать вручную, по расписанию и удобно проверять через стандартные инструменты systemd.

➡️ DevOps Ready | #практика

📂 Напоминалка по постепенному внедрению мониторинга в проект!

Мониторинг помогает раньше замечать ошибки, деградацию производительности и проблемы с доступностью, но для старого проекта необязательно сразу делать большой рефакторинг. На картинке показаны 7 шагов: от определения ключевых метрик и использования готовых логов до подключения агентов, добавления базовых метрик, настройки дашбордов и алертов, а также постепенного улучшения системы.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Шпаргалка по Ansible!

Например, ad-hoc команды помогают быстро выполнить действие на группе серверов, inventory описывает хосты, а playbook позволяет хранить автоматизацию в YAML-файле.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Проверяем свободное место перед backup-скриптом!

Очень частая проблема в автоматизации. Backup запускается по cron, архив начинает писаться, а потом диск заканчивается посередине процесса. В итоге получается битый файл, лишняя нагрузка и непонятная ошибка в логах.

Перед созданием архива лучше заранее проверить, хватает ли места.

Сначала зададим директорию и минимальный запас в килобайтах:

backup_dir="/var/backups/app"
min_free_kb=1048576

Теперь получим свободное место через df. Ключ -P делает вывод предсказуемым для скриптов:

free_kb=$(df -Pk "$backup_dir" | awk "NR == 2 {print $4}")

Если места меньше нужного, завершаем скрипт с ошибкой:

if [ "$free_kb" -lt "$min_free_kb" ]; then
    echo "not enough disk space" >&2
    exit 1
fi

После проверки можно спокойно запускать архивирование:

tar -czf "$backup_dir/app.tar.gz" /opt/app/data

Для cron полезно добавить дату в имя файла, чтобы старые архивы не перезаписывались:

stamp=$(date +%Y%m%d-%H%M%S)
archive="$backup_dir/app-$stamp.tar.gz"

И использовать переменную archive:

tar -czf "$archive" /opt/app/data

Если нужно контролировать размер каталога заранее, можно примерно оценить его через du:

need_kb=$(du -sk /opt/app/data | awk "{print $1}")

Тогда проверка станет ближе к реальности:

if [ "$free_kb" -lt "$need_kb" ]; then
    echo "backup may not fit" >&2
    exit 1
fi

Такой скрипт не делает backup умнее сам по себе, но убирает неприятный класс ошибок. Лучше упасть до начала операции, чем получить недописанный архив и узнать об этом только при восстановлении.

➡️ DevOps Ready | #практика

☁️☁️☁️☁️☁️☁️☁️

24 сентября Yandex Cloud проведёт Yandex Scale 2026 — флагманскую технологическую конференцию, посвящённую облачным технологиям, инфраструктуре и искусственному интеллекту.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨
В программе четыре продуктовых трека — AI, Data, Security и Hybrid Infrastructure & DevOps, — и отдельный углублённый технологический трек DeepTech, который пройдёт только онлайн.

В треке Hybrid Infrastructure & DevOps откроем программу рассказом про главные инфраструктурные анонсы и новинки 2026 года. На примере Stackland расскажем, как построить свою внутреннюю платформу по методологии Platform Engineering и ускорить time to market. Разберём, зачем бизнесу кластеры Yandex Managed Service for Kubernetes на тысячи нод — на реальном продакшн-кейсе Mindbox. Расскажем, как получить предсказуемую и безопасную ИИ‑разработку с ИИ‑командой на платформе SourceCraft и максимизировать возврат инвестиций от ИИ. Разберём возможности построения реальной гибридной инфраструктуры на базе единой технологической платформы и то, как полноценно объединить локальную и облачную среды, включая выделенные серверы BareMetal. И на примере крупного банка рассмотрим, как создать полноценный гибрид, соблюдая требования безопасности, регуляторов и бизнеса одновременно.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨
Отдельно пройдут воркшопы по Hybrid Infrastructure & DevOps. Смоделируем аварию на физическом сервере и проверим, как гибридная архитектура на облаке и BareMetal держит отказоустойчивость. Научим разворачивать корпоративную ИИ-систему с RAG-сценарием на Yandex BareMetal и Stackland — чтобы модель работала с внутренней документацией и базами знаний. Разберём, как эффективно делить GPU-ресурсы Yandex Managed Service for Kubernetes между параллельными задачами обучения моделей. И покажем, как команда ИИ-агентов SourceCraft проходит путь от бизнес-требований до безопасного релиза — с проверкой на уязвимости на каждом шаге.

🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨
🎨🎨🎨🎨🎨🎨🎨🎨🎨🎨

На конференции будут не только треки — ещё демозоны, питчинг решений, IT-квест и мерч. Параллельно в онлайн-студии — розыгрыш призов и секретный гость.

Программа целиком — на сайте конференции, регистрация там же, а участие бесплатное!

Знали, зачем в Bash-скриптах включать set -u?

В deploy-скриптах и автоматизации часто используются переменные окружения. Например, путь к артефакту, имя окружения, адрес сервера или токен.

Проблема в том, что Bash по умолчанию спокойно подставляет пустую строку, если переменная не задана.

Например, такой код может выглядеть безобидно.

rm -rf "$TARGET_DIR"/*

Если TARGET_DIR внезапно пустой, команда может начать работать совсем не с тем путём, который ожидался.

Для защиты от таких ошибок включают set -u.

set -u

После этого обращение к незаданной переменной завершит скрипт ошибкой, а не превратится в пустую строку.

Пример.

set -u
echo "$DEPLOY_ENV"

Если DEPLOY_ENV не задана, скрипт остановится сразу. Это намного лучше, чем продолжить деплой в непонятное окружение.

Но иногда переменная может быть необязательной. Тогда для неё лучше явно задать значение по умолчанию.

LOG_LEVEL="${LOG_LEVEL:-info}"

Так код говорит, что отсутствие LOG_LEVEL допустимо, и в этом случае используется info.

Для обязательных переменных удобно использовать проверку с понятным сообщением.

: "${DEPLOY_ENV:?DEPLOY_ENV is required}"
: "${TARGET_DIR:?TARGET_DIR is required}"

Такая запись завершит скрипт, если переменная не задана или пустая, и сразу покажет нормальную причину ошибки.

В реальных скриптах set -u часто используют вместе с set -e и pipefail.

set -euo pipefail

Но важно не включать режимы механически. Если в скрипте есть необязательные переменные, для них нужно использовать безопасные формы вроде ${VAR:-default}.

➡️ DevOps Ready | #совет

DevOpsPath - интерактивная карта навыков для DevOps-инженера!

На сайте собраны направления, которые помогают выстроить обучение по инфраструктуре без хаоса. Есть Linux, networking, containers, Kubernetes, CI/CD, cloud, monitoring, security и практические ориентиры для роста.

Оставляю ссылочку на DevOpsPath

➡️ DevOps Ready | #ресурс

Делаем безопасный backup конфига перед изменением!

Перед правкой nginx, systemd unit, docker-compose.yml или любого важного конфига полезно сначала сохранить копию. Это занимает секунды, но сильно упрощает откат.

Зададим путь к файлу:

file="/etc/nginx/nginx.conf"

Добавим timestamp:

stamp="$(date +%Y%m%d-%H%M%S)"

Соберём имя backup-файла:

backup="${file}.${stamp}.bak"

Перед копированием проверим, что файл существует:

test -f "$file" || {
  echo "Файл не найден: $file"
  exit 1
}

Теперь создаём копию с сохранением прав и владельца:

sudo cp -a "$file" "$backup"

После этого можно редактировать конфиг:

sudo nano "$file"

Если это nginx, сначала проверяем конфигурацию:

sudo nginx -t

И только потом перезагружаем сервис:

sudo systemctl reload nginx

Если что-то пошло не так, откат простой:

sudo cp -a "$backup" "$file"
sudo systemctl reload nginx

Для удобства можно посмотреть последнюю копию:

ls -lt /etc/nginx/nginx.conf.*.bak | head

Backup перед изменением конфига это маленькая привычка, которая часто экономит часы восстановления после неудачной правки.

➡️ DevOps Ready | #практика