DevOps *

Привет! Меня зовут Катерина Цаплина, я программный эксперт курса «MLOps для разработки и мониторинга моделей», и это вторая статья цикла о том, как компании реализуют MLOps. В предыдущей части мы разбирали, какие архитектурные подходы скрываются за MLOps: от workflow-фреймворков до managed-сервисов и внутренних платформ. 

В этой статье хочу разобрать один из самых известных платформенных кейсов — Michelangelo компании Uber. Он ценен тем, что наглядно показывает, как ML-платформа вырастает из практических задач и затем эволюционирует  вместе с изменением сценариев: от классического ML к deep learning и LLMOps.

Поговорим о том, как устроена платформа, какие сущности и слои в ней ключевые и почему этот пример остаётся полезным. Посмотрим на Michelangelo через призму российских реалий, порассуждаем о связи между зрелостью ML в компании и сложностью корпоративного ландшафта, а также о том, когда платформа действительно становится оправданной.

Привет, Хабр. Мы платформенная команда в продуктовой компании с восемью продуктовыми командами. У каждой свой микросервис, свой стек, свои нюансы. Есть общие конвенции, общий security baseline, общий подход к observability.

В начале прошлого года стало понятно: AI-инструменты разработки уже не эксперимент, а повседневная реальность. Claude Code, Cursor, Copilot, кто во что горазд. И при этом ровно ноль централизованного подхода. У одного разработчика в ~/.claude/CLAUDE.md свой набор правил, у другого .cursorrules с другими правилами. В одном репо команды лежал 400-строчный CLAUDE.md с дублирующимися общими конвенциями, в другом пустота. AI отвечал по-разному в одном и том же сервисе в зависимости от того, кто его спрашивал.

За полгода мы построили то, что внутри называем AI Kit. Это централизованный набор правил, skills, subagents и CI-инструментов для AI-ревью. В этой статье наш путь, грабли, цифры. И чего бы мы не делали, если бы начинали заново.

Если у вас несколько продуктовых команд и AI-инструменты уже есть, но дисциплины их использования нет, то статья для вас. Будет полезно тимлидам, CTO, инженерам платформенных команд и AI Champions.

Привет, Хабр! Сегодня я хочу осветить тему работы с системой контейнеризации Docker прямиком из программы на Rust. Эта статья будет полезна тем, кто хочет разрабатывать различные программы для автоматизации рутинных действий Docker.

30 апреля на PyPI обнаружили новую версию PyTorch Lightning, которая при импорте скачивала Bun и запускала 11,4 МБ опасного JavaScript-вора. Цель — браузеры, облачные API, GitHub-токены. Всего одна строчка импорта: import lightning — и все ваши API-ключи и данные будут скомпрометированы! Полный разбор инцидента внутри.

DevOps и безопасность — одни из немногих профессий, устойчивых к кризису. Если изучаете DevOps или прокачиваетесь в безопасности — этот цикл статей для вас.

Часть 2 серии об осмысленном CI/CD: настраиваем self-hosted GitLab Runner. Пройдем от docker-compose.yml до работающего runner, попутно разбирая ошибки permissions, SELinux context и особенности rootless Podman. Все то же самое актуально и для Docker.

Когда Kubernetes-кластеров становится больше одного, инфраструктура начинает жить по новым правилам. Один кластер развёрнут в основном датацентре, второй — в резервной площадке. Сложности начинаются в тот момент, когда этим кластерам нужно взаимодействовать друг с другом. Сервисы в одном кластере должны обращаться к сервисам в другом, приложениям требуется нормальная маршрутизация, а инженерам хочется управлять этим без набора временных решений вроде iptables и ручных DNS-записей.

В качестве сетевого слоя будем использовать Calico, а для межкластерного взаимодействия сервисов — Istio. Первый даст маршрутизацию и связность, второй — discovery, балансировку и управление трафиком на уровне приложений.

Привет, Хабр! Меня зовут Ярослав Яковкин, я младший инженер по разработке ПО в YADRO, работаю в команде TATLIN.FLEX. Еще будучи стажером, я разбирался в инструментах, которыми пользуется моя команда, и обнаружил, что система мониторинга Zabbix допускает некоторые ошибки в работе. Они не влияют на производительность, но, если их исправить, всем станет лучше.

Я погрузился и узнал, как устроен инструмент и что сделать, чтобы устранить неисправности, а опыт собрал в этой статье. Материал будет полезен тем, кто недавно работает с Zabbix, — возможно, вы найдете решение своей проблемы под катом. А опытных девопсов приглашаем в комментарии — поделитесь лучшими практиками по оптимизации Zabbix. 

Обычно для базовой диагностики прокси достаточно просто заглянуть на страницу администрирования Zabbix proxy или посмотреть метрики состояния прокси. Однако бывают ситуации, когда требуется более глубокий анализ.

Сегодня мы разберём взаимодействие между Zabbix server ↔ proxy и научимся интерпретировать внутренний протокол обмена.

Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте

Всем привет! Меня зовут Ярослав Покрепов, я DevOps-инженер в Авито. 

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

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

Дисклеймер: ранняя история инфраструктуры компании восстановлена не по документации, а по воспоминаниям инженеров, которые работали в тот период. Это устная история — с допущениями, реконструкцией контекста и попыткой передать факты и логику решений.

«У нас было два пакета findings SAST’а, семьдесят пять CVE с критичностью — Critical, пять дублей одной и той же CVE в разных сервисах, пол солонки false positive и целая россыпь уязвимостей всех сортов и расцветок: SQLi, XSS, SSRF, RCE, IDOR, утекшие секреты, misconfigs в Kubernetes, написанные человеком, который явно не планировал дожить до аудита.

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

Не то чтобы это был необходимый запас для управления безопасностью приложений, но если уж ты решил строить ASPM через агрегацию всего подряд, рано или поздно ты оказываешься именно в такой машине — на полной скорости, без карты, с разработчиками на заднем сидении, которые только и спрашивают: “Что из этого реально надо исправлять?”». 

Всем привет! Меня зовут Артем Пузанков, я руководитель отдела консалтинга безопасной разработки в Бастионе. Сегодня хотелось бы порефлексировать с вами про управление состоянием безопасности приложений, ASPM, AI-generated код и AppSec.

Эта статья о том, почему будущее ASPM не в том, чтобы собрать все дефекты в «единое окно», а в том, чтобы сопоставить обнаруженные находки, проверить достижимость и отделить реальные угрозы от шума (читай технического долга).

Да, простите меня ребята, но ко мне пришел автор курса из прошлой статьи и сказал, что все понял, учел поправил и даже GUI навалил. Так как я ранее приобретал курс, обновление получил просто так. Учитывая, что прошлая статья для многих оказалась полезной, я решил дополнить обзор новой — полезных изменений достаточно много.

Алерт по Kafka lag выглядит убедительно, пока не приходится объяснять, что именно значат «50 000 сообщений отставания» для пользователей и SLA. В статье разбираем, почему offset lag часто создает ложное ощущение контроля, где ломаются популярные подходы к расчету задержки и как перейти к мониторингу по реальному time lag.

На примере klag-exporter покажем, как считать задержку через таймстемпы сообщений, настроить метрики для Prometheus и Grafana и сделать алерты, которые помогают дежурному инженеру понять критичность проблемы без гадания по дашборду.

LLM пока не может хорошо обращаться с Е2Е автотестами потому что для этого нужно провести целый комплекс мероприятий. Сложность возникает уже на этапе запуска такого автотеста. В отличии от юнит автотестов, Е2Е автотесты почти всегда PageObject и целый проект со своей архитектурой на базе Selenium Appium Espresso и тд.

Для начала — просто гляньте на те фото и видео, которые я сгенерировал, вообще не прикасаясь к мышке или планшету. Конечно, до и после было проделано немало работы, но сам процесс создания цифрового арта не требовал ручного рисования. Так что скажем спасибо моим CPU и GPU — они реально тащили 💪

По ходу этого пути возникли интересные вопросы: когда вообще есть смысл использовать СPU, и как модели разного размера ведут себя при параллельных нагрузках? В целом, результаты получились довольно любопытными.

Статус 200 OK коварен своей тривиальностью.

Бэкенд-тесты «зеленые», API честно отдает данные, а веб-клиент мгновенно подхватывает изменения. Кажется, что всё в порядке, но в это же время мобильные клиенты теряют работоспособность. Приложение не выдает сетевых ошибок, оно просто не может корректно обработать обновленный DTO: клиент ожидает одну структуру данных, а получает другую.

Это не баг логики сервера, а технический разрыв между живым API и замороженным артефактом — версией приложения, которая ничего не знает о правках в схеме данных, сделанных через полгода после его релиза.

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

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

Я Алексей Матвеев, директор по мобильным технологиям в «Первой Форме», и в нашей компании, к сожалению, такое тоже происходит. Чтобы ловить такие расхождения до релиза, нам же был нужен прогноз совместимости до того, как изменения на бэкенде затронут пользователей. Мы создали прозрачный конвейер самодиагностики, который подсвечивает нестыковки в данных еще на этапе тестирования бэкенда, гарантируя корректную работу тех версий приложения, которые уже живут на устройствах пользователей. В статье расскажу подробно, как устроено это решение.

Привет, Хабр! Меня зовут Дмитрий Титов, я DevOps-инженер в команде интеграционных сервисов Platform V Synapse в СберТехе. Наша команда работает над продуктом Platform V Streaming Event Processing — программным решением для фильтрации и трансформации форматов событий, агрегирования и выявления аномалий и закономерностей.

В этой статье я расскажу, как мы создали систему автоматического генерирования конфигураций для одного из компонентов нашего продукта, используя RAG (Retrieval-Augmented Generation), векторные базы данных и межагентное взаимодействие по протоколу A2A.

Свежепоставленный мониторинг на DGX Spark. Открываю NVIDIA‑дашборд в Grafana — половина memory‑панелей пустые, прямые линии по нулю. Сначала кажется, что что‑то не настроил. Через полчаса доходит: это не у меня сломалось, это NVML на GB10 так работает.

Это та область, где на GB10 половина стандартного observability‑стека просто не работает: NVML отдаёт [N/A] на memory.used и memory.total, dcgm‑exporter не ставится, nvtop в memory‑колонке показывает пустоту. В Grafana NVIDIA‑дашборды по умолчанию выглядят так, будто GPU вообще нет — и это не очевидно, потому что Grafana при отсутствии данных не кричит, а молча рисует ровную линию по нулю.

Статья — про то, как я это место обошёл и что в итоге увидел в Grafana. Трёхуровневая схема: textfile collector для базовых метрик, per‑container attribution через docker top + nvidia-smi, и CLI‑фоллбэк на /proc/meminfo, который оказался полезен не только на Spark, но и на других Linux‑системах с единой памятью (unified memory) — AMD Strix Halo и подобные.

Kubernetes-операторы стали краеугольным камнем современного управления инфраструктурой. Операторы автоматизируют сложные жизненные циклы — развертывание, конфигурацию, масштабирование, резервное копирование и восстановление.

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

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

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня я хочу поделиться историей создания одного интересного проекта — клиента для облачного сервиса Ollama.