Коллеги, приветствую! 👋

Рекомендую обратить внимание на новый интенсив Слёрма «n8n для DevOps: AI-ассистент за 3 недели».

⏩Коротко: 3 недели по 2–3 часа в день, 8 воркфлоу в репозитории. Поднимаете self-hosted n8n в Docker, строите пайплайны с триггерами и ветвлением, вызываете LLM со структурированным выводом, готовите воркфлоу к продакшену: секреты, ретраи, лимиты.

Для старта опыт с n8n не требуется.

🔴Полезно DevOps/SRE и сисадминам - автоматизировать алерты, проверки деплоя и рутину через API и вебхуки.
🔴Разработчикам и тимлидам - понять, где нужен агент, а где достаточно обычного IF.

⏩УЗНАТЬ ПОДРОБНОСТИ

Читать полностью…

Существуют ли волшебные флаги?

Коллеги всех приветствую👋

Возникла задача копировать S3-бакеты. С небольшим количеством файлов всё нормально — справляется без проблем. Но когда файлов сотни миллионов, начинается боль.

🔴Исходные данные: несколько терабайт, средний размер файла 10–15 КБ, общее количество файлов 300–400+ миллионов. Доступной оперативной памяти 256–512 ГБ. Ожидаемая скорость хотя бы 50–100 МБ/с. Реальная скорость 1–2 МБ/с.

В чём проблема:
--fast-list — это флаг rclone, который загружает весь список объектов в память сразу, а потом начинает передачу.

🔴С --fast-list: память = N_объектов × 1 КБ. Для 400 млн файлов: 400 000 000 × 1 КБ = ~381 ГБ. Вывод: не укладывается в доступную память → rclone падает по OOM.

🔴Без --fast-list: rclone обрабатывает по одной папке (префиксу) за раз. Память = N_файловвкрупнейшей_папке × 1 КБ. Если крупнейшая папка = 5 млн файлов: 5 000 000 × 1 КБ = ~4.8 ГБ. НО: каждый файл = отдельный LIST + PUT запрос к S3.

Почему всё равно медленно:
Проблема не в нагруженности API, а в том, что запросов физически много. rclone упирается не в пропускную способность сети, а в количество операций, которые нужно выполнить. Каждый файл требует LIST (получить метаданные), HEAD (проверить mtime/size), PUT (загрузить файл), проверку destination. Итого ~4 API-вызова на файл × 400 млн = 1.6 млрд запросов.

Даже если S3-провайдер не режет rate limits и API не перегружен, просто физическое время на выполнение 1.6 млрд запросов при 1000–3000 запросов/сек даёт 6–18 дней только на запросы.

Как подобрать параметры transfers и checkers:
transfers и checkers — самые важные параметры копирования. Чтобы подобрать их правильно, нужно посчитать потребление памяти.
⏩transfers — сколько файлов копируется параллельно. Каждый transfer занимает buffer_size памяти (по умолчанию 16 МБ). Формула: transfers × buffer_size. Например, 256 × 16 МБ = ~4 ГБ.
⏩checkers — сколько файлов проверяется параллельно (сравнивает метаданные source и destination). Каждый checker держит в памяти ~1000 файлов по 1 МБ на файл. Формула: checkers × 1000 × 1 МБ. Например, 256 × 1000 × 1 МБ = ~250 ГБ.

🔴Парадокс с настройками transfers и checkers:
НО: это всё имеет смысл только с --fast-list. Без --fast-list rclone работает так медленно, что память вообще не утилизируется. Можно выставить transfers 256, checkers 256, но реальная скорость будет 1–2 МБ/с из-за количества S3-запросов.

🔴Получается замкнутый круг: с --fast-list нужно 381 ГБ памяти для 400 млн файлов (столько памяти может не быть), без --fast-list память не нужна, но скорость падает в 50–100 раз, потому что каждый файл = отдельный запрос.

➡️Выводы: --fast-list обязателен для миллионов файлов, но требует огромной памяти (~1 КБ на объект). Для 400 млн файлов это уже ~381 ГБ, что превышает типичные лимиты памяти. Без --fast-list rclone упирается в количество операций S3 — каждый файл = отдельный запрос. Оптимизация параметров (transfers, checkers, buffer-size) не даёт эффекта — бутылочное горлышко в количестве запросов, а не в rclone. Единственное решение: разбивать на префиксы и запускать параллельно несколько процессов

➡️Итог: сотни миллионов мелких файлов = ад для любого S3-клиента. rclone не виноват — это ограничение архитектуры S3 API, где каждый файл требует отдельного запроса.

P.S. Если кто сталкивался с такой же проблемой — поделитесь опытом, как решали? Может, есть волшебный флаг или сервис, который это умеет? Или скажите какую еще проблему я не учел, которая будет проблемой при такой большой переливке?

Жду ваши ответы в комментариях👇

Читать полностью…

Вчера стартовал курс «Профессия DevOps-инженер»🔥

Из чего состоит курс:
Обучение проходит на базе приложения SlurmTalks - платформы, которую студенты пошагово собирают и разворачивают, применяя изученные инструменты на практике.

Курс включает 7 модулей:
🔴 Linux и Git - база: администрирование, ветвление, слияние, работа с командной строкой.
🔴Ansible - автоматизация конфигураций: плейбуки, роли, шифрование секретов.
🔴 Docker - контейнеризация: образы, Dockerfile, Docker Compose, Docker Swarm.
🔴Kubernetes - оркестрация: архитектура кластера, Helm, работа с хранилищами данных, безопасность.
🔴CI/CD - сборка пайплайнов в GitLab: тестирование, безопасность, деплой.
🔴Мониторинг и логирование - Prometheus, Grafana, ELK/EFK-стек, работа с инцидентами.
🔴Terraform - инфраструктура как код: провайдеры, модули, работа с AWS, Yandex Cloud и другими облаками.

⚡️Завершает обучение финальный проект - построение инфраструктуры для высоконагруженного приложения с настройкой CI/CD, мониторинга и безопасности.

Первые 5 дней обучения - бесплатно. Можно начать курс и оценить формат, прежде чем принимать решение ➡️ попробовать бесплатно

Читать полностью…

Коллеги, приветствую 👋

Сегодня подводим итоги розыгрыша фирменного мерча: разыгрывались 3 кепки с надписью Devops Bootcamp. Условие было простое — кепки достаются авторам трёх мемов, набравших больше всего реакций. Итак, рады объявить победителей:

1️⃣ @balahonovden
2️⃣ @monk_22
3️⃣ @v122474487139

В ближайшее время с вами свяжутся коллеги из Слёрма и расскажут, как получить свой приз 🙂

Читать полностью…

Коллеги, приветствую👋

Решил порадовать подписчиков своего канала и разыграть фирменный мерч: 3 кепки с надписью Devops Bootcamp

Условия розыгрыша:
➡️ скидываете в комментарии свой лучший мем про devops — про боль CI/CD, про пятничный деплой, который все обещали не делать. В общем, всё, что действительно откликается тем, кто в теме.

➡️ Победителей я определю путем подсчета реакций под мемами. Три мема с наибольшим количеством реакций забирают кепки.

➡️ Мемы принимаю до 10 сентября, итоги 18 сентября.

Давайте посмотрим, у кого в нашем комьюнити самое классное чувство юмора 🙂

Читать полностью…

Коллеги, приветствую! 👋

Слёрм разыгрывает бесплатную консультацию - 30 минут с Анисой Рогатовой, Senior ИТ-рекрутером в финтехе (опыт в OZON, Банке Точка, SkillFactory, спикер HR API и INDEX)

На консультации:
🔴Разберёте ваше резюме по косточкам — что убрать, что усилить
🔴Получите конкретные правки под вашу цель, а не общие советы
🔴Получите ответы на карьерные вопросы: от интервью до дальнейшего роста

Условия просты:
➡️Нужно подписаться на канал - @devopsupgrade
➡️Нажать кнопку «УЧАСТВОВАТЬ»

8 сентября бот случайным образом определит победителей

Читать полностью…

Коллеги, приветствую👋

Сегодня поговорим о том, как быстро перенести индекс Elasticsearch между кластерами без S3.
Недавно при переезде на новый кластер Elasticsearch понадобилось перенести только несколько индексов. Казалось бы, задача простая: перенести документы — и готово. Но индекс в Elasticsearch - это не только документы. Есть ещё mapping, settings, aliases и другие метаданные.

Самый правильный вариант - Snapshot/Restore
Для полноценного переноса Elasticsearch предоставляет механизм Snapshot/Restore. Snapshot можно хранить во внешнем repository, например в S3, а затем восстановить на другом кластере.

Документация:
Snapshot and Restore
S3 repository
Это хороший вариант, когда инфраструктура уже готова. Но что делать, если доступ к S3 нужно ещё получить, а индексы нужны буквально «вчера»?

Reindex — быстрый перенос документов
В Elasticsearch есть API _reindex, который позволяет скопировать документы из одного индекса в другой. Он также поддерживает перенос из удалённого Elasticsearch-кластера.

Простейший вариант:

POST /_reindex
{
  "source": {
    "index": "old-index"
  },
  "dest": {
    "index": "new-index"
  }
}

Документация: Reindex API
Но здесь есть важный нюанс.
_reindex переносит документы, но не переносит mapping и settings исходного индекса.

Поэтому целевой индекс нужно подготовить до запуска reindex.
Сначала mapping, потом документы
Получить mapping исходного индекса можно так:

GET /old-index/_mapping

Документация: Get mapping
После этого создаём индекс на новом кластере с нужным mapping:

PUT /new-index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "keyword"
      },
      "age": {
        "type": "integer"
      }
    }
  }
}

Это важно, потому что если создать пустой индекс без нужного mapping, Elasticsearch может применить dynamic mapping при первой индексации документов. В результате типы полей могут отличаться от исходного индекса.
При создании индекса можно сразу задать settings, mappings и aliases: Create index API.

И не забываем про aliases
Ещё одна частая ошибка — перенести документы и забыть про aliases.

Например, приложение работает с:

users

а на самом деле это alias, указывающий на:

users-2026-08

Получить aliases можно через:

GET /old-index/_alias

После переноса их необходимо создать на новом индексе.

Например:

PUT /new-index/_alias/users

Или использовать _aliases, если нужно одновременно удалить alias со старого индекса и добавить его на новый:

POST /_aliases
{
  "actions": [
    {
      "remove": {
        "index": "old-index",
        "alias": "users"
      }
    },
    {
      "add": {
        "index": "new-index",
        "alias": "users"
      }
    }
  ]
}

Это удобно при production-миграции: приложение продолжает обращаться к тому же alias, а мы просто переключаем его на новый индекс.

Документация: Aliases API
Можно автоматизировать
Если индексов много или не хочется писать всё вручную, можно использовать elasticsearch-dump.
Инструмент позволяет отдельно переносить data, mapping, alias, settings, analyzer и другие сущности.
elasticsearch-dump на GitHub

Например:

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=mapping

elasticdump \
  --input=http://old-es:9200/my_index \
  --output=http://new-es:9200/my_index \
  --type=data

Это уже можно завернуть в обычный Bash-скрипт и автоматизировать миграцию.

Читать полностью…

Коллеги, приветствую!👋

Вебинар «Модели ветвления и их влияние на CI/CD-пайплайн» уже прошёл⚡️

Вместе с Кириллом старшим инженером по практикам DevOps в Фланте, разобрали 4 базовые модели ветвления, обсудили их плюсы и минусы, а на практическом примере показали, как выбор модели определяет требования к CI/CD-пайплайну.

⏩Отдельное спасибо всем участникам — вопросов было много, обсуждение получилось живым и по делу

Если пропустили эфир или хотите пересмотреть — запись уже доступна:
➡️ ВК - https://vkvideo.ru/live-59405817_456240151
➡️ Ютуб - https://www.youtube.com/live/rAiE8mfRPEk?si=RbUYMj5GgT9p5k4I

Читать полностью…

Коллеги, приветствую👋

Сегодня настроение порассуждать о достаточно общих вещах. Насколько вы в жизни и работе позволяете себе делать что-то не по плану, а действовать по ситуации?

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

🔴Сижу сейчас, изучаю карту на ближайшие 1000 км и как код пишу план поездки в выходные, и поймал себя на мысли, что даже если я не хочу полностью продумывать план на выходные и мне нравится действовать по ситуации — всё равно составляю варианты развития событий, смотрю ключевые точки. Чтобы потом, в выходные, отвлекаясь от монитора и не смотря в телефон, просто ехать — и всё будет решаться по ситуации, даже не строя план, куда надо приехать. Пусть получится так, как получится, но меня это не удивит.

А может, на самом деле всё в любом случае запланировано❓

Читать полностью…

Коллеги, приветствую👋

Напоминаю, сегодня в 19:00 мск пройдет вебинар на тему: «Модели ветвления и их влияние на CI/CD-пайплайн»⚡️

Со мной в эфире:
🔴Кирилл Юденок — старший инженер по практикам DevOps, Флант

Расскажем:
⏩Что такое модель ветвления и почему это не «просто про git»
⏩Зачем нужны модели ветвления (и почему без них плохо)
⏩Историю одного проекта — от "push" в main до выстроенного процесса
⏩4 базовые модели: схемы, плюсы, минусы — без воды
⏩Как выбранная модель ветвления определяет требования к CI/CD-пайплайну — на примере из практики

Успейте зарегистрироваться до старта ➡️ в боте

Встретимся в эфире!

Читать полностью…

⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️

Коллеги, приветствую!👋

Приглашаю вас на вебинар на тему:«Модели ветвления и их влияние на CI/CD-пайплайн»⚡️

Со мной в эфире:
🔴Кирилл Юденок — старший инженер по практикам DevOps, Флант

Расскажем:
⏩Что такое модель ветвления и почему это не «просто про git»
⏩Зачем нужны модели ветвления (и почему без них плохо)
⏩Историю одного проекта — от "push" в main до выстроенного процесса
⏩4 базовые модели: схемы, плюсы, минусы — без воды
⏩Как выбранная модель ветвления определяет требования к CI/CD-пайплайну — на примере из практики

❗️В эфире каждый участник сможет задать интересующий его вопрос по теме и получить ответ прямо от экспертов

Запись на вебинар ➡️ в боте

Читать полностью…

Коллеги, приветствую!👋

Рад сообщить: стартует грант на новый поток курса «Профессия DevOps-инженер»

Этот курс — для тех, кто уже работает с Linux, Bash и базами данных, но чувствует, что дорос до нового уровня. Если цель — войти в DevOps или прокачаться до уверенного middle-специалиста, вам сюда.

❗️Вы соберете портфолио из 2 реальных проектов под руководством инженеров из крупных IT-компаний

Попытайте удачу — вдруг этот грант ваш⬇️

Три призовых места:
🔴1 место — 100% скидка
🔴2 место — 50% скидка
🔴3 место — 30% скидка

Условия участия:
1️⃣Подписаться на канал — Devops Bootcamp с Федосеевым
2️⃣Выполнить задание гранта по ссылке до 13 августа включительно
3️⃣Результаты гранта будут объявлены 14 августа в канале Devops Bootcamp с Федосеевым

⚡️Старт гранта — 5 августа⚡️

Не откладывайте — время до дедлайна ограничено!

Читать полностью…

Коллеги, приветствую! 👋

17 июля состоялся прямой эфир на тему: «Путь DevOps-инженера»

Обсудили на эфире:
➡️ хватает ли на рынке DevOps-кадров прямо сейчас
➡️ как импортозамещение (Astra Linux, РЕД ОС и прочий «отечественный стек») меняет требования к инженерам
➡️ почему специалиста, который реально шарит в этих системах, найти — задача со звёздочкой
➡️ разобрали несколько резюме участников и дали рекомендации, как их улучшить и сделать более сильными для поиска новых возможностей

Смотрите запись эфира полностью здесь ➡️ смотреть

А если хотите стать тем самым специалистом, которого сейчас днём с огнём ищут — приходите на курс Профессия DevOps-инженер

Разберём актуальный стек, практику и всё то, что реально спрашивают на собеседованиях и требуют в проде

Читать полностью…

Коллеги приветствую👋🏻

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

Речь вот об этом репозитории:
https://github.com/bykvaadm/interview-platform

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

При этом структура гибкая: вы можете легко адаптировать её под свои темы, добавлять свои разделы, убирать спорные моменты.

Вопросы для обсуждения:
➡️Стоит ли, на ваш взгляд, заморачиваться и писать собственный набор вопросов в таком формате?
➡️Было бы полезно, если бы этим пользовались и другие коллеги?

А может, даже соберёмся и сообща накидаем общую базу — так получится объективнее.

Буду рад обсудить ваше мнение в комментариях⬇️

Читать полностью…

Коллеги приветствую👋

Напомню, что у Слёрма есть бесплатный курс «Быстрый старт в DevOps»

Если вы давно хотели разобраться, что вообще входит в DevOps, но не понимали, с чего начать — это один из самых отличных вариантов для старта

Внутри курса:
🔹чем занимается DevOps-инженер;
🔹зачем нужны Docker, Kubernetes, CI/CD, Terraform и мониторинг;
🔹как все эти инструменты связаны между собой;
🔹в каком порядке их изучать, чтобы не утонуть в количестве технологий.

Самое приятное — он бесплатный, поэтому можно спокойно пройти и понять, насколько вам вообще интересно это направление

Читать полностью…

«У вас что-то с кубером»

Коллеги всем привет👋🏻
Расскажу сегодня случай про обращение с проблемой:

Как обычно, вечер. У внешней команды установка релиза и он падает с ошибкой. Коллеги приходят с ошибкой и просят решить проблему. Релиз на их тестовых кластерах установился без проблем.

⏩В логах — отказ при создании роли из pre-upgrade hook. Примерно такой:

Error: UPGRADE FAILED: pre-upgrade hooks failed: warning: Hook pre-upgrade templates/reload-config.yml failed:roles.rbac.authorization.k8s.io "release-hook" is forbidden:
user "release-user" is attempting to grant RBAC permissions not currently held:

На первый взгляд всё очевидно: пользователю не хватает прав. Нужно поправить RBAC, выдать доступ и продолжить релиз.

Но сначала стоит спросить: а права на что именно мы собираемся выдавать?

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

- apiGroups: ["apps"]
resources: ["deployments/rollout", "deployments/status"]

⏩У стандартного Deployment нет подресурса rollout. Есть команда kubectl rollout, но это не одноимённый подресурс Kubernetes. В чарт попала правдоподобная, но несуществующая сущность — deployments/rollout.

Вероятно этот фрагмент написал ИИ. А результат не проверили.
А почему тогда на другом кластере работало?

⏩Потому что тестировали под администратором. Вот как выглядит проверка полномочий под cluster-admin — даже для выдуманных подресурсов:

$ kubectl auth can-i get deployments.apps --subresource=rollout -n production
yes

$ kubectl auth can-i get deployments.apps --subresource=shit -n production
yes

⏩Это иллюстративный вывод для учётной записи с cluster-admin, а не проверка существования этих подресурсов. Команда can-i отвечает на вопрос «разрешено ли мне такое действие?», а не «существует ли такой API?». Поэтому администратор получает yes даже для выдуманных названий

⏩При этом запись в RBAC не подтверждает существование указанного API-ресурса. Администратор может сохранить роль с deployments/rollout, но новый подресурс от этого не появится. В конфигурации просто останется бессмысленное правило.

⏩В продовом кластере RBAC был настроен корректно: установщик имел ограниченные полномочия и не мог выдавать разрешения, которыми сам не обладал.

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

⏩Выдать больше прав — значит заставить установку пройти, не исправив дефект.

ИИ удобно использовать в DevOps: он быстро собирает YAML, шаблоны и скрипты. Но правдоподобная конфигурация ещё не означает рабочую.

Читать полностью…

Коллеги, приветствую👋

Курс «Профессия DevOps-инженер» уже стартовал🔥

В закрытом чате уже активно идёт знакомство: участники из разных компаний, городов и даже стран общаются, делятся опытом, обсуждают CI/CD, кластеры и автоматизацию.

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

Начать погружение в курс можно бесплатно)

➡️ ПРИСОЕДИНИТЬСЯ ПО ССЫЛКЕ

Читать полностью…

⚡️⚡️⚡️⚡️⚡️⚡️

Коллеги, приветствую👋

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

🔴Мои коллеги Senior ИТ-рекрутер Аниса Рогатова и практикующий DevOps-инженер Евгений Федосеев разбирали реальные вакансии с карьенрого агрегатора: что на самом деле стоит за каждым требованием и на что смотрят при отборе.

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

Смотреть полную запись вебинара ➡️ СМОТРЕТЬ

Читать полностью…

🎉 Розыгрыш завершен!

🏆 Победители:
1. @WolkStt

🔍 Проверить результаты

Читать полностью…

Коллеги, приветствую!👋

Прошёл вебинар «Модели ветвления и их влияние на CI/CD-пайплайн»⚡️

Кирилл из Фланта разобрал 4 модели ветвления, их плюсы/минусы и на примере показал их связь с CI/CD.

Запись:
➡️ ВК - https://vkvideo.ru/live-59405817_456240151

➡️ Ютуб - https://www.youtube.com/live/rAiE8mfRPEk?si=RbUYMj5GgT9p5k4I

Читать полностью…

⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️⚡️

Коллеги, приветствую!👋

Приглашаю вас на вебинар на тему: «Разбор реальных вакансий Junior DevOps»⚡️

Спикеры:
🔴Аниса Рогатова — Senior ИТ-рекрутер в финтехе (OZON, Банк Точка, SkillFactory)
🔴Евгений Федосеев — DevOps-инженер в «Пульс АЙТИМ», 5+ лет в DevOps, выпускник курса «Профессия DevOps-инженер»

Что будет на вебинаре:
⏩Живой разбор реальных вакансий Junior DevOps — что стоит за каждым требованием
⏩Что на самом деле означает «знание K8s» для джуна (сложное — простыми словами)
⏩Зарплатную вилку:
как конкретные навыки конвертируются в цифры оффера.
⏩Как презентовать себя на собеседовании, чтобы вас увидели как готового специалиста
⏩Как пройти техническое собеседование с тех лидом — рабочие советы и лайфхаки

🔴Когда: 1 сентября, 19:00 по мск
🔴Запись на вебинар ➡️ по этой ссылке

Читать полностью…

Коллеги, приветствую!👋

Делюсь фрагментом нашего эфира про путь DevOps-инженера. Говорили о наболевшем: почему компетенции, наработанные на российском рынке, постепенно теряют ликвидность за его пределами, и что с этим делать.

Разобрали, как выстраивать свою квалификацию с учётом этого фактора, и какой стек выбирать — если ориентируетесь на РФ, а если смотрите в сторону зарубежных проектов.

Думаю, будет полезно всем, кто задумывается о своём развитии в DevOps.

Смотрите запись эфира полностью здесь ➡️ смотреть

Читать полностью…

Коллеги, приветствую!👋

Проверка работ на грант по курсу «Профессия DevOps-инженер» завершена — результаты уже готовы!

Более 400 человек подали заявки на грант, и выбор победителей дался нам совсем не просто. В итоге определили троих:
⚡️Скидка 100%
Назипов Даниил daniil.nazipov2001@yandex.ru

⚡️Скидка 50%
Романенко Дмитрий mr.komorka@gmail.com

⚡️Скидка 30%
Корнилов Александр kornilov.it@gmail.com

Поздравляем! Скоро с вами свяжется менеджер и расскажет о дальнейших шагах.

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

Не пропустите, с вами свяжутся в ближайшее время🔥

Читать полностью…

Коллеги, мы в эфире!

Ждем вас по ссылкам:
➡️ВК - https://vkvideo.ru/live-59405817_456240151

➡️Ютуб - https://www.youtube.com/live/rAiE8mfRPEk?si=RbUYMj5GgT9p5k4I

Читать полностью…

Коллеги приветствую👋

Сегодня немного дополним более ранний пост про использование inputs в пайплайнах. Это такое, что точно можно использовать, если все почему-то так еще не делаете. Рассмотрим проект запуска пайплайна в ручную, с указанием разных типов переменных. В этом случае хорошо получается заменить их на inputs и сделать все удобнее.

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

  inputs:
    environment:
      description: "Target environment"
      options: ["test", "stage", "prod"]
      default: "test"

    landscape:
      description: "Target stand"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["my-prod01", "my-prod02"]
          default: "my-prod01"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["my-stage01", "my-stage02"]
          default: "my-stage01"
        - options: ["my-test01", "my-test02", "sandbox01"]
          default: "my-test01"

    playbook:
      description: "Playbook to run"
      rules:
        - if: $[[ inputs.environment ]] == "prod"
          options: ["deploy", "check", "rollback"]
          default: "check"
        - if: $[[ inputs.environment ]] == "stage"
          options: ["deploy", "check", "rollback", "smoke", "migrate"]
          default: "deploy"
        - options: ["first_playbook", "deploy", "check", "smoke", "migrate", "debug"]
          default: "first_playbook"

    mode:
      description: "Execution mode"
      options: ["apply", "check", "diff"]
      default: "apply"

    limit_hosts:
      description: "Optional ansible --limit"
      default: ""
      regex: '^$|^[A-Za-z0-9_.:,-]+$'

    forks:
      description: "Ansible forks"
      type: number
      default: 10

    gather_facts:
      description: "Enable gather_facts"
      type: boolean
      default: true

    verbose:
      description: "Enable -vvv"
      type: boolean
      default: false

    confirmation:
      description: "Type APPROVE for production apply"
      default: ""

Для числовых знаний поставим type: number и boolean когда просто выбираем true/false что-бы не писать это текстом - можно и ошибиться.

Получаем основные поля - выбираются из предложенных вариантов. Число в специальном поле и переключатели там где это уместно. Остается пару полей с строкой - в данном случае это для гибкости.

Читать полностью…

Коллеги, приветствую 👋

Знаете, есть расхожее мнение, что в DevOps все стартуют по накатанной: профильное образование, сразу первая работа в IT и быстрый рост до Kubernetes и продакшна.

➡️ Чаще путь выглядит куда более "живым": пара лет на двух работах одновременно, задачи, которые не поддаются с первого раза, постоянные поиски своего направления и учеба буквально на ходу.

Один из менторов курса «Профессия DevOps-инженер» — Евгений Федосеев — сам прошел через всё это: начинал инженером земельного кадастра, а сейчас держит в зоне ответственности несколько кластеров Kubernetes в фармтехе.

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

Читать полностью…

Рад сообщить: старт нового потока курса Профессия DevOps-инженер запланирован на 21 сентября⚡️

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

Программа охватывает:
🔴полный цикл CI/CD;
🔴облачную инфраструктуру (AWS, Yandex Cloud);
🔴контейнеризацию (Docker) и оркестрацию (Kubernetes);
🔴управление инфраструктурой как кодом (Terraform);
🔴мониторинг, логирование и обеспечение отказоустойчивости.

Курс построен вокруг сквозного практического проекта. Участники работают с реальным приложением SlurmTalks на всех этапах.

Ключевые преимущества:
⏩диплом о профессиональной переподготовке;
⏩практический опыт, сопоставимый с задачами в реальных проектах;
⏩83% практики

Длительность обучения — 9 месяцев.

До 1 сентября действуют выгодные цены на все тарифы:
🔥Комфорт — 155 000₽ (вместо 195 000₽)
🔥Карьера — 190 000₽ (вместо 230 000₽ 🔥VIP — 335 000₽ (вместо 375 000₽)

Подробнее о тарифах и программе ➡️ на сайте

Читать полностью…

Коллеги, приветствую 👋

Хочу порекомендовать вам интенсив — если вы давно поглядываете в сторону SRE, но не знаете, с какого конца подступиться, это отличная точка входа.

За 7 учебных дней разберетесь, как SRE измеряет надежность, работает с инцидентами и улучшает сервисы. Соберете SRE-пакет по знакомому сервису и личный roadmap на 3 месяца — без кода и настройки окружения

➡️ Формат лёгкий: Telegram-чат, ~ 3 часов в день, из инструментов нужен только браузер.

➡️ Автор — Максим Гусев, руководитель SRE в RWB, 11+ лет в отказоустойчивых системах.

Если вы:
➖разработчик и хотите понимать, что происходит с сервисом после деплоя
➖сисадмин, уставший тушить пожары
➖начинающий DevOps, для которого SRE пока тёмный лес
➖или просто присматриваетесь к профессии и хотите понять, ваше это или нет

Узнать подробности ➡️ на страницу интенсива

Читать полностью…

Коллеги, приветствую! 👋

Эфир на тему: "Путь-Devops инженера" состоялся — делюсь с вами записью, чтобы вы могли посмотреть его в удобное время.

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

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

Если вы пропустили эфир или хотите понять, как двигаться дальше в DevOps — обязательно смотрите запись⬆️

Читать полностью…

Коллеги, приветствую! 👋

Если вы хотите разобраться, как эффективно и безопасно применять ИИ в инженерной работе, Слёрм запускает бесплатную вечернюю школу «ИИ для инженеров: польза и риски»

За 6 онлайн-занятий вместе с практикующими инженерами разберёте:
🔴где LLM действительно помогают DevOps, SRE, Platform и Security-командам;
🔴 как применять ИИ при работе с логами, алертами, инцидентами, тикетами и документацией;
🔴почему модели галлюцинируют и как проверять их ответы перед использованием;
🔴какие есть риски с безопасностью, данными, compliance и юридическими аспектами;
🔴 как встроить ИИ в рабочие процессы так, чтобы он приносил пользу, а не создавал новые проблемы.

В программе также будут темы про:
🔴разбор метрик и шумных алертов с помощью ИИ;
🔴автофикс проблем в проде;
🔴ИИ-агентов для бизнес-задач;
🔴использование LLM в SOC и борьбу с alert fatigue;
🔴инженерное мышление в эпоху LLM.

⏩Старт — 21 июля
⏩Участие бесплатное, формат — онлайн

Если тема вам актуальна ➡️ регистрируйтесь, будет полезно.

Читать полностью…