DevOps *

Цель этой статьи — восполнить пробел в документации связки Strimzi Kafka и мониторинга. У Strimzi есть раздел про метрики и Prometheus и примеры в репозитории (examples/metrics/prometheus-install), но они рассчитаны на общий Prometheus Operator; пошагового руководства именно под Helm-чарт kube-prometheus-stack (с порядком установки и нужными label’ами) в открытом доступе не нашлось. Ниже — собранный и проверенный вариант такой установки.

При проектировании инфраструктуры часто возникает задача поднять кластер «с чистого листа». Безусловно, Terraform и Ansible — это стандарт индустрии. Однако мне нужен был процесс быстрого получения готового кластера K8s, полностью независимый от локального окружения, чтобы запуск не требовал предварительной подготовки версий библиотек, интерпретаторов или наличия локальных файлов конфигурации.

В этой реализации я намеренно упростил работу с конфигурацией: параметры виртуальных машин (CPU, RAM, диски) описаны прямо в коде (см. config.go). Я решил, что проектирование гибкой системы внешних конфигов можно оставить на потом, чтобы на данном этапе не отвлекаться и сфокусироваться на главной задаче — отладке самого механизма восстановления и связности компонентов.

Я реализовал подход полной автоматизации с использованием технологий, которыми увлекаюсь. Суть проста: на машине CI-раннера нет ничего, кроме одного бинарного файла. Всё состояние кластера (IP-адреса, ID дисков), дампы баз данных и зашифрованные секреты хранятся в S3. Это позволяет восстановить кластер в исходное состояние даже после полного удаления, просто вытянув актуальное состояние из облачного хранилища.

В этой статье я поделюсь опытом создания кастомного CLI для подготовки инфраструктуры и использования FluxCD для развертывания приложений. А для проверки результата я использую Yandex Cloud Managed Kubernetes, чтобы запустить K6 Operator и дать внешнюю нагрузку в 1000 пользователей на восстановленные сервисы.

Кому эта статья может быть полезна?

Многие сегодня припарковали свои проекты на виртуальных серверах типа vps/vds или физическом сервере. И вот, по каким-то причинам, вы не хотели бы показывать свой код напрямую.

Если вы уже знаете про GitLab runner, Docker и registry – то можно пройти мимо и сберечь свое время. А кто не знает - добро пожаловать. Постараюсь, чтобы было не сложно.

Какие могут быть причины?

Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.

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

Есть момент, когда компания внезапно понимает: «мы уже не стартап на коленке, у нас продукт, клиенты, релизы, ответственность — и, кажется, пора взрослеть». Вот примерно там и появляется РБПО — разработка безопасного программного обеспечения.

В выпуске CrossCheck говорят: РБПО — не «для галочки» и не «для регулятора». Это про то, чтобы выжить в реальности, где код растёт, команды меняются, а рынок всё чаще спрашивает: «а вы вообще понимаете, из чего и как собраны ваши решения?».

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

В статье — практический разбор cgroups v2: как руками через cgroupfs создать группу, задать лимиты CPU/RAM и правильно запускать процессы без «окна без ограничений», а затем сделать то же самое через cg*-утилиты и systemd-run/slice. По дороге станет ясно, почему эти приёмы напрямую перекладываются на мир Docker и Kubernetes.

Если вы работаете в банке, страховой, МФО или любой другой организации, которой нужно проверять паспорта клиентов, запрашивать сведения из ЕГРЮЛ или получать сведения о наличии (отсутствии) судимости — рано или поздно вы упрётесь в СМЭВ. И скорее всего, обнаружите, что подключиться к нему сложнее, чем казалось.

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

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

Когда в команде спорят о фичах, производительности или надёжности, я редко слышу принципиально разные аргументы. Чаще это разные формы одного и того же:

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

Проблема в том, что «кажется» и «уверен» плохо масштабируются. А числа — масштабируются отлично.

Как писать «скучные» API-автотесты на Go: выносим всю инфраструктуру в Axiom, оставляя в тестах только бизнес-сценарии, и запускаем всё в CI/CD с Allure.

ONNX Runtime (ORT) — это высокопроизводительный движок для выполнения моделей в формате Open Neural Network Exchange (ONNX). Он предлагает оптимизированные реализации для CPU и GPU, поддержку различных аппаратных ускорителей и, что ключевое, простой C++ API. В этой статье мы разберем, как выполнить инференс модели для табличных данных, используя ONNX Runtime в C++ проекте.

Ссылка для скачивания: Библиотеку можно получить через официальный GitHub (сборка из исходников). Для простоты в проектах часто достаточно забрать предсобранные бинарники из релизов.

Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.

Мониторинг — это сердце любой современной IT-инфраструктуры. Сегодня я хочу рассказать о нашем опыте построения и развития инфраструктуры мониторинга в одном из крупнейших банков России – Россельхозбанке.

Привет, Хабр! Меня зовут Сергей Смирнов, я DevOps экосистемы «Своё» в РСХБ.Цифра.

Речь пойдет не о всей гигантской IT-инфраструктуре банка, а о ее специфической части. Мы работаем с тем, что можно назвать «внешним облаком» РСХБ. В этой статье я расскажу об общей архитектуре, ключевых технологиях для сбора метрик, логов, трассировок, алертинга и визуализации, принципах настройки и развертывания, примерах и готовых решениях, в частности о том, как Victoria Metrics может стать центральным элементом системы мониторинга, охватывающей как Kubernetes, так и другие компоненты инфраструктуры.

Самое главное – я поделюсь конкретными примерами конфигурационных файлов, Helm-чартов или других манифестов, которые позволят вам развернуть базовый (или даже расширенный) стек мониторинга «из коробки» в вашей собственной среде.

Атаки на сервера в России очень сильно изменились за последние 4 года, их стало в десятки раз больше, атакующие активно использую ИИ и при этом, законодатели решили еще и усилить эффект - запретив использовать западные бесплатные технологии защиты вроде Cloudflare. В сочетание с законом о приземление - когда ты обязан использовать сервера в РФ это дает кошмарный эффект в защите и огромный бонус для атакующего.

В этой статье мы защитим свой сервер, защитим SSH, защитим Nginx, панель управления Fastpanel и еще побочное преимущество - получим VPN на основе Tailscale (Wireguard).

Это статья написана исключительно на основе моего личного опыта - как я защищаю свои сервера. Если вам есть что добавить - буду рад это услышать. И так, у нас в нашем примере у нас чистая Ubuntu 24 server.

В предыдущих статьях я уже подробно описывал, как GPT-5.2 и Anthropic Sonnet справляются с задачами прикладного уровня.

В этой статье — Kimi K2.5 с reasoning’ом.

Важно сразу обозначить:
эксперименты те же самые.
Методология не менялась вообще.
Менялась только модель.

Уже нет сомнений в том, что искусственный интеллект позволяет оптимизировать и ускорить процесс разработки, помогая в написании и ревью кода. Но насколько полезен он может быть для задач в сфере инфраструктуры и девопс? 

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

В предыдущей статье я встроил команды для работы с веб-камерой в код сервиса робота, а также заменил Wi-Fi антенну на более крупную, чтобы повысить стабильность сигнала. Кроме того, я добавил поддержку управления с клавиатуры, чтобы сделать управление роботом более отзывчивым. В результате мне удалось успешно пройти полосу препятствий, управляя роботом и ориентируясь на изображение с веб-камеры.

В этом материале я создам Docker-контейнер для веб-приложения web-robot-control, который упростит и ускорит его запуск. Также я настрою GitHub Actions для сборки артефакта и его последующей автоматической отправки в Docker Hub.

Статья будет полезна веб-разработчикам, девопсам, которые интересуются созданием Docker-контейнеров и работой с Docker Hub.

Контейнер — не виртуальная машина. Между контейнером и хостом тонкая стена: общее ядро, общие ресурсы, минимальная изоляция по умолчанию. Стандартный docker run запускает процесс с root правами внутри контейнера и доступом к большинству системных вызовов.

Большинство команд оставляют дефолтные настройки, потому что «и так работает». Пока не приходят пентестеры или не случается инцидент. Разберём конкретные настройки, которые реально повышают безопасность, с примерами и объяснением зачем это нужно.

Всем привет! Меня зовут Рома, я DevOps в команде «Платформа» в Банки.ру.

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

В этой статье я расскажу, как мы нашли способ упростить и ускорить эту работу, а заодно навести порядок в репозитории.

Разработка AI-агентов сегодня — одна из самых «горячих» тем в IT. Кодинг-агенты уже оформились в отдельный класс продуктов с понятными лидерами: терминальные (Claude Code, Opencode) и IDE-ориентированные решения (Cursor, плагины для VS Code и т.д.).

Но что делать, если нужен универсальный помощник для повседневных задач: работы с файлами, ресёрча, анализа данных и OPS-активностей? В этой нише пока нет доминирующего архитектурного подхода.

В статье я рассматриваю один из возможных вариантов архитектуры универсального AI-агента: какие идеи за ним стоят, как они реализованы на практике, и какие сценарии уже сегодня выглядят реально рабочими.