DevOps *

Некоторое время назад мы столкнулись с типовой проблемой очередей при исполнении пайплайнов. Задачи упирались друг в друга, мешая выполнять операции последовательно.

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

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

Хотите увидеть, как живое Spring Boot‑приложение проходит путь от репозитория до кластера Kubernetes? В статье пройдем путь от создания простого HealthController до автоматического деплоя через CI/CD. Разберём Dockerfile без магии, манифесты Deployment с пробами, настройку ресурсов и изящный Graceful Shutdown. В финале вы получите живую связку «код — контейнер — кластер», готовую к продакшену.

Почему Kubernetes стал стандартом оркестрации контейнеров? Разбираем архитектуру без скучной теории: Control Plane, поды, сервисы, деплойменты — на реальных примерах. Вы узнаете, как избежать типичных ошибок, увидите опыт миграции Tinder и получите лучшие практики, которые применяют ведущие команды.

Статья для тех, кто хочет не просто знать команды kubectl, а понимать, как проектировать отказоустойчивые платформы

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

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

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

Часть 1: Вводная и формирование ТЗ -> вы здесь
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло

Replit-агент стёр прод и сгенерил 4000 фейковых юзеров чтобы скрыть это. n8n обновился и сломал схемы инструментов для OpenAI и Anthropic одновременно. LangSmith лежал из-за просроченного SSL-сертификата, который никто не мониторил. Пять уроков из реальных инцидентов. И ни один не про LLM.

История инцидента в продакшене: после планового релиза новая версия сервиса не поднялась, а откат на предыдущую версию тоже не помог. Причина оказалась не в коде, а в расхождении между тем, что было описано в Git, и тем, что реально жило в Kubernetes. Ручная правка ConfigMap несколько месяцев существовала только в кластере, пока очередной релиз не пересоздал поды и не вытащил проблему наружу. Разбираю, как мы нашли причину, почему Git не был настоящим источником правды и зачем после этого перешли на GitOps с Argo CD.

На прошлой неделе мы писали о том, как скармливали терабайты CI-логов LLM. Большинство вопросов на Hacker News касались не самих логов — спрашивали про агента: какие модели, как они взаимодействуют и во сколько всё это обходится.

Сейчас мы работаем на Opus 4.6 и платим меньше, чем когда всё крутилось на Sonnet 4.0.

Причина в основном в том, чего Opus не делает: 80% сбоев до него не доходят, а когда доходят — он не читает ни одной строки лога.

Архитектура выглядит так...

Когда речь заходит про автотесты, первыми на ум приходят проверки для UI, API или для мобильных устройств. Однако автотесты нужны не только для проверки пользовательских сценариев. Они могут решать и менее очевидные, но не менее важные задачи, например проверять работу пайплайнов. Если одни и те же пайплайны используют сотни сервисов и библиотек, любая ошибка в них быстро выходит за пределы одного проекта. У многих команд одновременно могут сломаться сборки, релизы и привычный процесс разработки. В нашем случае такие пайплайны работали примерно для 700 сервисов и более 200 библиотечных репозиториев. Чтобы гарантировать работоспособность пайплайнов, мы пришли к идее покрытия их автотестами.

В статье я расскажу, как мы в Ozon покрывали тестами работу пайплайнов в GitLab CI, какие требования нужно было учесть и как в итоге были устроены end-to-end-тесты для таких сценариев.

Привет! Меня зовут Андрей Пахомов, я разработчик в AI Platform Битрикс24. Сегодня расскажу, почему self-hosted LLM ломается в проде, где на самом деле возникают проблемы и какие метрики помогают вовремя это увидеть.

Flux CD — это набор инструментов для GitOps в Kubernetes. Он следит за Git-репозиторием и автоматически приводит состояние кластера в соответствие с описанными в нём манифестами и Helm-чартами. Flux работает как контроллер внутри кластера: подтягивает изменения из Git, применяет их через Kubernetes API и отслеживает статус каждого ресурса. Проект является graduated-проектом CNCF.

Когда вы впервые поднимаете GitOps в Kubernetes, Flux CD кажется достаточным: flux bootstrap, манифесты в Git, контроллеры тянут состояние кластера.

Но лучше перейти на Flux Operator:

Знаете, кому 29 апреля стукнуло 30 лет? Спецификации FastCGI. Тридцать лет с 1996 года. Погодите. Эта заметка не про ностальгию по .fcgi-скриптам, которые на каждый запрос форкали отдельный процесс и которыми сегодня никто не пользуется. И не про CGI вообще.

Разговор о другом. У нас всех в проде между прокси и бэкендом обычно стоит HTTP. nginx перед Go-приложением, Caddy перед Python-сервисом, Apache перед PHP-FPM, неважно, поверх там HTTP/1.1 или HTTP/2. И вот Эндрю Айер на agwa.name к юбилею FastCGI собрал аргументы, что этот участок инфраструктуры всё это время сидит на не самом удачном протоколе. Айер основатель SSLMate, и в SSLMate всё крутится на FastCGI в проде уже больше десяти лет. Так что пишет не теоретически.

Заметка короткая и по делу. HN-тред собрал сотню комментариев, для 2026 года это не топ, но там пишут люди, которые знают, о чём говорят. Если попроще, аргумент такой: у HTTP как протокола между прокси и бэкендом есть два структурных бага, которых у FastCGI нет, и индустрия за тридцать лет так и не нашла повода переехать. А обсуждение в треде ушло дальше: почему вообще HTTP победил, если он хуже технически. И ответ оказался любопытнее самого аргумента.

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.

Анализ DNS-снэпшота OpenINTEL за 2026-01-01

TL;DR. Используя ежедневные DNS-снэпшоты OpenINTEL поверх списка Tranco top-1M, мы собрали ландшафт email-инфраструктуры публичного веба на 1 января 2026 года. MX-записи опубликовали 660 114 доменов, SPF — 616 352, DMARC — 431 133. Дуополия Google Workspace (21.7%) + Microsoft 365 (16.3%) занимает суммарно ~38% receiving-стороны — заметно меньше, чем принято считать в популярных обзорах. На outbound-стороне Amazon SES вышел вперёд по числу авторизованных доменов (5.86%), обогнав SendGrid (4.66%). DMARC опубликован у двух третей SPF-доменов, но 19% всех DMARC-записей — это пустая v=DMARC1; p=none; без отчётов: формальная галочка, а не защита.

Всем привет. В этой статье расскажу о новостях касаемо Loki. О том что было представлено на GrafanaCON 2026 в Барселоне. Чего нам ждать от новой архитектуры Loki, как она будет работать, и что прячет под капотом.

Всем привет! Храню 7 терабайт фото и видео у себя дома на Synology DS224+ с DSM 7.3+

Это сетевое хранилище поддерживает Docker. Я дополнительно установил плашку памяти и теперь у меня 18 ГБ ОЗУ.

Но суть в том, что ночами я слышу "булькание" и "шуршание" дисков, кстати диски красные, прямо созданные под сетевые хранилища: WD120EFBX-68B0EN0 две штуки по 12 ТБ с зеркалированием.

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

Выложил проект в репозиторий

Infrastructure as Code научила нас важной дисциплине: инфраструктура не должна жить только в голове. Ресурсы, настройки и изменения надо описывать, хранить в Git, применять повторяемо и обсуждать как код.

Это все еще правильная мысль. Terraform хорошо описывает ресурсы. Ansible хорошо описывает действия. CI/CD хорошо описывает путь изменения от репозитория до рабочей среды. Мониторинг хорошо ловит симптомы.

Но когда в эксплуатацию входит ИИ-агент, появляется новый вопрос: что агент должен понимать перед действием?

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

Я называю этот слой AgentOps.

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

Итак, вы обучили модель и она показывает ожидаемые результаты. Теперь осталось выкатить её на контур, однако для этого необходим ряд компонентов: нужна маршрутизация трафика, непосредственно инференс. Желателен autoscaling модели, передача чувствительных данных, например креды до хранилища моделей. Ну и мониторинг не помешал бы.

Каждый компонент - это отдельный Helm-чарт, отдельные CRD и отдельная документация. В итоге, вместо быстрого тестирования модели и гипотез, приходится заниматься YAML-инжинирингом и громко ругаться благим матом.

Всем привет, на связи Пётр, инженер компании Nixys. В этой статье я покажу, как собрать полноценный inference-контур из пяти Kubernetes-операторов в одном values.yaml размером в 120 строк, используя nxs-universal-chart.

Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE.

Copy Fail как примитив Process Injection через Page Cache

Оригинальный PoC модифицирует setuid binary перед execve и получает root.
Второй публичный PoC подменяет id у текущего юзера на 0000.

Хорошие, рабочие LPE, дающие рута.

Но исследуя дополнительные свойства этого примитива я обнаружил несколько эффектов, не описанных в оригинальном disclosure.

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

Привет! Меня зовут Даниил Ткаченко, я веб‑разработчик в ИТ‑компании «Активика». В статье я поделюсь опытом развёртывания Sentry self‑hosted для высоконагруженного проекта. Несмотря на обилие материалов по SaaS‑версии, актуальных гайдов по self‑hosted‑установке почти нет — особенно с учётом современных требований к производительности и отказоустойчивости.

Мы столкнулись с рядом проблем: нестабильностью на базовом хостинге, отсутствием перехвата HTTP‑ошибок и быстрым заполнением диска. Под катом разберу каждую проблему, покажу код решений и дам рекомендации для тех, кто планирует развернуть Sentry самостоятельно.

Статья будет полезна разработчикам и DevOps‑инженерам без опыта работы с self‑hosted Sentry.