DevOps *

В секциях по интеграциям, DevOps и тестированию пока меньше заявок, чем в других направлениях INFOSTART TECH EVENT 2026. Это повышает шансы сильной темы пройти отбор, попасть в голосование и войти в программу конференции.

Приём заявок на INFOSTART TECH EVENT 2026 продолжается. Сейчас особенно ждём доклады в три секции:

Qdrant — это векторная база данных, которую используют для поиска похожих текстов, изображений и других объектов. Например, Qdrant часто применяют в чат-ботах, RAG-системах, рекомендательных сервисах и приложениях на базе искусственного интеллекта.

Однако после установки Qdrant важно правильно настроить доступ и хранение данных. Если просто открыть порт базы данных в интернет, злоумышленники могут попытаться получить доступ к коллекциям или удалить данные.

Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о новом предзаказе: «Метрики программной архитектуры. Кейсы, повышающие качество ПО».

Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.

Я Анастасия, ведущий SRE-инженер РСХБ.Цифра. В этой статье я расскажу о том, как мы в App.Farm, PaaS-платформе Россельхозбанка, перешли от одной «большой» Kafka до реализации услуги «Kafka as a Service» c индивидуальными кластерами под ключ. Звучит просто, но за этим кроется сложный путь проб и ошибок. 

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

В статье разберём, как выстроить воспроизводимый ML‑пайплайн с контролем данных, версий и состояний, чтобы решения модели можно было восстановить, проверить и обосновать.

Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

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

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

Артефакт нашей сборки — не бинарник, а код вместе с терабайтами рассчитанных таблиц. Рассказываем, как из штатных фич Airflow, Spark и Delta Lake у нас собрался настоящий CI/CD для данных и моделей — с релизами, стейджем и откатами. И почему кнопку «выкатить в прод» жмёт дежурный data scientist, а не инженер данных.

Когда инфраструктура начинает сбоить, причина редко остаётся в одном слое: за проблемой с деплоем тянутся пайплайны, контейнеры и секреты, а за деградацией сервиса – логи, сеть, база данных или настройки Linux. В этом дайджесте собрали практические материалы по K8s, CI/CD, DevSecOps, наблюдаемости, PostgreSQL и отказоустойчивости – для тех, кто хочет быстрее находить слабые места и лучше понимать, как связаны компоненты современной инфраструктуры.

Перед командой, выросшей на MySQL/MariaDB, встаёт вопрос перехода на PostgreSQL: лицензии, экосистема расширений, более предсказуемое поведение при конкурентных нагрузках - причин достаточно. Проблема в другом: как перенести боевую базу, которая не останавливается ни на минуту, без часов простоя и без риска потерять данные, записанные во время переноса.

В этой статье - как мы решали эту задачу для интернет-магазина на MariaDB, почему готовые консольные конвертеры не годятся для «живой» миграции, и как выглядит рабочая схема на Debezium + Kafka Connect, включая Ansible-роль для повторяемого запуска.

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

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

Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11.

Рассмотрим нестандартный вариант установки Kubernetes, а именно установка кластера без control-plane ноды как таковой в стандартном ее восприятии. Установим кластер Kubernetes где слой control-plane будет просто хостом без CRI, только базове systemd сервисы. "Спрячем" control-plane от лишних глаз.

Self-hosted git ставят ради приватности кода. А оказалось, что “приватное” в Gitea открывается одним HTTP-заголовком: без пароля утекают секреты из приватных репозиториев и открывается админка. Поднял уязвимую версию на стенде, воспроизвёл атаку целиком, показал как ловить в логах и чинить. И почему это не единичный баг, а паттерн 2026 года.

Есть паттерн, который я вижу почти в каждом кластере, куда прихожу: liveness-проба, скопированная из туториала, которая годами тихо делает продакшен хуже. Не «не помогает» — именно делает хуже: превращает локальные замедления в каскадные рестарты и красивые инциденты на ровном месте.

Тезис статьи простой: liveness-проба — это не «проверка здоровья». Это заявление «если этот запрос не ответил — процесс нужно убить». И в большинстве конфигураций, которые я встречал, это заявление ложно.

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

Чтобы упростить навигацию по материалам INFOSTART TEAM EVENT 2026, доклады собрали в пять профессиональных маршрутов: для ИТ-директоров, DevOps-инженеров, аналитиков, разработчиков 1С и руководителей проектов.

В каждой подборке - три выступления с видеозаписями и презентациями. Их можно посмотреть последовательно как небольшой учебный маршрут или выбрать отдельный доклад под текущую рабочую задачу...

Крон отработал. Экзит-код ноль. Файл лежит в S3, размер похож на правду. Мониторинг зелёный. Всё говорит о том, что бэкап сделан успешно, вот только его никогда не пробовали восстановить.

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

Команда VK Cloud перевела заключительную часть цикла Cilium про защиту цепочки поставок. Часть 1 была про контроль доступа, часть 2 — про укрепление зависимостей. Эта же часть о том, как изолировать секреты CI и продакшена за разными окружениями GitHub, подписывать каждый релиз без долгоживущих ключей через Sigstore Cosign, и какие пробелы безопасности остаются открытыми. Отдельно — разбор дорожной карты безопасности GitHub Actions на 2026 год и того, как платформенные изменения соотносятся с уже выстроенными контролями. Полезно DevOps- и SRE-инженерам, специалистам по безопасности и мейнтейнерам OSS-проектов.

Интернет — это зависимость без зафиксированной версии. Сегодня он возвращает одно, завтра — другое, а послезавтра — ничего. Поэтому мы решили сохранить для сборки тот интернет, который она однажды увидела. Для этого пришлось перехватывать HTTPS, выпускать собственные сертификаты, переподписывать индексы Debian и выяснять, почему Docker отправляет «случайные» заголовки.

В этой статье я расскажу, как разрабатывал кеширующую MITM-проксю, которая перехватывает весь HTTP/HTTPS-трафик и отдаёт ранее сохранённые ответы. Разберём также неочевидные технические проблемы, с которыми пришлось столкнуться.

В предыдущих статьях мы научились работать с Linux, освоили Bash, познакомились с Git и GitHub. Следующий шаг — Docker.

Если посмотреть на любую вакансию Junior DevOps, Backend-разработчика или SRE, среди требований почти всегда можно встретить Docker. Почему так?

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

Anthropic и AWS выпустили Claude apps gateway — self-hosted control plane для Claude Code и Claude Desktop, который живёт в вашей инфраструктуре и забирает с ноутбуков разработчиков ключи, настройки и учёт расходов. Один stateless-контейнер за внутренним ALB, вход через корпоративный OIDC, managed settings по группам, телеметрия по OTLP и лимиты трат через admin API. Разбираю по конфигам, что он реально контролирует, где проходит граница enforcement и в каких местах я бы притормозил перед раскаткой на сотни рабочих мест.