DevOps *

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

Сегодня поговорим о кластерном режиме в 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, а в чем его подводные камни, о которых обычно узнают уже в ходе эксплуатации.

Настройка OpenClaw — это один JSON5-файл и CLI на сотню с лишним команд. Документация разбросана между официальным справочником, GitHub issues и постами сообщества. Собрали всё в одном месте: структура конфигурации, управление шлюзом, модели, каналы, песочница, горячая перезагрузка, переменные окружения и безопасное хранение секретов.

Что происходит с инженерной практикой, когда код в проекте пишет не человек, а агент, а команда занимается средой, ограничениями и контурами проверки? В этом тексте — разбор реального эксперимента OpenAI, где внутренний продукт собирали через Codex почти без ручного кода: с собственными правилами для агентов, архитектурными инвариантами, наблюдаемостью, документацией внутри репозитория и постепенным ростом автономности. Это любопытный взгляд на разработку в режиме, где главным дефицитом становится уже не скорость написания кода, а человеческое внимание.

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

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

Сервер внезапно перестал отвечать, а в логах ошибка Too many open files? Дело не в нехватке памяти или перегруженном процессоре — просто ваш процесс исчерпал свои файловые дескрипторы. Под катом расскажу, что это такое, почему они заканчиваются, как быстро обнаружить проблему и как её пофиксить.

OSPF, BGP, VLAN, ACL — вы знаете их как свои пять пальцев. А потом приходит Kubernetes и предлагает «просто описать желаемое состояние в YAML». Звучит как магия? На самом деле под капотом K8s работают всё те же сетевые протоколы, просто теперь их настраивает не инженер с консолью, а код в репозитории. Эта статья — мост между классической сетевой инженерией и миром контейнеров. Без маркетинга, только факты: veth-пары, BGP-пиринги Calico, DNAT в iptables и почему ClusterIP не пингуется.

В этой статье разбираются все случаи, когда под в кластере может исчезнуть сам — без kubectl delete и без вашего ведома. Перезапуск kubelet, нехватка памяти, taint с эффектом NoExecute, высокоприоритетный под в очереди планировщика — любой из этих сценариев способен остановить под, даже если вы настроили плавное завершение.

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

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

Что если переход на локальную инфраструктуру (вроде Ollama) это решение, которое не просто поможет сэкономить, но изменит саму динамику разработки?