kagent — это open-source платформа с открытым исходным кодом, которая привносит «агентный» искусственный интеллект в облачные и Kubernetes-среды. Если говорить проще, она позволяет создавать интеллектуальных агентов, которые понимают запросы на естественном языке и автономно выполняют сложные операции по управлению инфраструктурой: диагностируют проблемы с сетью, анализируют логи, управляют развертываниями. https://kagent.dev

kagent был создан компанией Solo.io в 2025 году и является sandbox-проектом CNCF (Cloud Native Computing Foundation). Его главная идея — превратить AI-агента из простого чат-бота в полноценного участника DevOps- и платформенных процессов, управляемого теми же инструментами, что и остальные рабочие нагрузки в кластере.

🎯 Что дает kagent и как он работает

Ключевые возможности

• Управление как кодом (GitOps): Агенты определяются как обычные Kubernetes-ресурсы (Custom Resources). Вы можете версионировать их, применять через `kubectl` и управлять ими так же, как и любыми другими компонентами инфраструктуры.
• Автоматизация рутины: Агенты самостоятельно выполняют многошаговые задачи по устранению неполадок и мониторингу, снижая нагрузку на специалистов.
• Гибкость и отсутствие привязки: kagent поддерживает множество LLM-провайдеров (OpenAI, Anthropic, Gemini и другие), а также любые OpenAI-совместимые эндпоинты, что позволяет использовать практически любую модель, включая вашу собственную.
• Интеграция с инструментами: Агенты могут использовать широкий набор инструментов (Tools) через Model Context Protocol (MCP) для взаимодействия с системами: просмотр логов подов, запросы к Prometheus, управление ресурсами Kubernetes и многое другое.
• Human-in-the-loop: Встроенные механизмы подтверждения действий, когда агент предлагает изменить ресурс, но ждет одобрения человека, а также поддержка инициативных вопросов от агента.
• Долговременная память: Векторная память, позволяющая агентам помнить контекст между сессиями, а не только в рамках последнего запроса.
• Agent-to-Agent (A2A): Агенты могут обнаруживать друг друга и вызывать, что позволяет строить многоагентные рабочие процессы с делегированием задач.

Архитектура

Архитектура kagent состоит из трех основных компонентов:

1. Tools (Инструменты): Это «руки» агента — набор функций, которые агент может вызывать для выполнения реальных действий в инфраструктуре. kagent поставляется с предустановленными инструментами для отображения логов подов, запросов к Prometheus, генерации ресурсов и многого другого.
2. Agents (Агенты): Это «мозг» системы — автономные системы, которые планируют, выполняют и анализируют задачи, используя доступные инструменты. Вы описываете агента в YAML-файле, указывая его системный промпт (роль), модель LLM и список инструментов, к которым у него есть доступ. Агенты могут объединяться в команды, где планирующий агент распределяет задачи между исполнителями.
3. Framework (Фреймворк): Гибкий интерфейс, позволяющий запускать агентов как через UI, так и декларативно. Он построен на фреймворке Google ADK, но также поддерживает LangGraph, CrewAI и собственные фреймворки.

🐳 Практический пример: запуск kagent в Podman на macOS

Перейдем от теории к практике. Наш тестовый агент `myagent` был успешно запущен локально на MacBook (Intel) с использованием Podman. Он продемонстрировал возможность вызова инструментов (Tool Calling) и ведения диалога на русском языке.

Ключевые шаги развертывания

1. Подготовка окружения: Установка Podman и `podman-compose`, а также создание скрипта-обертки `docker-compose`, который перенаправляет вызовы в `podman-compose`, поскольку kagent ожидает наличия именно этой утилиты.
2. Создание проекта агента: Генерация структуры проекта командой `kagent init adk python myagent`.
3. Настройка базового образа: В `Dockerfile` базовый образ был заменен на `kagent-adk:0.10.4-full`, так как distroless-вариант не содержит оболочки `/bin/sh`, необходимой для выполнения команд установки зависимостей. Также был добавлен шаг `RUN uv pip install “google-adk[extensions]”` для поддержки LiteLLM и указана переменная `ENV PYTHONPATH=/app`.
4. Конфигурация подключения к LLM: В файле `agent.py` (и/или `docker-compose.yaml`) были явно указаны параметры для подключения к вашему эндпоинту ProxyAPI:
   • Модель: `openai/z-ai/glm-5.3-flash` (обязательный префикс `openai/` для LiteLLM).
   • Базовый URL: `https://api.proxyapi.ru/v1`.
   • API-ключ: ваш токен от ProxyAPI.
5. Запуск: Сборка образа и запуск контейнера через `podman-compose up`.

Результат: работающий агент с Tool Calling

На скриншоте видно, как агент `myagent` в интерактивном режиме `kagent run` отвечает на приветствие, а затем по запросу «давай кинем» выполняет вызов инструмента:

• Tool Call: `roll_die` с параметром `{“sides”: 6}`.
• Tool Result: `{“result”: 1}`.
• Ответ агента: «Выпала 1 🎲. На кубике с 6 гранями это минимальный результат — не повезло, но такое бывает! Хочешь бросить ещё раз или проверить число на простоту?»

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

⚖️ Сравнение с альтернативами

kagent — не единственный инструмент в этой нише. Чтобы понять его место, полезно сравнить его с другими решениями, которые решают смежные, но зачастую разные задачи. Подробные обзоры на Asya и Agent Autoscale появятся в отдельных статьях, а здесь мы приведем краткое сравнение.

Другие заметные инструменты в экосистеме

Помимо вышеперечисленных, стоит упомянуть специализированные утилиты, которые часто используются в связке или как альтернативы для конкретных задач:

• K8sGPT: AI-ассистент для быстрой диагностики кластера. Он сканирует ресурсы и объясняет проблемы на понятном языке, но по умолчанию не вносит изменений (read-only).
• HolmesGPT: Инструмент для более глубокого расследования инцидентов. Он анализирует логи, метрики и состояние кластера для поиска корневой причины, с возможностью опционального исправления с подтверждением.
• kubectl-ai: Утилита, которая превращает запросы на естественном языке в команды `kubectl`. Перед выполнением спрашивает подтверждение у пользователя.

💎 Заключение

kagent занимает важную нишу, предлагая Kubernetes-нативный, декларативный подход к управлению AI-агентами. Он идеально подходит для платформенных инженеров и DevOps-специалистов, которые хотят автоматизировать рутинные операции, используя знакомые им инструменты (YAML, `kubectl`, GitOps). В отличие от специализированных ассистентов (K8sGPT, HolmesGPT), kagent — это именно фреймворк для создания собственных агентов под конкретные задачи вашей инфраструктуры.

Хотя kagent не является решением для масштабных асинхронных пайплайнов (как Asya) или автоматического масштабирования флотов агентов (как Agent Autoscale), его сила — в простоте, гибкости и глубокой интеграции с экосистемой Kubernetes.

Успешный запуск агента с поддержкой Tool Calling в локальном окружении подтверждает, что kagent готов к практическому использованию и может стать мощным инструментом в арсенале вашей команды.

За последние два года AI-ассистенты для программирования перестали быть экзотикой и превратились в рабочий инструмент миллионов разработчиков. Однако выбрать подходящий — задача нетривиальная. Cline и Continue — два самых популярных open-source решения для VS Code, и хотя оба ставят перед собой схожую цель, подходы у них принципиально разные.

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

Cline: автономный агент

Cline — это автономный кодинг-агент, который живёт прямо в вашей IDE. Вы описываете задачу, а он читает файлы, вносит правки, запускает команды в терминале и повторяет цикл, пока задача не будет выполнена. Это ближайший open-source аналог Claude Code по стилю работы: агент владеет циклом выполнения, человек проверяет diff’ы.

Ключевые особенности:

• Чтение и запись файлов — навигация по кодовой базе, создание файлов и точечные правки. Каждое изменение показывается в виде diff’а перед применением.
• Выполнение команд — запуск shell-команд, тестов, установка пакетов и мониторинг вывода в реальном времени.
• Браузер — headless-браузер для тестирования веб-приложений, скриншотов и отладки ошибок.
• MCP-серверы — расширение возможностей через подключение внешних инструментов: баз данных, API, документации.
• Любая модель — Claude, GPT-4, Gemini, DeepSeek, локальные Ollama или любой OpenAI-совместимый endpoint.

Каждое действие требует вашего подтверждения — это zero-trust архитектура, при которой код не покидает вашу машину. Cline распространяется под лицензией Apache 2.0 и недавно преодолел отметку в 5 миллионов установок.

Continue: ассистент, который остаётся в потоке

Continue — это open-source AI-ассистент, построенный вокруг чата, inline-правок и автодополнения. Здесь человек остаётся за рулём: модель помогает, но не берёт управление на себя.

Ключевые особенности:

• Автодополнение кода — inline-подсказки прямо в редакторе, работающие на низкой задержке.
• Чат и inline-редактирование — общение с моделью в боковой панели и правки прямо в файле.
• Контекстные провайдеры — `@codebase`, `@file`, `@terminal` для запросов с учётом кода проекта.
• Slash-команды — кастомные команды для типовых задач: ревью кода, генерация тестов, рефакторинг.
• Гибкая конфигурация — всё управляется через единый `config.yaml`.

Continue — это middleware между редактором и LLM: расширение не поставляет собственную модель, а маршрутизирует запросы к тому провайдеру, который вы укажете. Проект поддерживает VS Code, JetBrains и Neovim, а его кодовая база остаётся открытой.

Сравнение: что выбрать

Если коротко: Cline лучше подходит для крупных механических задач — массовых рефакторингов, скаффолдинга, повторяющихся правок. Continue — для быстрой помощи в потоке, когда вы не хотите, чтобы модель «убегала вперёд».

Большинство разработчиков используют оба инструмента, переключаясь в зависимости от задачи.

Стоит упомянуть и о третьем игроке — Hermes. Это open-source AI-агент, который работает по протоколу Agent Client Protocol (ACP) и может быть подключён к VS Code, Zed или JetBrains через отдельное расширение ACP Client. Hermes CLI запускается как локальный подпроцесс, без облачного прокси, а расширение для VS Code стримит чат, выполняет инструменты и управляет сессиями. Главное отличие Hermes от Cline и Continue в том, что это не самостоятельное расширение с собственным интерфейсом, а агентный рантайм, который подключается к IDE через стандартизированный протокол. Подробнее о нём — в отдельной статье.

Установка и базовая настройка

Cline

Установка:

1. Откройте VS Code и перейдите в Extensions (`Ctrl/Cmd + Shift + X`).
2. Введите в поиске Cline.
3. Установите расширение от `saoudrizwan` (ID: `saoudrizwan.claude-dev`).
4. После установки нажмите на иконку Cline в Activity Bar. Если её не видно, перезапустите VS Code полностью.

Подключение провайдера:

Откройте настройки Cline и выберите провайдера. Можно использовать Cline Provider (pay-as-you-go), ClinePass (подписка) или подключить собственный API-ключ от Anthropic, OpenAI, OpenRouter или любого OpenAI-совместимого сервиса.

Continue

Установка:

1. Откройте Extensions (`Ctrl/Cmd + Shift + X`).
2. Найдите Continue и установите расширение от `Continue.dev`.

Настройка:

При первом запуске Continue предложит мастер настройки. Конфигурация хранится в файле `~/.continue/config.yaml` (macOS/Linux) или `%USERPROFILE%\.continue\config.yaml` (Windows). Открыть его можно из панели Continue: нажмите на иконку шестерёнки рядом с выпадающим списком моделей.

Если у вас остался старый `config.json`, его можно мигрировать в YAML — при наличии `config.yaml` расширение загрузит именно его.

Настройка кастомной модели в Continue

Одно из главных преимуществ Continue — возможность подключить любую модель через OpenAI-совместимый API. Вот пример конфигурации для подключения модели через прокси-сервис:

name: My Config
version: 1.0.0
schema: v1

models:
  - name: GLM 5.3 Flash via Proxy
    provider: openai
    model: z-ai/glm-5.3-flash
    apiBase: https://your-proxy-host.example.com/v1
    apiKey: ${{ secrets.PROXY_API_KEY }}
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      temperature: 0.7
      maxTokens: 4096
    capabilities:
      - tool_use

Ключевые моменты:

• `apiBase` должен заканчиваться на `/v1` — Continue автоматически добавит `/chat/completions`.
• `apiKey: ${{ secrets.PROXY_API_KEY }}` — ссылка на переменную из файла `.env`, который должен лежать рядом с `config.yaml`. Никогда не вписывайте ключ напрямую в конфиг.
• `capabilities: [tool_use]` — явно включает поддержку вызова инструментов, необходимую для работы Agent mode. Без этого кнопки Plan и Act будут неактивны.

Настройка MCP-серверов

MCP (Model Context Protocol) — это стандарт, позволяющий подключать к агенту внешние инструменты: базы данных, API, системы управления задачами. Оба инструмента поддерживают MCP, но конфигурируются по-разному.

Cline

Файл конфигурации: `cline_mcp_settings.json`. Открыть его можно через панель Cline: нажмите на иконку MCP Servers, перейдите на вкладку Configure и нажмите Configure MCP Servers.

Пример подключения локального MCP-сервера:

{
  "mcpServers": {
    "trino": {
      "command": "mcp-trino",
      "args": [],
      "env": {
        "TRINO_HOST": "192.168.3.81",
        "TRINO_PORT": "8080",
        "TRINO_USER": "trino",
        "TRINO_PASSWORD": "",
        "TRINO_CATALOG": "tpcds",
        "TRINO_SCHEMA": "sf10",
        "TRINO_SSL": "false",
        "TRINO_SCHEME": "http"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Для удалённых серверов используйте `“type”: “streamableHttp”` и поле `“url”`.

Continue

MCP-серверы добавляются в тот же `config.yaml`, где настраиваются модели, либо в отдельные файлы в папке `.continue/mcpServers/`.

Пример:

mcpServers:
  - name: Trino
    command: mcp-trino
    env:
      TRINO_HOST: "192.168.3.81"
      TRINO_PORT: "8080"
      TRINO_USER: "trino"
      TRINO_PASSWORD: ""
      TRINO_CATALOG: "tpcds"
      TRINO_SCHEMA: "sf10"
      TRINO_SSL: "false"
      TRINO_SCHEME: "http"

После сохранения конфигурации полностью перезапустите VS Code — оба расширения подхватывают MCP-серверы только при старте.

MCP-серверы для Trino: что выбрать

Trino — это распределённый SQL-движок для аналитических запросов к большим данным. Подключение MCP-сервера для Trino даёт AI-агенту возможность исследовать каталоги, выполнять запросы и анализировать планы выполнения прямо из чата. Для Trino существует несколько MCP-серверов, которые можно разделить на две категории: легковесные Python-серверы и высокопроизводительные Go-серверы.

Python-серверы (быстрый старт)

`trino-mcp` — самый функциональный и простой в настройке Python-сервер, который хорошо подходит для большинства задач. Поддерживает OAuth2 и Basic Auth, по умолчанию разрешает только `SELECT`-запросы (для записи нужно явно установить `ALLOW_WRITE_QUERIES=true`), автоматически добавляет комментарии в запросы с именем пользователя для аудита, а также умеет экспортировать результаты в JSON или CSV.

Установка через `uvx`:

uvx trino-mcp

Пример конфигурации для Continue:

mcpServers:
  - name: Trino
    command: uvx
    args:
      - "trino-mcp"
    env:
      TRINO_HOST: "your-trino-host"
      TRINO_PORT: "8080"
      TRINO_USER: "your-user"

`alaturqua/mcp-trino-python` — сервер, ориентированный на работу с Trino и Iceberg. Предоставляет расширенные возможности для исследования данных и обслуживания таблиц Iceberg, поддерживает три режима транспорта (`stdio`, `streamable-http`, `sse`) и имеет готовый `Dockerfile` для быстрого развёртывания.

Go-серверы (для продакшена)

`txn2/mcp-trino` — это, пожалуй, самый мощный и функциональный MCP-сервер для Trino. Он даёт AI-ассистентам безопасный, структурированный доступ к Trino и любым Trino-совместимым движкам. По умолчанию работает в режиме только для чтения, поддерживает ограничения на количество строк и таймауты запросов, а также имеет опциональный семантический слой для отображения бизнес-описаний, владельцев и маркеров чувствительности данных из DataHub или других каталогов метаданных.

Ключевые особенности:

• Выполнение SQL-запросов — `SELECT`, `SHOW`, `DESCRIBE` с настраиваемыми лимитами и таймаутами.
• Анализ планов выполнения — логические, распределённые и I/O-планы запросов.
• Просмотр схем — навигация по каталогам, схемам и таблицам.
• Описание таблиц — определения колонок с опциональными примерами данных.
• Мультикластерность — запросы к нескольким серверам Trino из одной установки через `TRINO_ADDITIONAL_CONNECTIONS`.
• Библиотека для Go — можно импортировать как Go-пакет и собрать собственный MCP-сервер с кастомной аутентификацией и аудитом.

Установка через Homebrew:

brew install txn2/tap/mcp-trino

Пример конфигурации для Cline:

{
  "mcpServers": {
    "trino": {
      "command": "mcp-trino",
      "args": [],
      "env": {
        "TRINO_HOST": "your-trino-host",
        "TRINO_PORT": "8080",
        "TRINO_USER": "trino",
        "TRINO_PASSWORD": "",
        "TRINO_CATALOG": "hive",
        "TRINO_SCHEMA": "default",
        "TRINO_SSL": "false",
        "TRINO_SCHEME": "http"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Пример конфигурации для Continue:

mcpServers:
  - name: Trino
    command: mcp-trino
    env:
      TRINO_HOST: "your-trino-host"
      TRINO_PORT: "8080"
      TRINO_USER: "trino"
      TRINO_PASSWORD: ""
      TRINO_CATALOG: "hive"
      TRINO_SCHEMA: "default"
      TRINO_SSL: "false"
      TRINO_SCHEME: "http"

Важные параметры `mcp-trino`:

• Подключение: обязательные переменные — `TRINO_HOST`, `TRINO_USER`. Порт по умолчанию: `8080` для HTTP или `443` для HTTPS.
• Режим только для чтения: включён по умолчанию. Для записи установите `TRINO_ALLOW_WRITE=true`.
• SSL: если Trino работает по HTTP, обязательно установите `TRINO_SSL: “false”` и `TRINO_SCHEME: “http”`, иначе сервер попытается использовать HTTPS и выдаст ошибку `invalid URL escape “%2F”`.

Что выбрать?

• Для быстрого старта: начните с `trino-mcp` (Python). Он легко устанавливается через `uvx` и имеет безопасные настройки по умолчанию.
• Для работы с Iceberg: обратите внимание на `alaturqua/mcp-trino-python`, если ваша основная задача — исследование и обслуживание таблиц Iceberg.
• Для продакшена: выбирайте `txn2/mcp-trino` (Go), если нужна высокая производительность, поддержка нескольких кластеров и возможность встраивания в собственные приложения.

Типичные проблемы и их решения

Модель не появляется в Continue после добавления в конфиг.
Проверьте, что файл `.env` существует и лежит в той же папке, что `config.yaml`. Имя переменной в `.env` должно точно совпадать с именем в `${{ secrets.ИМЯ }}`.

Кнопки Plan и Act неактивны.
Добавьте `capabilities: [tool_use]` в блок модели. Без этой способности Continue блокирует агентные режимы.

Ошибка `401 status code (no body)`.
Ключ API не распознан. Проверьте, что `apiBase` заканчивается на `/v1`, ключ действителен и имеет положительный баланс.

MCP-сервер не подключается с ошибкой `invalid URL escape “%2F”`.
Сервер пытается использовать HTTPS, хотя Trino работает по HTTP. Добавьте `TRINO_SSL: “false”` и `TRINO_SCHEME: “http”` в переменные окружения MCP-сервера.

Модель зависает после долгих раздумий в Agent mode.
Скорее всего, прокси-сервис не передаёт `tool_calls` в потоковом режиме. Проверьте это через `curl` с `“stream”: true` и имитацией вызова инструмента. Если `tool_calls` в потоке нет — попробуйте отключить стриминг через `config.json` или использовать модель с нативной поддержкой function calling.

Заключение

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

Оба инструмента бесплатны, оба поддерживают MCP и работают с любой моделью. С помощью MCP-серверов, таких как `txn2/mcp-trino`, вы можете подключить к агенту Trino и работать с данными прямо из чата — без переключения между окнами и ручного написания запросов.

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

Peakstarwave — это цифровой художник, визуальный дизайнер и автор моушн-графики, известный своими ретро и ностальгическими эстетиками (80-е и 90-е годы), работами с анимацией, коллажами и экспериментальными визуальными образами.

Основные направления творчества

• Моушн-дизайн и анимация: Создает визуализации и короткие анимационные ролики в программах вроде After Effects и смешанных техниках (цифровой и аналоговый подход).
• NFT и криптоарт: Выпускает цифровые коллекции на специализированных платформах (например, серия Animals из 100 уникальных GIF-работ на SuperRare и NFT Calendar).
• Графика и ретро-эстетика: Разрабатывает работы с эффектами зернистости, типографикой и ностальгическими образами (включая известные серии вроде Blue horse и графику для музыкальных релизов).

https://superrare.com/artwork/eth/0xDFf3b7A47Cf780C1D15ea1c9ba0E5c0Db771Ce70/6

В предыдущей части мы настроили балансировку нагрузки через Traefik, но весь трафик ходил по HTTP — незашифрованным. В этой части мы добавим HTTPS с помощью самоподписных сертификатов. Это хороший способ подготовить инфраструктуру к продакшену, где вы сможете заменить их на сертификаты от Let’s Encrypt буквально одной строкой.

Часть 1: HashiCorp Nomad: развертывание интерактивного Python-приложения на macOS
Часть 2: Балансировка нагрузки и сервис-дискавери с Consul и Traefik для Marimo

Зачем нужен HTTPS

• Шифрование: данные между браузером и сервером передаются в зашифрованном виде.
• Подготовка к продакшену: архитектура с двумя точками входа (HTTP и HTTPS) и автоматическим редиректом — это стандартная схема.
• Доверие к сертификатам: локально вы можете использовать самоподписные сертификаты, а в продакшене — Let’s Encrypt, не меняя структуру конфигурации.

Шаг 1: Генерация самоподписного сертификата

Для создания сертификата используем `openssl`, который уже есть в macOS. Важный момент: обязательно указываем Subject Alternative Name (SAN) с именем домена, иначе современные браузеры откажутся считать сертификат валидным.

mkdir -p ~/marimo-app/certs && cd ~/marimo-app/certs

openssl req -x509 -nodes -days 365 \
  -newkey rsa:2048 \
  -keyout marimo.localhost.key \
  -out marimo.localhost.crt \
  -subj "/CN=marimo.localhost" \
  -addext "subjectAltName=DNS:marimo.localhost"

В папке `certs` появятся два файла:

• `marimo.localhost.key` — приватный ключ.
• `marimo.localhost.crt` — сертификат.

Что произойдёт при открытии сайта: браузер покажет предупреждение, что сертификат не является доверенным. Это ожидаемое поведение — вы можете принять исключение для домена `marimo.localhost`. В продакшене предупреждения не будет, так как сертификаты Let’s Encrypt автоматически доверенные.

Шаг 2: Обновление конфигурации Traefik

Traefik поддерживает разделение конфигурации на статическую (точки входа, провайдеры) и динамическую (маршруты, сертификаты). Мы создадим обе через блоки `template` в задании Nomad.

Статическая конфигурация

Добавим точку входа `websecure` на порту 8443 и настроим автоматический редирект с HTTP на HTTPS:

[entryPoints]
  [entryPoints.web]
    address = ":8080"
    [entryPoints.web.http.redirections.entryPoint]
      to = "websecure"
      scheme = "https"
      permanent = true

  [entryPoints.websecure]
    address = ":8443"

  [entryPoints.traefik]
    address = ":8081"

[api]
  dashboard = true
  insecure  = true

[providers.consulCatalog]
  prefix           = "traefik"
  exposedByDefault = false

  [providers.consulCatalog.endpoint]
    address = "127.0.0.1:8500"
    scheme  = "http"

[providers.file]
  filename = "${NOMAD_TASK_DIR}/dynamic.toml"
  watch    = true

Ключевые моменты:

• `websecure` на порту `8443` — точка входа для HTTPS-трафика.
• `[entryPoints.web.http.redirections.entryPoint]` — HTTP-запросы автоматически перенаправляются на HTTPS.
• `[providers.file]` — подключает динамический провайдер, который читает наш файл с сертификатами.

Динамическая конфигурация

Здесь мы описываем сам сертификат:

[tls]
  [tls.stores]
    [tls.stores.default]
      [tls.stores.default.defaultCertificate]
        certFile = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.crt"
        keyFile  = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.key"

  [[tls.certificates]]
    certFile = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.crt"
    keyFile  = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.key"

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

Шаг 3: Полное задание Traefik

Вот итоговый файл `traefik.nomad` с обеими конфигурациями:

job "traefik" {
  region      = "global"
  datacenters = ["dc1"]
  type        = "service"

  group "traefik" {
    count = 1

    network {
      port "http" {
        static = 8080
      }
      port "api" {
        static = 8081
      }
    }

    service {
      name = "traefik"
      check {
        name     = "alive"
        type     = "tcp"
        port     = "http"
        interval = "10s"
        timeout  = "2s"
      }
    }

    task "traefik" {
      driver = "raw_exec"

      # Статическая конфигурация Traefik
      template {
        data = <<EOF
[entryPoints]
  [entryPoints.web]
    address = ":8080"
    [entryPoints.web.http.redirections.entryPoint]
      to = "websecure"
      scheme = "https"
      permanent = true

  [entryPoints.websecure]
    address = ":8443"

  [entryPoints.traefik]
    address = ":8081"

[api]
  dashboard = true
  insecure  = true

[providers.consulCatalog]
  prefix           = "traefik"
  exposedByDefault = false

  [providers.consulCatalog.endpoint]
    address = "127.0.0.1:8500"
    scheme  = "http"

[providers.file]
  filename = "${NOMAD_TASK_DIR}/dynamic.toml"
  watch    = true
EOF
        destination = "local/traefik.toml"
      }

      # Динамическая конфигурация: сертификаты по абсолютному пути
      template {
        data = <<EOF
[tls]
  [tls.stores]
    [tls.stores.default]
      [tls.stores.default.defaultCertificate]
        certFile = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.crt"
        keyFile  = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.key"

  [[tls.certificates]]
    certFile = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.crt"
    keyFile  = "/Users/yuriygavrilov/marimo-app/certs/marimo.localhost.key"
EOF
        destination = "local/dynamic.toml"
      }

      config {
        command = "/usr/local/bin/traefik"
        args = [
          "--configfile",
          "${NOMAD_TASK_DIR}/traefik.toml"
        ]
      }

      resources {
        cpu    = 100
        memory = 128
      }
    }
  }
}

Шаг 4: Обновление тегов Marimo

В задании `marimo-job.nomad` нужно переключить сервис на точку входа `websecure` и включить TLS:

service {
  name = "marimo-app"
  port = "http"
  tags = [
    "traefik.enable=true",
    "traefik.http.routers.marimo.rule=Host(`marimo.localhost`)",
    "traefik.http.routers.marimo.entrypoints=websecure",
    "traefik.http.routers.marimo.tls=true",
    "traefik.http.services.marimo-app.loadbalancer.sticky.cookie=true",
  ]
  check {
    type     = "http"
    path     = "/"
    interval = "2s"
    timeout  = "2s"
  }
}

Что изменилось:

• `entrypoints=websecure` — трафик направляется на HTTPS-точку входа.
• `tls=true` — включена TLS-терминация для этого маршрута.

Шаг 5: Запуск и проверка

Перезапустите оба задания:

nomad job stop traefik
nomad job run traefik.nomad
nomad job run marimo-job.nomad

Откройте в браузере:

https://marimo.localhost:8443

Браузер покажет предупреждение о недоверенном сертификате. Нажмите «Дополнительно» → «Перейти на marimo.localhost (небезопасно)» или добавьте сертификат в системный раздел доверенных сертов (в macOS это делается через «Связка ключей»).

Если вы попробуете открыть `http://marimo.localhost:8080`, Traefik автоматически перенаправит вас на HTTPS.

Возможные ошибки и их решения

Ошибка: `Unclosed configuration block`

Причина: незакрытые блоки `{ ... }` в HCL-файле.

Решение: внимательно проверьте, что все блоки `job`, `group`, `task`, `config`, `template` закрыты. В HCL отступы не важны, но фигурные скобки — критичны.

Ошибка: `Missing required argument: “command”` при `raw_exec`

Причина: конфигурация скопирована из задания для `docker` (с полями `image`, `volumes`, `network_mode`), но применён драйвер `raw_exec`.

Решение: для `raw_exec` используйте поля `command` и `args`. Файлы конфигурации создавайте через `template`.

Ошибка: `volume_mount` не поддерживается драйвером `raw_exec`

Причина: драйвер `raw_exec` работает напрямую с процессами хоста и не поддерживает монтирование томов.

Решение: используйте абсолютные пути к файлам (как мы сделали в динамической конфигурации). Или переходите на драйвер `docker`/`podman` — там `volume_mount` работает штатно.

Ошибка: `entryPoint “websecure” doesn’t exist`

Причина: имя точки входа в тегах сервиса не совпадает с именем в статической конфигурации Traefik.

Решение: убедитесь, что в конфиге есть блок `[entryPoints.websecure]`, а в тегах указано `traefik.http.routers.marimo.entrypoints=websecure`.

Итог

Мы добавили HTTPS в наш стек. Теперь архитектура выглядит так:

Пользователь (HTTPS)
     │
     ▼
  Traefik  ──►  Marimo 1 / 2 / 3
(8443)              │
     │              ▼
     └─────────► Consul
                    ▲
                    │
             Nomad Cluster

• HTTP-трафик на порту 8080 автоматически перенаправляется на HTTPS.
• HTTPS-трафик на порту 8443 расшифровывается Traefik и направляется на реплики Marimo.
• Сертификаты хранятся на хосте и подключаются через абсолютные пути.

В продакшене достаточно заменить пути к сертификатам и указать Traefik получать их автоматически от Let’s Encrypt — структура конфигурации останется той же. Мы разберём это в следующей части.

А вот еще бонус:

Все это через туннель https://cloudpub.ru/docs/http

Вот так:

yuriygavrilov@MacBookPro ~ % ./clo publish https marimo.localhost:8443
Сервис опубликован: https://marimo.localhost:8443 -> https://thirdly-fast-bushbuck.cloudpub.ru:443

Ну и конечно нужно DNS поправить, но работает и с авторизацией

Но лучше так не делать, все такие весь трафик так проходит через cloudpub

В первой части мы развернули приложение Marimo через Nomad, используя драйвер `raw_exec` и динамические порты. Приложение работало, но у него был существенный недостаток: каждая реплика была доступна по отдельному порту, а пользователю приходилось вручную искать актуальный адрес. Кроме того, отсутствовала отказоустойчивость — при падении одной реплики трафик не перераспределялся.

Первая часть тут HashiCorp Nomad: развертывание интерактивного Python-приложения на macOS

В этой статье мы решим эти проблемы с помощью Consul (сервис-дискавери) и Traefik (балансировщик нагрузки). Мы также настроим липкие сессии (sticky sessions), которые критически важны для stateful-приложений, таких как Marimo.

Зачем нужны Consul и Traefik?

• Consul — распределённый каталог сервисов. Он хранит информацию о работающих репликах, проверяет их здоровье и предоставляет DNS-интерфейс. Без него балансировщик не знал бы, куда направлять трафик.
• Traefik — современный обратный прокси и балансировщик нагрузки. Он автоматически обнаруживает сервисы через Consul Catalog Provider и распределяет запросы между здоровыми репликами.
• Nomad — оркестратор, который управляет всеми компонентами.

Итоговая архитектура:

Пользователь
     │
     ▼
  Traefik  ──►  Marimo 1 / 2 / 3
(балансировщик)      │
     │               ▼
     └──────────► Consul
                     ▲
                     │
              Nomad Cluster

Предварительные требования

Убедитесь, что у вас есть:

1. Работающий Nomad в режиме разработки (`nomad agent -dev -bind=0.0.0.0`).
2. Проект `~/marimo-app` с файлами `app.py`, `pyproject.toml`, `uv.lock` и виртуальным окружением.
3. Установленный Consul.
4. Установленный Traefik (мы будем запускать его через Nomad, но бинарник должен быть доступен).

Установка Consul

brew tap hashicorp/tap
brew install hashicorp/tap/consul

Установка Traefik

brew install traefik

Проверьте пути:

which consul   # /usr/local/bin/consul
which traefik  # /usr/local/bin/traefik

Шаг 1: Запуск Consul в режиме разработки

Откройте отдельный терминал и запустите Consul:

consul agent -dev -bind=0.0.0.0 -client=0.0.0.0

Consul будет доступен по адресу `http://127.0.0.1:8500`. Оставьте терминал открытым.

Важно: Consul должен быть запущен до того, как вы запустите Nomad с интеграцией с Consul, иначе сервисы не зарегистрируются.

Шаг 2: Обновление задания Marimo

Мы добавим в задание блок `service`, который зарегистрирует приложение в Consul и снабдит его тегами для Traefik. Также включим липкие сессии, чтобы запросы одного пользователя всегда попадали на одну и ту же реплику.

Создайте файл `marimo-job.nomad`:

job "marimo-app" {
  datacenters = ["dc1"]
  type = "service"

  group "app" {
    count = 3

    network {
      port "http" {}
    }

    service {
      name = "marimo-app"
      port = "http"
      tags = [
        "traefik.enable=true",
        "traefik.http.routers.marimo.rule=Host(`marimo.localhost`)",
        "traefik.http.routers.marimo.entrypoints=web",
        "traefik.http.services.marimo-app.loadbalancer.sticky.cookie=true",
      ]
      check {
        type     = "http"
        path     = "/"
        interval = "2s"
        timeout  = "2s"
      }
    }

    task "marimo" {
      driver = "raw_exec"

      config {
        command = "/Users/yuriygavrilov/marimo-app/.venv/bin/marimo"
        args = [
          "run", "app.py",
          "--headless",
          "--port", "${NOMAD_PORT_http}",
          "--host", "0.0.0.0"
        ]
        work_dir = "/Users/yuriygavrilov/marimo-app"
      }

      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

Что изменилось:

• `count = 3` — запускаем три реплики.
• Блок `service` — регистрирует сервис в Consul.
• Теги Traefik:
  • `traefik.enable=true` — разрешает Traefik обслуживать сервис.
  • `traefik.http.routers.marimo.rule=Host(\`marimo.localhost\`)` — правило маршрутизации по домену.
  • `traefik.http.routers.marimo.entrypoints=web` — точка входа (должна совпадать с именем в конфиге Traefik).
  • `traefik.http.services.marimo-app.loadbalancer.sticky.cookie=true` — включает липкие сессии на основе cookie.

Примечание про домен `.localhost`

В примере используется домен `marimo.localhost`. Добавлять его в `/etc/hosts` не нужно — имена, заканчивающиеся на `.localhost`, автоматически резолвятся в `127.0.0.1` согласно стандарту RFC 6761 (раздел 6.3) и RFC 6762. Это поведение поддерживается:

• системным резолвером macOS (`mDNSResponder`),
• всеми современными браузерами (Chrome, Safari, Firefox),
• а также большинством инструментов командной строки (`curl`, `ping` и т.д.).

Именно поэтому `http://marimo.localhost:8080` будет работать «из коробки» без правки системных файлов.

Когда `/etc/hosts` всё-таки понадобится:

Если вы хотите использовать другое имя — например, `marimo.dev`, `marimo.internal` или реальный домен вроде `marimo.example.com`, — тогда запись нужна:

echo "127.0.0.1 marimo.dev" | sudo tee -a /etc/hosts

Для локальной разработки и тестирования домен `.localhost` — самый удобный вариант: он не требует никаких дополнительных настроек и работает одинаково на любой машине.

Шаг 3: Создание задания для Traefik

Traefik будет запущен через `raw_exec`. Конфигурационный файл создаётся динамически с помощью шаблона Nomad.

Создайте файл `traefik.nomad`:

job "traefik" {
  region      = "global"
  datacenters = ["dc1"]
  type        = "service"

  group "traefik" {
    count = 1

    network {
      port "http" {
        static = 8080
      }
      port "api" {
        static = 8081
      }
    }

    service {
      name = "traefik"
      check {
        name     = "alive"
        type     = "tcp"
        port     = "http"
        interval = "10s"
        timeout  = "2s"
      }
    }

    task "traefik" {
      driver = "raw_exec"

      # Создаём конфигурационный файл Traefik через шаблон
      template {
        data = <<EOF
[entryPoints]
  [entryPoints.web]
    address = ":8080"
  [entryPoints.traefik]
    address = ":8081"

[api]
  dashboard = true
  insecure  = true

# Включаем Consul Catalog Provider
[providers.consulCatalog]
  prefix           = "traefik"
  exposedByDefault = false

  [providers.consulCatalog.endpoint]
    address = "127.0.0.1:8500"
    scheme  = "http"
EOF
        destination = "local/traefik.toml"
      }

      config {
        command = "/usr/local/bin/traefik"
        args = [
          "--configfile",
          "${NOMAD_TASK_DIR}/traefik.toml"
        ]
      }

      resources {
        cpu    = 100
        memory = 128
      }
    }
  }
}

Ключевые моменты:

• `driver = “raw_exec”` — запускаем бинарник напрямую.
• `template` — создаёт файл `traefik.toml` в директории задачи.
• `command` — полный путь к Traefik.
• `args` — указываем путь к созданному конфигу через переменную `${NOMAD_TASK_DIR}`.
• В конфиге Traefik точка входа называется `web` (порт 8080). Это имя должно совпадать с тегом `traefik.http.routers.marimo.entrypoints=web`.

Шаг 4: Запуск всех компонентов

Убедитесь, что Consul и Nomad запущены в отдельных терминалах.

Затем в терминале, где вы работаете с заданиями:

cd ~/marimo-app

# Запускаем приложение
nomad job run marimo-job.nomad

# Запускаем Traefik
nomad job run traefik.nomad

Проверьте статус:

nomad job status marimo-app
nomad job status traefik

Шаг 5: Проверка работы

1. Consul: откройте `http://127.0.0.1:8500` и убедитесь, что сервис `marimo-app` зарегистрирован.

2. Traefik Dashboard: откройте `http://127.0.0.1:8081/dashboard/`. В разделе HTTP Routers должен быть маршрут `marimo` со статусом Enabled. В HTTP Services — сервис `marimo-app` с тремя здоровыми репликами.

3. Приложение: откройте `http://marimo.localhost:8080`. Вы должны увидеть интерфейс Marimo с полем ввода имени и диаграммой. Проверьте, что при нажатии кнопки данные обновляются, а ошибка `Invalid session id` не появляется.

Возможные ошибки и их решения

В процессе настройки мы столкнулись с несколькими типичными проблемами. Вот они и способы их устранения.

Ошибка 1: `EntryPoint doesn’t exist entryPointName=web`

Причина: в тегах сервиса указана точка входа `web`, а в конфигурации Traefik она называется иначе (например, `http`).

Решение: приведите имена к единому виду. В нашем случае мы переименовали точку входа в конфиге Traefik в `web`:

[entryPoints]
  [entryPoints.web]
    address = ":8080"

И в тегах указали `traefik.http.routers.marimo.entrypoints=web`.

Ошибка 2: `Invalid session id: s_bpy8u7`

Причина: отсутствие липких сессий. Marimo — stateful-приложение, оно хранит сессию на конкретной реплике. Если запросы распределяются случайно, браузер попадает на разные реплики, и сессия теряется.

Решение: добавьте тег `traefik.http.services.marimo-app.loadbalancer.sticky.cookie=true`. Traefik установит cookie и будет направлять все запросы от одного браузера на одну и ту же реплику.

Ошибка 3: `Missing required argument: “command”` при использовании `raw_exec`

Причина: конфигурация написана для драйвера `docker` (с полями `image`, `volumes`, `network_mode`), но применён `raw_exec`.

Решение: для `raw_exec` используйте `command` и `args`. Файлы конфигурации создавайте через `template`. Пример для Traefik приведён выше.

Ошибка 4: `raw_exec` отключён

Причина: в некоторых сборках Nomad драйвер `raw_exec` отключён по умолчанию.

Решение: добавьте в конфигурацию клиента Nomad (например, `/etc/nomad.d/nomad.hcl`):

plugin "raw_exec" {
  config {
    enabled = true
  }
}

и перезапустите агент Nomad, но в моем случае это не понадобилось.

Итог

Мы добавили к нашему приложению Marimo два важных компонента:

• Consul — для сервис-дискавери и проверки здоровья.
• Traefik — для балансировки нагрузки и единой точки входа.

Теперь приложение доступно по адресу `http://marimo.localhost:8080`, а трафик автоматически распределяется между тремя репликами. Благодаря липким сессиям пользователи не теряют состояние при работе с интерактивным интерфейсом.

Этот подход является основой для построения отказоустойчивых и масштабируемых систем. В следующих статьях мы рассмотрим настройку TLS/HTTPS, использование Vault для управления секретами и автоматическое масштабирование.

Поздравляю! Теперь ваше приложение готово к более серьёзным нагрузкам. 🚀

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

В этой статье мы разберем, что такое Nomad, установим его на macOS, создадим простое интерактивное приложение на Marimo с полем ввода имени и генерацией случайных данных на столбчатой диаграмме, а затем развернем его с помощью Nomad, используя драйвер `raw_exec`. В конце обсудим ограничения такого подхода и путь к настоящему продакшену.

Что такое HashiCorp Nomad?

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

Ключевые особенности

• Универсальность: Nomad может запускать Docker-контейнеры, обычные приложения (без контейнеризации), микросервисы и пакетные задачи на одной инфраструктуре.
• Простота: Nomad распространяется как единый бинарный файл, не требует внешних зависимостей для хранения или координации и автоматически обрабатывает сбои приложений, узлов и драйверов.
• Масштабируемость: Nomad способен масштабироваться до 10 000+ узлов и имеет встроенную поддержку GPU-нагрузок.
• Гибкость: Поддерживает различные типы задач: сервисы, пакетные задания и системные задачи. Работает на Linux, macOS и Windows.

Установка Nomad на macOS

Для установки Nomad на macOS удобнее всего использовать Homebrew. Выполните следующие команды в терминале:

# Добавляем репозиторий HashiCorp
brew tap hashicorp/tap

# Устанавливаем Nomad
brew install hashicorp/tap/nomad

После установки проверьте версию:

nomad version

Пример вывода:

Nomad v2.0.5
BuildDate 2026-08-12T18:22:41Z
Revision 5c8612bba6eb8e44cc3fc434125cb1b13463c309

Важно: На Intel Mac (x86_64) могут возникнуть проблемы с загрузкой бинарников из-за прекращения поддержки Apple. В этом случае рекомендуется использовать VPN для доступа к ресурсам HashiCorp. Если Nomad не устанавливается через Homebrew, можно собрать его из исходников или использовать MacPorts.

Запуск Nomad в режиме разработки

Для тестирования и разработки Nomad поддерживает режим `-dev`, который запускает одноузловой кластер на вашем компьютере:

nomad agent -dev -bind=0.0.0.0

Эта команда запустит Nomad, и веб-интерфейс будет доступен по адресу `http://127.0.0.1:4646`. Оставьте этот терминал открытым — это ваш “сервер” Nomad.

Создание Marimo-приложения

Установка `uv`

`uv` — это современный и быстрый менеджер пакетов для Python. Установите его:

curl -LsSf https://astral.sh/uv/install.sh | sh

Создание проекта

mkdir ~/marimo-app
cd ~/marimo-app
uv init
uv add marimo altair pandas numpy

Написание приложения

Создайте файл `app.py` со следующим содержимым. Приложение будет иметь поле для ввода имени, кнопку для генерации случайных значений и столбчатую диаграмму:

import marimo

__generated_with = "0.11.0"
app = marimo.App()


@app.cell
def _():
    import marimo as mo
    import altair as alt
    import pandas as pd
    import numpy as np
    return alt, mo, np, pd


@app.cell
def _(mo):
    # Поле для ввода имени
    name_input = mo.ui.text(
        placeholder="Введите ваше имя...",
        label="Имя пользователя"
    )
    name_input
    return (name_input,)


@app.cell
def _(mo, name_input):
    # Отображение приветствия
    if name_input.value:
        mo.md(f"## Привет, **{name_input.value}**! 👋")
    else:
        mo.md("## Введите имя выше")
    return


@app.cell
def _(mo):
    # Кнопка для генерации данных
    generate_button = mo.ui.button(
        label="🎲 Сгенерировать данные",
        value=0,
        on_click=lambda value: value + 1
    )
    generate_button
    return (generate_button,)


@app.cell
def _(alt, generate_button, mo, np, pd):
    # Генерация случайных данных при нажатии кнопки
    np.random.seed(generate_button.value)
    categories = ["Категория A", "Категория B", "Категория C", "Категория D", "Категория E"]
    values = np.random.randint(10, 100, size=5)
    
    df = pd.DataFrame({
        "Категория": categories,
        "Значение": values
    })
    
    chart = alt.Chart(df).mark_bar().encode(
        x=alt.X("Категория", sort=None),
        y="Значение",
        color=alt.value("#4C78A8")
    ).properties(
        title="Случайные значения по категориям",
        width=500,
        height=300
    )
    
    mo.ui.altair_chart(chart)
    return (chart,)


if __name__ == "__main__":
    app.run()

Проверка локально

Запустите приложение в режиме редактирования:

uv run marimo run app.py

Убедитесь, что приложение работает: введите имя, нажмите кнопку — диаграмма должна обновиться. Закройте сервер (`Ctrl+C`).

Создание задания для Nomad

Создайте файл `marimo-job.nomad` в папке проекта:

job "marimo-app" {
  datacenters = ["dc1"]
  type = "service"

  group "app" {
    count = 2

    network {
      port "http" {}
    }

    task "marimo" {
      driver = "raw_exec"

      config {
        command = "/Users/yuriygavrilov/marimo-app/.venv/bin/marimo"
        args = [
          "run", "app.py",
          "--headless",
          "--port", "${NOMAD_PORT_http}",
          "--host", "0.0.0.0"
        ]
        work_dir = "/Users/yuriygavrilov/marimo-app"
      }

      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

Пояснения:

• `driver = “raw_exec”` — запускает процесс напрямую на хосте без изоляции.
• `count = 2` — запускаем две реплики приложения. Nomad автоматически распределит их по узлам (в нашем случае — по одному узлу, но на разных портах).
• `port “http” {}` — динамический порт. Nomad резервирует случайный свободный порт для каждой аллокации. Такой подход избавляет от конфликтов портов при запуске нескольких реплик.
• `command` — полный путь к исполняемому файлу `marimo` в виртуальном окружении.
• `${NOMAD_PORT_http}` — Nomad автоматически подставляет динамически выделенный порт через переменную окружения `NOMAD_PORT_`.
• `work_dir` — рабочая директория, где находится `app.py`.

Важно: замените `/Users/yuriygavrilov/` на реальный путь к вашей домашней директории.

Запуск задания

Убедитесь, что Nomad работает (в первом терминале). Во втором терминале выполните:

nomad job run marimo-job.nomad

Пример успешного вывода:

==> 2026-09-26T21:26:27+03:00: Monitoring evaluation "cba695bd"
    2026-09-26T21:26:27+03:00: Allocation "2327286c" created: node "7f836ccd", group "app"
==> 2026-09-26T21:26:27+03:00: Monitoring deployment "9ea4ff53"
  ✓ Deployment "9ea4ff53" successful
    
    Deployed
    Task Group  Desired  Placed  Healthy  Unhealthy  Progress Deadline
    app         1        1       1        0

Как узнать порт приложения

После запуска задания выполните:

nomad job status marimo-app

Вы увидите таблицу аллокаций с их ID. Для каждой аллокации выполните:

nomad alloc status <ID_аллокации>

В выводе найдите секцию `Allocation Addresses`:

Allocation Addresses:
Label  Dynamic  Address
*http  yes      127.0.0.1:20938

Откройте в браузере `http://127.0.0.1:20938` — ваше приложение работает.

Повторите команду для остальных аллокаций, чтобы получить порты всех реплик.

Ограничения текущего подхода

Мы успешно запустили приложение, но важно понимать, что это ещё не полноценное масштабированное решение. Вот почему:

1. Нет балансировщика нагрузки

У нас работают две реплики на разных портах (`20938`, `21001` и т.д.). Чтобы обратиться к приложению, пользователь должен знать конкретный порт каждой реплики. Это неудобно:

• Нельзя дать пользователям один адрес, например `http://marimo.mycompany.com`.
• Нет автоматического распределения трафика между репликами.
• Нет отказоустойчивости: если одна реплика упадёт, клиент, знающий только её порт, потеряет доступ.

2. Нет сервис-дискавери

Nomad не регистрирует сервисы автоматически (для этого нужен Consul). Без сервис-дискавери балансировщик не сможет узнать, какие реплики сейчас работают.

3. Минимальная изоляция

Драйвер `raw_exec` запускает процессы прямо на хосте. В продакшене это небезопасно: приложение имеет доступ ко всей файловой системе и может влиять на систему.

Путь к продакшену: что нужно добавить

1. Балансировщик нагрузки (Traefik, NGINX, HAProxy)

Traefik — самый простой вариант для интеграции с Nomad. Он умеет:

• Автоматически обнаруживать сервисы через Consul.
• Распределять трафик между всеми здоровыми репликами.
• Работать с TLS/HTTPS “из коробки”.
• Иметь удобную панель управления.

Как это выглядит в задании: вы добавляете специальные теги в блок `service` вашего приложения, и Traefik сам настраивает маршрутизацию:

service {
  name = "marimo-app"
  port = "http"
  tags = [
    "traefik.enable=true",
    "traefik.http.routers.marimo.rule=Host(`marimo.localhost`)",
  ]
}

Затем запускаете Traefik как отдельную задачу в Nomad, и он становится единой точкой входа для всех пользователей.

2. Сервис-дискавери (Consul)

Consul — это распределённый каталог сервисов. Он:

• Хранит информацию о том, какие реплики сейчас работают и на каких портах.
• Предоставляет DNS-интерфейс: ваше приложение доступно как `marimo-app.service.consul`.
• Позволяет балансировщику динамически обновлять список бэкендов.

3. Контейнеризация (Docker/Podman)

В продакшене используйте контейнерные драйверы вместо `raw_exec`:

• Изоляция: приложение работает в своём окружении, не влияя на хост.
• Воспроизводимость: одинаковое поведение на любой машине.
• Безопасность: ограничения по ресурсам и правам доступа.

4. Полноценный кластер Nomad

В продакшене Nomad работает не как один процесс, а как кластер:

• 3 серверных узла (минимум) — хранят состояние и принимают решения о планировании.
• N клиентских узлов — выполняют задачи.
• Интеграция с Vault для управления секретами.

Итоговая архитектура для продакшена

Пользователь
     │
     ▼
  Traefik  ──►  Marimo 1 / 2 / 3
(балансировщик)      │
                     ▼
                  Consul
                     ▲
                     │
              Nomad Cluster

Заключение

Мы рассмотрели базовый процесс развертывания Python-приложения с помощью HashiCorp Nomad:

1. Установили Nomad через Homebrew.
2. Запустили Nomad в режиме разработки.
3. Создали Marimo-приложение с полем ввода имени и интерактивной диаграммой.
4. Написали задание Nomad с драйвером `raw_exec` и динамическим портом.
5. Запустили две реплики приложения и научились находить их порты.

Этот подход отлично работает для разработки и тестирования. Но для настоящего продакшена необходимо:

• Добавить балансировщик нагрузки (Traefik, NGINX, HAProxy), чтобы пользователи обращались к одному адресу.
• Внедрить сервис-дискавери (Consul), чтобы балансировщик знал о работающих репликах.
• Использовать контейнерные драйверы (Docker, Podman) для изоляции.
• Построить полноценный кластер Nomad с тремя серверными узлами.

Nomad — это мощный и гибкий инструмент, который подходит как для простых задач, так и для сложных распределённых систем. Его простота и универсальность делают его отличным выбором для разработчиков, которые хотят быстро развертывать приложения без излишней сложности Kubernetes.

Следующий логичный шаг — добавить Traefik и Consul, чтобы превратить наш прототип в отказоустойчивое и масштабируемое решение. Об этом — в следующих статьях.

Вчера, 19 сентября 2026 года, мне посчастливилось побывать в парке «Зарядье» на выставке «Мастерская новатора. Константин Худяков». Это событие стало для меня не просто очередным культурным выходом, а настоящим погружением в мир, где технологии и искусство сплетаются в единое целое. Выставка, посвященная памяти художника-визионера и одного из основоположников цифрового искусства в России, открылась 18 сентября и продлится до 8 ноября.

Спасибо организаторам 🙏🤗🤝

🖼️ Два образа, которые не отпускают

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

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

Стерео-лайт-панель — это уникальное технологичное произведение цифрового искусства, созданное российским художником Константином Худяковым. Эта техника соединяет многоракурсную стереофотографию, компьютерную графику и внутреннюю светодиодную подсветку, создавая эффект живого объемного изображения без очков.

«Глаз ангела» — работа, которая завораживает с первого взгляда. Это не просто глаз, а портал в иную реальность, где каждый отраженный луч, каждая частица света рассказывают свою историю. Меня поразила глубина и многослойность этого образа и детализация. Когда смотришь на него, кажется, что видишь не только саму картину, но и время, в которое она была создана, и мысли автора, вложенные в нее. Эти две работы понравились мне одинаково сильно, и я до сих пор нахожусь под их впечатлением.

🧬 Код цифрового искусства

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

Каждый слой — это не просто технический элемент. Это образ жизни художника, его мировоззрение, технологии, которые были доступны на момент создания, и само время, которое диктовало свои условия. Раскрывая эти слои один за другим, начинаешь видеть, как автор превосходил свое время, заглядывая в будущее и предугадывая то, что станет доступно лишь десятилетия спустя. Худяков начал работать с цифровыми технологиями еще в конце 1990-х, когда многие даже не представляли, что компьютер может быть инструментом искусства. Его авторская техника «искусства высокого разрешения» позволяла создавать графику, которая по качеству и глубине не уступала живописи.

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

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

🌱 Ученики и последователи

На выставке также были представлены работы учеников и последователей Худякова. Мое внимание привлекли проекты, созданные командой студии Synticate. Эта арт-группа, основанная Владиславом Ткачуком и Романом Цукановым, занимается созданием цифровых форм жизни и исследованием будущего симбиоза природы и технологий. Их концепция «экофутуризма» очень близка идеям Худякова о синтезе искусства и науки.

Особенно интересной мне показалась работа из серии «Киберорганика». В этой работе чувствуется тот же подход, что и у Худякова: синтез природы и технологий, создание новой формы жизни на стыке реального и цифрового. Synticate интегрируют компьютерную графику в реальные съемки, что позволяет им рассказывать истории о будущем, не отрываясь от настоящего.

🤝 Коллективное творчество

Отдельно хочется сказать о том, как Худяков работал над своими масштабными проектами. Художник создавал цифровые портреты, используя фотографии реальных людей, а затем объединял их в единое многоликое произведение. Например, в проекте «Биохакинг» приняли участие 250 человек — Худяков сделал более 150 снимков лица каждого, чтобы затем создать собирательный образ. Этот подход — использование коллективного опыта и множества человеческих лиц для создания одного образа — как нельзя лучше отражает его философию: искусство создается не в вакууме, а из живого опыта многих людей и становятся их кодом.

💎 Заключение

Посещение «Мастерской новатора» стало для меня не просто знакомством с творчеством Константина Худякова, но и глубоким размышлением о природе цифрового искусства. Работы, увиденные вчера, — это не просто картинки. Это многослойные коды, в которых зашифрована жизнь их создателя, его время и его взгляд в будущее.

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

https://discovery-ru.livejournal.com/14183.html

1. Что такое Hugr и зачем он нужен

Hugr — это open-source платформа класса Data Mesh и высокопроизводительный GraphQL-бэкенд, построенный поверх аналитического движка DuckDB. Проект развивается командой hugr-lab под руководством Владимира Грибанова и распространяется под лицензией MIT.

Назначение — решить конкретную инженерную боль: данные в организации разбросаны по десяткам систем (PostgreSQL, SQL Server, S3, REST API, Kafka, Redis), и каждая команда строит собственный слой доступа. Классические ETL-пайплайны и дублирование данных в единое хранилище дают задержку актуальности, удваивают инфраструктуру и создают узкое горлышко на дата-инженерах.

Hugr предлагает иную модель: данные остаются на месте, а поверх них выстраивается единый GraphQL-слой, который компилирует декларативные схемы в исполняемые запросы к каждому источнику. Для аналитика — один интерфейс вместо десятков коннекторов. Для разработчика — типизированный GraphQL API без ручного CRUD. Для дата-инженера — декларативное описание схемы через SDL-директивы вместо поддержки ETL.

Ключевые характеристики:

2. Архитектура: почему именно такая

2.1. Мотивация

Традиционный подход «единое хранилище» (Data Warehouse / Lakehouse) предполагает перемещение данных в одну точку. Это создаёт три проблемы:

1. Задержка актуальности — данные в хранилище отстают от источника.
2. Дублирование и стоимость — копирование петабайтов дорого и медленно.
3. Схема-каплинг — потребители привязаны к физической структуре хранилища.

Data Mesh инвертирует модель: каждый домен владеет своими данными и публикует их как продукт, а платформа обеспечивает федеративный доступ. Hugr — инфраструктура этого доступа.

2.2. Компоненты

┌────────────────────────────────────────────────┐
│                  Клиенты                       │
│   Web · BI · Python · MCP/AI                   │
└───────────────────────┬────────────────────────┘
                        │ GraphQL / IPC / REST
┌───────────────────────▼────────────────────────┐
│              Hugr Server (Go)                  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │ GraphQL  │ │ Schema   │ │ Access Control │  │
│  │ API+Subs │ │ Compiler │ │ OAuth2 / RBAC  │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
│  ┌──────────────────────────────────────────┐  │
│  │     DuckDB Analytical Engine (Go)        │  │
│  │  In-process · Колоночный · Vectorized    │  │
│  └──────────────────────────────────────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌────────────────┐  │
│  │  Cache   │ │  CoreDB  │ │ IPC Protocol   │  │
│  │Mem+Redis │ │ metadata │ │  (Arrow)       │  │
│  └──────────┘ └──────────┘ └────────────────┘  │
└──┬──────────┬──────────┬───────────┬───────────┘
   │          │          │           │
┌──▼───┐  ┌───▼────┐ ┌───▼────┐ ┌────▼──────┐
│ PG / │  │SQL Srv │ │DuckLake│ │ REST API  │
│MySQL │  │Azure   │ │Iceberg │ │Arrow Fl.  │
│Parq. │  │        │ │S3/CSV  │ │ Redis KV  │
└──────┘  └────────┘ └────────┘ └───────────┘

DuckDB как ядро — in-process колоночная СУБД для OLAP. Не требует отдельного процесса и сетевого порта, работает с десятками форматов (Parquet, CSV, JSON, GeoParquet, Delta Lake), обеспечивает векторизованное исполнение. Для Hugr это нулевая сетевая задержка между движком и логикой и возможность кросс-источниковых JOIN’ов в памяти.

CoreDB хранит метаданные: источники, каталоги схем, роли, политики доступа. Может быть DuckDB-файлом или PostgreSQL (обязателен для кластера).

Компилятор схем преобразует GraphQL SDL с директивами (`@table`, `@view`, `@function`, `@field_references`, `@join`, `@module`) в логическую модель, из которой генерируются типы, фильтры, агрегации, мутации и sub-query поля для связей.

3. Источники данных: единая точка входа

3.1. Поддерживаемые типы

3.2. Декларативная регистрация

Источник описывается мутацией `insert_data_sources`, после чего его схема компилируется и попадает в общее GraphQL-дерево. Адаптеры и коннекторы писать не нужно.

mutation {
  core {
    insert_data_sources(data: {
      name: "my_llm"
      type: "llm-openai"
      prefix: "my_llm"
      path: "http://localhost:1234/v1/chat/completions?model=gemma-4&timeout=120s"
    }) { name }
  }
}

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

4. GraphQL как универсальный слой доступа

4.1. Автогенерация из схемы

Для каждого табличного объекта компилятор создаёт:

• запросы с `filter`, `order_by`, `distinct_on`, `limit`, `offset`;
• запрос по первичному ключу (`object_name_by_pk`) и уникальным полям;
• агрегации (`object_name_aggregation`) и корзинные агрегации (`object_name_bucket_aggregation`);
• мутации `insert`, `update`, `delete` с типизированными входными структурами;
• фильтровые типы с операторами `eq`, `in`, `gt`, `lt` и вложенными фильтрами по связям;
• sub-query поля для связей (включая M2M), query-time JOIN’ы и пространственные JOIN’ы.

Дата-инженер описывает логическую модель — полный CRUD, агрегации и связи появляются автоматически.

4.2. Подписки

• Streaming LLM completions — токены с событиями `content_delta`, `reasoning`, `tool_use`, `finish`, `error`.
• Pub/Sub — подписка на каналы Redis.
• Keyspace events — мониторинг изменений ключей по паттерну.

4.3. JQ-трансформации

Серверные JQ-преобразования: встроенный `jq()` в GraphQL, REST-эндпоинт `/jq-query`, доступ к переменным через `$var_name`, вложенные GraphQL-запросы из JQ через `queryHugr()`. Это постобработка без выгрузки в Python — группировка, фильтрация, реструктуризация на сервере.

5. AI-возможности: LLM и Embeddings

5.1. Модуль `core.models`

Провайдеры: OpenAI (и совместимые: Ollama, LM Studio, vLLM, Mistral, Qwen, Azure OpenAI), Anthropic (Claude), Google Gemini. Различия форматов абстрагированы.

5.2. Tool Calling и Round-trip

Вызовы инструментов нормализованы. Для Gemini 2.5+ поддерживается `thought_signature` — обязательное поле при отправке результатов инструментов обратно модели. Пайплайн: запрос → `tool_calls` + `thought_signature` → исполнение инструмента → сообщение с `role: “tool”` → полная история в `chat_completion`.

5.3. Thinking Budget

Параметр `thinking_budget` управляет chain-of-thought: задаётся на уровне источника (максимум) и запроса (кап). Модель сначала выдаёт `reasoning`-события, затем `content_delta`.

5.4. MCP-интеграция

Поддержка Model Context Protocol позволяет AI-ассистентам (Claude, Cursor) исследовать схему, выполнять семантический поиск и генерировать/валидировать GraphQL-запросы. Основа для «vibe-аналитики»: LLM строит запросы на естественном языке, Hugr их исполняет.

6. Hugr Apps: расширяемость через Arrow Flight

6.1. Концепция

Hugr Apps — внешние Go-приложения, подключаемые через DuckDB Airport extension (Apache Arrow Flight gRPC). Публикуют в общую GraphQL-схему скалярные функции, таблицы, табличные функции и собственные источники данных (например, PostgreSQL с миграциями).

6.2. Жизненный цикл

Heartbeat: интервал 30 сек, таймаут 10 сек, 3 неудачи → приостановка каталога. При восстановлении каталог перекомпилируется.

6.3. Практический смысл

Бизнес-логику (геокодирование, скоринг, расчёты) можно вынести в отдельный сервис и опубликовать как SQL/GraphQL-функции без изменения основного конвейера.

7. Production-readiness и работа под нагрузкой

7.1. Кластерный режим

• CLUSTER_ROLE: `management` или `worker`.
• Management-нода координирует синхронизацию схем, жизненный цикл источников и конфигурацию хранилищ.
• Worker-ноды получают обновления через push (broadcast) и pull (polling).
• PostgreSQL CoreDB обязателен — все ноды разделяют единую метабазу.

7.2. Кеширование

1. In-memory — горячие данные на каждой ноде.
2. Внешний кеш (Redis / Memcached) — разделяемый, инвалидация при мутациях.

Директива `@cache` управляет кешированием на уровне схемы.

7.3. Производительность

• Нулевая сетевая задержка между логикой и движком.
• Векторизованное колоночное исполнение.
• Поддержка десятков форматов без конвертации.
• Кросс-источниковые JOIN’ы в памяти.
• Filter pushdown — условия `WHERE` передаются на сторону источника (особенно PostgreSQL).

7.4. Безопасность

OAuth2 / OpenID Connect, field-level и row-level security, ролевая модель с предопределёнными фильтрами, автозаполнение контекста пользователя/роли в мутациях.

7.5. Развёртывание

• Docker: `docker run -d --name hugr -p 15000:15000 -v ./schemas:/schemas ghcr.io/hugr-lab/automigrate:latest`
• Kubernetes: Helm-чарты в `hugr-lab/docker` (multi-node, load balancing, кеширование).
• Embedded: Go-пакет `hugr-lab/query-engine`.

7.6. Ограничения

• Планируются коннекторы к SQLite (через DuckDB) и ClickHouse.
• GraphQL как источник данных — в разработке.
• «Talk-to-data» (естественный язык) — анонсирован.

Для высоких нагрузок рекомендуется кластерный режим с PostgreSQL CoreDB и Redis-кешем.

8. Области применения и примеры

8.1. Бэкенд данных для приложений

Единый GraphQL-слой поверх существующих БД: быстрый запуск API, централизованная схема, контроль доступа.

{
  marketing {
    campaigns_aggregation_bucket {
      key { channel { name } }
      aggregations { payments { amount { sum } } }
    }
  }
}

8.2. Data Mesh-платформа

Каждый домен публикует свою схему как модуль. Федеративный доступ через единый API, децентрализованное владение.

8.3. Аналитика и MLOps

OLAP-запросы и пространственные агрегации через GraphQL, экспорт в Arrow IPC → Python (pandas, GeoDataFrame, Jupyter), JQ-трансформации на сервере, цикл Ingestion → Processing → ML → API Access.

8.4. Агентная аналитика (Vibe Analytics)

Через MCP-эндпоинт LLM-агент исследует схему, генерирует запросы, выполняет цепочки и строит JQ-преобразования. Пользователь задаёт вопрос на естественном языке — агент возвращает результат.

8.5. Реал-тайм дашборды

Подключение Grafana/Metabase к Hugr → данные обновляются на каждый запрос, без ETL-задержек, с комбинацией нескольких источников.

8.6. Геопространственные задачи

Нативные пространственные типы, кросс-источниковые spatial JOIN’ы, поддержка GeoParquet, GeoJSON, Shapefiles, агрегации по пространственным отношениям.

9. Итог

Hugr занимает нишу между «тяжёлыми» платформами данных (Databricks, Snowflake) и лёгкими GraphQL-обёртками над одной БД. Его ценность:

• Декларативность — схема через SDL-директивы, полный CRUD генерируется автоматически.
• Федеративность — данные не перемещаются, доступ на месте.
• Производительность — DuckDB in-process даёт колоночную векторизацию без сетевых накладных расходов.
• Расширяемость — Hugr Apps, Extension-источники, AI-модуль, Redis.
• Открытость — MIT, Go-стек, Docker/K8s, embedded-режим.

Для команды, которая хочет дать аналитикам и приложениям единый доступ к разнородным данным без ETL-империи, Hugr — зрелый и прагматичный выбор с понятной траекторией масштабирования.

10. Что ещё: другие инструменты и события из рассылки DuckDB (сентябрь 2026)

Ежемесячная рассылка DuckDB #45 (16 сентября 2026) принесла несколько значимых новостей.

Крупные события

• AWS приобретает DuckLabs (компанию-создателя DuckDB). Проекты DuckDB, DuckLake, Quack остаются под MIT-лицензией и управлением DuckDB Foundation. Сообщество восприняло новость со сдержанным оптимизмом благодаря независимому фонду и открытой лицензии. Однако аналитики предупреждают: «разработчики не должны путать неизменность лицензии с неизменностью проекта — люди, пишущие код DuckDB, теперь получают зарплату от AWS, а зарплата влияет на дорожную карту».
• MotherDuck приобретает Tower.dev для интеграции рантайм-инфраструктуры в MotherDuck Flights — AI-агенты смогут выполнять задачи дата-инжиниринга и публиковать данные как API. Tower — это hosted-рантайм для Python-пайплайнов, обеспечивающий песочницу, планирование и наблюдаемость для кода, написанного LLM.

DuckDB 2.0 preview (кодовое имя «Cyanoptera»)

Доступна preview-версия с клиент/серверным режимом через Quack и `CONNECT`, новым PEG-парсером SQL, переработанным C API для расширений, новым форматом хранения по умолчанию. Асинхронный I/O для S3, переписанный движок рекурсивных CTE и оптимизированный тип VARIANT. Релиз запланирован на октябрь 2026.

Экосистема

Эти новости подтверждают вектор: экосистема DuckDB стремительно расширяется от аналитического движка в сторону полноценной платформы данных — с клиент/серверным режимом, AI-интеграцией и корпоративными сценариями. Hugr органично встраивается в эту экосистему, используя DuckDB как вычислительное ядро и добавляя слой декларативного доступа, который превращает сырой движок в управляемую платформу данных.

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

Наткнулся на эту статейку, но доступа не имел к сожалению, а написал с ИИшечкой. Не знаю как получилось, вам оценивать.

https://www.rbc.ru/business/16/09/2026/6aa39f109a7947237af8c218

Кстати там есть еще интересные исследования, вот например такое

можно скачать тут – Игра на нервах Есть еще 28 файлов.

Вот тут еще небольшое введение https://www.kommersant.ru/doc/8956332

https://www.kommersant.ru/doc/8956332

Исследование СберУниверситета описывает этот феномен как мазохистическое лидерство. Важно подчеркнуть: речь идёт не о клиническом диагнозе и не о характеристике конкретного человека, а о системной роли, которую организация нередко сама подпитывает и воспроизводит. Логика этой роли проста: если всё спокойно, значит, я недостаточно нужен. Поэтому вокруг лидера регулярно возникают авралы, срочные совещания, ночные переписки и «героические» спасательные операции. Проблема в том, что часто эти пожары создаются самой системой управления — или самим руководителем.

Масштаб явления

По данным исследования СберУниверситета «Игра на нервах? Деструктивные проявления в коммуникациях руководителя» (осень 2024 года, 518 респондентов), 72% сотрудников регулярно сталкиваются хотя бы с одним из девяти видов деструктивного поведения со стороны руководителя. Самое распространённое — отсутствие эмпатии и сочувствия: с этим систематически сталкиваются 54% респондентов, а 87% испытывают негативное воздействие из-за такого поведения — например, когда работают по ночам или в выходные. При этом 42% указывают на слабые управленческие навыки начальства, а 47% демотивирует обесценивание их работы.

Почему такие лидеры появляются

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

Есть и психологический фактор. Для мазохистического лидера перегрузка становится способом самоутверждения. Он привыкает быть незаменимым, получать признание через жертву и контролировать команду через постоянное напряжение. Иногда такой руководитель искренне уверен, что иначе люди «расслабятся» и работа развалится. Как отмечают эксперты СберУниверситета, за таким поведением часто стоят неосознанные защитные механизмы: руководитель может выступать одновременно в роли «жертвы» обстоятельств и «преследователя» по отношению к подчинённым.

Как страдание становится нормой

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

Со временем компания теряет способность отличать продуктивность от суеты. Совещаний становится больше, решений — меньше. Люди боятся брать паузу, признавать ошибки и говорить о реальных рисках. Хронический стресс снижает внимание, ухудшает качество решений и повышает текучесть кадров. По данным исследования Русской Школы Управления, к концу 2025 года 48% работающих россиян отмечали у себя симптомы эмоционального выгорания, а 68% говорили о постоянной усталости. Выгорание перестаёт быть личной проблемой конкретного человека и становится управленческим дефектом всей системы.

Героизм в кризисе и героизм как норма — не одно и то же

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

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

Методика диагностики: диаграмма Исикавы

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

«Голова рыбы» — это сама проблема: устойчивое воспроизводство мазохистического лидерства. «Рёбра» — пять узловых блоков, по которым распределяются провоцирующие факторы:

Практический алгоритм: соберите рабочую группу из 5–7 человек (руководители, HR, сотрудники), за 30–40 минут сформулируйте проблему в «голове рыбы», затем предложите участникам записать факторы на стикерах и распределить их по блокам. После этого выберите три корневые причины, которые получают больше всего голосов, и под каждую определите одно конкретное действие с ответственным и сроком. Такой анализ позволяет увидеть, что мазохистическое лидерство — не личная патология, а системный сбой, в котором сходятся культурные, управленческие и психологические факторы.

Что могут сделать компании

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

• Текучесть кадров — особенно в тех подразделениях, где руководитель демонстрирует мазохистический стиль. Резкий рост — первый сигнал.
• Уровень выгорания — измеряется через короткие пульс-опросы (например, раз в квартал): «Как часто за последний месяц вы чувствовали эмоциональное истощение?»
• Доля переработок — процент сотрудников, регулярно работающих сверх нормы. Если он стабильно высок, это не «преданность», а системный сбой.
• Количество задач, закрытых без аврала — позитивная метрика, которая смещает фокус с «тушения пожаров» на предотвращение.
• eNPS — полезен, но с оговоркой: он измеряет лояльность, а не выгорание. Исследования показывают, что «промоутеры» могут увольняться чаще всех: парадокс «удовлетворённого увольняющегося». Поэтому eNPS стоит дополнять прямым вопросом: «Планируете ли вы остаться в компании через год?».

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

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

Что делать сотрудникам

Если человек оказался в команде мазохистического лидера, важно не подыгрывать культуре страдания. Вот чек-лист красных флагов, которые стоит отслеживать:

• Срочность без причины — задачи объявляются «горящими», хотя объективных оснований для этого нет.
• Культ переработок — работать допоздна и в выходные считается нормой, а не исключением.
• Обесценивание — ваши результаты принижаются или игнорируются, компетентность ставится под сомнение.
• Наказание за границы — попытка обозначить рабочее время или отказаться от внеурочной задачи воспринимается как нелояльность.
• Хронический кризис — авралы повторяются каждую неделю, а «герои» регулярно «спасают» проекты.

Если человек оказался в такой среде, важно постепенно переводить разговор из эмоциональной плоскости в управленческую. Например, вместо «мы опять ничего не успеваем» — спрашивать: какие задачи приоритетны? Что можно перенести? Кто принимает решение? Какие риски мы видим заранее? Такой подход возвращает ответственность в систему, а не оставляет её на уровне личного героизма. Полезно фиксировать договорённости письменно, обозначать границы рабочего времени и показывать связь между хаосом и потерей качества. Если руководитель готов к диалогу, это может изменить ситуацию. Если нет — у сотрудника появляется более ясная картина: проблема не в его слабости, а в токсичной управленческой модели.

Что почитать по теме

• Дэвид Дотлих, Питер Кейро. «Темная сторона силы» — о том, как сильные стороны руководителя превращаются в критические недостатки, и о 11 наиболее распространённых деструкторах.
• Лора Ловетт. «Токсичный начальник» — практические стратегии для выживания и обретения контроля над карьерой, включая чек-лист для определения типа токсичного руководителя.
• Кэри Купер. «Организационный стресс» — фундаментальный труд о выгорании как особой форме стресса и организационных условиях его возникновения.
• Эрих Фромм. «Бегство от свободы» — классический психоаналитический анализ садо-мазохистских механизмов в отношениях власти и подчинения.
• Исследования СберУниверситета — «Игра на нервах? Деструктивные проявления в коммуникациях руководителя» и «Демотивирующее поведение руководителей» — доступны на сайте организации.

Вместо вывода

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

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

Бежит кучка ежиков, вдруг вожак орёт: «Стой!!!» — все ежи встали, снова вожак орёт: «Пастись!!!» — все ежи пасутся, а вожак про себя думает: «Хы… Ну чем не кони!»

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

День первый: поездка в детский хоспис

Всю ту неделю я чувствовал, что мне катастрофически не хватает физической активности. Сидячая работа, встречи, дедлайны — тело требовало движения и какой-то разрядки. Но тратить время и силы на спортзал не хотелось — хотелось чего-то нового и свежего. И тут подвернулась возможность съездить от компании в Московский областной хоспис для детей – ГБУЗ МО «МОХД» — помочь с благоустройством территории и по хозяйству.

Это учреждение — первое в Подмосковье и одно из первых в России, оно открылось в 2019 году при поддержке благотворительного фонда «Бумажная птица». Хоспис оказывает паллиативную помощь, и здесь важно всё: не только медицинская, но и социальная, психологическая и духовная поддержка.

Территория оказалась невероятно красивой. Ухоженный парк, аккуратные дорожки, здание в усадебном стиле — на фотографиях, которые я сделал, это отлично видно. Мы помогали по хозяйству приводить в порядок территорию: что-то подстригали, что-то убирали, где-то просто наводили красоту и красили. Физическая работа на свежем воздухе — именно то, что было нужно. Приехал без задних лап.

А после — «по-императорски» откушали на террасе. Честно, это был один из самых вкусных и желанных обедов за последнее время. Не потому, что кухня была ресторанной или фуршетной (всё было очень достойно), а потому, что после реального дела и на таком красивом фоне еда воспринимается иначе. В тот день я спал как убитый — коллегам я этого не говорил, но это было фактом. Надо будет повторить — и пользу принёс, и сам отвлёкся от города и текущих дел.

Кстати, если вы тоже хотите найти подобные мероприятия, очень удобно пользоваться платформой dobro.ru (DoBro — «Просто Делай Бро», звучит! :) ) — там собраны тысячи волонтёрских событий: от помощи приютам до экологических акций. Заполняете профиль, выбираете то, что цепляет, подаёте заявку — и вперёд.

День второй: ярмарка RWB Участие в офисе

А сегодня в офисе прошла благотворительная ярмарка RWB Участие. Это уже не первая такая ярмарка. Два раза утром я проходил мимо, а на третий раз выкроилось время — заглянул и не прогадал. Все три раза, кстати, коллеги толпились вокруг и разглядывали все.

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

И не прогадал. Во-первых, случайно встретил Татьяну Владимировну Ким — основателя Wildberries, главу РВБ. Встреча была неожиданной, но очень тёплой. Ну и посчастливилось сделать фото на память.

Во-вторых, купил книгу. И да, я знал, что книги есть на Wildberries, но не думал, что их можно купить прямо на ярмарке в офисе. Бумажные книги приятнее покупать физически — прикоснуться к бумаге, полистать. Теперь у меня есть экземпляр с автографом — но его я вам не покажу, это личное :).

О какой книге речь? О сборнике историй партнёров Wildberries. В предисловии Татьяна Ким пишет:

«Эта книга не о брендах, а о людях, которые изменили свою жизнь раз и навсегда… Дело не в удаче, а в подходе и отношении, в ваших усилиях и желании сделать самое лучшее. Можно сказать, что эта книга о мечте — большой, искренней, исполнимой!»

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

Вторая книга — «Я — Сания» Дианы Машковой и Сании Испергеновой. Это история сироты, написанная в соавторстве с известной писательницей. Книга вышла в рамках проекта «Библиотека благотворительного фонда “Арифметика добра”». Тяжёлая, но важная история. Записал в план на чтение и в закладки.

Почему это важно

Всё это — и поездка в хоспис, и ярмарка — для меня не просто «мероприятия». Это напоминание о том, что помогать легко. Можно найти мероприятие на dobro.ru и поехать волонтёрить. Можно зайти на ярмарку в офисе и купить что-то у фонда. Можно просто перевести деньги через платформу RWB Участие — там собраны верифицированные НКО, и за каждый благотворительный перевод начисляется кешбэк 3% ягодками.

Лето закончилось, но добрые дела не имеют сезонности. Я точно знаю, что буду повторять этот опыт — и в хосписе, и на ярмарках. Потому что после таких дней действительно лучше спишь. И это не только про физическую усталость. Это про ощущение, что день прожит не зря. Кстати, ещё не скоро, но зимой организуется «Ёлка желаний» — тоже очень интересное благотворительное мероприятие, где можно подарить подарки детям и сделать реальностью чью-то мечту.