Библиотека девопса | DevOps, SRE, Sysadmin

❓ Вопрос с собеса

ConfigMap обновлён. Что происходит дальше в работающем поде?

piVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  DB_POOL_SIZE: "10"

Вы меняете LOG_LEVEL на debug. Применяете через kubectl apply. Под работает, не перезапускался. Приложение видит info или debug? ➡️ Ответ тут 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #задача_со_звёздочкой

🛠 Логирование с временными метками в bash-скриптах Когда скрипт падает на проде в три ночи, первый вопрос: что именно произошло и в какой момент. Без логов остаётся только гадать. Три функции вместо голого echo:

#!/bin/bash
set -euo pipefail

LOG_FILE="/var/log/myscript.log"

log()  { echo "[INFO]  $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; }
warn() { echo "[WARN]  $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; }
error(){ echo "[ERROR] $(date '+%H:%M:%S') $1" | tee -a "$LOG_FILE"; exit 1; }

log "Script started"
warn "Config file missing, using defaults"
error "Database connection failed"   # здесь скрипт остановится

Три уровня: log для обычных событий, warn для подозрительного, error для критического с немедленным выходом. tee -a пишет одновременно в терминал и в файл. Флаг -a означает append, то есть каждый запуск дописывает в конец, а не перезаписывает лог с нуля. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🌐 Контроль сетевого трафика CI-runner'ов У большинства команд нет никакой видимости того, что их CI-runner'ы делают в сети. Это серьёзная слепая зона. Step Security выпустили GitHub Action, который логирует или блокирует исходящие соединения прямо во время билда. Добавляется одним шагом в начало каждой джобы:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Добавьте этот шаг ПЕРВЫМ в каждом job
      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit       # 'audit' только логирует, 'block' блокирует
          allowed-endpoints: >       # белый список разрешённых эндпоинтов
            registry.npmjs.org:443
            github.com:443
            objects.githubusercontent.com:443

      - uses: actions/checkout@v4
      - run: npm ci
      # Любое соединение с sfrclak.com теперь попадёт в логи безопасности

Два режима работы В режиме audit Harden-Runner пишет в лог все исходящие соединения, ничего не блокируя. Это безопасный старт: билды не ломаются, но вы видите реальный сетевой профиль своего пайплайна. Когда понимаете, какие соединения для вас нормальные, переключаетесь на block с белым списком. Любое неожиданное исходящее соединение сразу роняет билд. Начните с audit, посмотрите на трафик неделю, потом переходите на block. Большинство легитимных билдов ходят в три-пять известных эндпоинтов, и белый список для них составляется за пять минут. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

Как и зачем эффективно интегрировать legacy-системы через Apache Kafka? Ждем вас на открытом практикуме «Интеграция legacy-систем через Apache Kafka: быстрый старт без переписывания всего» от ОТУС! Расписание эфира: • Проблема: почему просто переписать — это рискованно, а P2P-интеграции ведут к спагетти-архитектуре • Решение: Apache Kafka как слой реального времени — обзор паттерна «труба и фильтры» для Legacy • Разбор паттернов: как обмануть старую систему: дуалирование записи (Dual Writes) и чтение из журналов транзакций • Дорожная карта: 3 шага к отказу от монолита с сохранением работоспособности старой системы (Strangler Fig Pattern) Ведущий: Сергей Прощаев — ведущий инженер в компании ПАО «Сургутнефтегаз». Бонусы для участников: 7% скидка на любой курс ОТУС Доступ к бесплатному пробному периоду корпоративной платформы Экспертные разборы по Kafka Ссылка на регистрацию: https://clc.to/-YTpeg Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👀 Просмотр истории команд в терминале Если вы часто работаете в терминале, вы знаете это чувство: нужная команда была, но куда делась. Прокручивать весь history неудобно. Вот два простых bash-алиаса, которые решают эту проблему. Последние N команд:

h() {
  history | tail -n "$1"
}

Вызываете h 20 и получаете последние 20 команд. Поиск по истории:

hg() {
  history | grep "$1"
}

Когда помните только часть команды, hg docker или hg ssh быстро находит всё, что вы когда-либо запускали с этим словом. Положите обе функции в ~/.bashrc или ~/.zshrc и перезагрузите конфиг:

source ~/.bashrc

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🔄 PowerShell 7.6 вышел с опозданием Релиз PowerShell 7.6 запланировали намного раньше, а вышел он в марте 2026 года. Команда опубликовала разбор того, что пошло не так. Суть проблем сводится к нескольким факторам. В октябре 2025 года в систему сборки внесли изменения, из-за которых сломался Alpine-пакет. Библиотека Microsoft.PowerShell.Native собиралась новым инструментом, несовместимым с Alpine. Следом в ноябре добавились новые требования по комплаенсу: пришлось менять инструменты упаковки пакетов для не-Windows-платформ. Это сдвинуло выход исправлений с октября на декабрь. В декабре вышел preview.6, но из-за заморозки изменений на праздники и ограниченной доступности ключевых людей не удалось опубликовать пакеты в PMC и NuGet. В январе 2026-го всплыла ещё одна проблема: библиотека libpsl-native на RHEL 8 требовала сборки под glibc 2.28, а не 2.33, которую использовали для RHEL 9 и выше. Команда честно признала системные сбои в процессе. Не было чёткого владельца релиза, не хватало структурированного отслеживания состояния, а замедление цикла preview-версий означало, что проблемы обнаруживались поздно, когда их исправление обходилось дороже. Что теперь меняется: команда назначила явного ответственного за каждый релиз, настроила внутренний трекинг блокеров, восстанавливает регулярный график preview и упрощает систему сборки пакетов. ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #разбор_полётов

💻 Топ-вакансий для девопсов за неделю Junior DevOps engineer — от 90 000 ₽, удалёнка DevOps Engineer — до 300 000 ₽, офис в Санкт-Петербурге Middle DevOps Engineer — до 6 000 $, удалёнка ➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs 🐸Библиотека devops'a #вакансия_недели

🖇 Kubernetes v1.36: что будет нового Команда Kubernetes опубликовала предварительный обзор v1.36. Релиз выходит 22 апреля 2026 года. Список фич ещё может измениться, но основное уже зафиксировано. Что уходит gitRepo volume plugin удалён окончательно. Плагин был помечен как устаревший ещё в v1.11, но технически работал до последнего. Если у вас есть workloads с gitRepo, нужно мигрировать на init containers или git-sync. Поле spec.externalIPs в Service помечается как устаревшее. Оно позволяло проводить man-in-the-middle атаки на трафик кластера. Альтернативы: LoadBalancer, NodePort или Gateway API. Ingress NGINX выведен из строя 24 марта 2026 года. Новых релизов, патчей безопасности и багфиксов больше не будет. Что стабилизируется SELinux-лейблинг для томов. Вместо рекурсивного перелейблинга файлов теперь применяется монтирование с опцией -o context=XYZ. Метка применяется ко всему тому сразу при монтировании. Внешнее подписание токенов ServiceAccount. Kube-apiserver делегирует подписание токенов внешним системам: облачным KMS или аппаратным HSM. Dynamic Resource Allocation получает новые возможности Пометки устройств и допуски для DRA переходят в бету и включаются по умолчанию. DRA-драйверы могут помечать устройства как недоступные для планировщика — тогда они не используются, пока нагрузка явно не запросит такое устройство. Разделяемые устройства в DRA: одна физическая карта теперь может делиться на несколько логических единиц для разных нагрузок. GPU больше не нужно отдавать целиком одному поду. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🧑‍💻 Храним секреты без менеджеров паролей: реальные примеры Если у вас нет Vault или AWS Secrets Manager, это не значит, что секреты можно кидать в .env и надеяться на лучшее. Есть несколько рабочих способов защититься без сторонних платных инструментов. Docker Secrets Docker Swarm умеет хранить секреты отдельно от контейнера. Файл не попадает в образ, не светится в docker inspect, не передаётся через переменные окружения. Создаём секрет:

echo "my_super_password" | docker secret create db_password -

Используем в docker-compose.yml:

version: "3.8"

services:
  app:
    image: myapp:latest
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true

Внутри контейнера секрет доступен как файл /run/secrets/db_password. В коде читаем так:

with open("/run/secrets/db_password") as f:
    password = f.read().strip()

Если Swarm не нужен и работаете в обычном Compose, секрет можно передать через файл на хосте:

secrets:
  db_password:
    file: ./secrets/db_password.txt

Файл ./secrets/db_password.txt добавляем в .gitignore. В репозиторий он не попадает, но и на машине лежит в читаемом виде. GitHub Actions: repository secrets Секреты хранятся на стороне GitHub, в код не попадают. Добавляем через Settings → Secrets and variables → Actions. Пример воркфлоу, который использует токен для деплоя:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to VPS
        env:
          SSH_KEY: ${{ secrets.VPS_SSH_KEY }}
          VPS_HOST: ${{ secrets.VPS_HOST }}
        run: |
          echo "$SSH_KEY" > /tmp/deploy_key
          chmod 600 /tmp/deploy_key
          ssh -i /tmp/deploy_key -o StrictHostKeyChecking=no user@$VPS_HOST "cd /app && git pull && systemctl restart app"

Что здесь важно: ${{ secrets.VPS_SSH_KEY }} нигде не выводится в логи — GitHub автоматически маскирует значения. Если случайно напишете echo ${{ secrets.VPS_SSH_KEY }}, в логах увидите ***. Для разных окружений используйте энвы:

jobs:
  deploy:
    environment: production  # у этого environment свой набор секретов
    runs-on: ubuntu-latest

VPS без managed-сервисов: systemd и переменные окружения Если приложение запускается через systemd, секреты можно передать через EnvironmentFile. Файл лежит на сервере с ограниченными правами доступа. Создаём файл с секретами на VPS:

sudo mkdir -p /etc/myapp
sudo nano /etc/myapp/secrets.env

Содержимое файла:

DB_PASSWORD=my_super_password
API_TOKEN=abc123xyz

Ограничиваем доступ:

sudo chmod 600 /etc/myapp/secrets.env
sudo chown root:root /etc/myapp/secrets.env

В юнит-файле systemd подключаем файл:

[Unit]
Description=My App

[Service]
User=appuser
EnvironmentFile=/etc/myapp/secrets.env
ExecStart=/usr/bin/myapp
Restart=always

[Install]
WantedBy=multi-user.target

Приложение получает переменные окружения как обычно. Файл с секретами читает только root, в репозиторий он не попадает никогда. Дополнительный слой: git-crypt Если секреты всё-таки нужно хранить в репозитории (например, конфиги для команды), можно шифровать их прямо в git. git-crypt шифрует выбранные файлы с помощью GPG-ключа. Все видят зашифрованный blob, расшифровать может только тот, у кого есть ключ.

# Инициализация
git-crypt init

# Добавляем пользователя по GPG-ключу
git-crypt add-gpg-user USER_ID

# Указываем какие файлы шифровать (.gitattributes)
echo "secrets.env filter=git-crypt diff=git-crypt" >> .gitattributes

После этого secrets.env в репозитории выглядит как бинарный мусор. На машине с ключом обычный текст. Ни один из этих способов не заменяет полноценный менеджер секретов, но каждый из них закрывает конкретную дыру лучше, чем голый .env. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

👨‍💻 EXPOSE vs PUBLISH в Docker EXPOSE и -p оба про порты, но работают по-разному. Один объявляет намерение, другой реально открывает доступ. EXPOSE это документация, не настройка EXPOSE в Dockerfile говорит только одно: "контейнер слушает этот порт". Это подсказка для разработчика и для Docker, но не более. Трафик снаружи всё равно не пройдёт:

FROM node:18
EXPOSE 3000
CMD ["node", "index.js"]

После docker build и docker run без дополнительных флагов порт 3000 недоступен с хоста. EXPOSE ничего не открывает. PUBLISH это реальное пробрасывание порта Флаг -p при запуске контейнера связывает порт хоста с портом контейнера. Вот это уже работает:

# хост:контейнер
docker run -p 8080:3000 myapp

Теперь запрос на localhost:8080 попадает в контейнер на порт 3000. Без -p — не попадает, даже если EXPOSE 3000 прописан. Варианты использования -p:

# конкретный порт хоста
docker run -p 8080:3000 myapp

# случайный свободный порт хоста
docker run -p 3000 myapp

# только на localhost хоста, не наружу
docker run -p 127.0.0.1:8080:3000 myapp

# все порты из EXPOSE на случайные порты хоста
docker run -P myapp

Последний вариант с -P это единственный случай, когда EXPOSE влияет на поведение. Docker смотрит, какие порты объявлены через EXPOSE, и пробрасывает их все на случайные порты хоста. В Docker Compose Та же логика, другой синтаксис. expose — только между контейнерами внутри сети. ports — наружу на хост:

services:
  app:
    image: myapp
    expose:
      - "3000"      # видно другим сервисам в сети, не хосту
    ports:
      - "8080:3000" # видно хосту

Важный момент: контейнеры в одной Compose-сети и так видят друг друга по всем портам без expose и без ports. Директива expose в Compose нужна только для явной документации намерений. EXPOSE — документация для людей и инструментов. На реальный трафик не влияет. -p / ports — реальное пробрасывание, без него порт снаружи недоступен. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🔄 Deepin 25.1.0 Китайский дистрибутив Deepin выпустил новую версию, подглядываем что нового. Самое заметное по части производительности: переход ядра с 6.12 на 6.18. Туда вошёл планировщик BORE из CachyOS, который изначально делался для игр и плавного десктопа под нагрузкой. Из неожиданного: Claw Mode. Это режим управления всей системой голосом или текстом на естественном языке. Говоришь «открой терминал и переименуй все файлы в папке Downloads по дате» — система выполняет. ИИ-ассистент для текстов тоже переработан: теперь он сначала строит план, показывает его пользователю, тот может поправить, и только потом идёт генерация. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

🌐 Открываем localhost в интернет MekongTunnel это SSH-туннель сервер, написанный на Go. Он поднимает публичный HTTPS-URL для вашего локального приложения через SSH проброс удалённого порта. Как запустить:

sudo curl -L https://github.com/MuyleangIng/MekongTunnel/releases/download/v1.1.0/mekong-linux-amd64 \
  -o /usr/local/bin/mekong
sudo chmod +x /usr/local/bin/mekong

Для Linux amd64 меняете linux-amd64 на darwin-arm64 . Windows: скачиваете .exe и добавляете в PATH. Запуск туннеля:

mekong 3000

В терминале появится публичный URL вида https://happy-tiger-a1b2c3d4.mekongtunnel.dev, QR-код для телефона и URL уже скопирован в буфер. Или через чистый SSH без CLI:

ssh -t -R 80:localhost:8080 mekongtunnel.dev

Сервер имеет встроенную защиту от злоупотреблений. На один IP можно открыть не больше 3 туннелей, запросы ограничены 10 в секунду с бёрстом до 20. Если клиент переподключается слишком часто, IP блокируется на 15 минут. Чтобы не попасть в блок, держите соединение живым:

ssh -t -R 80:localhost:8080 \
    -o ServerAliveInterval=60 \
    -o ServerAliveCountMax=3 \
    yourdomain.com

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🎮 DOOM прямо в терминале через curl Кто-то сделал DOOM, который запускается через curl и рендерится в терминале ANSI-символами. Никаких зависимостей, никакого GUI — только браузер терминала и HTTP. Как запустить:

curl -sL http://localhost:3000 | bash

Есть и второй вариант: без bash, чистым curl. Но тут придётся вручную переключить терминал в raw mode, иначе curl не увидит нажатие клавиши до Enter:

stty -echo -icanon min 1 time 0 && curl -sN -X POST -T - localhost:3000/play

После игры терминал нужно починить командой reset. Сессии без активности удаляются через 60 секунд. Игра стартует сразу с E1M1 на сложности «Hurt me plenty», без меню. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #пульс_индустрии

23 апреля в 18:30 (мск) пройдёт офлайн-митап MWS Cloud Platform «Под капотом: инфраструктура». Также будет онлайн-трансляция. В программе доклады инженеров, которые ежедневно решают нетривиальные задачи при работе над инфраструктурными сервисами облака.  Вы сможете: — узнать, с какими сложными архитектурными задачами сталкивались, как выбирали технологии и почему принимали те или иные решения — подискутировать о разных подходах к решению схожих задач, задать вопросы,  поделиться своим опытом — понять, как лучше и эффективнее использовать облачные технологии для решения ваших рабочих задач После основной части — нетворкинг и угощения. Регистрируйтесь на митап! Это возможность обсудить нюансы, которые всплывают только в продакшене, и будут полезны на практике. 🗓23 апреля, начало в 18:30 📍Москва, Дом Культур, ул. Сретенка, 25 Вход бесплатный, но требуется регистрация и её подтверждение — количество мест ограничено. Зарегистрироваться

👨‍💻 Минимум, который должен быть в каждом репозитории Ручная проверка изменений в зависимостях не работает при любом серьёзном темпе разработки. Когда в PR меняется lockfile на тысячу строк, никто не будет вручную проверять каждый пакет. Именно так проскакивают вредоносные версии. Минимальная настройка • Dependabot для GitHub Включите в настройках репозитория: Settings → Security → Dependabot. Потом добавьте конфиг:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "security"

Dependabot будет создавать PR с обновлениями раз в неделю и автоматически помечать их нужными лейблами. • npm audit в CI Добавьте шаг в пайплайн и запускайте его до тестов, а не после:

- name: Security audit
  run: npm audit --audit-level=high

Флаг --audit-level=high завалит сборку только при уязвимостях уровня high и critical. Мелкие предупреждения не будут блокировать работу, но серьёзные проблемы не пройдут незамеченными. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🛠 Одна функция вместо десяти команд Каждый раз, когда нужно распаковать архив, начинается одно и то же. Это tar.gz или tar.bz2? Какие там флаги у unrar? А 7z вообще как запускается? Приходится лезть в документацию или историю команд. Самописная функция extract() решает именно эту проблему. Скопируйте функцию в ~/.bashrc или ~/.zshrc:

extract() {
  if [ -f "$1" ]; then
    case "$1" in
      *.tar.bz2) tar xjf "$1" ;;
      *.tar.gz)  tar xzf "$1" ;;
      *.bz2)     bunzip2 "$1" ;;
      *.rar)     unrar x "$1" ;;
      *.gz)      gunzip "$1" ;;
      *.tar)     tar xf "$1" ;;
      *.tbz2)    tar xjf "$1" ;;
      *.tgz)     tar xzf "$1" ;;
      *.zip)     unzip "$1" ;;
      *.7z)      7z x "$1" ;;
      *)         echo "unknown archive" ;;
    esac
  fi
}

Потом применяете изменения:

source ~/.bashrc

Функция определяет тип архива по расширению файла и сама выбирает нужную команду. Вы просто пишете extract имя_файла и получаете распакованное содержимое. Без флагов, без гугления, без ошибок из-за опечатки в параметрах. Поддерживаемые форматы: tar.gz, tar.bz2, bz2, rar, gz, tar, tbz2, tgz, zip, 7z. Один синтаксис для любого формата. Если файл не распознан, функция скажет unknown archive вместо того, чтобы молча упасть. Что можно добавить Базовая версия уже полезна, но её можно немного доработать. Например, добавить проверку, что нужная утилита вообще установлена, или выводить имя команды перед запуском. Вот расширенный вариант:

extract() {
  if [ ! -f "$1" ]; then
    echo "'$1' не найден"
    return 1
  fi

  case "$1" in
    *.tar.bz2) tar xjf "$1" ;;
    *.tar.gz)  tar xzf "$1" ;;
    *.bz2)     bunzip2 "$1" ;;
    *.rar)     unrar x "$1" ;;
    *.gz)      gunzip "$1" ;;
    *.tar)     tar xf "$1" ;;
    *.tbz2)    tar xjf "$1" ;;
    *.tgz)     tar xzf "$1" ;;
    *.zip)     unzip "$1" ;;
    *.7z)      7z x "$1" ;;
    *)         echo "Формат не поддерживается: '$1'" ; return 1 ;;
  esac
}

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #root_prompt

🤯 Представьте, что ваш AI-агент работает так же предсказуемо, как обычный микросервис. Звучит утопически, но это именно то, к чему должна прийти разработка в 2026 году. Основная боль текущих реализаций — полная непредсказуемость поведения. Сегодня агент выполнил задачу за два шага, а завтра ушёл в рекурсию и потратил все лимиты. Наш обновлённый курс «Разработка AI-агентов» научит, как приручить этот хаос с помощью Python и современных фреймворков. Мы не будем учить «общаться» с нейросетью, мы будем строить из неё надёжный инструмент. ✅ Что вы получите: — понимание того, как управлять логикой агента на уровне кода; — навыки работы с LangChain и библиотеками оркестрации; — готовые паттерны для обработки ошибок и галлюцинаций; — опыт создания систем, которые реально экономят время. Есть пара мест со скидкой до завтра, решайтесь 👈🏻

🔄 Релизная неделя Вспоминаем и освежаем все релизы недели — GNU nano 9.0 Главное изменение: переработанная горизонтальная прокрутка: теперь при приближении курсора к правому краю экрана все строки сдвигаются ровно настолько, чтобы курсор оставался в поле зрения. — GParted Live 1.8.1-3 Релиз построен на свежем снапшоте Debian Sid от 4 апреля и включает ядро Linux 6.19.10-1. Из заметного: исправлена ложная детекция ZFS на целых дисках через blkid, починены контрольные суммы файлов внутри live-системы: вместо sha256 теперь используется b3sum. — SQLite 3.53.0 Главное в этом релизе: исправление серьёзного бага повреждения базы в режиме WAL, который появился ещё в 3.51. — Linux 7.0 уже скоро — Вышел APT 3.2 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #дайджест_недели

⭐️ Little Snitch вышел для Linux Авторы macOS-файрвола Little Snitch выпустили версию для Linux. Инструмент показывает, какие процессы и куда подключаются, и позволяет блокировать соединения в один клик. Перехват трафика реализован через eBPF на уровне ядра. Основной код написан на Rust, интерфейс сделан как веб-приложение. Little Snitch для Linux не является инструментом безопасности в полном смысле. eBPF имеет ограничения, и обойти файрвол технически возможно. Основной фокус это приватность: показать, что происходит, и заблокировать соединения легитимного ПО, которое не пытается активно уклоняться. ➡️ Источник | Инструмент 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека devops'a #арсенал_инженера

🤔 Разрабатываете ИИ-агентов, но всё ещё не уверены в их стабильности и прогнозируемости? Мы поговорили с десятками разработчиков ИИ-агентов и сделали отдельный курс по AgentOps. 🧠 На нём вы узнаете: – как оптимизировать траты на токены; – как на практике оценить качество работы агента; – как «докручивать» RAG-системы без потери качества; – как обеспечить устойчивость агента к сбоям внешних сервисов без падения всей системы и про многое-многое другое. 📅 Старт: 19 мая. 👥 Спикеры — практики с опытом в AI и Data Science в крупных IT-компаниях, таких как Яндекс, Huawei, МТС и др. Длительность: 6-12 недель в зависимости от тарифа. 🔗 Программа курса и другие подробности