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

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 | #практика

Знали, зачем в Bash-скриптах иногда включают noclobber?

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

Например, такая команда всегда перезапишет файл:

echo "ready" > report.txt

Если report.txt уже существовал, старое содержимое пропадёт без предупреждения.

Для защиты можно включить режим noclobber:

set -o noclobber

После этого обычное перенаправление через > не сможет перезаписать существующий файл:

set -o noclobber
echo "ready" > report.txt

Если файл уже есть, shell завершит команду ошибкой. Это полезно для отчётов, lock-файлов, backup-метаданных и любых артефактов, которые нельзя случайно затереть.

Когда перезапись действительно нужна, её можно сделать явно через >|:

echo "ready" >| report.txt

Так в коде сразу видно намерение. Обычный путь защищён, а опасное действие становится заметным.

Часто noclobber используют локально в небольшом блоке:

set -o noclobber
echo "$payload" > "$target"

А если скрипт должен продолжить работу с обычным поведением, режим можно выключить:

set +o noclobber

Важно помнить, что noclobber защищает именно перенаправление shell. Он не мешает программе внутри команды самой открыть файл на запись.

➡️ DevOps Ready | #совет

Netshoot - набор сетевых инструментов для диагностики контейнеров!

В репозитории собран Docker-образ для сетевой отладки в Docker и Kubernetes. Внутри есть tcpdump, tshark, termshark, curl, httpie, grpcurl, nmap, netcat, socat, iproute2, mtr, iperf, openssl и другие утилиты.

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

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

Знали, зачем для одноразовых контейнеров часто добавляют docker run --rm?

Когда контейнер запускают для короткой проверки, он после завершения остаётся в системе. Сам процесс уже не работает, но запись о контейнере и его writable layer остаются.

Например так:

docker run alpine echo ready

Если делать такие запуски часто, docker ps ничего лишнего не покажет, потому что контейнеры уже остановлены. Но они всё ещё видны через docker ps -a.

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

docker ps -a

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

Для одноразовых команд добавляют --rm:

docker run --rm alpine echo ready

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

Например для сетевой проверки:

docker run --rm curlimages/curl \
  curl -I https://example.com

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

Для отладки иногда лучше оставить контейнер:

docker run --name debug-app my-image

Для коротких одноразовых команд --rm помогает держать Docker чистым. Для расследования падений лучше сначала сохранить контейнер и удалить его вручную позже.

➡️ DevOps Ready | #совет

📂 Шпаргалка по организации конфигурации DevOps окружений!

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

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

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

Знали, зачем для одноразовых контейнеров часто добавляют docker run --rm?

Когда контейнер запускают для короткой проверки, он после завершения остаётся в системе. Сам процесс уже не работает, но запись о контейнере и его writable layer остаются.

Например так:

docker run alpine echo ready

Если делать такие запуски часто, docker ps ничего лишнего не покажет, потому что контейнеры уже остановлены. Но они всё ещё видны через docker ps -a.

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

docker ps -a

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

Для одноразовых команд добавляют --rm:

docker run --rm alpine echo ready

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

Например для сетевой проверки:

docker run --rm curlimages/curl \
  curl -I https://example.com

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

Для отладки иногда лучше оставить контейнер:

docker run --name debug-app my-image

Для коротких одноразовых команд --rm помогает держать Docker чистым. Для расследования падений лучше сначала сохранить контейнер и удалить его вручную позже.

➡️ DevOps Ready | #совет

Знали, зачем в скриптах использовать install вместо touch плюс chmod?

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

Обычно пишут в несколько шагов:

touch /etc/myapp/token
chmod 600 /etc/myapp/token

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

Для таких случаев есть install:

install -m 600 /dev/null /etc/myapp/token

Команда создаёт файл и сразу выставляет нужные права. /dev/null здесь используется как пустой источник.

Для директорий тоже можно сразу указать режим:

install -d -m 750 /var/lib/myapp

А если нужно задать владельца и группу:

install -o app -g app -m 750 -d /var/lib/myapp

Это делает deploy-скрипт короче и безопаснее. Права, владелец и сам факт создания описаны в одной команде, а не размазаны по нескольким строкам.

➡️ DevOps Ready | #совет

Знали, почему порядок COPY в Dockerfile может сильно влиять на скорость сборки?

Docker собирает образ слоями и старается переиспользовать кеш. Если слой не изменился, он берётся из кеша, а следующая команда не выполняется заново.

Проблема часто появляется в Node, Python, Java и других проектах, где зависимости устанавливаются до копирования всего исходного кода.

Неудачный Dockerfile может выглядеть так:

COPY . .
RUN npm ci
RUN npm run build

Теперь любое изменение в одном файле проекта сбивает кеш для COPY . . После этого npm ci запускается заново, даже если package.json вообще не менялся.

Лучше сначала копировать только файлы зависимостей:

COPY package*.json ./
RUN npm ci

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

Исходный код копируют уже после установки:

COPY . .
RUN npm run build

Такая же идея работает и для других стеков. В Python сначала копируют requirements.txt или pyproject.toml, в Java отдельно копируют pom.xml или gradle-файлы.

Например для Maven:

COPY pom.xml ./
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package

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

➡️ DevOps Ready | #совет

K9s - удобный терминальный интерфейс для Kubernetes!

Этот репозиторий содержит CLI-инструмент, который открывает интерактивный terminal UI для работы с Kubernetes-кластерами. Через него удобно смотреть Pod, Deployment, Service, логи, события и состояние ресурсов без постоянного набора kubectl-команд.

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

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

Шпаргалка по командам Helm!

Например, helm install ставит chart в кластер, helm upgrade обновляет релиз, а helm rollback помогает быстро откатиться на предыдущую рабочую версию.

На картинке собраны основные команды Helm. Есть установка и удаление приложений, работа с repo, поиск chart, обновление релизов, rollback, просмотр values, hooks, manifest и управление плагинами.

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

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

Делаем простой release через symlink!

Иногда приложение нужно выкладывать так, чтобы новая версия появлялась почти мгновенно, а откат занимал одну команду. Для этого часто используют директории releases и ссылку current.

Структура может быть такой:

/opt/app/releases/2026-08-29_1200
/opt/app/current -> /opt/app/releases/2026-08-28_1800

Сначала создаём новую папку релиза:

release="/opt/app/releases/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$release"

Потом копируем туда собранные файлы:

rsync -a ./dist/ "$release/"

До переключения current пользователи всё ещё смотрят на старую версию. Это удобно, потому что подготовка релиза не ломает рабочее приложение.

Переключение делается через ln -sfn:

ln -sfn "$release" /opt/app/current

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

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

ln -sfn /opt/app/releases/2026-08-28_1800 /opt/app/current

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

Такой подход полезен для простых серверов, статических сайтов, внутренних тулов и приложений без сложной deploy-платформы.

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

Linux Journey - маршрут по Linux с практическими темами!

На сайте собраны уроки по командной строке, файловой системе, процессам, permissions, пакетам, устройствам, networking, DNS, routing, logging и другим темам, которые нужны DevOps-инженеру и backend-разработчику.

Разделы идут как большая карта обучения. Можно открыть тему, пройти объяснение, перейти к упражнениям и потом двигаться дальше по связанным главам без обязательной регистрации.

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

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