DevOps *

Я не программист. По крайней мере, несмотря на то, что в 2010 году я закончил «Прикладную информатику в менеджменте» (ДГТУ) и учился писать на C++, таковым в настоящее время себя не считаю.

При этом с июля 2026 года я управляю большим продуктом (собственная фабрика аналитики, своего рода ERP внутри компании), код которого пишут ИИ‑агенты. Я даю задачи голосом (не помню, когда в последний раз формировал текст задач на клавиатуре), агенты пишут код, проверяют его и выкладывают новую версию на сайт. Продукт собран на Next.js 16, TypeScript и PostgreSQL. На 1 октября в истории проекта уже более 6500 коммитов и 1.800.000 строк кода.

Код я не читаю. Поэтому между словом агента «готово» и появлением новой версии на сайте стоят автоматические проверки. Их называют «сторожами», сейчас их около двухсот. Если хотя бы один сторож покраснел, новая версия не попадает на сайт, а я получаю в Telegram сообщение «выкат остановлен» со списком красных.

Так я узнаю, готов ли продукт. И несколько раз эти проверки говорили неправду. Ниже пять примеров: что случилось, как мы это заметили и что изменили.

За последние дни Anthropic забанило много аккаунтов. Моё предположение: под бан попали аккаунты, на которых светился российский IP и часовой пояс компьютера

Я настроил Claude Desktop и Claude Code так, чтобы запросы всегда уходили с одного IP своего VPS через CLIProxyAPI.

В статье показываю как это настроить: сервер, вход через OAuth, Desktop и Claude Code. Для каждого шага есть промпт для агента и ручная инструкция:)

Облачные платформы, как правило, выглядят одинаково пугающе: открываешь консоль, а там десятки сервисов, виртуальные сети, Kubernetes, базы данных, IAM, какие-то шлюзы… Вообще непонятно, что там делать, — прямо как при первом заходе в «Битрикс».

Мне по долгу службы выпала возможность поработать через MWS Cloud Platform, и я решил изучить ее как нормальный человек (а не от корки до корки по документации): поставить конкретную задачу и пройти весь путь самому. Сегодня миссия простая: взять готовую LLM в облаке, развернуть ее и начать отправлять ей реальные запросы со своего компьютера.

Если вам нужна LLM как часть своего инструмента, а не как очередной чат-бот, приложение, рабочий скрипт или AI-агент, ее нужно где-то запускать и как-то подключать. GPT Model Hub как раз позволяет взять готовую модель и получить к ней API, не разворачивая всю инфраструктуру самостоятельно.

Поэтому в этом обзоре пройдем путь от первого входа в аккаунт до рабочего Qwen: подключим биллинг, создадим деплоймент, получим API-ключ и заведем модель в VS Code. Этим материалом я запускаю цикл обзоров на большой продукт MWS Cloud Platform.

Поехали!

Как спрятать реальный IP сервера?

В первой части серии разбираемся с iptables: как устроены таблицы и цепочки netfilter, что происходит с пакетом на пути от клиента до бэкенда и как с помощью DNAT/SNAT организовать простой прокси-узел. Покажем рабочую конфигурацию для HTTPS, TCP и UDP, разберём типичные проблемы с FORWARD, conntrack и маршрутизацией, а главное — выясним, почему простой NAT не позволяет одновременно скрыть IP сервера и сохранить реальный IP клиента. В конце сравним подход с nftables и разберём, в какой момент iptables перестаёт подходить для цепочки прокси.

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

У нас на этом месте оказался я — единственный администратор примерно на 60 сотрудников. Агенты сотрудников писали мне письма, я пересылал их своему агенту и отправлял ответ обратно. Пользователи шутят, что мы стали прокладками между несколькими ИИ.

В статье — как мы пришли к профильному ИТ-суперагенту, как он устроен внутри (MCP, два RAG-источника, права, проверки на серверах, эскалация в мессенджер) и на какие грабли наступили. Это не продукт и не реклама — рабочий прототип, который сейчас крутится в пилоте.

Часть вторая по использованию ИИ в сложной работе devops. Первая доступна по ссылке

Жду ваших коментариев и дополнений

Вспомните свой обычный рабочий день: три терминала, Lens, вкладки с Grafana, Argo CD и GitLab, KeePassXC, Obsidian с ранбуками, DBeaver, WinBox для роутеров и где-то среди всего этого — чат с ИИ. Алерт прилетает в Telegram, команду из ранбука копируешь руками, пароль ищешь в третьем окне. Мне надоело собирать себя по кусочкам каждое утро, и я сделал OpsDeck — бесплатное приложение с открытым кодом, в котором всё это живёт вместе и знает друг о друге. Ниже — экскурсия по каждому разделу со скриншотами.

В первой части я рассказывал, как мы дошли от обычного копирования кода между MODX и ChatGPT до нормального предметного интерфейса к CMS. Агент перестал видеть сайт как россыпь файлов и строк в базе и получил возможность работать с ресурсами, чанками, TV и зависимостями между ними. В какой-то момент этого стало достаточно, чтобы ставить задачу примерно так же, как я поставил бы её разработчику, без подробной инструкции, куда именно залезть и какую строку там поменять.

Следующий шаг напрашивался сам собой. Если агент уже разобрался в проблеме и нашёл решение, какого чёрта я должен брать его код, подключаться по SSH, делать резервную копию, заливать исправление, запускать проверки и потом ещё ходить по сайту смотреть, не отвалилось ли что-нибудь рядом. Хотелось просто написать «Посмотри, почему форма перестала отправляться, исправь и проверь» и получить в ответ не инструкцию из десяти пунктов, которые мне потом самому предстоит выполнить, а уже исправленный сайт.

Вот на этом месте и началась вторая часть нашего проекта. Сам доступ на запись дать оказалось совсем несложно. К MODX MCP добавились SSH, физические файлы, логи, браузер и несколько служебных инструментов. Гораздо больше времени ушло на то, чтобы после команды «исправляй» не сидеть у агента за спиной и не следить, что именно он там сейчас собирается натворить.

Эта статья - о шаге, который предшествует настройке маршрутов: как выбрать сигнал, связать его с влиянием на бизнес, определить срочность и проверить, что вызов дежурного действительно оправдан. В качестве сквозного примера возьмём оформление заказа, а в конце свяжем правила детектирования с обработкой в nxs-anomaly.

Практика к первой части серии «Kubernetes просто». Поднимем локальный кластер с помощью kind, найдём компоненты Control Plane и запустим первый Pod. Разберём команды и их вывод, а затем закрепим материал самостоятельными заданиями.

Можно годами работать с Kubernetes, писать манифесты и разбираться с падениями подов – и всё равно смутно представлять, что именно происходит внутри системы. Я решил закрыть этот пробел радикально: собрал собственный оркестратор Smith и по ходу разработки столкнулся с теми же проблемами, которые когда-то сформировали архитектуру Kubernetes.

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

В мае 2026 ИИ-агент попросился в любительскую сеть DN42, чтобы “создать индекс сети”, и заодно сообщил о пяти инстансах AWS по 20 Гбит/с, уже запущенных и ждущих допуска. Заявку в сеть так и не приняли, зато затянули взаимодействие на сутки: субагент принимал индивидуальные OPT-OUT, но отказался исключить всех сразу, сайт агента вел профили участников, а в реестр прилетел документ про “уровень счастья ноды”. Закончилось заявленным счетом на $6531 и просьбой о пожертвованиях. Пересказ истории Lan Tian, голоса Hacker News и мои выводы о том, какие гейты ставить агенту на деньги, ресурсы и необратимые действия.

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

В экспериментах с Linux и gVisor встретились три ситуации. Механизм ограничения отсутствует, для его настройки не хватает прав или настройка проходит успешно без ожидаемого эффекта. Даже загруженная и подключённая программа фильтрации не всегда что-то фильтрует. Показываю результаты, ошибки собственных проверок и подход, который помогает проверить ограничения до запуска инструмента агента.

Привет, Хабр! Под эгидой AOT мы проводим конференции для сообщества вокруг Kubernetes. На Kuber Conf от АОТ в 2025 году у нас выступал Михаил Петров, Kubernetes-эксперт в Stackland (Yandex Cloud). Для тех, кто любит смотреть видео — держите ссылку. 

А ниже — текстовая версия доклада в изложении Михаила.

---------

В целом кубером я занимаюсь вот уже почти 10 лет и за это время построил десятки продакшн-кластеров в VK и не только. В Yandex Cloud мы сейчас разрабатываем onprem-решение для запуска ИИ- и дата-нагрузок на базе Kubernetes и Talos OS.

В этой статье расскажу вам, как внедрить в ваши Kubernetes-кластера CNI Chaining — обсудим, когда это вообще полезно и применимо, какие плюсы несёт и с какими сложностями можно столкнуться в процессе.

Представьте: два часа ночи, вы деплоите фикс — а сервис не поднимается: Address already in use. Гуглите, находите PID, делаете kill -9. Помогает. Но утром та же ошибка на том же порту.

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

Разбираем оба случая: быстрый фикс под Linux, macOS, Windows и Docker — и что на самом деле происходит с портом, когда процесса уже нет.

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

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

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

Привет, Хабр! На связи Егор Сапун, руководитель направления сертификации инфраструктуры Рег.облака.

Кибератаки касаются не только крупного бизнеса. За последний год с киберинцидентами столкнулись 82% российских компаний малого и среднего бизнеса. По данным Positive Technologies, в 2025 году 75% успешных атак на веб-приложения российских организаций приводили к нарушению их деятельности.

От части атак на сайты, веб-приложения и API защищает WAF. Но для многих компаний это все еще enterprise-решение: классический WAF необходимо развернуть в своей или арендованной инфраструктуре, встроить в путь трафика. Для этого нужны вычислительные ресурсы а также компетенции по настройке и сопровождению. У небольших компаний таких ресурсов может и не быть.

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

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

Привет, Хабр! Меня зовут Антон Алексеев, я ML Ops-инженер в Авито.

В этой статье я разберу, почему существующий PaaS — отличный инструмент для веб-сервисов, но плохо подходит для ML/LLM-Inference, и с какими похожими проблемами сталкиваются крупные компании, у которых те же задачи.

Также расскажу, почему было принято решение не дорабатывать PaaS под Inference, а строить отдельную Inference-платформу на базе готового open-source ядра, и почему этот путь оказался предпочтительнее.

AI-ревьюер для GitLab, который проверяет не отдельный merge request, а всю задачу сразу, во всех сервисах, которые она задела. И почему для этого понадобился агент, а не анализ diff через API.

if roc_auc < 0.85: exit 1 — примерно так выглядит quality gate почти в каждом ML-пайплайне, который мне попадался. В обычном CI то же самое — количество проблем в Sonar и код выхода тестов.

Я видел, как приложение проходило весь пайплайн, выкатывалось в прод, и через 2 часа бизнес срочно требовал отката из-за неработоспособности важного функционала.

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

Дальше семь способов, которыми гейт пропускает брак в прод. Там будет и утечка между train и test, и старый добрый || true в .gitlab-ci.yml. По каждому посмотрим реальный кейс с цифрами.