DevOps *

Device plugin умеет выделять только целочисленные ресурсы: одну карту, две карты — или одну MIG‑партицию, но не «полкарты» и не «30% памяти». В реальности же нужны доли памяти, учёт топологии, предсказуемые обновления и изоляция, а не пулы лейблов и кастомные шедулеры. Разобрал, почему индустрия устала от костылей, как это проявляется в настоящем AI‑кластере и что именно пытается исправить DRA. Читать, если хотите управлять ресурсами явно, а не тушить пожары по расписанию.

В последнее время я часто работал с разными ML-проектами в GitLab. В каждом был свой .gitlab-ci.yml, своя обвязка вокруг MLFlow, своя регистрация и валидация модели. Со временем я понял, что MLOps-пайплайн во всех проектах очень похож, а при работе с новыми копипаста размножается быстрее кроликов. Ну и тут уже хочешь не хочешь, но идея сделать общий шаблон напрашивается. Однако будем честны, обычный template для CI — это круто, но хочется чего-то гибкого, декларативного и красивого. Для достижения этих целей GitLab уже давно предлагает переходить на CI/CD компоненты. В результате я хотел видеть 10 строк YAML, которые будут выдавать полноценный пайплайн с валидацией данных, обучением, quality gates и регистрацией модели.

И спустя месяц я добился желаемого. В этой статье покажу, как устроен компонент, на какие грабли наступал по пути, и как подключить всё это в ваш проект.

Сам компонент.

Хабровчане, приветствую! Меня зовут Михаил Казанцев, я ведущий системный аналитик в мобильном приложении Вайлдберриз. Работал и писал требования как в стартапах с монолитами, так и в банковском секторе с сотнями сервисов в одном контуре, рассказать есть что.

Я хочу рассказать о своём восприятии основной идеи книги Мартина Клепмана — Высоконагруженные приложения через призму своего ультрамарафонского опыта тренировок и соревнований и практики проведения чайных церемоний. Книга технически сложная, поэтому

Kubernetes часто называют сложной системой, в которой легко запутаться. Control Plane, etcd, scheduler, worker nodes — когда сталкиваешься с этим в первый раз, кажется, что разобраться невозможно. Но на самом деле за громкими названиями скрываются простые и логичные компоненты.

Мы подготовили простую теоретическую подводку и ранбук по запуску своего кластера с нуля. Материал подойдёт всем, кто хоть немного знаком с контейнерами и хочет понять, что происходит после команды kubectl apply. Никакой магии — только архитектура, жизненные циклы, живые примеры и пара схем для наглядности.

В Kafka данные могут пропадать, даже если в конфигах стоит хранение 7 дней. В этом коротком кейсе — как я решил проблему потери данных, внедрив мониторинг «окна безопасности».

Проблема: Байты сильнее времени

Решение: Метрика «Data Safety Window»

Конфигурация — это лишь декларация о намерениях. Реальное окно жизни данных диктует нагрузка в моменте.

Чтобы не гадать по конфигам, я внедрил расчет фактического запаса времени в Grafana.

Привет! Меня зовут Амир Уразалин, я DevOps-инженер в KTS.

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

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

Привет, Хабр! Меня зовут Денис Коробков, я руковожу отделом DevOps по розничному направлению в ПСБ. В своей статье расскажу, как мы внедрили релизную платформу, чтобы выстроить и автоматизировать релизный процесс.

До недавнего времени он был практически полностью ручным. Разработчики согласовывали участие в релизе по почте, релиз-менеджеры вручную собирали общий список сервисов и индивидуально переносили каждую сборку между стендами. Потом в компании изменился подход к разработке: розничный блок, в том числе и микросервисная платформа, перешёл на Trunk Based Development (далее TBD). В связи с этим нам нужно было уменьшить ручные шаги и сократить время релизного цикла. 

Релизная платформа позволила нам уйти от ручной работы там, где это было возможно, и сэкономила довольно много времени. Расскажу, что она умеет, как устроена изнутри, и приведу цифры — где и на чём мы снизили затраты по часам. Надеюсь, будет интересно почитать DevOps-ам и вообще всем, кто имеет отношение к релизному циклу. Прошу под кат. 

В этой статье мыпопробуем провести небольшое расследование, посвященное тому, как найти и обезвредить «тихого убийцу». В частности, мы на конкретных примерах разберём утечки памяти, фрагментацию дисков, проблему 95-го перцентиля и «зловещую тишину» в логах. А также, рассмотрим инструменты, которые не дадут производительности умереть незаметно.

Docker Swarm предоставляет встроенный механизм управления секретами: пароли, ключи API и сертификаты передаются в контейнеры через зашифрованный канал и монтируются в /run/secrets/. Звучит безопасно — пока вы не осознаете, что любой пользователь с доступом к docker exec может прочитать эти секреты в любой момент жизни контейнера.

В этой статье я разберу, почему стандартные способы защиты не работают, и покажу решение на основе именованных каналов (FIFO), которое позволяет секрету быть прочитанным ровно один раз — при старте приложения.

341 вредоносный навык на 2857 проверенных — и это только то, что нашли. Навыки в OpenClaw — это не плагины и не контент. Это инструкции, по которым агент читает файлы, запускает команды и ходит в сеть. Одна неудачная установка из ClawHub — и вы отдали незнакомцу выполнение кода в привилегированной среде. Разбираемся, как устроена система навыков, как писать свои, где они хранятся, почему порядок приоритета важнее, чем кажется, — и что делать, чтобы удобство не обернулось инцидентом.

Во многих командах сегодня все выглядит «как положено»: Kubernetes, CI/CD, Terraform, DevOps-команда на месте.

Но по мере роста системы появляется другой эффект: разработка тормозит не из-за кода, а из-за инфраструктуры. Любое изменение проходит через одну точку — DevOps.

И дело не в том, что команда работает плохо. Просто через нее проходит все: задача уходит в очередь, возвращается на доработку и снова ждет. Бизнес давит на скорость, но инфраструктура не успевает.

Привет, Хабр! Меня зовут Павел Лавров, я owner нового продукта в экосистеме Orion soft — GitOps-платформы HyperDrive. И в этой статье я расскажу, почему проблема не в людях и не в инструментах — она в самой модели работы с инфраструктурой. Давайте разберемся, как возникает это узкое место и что меняется, если его убрать.

Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top. Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но вопрос оставался один и тот же:

Сервер тормозит. Что не так?

За эти годы у меня накопились инструкции, SSH-скрипты, обёртки над vmstat, iostat, ss, perf. Каждый раз, подключаясь к проблемному серверу, я тратил 20-40 минут на одни и те же действия вроде команды top

Это Tier 1 — базовый уровень. Но когда top показывает что всё вроде нормально, а приложение всё равно тормозит, начинается настоящая диагностика.

Онбординг — один из важных аспектов, требующих особого внимания при масштабировании компании. А теперь представьте, что у вас есть универсальный инструмент, который помогает закрывать целый класс задач команды разработки: настраивает локальное окружение проекта одной кнопкой,  унифицирует окружение для всех разработчиков на разных ОС, обеспечивает безопасность инфраструктуры, упрощает CI и многое другое.

Всё это — девконтейнеры! Да, мы начинаем программировать прямо в контейнере. И всё это бесплатно и без необходимости развёртывания новых сущностей в вашей организации. О такой кнопке «сделать хорошо» мы и поговорим в этой статье по мотивам моего доклада для DevOps Conf. 

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

Мы пройдем путь от бинарных логов AIX до journald, а в конце разберемся, как практически использовать journalctl с популярными инфраструктурными службами. 

Разбор межфайловой дедупликации на версионных данных: почему обычная упаковка упирается в потолок и что меняется на CPython, Go и Node.js.

ИИ не заменяет людей — люди просто больше работают. Так давайте хотя бы ночью пусть работает ИИ.

Как мы сделали Авто‑Кодера, выжимая максимум из нашей подписки на LLM!

Вы уверены, что ваш “случайный” пароль действительно случайный?

Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.

В статье я последовательно разбираю:

• почему классическая “энтропия пароля” часто вводит в заблуждение;

• как устроен Mersenne Twister и в чём его фундаментальная проблема;

• почему даже хороший seed (через os.urandom) не делает random безопасным;

• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.

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

Отдельно показываю, где проходит граница между «кажется надёжным» и «действительно криптостойким», и почему secrets — это не просто «рекомендованный модуль», а принципиально другой класс генерации.

LLM-агенты отлично решают алгоритмические задачи. Но что произойдет, если поместить их в реальную инфраструктуру – с CI/CD, branch protection и security-политиками?

Я провел эксперимент: дал агентам простую задачу – внести изменение в репозиторий и замерджить его в main, соблюдая все правила. При этом у них был доступ к тем же инструментам, что и у разработчика, включая GitHub CLI и админский токен.

Результат оказался немного неожиданным. Практически все модели успешно выполнили задачу, но ни одна так, как я ожидал.

В статье — не просто список инструментов, а как они сочетаются, какие подводные камни ждут при развёртывании, какие цифры можно ожидать по производительности и как обойти ограничения Llama 8B без облачных кредитов.

Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр.

Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной.

Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep, ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит.

Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.