DevOps *

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.

29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».

Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.

Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.

Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.

Статья о том, как читать kubectl describe pod не как длинный вывод, а как историю жизни Pod«а: кто его создал, куда его пытались поставить, скачался ли image, стартовали ли init containers, что случилось с probes, volumes, restarts и Events.»

Постарался сделать материал дружелюбным для джунов и мидлов, но без упрощения до «введите команду и посмотрите статус». Тут много реальной эксплуатации: Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount, CreateContainerConfigError, Evicted и любимое «Pod Running, но сервис не работает».

Если вам нужна не вся теория, а быстрая шпаргалка для инцидента — в конце статьи есть компактная схема: что смотреть в kubectl describe pod при Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount и других типовых состояниях. Можно сразу перейти к ней, сохранить и использовать как чек‑лист. А если хочется понять не только «куда смотреть», но и почему Kubernetes ведёт себя именно так — дальше разберём describe вместе по шагам.

Все русскоязычные гайды по GitLab CI/CD — это «сделай вот так под Node.js/Java/.NET». А как оно вообще работает? Написал подробный туториал: термины, схемы, разбор .gitlab-ci.yml, логи runner’а построчно. Первая часть из трёх — от простейшего pipeline до понимания, что конкретно вам нужно в вашем случае.