DevOps *

Привет, Хабр! Меня зовут Михаил Пушкарёв, в команде РСХБ.Цифра я отвечаю за развитие систем класса ECM и OCR. В РСХБ технологии OCR применяются начиная с 2010 года и развиваются до сих пор. Технология направлена, в первую очередь, на ускорение и обслуживание клиентов банка. Сформированная конструкция контуров и наличие локальных установок делали процесс развития и обновления системы не просто сложным, а очень сложным. Помимо этого, на горизонте всё более явно начинал «маячить» процесс переходов на отечественные ОС, что привело бы к невозможности работы со всеми программными комплексами из-за того, что толстые клиенты предусматривали работу только с ОС Windows.

Конечно же, непосредственный уход с рынка Abbyy накладывал свой отпечаток на данные процесс. К моменту ухода Abbyy мы уже сформировали собственную компетенцию, которая позволяла нам в полной мере заниматься развитием проекта (добавлять новые шаблоны) или решать какие-либо проблемы. Но так как ПО не является свободно распространяемым, по сути мы лишились обновлений комплекса.

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

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

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

В современных облаках есть много задач, связанных с проблемами производительности и масштабируемости виртуальных сетей. Кроме этого, есть ряд задач, требующих интеграции с аппаратными сетевыми устройствами. Чтобы преодолеть этот барьер, в собственном SDN (Software Defined Network, программно-определяемая сеть) мы реализовали поддержку технологии EVPN. За это отвечает специальный компонент — EVPN-connector. Он использует OpenVSwitch для передачи данных и GoBGP для передачи информации и позволяет строить распределенные сети с поддержкой L2- и L3-режимов, а также обеспечивает интеграцию с аппаратными устройствами. В этой статье мы, команда IaaS Network в VK Cloud, расскажем о EVPN-connector в деталях.

Привет, Хабр! На связи команда «Гравитон». В этой небольшой статье мы собрали подборку практических приемов для эффективной работы с bash, которые помогут упростить интерактивное взаимодействие, а также повысить надежность и читаемость скриптов.

У компаний, которые работают в облаке, каждый новый месяц начинается с сюрприза. Его преподносят счета, которые почему-то всегда оказываются процентов на 30-40 больше прогноза. И тут начинается. Финдир смотрит на тимлида. Тимлид — на команду. Команда — в логи. А в логах — тишина. Ничего же не меняли. Или меняли?

В прошлой статье мы собрали типовые сцены из жизни. Помните наших героев?

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

Привет, Хабр! Если интересно проанализировать недостатки инструмента inotify с позиции решения ИБ-задачи контроля целостности (именно самого инструмента в его первозданном виде), то добро пожаловать под кат!

Введение

Давайте поговорим о такой задаче информационной безопасности, как контроль целостности объектов файловой системы.

Какие инструменты контроля целостности в Linux приходят сразу на ум?

AIDE (Advanced Intrusion Detection Environment)
AFICK (Another File Integrity Checker)
tripwire
wazuh
OSSEC

Из перечисленных инструментов aide, afick и tripwire работают по принципу «редкого» мониторинга, а wazuh, ossec — постоянного (более подробно эти понятия раскроются дальше).

В этой статье лишь немного затронем тему принципа работы «редкого» мониторинга, в большей степени поговорив о проблемах, возникающих при работе с inotify, который положен в основу постоянного мониторинга wazuh/ossec.

Мы не будем досконально рассматривать сам механизм ядра Linux, хорошего материала на эту тему достаточно, в том числе и на Хабре. Также не станем проводить глубокий анализ работы прекрасных утилит inotify-tools или incron. Речь пойдет именно про сам inotify в его первозданном виде без каких-либо обвязок и библиотек. Нам важно понять, с какими проблемами можно столкнуться в случае проектирования ПО, использующего сам inotify. Что касается inotify-tools, то здесь мы посмотрим на то, закрывают ли утилиты данного пакета описанные проблемы.

Когда команда выбирает LLM для продакшена, «сравнение по бенчмаркам» — это лишь первый фильтр. Для CTO ключевой вопрос звучит иначе: какую комбинацию качества, стоимости, стабильности API, юридических ограничений и интеграций мы получим на реальной нагрузке. Я разобрал популярные модели через призму двух контуров: качество/бенчмарки и инфраструктурная пригодность.

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

У любого бизнеса есть миссия и цель. Миссии бывают разные, цель всегда одна: извлечение прибыли. Если ты маркетолог, или продажник, то напрямую наливаешь деньги в кассу. В этом случае всё понятно: выручка минус расходы == прибыль. 

Но что если ты — технарь? Разработчик пилит фичи, по сути реализует бизнес-процессы, которые также зарабатывают деньги. 

Но если твоя работа на фичи не завязана, или состоит не только в этом? Или ты и вовсе не разработчик, а DevOps, SRE, QA, безопасник и так далее? 

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

Привет! Меня зовут Степан и я занимаюсь управлением техническими рисками в онлайн бизнесах. Эта статья — практическое руководство о том, как определить ценность твоей работы, научиться измерять её практическую пользу и управлять целями, если ты не приманиваешь деньги напрямую на расчетный счет.

Есть типичная боль: ты вроде всё сделал правильно — контейнеры поднялись, API отвечает, UI открывается… а потом оказывается, что «не работает». Причём не «сломано в пепел», а именно «почти»: где‑то 404, где‑то таймаут, где‑то UI открывается, но вкладки пустые, где‑то один запрос проходит, другой — молчит.

И самое неприятное: когда начинаешь чинить «по ощущениям», можно потратить часы, а потом выяснить, что причина была не в коде, а в порте, origin, IPv6, миграциях или в том, что UI ходит не туда.

Я перестал спорить с реальностью и сделал себе простой подход evidence-first:

pgAdmin4 - де-факто стандартный GUI для PostgreSQL.
И при этом на Arch Linux его Desktop-версия годами находится в полурабочем состоянии.

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

Если вам тоже надоело чинить pgAdmin после каждого обновления Python или Electron - это для вас.

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Представьте: вы прыгаете с парашютом, дергаете кольцо, а из ранца вместо купола вылетает записка: «404: Not Found». В ИТ-инфраструктуре бэкап — именно такой парашют. И проблема в том, что 90% инженеров уверены: раз ранец за спиной висит, значит, гравитация им не страшна. Мало кто проверяет его «укладку» (валидацию) и тренирует само приземление (DR). Чаще всего процесс строится либо на слепой вере в собственную память, либо на тотальном доверии древним скриптам, которые DevOps-археолог написал еще пять лет назад. В момент свободного падения времени на исправление конфигов этих скриптов уже не будет. Поэтому под катом — краткая инструкция по «укладке парашюта»: быстро и без воды про классические ошибки и как их обойти.

Привет, Хаброжители! Узнайте, как управлять кластерами Kubernetes и конфигурациями приложений с помощью Argo CD — простого и удобного инструмента GitOps с открытым исходным кодом. Благодаря этому практическому руководству команды разработчиков быстро освоят базовые навыки использования Argo CD для развертывания контейнерных приложений и управления ими — без полного доступа к существующей среде Kubernetes.

Полное руководство по развертыванию высокодоступного кластера Kubernetes 1.35 на Ubuntu 24.04

Эта подробная техническая статья представляет собой пошаговое руководство по созданию отказоустойчивого кластера Kubernetes версии 1.35 с использованием утилиты kubeadm. В руководстве рассматривается развертывание производственного кластера с тремя master-нодами и тремя worker-нодами, что обеспечивает высокую доступность и отказоустойчивость.

Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.

В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.

Kubernetes взламывают не «эксплойтом века», а банальностями: открытый доступ, cluster-admin «на время», default serviceAccount, секреты в манифестах (да, base64 не защита). Дальше сценарий предсказуемый — от тихого майнинга до утечки ключей, как в истории с Tesla.

В статье разберу три базовых опоры k8s-безопасности: минимизация прав через RBAC, нормальная работа с секретами и изоляция workload’ов через securityContext и политики — с типовыми ошибками и практиками, которые реально внедрить.

Observability — это не просто логи или метрики по отдельности, а целостная картина поведения системы. В этой статье разберём минимальный, но полноценный стек OpenTelemetry для Go-приложений: соберём метрики, трейсы и логи, прокинем их через otel-collector и посмотрим результат в Grafana (Prometheus + Tempo + Loki).

Без лишней теории — только практический пример: docker-compose, инициализация OTel в Go, инструментирование HTTP-клиента и сервера и просмотр данных в UI. В итоге получится рабочий шаблон, который можно использовать как основу для своих сервисов.

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

Мы перевели сервер управления Netbird с Fail2Ban на CrowdSec и собрали это в практический разбор: как читать JSON‑логи Caddy без плясок с регулярками, как вешать блокировки на nftables, и почему community threat intel позволяет отрезать часть сканеров ещё до того, как они успевают что‑то «прощупать». По ходу рассмотрим конфиги, команды и наблюдения, что именно меняется в шуме, банах и нагрузке.

За последние восемь лет более 15 популярных баз данных изменили лицензии с открытых (BSD, Apache) на модели с ограничениями, которые запрещают коммерческое использование или требуют раскрыть весь программный стек. Разработчики выбирают открытые БД, а через несколько лет сталкиваются с необходимостью покупать лицензии или мигрировать — обычно в самый неподходящий момент.

Если вы думаете «сейчас выберем open source, а там разберемся» — этот пост для вас. Я не буду разбирать юридические тонкости, а попробую ответить на простой вопрос — какие БД сегодня опасно брать в прод и чем их можно заменить, если это уже случилось.

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