Я сам пойду на этот вебинар по RAG. Вот почему вам тоже стоит присоединиться

Коллеги, я постоянно мониторю новые технологии, и RAG — одна из тех тем, которую стоит изучить каждому DevOps-инженеру прямо сейчас. Сам давно хотел разобраться в практическом применении, поэтому очень рад, что Слёрм позвал меня ведущим на очень крутой веб

➡️ 8 октября в 19:00 мск встречаемся на вебинаре «Что такое RAG и с чем его едят»

Спикер: Андрей Богомолов — co-founder и CTO GenAI LAB, эксперт с более чем 10-летним опытом в AI

Лично мне интересно посмотреть на реальные кейсы, особенно:

📌 Как собрать работающий RAG на базе телеграм-канала
📌 Автоматизацию через n8n — всегда полезно иметь в арсенале новые инструменты
📌 Что ломается в продакшене — самый ценный опыт, который обычно не найти в документации

Андрей и команда GenAI LAB реализовали 100+ AI-проектов и обучили 300+ специалистов — определенно есть чему поучиться. Я планирую спросить про аи все, что мы с вами стеснялись спросить — даже самые «глупые» вопросы (все же помнят, что глупых вопросов не бывает?)

Регистрируйтесь, разберемся в технологии вместе!

🔥 Занять место на вебинаре — через бота

⚡️⚡️⚡️ На этой неделе вышел заключительный эпизод «DevOps про деньги»

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

➡️ сколько платят в DevOps
➡️ какие бывают плюшки
➡️ какие скиллы прокачивать, чтобы зарабатывать больше

Спойлер: общая вилка получилась от 190 до 800 тысяч рублей в месяц

Где посмотреть:

YouTube
VK Видео
Rutube

Смотрите, делайте выводы и приходите к нам в DevOps — тут есть не только чай и печеньки. А всем необходимым навыкам научим на DevOps Upgrade :)

DevSecOps — это не про моду. Это про то, как перестать бояться релизов

На эфирах и вебах неоднократно звучал вопрос — DevSecOps это просто очередной модный термин или действительно что-то важное?

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

➡️ Этого стресса можно избежать, если встроить безопасность в пайплайн с самого начала

Я давно перестал относиться к DevSecOps как к модному слову. Для меня это вопрос спокойного сна перед релизами. Именно поэтому рекомендую интенсив «DevSecOps Bootcamp», где одним из спикеров будет любимый вами Андрей Сухоруков

Если вы:
⭐️ Используете инструменты безопасности, но не знаете, что делать с результатами
⭐️ Сканируете код, но пропускаете образы, зависимости и конфиги
⭐️ Чувствуете, что безопасность скорее мешает, чем помогает
⭐️ Понимаете, что вам есть что защищать

Приходите на интенсив «DevSecOps Bootcamp» 11 октября. Вы научитесь снижать количество инцидентов до 70% и ускорять релизы до 20%. Проверено на практике

➡️ Подробности — на сайте

Жду начало мотосезона 🔥

SRE Day: 11 октября. Берите на вооружение готовые стратегии надежности от ведущих инженеров

Коллеги, отмечу в своем календаре и вам рекомендую. 11 октября пройдет SRE Day — онлайн-мероприятие, полностью посвященное Site Reliability Engineering.

Для тех, кто хочет не просто слушать, а сразу применять в работе, здесь будет много практики. В программе — интерактивная игра по разбору инцидента, взгляд на карьеру от джуна и сеньора, и круглый стол с 5 экспертами 🔥

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

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

➡️ В общем, моя вам рекомендация — обязательно сходить на SRE Day. Подробнее про программу — по ссылке

Помогите понять реальные задачи DevOps. Yandex Cloud ищет инженеров для исследования

Про задачи DevOps Middle мы с вами говорим уже больше полугода — и на честных вакансиях разбирали, и на девопс про деньги

Сейчас мы с командой Yandex Cloud проводим исследование рабочих задач DevOps-инженеров уровня Middle — интересно узнать, насколько результаты этого исследования будут близки к тому, что получилось в Слёрме

➡️ Приглашаю вас поучаствовать — ваш опыт поможет лучше понять потребности инженеров.

Как проходит исследование:
🔴 Онлайн-встреча на 30 минут
🔴 Ответы на вопросы о ваших рабочих задачах
🔴 Все данные анонимизируются

Требования к участникам:
✅ Опыт в IT от 2 лет
✅ Опыт в роли DevOps-инженера от 1 года
✅ Работа с Yandex Cloud от 6 месяцев
✅ Использование Yandex Cloud не реже 1 раза в месяц

В благодарность за участие вы получите грант 3000₽ на инфраструктуру в Yandex Cloud (отличная возможность начать наконец выполнять мои задачки 😅)

Если вы подходите под требования и хотите принять участие в исследовании — напишите в тг Полине

Буду рад вашему участию!

Как насчет вторничной задачи?
#задача@devopsupgrade

Сегодня просто, затронем базу

Команда решила внедрить GitOps для управления инфраструктурой и деплоем. Какой сценарий наилучшим образом иллюстрирует принцип «Git — единственный источник истины»?

1️⃣ Разработчик делает хот-фикс напрямую в продакшен-кластере через kubectl edit, а затем коммитит изменения в Git

2️⃣ CI-пайплайн собирает образ, проставляет тег образа в GIT и сразу с помощью kubectl apply деплоит его в кластер

3️⃣ ArgoCD постоянно мониторит Git-репозиторий и автоматически синхронизирует состояние кластера с тем, что описано в манифестах в репозитории. Любые расшения будут перезаписаны из Git

4️⃣ CI-пайплайн собирает образ и сразу же с помощью kubectl apply разворачивает его в кластере, а затем пушит новый тег образа в Git

5️⃣ Инженеры используют helm upgrade --force для развертывания приложений, а чарты хранятся в Git

Почему ваши процессы в Linux внезапно умирают?

Коллеги, сегодня поговорим о проблеме, которая может незаметно гробить ваши приложения в продакшене. Речь о лимите одновременных процессов (nproc)

➡️ Что происходит:

По умолчанию во многих дистрибутивах лимит nproc установлен в 4096 процессов на пользователя. Для высоконагруженных приложений (особенно в Go, Java, Python с асинхронностью) этого может не хватить. Процессы начинают падать с ошибкой fork: retry: Resource temporarily unavailable, хотя память и CPU в норме

Почему это бесит:

⏩ Ошибка маскируется под другие проблемы
⏩ На тестовых стендах всё работает
⏩ В мониторинге нет явных аномалий
⏩ Расследование может занять часы

Проверка и решение:

# Текущий лимит
ulimit -u

# Постоянное решение в /etc/security/limits.conf
* soft nproc 65536
* hard nproc 65536

# Для systemd-сервисов добавляем в сервис-файл
[Service]
LimitNPROC=65536

‼️ Важно: После изменения limits.conf нужен перелогин. Для systemd-сервисов — перезапуск сервиса

В действительно нагруженных системах может недостаточно даже таких лимитов, поэтому вот пример подобного файла от действующего сервера:

*         hard    nproc           infinity
*         soft    nproc           infinity
root      hard    nproc           infinity
root      soft    nproc           infinity
*         hard    nofile          1048576
*         soft    nofile          1048576
root      hard    nofile          1048576
root      soft    nofile          1048576
*         hard    memlock         64
*         soft    memlock         64
root      hard    memlock         64
root      soft    memlock         64
*         hard    sigpending      infinity
*         soft    sigpending      infinity
root      hard    sigpending      infinity
root      soft    sigpending      infinity

Сталкивались с подобным? Делитесь в комментариях — какие лимиты выставляете, чтобы потом не ловить падения?

⚡️⚡️⚡️ RAG-бот своими руками: вебинар через час!

Коллеги, ровно в 19:00 встречаюсь в прямом эфире с Андреем Богомоловым на вебинаре по RAG — технологии, которая меняет работу с документацией и логами

Тема очень интересная, поэтому планирую засыпать Андрея разными каверзными вопросами. Присоединяйтесь и тоже спрашивайте!

⏩ Занять место на вебинаре — через бота

⭐️ Стартуем через 15 минут! ⭐️

Подключайтесь