DevOps *

Привет! На связи команда Yandex Monium, это вторая часть серии про эффективный мониторинг. Исторически Monium был разработан командой Yandex Infrastructure как внутренняя observability‑платформа и использовался для мониторинга критических сервисов внутри Яндекса. В прошлый раз мы рассказали о том, что важно знать про мониторинг в целом, а также рассмотрели подробнее асинхронные задачи. На примере кейса с таинственным зависанием задач мы увидели, как с помощью метрик можно определить не очевидную проблему, вызванную скрытым багом. 

Но вполне возможно, что у вас всё взаимодействие происходит через очереди, а не через асинхронные задачи. Далее в этой статье:

— В первой части разберём кейсы на примере in‑memory‑очереди. Это также применимо для различных типов очередей, в том числе для Apache Kafka. 

— Во второй части перейдём к клиент‑серверному взаимодействию.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

Привет! Меня зовут Вероника, я руководитель проекта по разработке ГИС. Эту статью мы писали вместе с Евгением — нашим DevOps-инженером, который отвечает за CI/CD, релизы и за то, чтобы наши обновления не превращались в ночной кошмар.

…

Однажды темным хмурым вечером в ожидании очередного деплоя я имела неосторожность задеть DevOps-инженера вопросом: «Что ты там часами делаешь, тебе же всего одну кнопку надо нажать?». Он объяснил, что это не совсем так. Я предложила:

— А давай сделаем одну «большую зеленую кнопку», которая все сама задеплоит?

— Технически можно, но…

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

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

Недавно на глаза попалась интересная статья про новый проект TeleMT. И я бы наверно не стал заморачиваться. И тоже настроил бы его за 5 минут. По шагам из статьи. Если бы не пара "но". Во-первых, я болен хроническим неприятием засовывания докера где следует и где не следует. А во-вторых – 443 порт на моем подопытном сервере уже занят предыдущим "экспериментом".

На нестандартный порт вешать второй "эксперимент" мне не хотелось. Покупать второй айпишник или хостинг – тем более. Требовалось сотворить чутка новой дичи магии. О результатах сего докладываю в этой статье. Вдруг кому-то пригодится.

В 2026 году выбор AI-инструмента для бизнеса — это уже не сравнение бенчмарков, а управление рисками. Зарубежные облачные сервисы работают в условиях управляемой нестабильности: ТСПУ деградирует соединения, Cloudflare теряет трафик, а ПП РФ №1667 закладывает инфраструктурную основу для перехода к «белым спискам» IP. Разбираем правовую и сетевую карту рисков для каждой категории AI-сервисов — и объясняем, почему self-hosted модели в 2026 году стали не нишевым решением для параноиков, а базовым требованием к Enterprise-архитектуре.

Сейчас очень часто в вакансиях на ДевОпс ищут людей которые, понимают и могут в Helm чарт.

Как правило, собеседование это не просто экзамен знаю/не знаю - это еще и проверка на понимание принципов работы какой-то технологии, умение решать задачи.

Я решил поделиться с вами своим опытом и понял что тут как никогда пригодится метод понимания процессов через визуализацию. О принципах работы метода «Дворца памяти» можно прочитать тут же на Хабр.

Привет, друзья!

Сегодня поговорим о кластерном режиме в Pilot – линейке продуктов, на базе которых организуют совместную работу над строительными проектами, сборку и проверку BIM-моделей.

Кластерный режим Pilot обеспечивает отказоустойчивость и горизонтальное масштабирование её центрального компонента — Pilot-Server. Для хранения данных в кластере используется PostgreSQL, а для взаимодействия между узлами — Redis.

Примечание: На данный момент кластеризация доступна только для Pilot-Server. Pilot-BIM-Server и Pilot-Web-Server работают как отдельные сервисы без возможности горизонтального масштабирования.

Какие преимущества мы получаем по сравнению с подходом, где используется один компонент Pilot-Server?

1. Аппаратный сбой на сервере Pilot-Server. При падении машины, на которой расположен единственный экземпляр Pilot-Server, работа пользователей парализуется, никакие действия с системой в режиме онлайн невозможно совершить. При нескольких компонентах на разных серверах, в случае падения одного из них, мгновенно назначается новый активный узел из оставшихся рабочих. Для пользователей это будет кратковременный разрыв соединения, после которого они переподключатся к новому узлу.

2. Обновление ПО. При обновлении Pilot-Server с единственным экземпляром, пользователи не могут подключаться в этот момент. В кластерном режиме обновление можно произвести в режиме “Последовательного обновления”.

3. Рост нагрузки на Pilot-Server. Большое количество запросов к одному компоненту Pilot-Server может превысить пропускную способность одного сервера. В кластерном режиме за счёт нескольких узлов с Pilot-Server  нагрузка будет распределяться между ними через балансировщик.

В нашем сообществе уже не первый день живёт агент @vega_exactly_not_ai.

Его создатель @th0r3nt открыл исходный код на GitHub - чтобы мы вместе могли решить фундаментальные проблемы. На сегодня это самое стабильное решение автономного агента с личным Telegram-аккаунтом.

Создатель попросил рассказать об архитектуре и поставить ряд вопросов перед сообществом. Думаю, вместе мы способны разобраться.

Большинство современных Open-Source фреймворков для создания ИИ-агентов (от AutoGPT до недавнего OpenClaw) страдают от ряда детских болезней. Во-первых, это амнезия: агент теряет контекст спустя десяток шагов, так как векторные базы данных превращают память в кашу из семантически похожих, но логически не связанных кусков текста. Во-вторых, это зацикливание в бесконечных ReAct-петлях. В-третьих - ужасная безопасность при выполнении сгенерированного кода прямо на хостовой машине.

В этой статье я хочу разобрать архитектуру Autonomous Agent Framework (AAF) - моего pet-проекта, который перерос в полноценную OS-level сущность на Python.

Главная идея AAF: агент не должен быть просто скриптом, ожидающим промпта. Это должен быть долгоживущий асинхронный процесс с гибридной памятью, шиной событий и собственной изолированной средой для запуска субагентов.

Продолжаем наши обзоры плагинов к GIgaIDE. Первая статья здесь, последняя доступна по этой ссылке. На этот раз в нашем обзоре — плагины Docker и Remote, доступные в версии GigaIDE PRO и обновляемые с маркетплейса.

Начнём с рассказа про плагин Docker.

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

KeeneticOS из коробки закрывает большинство бытовых задач, но как только появляется требование рулить трафиком по-своему, быстро упираешься в нюансы. Я собрал рабочую схему на Keenetic Hopper: Entware + Xray-core (TUN) + policy-based routing через fwmark и отдельную таблицу маршрутизации. Главный фокус на эксплуатации, я покажу минимальный чек-лист диагностики, и как сделать конфигурацию самовосстанавливающейся, чтобы больше никогда не залазить руками. Статья - практическая инструкция: команды, конфиги и понятные критерии.

Вам точно нужен только HTTP-мониторинг? А как насчёт проверки, что DNS резолвится правильно, SMTP-сервер принимает почту, а Minecraft-сервер отвечает на handshake? В PingZen мы добавили 22 протокола, включая Transaction с Playwright, чтобы вы могли мониторить буквально всё. Рассказываю, зачем это нужно и как работает «под капотом».

Иногда нужно получить SSH-доступ к домашнему серверу (ноутбуку или мини-серверу на Ubuntu), который находится за NAT/CGNAT провайдера. Публичный IPv4 отсутствует, а использовать VPN или облачные туннели (ngrok, Cloudflare Tunnel и т.п.) не хочется.

Один из простых способов — обратный SSH-туннель с помощью autossh + проксирование через уже существующий Xray-клиент (VLESS + Reality), который и так работает для выхода в интернет.

Привет! Это команда Яндекс Практикума, сегодня мы вместе с вами рассмотрим, что из себя представляет DevOps в 2026 году и расскажем про онлайн-магистратуру ИТМО в партнёрстве с Яндекс Практикумом «DevOps‑инженер облачных сервисов»: кому подойдёт программа, как поступить в 2026 году, какие навыки вы будете изучать, какие у вас будут перспективы в этой области и при чём тут искусственный интеллект.

OpenClaw очень просто для быстрого старта. После openclaw onboard у тебя работает Gateway и один агент отвечает в Telegram. Но дальше начинается самое интересное — и самое неочевидное: как устроен openclaw.json, что из workspace-файлов реально попадает в контекст, как включить heartbeat так, чтобы он не превратился в генератор мусора и расхода токенов, и как правильно разнести нескольких агентов по чатам и топикам.

Документация OpenClaw покрывает это фрагментарно, а большинство гайдов заканчиваются на «поставил — работает». Этим туториалом постараемся закрыть следующие шаги: разбираем конфиг секция за секцией, показываем рабочие примеры для Telegram, bindings, session policy и multi-agent — всё, что нужно, чтобы перейти от одного бота в личке к нормальной продакшн-конфигурации.

OpenCost — open-source проект для расчёта и визуализации стоимости ресурсов в Kubernetes. Он агрегирует данные об использовании CPU, памяти и диска (ноды, поды, PVC), применяет к ним тарифы и даёт метрики и API для отображения затрат по namespace, deployment, label и т.д. Изначально создан в Kubecost, затем выделен в отдельный проект под CNCF; поддерживает кастомные цены и интеграцию с разными облаками и он-прем-кластерами.

Привет! Меня зовут Карина, я QA-инженер в hh.ru. Наша компания растёт, а вместе с ней — число команд, вовлечённых в разработку и функционал. Появляются новые сервисы, базы данных, очереди. Каждый компонент требует слаженной работы и надёжной поддержки на тестовых стендах.

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

Я спроектировал архитектуру команды из 9 ИИ-агентов, которая проектирует, пишет, тестирует и деплоит других ИИ-агентов. Стоимость — от одной RTX 4090 до кластера A100.

Не бывает «лучшей модели» — бывает лучшая модель для конкретной роли. Оркестратору нужен reasoning (GPQA 88.4%), билдеру — кодогенерация (HumanEval 92.7%), критику — понимание tool use (tau-bench 87.4%). Поэтому вместо одного GPT-5 на все задачи — 6 open-source моделей на 9 ролей.

Внутри: конкретный маппинг модель → роль с обоснованием через бенчмарки, трюк с шарингом инстансов (9 агентов = 3-4 модели), три конфигурации развёртывания от одной RTX 4090 (24 GB) до кластера A100 (211 GB), честное сравнение self-hosted vs. API, квантизация, инфраструктура инференса и интерактивный дашборд.

Kubernetes полюбился разработчикам своим удобством: описал развертывание, в любой момент изменил параметры — и все работает. Но вот раскатка самих кластеров долгое время оставалась лоскутным одеялом: Terraform, Ansible, десятки плейбуков и пайплайнов. Потерял стейт — и начинается квест. 

Cluster API (CAPI) закрыл этот разрыв и за последние годы стал едва ли не стандартом для управления Kubernetes-кластерами. Он превратил развертывание и сопровождение инфраструктуры в такой же декларативный процесс, как деплой приложения.

В нашей платформе «Штурвал» мы уже давно используем Cluster API в продакшене. И довольно быстро стало понятно: это не просто удобный способ развернуть Kubernetes, а смена парадигмы эксплуатации. Но вместе с предсказуемостью приходят новые сложности — от обновлений управляющей плоскости до нетривиальных сценариев отказа. В этой статье разберемся, чем хорош Cluster API, а в чем его подводные камни, о которых обычно узнают уже в ходе эксплуатации.