о книге «Data Contracts» или как договориться о данных в эпоху хаоса и вернуть им ценность

Введение: Кризис доверия в мире данных
Книга Чада Сандерсона и Марка Фримена «Data Contracts» выходит в момент глубокого кризиса в индустрии данных. Несмотря на триллионы долларов инвестиций в Modern Data Stack, облака и ИИ, компании всё чаще сталкиваются с парадоксом: данных больше, чем когда-либо, а извлекаемая ценность — под вопросом. Дашборды врут, модели ML ошибаются, а инженеры данных погребены под лавиной инцидентов. Авторы дают диагноз этой болезни: «данные долг» (data debt), и предлагают радикальное лечение: «данные контракты» (data contracts).

Часть 1: Диагноз — Эпидемия данных долга
Авторы проводят читателя через историческую эволюцию, объясняя, как мы пришли к текущему хаосу.

1. Золотой век и падение Хранилищ Данных: Раньше централизованные хранилища данных, созданные архитекторами, обеспечивали «единый источник истины». Это было медленно, дорого, но надежно.
2. Agile, микросервисы и «дамп данных»: Софтверные компании, движимые скоростью, убили роль архитектора данных. Данные перестали проектировать — их начали «сливать» в data lakes. Разрыв между командами, создающими данные (продуктовые разработчики, OLTP) и использующими их (аналитики, дата-сайентисты, OLAP), стал пропастью.
3. Иллюзия Modern Data Stack: Такие инструменты как Snowflake, Fivetran и dbt решили проблему «как» работать с данными, но усугубили проблему «что» и «почему». Они упростили перемещение и трансформацию беспорядочных данных, легализовав отсутствие дисциплины. Результат — взрывные затраты, непонятные SQL-запросы-монстры и полная потеря доверия.

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

Часть 2: Новый императив — Data-Centric AI
Авторы блестяще связывают кризис данных с новой парадигмой в машинном обучении. Эндрю Нг провозгласил сдвиг от model-centric AI (бесконечная настройка алгоритмов) к data-centric AI (систематическое улучшение качества данных для обучения).

• Почему это важно? Модели, особенно с появлением больших языковых моделей (LLM), становятся товаром. Любой может вызвать мощнейшую модель через API. Конкурентное преимущество теперь создается не алгоритмом, а качественными, уникальными данными, на которых он обучается и работает.
• Парадокс: В момент, когда бизнесу как никогда нужны чистые, надежные данные для ИИ, его инфраструктура данных наименее к этому готова. Data-Centric AI требует фундамента, которого нет — управляемого, контрактного подхода к данным.

Часть 3: Лечение — Data Contracts как API для доверия
Data Contracts — это ядро предлагаемого решения. Это не юридические документы, а машиночитаемые соглашения, оформленные как код.

• Что это такое? Контракт между производителем данных (например, сервис, который генерирует события о покупках) и потребителем данных (например, команда аналитики, строящая отчет по выручке).
• Что в него входит? Схема данных (типы, имена полей), семантика (что означает каждое поле, бизнес-правила), соглашения об уровне обслуживания (SLAs — частота обновления, задержка), правила обработки конфиденциальных данных (PII).
• Как работает? Контракт устанавливается через API. При попытке изменить источник данных (удалить поле, изменить тип) система проверяет все зависимые контракты и либо блокирует изменение, либо требует скоординированной миграции. Это автоматизирует коммуникацию и создает «защитные ограждения».

Часть 4: Практика — Качество данных как измеримый процесс
Авторы уходят от утопии «идеальных данных» к прагматичному управлению качеством. Они предлагают измерять его через:

• Опережающие индикаторы: Наличие владельцев у источников данных, уровень доверия команд к данным (измеряется через опросы), объем данных долга (сложность запросов, количество backfill-задач).
• Запаздывающие индикаторы: Время простоя данных (data downtime), количество инцидентов с реальным бизнес-влиянием (например, ошибочный отзыв товара).

Главная мысль: нужно говорить с бизнесом не о «качестве», а о рисках и потерях денег из-за его отсутствия.

Заключение: Возвращение к дисциплине через инновации
«Data Contracts» — это манифест за возвращение инженерной дисциплины в мир данных, но на новом уровне. Это не призыв вернуться к медленным централизованным хранилищам. Это предложение создать децентрализованную, но управляемую экосистему данных, где скорость микросервисов сочетается с надежностью контрактов.

Книга является обязательным чтением для:

• Руководителей данных (CDO, Head of Data), чтобы понять стратегический ответ на вызовы data debt и Data-Centric AI.
• Инженеров данных и архитекторов, ищущих практические методы наведения порядка.
• Продуктовых менеджеров и разработчиков, которые должны осознать, что их данные — это продукт для внутренних клиентов.
• Дата-сайентистов и аналитиков, уставших от нестабильных данных.

Data Contracts — это больше, чем технология. Это философия сотрудничества, которая превращает данные из источника постоянных проблем в настоящий актив, способный обеспечить конкурентное преимущество в эпоху ИИ.

Приложение пример полей и контракта данных

Атрибуты контракта (обязательные и опциональные)

version: 1.0
domain: sales
owner: team-sales@company.com
data_product: customer_events
schema:
  type: avro/json
  definition: { ... }
slas:
  freshness: "5m"
  completeness: "99.9%"
security:
  pii_fields: ["email", "phone"]
  masking: dynamic
quality_checks:
  - type: null_check
    columns: ["user_id"]
  - type: range_check
    column: "amount"
    min: 0
consumers:
  - analytics_team
  - ml_team
lifecycle:
  retention_days: 365
  archive_after: 90

https://github.com/marmotdata/marmot

Marmot is an open-source data catalog designed for teams who want powerful data discovery without enterprise complexity. Built with a focus on simplicity and speed, Marmot helps you catalog assets across your entire data stack – from databases and APIs to message queues and data pipelines.

Unlike traditional catalogs that require extensive infrastructure and configuration, Marmot ships as a single binary with an intuitive UI, making it easy to deploy and start cataloging in minutes.

Built for Modern Data Teams

Deploy in Minutes: Single binary, Docker, or Kubernetes – no complex setup required
Powerful Search: Powerful query language with full-text, metadata, and boolean operators
Track Lineage: Interactive dependency graphs to understand data flows and impact
Flexible Integrations: CLI, REST API, Terraform, and Pulumi – catalog assets your way
Lightweight: PostgreSQL-backed with minimal resource requirements

Очень красивые и редкие

https://missing-semester-rus.github.io

Может кому надо?

В современном маркетинге данные — это новая нефть, а рекламный идентификатор (Advertising ID) — это трубопровод, по которому эта нефть течет. От смартфона в кармане до умного телевизора в гостиной: каждое устройство имеет свой цифровой паспорт.

В этой статье мы разберем не только скрытую механику «рекламной слежки», но и юридические риски для бизнеса в РФ, новые технологии обхода блокировок и то, как клиентский опыт (CX) меняется в эпоху тотальной приватности.

1. Зоопарк идентификаторов: Кто есть кто

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

📱 Мобильные устройства (MAID — Mobile Advertising IDs)

Это самые ценные идентификаторы, так как смартфон является наиболее персональным (“интимным”) устройством.

• IDFA (Identifier for Advertisers): Стандарт Apple (iOS). После внедрения *App Tracking Transparency (ATT)* в iOS 14.5 доступ к нему закрыт по умолчанию.
  > Важно: Лишь 20-30% пользователей в мире нажимают «Разрешить» (Allow Tracking). Это создало огромную «слепую зону» в аналитике.
• GAID (Google Advertising ID) / AAID: Аналог для Android. Позволяет связывать активность пользователя между разными приложениями. Google также движется в сторону ограничения доступа через инициативу Privacy Sandbox on Android.

📺 Телевизоры и Set-Top Box (CTV IDs)

С ростом Smart TV и стримингов маркетологи теперь трекают пользователей «на диване».

• Примеры: TIFA (Samsung), Roku ID, Amazon Fire TV ID.
• Логика Household (Домохозяйство): В отличие от личных смартфонов, эти ID часто привязаны к семье.
  • *Инсайт эксперта по данным:* Это создает проблему «шумных данных». Если вы рекламируете женские духи, а телевизор смотрит муж или ребенок, атрибуция будет ошибочной. Для очистки данных используются Cross-Device графы, связывающие TV ID с мобильными телефонами, находящимися в той же Wi-Fi сети.

🌐 Веб-идентификаторы

• Third-Party Cookies: Старейший и умирающий стандарт. Текстовые файлы, оставляемые рекламными сетями (не владельцем сайта) в браузере.
• Stable IDs / Hashed Emails: Новая валюта рынка. Это зашифрованные (хэшированные) адреса электронной почты или номера телефонов. Используются в таких решениях, как *Unified ID 2.0*.

2. Механика: Как они строятся и живут

Формула генерации

Большинство мобильных ID (GAID, IDFA) представляют собой UUID (Universally Unique Identifier) версии 4. Это 128-битное число.

$$ P(collision) \approx \frac{n^2}{2 \times 2^{128}} $$

Вероятность совпадения двух таких ID астрономически мала.

• Пример: `123e4567-e89b-12d3-a456-426614174000`
• Генерация: Алгоритм использует криптографически стойкий генератор случайных чисел (CSPRNG) + энтропию системы (время запуска, «шум» железа).

Жизненный цикл и безопасность

Главное отличие рекламного ID от аппаратного (IMEI) — возможность сброса (Resettability).

1. Действие пользователя: В настройках конфиденциальности нажимается «Сбросить рекламный ID».
2. Реакция ОС: Генерируется новый UUID.
3. Результат: Для рекламных сетей устройство становится «чистым листом». История интересов разрывается.

3. E-commerce: Сквозь экраны к покупке

В интернет-коммерции ID — это клей, собирающий разрозненные клики в путь покупателя (Customer Journey Map).

Сквозная аналитика (Cross-Device)

Как понять, что телефон `User_A` и ноутбук `Cookie_B` — это один человек?

1. Deterministic (Точный метод): «Золотой стандарт». Пользователь залогинился в магазине под своим Email на обоих устройствах. Связка 100% достоверна.
2. Probabilistic (Вероятностный метод): Система видит, что телефон и ноутбук ежедневно выходят в сеть с одного IP-адреса Wi-Fi в одно время, имеют похожие паттерны посещения сайтов. Алгоритмы с вероятностью 90%+ «склеивают» профили в один Household.

Механика таргетинга (RTB – Real Time Bidding)

Процесс показа рекламы занимает менее 100 миллисекунд:

1. Вы смотрите кроссовки в приложении (система фиксирует ваш `GAID`).
2. Вы открываете новостной сайт. Сайт отправляет ваш `GAID` на рекламную биржу.
3. DSP (платформа закупки) узнает ваш ID в базе сегментов: *«Это тот же, кто смотрел Nike 5 минут назад!»*.
4. Происходит мгновенный аукцион, ставка выигрывает, и вам показывается баннер.

4. Феномен Amazon Ads и Retail Media

Amazon (и его аналоги в РФ) стоит особняком. Это закрытая экосистема (Walled Garden), чья сила не в технологиях трекинга, а в транзакционных данных. Им не нужно *угадывать*, что вы хотите купить, они *знают*, что вы покупаете.

Идентификатор Amazon

В основе лежит не «летучий» UUID устройства, а Internal Customer ID, жестко привязанный к аккаунту.

• Формула матчинга: Для обмена данными с внешним миром используется Hashed Email (HEM). Ваш email превращается в необратимую строку (обычно SHA-256).
• Clean Rooms (AMC): Amazon Marketing Cloud позволяет крупным брендам загружать свои CRM-данные в защищенную среду, где они пересекаются с данными Amazon. Рекламодатель получает инсайты (например, “Клиенты, купившие кофемашину у нас на сайте, покупают капсулы на Amazon”), но не видит персональных данных конкретных людей.

5. Война за приватность и обходные пути

Индустрия находится в состоянии холодной войны между запросом на приватность и эффективностью.

Главные сложности

• Apple ATT: Обрушение эффективности рекламы Facebook на iOS. Стоимость привлечения клиента (CAC) выросла на 40-60%.
• Смерть Cookies: Google Chrome (хоть и откладывает полное отключение) внедряет Privacy Sandbox, заменяя индивидуальные куки на FLoC/Topics API (группировку по интересам).
• Блокировщики: AdBlock режет запросы к доменам трекеров. (на уровне DNS, например AdGuard)

Как рынок обходит блокировки? Технический Deep Dive

1. Server-Side Tracking (S2S / CAPI):
   Вместо отправки данных пикселем из браузера (JS), данные о покупке отправляются напрямую с бэкенда магазина на сервер рекламной системы (например, через Facebook Conversions API).
• Плюс:* Не блокируется AdBlock и браузерами. Точность данных выше.
• Минус:* Сложная техническая реализация. Требует согласия пользователя на передачу данных.

2. Fingerprinting (Серый метод):
   Сбор уникальных параметров устройства без использования cookie:
• `Screen Resolution` + `User Agent` + `Battery Level` + `System Fonts` + `AudioContext`
• Такой “цифровой отпечаток” уникален для 95% пользователей. Apple и Google активно борются с этим методом, считая его нарушением приватности.

Итог: Тренды 2025+ и рекомендации

Эра «дикого запада», когда можно было незаметно следить за каждым шагом, заканчивается. Мы переходим в эру агрегированных данных и доверительного маркетинга (Zero-Party Data).

Ключевые тренды:

1. First-Party Data — король: Компании, владеющие собственными данными и прямым контактом с клиентом (Email, App), выигрывают. Зависимость от Facebook становится токсичной.
2. Retail Media Networks: Бум рекламных сетей маркетплейсов. Они обладают данными о деньгах, а не о кликах.
3. AI вместо Cookies: Алгоритмы машинного обучения будут «достраивать» потерянные данные. Например, Google GA4 уже использует моделирование конверсий для пользователей, отказавшихся от трекинга.

✅ Рекомендация

• Инвестируйте в CDP (Customer Data Platform): Собирайте все данные (CRM, сайт, приложение) в одном месте.
• Внедряйте Server-Side трекинг: Это единственный способ сохранить точность аналитики в будущем.
• Тестируйте новые каналы: Telegram Ads (работает без кук, на контексте каналов) или Retail Media.
• Аудит согласий: Проверьте формы сбора данных на сайте. Галочка «Согласен на рекламную рассылку» должна быть отделена от «Согласен на обработку ПДн». Но мне, если честно, не нравится такой подход. Я бы сделал так – Типа Посмотри 10 рекламных роликов, и спи спокойно сегодня до 12, больше показывать сегодня не буду типа)))
• Обезличивание: Используйте методы обезличивания (деперсонализации) при передаче данных партнерам, как того требуют новые правила consultant.ru.
• Цели обработки: Четко прописывайте цели в политике конфиденциальности (например, не просто “маркетинг”, а “таргетирование рекламы в сетях Яндекса”) rppa.pro. Кстати, хороший справочник.

куча разного софта есть, но этот очень похож на YNAB – который кстати удобный, но платный

https://github.com/actualbudget/actual

Пробуйте ...

Мне еще нравится https://ledger-cli.org но это для особо упоротых и командной строки. :)

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

В этом обзоре мы разберем ключевые события, техно-потери и главные приобретения, сформировавшие ландшафт года.

Оригинал тут: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html?utm_source=tldrdev или на интересном канале https://t.me/five_minutes_of_data

🚀 Главные тренды 2025 года

1. Доминирование PostgreSQL и его экосистемы

PostgreSQL окончательно закрепил за собой статус “стандарта де-факто”. Выход PostgreSQL 18 в ноябре 2025 года принес долгожданную подсистему асинхронного ввода-вывода (AIO), что позволяет базе данных меньше зависеть от кэша операционной системы. Также была добавлена поддержка *skip scans*, что значительно ускоряет запросы по B-Tree индексам, даже если пропущены ведущие ключи (префиксы).

Но главный “движ” происходил не в ядре, а вокруг него:

• Распределенный Postgres: В этом году развернулась настоящая битва за горизонтальное масштабирование (шардинг). Проекты вроде Multigres (от Supabase) и Neki (от PlanetScale) нацелились на решение проблемы масштабирования записи, бросая вызов таким ветеранам, как Citus и YugabyteDB.
• Война поглощений: Крупнейшие игроки скупали Postgres-стартапы. Databricks заплатил 1 млрд долларов за Neon, а Snowflake выложил 250 млн долларов за Crunchy Data. Это показывает, что облачные гиганты хотят владеть своими собственными “движками” Postgres, а не просто хостить open-source.

2. Взлет MCP (Model Context Protocol)

Если 2023-й был годом векторных индексов, то 2025-й стал годом MCP от Anthropic. Это стандартизированный протокол (на базе JSON-RPC), позволяющий LLM взаимодействовать с внешними инструментами и базами данных без написания кастомного связующего кода (glue code).

Практически все вендоры (MongoDB, Neo4j, Redis, Snowflake, ClickHouse) выпустили свои MCP-серверы. Теперь AI-агент может самостоятельно “изучить” схему базы данных и выполнить SQL-запрос.

Важно: Это открывает огромные возможности, но и создает риски безопасности. Агент с правами администратора может случайно выполнить `DROP DATABASE`. Внедрение MCP требует жесткого разграничения прав доступа и использования прокси с защитными механизмами.

3. Битва форматов файлов и “Смерть Parquet”?

Неожиданно обострилась конкуренция в области файловых форматов для аналитики. Старый добрый Parquet столкнулся с новыми претендентами: Vortex (от SpiralDB), Nimble (Meta), Lance и другие.
Причина — рост использования GPU для аналитики и необходимость в более быстрых декодерах. Parquet, созданный более 10 лет назад для Hadoop, начинает отставать в эпоху современного “железа” и случайного доступа к данным.

• Появление DuckLake указывает на попытки переосмыслить архитектуру Data Lakehouse.

4. Рост локальных и Edge баз данных

На фоне развития Local AI (запуск нейросетей на устройствах пользователя) вырос спрос на базы данных, работающие “на краю” (on-device). Такие решения, как Turso (на базе libSQL/SQLite) и оптимизированные версии DuckDB, позволяют обрабатывать данные прямо на ноутбуке или смартфоне пользователя, снижая задержки и повышая приватность. AI больше не обязан жить только в облаке.

☠️ Кладбище технологий 2025

Не все пережили этот год. Рынок безжалостен к тем, кто не нашел свою нишу или бизнес-модель.

• Voltron Data: “Супергруппа” разработчиков (создатели Apache Arrow, Ibis и др.), собравшая $110 млн, не смогла выпустить коммерчески успешный продукт Theseus (GPU-ускоренная база). Они закрылись.
• PostgresML: Идея запускать ML прямо внутри Postgres была хорошей, но убедить компании мигрировать на их платформу оказалось сложно.
• Fauna (прекращение поддержки собственного языка?): Хоть компания и жива, игнорирование SQL в начале пути стоило им дорого. В 2025 году стало окончательно ясно: если у тебя нет SQL — ты теряешь рынок.
• Derby: Один из старейших Java-движков (экс-IBM Cloudscape) перешел в режим “read-only” (архивации). Эпоха ушла.

🏆 Интересные технические новинки

🔥 Скандал года: MongoDB против FerretDB

Судебный иск MongoDB против FerretDB стал самым громким юридическим событием. FerretDB предлагает open-source прокси, который конвертирует запросы MongoDB в SQL для PostgreSQL. MongoDB обвинила их в нарушении прав на торговую марку и патенты.
Это дело ставит под вопрос саму возможность создания совместимых API. Если Oracle проиграла Google в битве за Java API, то исход битвы за API баз данных пока не ясен.

МненИИе: Что нас ждет в 2026

*Раздел подготовлен на основе анализа трендов и экстраполяции текущих событий.*

1. “Агентификация” баз данных:
   В 2026 году базы данных перестанут быть пассивными хранилищами. Мы увидим первые промышленные внедрения Autonomous DBA Agents — AI-агентов, которые живут внутри базы, сами строят индексы, оптимизируют запросы в реальном времени и даже исправляют простые ошибки в данных без участия человека. MCP станет стандартом для всех Enterprise-решений.

2. GPU становится стандартом для OLAP:
   Неудача Voltron Data не остановит тренд. Просто GPU-ускорение станет не отдельным продуктом (“GPU Database”), а опцией внутри существующих гигантов (Snowflake, Databricks, PostgreSQL). Запросы будут прозрачно делегироваться на видеокарты там, где это эффективно. Традиционные CPU-only аналитические системы начнут проигрывать в соотношении цена/производительность.

3. Кризис “Open Source” лицензий:
   На фоне исков (как у MongoDB) и желания облачных провайдеров (AWS, Azure) забирать себе всю прибыль от open-source проектов, мы увидим появление новых, более жестких лицензий (наподобие BSL), которые фактически запрещают конкуренцию со стороны облаков, но остаются открытыми для пользователей. Понятие “Open Source” будет размываться в сторону “Source Available”.

4. Смерть специализированных векторных баз:
   Векторные базы данных как отдельный класс продуктов (Pinecone, Weaviate и т.д.) столкнутся с экзистенциальным кризисом. PostgreSQL, Oracle, MongoDB и Elasticsearch уже интегрировали векторный поиск достаточно хорошо для 95% задач. Большие специализированные игроки будут куплены (как Pinecone готовился к продаже в 2025), а мелкие — исчезнут.

2026 год обещает быть годом, когда искусственный интеллект окончательно “поселится” внутри СУБД, а граница между кодом приложения и базой данных станет еще более прозрачной.

Что то вспомнилось мне, решил посмотреть и дополнить. Как то давно был на лекции Губко, очень интересно рассказывал о фракталах. Оригинал тут есть: https://www.klex.ru/1yt1

М.В. Губко «Управление организационными системами с коалиционным взаимодействием участников» (ИПУ РАН, 2003).

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

1. Анализ

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

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

Методология: Аппарат кооперативной теории игр (C-ядро, вектор Шепли, решения в угрозах и контругрозах) интегрированный в задачи управления (стимулирование, распределение ресурсов).

2. Краткое содержание по главам

Глава I. Модели коалиционного взаимодействия

Автор проводит ревизию теории кооперативных игр для нужд управления.

• Выбор концепции решения: В качестве основного критерия устойчивости коалиции выбрано C-ядро (Core). Если C-ядро не пусто, существует такое распределение выигрыша, что ни одной группе не выгодно отделяться.
• Проблема: Для многих игр C-ядро пусто (система неустойчива). В таких случаях автор предлагает использовать концепцию решения в угрозах и контругрозах (уточнение переговорного множества), чтобы предсказать, какие коалиции наиболее вероятны.

Глава II. Взаимодействие при полной информации (Стимулирование)

Здесь рассматриваются ситуации, где Центр знает параметры агентов, но агенты могут кооперироваться.

• Веерные структуры: В простой структуре (один начальник — много подчиненных) показано, что если технологии позволяют агентам перераспределять работу, они могут «оптимизировать» выполнение плана так, что Центру это безразлично (он получает результат), но агенты выигрывают за счет перераспределения усилий.
• Матричные структуры: Рассмотрена проблема двойного подчинения. Доказано, что полная кооперация менеджеров среднего звена (проектов и отделов) часто невозможна без специального согласования интересов с высшим руководством.
• Формирование состава: Интересный вывод: агенты могут сами исключать неэффективных участников из системы («увольнять» коллег), перераспределяя их задачи и зарплату между собой, если это выгодно коалиции.

Глава III. Взаимодействие с сообщением информации (Распределение ресурсов)

Рассматривается ситуация, когда Центр не знает истинных потребностей агентов, а агенты подают заявки.

• Системы приоритетного распределения ресурсов проанализированы на устойчивость к сговору.
• Доказано, что объединение в коалиции невыгодно агентам, если полезность *нетрансферабельна* (нельзя передать выигрыш другому).
• При *трансферабельной* полезности (можно передавать деньги/ресурс) найдены условия сбалансированности игры. Показано, что наличие у Центра априорной информации (например, знание, что потребность агента лежит в определенном диапазоне) резко повышает эффективность управления и устойчивость к сговору.

3. Дополнительные знания (контекст)

Чтобы глубже понять работу, стоит добавить знания, которые выходят за рамки текста 2003 года или подразумеваются “между строк”:

1. Связь с Mechanism Design: Работа Губко лежит в русле мировой теории *Mechanism Design* (Гурвич, Маскин, Майерсон). Однако западная школа чаще фокусируется на *Coalition-Proof Nash Equilibrium* (равновесие, устойчивое к коалициям), в то время как Губко адаптирует понятие C-ядра.
2. Эффект «Зайца» (Free Rider Problem): В работе мало акцента на поведенческую экономику, но коалиции часто разваливаются не из-за математической невозможности деления выигрыша, а из-за недоверия и желания отдельных участников «проехать зайцем» за счет усилий коллектива.
3. Блокчейн и DAO: Современные децентрализованные автономные организации (DAO) сталкиваются ровно с теми же проблемами, что описаны в Главе III. Механизмы голосования и распределения токенов часто атакуются именно коалициями пользователей (sybil attacks или сговор «китов»). Математика из этой книги применима к криптоэкономике.
4. Асимметрия информации: Книга подтверждает фундаментальный закон кибернетики: эффективность управления ограничена степенью информированности Центра. Уменьшение неопределенности (знание диапазонов пиков функций полезности) прямо конвертируется в устойчивость системы.

4. Итог

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

Главное достижение работы — формулировка условий (на свойства целевых функций и механизмов распределения), при которых интересы максимальной коалиции (всех участников) совпадают с интересами Центра. Это состояние называется полной сбалансированностью.

---

5. Рекомендации и переосмысленные выводы

На основе анализа и современных реалий менеджмента, предлагаю следующие выводы и рекомендации для практиков:

Переосмысленные выводы:

1. Коалиция — не враг, а инструмент: Традиционно считается, что сговор сотрудников — это плохо (коррупция, саботаж). Однако анализ (особенно Глава II) показывает, что коалиция может действовать как *распределенный вычислитель*. Агенты внутри группы могут решать задачи перераспределения нагрузки эффективнее, чем удаленный Центр.
2. Самоочищение системы: Математически обосновано (Глава II), что устойчивая коалиция стремится избавиться от «балласта» (неэффективных агентов). Центру не всегда нужно проводить аттестации — достаточно создать механизм, где фонд оплаты труда фиксирован на группу, и группа сама вытеснит слабых игроков (при условии трансферабельной полезности).
3. Прозрачность ограничений: В Главе III показано: если Центр знает хотя бы границы потребностей агентов, он может гарантировать устойчивость. Отсюда вывод — инвестиции в мониторинг и прозрачность данных о ресурсах важнее, чем усложнение формул премирования.

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

1. Используйте коллективные KPI: Вместо борьбы с коалициями, легализуйте их. Переходите от индивидуального стимулирования к бригадному/отдельному (механизмы с полной сбалансированностью). Пусть C-ядро работает на вас.
2. Механизмы «защиты от сговора»: Если вы распределяете дефицитный ресурс (бюджет, премии), используйте механизмы, которые математически делают сговор невыгодным (например, механизмы Гровса-Кларка или специальные аукционы), либо убедитесь, что ресурс *нетрансферабелен* (сотрудник не может передать свою грамоту или доступ другому).
3. Управление информацией: Введите жесткие интервальные ограничения на заявки. Не позволяйте агентам заявлять «любые» потребности. Зная технические пределы оборудования или рыночные бенчмарки зарплат, Центр сужает пространство для манипуляций коалиций.
4. Матричная структура требует «Налога»: Анализ показывает, что в матричных структурах (проект vs функция) неизбежен конфликт. Для его решения требуется механизм внутреннего трансфертного ценообразования или «налога», который выравнивает интересы менеджеров среднего звена с целями всей компании. Без этого матрица будет либо парализована, либо разорвана борьбой за ресурсы.

А вот еще одна его работа М.В. Губко https://www.klex.ru/1ysn – «Математические модели оптимизации иерархических структур» (2006)

И ее небольшой анализ:

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

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

1. Анализ материала и методологии

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

Особенности подхода:

1. Разделение задач: Автор четко отделяет *дизайн структуры* (кто кому подчиняется) от *дизайна технологии* (кто что делает) и *механизмов управления* (мотивация). Это позволяет свести проблему к задаче дискретной оптимизации на графах.
2. Секционные функции затрат: Вводится предположение, что затраты менеджера зависят только от того, кем он управляет *непосредственно* (его «секции»).
3. Однородность: Ключевой математический инструмент — использование однородных функций затрат (свойство самоподобия или масштабируемости). Это согласуется с эмпирическими законами (например, зависимость зарплаты топ-менеджера от размера фирмы по Саймону).

Научная новизна (на момент написания): Получение *аналитических* формул (нижних оценок) для стоимости оптимальной иерархии, что позволяет не перебирать миллионы вариантов, а сразу строить «почти оптимальное» дерево.

2. Краткое содержание по главам

Глава 1. Постановка задачи

Вводится математический аппарат. Иерархия моделируется как ориентированное дерево.

• Исполнители имеют «меру» (сложность работы, объем задач).
• Менеджеры имеют функцию затрат $c(\mu_1, \dots, \mu_r)$, зависящую от мер подчиненных групп.
• Вводятся понятия сужающих (выгодно нанимать помощников, ведет к многоуровневости) и расширяющих (выгодно увольнять промежуточных начальников, ведет к плоской структуре) функций затрат.

Глава 2. Обзор литературы

Автор критически анализирует существующие модели (Бекманн, Вильямсон, Кальво-Веллиц, Раднер).

• *Вывод:* Большинство классических экономических моделей рассматривают только симметричные иерархии с фиксированным числом уровней. Подход Губко более гибок, так как ищет оптимальную структуру без ограничений на симметрию.

Глава 3. Оптимальные деревья (Ядро книги)

Здесь содержится главный теоретический результат.

• Доказано, что для однородных функций затрат оптимальная иерархия стремится быть однородным деревом. Это значит, что на каждом уровне менеджеры имеют примерно одинаковую норму управляемости (число подчиненных).
• Выведена формула нижней оценки затрат $C_L(N)$. Это теоретический минимум расходов, к которому нужно стремиться.
• Предложены алгоритмы построения субоптимальных деревьев (Bottom-Up и Top-Down), которые дают результат, очень близкий к идеальному.

Глава 4. Примеры и приложения

Теория применяется к практике:

1. Сборочное производство: Доказано, что при определенных условиях последовательная сборка (конвейер) экономически выгоднее параллельной.
2. Обработка информации (приказы): Моделируется процесс, где менеджер детализирует приказ сверху для подчиненных. Анализируется баланс между квалификацией менеджера и степенью его специализации.
3. Пределы роста фирмы: Исследуется зависимость затрат на управление от размера фирмы ($n$).
   • Если степень однородности затрат $\gamma < 1$, фирма может расти бесконечно (эффект масштаба положительный).
   • Если $\gamma > 1$, затраты на управление растут быстрее доходов, фирма становится неэффективной при превышении критического размера.

Глава 5. Обобщения

Рассматриваются более сложные случаи: кусочно-однородные функции (скачкообразное изменение затрат) и управление технологическими связями (когда структура подчинения диктуется потоками материалов/информации между цехами).

3. Дополнение новыми знаниями и современный контекст

Книга написана в 2006 году. С позиции сегодняшнего дня (2024+) анализ можно дополнить следующими аспектами:

1. Цифровизация и AI: В моделях Губко функция затрат менеджера $c(\mu)$ — это «черный ящик», зависящий от человеческих когнитивных способностей. Сегодня внедрение AI и ERP-систем меняет эту функцию. IT-системы увеличивают норму управляемости (снижают затраты на контроль), что делает иерархии более плоскими (расширяющий эффект).
2. Сетевые структуры и Agile: Книга фокусируется на *древовидных* иерархиях. Современный менеджмент часто использует матричные или сетевые структуры (двойное подчинение, кросс-функциональные команды). Модель Губко считает такие связи «дорогими» и неоптимальными, но в условиях высокой неопределенности (VUCA-мир) гибкость сети может окупать излишние затраты на коммуникацию, чего статические модели не учитывают.
3. Человеческий фактор: Модель предполагает *анонимность* менеджеров (все менеджеры одного уровня одинаковы). В реальности «звездный» менеджер может эффективно управлять 20 людьми, а слабый — только 3. Современный HR-анализ требует ввода индивидуальных коэффициентов в функцию затрат.
4. Трансакционные издержки: В главе про сборочное производство неявно затрагивается тема трансакционных издержек (Коуз). Современные платформенные экономики (Uber, маркетплейсы) показывают, что алгоритм может заменить целые слои иерархии, сводя функцию затрат менеджера к нулю или константе (стоимость сервера).

4. Итог, рекомендации и переосмысленные выводы

Итог

Книга М.В. Губко — мощное математическое доказательство того, почему классические пирамидальные структуры (где у каждого начальника 5-7 подчиненных) так устойчивы и распространены. Это не просто традиция, это математический оптимум для широкого класса функций затрат, обладающих свойством масштабируемости.

Практические рекомендации (на основе моделей книги):

1. Правило «7 ± 2» имеет математическое обоснование: Если работа менеджеров однотипна (однородная функция затрат), то норма управляемости должна быть одинаковой по всей иерархии. Если у вас в одном отделе начальник руководит 2 людьми, а в соседнем таком же — 15, ваша структура математически неэффективна. Нужно перебалансировать нагрузку.
2. Диагностика предела роста: Оцените, как растут зарплаты и расходы на управление при росте отдела.
   • Если расходы на управление растут быстрее, чем линейно (степень $\gamma > 1$), вашу организацию нельзя масштабировать простым добавлением людей — она «схлопнется» под весом бюрократии.
   • Решение:* Либо дробить компанию на независимые юниты (рыночные отношения внутри фирмы), либо внедрять IT (менять саму функцию $c(\mu)$, снижая $\gamma$).
3. При слияниях и поглощениях: Используйте алгоритм «Bottom-Up» (снизу-вверх). Сначала объединяйте мелкие подразделения в кластеры, потом кластеры в департаменты. Это дешевле, чем пытаться натянуть новую структуру сверху.
4. Квалификация vs Специализация: В главе 4 показано, что при низкой квалификации управленцев выгоднее делать структуру более многоуровневой (узкая норма управляемости). Если вы нанимаете дорогих профи, делайте структуру более плоской. Это математически обоснованный трейд-офф.

Переосмысленные выводы (Insight):

• Иерархия — это компрессор информации. Главный вывод из главы 4.3: смысл иерархии не во власти, а в сжатии информации при передаче снизу вверх и детализации приказов сверху вниз. Оптимальная структура — это оптимальный алгоритм сжатия данных. Если данные не сжимаются (каждый чих сотрудника требует внимания гендиректора), иерархия парализуется.
• Симметрия — признак здоровья. Теоретически доказано, что для выпуклых функций затрат оптимальное дерево стремится к симметрии. Сильные перекосы («флюсы») в оргструктуре — верный признак неэффективности расходов.
• Цена контроля. Стоимость иерархии — это цена, которую мы платим за невозможность одного человека управлять всем сразу. Главная задача организационного дизайна — не «красиво нарисовать квадратики», а минимизировать эту цену через подбор такой нормы управляемости $r$, при которой производная затрат равна нулю. Для большинства стандартных задач это $r \approx 5..9$.

вот же блин, не ждал я тут подвоха 😭

сдулся мой старенький asustor, придется бутылки сдавать ... и еще накатить чего-то с горя, что бы было что сдавать.

🥹

а вот еще тряхнул стариной и решил понарошку собрать комп нестыдный на сегодня :)) ну даже очень.
вот что вышло:

ну прям мечта сисадмина и не только))) это по сути 4 в одном. через proxmox 4 виртуалки. Первая True Nas Scale для массива, вторая ubuntu server для докеров и Portainer тоже с gpu и третья виндовая для gpu в виндовой среде. Встречайте...

Проект “Монолит”: Как собрать домашний сервер мечты за миллион (и зачем это вообще нужно)

Говорят, что универсальных инструментов не бывает. Что “Швейцарский нож” режет хуже скальпеля, а универсальная шина хуже зимней. Мы решили бросить вызов этому утверждению. Ну я и мой электронный друг Gemini.

Задача звучала амбициозно: собрать в одном компактном корпусе устройство, которое заменит целый IT-отдел. Оно должно быть:

1. AI-станцией для запуска “тяжелых” нейросетей (LLM) локально.
2. Графическим ПК топового уровня (4K/8K видео).
3. Корпоративным хранилищем (NAS) на 100+ ТБ с надежностью банка.
4. Лабораторией виртуализации для Docker, Kubernetes и DevOps-экспериментов.

И всё это должно работать 24/7, стоять дома и не напоминать шумом взлетающий Боинг. Спойлер: у нас получилось.

Почему не Mac Pro и не облака?

Первый вопрос, который задают рациональные люди: *“Зачем тратить 1.2 млн рублей на самосбор, если есть MacBook Pro, AWS и простая дисковая шуршалка в углу?”*

• MacBook M4 Max прекрасен, но это “золотая клетка”. На нем не развернешь серьезный кластер виртуализации, в нем нет 100 ТБ памяти, и он все еще слабее в AI-обучении, чем топовые GPU. Ну и закрыл крышку – прод упал.
• Облака — это игла подписки. Аренда мощностей уровня нашей сборки (A100/H100) будет стоить те же деньги за год-полтора, но в итоге у вас не останется ничего.

Мы выбрали путь “Digital Sovereignty” (Цифровой суверенитет). Своё железо, свои данные, свои правила.

Анатомия Монстра: Разбор “железа”

Каждый компонент здесь — результат компромиссов и долгих споров. Вот наша “Золотая конфигурация”:

1. Сердце: Архитектура “Всё в одном”

Мы отказались от серверных Threadripper в пользу AMD Ryzen 9 9950X3D.

• *Зачем?* Нам важна однопоточная производительность для графики и отзывчивости системы. 16 ядер Zen 5 — это избыточно для дома, но идеально для виртуализации. А X3D-кэш делает этот “сервер” лучшим графическим ПК в мире.
• *Материнская плата:* MSI MAG X870E Tomahawk. Надежная база с хорошим VRM, способная переварить этот процессор 24/7. Есть еще Eco режим, что позволит немного снизить мощность, но выиграть в теплоотдач и работе 24x7.

2. Мозг AI: Революция 5090 D

Сначала мы смотрели на RTX 4090. Но потом решили взглянуть на NVIDIA RTX 5090 D (32GB).
Это “Game Changer”.

• Потребительские карты обычно имеют 24 ГБ памяти. Этого мало для серьезных языковых моделей (LLM). Llama-3-70B туда влезает только “порезанной”.
• 32 ГБ GDDR7 памяти у 5090 D открывают портал в мир взрослого AI.
• Двухслотовая турбина выбрасывает горячий воздух из корпуса, спасая остальные компоненты от перегрева. Да, это стоит 340 000 рублей, но альтернатива (профессиональные карты RTX 6000) стоит в 3 раза дороже. Это отличный истребитель, но не космический крейсер enterprise уровня.

3. Хранилище: Надежность прежде всего

• Диски: 8 штук **WD Ultrastar по 22 ТБ. Это 176 ТБ “сырого” объема.
• Контроллер: Настоящий серверный HBA-адаптер **LSI 9300-8i в прошивке IT-Mode. Никаких программных RAID на материнской плате, только хардкор.
• Файловая система: ZFS в режиме **RAIDZ2 (аналог RAID 6). Могут умереть любые два диска одновременно — данные выживут.

4. Память: Золотая (в прямом смысле) DDR5 ECC

Самая болезненная строка бюджета. 128 ГБ DDR5 ECC.
Из-за бума ИИ цены на память взлетели. Комплект из 4 планок по 32 ГБ сейчас стоит около 200 000+ рублей.

• Можно ли сэкономить и взять обычную?* Нет. ZFS активно использует оперативную память. Ошибка в бите памяти может разрушить файловую систему. Для сервера 24/7 ECC (коррекция ошибок) — обязательное требование. Лучше этим не пренебрегать.

5. Корпус: Jonsbo N5

Это магия инженерии. Красивый черный куб, куда помещается E-ATX плата, полноразмерная видеокарта и 8 жестких дисков. Мечта с красивыми деревяшками на лицевой панеле :)

Программная магия: Как этим управлять?

Железо — это только половина дела. Вся мощь раскрывается в софте.
Мы используем Proxmox VE как гипервизор. Это “слоеный пирог”:

1. VM TrueNAS: Прямой проброс контроллера LSI. Эта виртуалка управляет дисками и раздает файлы по сети.
2. VM Windows 11: Прямой проброс RTX 5090. Подключаем монитор/клавиатуру — и это мощнейший графический ПК. Или подключаемся удаленно через Moonlight.
3. VM Ubuntu Server + Docker (Portainer): Здесь живут “слуги”: Home Assistant (умный дом), Plex (кинотеатр), Nextcloud (ваше личное облако) и среды для разработки.

Экономика: Игрушка или Инвестиция?

Цена сборки чуть переваливает за 1 250 000 рублей. Безумие?
Смотря как посмотреть.

Если рассматривать это как консоль для игр — безумие.
Но если вы IT-инженер, DevOps или AI-энтузиаст, это устройство становится активом:

• Аренда мощностей: В простое карту 5090 можно сдавать в аренду на площадках типа Vast.ai для обучения чужих нейросетей, отбивая стоимость “железа”.
• Обучение и Карьера: Навыки поднятия Kubernetes-кластера дома или тонкой настройки LLM стоят на рынке труда гораздо дороже миллиона.
• Свой стартап: Это готовый MVP-стенд для запуска своего AI-сервиса без трат на облака.

Итог

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

Добро пожаловать в клуб владельцев виртуальных “Monolith”. 🤪

UPD: 25.01.2026

Первый шаг к монолиту сделан.

Кстати, конфигурация немного поменялась. Самсунг ssd заменил в плане на Микрон серверный по 960gb, но 4 штуки. У них оказался срок службы гораздо большое. в 5-7 раз где-то. Они будут работать в Raid10 или raidz1 с блоком 32к. Места будет чуть меньше в raidz1, где то 2.7tb.

Почему Micron 7450 MAX 1.6TB лучше Samsung 990 PRO

Сравниваем, опираясь на мануал материнской платы и датащит диска:

1. Бессмертие (Endurance):
   • Samsung 990 PRO (2TB):** Ресурс ~1,200 TBW.
   • Micron 7450 MAX (1.6TB): Ресурс **8,700 TBW (См. Table 3 в инструкции).
   • Итог: Micron выносливее **в 7 раз. Вы можете писать на него базы данных и логи круглосуточно, и он переживет сам сервер.

2. Over-provisioning (Резервная область):
   Почему объем такой странный — 1.6 ТБ, а не 2 ТБ?
   Micron намеренно “скрыл” около 400 ГБ флеш-памяти. Контроллер использует это скрытое место, чтобы перемещать данные, выравнивать износ и поддерживать высокую скорость, когда диск заполнен.
   У Samsung 990 PRO этой резервной области почти нет, поэтому при заполнении на 90% он начнет тормозить. Micron 7450 MAX будет работать на полной скорости даже если вы забьете его под завязку.

3. Скорость случайной записи (IOPS):
   Для виртуалок важна запись мелких файлов (4K Random Write).
• Micron 7450 PRO:** 120,000 IOPS.
• Micron 7450 MAX: **250,000 IOPS (См. Table 2).
• Модель MAX в два раза быстрее обычной серверной PRO-версии на запись. Это идеально для баз данных и ZFS SLOG.

Математика массива на Micron 1.6TB

Если берем 4 таких диска и делаем ZFS RAID10:

$$1.6 \text{ ТБ} \times 4 = 6.4 \text{ ТБ (Сырой объем)}$$
$$\text{Полезный объем (RAID10)} = 3.2 \text{ ТБ}$$

Еще большой плюс: PLP (Power Loss Protection) — Защита от потери питания, которая есть в Micron. На плате распаяны танталовые конденсаторы. Если питание пропадает, у диска есть еще несколько миллисекунд, чтобы сбросить всё из оперативной памяти в ячейки NAND = защита от отключения электропитания и потери данных.

Почему это важно для ZFS, он очень зависит от синхронной записи (Sync Writes) для баз данных и виртуальных машин. Зная, что у диска есть защита PLP, ZFS может безопасно отключать некоторые программные тормоза (O_DSYNC), работая значительно быстрее на мелких операциях записи.

Итого:
3.2 ТБ сверхбыстрого, защищенного от потери питания (PLP), “бессмертного” серверного пространства — это мечта для гипервизора Proxmox.

Короче берем Micron 7450 MAX 1.6TB. Это лучший компонент во всей сборке с точки зрения профессионального подхода. Главное найти его в форм-факторе 2280, а то на материнской плате есть только один длинный порт.

Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.

Сегодня я расскажу, как настроить Dokku через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.

Часть 1. Фундамент: Запуск Dokku в Portainer

Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.

Docker Compose конфигурация

Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.

# version: '3.2'
services:
  agent:
    image: dokku/dokku:${VERSION}
    pid: host.  # ⚠️ важно для работы на NAS
    network_mode: bridge # ⚠️ важно для работы на NAS
    environment:
      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}
      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${VOLUME_PATH:-/var/lib/dokku}:/mnt/dokku
    ports:
      - "3022:22" # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 
      - "80:80"    # Внешний порт 80 -> порт 80 внутри контейнера Dokku
      - "443:443"

Нюансы сети:
Чтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил AdGuard Home в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.

Также для удобства я настроил `~/.ssh/config` на ноутбуке, чтобы не вводить порты вручную:

Host dokku.datahub.mother
  HostName 192.168.0.20
  Port 3022
  User dokku

ну и ключ сам так можно добавить

echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" | dokku ssh-keys:add dokku

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.

Код приложения (`app.py`)

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>Приветствую в игре Нового 2026 года! 🎉</h1>
    <p>Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!</p>
    <p>Введи свой год рождения:</p>
    <form action="/result" method="get">
        <input type="number" name="birth_year" min="1900" max="2025" required>
        <button type="submit">Угадать возраст на Новогодний 2026!</button>
    </form>
    """

@app.route('/result')
def result():
    birth_year = request.args.get('birth_year')
    if not birth_year or not birth_year.isdigit():
        return "Ошибка: введи корректный год рождения!"
    
    birth_year = int(birth_year)
    age_in_2026 = 2026 - birth_year
    return f"""
    <h2>Результат: 🎇</h2>
    <p>В 2026 году тебе будет {age_in_2026} лет!</p>
    <p>Счастливого Нового 2026 года! Пусть все твои желания сбудутся!</p>
    <a href="/">Играть снова</a>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Подготовка к деплою

Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:

1. `requirements.txt` (зависимости):

Flask==2.3.2
gunicorn==20.1.0
Werkzeug==2.3.3

2. `Procfile` (команда запуска):

web: gunicorn app:app --bind 0.0.0.0:5000

3. `.python-version` (опционально, явная версия Python):

3.11.14

Процесс деплоя

Все делается через Git, как на “взрослых” платформах:

1. Создаем приложение на сервере:

ssh dokku@dokku.datahub.mother apps:create my-first-app

2. Отправляем код:

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит

git remote -v

ну и поменяем еще не верное

git remote remove dokku

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `http://my-first-app.dokku.datahub.mother`.

Еще нужно домен установить

ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother

или можно сразу глобально его установить:

ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother
# но тогда придется удалить ручную привязку 
ssh dokku@dokku.datahub.mother domains:clear my-first-app

# не забыть перебрать nginx ( на всякий случай ) 
ssh dokku@dokku.datahub.mother proxy:build-config my-first-app

Сертификат сгенерировать

ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

и проверить порты

ssh dokku@dokku.datahub.mother ports:report my-first-app

если порты не корректные, то можно их установить так:

ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000

Часть 3. Уровень PRO: Скорость (uv) и Marimo

Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на Marimo, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук https://marimo.app

1. Ускорение сборки с `uv`

Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.
Я перешел на uv — новый менеджер пакетов на Rust.

Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось в разы.

2. Ловушка масштабирования (Scaling)

Marimo — это stateful приложение (хранит состояние в памяти). Flask, который мы делали выше — stateless.

Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так

ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3

далее Dokku запустил 3 копии контейнера (`web=3`).
Начался хаос:

• Интерфейс открывался.
• При нажатии кнопок вылетала ошибка `Invalid server token`.

Почему? Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.

Решение:
Для интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:
Ну ли придется делать липкие сессии на nginx или еще что-то.

ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.

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

Вот так можно установить лимиты или повысить их:

ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2

3. SSL в локальной сети

Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.
Я решил вопрос генерацией самоподписанного сертификата одной командой Dokku:

ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

Браузер ругается, но приложение работает полноценно.

Еще я прогнал стресс тесты

ab -n 10000 -k -c 2000 ...

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

Итог

Dokku на домашнем сервере — это отличный инструмент.

• Для простых API (Flask/FastAPI): Работает “из коробки” идеально.
• Для сложных задач: Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.

Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. https://dokku.com/docs/enterprise/pro/

Пора чего-нибудь накатить новогоднего еще :)