DevOps *

Домашний облачный рабочий стол и гейминг в контейнере, с общим GPU. Готового решения не было — пришлось пройти четыре тупика и написать свой Wayland-композитор.

Пока вокруг AI все в основном обсуждают модели, бенчмарки и очередных «автономных агентов», параллельно растёт более прикладная часть экосистемы — готовые skills под конкретные задачи. И Hermes Skill Hub здесь особенно интересен.

Когда открываешь такой хаб, быстро становится понятно, что агенты уже живут не только на уровне «вот модель, вот чат, вот промпт». Поверх этого слоя появляется следующий: готовые блоки действий, готовые workflow, готовые куски автоматизации, из которых можно собирать собственные процессы. По сути, skill здесь — это уже не просто текстовая подсказка, а оформленный способ решать повторяемую задачу, строить собственные пайплайны.

Привет, Хабр. Меня зовут Василий Щитов. Я старший инженер в команде CI-инфраструктуры ВКонтакте. 

Когда в компании десятки проектов и сотни сборок, ручное управление конфигурациями через UI быстро превращается в хаос. Внести однотипное изменение во все пайплайны, отследить историю правок или быстро развернуть окружение на новом инстансе TeamCity становится нетривиальной задачей. Можно превратить этот хаос в упорядоченную структуру, если описать конфигурацию как код с помощью Kotlin DSL. Но далеко не все понимают, как работать с Kotlin DSL для решения своих задач.

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

В предыдущей части были рассмотрены варианты ingress-контролера. В этой статье расскажем, как мы тестировали Traefik и постепенно готовим инфраструктуру к переходу на Gateway API без простоев и массового переписывания сервисов.

Сначала хотелось просто скрывать случайные токены по энтропии. Потом выяснилось, что UUID, trace id и номера карт ломают эту идею, и пришлось собирать более честный фильтр логов.

В прошлой части цикла мы подготовили фундамент будущего РБПО: развернули виртуальные машины, настроили Ubuntu Server, сеть, брандмауэр и Docker. Другими словами, построили площадку, на которой теперь можно начинать возводить сам конвейер безопасной разработки.

Теперь пора наполнять наши виртуальные машины полезным содержимым. Если продолжать сказочную аналогию — заселим наше царство безопасной разработки первыми жителями: хранителем секретов, смотрителем артефактов, летописцем уязвимостей и прочими полезными персонажами. То есть установим и настроим GitLab, Nexus, HashiCorp Vault, DefectDojo и Dependency-Track, а также подготовим отдельную виртуальную машину с набором CLI-инструментов для анализа безопасности.

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

Что ж, глаза боятся, а руки команды в терминале набирают. Начнем с GitLab.

Привет, Хабр! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы развиваем облачный сервис и регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.

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

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

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Недавно мы вчетвером с QA-командой нашли способ оптимизировать нашу работу и сэкономить время на написание тест-кейсов и чек-листов с помощью автоматизирующего рутину бота. На всю разработку у нас ушло около двух недель, а в продакшене бот живёт с апреля 2026 года. Расскажу, как мы это сделали и какие результаты получили в итоге.

Привет, Хабр! Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». Больше 20 лет я занимаюсь системной интеграцией и управлением проектами.

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

Wazuh – это open-source SIEM, который собирает логи, детектирует подозрительную активность и умеет на неё реагировать. Инструмент хороший, но дефолтный набор правил – как швейцарский нож: вроде и режет, и открывает, а под конкретную задачу всё равно приходится подтачивать. Он рассчитан на «среднюю» инфраструктуру и без адаптации генерирует много шума.

Моя задача сводилась к тому, чтобы отделить этот шум от значимых событий, не потеряв при этом сами атаки. В этой статье – методология и грабли, на которые я наступил. Будет полезно тем, кто настраивает Wazuh впервые, и тем, кто хочет разгрузить аналитиков от потока ложных тревог.

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

Последние месяцы я гонял другой подход: не «чат, который пишет код», а AI-команда, которая закрывает полный цикл разработки — от формулировки задачи до выката на прод, с планированием, постановкой тикетов, код-ревью, тестами на dev-окружении и автоматическим деплоем. Между этапами ничего не разваливается, потому что система устроена примерно как нормальная команда людей, только роли играют саб-агенты.

В этой статье разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. В качестве подопытного — мой pet-проект, обычный Telegram-бот на Go (MongoDB, Kubernetes). Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не песочница.

MyPrepod — крупнейший портал отзывов о преподавателях российских ВУЗов. Он стал таким не только за счет того, что даже на момент MVP 2017 года он был UX‑удобнее для студентов, чем СтудИзба или professorrating, но и за счет полной анонимности.

Переписали анонимный портал отзывов на преподавателей с PHP 5.4 на современный стек. Сайт грузился 15 секунд, рекламодатели не шли, хостинги блокировали без предупреждения в 2 ночи. Разбираем, как выстроить инфраструктуру, которая переезжает на новый сервер за одну команду и выживает, когда всё вокруг пытается тебя снести.

Пол-года мой личный ИИ-агент “Паспарту” жил на OpenClaw. Я переехал на опенсорсный self-hosted Hermes — и собрал пятнадцать граблей, чтобы Вы их обошли. Честный разбор переезда + пошаговый гайд, по которому повторите за пару часов.

Если ваш проект перерос стадию “просто собрать” и теперь требует бесперебойной работы в проде, простого пайплайна больше недостаточно. Главная боль — как исключить downtime и иметь возможность мгновенного отката? В третьей части цикла разбираемся с GitLab Container Registry.

Мы настроим хранение версий Docker-образов, разберем подводные камни Docker in Docker (dind) и SELinux, а также автоматизируем тестирование перед выкатом. Наконец простейший скрипт для запуска контейнера на production-сервере из вашего приватного Gitlab Registry.

Код стало писать дешевле: большие команды и AI-агенты быстрее создают новые файлы, паттерны и, иногда, дубли. Если поиск copy-paste работает медленно, его легко убрать из каждого pull request и запускать только иногда. Я попробовал сделать быстрый Rust-клон jscpd, чтобы duplicate-code check оставался достаточно дешевым для обычного CI.

Это продолжение первой статьи про Briefka — там я описывал самого бота и базовую архитектуру каскада LLM-провайдеров. За прошедшие 4 месяца бот органически вырос с 59 до 84 пользователей, и именно на этом масштабе бесплатный каскад начал срываться на платного провайдера. Расскажу, почему так вышло и как я вернул расходы к нулю — с цифрами и кодом.

Код ниже — реальные фрагменты из боевого Briefka, слегка сокращённые для читаемости: убраны логирование и сбор статистики.

Стоит ли покупать курс, если уже знаешь 70% материала? Я купил и делюсь своим мнением о прохождении курса

Я думал, проект готов к релизу. CI думал иначе — и оказался прав десять раз. История про то, что видно только на чистом раннере.

«Полностью готовый» и локально зелёный проект — а первый же полный прогон CI вскрыл десяток скрытых проблем: версия CMake на Ubuntu 22.04, строгий GCC 11, артефакты с 403 от CDN, ASan под valgrind, недоступный из сети реестр и другие. Показываю каждую проблему с настоящим сообщением об ошибке и решением, а заодно — как поднял свой раннер, выпустил релиз руками без раннеров и ускорил пайплайн с 53 до 15 минут. Мораль: CI ловит ровно то, что невидимо на машине разработчика, — версии инструментов, окружение и сеть.

Я пользуюсь Hermes Agent уже месяц. Всё это время работал через командную строку (WSL) потому что на windows версии не было, Конечно, уже это довольно ощутимое ограничение, так как Hermes не имел полный выход к файлам в Windows, за это время свыкся с терминалом запускал через hermes chat. недавно вышла версия v0.15.2, и вместе с ней десктопный установщик на Electron. Windows, macOS, Linux.

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

Большинство проблем с SSL-сертификатами возникает не при настройке TLS, а на этапе создания CSR: забытые SAN-домены, неправильные ожидания от wildcard, ручные ошибки в openssl.cnf. Разбираем, почему с сокращением срока действия сертификатов до 47 дней к 2029 году ручной выпуск перестаёт быть жизнеспособным, и какие инструменты приходят ему на замену.