DevOps *

В прошлой части цикла мы подготовили фундамент будущего РБПО: развернули виртуальные машины, настроили 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, слегка сокращённые для читаемости: убраны логирование и сбор статистики.

Я думал, проект готов к релизу. 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 году ручной выпуск перестаёт быть жизнеспособным, и какие инструменты приходят ему на замену.

Часть своих сервисов я держал в облаке, но когда счёт за AWS начал превышать ожидания, стало понятно: пора переносить их домой. Несколько месяцев назад я купил мини-ПК, но всё никак не находил времени его задействовать. Так я занялся решением проблемы локального деплоя.

Привет, я Сергей Истомин, DevOps-инженер в KTS. А ниже моя история про построение мультитенантного скоупа кластеров VictoriaMetrics с разными периодами хранения метрик.

Статья будет о том, как собрать систему одновременно и простую, и сложную. Простую потому, что каждый поток данных в ней лаконичный и линейный, и сложную потому, что совокупности этих потоков комбинируются и интегрируются в общие компоненты. Система будет построена на редакции Community Edition.

Надеюсь, что я вас хорошенько запутал и при этом заинтриговал.

Привет, Хабр! На связи Даниэль из InfoWatch, разработчик решений класса информационной безопасности. В предыдущей статье мы рассматривали задачу контроля целостности в среде Linux с помощью системного интерфейса inotify. Поговорили о ключевых недостатках, с которыми приходится сталкиваться в ходе работы с самим инструментом напрямую.

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

Введение

Начнём с краткой сводки по fanotify. fanotify представляет собой kernel-интерфейс, позволяющий мониторить события файловой системы в режиме реального времени. Определение такое же, как и для inotify. Почти. Существенная разница в том, что список обрабатываемых событий у fanotify гораздо шире, а также есть возможность принимать решение kernel-характера в user space. Простыми словами: вы можете разрешать/запрещать запуск программ без написания драйверов (модулей ядра), так как fanotify позволяет разрешить/запретить создание процесса в пользовательском пространстве.

Привет, Хабр! Меня зовут Виктор Лучиц, я архитектурный лид в отделе инфраструктурной разработки рекламных технологий VK. Я расскажу, как наша команда осуществила конвергенцию двух наших core-технологий, как справлялись с инцидентами и что в итоге получили.

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

Привет, Habr!

Мы разрабатываем IncidentRelay - self-hosted систему для on-call scheduling, маршрутизации алертов и доставки уведомлений. Идея простая: дать командам SRE, DevOps, platform и operations понятный инструмент, который можно развернуть у себя, подключить к мониторингу и использовать без зависимости от внешней incident-management платформы.

В статье — разбор основ Ansible: как писать идемпотентные плейбуки, не класть продакшен сухими прогонами и встроить Ansible в CI/CD.

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