Почему ваши процессы в 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 минут! ⭐️

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

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 в DevOps: смотрите запись вебинара и приходите на курс по AI

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

После вебинара я еще раз убедился: AI — это не будущее, а настоящее DevOps. В магистратуре тоже много говорят про LLM, слушаю с большим интересом. И если вы, как и я, хотите не просто следить за трендами, а реально внедрять AI в свою работу — очень рекомендую обратить внимание на курс Слёрма «AI в DevOps», который стартует 20 октября (‎возможно, я тоже пойду)

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

⏩ Посмотреть запись вебинара:
YouTube
VK Видео
Rutube

➡️ Узнать о курсе «AI в DevOps» — по ссылке

Привет! На связи Аниса

Октябрь...🍂 Наиболее активный месяц, когда рынок труда достигает пика по открытым вакансиям.

И вот мы готовы ворваться на всеми известный красный сайт с вакансиями, но... Нас таких много! А это значит, что нужно найти дополнительный путь – максимально целевой, быстрый и действенный.

Нетворк! заиграли фанфары где-то на фоне

Меня, как интроверта, хоть и с повышенными коммуникативными навыками, это слово вводит в некий ступор.

Согласитесь, сразу в голове: «И как дальше? Мне прям идти и прям писать кому-то, с кем не общался 2 года? Они точно подумают, что я только из-за работы написал». Было, понимаю. Поэтому, вот:

3 ненапряжных способа развития сети контактов — с бережным отношением к своей социальной батарейке.

⏩ Периодически «показываемся» нашим новым контактам (рекрутеры, бывшие коллеги, знакомые). Всё как в жизни – лайк/ответ на пост в соцсетях, и вы уже более заметны = узнаваемы.

⏩ Развиртуализируемся. Переводим онлайн-общение в оффлайн. Совместный обед в 1.5 часа не утомит, а личный контакт всегда укрепляет социальную связь лучше переписок.

⏩ Писать бывшим коллегам по вопросу работы – нормально. Любой формат: от «Вот и я пишу тебе спустя 2 года с вопросом о работе 😁» до юморного «Привет, спишь?» комфортен, если это ваш стиль. Я сама по долгу профессии часто бываю на той стороне, кому пишут. Никаких грешных мыслей об адресантах не возникает, честно! А если кто и подумает что-то о вас – пусть. Это говорит лишь о них. Зато вы действуете, пока другие осуждают.

И важно: пусть всё это будет в гармонии с вашими ощущениями.

А если захотите попробовать себя в реальном интервью с рекрутером (прям реальном, без поблажек) и понять цель вопросов в стиле «расскажите про свой факап» и ожидания от него – я тут ✋

⚡️⚡️⚡️⚡️ Последний день чтобы стартовать в DevOps в этом году!

Коллеги, сегодня — последний день, когда можно присоединиться к DevOps Upgrade в 2025 году

Все, кто запишется сегодня, успеют:
⏩ Начать обучение до новогодних праздников
⏩ Закрыть базовые модули к началу года
⏩ Войти в 2026 с новыми навыками и планом развития

Это ваш последний шанс в этом году сделать осознанный шаг в карьере DevOps-инженера

➡️ Успейте присоединиться до конца дня — по ссылке ⬅️

После вебинара по RAG: куда двигаться в AI для DevOps?

Коллеги, после недавнего вебинара по RAG появилось чёткое понимание: AI в DevOps — это уже не эксперименты, а рабочие инструменты. И теперь хочется двигаться дальше — к системному внедрению

Вот что действительно работает в 2025:

🌟 GitHub Copilot — мощный помощник для ускорения написания конфигов, который предлагает релевантные шаблоны и код

🌟 n8n + локальные LLM — архитектура для автоматизации workflow с минимальными рисками утечки данных

🌟 Ollama + Llama 3 — полный контроль над моделями для внутренних задач

🌟 AI в мониторинге — прогнозирование аномалий и проактивное выявление потенциальных проблем

📌 Главный инсайт:
RAG оказался не просто поиском по документам, а способом создать ассистента, который знает вашу инфраструктуру изнутри

Теперь планирую углубиться в тему — возможно, через курс по AI в DevOps, который стартует 20 октября. Если кто-то тоже загорелся темой после вебинара — пишите в комментариях, какие аспекты AI вам наиболее интересны ⬇️

⚡️ Мой провальный роман с AI-ассистентами: почему генерация картинок — это отдельный вид искусства

Коллеги, хочу поделиться своим опытом погружения в AI на прошлой неделе. Признаюсь честно: до этого использовал нейросети минимально, но решил разобраться основательно. И теперь понимаю, почему у многих горят жопы от работы с AI

Что получилось легко

➡️ Генерация длинных текстов — работает прилично, если проверять факты
➡️ Примеры коротких кусков кода — более-менее
➡️ Запросы по документации — тут проблем нет

Что не получилось вообще

Попробовал генерацию векторной графики. Хотел сделать логотип и рендер объекта. Буквы — пожалуйста. Но когда попросил нарисовать конкретную форму по SVG-шаблону... AI упорно генерировал абстракции, уверяя что это именно то, что я просил 🗿

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

Например, вот эту картинку я делал через DALL-E несколько часов (узнали игру? может, играл кто?). Если у вас есть опыт в генерации изображений — поделитесь лайфхаками! Очень хочу разобраться, хотя бы в формате «сделать что-то вечером после работы»

P.S. Я таки решил присоединиться к курсу по AI в DevOps. Там, конечно, не учат генерировать мемы, но учат внедрять AI в реальные процессы. Так что встретимся уже в понедельник (надеюсь, у меня ничего не изменится)‌‎🤘🏼

Привет! На связи Аниса 🚶‍♀️
#карьера@devopsuprade

Продолжаю тему поиска работы. Тут говорили о том, как расширять нетворк. Однако не менее важно — вовремя понять, куда идти не стоит. В условиях, когда хороших вакансий мало, легко пропустить тревожные звоночки. Но не нам!

Разберем примеры из красной и желтой зоны. Все совпадения случайны 😇

1️⃣ Красная зона: бежим, не оглядываемся

➡️ «Про деньги поговорим потом»
База! Часто значит, что ваши ожидания и бюджет компании не совпадают. Прозрачные компании либо сразу говорят вилку (редко, но бывает), либо четко отвечают, вписываетесь вы в нее или нет. Исключение – строгие NDA в узких нишах.

➡️ «Нам нужен человек, который продаст пользу своей роли бизнесу»
Кхм, точнее так: «Мы пока сами не понимаем, зачем вас нанимаем. Но надо». Частый симптом прошлого неудачного найма и лёгкого скепсиса ко всем новым кандидатам. Бесполезная трата времени и сил.

2️⃣ Желтая зона: сомнительно, но окэй. Принимаем решение по совокупности факторов и общему впечатлению

➡️ «У нас нет четких KPI, они гибкие и меняются»
Такое бывает в молодых и быстрорастущих компаниях, когда цели ставятся краткосрочно. Готовы ли вы к постоянной смене правил игры? Думаем.

➡️ «Личные вопросы без контекста»
Семейное положение, планы на детей – тонкая тема даже для светских бесед. Допустимо, только если рекрутер сразу поясняет зачем это спрашивает (например, для оформления визы при релокации, предоставляемой компанией). Без объяснений – это too much для интервью.

Безусловно, границы выбираем мы сами. Лучше всего «предупрежден — значит вооружен»

Чем бы вы дополнили эти пункты? Пишите в комментариях!

SRE 2025: как устроена надежность систем на самом деле?

Коллеги, команда DevCrowd запустила масштабное исследование про SRE и DevOps-практики. Ребята делают действительно полезную штуку: помогут понять, как на самом деле устроена работа SRE-команд

⭐️Кто за что отвечает в вашей компании?
⭐️Какие инструменты реально работают в продакшене?
⭐️ Где проходит граница между SRE и DevOps?

Лично мне интересно сравнить свой опыт с коллегами из других компаний. Исследование полностью анонимное, на заполнение уйдет ~10 минут.

Заполняя опрос, вы помогаете сделать роль SRE более понятной и заметной на рынке. Итоги будут в открытом доступе в ноябре — сможете сравнить свои практики с общими трендами.

➡️ Пройти опрос можно здесь