DevOps *

Это первая статья из цикла о том, как я пытался сделать алерты 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.

MCP-серверы не умеют в авторизацию, n8n не умеет в per-user токены, а OAuth-клиенты говорят на разных диалектах. Рассказываем, как один Auth Proxy перед FastMCP Gateway закрыл все три проблемы — и почему в итоге бот переехал на LangGraph

У меня несколько аккаунтов Claude Code. Не из любви к роскоши, а потому что у Anthropic есть недельные ограничения на использование, и когда активный аккаунт упирается в них, я просто переключаюсь на следующий.

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

Можно ли его сделать так, чтобы старые сессии не терялись из видимости? Хотя бы найти где они физически живут.

То что я нашла, оказалось интереснее ожиданий. На жёстком диске 48 мегабайт истории работы с Claude, разбитой по шести папкам. В окне приложения у меня видно 69 сессий из 715. Остальные на диске, доступны для cat/grep/Python, но через приложение полностью невидимы.

Что под капотом, где они лежат, как вернуть, и почему любой инструмент миграции сейчас имеет срок годности.

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

В одно время между парами по актерскому и сценречью у нас образовался перерыв в несколько часов, и зумерши притащили небезызвесную игру «Шпион». Реализована она была на минималках даже для web-а из 90-х: нужно было внести список играющих, а потом передавать смартфон по кругу для получения персональной инфы. Интерфейс текстовый.

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

Вопросы могут быть самыми разными: Это на улице или в помещении? Это для детей или взрослых? Можно ли на этом ездить? Это едят? И т. д.

«Шпион», при всей кажущейся его простоте забавлял нас много дней. Но мне, как айтишнику со стажем большим, чем те, с кем я учусь, было дико видеть, как для игры, явно претендующей на сетевую, нужно передавать чей-то смартфон из рук в руки. Так получилось, что я в это время активно работал над своим LOTIS, о котором писал здесь уже. И вот в какой-то из вечером я сделал сетевого шпиона, чем несказанно удивил своих коллег, будущих актеров. Заодно и протестировал LOTIS в режиме чата.