5169
Это проект Слёрма: коммьюнити для начинающих DevOps-инженеров, как стартовать в Девопс, вебы от ТОП экспертов, новости, общение и поддержка Бесплатный курс по DevOps: https://to.slurm.io/2pKSCw Присоединиться к чату канала: https://t.me/+8C5lo1K0Jn80MDIy
Привет! На связи Аниса
#карьера@devopsuprade
Сегодня без лишних предисловий иду к вам с интересной темой: обсуждение денег на интервью.
Наслышана о разных методиках обсуждения финансов – кто-то до последнего не называет точных цифр своих з/п ожиданий, а кто-то, наоборот, с первого звонка определяет строгий минимум, ниже которого общаться не готов.
🌟 Я тоже периодически прохожу интервью. И вот мои рекомендациями, проверенные временем и офферами.
А вы забирайте, что вам ближе⬇️
⏩Стараемся не использовать не целые значения, например: 190, 210, 155 и тд. Мозг человека часто не воспринимает эти маленькие хвостики (вспоминаем правило акций за 599 и тд). Да и к чему мелочиться, если можно округлить!)
⏩На вопрос: «Какие ваши з/п ожидания?» всегда отвечаем уверенно. Можно даже заранее прорепетировать – произносить голосом комфортные для себя цифры, чтобы привыкнуть. Любые фразы, выдающие сомнения в своих же з/п ожиданиях, создают впечатление, что мы не верим в то, сколько стоим. А значит нам можно столько и не платить. Надо воспитывать рынок!)
⏩Всегда оставляем поле для обсуждения. Я против строгих рамок, так как они могут сыграть со мной, как с кандидатом, злую шутку.
Можно поступить так: поделиться ожиданиями в формате «минимум N, комфорт Y» на 20-30% выше своих реальных, добавив: «готов(а) к обсуждению». Это будет win-win исход.
Сегодня праздничный вторник, так что задача будет необычная
#задача@devopsupgrade
Какой из перечисленных принципов улучшения работы с DevOps практиками НЕ входит в «Три пути» Из книги «Проект феникс»
Если не читали — не проблема. Посмотрим кто как чувствует 😎
Коллеги, приветствую!
На этой неделе я был в командировке, в нашем другом офисе.
💬 Хочется поразмышлять на тему: бывают ли командировки, которые не напрягают, а вообще вполне приятные? Я, наверное, не тот человек, кто хотел бы в своей деятельности постоянно ездить в командировки, но в некоторых случаях это может нравится.
Например, когда они не слишком частые и ощущаются как приятная смена обстановки. Похоже на походы в офис, но еще лучше. Очень рад что получается организовывать такие встречи, как большие встречи команды. Удобно познакомиться с новыми сотрудниками лично или пообщаться с теми, кого давно не видел. Часть вопросов удается решить достаточно быстро.
Но не все на самом деле любят такие поездки, и бывает комфортнее оставаться дома даже без особых причин. Я считаю, что, однозначно, никого нельзя заставлять в таком участвовать. Но, конечно, всем вместе веселее.
А как вы относитесь к командировкам или очным встречам команды?
Привет! На связи Аниса
#карьера@devopsuprade
Недавно мы с вами обсуждали сопроводы к открытым вакансиям.
А как насчёт скрытых вакансий? Рассказываю 🤓
Скрытый рынок труда — это процесс закрытия вакансии без публикации на сайтах. Такие вакансии закрываются за счёт личных контактов (пост про нетворк) и работы с внутренней базой кандидатов — то есть с прошлыми соискателями.
Как кандидатам с этим работать? Ответ: смело самим писать рекрутерам!
(все персонажи и события вымышлены, любые совпадения случайны 🍿)
6 правил написания классного письма для поиска работы:
1. Кто вы, как нашли рекрутера, почему ему написали.
Маша, привет!
Я Аниса, Старший рекрутер в Ромашкино.
Увидела твой пост в линке про неудачные собесы с кандидатами. Хочу стать обратным примером, а именно: самым быстрым и качественным закрытием вакансии — и вот пишу тебе)
Смогу выстроить HR-процессы с нуля — начиная от пребординга и заканчивая ведением HR-аналитики. Плюс дружу с публичностью и развитием HR-бренда.
Из достижений:
- внедрила метрику X в компании N, которая позволила управлять временем ожидания обратной связи от нанимающего и сократить цикл найма на Y
- организовала коммьюнити в компании M внутри рекрутмента для обмена опытом с регулярными митапами по темам развития hard + soft скиллов
Коллеги и любители докладов, привет!
Расскажу, чем занимаюсь ➡️ на этой неделе у нас внутренние доклады от DevOps, лучшие и самые интересные из которых потом попадут на наш открытый митап, который, я надеюсь, будет в обозримом будущем.
Я очень рад, что коллеги рассказывают действительно интересные вещи. Отдельно хочется поделиться тем, как на самом деле бывает важно всем собраться и вспомнить, кто как выглядит. Обязательно находятся небольшие вопросы, которые будут решены в рамках этих встреч 🔥
Делитесь вашими новостями, что на повестке этой недели?
Кто такой DevOps в 2025? Живой разговор с теми, кто каждый день решает это на практике
Коллеги, кажется, настало время разобраться, куда катится мир DevOps. А разбираться будем с теми, кто знает про него не по учебникам.
11 ноября в 18:00 мск приглашаю вас на разговор, который точно не будет скучным. Если вы, как и я, чувствуете, что границы профессии стали слишком размытыми — этот вебинар для нас с вами.
Кто со мной на сцене:
➡️ Всеволод Севостьянов — тот самый, что вел «DevOps про деньги». Энергичный, с живыми шутками «для своих» и без пафоса. Если вы устали от занудных вебинаров — он ваш человек.
➡️ Мария Калашникова — лидер кураторов, тьютор и фасилитатор в Слёрме. Говорят, задаёт вопросы, после которых хочется пересмотреть карьеру. Проверим?
Что будем обсуждать:
📌 Почему в 2025 году DevOps остаётся профессией-загадкой, где каждый работодатель видит что-то своё
📌 Как читать между строк в вакансиях и отделять реальные требования от «хотелок»
📌 Чем на самом деле отличается путь от Junior до Lead — не в днях, а в ответственности и влиянии
📌 Как перестать метаться между сотней технологий и выстроить осмысленный путь роста
⚡️ Присоединяйтесь — вместе разберёмся, куда движется профессия и где в ней наше место
P.S. Особенно рекомендую тем, кто чувствует, что застрял в развитии или не понимает, какие навыки прокачивать дальше. Лично сам жду этот разговор — давно назрело!Читать полностью…
🔔 Это последнее напоминание 🔔
Записаться на DevOps Upgrade можно еще три часа. Следующая возможность появится только в 2026 году
Запрыгнуть в последний вагон — по ссылке
⚡️⚡️⚡️⚡️ Последний день чтобы стартовать в DevOps в этом году!
Коллеги, сегодня — последний день, когда можно присоединиться к DevOps Upgrade в 2025 году
Все, кто запишется сегодня, успеют:
⏩ Начать обучение до новогодних праздников
⏩ Закрыть базовые модули к началу года
⏩ Войти в 2026 с новыми навыками и планом развития
Это ваш последний шанс в этом году сделать осознанный шаг в карьере DevOps-инженера
➡️ Успейте присоединиться до конца дня — по ссылке ⬅️
Привет! На связи Аниса
Октябрь...🍂 Наиболее активный месяц, когда рынок труда достигает пика по открытым вакансиям.
И вот мы готовы ворваться на всеми известный красный сайт с вакансиями, но... Нас таких много! А это значит, что нужно найти дополнительный путь – максимально целевой, быстрый и действенный.
Нетворк! заиграли фанфары где-то на фоне
Меня, как интроверта, хоть и с повышенными коммуникативными навыками, это слово вводит в некий ступор.
Согласитесь, сразу в голове: «И как дальше? Мне прям идти и прям писать кому-то, с кем не общался 2 года? Они точно подумают, что я только из-за работы написал». Было, понимаю. Поэтому, вот:
3 ненапряжных способа развития сети контактов — с бережным отношением к своей социальной батарейке.
⏩ Периодически «показываемся» нашим новым контактам (рекрутеры, бывшие коллеги, знакомые). Всё как в жизни – лайк/ответ на пост в соцсетях, и вы уже более заметны = узнаваемы.
⏩ Развиртуализируемся. Переводим онлайн-общение в оффлайн. Совместный обед в 1.5 часа не утомит, а личный контакт всегда укрепляет социальную связь лучше переписок.
⏩ Писать бывшим коллегам по вопросу работы – нормально. Любой формат: от «Вот и я пишу тебе спустя 2 года с вопросом о работе 😁» до юморного «Привет, спишь?» комфортен, если это ваш стиль. Я сама по долгу профессии часто бываю на той стороне, кому пишут. Никаких грешных мыслей об адресантах не возникает, честно! А если кто и подумает что-то о вас – пусть. Это говорит лишь о них. Зато вы действуете, пока другие осуждают.
И важно: пусть всё это будет в гармонии с вашими ощущениями.
А если захотите попробовать себя в реальном интервью с рекрутером (прям реальном, без поблажек) и понять цель вопросов в стиле «расскажите про свой факап» и ожидания от него – я тут ✋
Нас уже 5000! 💥💥💥
Коллеги, канал вчера переступил отметку 5000 подписчиков — это супер круто!
Хочу сказать спасибо каждому из вас за:
- Ваши вопросы в комментариях
- Активность и честную обратную связь
- Совместное обсуждение сложных тем
- Поддержку друг друга
Для меня этот канал — не просто цифры, а настоящее комьюнити единомышленников. Особенно кайфово видеть, как вы помогаете друг другу в комментариях и делитесь опытом
Дальше — больше!🥂
⭐️ Стартуем через 15 минут! ⭐️
Подключайтесь
Почему ваши процессы в 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
* 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
Помогите понять реальные задачи DevOps. Yandex Cloud ищет инженеров для исследования
Про задачи DevOps Middle мы с вами говорим уже больше полугода — и на честных вакансиях разбирали, и на девопс про деньги
Сейчас мы с командой Yandex Cloud проводим исследование рабочих задач DevOps-инженеров уровня Middle — интересно узнать, насколько результаты этого исследования будут близки к тому, что получилось в Слёрме
➡️ Приглашаю вас поучаствовать — ваш опыт поможет лучше понять потребности инженеров.
Как проходит исследование:
🔴 Онлайн-встреча на 30 минут
🔴 Ответы на вопросы о ваших рабочих задачах
🔴 Все данные анонимизируются
Требования к участникам:
✅ Опыт в IT от 2 лет
✅ Опыт в роли DevOps-инженера от 1 года
✅ Работа с Yandex Cloud от 6 месяцев
✅ Использование Yandex Cloud не реже 1 раза в месяц
В благодарность за участие вы получите грант 3000₽ на инфраструктуру в Yandex Cloud (отличная возможность начать наконец выполнять мои задачки 😅)
Если вы подходите под требования и хотите принять участие в исследовании — напишите в тг Полине
Буду рад вашему участию!
Новый поток — новые лица: смотрите, как начинается путь в DevOps
На прошлой неделе запустили новый поток DevOps Upgrade! Кайфуем от активности в общем чате — участники знакомятся, делятся опытом, целями и ожиданиями от курса
➡️ В этом потоке собрались системные администраторы, разработчики и инженеры из разных городов. Это еще раз доказывает, что в DevOps приходят совершенно разные люди, которые хотят развивать свои навыки
Каждый старт — это особенное событие. Уникальное коммьюнити, которое собирается только раз в несколько месяцев 🔥
Начало положено — впереди 9 месяцев интенсивного роста. До конца недели вы еще можете присоединиться к потоку. Подробности — на сайте
DevSecOps — это не про моду. Это про то, как перестать бояться релизов
На эфирах и вебах неоднократно звучал вопрос — DevSecOps это просто очередной модный термин или действительно что-то важное?
Прежде чем ответить на вопрос, предлагаю вспомнить эти ужасные моменты, когда безопасность в последний момент рубит ваш выстраданный релиз
➡️ Этого стресса можно избежать, если встроить безопасность в пайплайн с самого начала
Я давно перестал относиться к DevSecOps как к модному слову. Для меня это вопрос спокойного сна перед релизами. Именно поэтому рекомендую интенсив «DevSecOps Bootcamp», где одним из спикеров будет любимый вами Андрей Сухоруков
Если вы:
⭐️ Используете инструменты безопасности, но не знаете, что делать с результатами
⭐️ Сканируете код, но пропускаете образы, зависимости и конфиги
⭐️ Чувствуете, что безопасность скорее мешает, чем помогает
⭐️ Понимаете, что вам есть что защищать
Приходите на интенсив «DevSecOps Bootcamp» 11 октября. Вы научитесь снижать количество инцидентов до 70% и ускорять релизы до 20%. Проверено на практике
➡️ Подробности — на сайте
11 ноября разбираем вакансии: что от нас хотят работодатели в 2025
Коллеги, продолжаем начатый ранее разговор о том, как меняется наша профессия. Напоминаю, что 11 ноября в 18:00 МСК жду вас на открытом вебинаре, где мы с экспертами будем искать ответы вместе
Мы уже не раз поднимали тему вакансий в эфирах — и каждый раз вижу, насколько это живой и болезненный вопрос. Поэтому на предстоящем вебинаре мы тоже решили сделать акцент на разборе реальных вакансий — вместе с Всеволодом Севостьяновым и Марией Калашниковой
‼️ И здесь мне снова нужна ваша помощь.
Присылайте в комментарии ссылки или скрины вакансий, которые вызывают у вас вопросы. Возьмём самые показательные случаи и научимся читать между строк: где в описании скрываются реальные требования, а где — фантазии HR.
Для меня это не просто вебинар. Это возможность вместе разобраться в том, что действительно происходит на рынке
➡️ Присоединяйтесь к разговору — будет практично и без воды
Коллеги приветствую!
Чем занимаетесь в выходные?
Пока ждем новый поток — время подружиться с Linux
Коллеги, следующий DevOps Upgrade стартует только в марте, и у нас есть отличная возможность подтянуть то, на что вечно не хватает времени — фундаментальные знания Linux.
Сам постоянно вижу, как уверенное владение линуксом отличает сильных специалистов. Когда понимаешь не просто команды, а как работает система — совсем по-другому подходишь к задачам
У Слёрма есть классный курс, который ведет Кирилл Казарин (наш коллега, DevOps/SRE в RingCentral) — там как раз тот редкий случай, когда теория сразу превращается в практические навыки. 57 часов работы со стендами — это серьезно
⚡️ Что меня привлекает в таком подходе:
— Разбирают не только основы, но и тонкости безопасности
— Учат читать метрики и не теряться в инцидентах
— Показывают работу с серверами без GUI
⏩ Новый поток стартует 17 ноября. Если вы сейчас в раздумьях, как провести время с пользой — возможно, это ваш шанс прокачать базу, которая пригодится в любом случае
Подробности — на сайте
Коллеги, несу вам интересное предложение — DevOpsConf 2026 ищет спикеров ⭐️
Если у вас есть подходящие истории, кейсы/решения по DevOps, SRE или инженерным практикам — самое время рассказать о них широкой аудитории. Я планирую подать заявку в ближайшее время.
Ключевые темы конференции:
➡️ Эксплуатация LLM
➡️ AI-Driven Engineering: практики, риски и трансформация разработки
➡️ Как сократить косты на инфраструктуру?
➡️ Цифровые иммунные системы и инженерия надёжности (это SRE и новый термин оттуда)
➡️ Про разработку для системных инженеров
➡️ Требования регуляторов на простом русском
➡️ Базовые практики работы и про то, почему они по-прежнему важны
Для участия подойдут доклады, которые:
🌟основаны на личном опыте;
🌟демонстрируют результаты применения Open Source решений;
🌟рассказывает о проектах в стадии промышленной эксплуатации;
🌟содержит полезную информацию для аудитории.
Вы либо ненавидите YAML, либо еще не написали в нем достаточно много
Коллеги, признаюсь честно: каждый раз, когда я вижу новый YAML-файл, во мне просыпается тихая ярость. И знаю — я не один такой.
Вот что сводит с ума лично меня:
🌟 Два пробела вместо таба. Один неверный отступ — и прощай, пайплайн
🌟 Забыл дефис в списке? Получай немую ошибку парсинга где-то в 15-й строке
🌟 Неявное приведение типов: "yes" → true, "123" → number, "1.0" → float
🌟 Переносы строк в multiline-строках (|, >, |-, >-) — это отдельный вид боли
🌟 Отсутствие встроенной валидации схемы — ошибки всплывают только при запуске
Главная проблема YAML: кажется простым, но подводных камней хватит на всех. «О, это же просто ключи и значения!» — говорил я себе в начале. А через месяц понял, что трачу непропорционально много времени на отладку конфигов
При этом мы все зависим от этого формата:
➡️Kubernetes manifests
➡️GitLab CI/CD
➡️Ansible playbooks
➡️Docker Compose
➡️Helm charts
➡️GitHub Actions
YAML — это тот инструмент, который постоянно подводит в мелочах, но без которого никуда в современном DevOps.
Что реально помогает:
1️⃣yamllint — валидация синтаксиса до запуска
2️⃣VS Code/YAML-extension — подсветка и валидация в реальном времени
3️⃣Schema validation — например, с помощью kubeval для Kubernetes
4️⃣Статический анализ в pre-commit — отлавливаем ошибки до коммита
5️⃣Генераторы конфигов — когда YAML становится слишком сложным
А вы как относитесь к YAML? Поделитесь в комментариях — какая ваша самая болезненная история с этим «простым» форматом? Может, кто-то нашёл идеальное решение?
После вебинара по RAG: куда двигаться в AI для DevOps?
Коллеги, после недавнего вебинара по RAG появилось чёткое понимание: AI в DevOps — это уже не эксперименты, а рабочие инструменты. И теперь хочется двигаться дальше — к системному внедрению
Вот что действительно работает в 2025:
🌟 GitHub Copilot — мощный помощник для ускорения написания конфигов, который предлагает релевантные шаблоны и код
🌟 n8n + локальные LLM — архитектура для автоматизации workflow с минимальными рисками утечки данных
🌟 Ollama + Llama 3 — полный контроль над моделями для внутренних задач
🌟 AI в мониторинге — прогнозирование аномалий и проактивное выявление потенциальных проблем
📌 Главный инсайт:
RAG оказался не просто поиском по документам, а способом создать ассистента, который знает вашу инфраструктуру изнутри
Теперь планирую углубиться в тему — возможно, через курс по AI в DevOps, который стартует 20 октября. Если кто-то тоже загорелся темой после вебинара — пишите в комментариях, какие аспекты AI вам наиболее интересны ⬇️
⏰ 8 часов до закрытия DevOps Upgrade!
В 23:59 продажи закрываются. Занять место на курсе — по ссылке
Коллеги приветствую. Сегодня участвую в интересной активности, потом конечно подробнее с удовольствием расскажу
Читать полностью…
RAG в DevOps: смотрите запись вебинара и приходите на курс по AI
Коллеги, хочу поделиться с вами записью вебинара по RAG, который мы провели в среду
После вебинара я еще раз убедился: AI — это не будущее, а настоящее DevOps. В магистратуре тоже много говорят про LLM, слушаю с большим интересом. И если вы, как и я, хотите не просто следить за трендами, а реально внедрять AI в свою работу — очень рекомендую обратить внимание на курс Слёрма «AI в DevOps», который стартует 20 октября (возможно, я тоже пойду)
Лично мне импонирует практический подход — здесь не будет сухой теории, только реальные инструменты и кейсы, которые можно сразу применять в работе. Я сам планирую углубиться в тему, потому что вижу, как это может упростить рутину и ускорить процессы.
⏩ Посмотреть запись вебинара:
YouTube
VK Видео
Rutube
➡️ Узнать о курсе «AI в DevOps» — по ссылке
Docker: норм или стрем? Разбираемся с местом Docker в современном DevOps-стеке
В конце 2020 года громом грянула новость: Kubernetes объявляет docker-shim устаревшим. Пресса подхватила, заголовки кричали: «Kubernetes бросает Docker!». Это породило массу недопонимания
На деле же Kubernetes никогда не запускал ваши контейнеры напрямую через Docker. Для этого всегда использовался низкоуровневый containerd (или CRI-O), который является частью самого Docker. Docker выступал в роли «менеджера» поверх containerd
Проблема была в том, что Docker не реализовывал напрямую CRI — стандартный интерфейс Kubernetes для работы с контейнерами. Для общения с Docker Kubernetes использовал специальный адаптер, называемый dockershim
➡️ Решение Kubernetes: Убрать этот адаптер и говорить с containerd напрямую через CRI. Это упрощало архитектуру и делало её более стандартной
В итоге с точки зрения разработчика и DevOps-инженера, создающего образы, — ничего не поменялось. Но зачем тогда альтернативы? Podman, Buildah, Kaniko...
Docker — это монолит. Он включает в себя всё:
🌟 Демон (dockerd)
🌟 Сборку образов (docker build)
🌟 Управление контейнерами (docker run)
🌟 Реестр (docker push/pull)
🌟 Оркестрацию (docker-compose, Docker Swarm)
Современная философия Unix — это инструменты, делающие одну вещь, но делающие её хорошо
Вот кто и зачем пришёл на эту сцену:
1️⃣ Podman — «Беспалубный» Docker
Ключевое отличие: не требует демона. Запускает контейнеры от имени пользователя (rootless). Это серьезный плюс для безопасности
Совместимость: CLI почти один в один с Docker. alias docker=podman — и многие даже не заметят разницы
Зачем? Для безопасности, более простой интеграции с systemd и идеологии «без демона»
2️⃣ Buildah — Инструмент для сборки OCI-образов
Ключевое отличие: позволяет собирать образы без Dockerfile и без демона. Даёт тонкий контроль над каждым слоем
Зачем? Для создания минималистичных образов (сборка из scratch) и для CI/CD, где не хочется запускать целый Docker Daemon
3️⃣ Kaniko — Сборка образов в Kubernetes. Хоть и потеряла поддержку, можно использовать форки
Ключевое отличие: Собирает образы контейнеров внутри контейнера или Pod в Kubernetes. Не требует привилегированного доступа (Docker Daemon-less)
Зачем? Идеально для безопасных CI/CD пайплайнов, работающих прямо в Kubernetes. Больше не нужно маунтить /var/run/docker.sock в раннере, что является огромной дырой в безопасности
4️⃣ Nerdctl / containerd — Низкоуровневый контроль
containerd — это и есть та самая среда выполнения, которая теперь используется в Kubernetes по умолчанию. nerdctl — это CLI для работы с ним
Зачем? Для отладки и управления контейнерами прямо на нодах Kubernetes на низком уровне
⚡️ Docker для разработки — бесспорный король
Docker Desktop, простой Dockerfile и docker-compose up — это по-прежнему самый быстрый и удобный способ поднять локальное окружение. Менять это на Podman ради идеологии — часто неоправданная трата времени
Docker в продакшене — уступает место специализированным инструментам
На нодах Kubernetes у вас уже работает containerd. Вам не нужен полноценный Docker.
Для CI/CD использование Docker-in-Docker (dind) или маунта docker.sock считается антипаттерном с точки зрения безопасности. Здесь побеждает Kaniko или Buildah
Для управления контейнерами на серверах (вне K8s) Podman — отличная и более безопасная альтернатива
⏩ Ваши навыки работы с Docker не обесценились
Концепции, которые вы освоили с Docker: образы, слои, volumes, сети, Dockerfile — универсальны. Они переносятся на Podman, Buildah и Kaniko практически один в один. Вы учились не нажимать кнопки в docker, вы учились концепциям контейнеризации
📌 Docker не умер. Он повзрослел и занял свою чёткую нишу. Это как швейцарский нож: он невероятно удобен, когда вам нужно многое сделать быстро и без лишних инструментов (разработка). Но для серьёзной, высоконагруженной и безопасной работы на кухне продакшена шеф-повар будет использовать специализированные ножи: Kaniko для нарезки, Podman для чистки, а containerd — как мощную плиту
⚡️⚡️⚡️ RAG-бот своими руками: вебинар через час!
Коллеги, ровно в 19:00 встречаюсь в прямом эфире с Андреем Богомоловым на вебинаре по RAG — технологии, которая меняет работу с документацией и логами
Тема очень интересная, поэтому планирую засыпать Андрея разными каверзными вопросами. Присоединяйтесь и тоже спрашивайте!
⏩ Занять место на вебинаре — через бота
Как насчет вторничной задачи?
#задача@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
SRE Day: 11 октября. Берите на вооружение готовые стратегии надежности от ведущих инженеров
Коллеги, отмечу в своем календаре и вам рекомендую. 11 октября пройдет SRE Day — онлайн-мероприятие, полностью посвященное Site Reliability Engineering.
Для тех, кто хочет не просто слушать, а сразу применять в работе, здесь будет много практики. В программе — интерактивная игра по разбору инцидента, взгляд на карьеру от джуна и сеньора, и круглый стол с 5 экспертами 🔥
Особенно прикольно, что можно будет задать вопросы и сразу получить обратную связь — обычно это самый дефицитный ресурс
Если вы работаете с надежностью систем, мониторингом или дежурствами — рекомендую посмотреть. Как минимум, возьмете несколько рабочих методик для своих процессов
➡️ В общем, моя вам рекомендация — обязательно сходить на SRE Day. Подробнее про программу — по ссылке
⚡️⚡️⚡️ На этой неделе вышел заключительный эпизод «DevOps про деньги»
В нем уже не было интервью — только подведение итогов. Сева поговорил с девятью девопсами, и теперь может точно сказать:
➡️ сколько платят в DevOps
➡️ какие бывают плюшки
➡️ какие скиллы прокачивать, чтобы зарабатывать больше
Спойлер: общая вилка получилась от 190 до 800 тысяч рублей в месяц
Где посмотреть:
YouTube
VK Видео
Rutube
Смотрите, делайте выводы и приходите к нам в DevOps — тут есть не только чай и печеньки. А всем необходимым навыкам научим на DevOps Upgrade :)