DevOps *

Я работаю по ИП, поэтому не только пишу код, но и поддерживаю как DevOps свои проекты у заказчика. Эта история началась банально: я собирался в отпуск и хотел оптимизировать часть процессов, которые в повседневной жизни занимают время — чтобы не дёргать клиентов из-за вопросов по ошибкам, которые я мог не увидеть во время отдыха. Пусть локальная моделька сама разгребает типовое. Думал: запущу OpenClaw, подключу к локальной модели — и поеду спокойно.

Через две недели — вместо отпуска — я сидел и обучал Qwen3 на Nvidia RTX 3090 24GB, потому что ни одно из существующих решений у меня не работало. Дальше расскажу, как до этого докатился — с цифрами, граблями и бенчмарками.

Всем привет!

Хочу поделиться историей, как я решил попробовать сделать для себя тот самый саморазвивающийся ИИ-стартап и что из этого вышло.

Начну с предыстории. В 2022 году я переехал в Грузию, в Батуми. Здесь я практически сразу начал учить язык, и мне захотелось чуть упростить себе этот процесс — сделать это я решил с помощью своего Telegram-бота. Почему бота? Всем известно, что материал усваивается быстрее и проще, если не садиться за него раз-два в неделю, а стараться изучать что-то небольшое каждый день. Тут мне бы очень помог Duolingo. Но там грузинского нет, хотя есть клингонский. Короче, было решено сделать свой Duolingo из Telegram-бота, только для грузинского.

Сначала получилось что-то совсем простое: перевести / сохранить слово / устроить с новыми словами квиз. Долгое время этого функционала мне хватало, и бот я не развивал, но вот решил попробовать автоматизировать его при помощи современных LLM. Идея была такая — ночью агенты кодят. А утром я читаю чейнджлог и наслаждаюсь новыми функциями. Что получилось на деле —можно почитать под катом.

В эпоху вайбкодинга удивить кого‑то базовым веб‑интерфейсом сложно. Но сделать его понятным и простым в поддержке — другой вопрос. Если вы хотите обернуть свои скрипты\автоматизацию в красивую обертку, а также сделать это быстро и просто — я нашел для вас классную библиотеку на python.

Цель статьи — поделиться классным инструментом и замотивировать вас к созданию нового. Поехали!

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

В статье разбираем, как self-service подход и платформенная инженерия помогают убрать этот шлюз: автоматизировать деплой, выдачу окружений, базы данных и типовые операции так, чтобы разработчики получали автономию, а админы и 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, и как модели разного размера ведут себя при параллельных нагрузках? В целом, результаты получились довольно любопытными.