Все публикации подряд на Хабре [expanded by feedex.net]

Делаем RAG-систему с нуля

JBFW — Sun, 04 Oct 2026 01:44:58 +0000

JBFW28 минут назад

17 мин

У меня с давних времен сохранилась куча всяких заметок, в основном в виде простых текстовых файлов.
Самых разных: от скриптов и конфигов до всяких рецептов, всё что когда-то пригодилось или могло пригодиться.

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

Единственный минус, когда их много - для того чтобы что-то найти нужно пройтись по каталогам где они лежат и увидеть глазами.
Особенно - если их никто не пытался строго структурировать, и они лежат где-то так:
"Документы/старое/1/1/разобрать/старый диск/Документы/Работа/...".
Ну, это конечно запущенный случай, и надо бы разобрать, когда-нибудь, может быть - ну, собственно говоря, там так и написано...

Что если попробовать прикрутить к этому поиск?

Вот только нужно соблюсти несколько условий:
1 - ничего не испортить. Информация хранится в файлах - и эти файлы-первоисточники не должны потеряться.
2 - только локальная обработка. Никаких облаков, подписок и прочего.
3 - не должны быть завышены системные требования, задача должна решаться как можно проще, без приобретения дорогостоящего оборудования, буквально на том что есть.
А есть машинки с 4 гигами памяти, с этим не проблема.

И вот, исходя из таких предпосылок, начинаем...
Дисклеймер: с нуля означает с нуля, то есть от "я читал про это" до более-менее работающей системы, и без претензий на продакшен, чисто для себя.
Инженерам по строительству RAG-систем тут вряд ли будет что-то интересно.

В соответствии с нормами текущего времени - базовые вопросы были адресованы LLM, а вот с ответами уже пришлось разбираться самому.

В теории это должно работать примерно так: в основе лежит некая ИИ-модель, которая умеет оценивать тексты.
Оценивает они их по принципу "существует всего 768 тем, и вот этот текст соответствует этим темам на [0.32, 0.522, 0.12, 0.023, ...]".
Полученный массив - 768-мерный вектор, который описывает данный кусочек текста.
Поисковой запрос в виде текста также оценивается этой же моделью, также формируется вектор, а потом этот вектор прогоняется по базе сохраненных векторов в поисках наиболее близких по теме, для чего нужна так называемая векторная БД.
Ищется не прямое совпадение, а "дистанция" между векторами: чем она меньше - тем больше тексты похожи.

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

Также LLM предложил готовый пример скрипта, реализующего данную логику. Скрипт был, конечно же, на Python.

Python - язык №1 в топах, и почему я его не люблю

Есть такие языки программирования, которые просто не нравятся. У меня это - Pascal и Python. Один к счастью сейчас почти не встречается, а вот второй занимает первые строчки всяческих рейтингов.
Не нравится же он по нескольким причинам, и сейчас первая, чисто вкусовщина:
он создает своеобразный вайб, как будто в институте на лекции очень пожилой профессор, прекрасный математик, но реально писавший программы последний раз 50 лет назад на PL/1 еще для ЕС, пытается обьяснить студентам алгоритм с использованием псевдокода.
А студенты потом тащат этот псевдокод в продакшен - работает же?
Работает, но есть нюансы...

import faiss
import numpy as np
from sentence_transformers import SentenceTransformer
embedder = SentenceTransformer(
    "intfloat/multilingual-e5-base"
)
chunks = [
        {
            "text": "Текст 1",
            "source": "/data/manual1.pdf",
        },
        {
            "text": "Текст 2",
            "source": "/data/manual2.pdf",
        }
]
texts = [chunk["text"] for chunk in chunks]
vectors = embedder.encode(
    texts,
    normalize_embeddings=True,
    show_progress_bar=True
)
vectors = np.asarray(vectors, dtype="float32")
dimension = vectors.shape[1]
index = faiss.IndexFlatIP(dimension)
index.add(vectors)
faiss.write_index(index, "documents.faiss")
import json
with open("chunks.json", "w", encoding="utf-8") as f:
    json.dump(chunks, f, ensure_ascii=False, indent=2)
def search(query, index, chunks, embedder, top_k=5):
    query_vector = embedder.encode(
        [query],
        normalize_embeddings=True
    ).astype("float32")
    scores, ids = index.search(query_vector, top_k)
    results = []
    for score, idx in zip(scores[0], ids[0]):
        if idx >= 0:
            item = chunks[idx].copy()
            item["score"] = float(score)
            results.append(item)
    return results
results = search(
    "текст запроса",
    index,
    chunks,
    embedder,
    top_k=5
)
for result in results:
    print(result["source"], result["score"])
    print(result["text"])

(скрипт не мой, но нужен тут для понимания откуда ног растут)

В данном случае вектора создаются с помощью модели "intfloat/multilingual-e5-base", записываются в векторную базу FAISS, а метаданные, что откуда взято - в JSON-файл.
ИМХО, неплохой учебный пример, демонстрирующий логику работы.
Исходные файлы разбиваются на чанки, чанки индексируются, по векторам находятся совпадения, результаты можно отсортировать по рейтингу, и в итоге уже выдать документы-первоисточники, откуда что взято.

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

Первая проблема была в том, что всё это было ОЧЕНЬ долго: и в основном время тратилось на загрузку модели.
Особенно при поиске: скрипт запускается, грузит модель, и только потом уже можно отправлять в нее запрос.

Разумеется, о практическом использовании такого говорить нельзя, поэтому в очередной версии "поисковик" запускал http-сервер, который принимал поисковую строку, отправлял ее в модель, и возвращал результаты.

Почему Python так любят многие?

Он простой с точки зрения установки: достаточно команды pip install something - оно будет где-то найдено, скачано и быстро установлено.
Сложности могут возникнуть только на самом первом этапе - ~~подготовки рабочего места студента~~

python3 -m venv .venv
source .venv/bin/activate

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

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

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

Также возникло желание заменить эту модель на что-то более другое - тогда выяснилось, что модель может работать вообще отдельно, на llama.cpp или Ollama.
Порядок работы немного поменялся: Ollama запускалась на другом сервере в сети, скрипты обращались к ней за векторами по API, и вот только поиск шел уже в той же FAISS.

from  ollama import Client
ol_host = "http://ollama:11434"
oclient = Client(host=ol_host)
...
    #new_vector = embedder.encode(
    #    #[f"{content}"],
    #    normalize_embeddings=True,
    #    convert_to_numpy=True
    #).astype("float32")
    response = oclient.embed(
        model=model,
        input=content,
        dimensions=dimension
    )
    embeddings = response['embeddings']
    new_vector = np.array(embeddings, dtype=np.float32)
...

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

Python - технические моменты

Во-первых, ужасно неудобный (для меня) синтаксис.
При всей легкости установки чужих готовых модулей - писать на этом самому совершенно не хотелось.
Почти как в старом анекдоте: "Ты C знаешь? Вот вообще на него не похоже!"

Во-вторых - он тормоз.
Простейшие вещи, которые к примеру, на Perl, отрабатывают мгновенно - тут раздражающе тормозили.

И в третьих - ну вот, допустим, допустили вы очепятку. Переменная не так называется, как должна.
Что делает perl-скрипт при запуске? Он сразу ругается: в строке такой-то переменная "anme" не была обьявлена / не используется, проверьте!
Что делает python-скрипт при запуске? Он запускается, работает, и только при обращении к проблемному коду почему-то происходит ошибка, хорошо если в лог напишет.

А с учетом того что он тормоз, и до нужного места может дойти не сразу - приятного мало.

В общем, возникло сильное желание переписать все на ~~Rust~~ Perl.
К сожалению, экосистема Perl сейчас действительно беднее чем Python: аналогов FAISS нет, модели локально запускать не умеет. А некоторые и вовсе считают, что он был популярным языком для веб в начале 90-х, да весь вышел.

Тем не менее, и для него есть модули работы с векторными БД, а модель мы уже вынесли за скобки, в Ollama.
Можно было конечно сразу начать с Qdrant, а можно попроще, с sqlite3 с векторным модулем.

Называется это SQLite::VecDB, и как большинство Perl-модулей устанавливается через CPAN:

cpan SQLite::VecDB

Но есть нюанс...

Почему Perl быстрый и почему он сегодня проигрывает

Система установки Perl-модулей CPAN сделана с расчетом на то, что модули могут быть написаны как на чистом Perl (PurePerl, PP), так и с использованием вставок на C/C++.
Самые распространенные модули входят в дистрибутив ОС и могут быть скачаны в виде готовых архивов, нестандартные - скачиваются исходниками.
Если с PP всё понятно - модуль скачался и записан в определенный каталог модулей - то те, которые требуют компиляции - должны быть скомпилированы на целевой системе, с подключением нужных библиотек.
Всё это происходит автоматически, нужно только установить необходимое, типа исходников этих библиотек. Как правило, они есть в дистрибутиве, нужно только их найти.

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

В частности, упомянутый модуль требует исходников векторного расширения sqlite3 - и они тоже есть в дистрибутиве, но нужно их найти, установить через пакетный менеджер, вместе с gcc/g++ и прочим.
Получается очень быстрая реализация, по факту на С с оберткой на Perl, но всё это требует несколько больше знаний и движений, чем pip install.

И второй нюанс, на примере этого же пакета: согласно документации (man SQLite::VecDB) есть вариант запуска с использованием специального модуля для работы с Ollama.
Теоретически это должно бы упростить работу - но по факту этот самый "упрощающий модуль" требует предустановки еще 100500 других, которые вероятно уже были установлены у разработчика, и он не задумываясь использовал готовые блоки. Code reuse, вот это всё.

Поэтому, несмотря на то что всё происходит автоматически - оно происходит очень долго (автотесты же, на каждый пакет и чих).
Иногда быстрее написать самому вручную - но это всё еще сложнее pip install.

Итог немного предсказуем: быстрый, но более сложный Perl проигрывает...

Возвращаясь к нашим баранам: SQLite::VecDB позволяет хранить базу векторов и метаданных в файле sqlite3, а также выполнять по ней поиск.
Вектора рассчитывает Ollama, и таким образом удалось наконец всё "переписать на Perl".

Упомянутый модуль для работы с Ollama по сути должен был всего лишь запросить вектор и подставить его куда нужно.
Как и говорил - оказалось быстрее написать свой вариант запроса:

#!/usr/bin/perl
use SQLite::VecDB;
use HTTP::Tiny;
use JSON;
my $dim = 768;
my $model = 'snowflake-arctic-embed2';
my $url = 'http://ollama:11434/api/embed';
my $vdb = SQLite::VecDB->new(
  db_file    => '/data/vectors.db',
  dimensions => $dim,
);
my $coll = $vdb->collection('documents');
# сохранение в базу
sub add_vector {
  my ($id, $vector, $data, $content) = @_;
  $coll->add(
    id       => $id,
    vector   => $vector,
    metadata => $data,
    content  => $content,
  );
}
my $http = HTTP::Tiny->new(timeout => 30);
# запрос вектора у Ollama
sub get_vector {
  my ($text) = @_;
  my $payload = {
    model => $model,
    input => $text,
    dimensions => $dim,
  };
  my $json = to_json($payload);
  my $response = $http->post(
    $url,
    {
        headers => { 'Content-Type' => 'application/json' },
        content => $json,
    }
  );
  if ($response->{success}) {
    my $data = from_json($response->{content});
    my $vector = $data->{embeddings}[0];
    return $vector;
  }
  else{
    print STDERR "Error: $response->{status} $response->{reason}\n$response->{content}\n";
    return undef;
  }
}
# поиск по вектору в базе
sub search_vector {
  my ($vector) = @_;
  my @results = $coll->search(
    vector => $vector,
    limit  => 10,
  );
  my $ret = [];
  for my $r (@results) {
    my $t = {
      id       => $r->{id},
      distance => $r->{distance},
      content  => $r->{content},
      metadata => $r->{metadata},
    };
    push(@$ret, $t);
  }
  return $ret;
}
# пример запроса вектора
# my $vector = get_vector('Text1');
# сохранение вектора, метаданных и текста для полнотектового поиска, если надо
# add_vector('ID1', $vector, {file => 'file1', page => 12}, 'Text1');
# пример поиска
# my $query = get_vector('Search string');
# search_vector($query);

И опять прикрутим HTTP-сервер, чтобы можно было к поисковому скрипту, привязанному к файлу sqllite3 и модулям, обращаться из любого места в сети.
В Perl, конечно же, есть готовые модули, в том числе достаточно серьезные фреймворки - но тут нужен простой, примитивный веб-сервис, для которого тащить что-то большое - всё равно что стрелять по воробьям из Царь-пушки.

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

#!/usr/bin/perl
package MicroHTTPD;
use strict;
use warnings;
use IO::Socket::INET;
use URI::Escape qw(uri_unescape);
use JSON;
# хардкод, но можно переназначить
our $port = 8080;
our $iface = '0.0.0.0';
our $routes = {
  'get'  => {},         # сюда добавляем функции, вызываемые по GET
  'post' => {},         # сюда - вызываемые через POST
  'any'  => {},         # сюда - те, которые можно и так и так.
};
# запуск сервера
sub serve {
  my $server = IO::Socket::INET->new(
    Local      => $iface,
    LocalPort  => $port,
    Listen     => 10,
    Reuse      => 1,
  ) or die "Startup error: $!\n";
  print "Server started: http://$iface:$port/\n";
  while (my $client = $server->accept()) {
    $client->autoflush(1);
    my $headers = '';
    while (my $line = <$client>) {
      $headers .= $line;
      last if $line eq "\r\n";
    }
    my ($request_line, @header_lines) = split /\r\n/, $headers;
    my ($method, $path, $http_version) =
      $request_line =~ /^(\S+)\s+(\S+)\s+(HTTP\/\d\.\d)$/;
    unless ($method && $path) {
      send_response($client, 400, "Bad Request", "Incorrect HTTP-request");
      close $client;
      next;
    }
    my %headers;
    for my $line (@header_lines) {
      next unless $line =~ /^([^:]+):\s*(.*)$/;
      $headers{lc $1} = $2;
    }
    my $body = '';
    if ($method eq 'POST') {
     my $content_length = $headers{'content-length'} || 0;
      if ($content_length > 1024 * 1024) {
        send_response($client, 413, "Payload Too Large", "Request body too large");
        close $client;
        next;
      }
      read($client, $body, $content_length);
    }
    if ($method eq 'GET') {
      my ($route, $query_string) = split /\?/, $path, 2;
      my %params = parse_params($query_string || '');
      my $processed = 0;
      for my $r (keys( %{ $routes->{get} } )){
        if ($route eq $r) {
          my ($ret_body, $ret_headers) = $routes->{get}->{ $r }->( \%params, \%headers );
          send_response($client, 200, "OK", $ret_body, $ret_headers);
          $processed = 1;
          last;
        }
      }
      for my $r (keys( %{ $routes->{any} } )){
        if ($route eq $r) {
          my ($ret_body, $ret_headers) = $routes->{any}->{ $r }->( \%params, \%headers );
          send_response($client, 200, "OK", $ret_body, $ret_headers);
          $processed = 1;
          last;
        }
      }
      if(!$processed){
        send_response($client, 404, "Not Found", "Method not found");
      }
    }
    elsif ($method eq 'POST') {
      my ($route) = split /\?/, $path, 2;
      my %params = ();
      if($headers{'content-type'} eq 'application/x-www-form-urlencoded'){
        %params = parse_params($body || '');
      }
      if($headers{'content-type'} eq 'application/json' ){
        my $t = from_json($body||'{}');
        %params = %$t;
      }
      my $processed = 0;
      for my $r (keys( %{ $routes->{post} } )){
        if ($route eq $r) {
          my ($ret_body, $ret_headers) = $routes->{post}->{ $r }->( \%params, \%headers );
          send_response($client, 200, "OK", $ret_body, $ret_headers);
          $processed = 1;
          last;
        }
      }
      for my $r (keys( %{ $routes->{any} } )){
        if ($route eq $r) {
          my ($ret_body, $ret_headers) = $routes->{any}->{ $r }->( \%params, \%headers );
          send_response($client, 200, "OK", $ret_body, $ret_headers);
          $processed = 1;
          last;
        }
      }
      if(!$processed){
        send_response($client, 404, "Not Found", "Method not found");
      }
    }
    else {
      send_response(
        $client,
        405,
        "Method Not Allowed",
        "Method Not Allowed",
        {
          'Content-Type' => "text/plain; charset=utf-8",
          'Allow' => "GET, POST",
        }
      );
    }
    close $client;
  }
}
sub parse_params {
  my ($data) = @_;
  my %params;
  for my $pair (split /&/, $data) {
    my ($key, $value) = split /=/, $pair, 2;
    $key   = uri_unescape($key   // '');
    $value = uri_unescape($value // '');
    $key   =~ tr/+/ /;
    $value =~ tr/+/ /;
    $params{$key} = $value;
  }
  return %params;
}
sub send_response {
  my ($client, $status, $status_text, $body, $headers) = @_;
  $headers->{'Content-Type'} ||= 'text/plain; charset=utf-8';
  my $response =
      "HTTP/1.1 $status $status_text\r\n"
    . "Content-Length: " . length($body) . "\r\n";
  for my $x (keys(%$headers)){
    $response .= "$x:$headers->{$x}\r\n";
  }
  $response .=
    "Connection: close\r\n"
    . "\r\n"
    . $body;
  print $client $response;
}
1;

Это модуль микро-HTTP сервера, к которому можно подключить методы на GET и POST запросы. Что и как они будут выполнять - на усмотрение того кто их напишет. Поддерживается параллельное исполнение - в общем, для вебсервиса сойдет.

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

#!/usr/bin/perl
use lib ".";
use MicroHTTPD;
# $MicroHTTPD::port = 8080;
....
....
# обработчик http для добавления в базу
sub add_text {
  my ($params, $headers) = @_;
  my $text = $params->{text};
  my $id   = $params->{id};
  my $data = $params->{data};
  my $vector = get_vector($text);
  if(defined $vector){
    add_vector($id, $vector, $data, $text);
    return ("OK add vector", {} );
  }else{
    return ("ERR no vector", {} );
  }
}
# обработчик http для поиска по базе
sub search_text {
  my ($params, $headers) = @_;
  my $text = $params->{text};
  my $vector = get_vector($text);
  if(defined $vector){
    my $ret = search_vector($vector);
    my $json = to_json($ret);
    return ($json, { 'Content-Type' => 'application/json' } );
  }else{
    return ("[]", { 'Content-Type' => 'application/json' } );
  }
}
$MicroHTTPD::routes->{post}->{'/load'} = \&add_text;
$MicroHTTPD::routes->{post}->{'/query'} = \&search_text;
MicroHTTPD::serve();

Всё это запускается в докер-контейнере, и схема работы получается примерно такая:

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

Данные

В качестве подопытных были взяты файлы с рецептами, сохраненные примерно сто лет назад, по сути просто копипаста постов с форума.
В качестве "поисковых запросов" - несколько коротких фраз, примерно таких, какие я использую в поисковиках.

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

Теория говорит нам, что входящие файлы надо разбить на чанки, и загружать их.
Первый вариант - разбить текст на абзацы.
Скрипт читает, разбивает, загружает - ОК.
Второй скрипт запускает поисковые фразы и сохраняет результаты.

Вот например, "хлеб" найден в Чебуреках (0.45), в Картошке в духовке (0.53), в Бисквите (0.63). Чем больше цифра - тем хуже.
А "Ремонт велосипедов" - в "Картошке в духовке" несколько раз (0.29-0.39) - хотя оно вообще не по теме.
Зато "Шашлык изз баранины" в Бисквите и Чебуреках, и немного найден в Баранине (0.50), хотя там и про баранину и про шашлык.
В общем, велосипедов в Картошке с духовкой оказалось больше, чем шашлыка в шашлыке, а "Творожная запеканка" в "Творожной запеканке" вообще не обнаружена.
Так-то логично: индексирована живая речь, с эмоциями, восклицаниями и балабольством, что пониманию контекста не способствует.

Ок, пробуем разбить на предложения.
Результат - лучше смотреть на сравнении (слева - по абзацам, справа - по предложениям):
Чуть лучше теперь найден шашлык, всё остальное примерно так же или хуже. Тоже логично, шума стало меньше, но контекста больше не стало.

Но был еще список файлов с описаниями!
И вот тут-то оно заработало: ремонт велосипедов остался примерно так же, зато нашлась Баранина и особенно - Творожная запеканка.
Ну с ней понятно, там было полное совпадение описания с поисковой фразой.

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

Качество угадывания темы и скорость сильно зависят от модели: одни показывают максимум 4-5 секунд на анализ, другие думают больше 30 секунд.
Так же, радикальное уменьшение размерности вектора, с 768 до 256, на тех же данных и тех же запросах дает совсем какую-то незначительную разницу, во втором-третьем знаке после запятой.

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

Можно прикрутить LLM для того, чтобы он оценивал файлы и давал им имена/описания, но тут упираемся в первоначальное требование: работать локально на том железе которое есть.
Протестированные модели хоть и справлялись в принципе с подобной задачей, но результаты сильно напоминали мемные "носки белосвежного вида" или "светчики лампады нити праздника": если знать контекст - можно понять почему так написано, но задача-то наоборот: понять контекст, читая это.

Более-менее с задачей справилась qwen2:

Скрипт анализа файла

#!/bin/sh
if [ "x$1" = "x" ] ; then
        exit
fi
fname=$1
text=$(head -15 $fname)
# model: "granite4:350m",
# model: "llama3.2:latest",
jq -n --arg text "$text" '{
  model: "qwen2:1.5b",
  stream: false,
  prompt: (
    "Прочитай этот файл, опиши о чем в нем написано, на русском языке, не будь многословным, составь ответ от 2 до 7 слов, не больше:\n\n" + $text
  )
}'  curl 'http://ollama:11434/api/generate' \
        -H "Content-Type: application/json" \
        -d @-  \
         jq -r '.response'

Вызываем его примерно таким образом:

#!/bin/bash
ROOT_DIR=/source_directory
find "$ROOT_DIR" \
    -type f -print0
while IFS= read -r -d '' file; do
    mime_type=$(file --brief --mime-type -- "$file")
    case "$mime_type" in
        text/* )
            echo "$file"
            info=$( ./describe "$file")
            (
              echo "FILE $file : $mime_type"
              echo "$info"
              echo "========================================"
            ) >> FILE_ID.DIZ
            ;;
        *)
            printf 'Пропуск: %s [%s]\n' "$file" "$mime_type" >&2
            ;;
    esac
done

Историческая справка: во времена FIDO и BBS пользователи обменивались файлами, заливая на BBS архивы. Чтобы как-то описать, что это там такое в архиве - создавался специальный файл FILE_ID.DIZ, в котором и было написано, что там внутри.

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

Остается только прочитать его в систему, для того чтобы искать потом:

#!/usr/bin/perl
#
use Data::Dumper;
use JSON;
use HTTP::Tiny;
my $url = 'http://dataserver:3333/load';
my $http = HTTP::Tiny->new(timeout => 30);
my $file='FILE_ID.DIZ';
open(my $in, $file);
exit if(!defined $in);
my $fname = undef;
my $info = '';
my $id = 0;
while(my $str = <$in>){
  $str =~ s/[\r\n]+/ /gm;
  if(!defined $fname && $str =~ /^FILE (.+) :/){
    $fname = $1;
  }
  elsif(defined $fname && $str ne ' '){
    if($str =~ /^=+ $/){
    if($info ne ''){
      $id ++;
      my $d = {
        id   => $id,
        data => { file => $fname},
        text => $info,
        collection => 'texts',
      };
      my $json = to_json($d);
      my $response = $http->post(
        $url,
        {
          headers => { 'Content-Type' => 'application/json' },
          content => $json,
        }
      );
      if ($response->{success}) {
         print "$response->{content}\n";
      }
      else{
         print STDERR "Error: $response->{status} $response->{reason}\n$response->{content}\n";
      }
    }
    $fname = undef;
    $info = '';
    }else{
      $info .= $str;
    }
  }
}
close($in);

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

Простейший вариант запроса - ну например, так:

curl -s -X POST -d text="микроконтроллер stm32" -d collection='texts' 'http://dataserver:3333/query'

В результате будет выведен список найденных записей в виде JSON-массива:

[{"metadata":{"file":"/srv/raid/stm32/README"},"distance":0.409470826387405,"content":"Данный файл содержит команда openocd для загрузки программы на микроконтроллер STM32. Он указывает на использование различных типов транспортных средств, включая DAPdirect SWD и HLA-USB SWD. Загруженный файл firmware.bin находится в диапазоне 0x08000000 и проверяется после его загрузки. ","id":"13"},
{"id":"17","content":"Безуспешная установка драйвера CMSIS-DAP для F0xx с ПИСО, указание скорости адаптера на 1000, создание ПИСО $_CHIPNAME.cpu в сеть Cortex-M. Инициализация памяти устройства с областью 0x20000000 до 0x1000 для восстановления области обновления, установка Flash banks на Flash0 STM32F1x. ","metadata":{"file":"/srv/raid/OCD/OpenOCD"},"distance":0.490307033061981},
...
]

Это можно интегрировать в веб-систему, а можно сделать, например, и такое:

Вот пользуюсь я, скажем, консолью и MidnightCommander в нем, а у MC есть такая фишка - ExternalPanelize, Ctrl-x !: можно вызвать внешнюю команду, которая вернет некоторый список файлов, который в свою очередь будет отображен в окне MC как каталог.

Если при загрузке файлов в поисковую систему сохраняется также путь к файлу, и файлы эти доступны с машины, например по NFS - то можно написать такой скрипт, который в ответ на запрос выведет список файлов.
Тогда они все появятся в одной панели, их можно будет легко просматривать или копировать.

Кроме того, есть еще одна фишка - быстрый просмотр, Ctrl-x q - тогда во второй панели показывается часть содержимого текстового файла.
Можно быстро посмотреть, то или не то - прежде чем уже полноценно открывать файл.

К сожалению, вот тут MC не всесилен: в ExternalPanelize можно ввести свою команду, но нельзя сохранить ее так, чтобы она запрашивала строку.
Придется вводить вместе со строкой.

Пишем скрипт, назовем его просто Q:

#!/bin/sh
curl -s -X POST -d text="$@" -d collection='texts' 'http://dataserver:3333/query'  jq -r '.[].metadata.file'

Теперь при поиске в ExternalPanelize пишем команду, например, "Q микропроцессор stm32" - и получаем список файлов...
Не идеально, но и так тоже можно. Ну и наконец, про скорость работы всего этого.
Самое медленное - работа моделей, тут всё упирается в железо и память.
Но вот у меня, в качестве эсперимента, всё работает вообще на дешевом одноплатнике - по скорости сопоставимо с "найти в Гугле".
Конечно, несколько параллельных запросов заставят систему выполнять их по очереди, но поскольку всё работает через HTTP - при желании можно разнести несколько запросов по нескольким машинам, отправляя разные на разные.
Другой вопрос, что мне дома это не нужно, да и вообще больше эксперимент.

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

Хабр Курсы для всех

Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!

От bare metal до managed Kubernetes: разбираем архитектуру Cozystack. Расшифровка митапа в Дубае

kvaps (Ænix) — Sun, 04 Oct 2026 01:01:27 +0000

1 час назад

28 мин

Репортаж

Как устроен Cozystack и managed Kubernetes на собственном железе

Во время поездки в ОАЭ я случайно попал в дубайское IT-комьюнити в Telegram. Там мы внезапно скоординировались и собрали незапланированный митап. 3 октября встретились в небольшой переговорке в Дубае — получилось душевно, и мы успели обсудить много интересных тем: от Talos и хранилища до сетей и устройства managed Kubernetes.

За помощь с организацией большое спасибо члену нашего комьюнити Artem Goncharenko — @roysbike. Артём нашёл локацию и скоординировал встречу.

Участники экспромт-митапа Cozystack в Дубае

Экспромт-митап 3 октября 2026 года в Дубае.

На митапе я рассказывал о Cozystack — открытой платформе для предоставления managed-сервисов на собственном железе. Начали с обзорной презентации, но довольно быстро перешли к вопросам: почему выбрали именно такой storage, зачем нам одновременно Kube-OVN и Cilium, как устроен Kubernetes внутри Kubernetes и где проходит граница между облачной платформой и обычной виртуализацией.

Ниже — отредактированная техническая расшифровка доклада и обсуждения. Я разберу, как связаны Talos, Flux, LINSTOR, Kube-OVN, Cilium, KubeVirt, Kamaji и Cluster API; как пользовательский ресурс превращается в работающий сервис; и почему для managed Kubernetes важно отдельно обслуживать control plane, вычислительные узлы и хранилище.

Пользователю нужен работающий сервис

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

Мы хотим поднять эту абстракцию на уровень выше. Человек заказывает PostgreSQL, Kubernetes-кластер или другой готовый сервис, а платформа берёт на себя его развёртывание и обслуживание.

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

Каталог приложений Cozystack

Пользователь выбирает сервис в каталоге; низкоуровневые ресурсы создаёт платформа.

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

Поэтому Cozystack мы рассматриваем как платформу для managed-сервисов. Kubernetes даёт нам основу, но пользовательский сервис появляется только после того, как мы связываем все необходимые механизмы между собой.

Самая дорогая часть интеграции

Когда приходит заказчик, его задача обычно звучит вполне конкретно: нужен сервис, нужна инфраструктура, нужно решить определённую проблему. А самая трудоёмкая часть решения часто прячется между компонентами.

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

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

Интеграции с сетью избежать невозможно: платформу в любом случае нужно подключить к сети заказчика. А вот зависимость от внешнего хранилища можно убрать. Если готового storage нет, мы приносим свой LINSTOR и строим хранилище на доступных дисках. Если хранилище уже есть, подключаем его через стандартный механизм CSI. Это позволяет использовать существующую инфраструктуру и при этом не делать её обязательным условием установки.

Это не означает, что мы пишем всё самостоятельно. Наоборот, мы стараемся переиспользовать стандартные Kubernetes-операторы и существующие технологии. Собственная работа сосредоточена на том, как сделать из них единую систему.

На обзорной схеме архитектура разделена на четыре уровня:

Уровень	Что на нём находится	Какую задачу решает
1	Операционная система и железо, Talos Linux	Даёт воспроизводимую основу для работы узлов
2	LINSTOR, сеть, KubeVirt	Предоставляет хранение, связность и виртуальные машины
3	Операторы, Cluster API, мониторинг	Обслуживает жизненный цикл приложений и кластеров
4	Managed Kubernetes, базы данных и пользовательский Kubernetes API	Предоставляет готовые сервисы клиенту

Четыре уровня архитектуры Cozystack

Архитектура Cozystack: от операционной системы и железа до пользовательских managed-сервисов.

Flux CD отвечает за доставку и согласование конфигурации компонентов. Эта схема помогает объяснить, почему интерфейс заказа базы данных — только верхушка системы: ниже должны согласованно работать ещё несколько уровней.

Talos Linux и конфигурация узлов

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

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

На вопрос «это прежде всего про security?» я отвечал, что для нас ключевой эффект — управляемость и воспроизводимость. Внутри системы работают контроллеры, которые приводят её состояние к заданному. Это та же идея reconciliation, на которой построен Kubernetes.

Две части конфигурации

В показанном на слайде YAML есть две основные секции: machine и cluster.

machine описывает конкретную машину: её роль, параметры доступа к Talos API, настройки сети, интерфейсы и диск для установки. На слайде это узел типа control-plane, интерфейс eth0 и установка на /dev/sda.

Секция machine в конфигурации Talos

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

cluster описывает Kubernetes-кластер: endpoint control plane, параметры удостоверяющего центра и настройки компонентов Kubernetes. На слайде endpoint — https://192.168.100.10:6443; тот же адрес фигурирует в настройке виртуального IP. Другим узлам нужно знать, к какому кластеру подключаться.

Секция cluster в конфигурации Talos

Иллюстрация структуры конфигурации, а не реальный конфиг: сертификаты и ключи заменены пустыми строками, часть секций сокращена. Общие параметры cluster дополняются настройками конкретной machine.

Вопрос из зала: как узлы находят друг друга и нужно ли делать bootstrap на каждом?

Bootstrap выполняется один раз, на одном control-plane узле. Остальные машины получают конфигурацию того же кластера и присоединяются к нему. Независимо инициализировать кластер на каждой машине не нужно.

Здесь важно разделять общий адрес API и discovery узлов. В показанной конфигурации VIP 192.168.100.10 даёт устойчивый адрес Kubernetes API: его обслуживает один из control-plane узлов, а при переключении адрес переходит к другому. Discovery через Kubernetes API позволяет Talos получать сведения об участниках уже работающего кластера. Это не заменяет первоначальный bootstrap: сначала должна появиться управляющая часть, к которой можно обращаться.

Зачем мы сделали Talm

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

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

Таким образом, аппаратные различия учитываются при подготовке конфигурации, а сама установка остаётся воспроизводимой. Мы не исправляем сервер вручную после каждого развёртывания.

Образ системы и настройки меняются по-разному

Вопрос из зала: при изменении конфигурации Talos нужно перезагружать узел? А как добавлять модули ядра?

Изменение конфигурации не всегда требует перезагрузки: многие настройки Talos применяет в работающей системе. Обновление образа ОС и состава расширений — другая операция, которая может требовать перезапуска.

Talos использует immutable-образ: системная основа заранее собрана, а нужные для нашей платформы модули подготавливаются вместе с образом. В обычном Linux storage-компонент может запускать DKMS и собирать модуль на каждом узле в рантайме под установленное ядро. Здесь мы переносим эту работу на этап подготовки образа. В результате узлы получают один и тот же проверенный набор компонентов, вместо того чтобы каждый раз собирать его независимо при установке.

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

Почему мы выбрали LINSTOR и DRBD

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

Мы используем LINSTOR и DRBD; развёртывание LINSTOR в Kubernetes обслуживает Piraeus Operator. Здесь полезно разделять их роли. LINSTOR управляет размещением и жизненным циклом томов, а DRBD обеспечивает репликацию блочных устройств. Под ними находятся привычные механизмы хранения, такие как LVM или ZFS.

Слои хранения LINSTOR

LINSTOR управляет стеком хранения, а репликация DRBD работает на уровне ядра.

Поэтому LINSTOR я бы не описывал как прямой аналог Ceph. Это другой подход: управление томами и их репликами поверх стандартных технологий хранения.

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

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

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

Данные и вычисления нужно размещать вместе

На митапе спросили: что происходит, если реплики диска находятся на одних серверах, а виртуальная машина запускается на другом?

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

У этого два уровня. Сначала планировщик учитывает, где уже находятся реплики тома, и старается разместить Pod или VM на подходящем узле. Для этой задачи используется LINSTOR scheduler extender.

В обратную сторону работает auto-diskful в LINSTOR. Если ресурс достаточно долго находится в роли Primary на узле без локальной реплики, LINSTOR может создать там дисковую реплику и синхронизировать данные. Порог задаётся параметром DrbdOptions/auto-diskful. При включённом auto-diskful-allow-cleanup после синхронизации можно удалить лишнюю Secondary-реплику, соблюдая заданное количество копий.

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

Кроме того, требования клиентов бывают разными. Одному нужно разместить всё в пределах одной площадки. Другому — распределить ресурсы между дата-центрами. Это уже часть политики размещения сервиса. Для таких требований у нас есть cozystack-scheduler и абстракция SchedulingClass. Требование к размещению задаётся на уровне сервиса; дальше его должен реализовать механизм планирования.

Такие компоненты мы стараемся делать пригодными для отдельного использования. Если решённая задача полезна и за пределами Cozystack, хочется, чтобы результат можно было переиспользовать.

Виртуальные машины заставили пересмотреть сеть

Изначально мы пробовали строить сеть на Cilium. Он хорошо закрывает многие задачи Kubernetes, но при работе с KubeVirt мы столкнулись с требованиями, которые отличаются от обычного контейнерного сценария.

Виртуальная машина — это полноценная гостевая операционная система. Она может сохранять настройки интерфейсов и ожидать стабильную сетевую идентичность. Например, гостевая Ubuntu после первого запуска может привязать конфигурацию к MAC-адресу. Если после перезапуска окружение интерфейса изменилось, внутри VM появляются проблемы, которых пользователь облака совершенно не ожидает.

Другая задача — live migration. Виртуальная машина должна переехать на другой физический сервер, сохранив сетевую связность. Сеть должна позволять это сделать без привязки адреса VM к конкретному узлу.

Для этой части нам подошёл Kube-OVN. Он даёт необходимые механизмы работы с адресами и MAC-адресами и позволяет организовать сеть для перемещения виртуальных машин между узлами.

В отличие от модели с отдельными диапазонами Pod IP, закреплёнными за узлами, нам нужна адресация, допускающая перемещение нагрузки между серверами. Kube-OVN мы используем как сетевой транспорт для Pod'ов и виртуальных машин. Он позволяет сохранить нужную VM сетевую идентичность при её перемещении.

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

Почему нам важно сохранить модель Kubernetes

Можно было бы объявить стандартную сеть Kubernetes служебной, а всю пользовательскую сеть построить отдельно: через дополнительные интерфейсы и независимые механизмы управления.

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

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

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

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

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

Исходники — lllamnyp/cozyplane, пример работы — демонстрация CozyPlane.

Как я разделяю сеть Kubernetes

Вопрос из зала: если пользователь создаёт Service типа LoadBalancer во вложенном Kubernetes, каким образом туда придёт трафик? Чтобы ответить, сначала полезно разделить четыре разных сетевых механизма.

Сеть физических узлов

Первый уровень — Node network. Узлы должны обмениваться трафиком через физическую сеть. Это может быть сеть провайдера или собственная схема коммутации и маршрутизации.

Если серверы не могут связаться друг с другом, CNI не исправит саму инфраструктурную проблему. И наоборот: наличие связи между узлами ещё не доказывает, что работает сеть Pod'ов.

Сеть Pod и роль CNI

При запуске Pod создаётся отдельное сетевое пространство имён. В типичном показанном на слайде сценарии оно связано с хостом через пару veth. CNI настраивает подключение нагрузки и необходимую связность.

Сеть узлов и сеть Pod

Физическая связность узлов и связность Pod — два разных уровня. CNI связывает сетевые пространства нагрузок с кластерной сетью.

В объяснении я отдельно обращал внимание на направления: Pod должен достигать другого Pod, в том числе на другом узле; узлы и Pod'ы также должны взаимодействовать в рамках сетевой модели кластера. Этим Kubernetes отличается от привычной схемы, где гипервизор и гостевые машины живут в полностью отдельных сетях.

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

Важны и системные нагрузки с hostNetwork. Не всё в Kubernetes запускается в обычной сети Pod'ов: отдельные компоненты используют сеть узла. Поэтому связность между этими уровнями нужна для штатной работы платформы.

Services не являются отдельной физической сетью

Теперь представим, что приложение работало в pod3. Pod удалили, на его месте появился pod5, и адрес нового экземпляра изменился. Использовать IP конкретного Pod как постоянный адрес приложения нельзя.

Для этого существует Service: он даёт стабильную точку обращения, а сервисный механизм направляет трафик к актуальным экземплярам приложения. В обычной реализации эту роль выполняет kube-proxy; в другой конфигурации — соответствующий механизм Cilium.

Обработка сервиса на узле

Сервисный механизм работает на узлах и направляет трафик к выбранным Pod. Он не требует единственного центрального сервера для всех Services.

На слайде эта часть называется Service network. Но это не ещё один физический интерфейс или отдельный VLAN. Это слой адресации и обработки пакетов. Он работает поверх уже существующей связности и позволяет отделить адрес сервиса от жизненного цикла конкретного Pod.

Как трафик приходит снаружи

Четвёртая задача — внешняя балансировка. Работающий ClusterIP внутри кластера сам по себе не обеспечивает доступ внешнему клиенту.

В облаке пользователь заказывает Service типа LoadBalancer, а cloud-интеграция создаёт или настраивает внешний балансировщик. Затем трафик направляется в кластер и доставляется к нагрузке.

Внешний балансировщик и сервисный слой

Внешняя балансировка доставляет трафик к кластеру; сервисный слой направляет его к нужной нагрузке.

На собственном железе такую функцию тоже нужно реализовать. Мы используем MetalLB и интегрируем его с сетью площадки. Внешние адреса могут приходить через L2 или маршрутизируемую схему; это зависит от окружения.

Для вложенного Kubernetes эта задача связывается с нижележащей платформой через cloud controller manager. Пользователь создаёт LoadBalancer в своём API, а управляющий компонент обеспечивает соответствующий ресурс в инфраструктуре. Поэтому «запустить API-сервер Kubernetes» и «предоставить managed Kubernetes с работающим LoadBalancer» — разные объёмы работы.

Проверять эти четыре уровня нужно отдельно: связь узлов, связь Pod'ов, обработку Services и доставку внешнего трафика. Успешная проверка одного уровня ещё не доказывает работоспособность следующего.

Входящий и исходящий трафик разные истории

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

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

Для таких сценариев мы используем policy routing. У нас есть контроллер, который помогает настраивать соответствующие правила на узлах: определённый трафик должен выходить через определённый маршрут и интерфейс.

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

Сам контроллер — проприетарный. Механизмы source-based и policy-based routing я раньше разбирал в статье «Тонкая настройка маршрутизации для MetalLB в режиме L2».

Пользовательский API поверх Flux

Следующий вопрос — как дать пользователю возможность заказывать сервисы.

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

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

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

В Kubernetes есть разные способы расширить API. Один из самых известных — CRD и контроллеры. Мы также используем механизм агрегации API: регистрируем собственный API-сервер, который обслуживает определённую группу ресурсов.

Здесь полезная аналогия — metrics-server. Ресурсы его API доступны через Kubernetes API, но обслуживает запросы отдельный компонент. Аналогично мы регистрируем свою API-группу через APIService, и kube-apiserver перенаправляет запросы соответствующему серверу.

Cozystack API Server в Kubernetes Aggregation Layer

Группа apps.cozystack.io обслуживается отдельным API-сервером, который работает с HelmRelease. Операторы и Helm controller продолжают выполнять свои задачи через Kubernetes API.

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

Пользователь видит обычные Kubernetes-объекты. С ними можно работать привычными инструментами и применять стандартную модель разграничения доступа. Но за ними стоит наша логика представления приложений поверх Flux и HelmRelease.

Путь запроса выглядит так: пользователь создаёт объект сервиса в API Cozystack; наш API связывает его с параметрами приложения и ресурсом Flux; Helm chart разворачивает низкоуровневые объекты; их жизненный цикл обслуживают специализированные операторы.

Это разделение ответственности: API Cozystack определяет, что пользователь вправе заказать, Flux доставляет описание, а оператор приложения отвечает за специфическую логику самого сервиса. Исходный код платформы доступен в cozystack/cozystack.

Подробное объяснение этой модели — в статье о Cozystack API и Kubernetes Aggregation Layer.

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

Каталог приложений должен расширяться независимо от платформы

Из этого следует ещё одна идея: каталог сервисов не должен навсегда оставаться жёстко зашитым в платформу.

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

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

Здесь важно сохранить целостность пользовательского интерфейса. Подключение нового оператора должно сопровождаться описанием того, что именно пользователь заказывает и какие гарантии платформа готова дать.

Мониторинг и доступ часть готового сервиса

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

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

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

Отдельная часть — управление идентификацией и доступом. В презентации показана интеграция с Keycloak, LDAP, Active Directory и OIDC-провайдерами. Пользователь может иметь доступ к нескольким тенантам, поэтому учётная запись и границы инфраструктурных ресурсов не должны быть одной и той же сущностью.

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

Тенанты рекурсивная модель и разные границы изоляции

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

На уровне реализации тенант связан с Kubernetes namespace. Но namespace сам по себе не отвечает на все вопросы изоляции.

Рекурсивная структура тенантов и их компонентов

Компоненты могут выделяться на разных уровнях дерева тенантов.

На слайдах это показано деревом: tenant-root, вложенный tenant-foo и ещё один уровень — tenant-bar. Рядом с тенантами размещены инфраструктурные компоненты и приложения. Так можно показать одновременно организационную структуру и то, какие сервисы выделены на конкретном уровне.

Здесь важно различать soft multitenancy и hard multitenancy — разные требования к границе между тенантами.

В сценарии soft multitenancy пользователи разделяют общую инфраструктуру, а доступ и ресурсы разграничиваются на уровне Kubernetes: namespace, RBAC, квоты и сетевые политики. Например, пользователь заказывает управляемую базу данных. Он управляет разрешёнными параметрами, а платформа запускает известную нам нагрузку с контролируемой конфигурацией.

В сценарии hard multitenancy мы исходим из того, что независимые пользователи могут запускать собственный код: произвольные контейнеры, GitLab или любое другое приложение. Здесь нужна более строгая граница изоляции. Для этого пользователь получает отдельный Kubernetes-кластер с worker-узлами в виртуальных машинах либо отдельную виртуальную машину.

Мы не считаем контейнерную изоляцию достаточной универсальной границей между независимыми пользователями, которым разрешено запускать что угодно. Поэтому административные права внутри пользовательского Kubernetes не означают административных прав в management-кластере.

Общие сервисы и выделенные компоненты

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

Пользователь при этом должен видеть услугу на соответствующем уровне абстракции. Заказывая S3 bucket, он не обязан разбираться, какой именно компонент реализует объектное хранилище. Это решение платформы.

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

Proxmox и модель managed Kubernetes в облаке

Вопрос из зала: как ты относишься к Talos в виртуальных машинах на Proxmox?

Я много раз видел такой сетап, и мне он нравится. Это вполне рабочая связка, с которой можно идти в production.

Что мне не нравится — когда внутри этих VM появляется инфраструктурное состояние, например SDS-хранилище. В моём понимании Kubernetes-машины должны быть эфемерными: их можно удалить и пересоздать, сохранив данные отдельно. Proxmox ближе к pet-модели, в которой конкретную VM обслуживают как отдельный сервер. Поэтому вопрос не столько в возможности запустить Talos, сколько в том, какие жизненные циклы и зависимости мы создаём.

В традиционной виртуализации администратор часто работает с конкретными физическими серверами и VM. Он видит топологию, выбирает размещение, устанавливает гостевую ОС и дальше обслуживает её как отдельный сервер.

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

Из Proxmox можно строить интеграции для Kubernetes. В разговоре я упоминал CSI-драйвер, который позволяет Kubernetes заказывать тома в такой инфраструктуре. Сам по себе этот драйвер, однако, закрывает только storage-интеграцию: для облачной модели нужны и остальные механизмы.

Упомянутый драйвер — sergelogvinov/proxmox-csi-plugin.

Control plane compute и storage обслуживаются отдельно

На слайде с типичной схемой Kubernetes в облаке control plane нарисован отдельным блоком, рабочие узлы — отдельными машинами, PersistentVolume — отдельно от них. Внешний балансировщик тоже имеет собственный жизненный цикл.

Типичная схема managed Kubernetes в облаке

Control plane, рабочие узлы, постоянные тома и внешний балансировщик — разные обслуживаемые сущности.

«Отдельно» здесь означает прежде всего разные жизненные циклы и границы ответственности. Пользовательские данные не должны исчезать при замене worker-ноды, а control plane не должен требовать существования конкретной рабочей машины. Это не требование купить физически отдельное железо для каждого блока схемы.

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

После появления новых worker-нод кластер может снова исполнять нагрузки, используя сохранившиеся данные. Пользовательские приложения, конечно, не работают, пока нет вычислительных узлов, но потеря workers сама по себе не должна означать потерю кластера и его дисков.

Именно поэтому я говорю, что worker-ноды managed Kubernetes должны быть заменяемыми. На них не должно находиться единственное состояние, без которого кластер нельзя восстановить.

Почему на bare metal сложнее

В самостоятельном bare-metal кластере легко совместить на одних узлах control plane, пользовательские приложения и локальное хранилище. Такой дизайн может быть оправдан, но при отказе сервера затрагивает сразу несколько уровней системы.

Для managed Kubernetes хотелось бы дать пользователю другую модель: управление кластером обслуживается отдельно, вычислительные узлы можно заменить, а постоянные диски предоставляет нижележащая инфраструктура. Это позволяет обновлять, добавлять и удалять ноды, не превращая каждую операцию в ручное спасение приложения.

У самой платформы всё равно есть физические узлы и связанные с ними отказы. Но мы контролируем набор нагрузок management-кластера и проектируем их под эти условия. А внутри пользовательского кластера предоставляем обычные Kubernetes-интерфейсы: Node, PersistentVolumeClaim, Service, группы рабочих узлов.

Cluster API и Kubernetes внутри Kubernetes

Теперь посмотрим, как из одного приложения в каталоге получается пользовательский Kubernetes-кластер.

В Cozystack есть management-кластер, внутри которого работают управляющие компоненты платформы. Пользовательский кластер имеет собственный Kubernetes API и собственные worker-ноды. Административные права пользователя распространяются на его кластер.

Control plane пользовательского кластера мы запускаем с помощью Kamaji. Это оператор hosted control planes: компоненты control plane работают как Pod'ы внутри management-кластера. На митапе я показывал такие Pod'ы с контейнерами управляющей части.

Worker-ноды создаются как виртуальные машины через KubeVirt. Для пользователя это обычные Kubernetes-ноды, к которым подключается kubelet. Снаружи мы можем видеть соответствующую VM, подключаться к её консоли и управлять её жизненным циклом.

Приложение создаёт набор декларативных ресурсов

Пользовательский ресурс Kubernetes в каталоге — верхнеуровневое описание. За ним стоит Helm chart, создающий набор ресурсов, в том числе объекты Cluster API.

Cluster API — проект управления жизненным циклом кластеров через Kubernetes API. Его контроллеры работают в management-кластере и следят за декларативными объектами кластеров и машин.

Объекты Cluster API и три группы провайдеров

На слайде показаны KamajiControlPlane, KubevirtCluster, KubevirtMachineTemplate и KubeadmConfigTemplate. Каждый провайдер обслуживает свою часть модели.

Три роли провайдеров

У Cluster API есть три важных для этого объяснения типа провайдеров.

Control plane provider отвечает за управляющую часть кластера. В показанной схеме это KamajiControlPlane. Соответствующий провайдер Kamaji связывает модель Cluster API с hosted control plane.

Infrastructure provider отвечает за инфраструктурные объекты — например, виртуальные машины. В нашем случае на схеме показаны KubevirtCluster и KubevirtMachineTemplate, а реализацию предоставляет Cluster API Provider KubeVirt.

Bootstrap provider подготавливает конфигурацию, с которой созданная машина сможет стать узлом нужного Kubernetes-кластера. На этих слайдах показан KubeadmConfigTemplate.

Именно эту последнюю часть легко пропустить. Создать VM недостаточно: её гостевой системе нужно знать endpoint API-сервера, параметры подключения и способ инициализации kubelet. Bootstrap provider формирует необходимые данные и сохраняет их в Secret, который затем используется при создании машины.

В зависимости от ОС bootstrap-механизм может отличаться. На слайдах я объяснял вариант с kubeadm; у Talos есть отдельный bootstrap provider. Эти варианты нельзя смешивать в одну конфигурацию только потому, что сверху у них одинаковый объект Cluster.

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

MachineDeployment MachineSet и Machine

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

MachineDeployment описывает группу машин и желаемое состояние этой группы. Под ним появляется MachineSet, а тот управляет отдельными объектами Machine.

Связь похожа на знакомую модель Deployment → ReplicaSet → Pod, только предмет управления здесь — машины Kubernetes-кластера.

Machine связан с инфраструктурным объектом провайдера. В случае KubeVirt дальше появляются объекты виртуализации: VirtualMachine, работающий экземпляр VirtualMachineInstance и Pod, в котором исполняется виртуальная машина.

От MachineDeployment к Pod виртуальной машины

Верхняя цепочка управляет группой Kubernetes-машин; нижняя показывает, как конкретная машина исполняется через KubeVirt.

Это не означает, что гостевой Kubernetes считает свой worker обычным Pod management-кластера. У каждого уровня собственное представление. В management-кластере мы видим объекты Cluster API и виртуализации, а внутри пользовательского — объект Node.

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

Один management-кластер обслуживает несколько пользовательских

На следующей схеме один management-кластер через Cluster API управляет несколькими tenant Kubernetes-кластерами.

Management-кластер и пользовательские кластеры

Cluster API управляет жизненным циклом кластеров, но cloud-интеграции и дополнительные компоненты нужно настроить отдельно.

После создания нод работа ещё не закончена. Требуются как минимум cloud controller manager, CSI и Cluster Autoscaler. На слайде они перечислены рядом с вопросом о настройке пользовательских кластеров.

Cluster API создаёт и обслуживает кластерные машины. Но он сам по себе не гарантирует, что пользовательский Service типа LoadBalancer получит внешний адрес или что PVC будет обеспечен диском нижележащей платформы. Для этого нужны соответствующие интеграции.

Что делают CCM CSI и Cluster Autoscaler

Cloud controller manager, или CCM, связывает Kubernetes с инфраструктурой. В обсуждении мы говорили о двух конкретных задачах: обслуживании LoadBalancer и согласовании состояния нод с существованием виртуальных машин. Если VM больше не существует, соответствующая нода не должна бесконечно оставаться в кластере как потерянный объект. Для KubeVirt есть cloud-provider-kubevirt.

CSI обеспечивает работу с постоянными дисками. Пользователь создаёт PVC внутри своего кластера, а интеграция должна выделить и подключить том, предоставляемый нижележащей инфраструктурой. Здесь используется KubeVirt CSI driver. На митапе я также упоминал файловые тома ReadWriteMany: для них используется схема с NFS-сервером, которую обслуживает платформа.

Cluster Autoscaler меняет количество worker-нод в соответствии с потребностями кластера и возможностями групп машин. Чтобы пользователь получил реальное увеличение вычислительных ресурсов, он должен быть связан с механизмом создания нод, а не просто видеть неразмещённые Pod'ы.

Это разные контроллеры и разные задачи. Они вместе превращают запущенный Kubernetes в облачный сервис.

Где исполняются управляющие компоненты

Размещение компонентов managed Kubernetes

Управляющие компоненты располагаются со стороны платформы; CNI и node-часть CSI работают на пользовательском worker.

Такое размещение важно для границы доступа. Пользователь является администратором своего Kubernetes. Если принести туда секреты для управления management-кластером, он потенциально сможет ими воспользоваться.

Поэтому компонент, которому нужны права на нижележащую инфраструктуру, можно оставить снаружи пользовательского кластера. Он обращается к нужным API, но его инфраструктурные credentials не становятся обычным Secret в среде, полностью подконтрольной клиенту.

Node-часть CSI при этом должна работать рядом с workload и подключать диски на узле. CNI тоже настраивает сеть на worker. То есть «вынести контроллеры наружу» не означает, что внутри пользовательского кластера вообще нет служебных компонентов.

Доставку конфигурации и компонентов мы связываем через Flux. На слайдах отдельно показано, что часть ресурсов применяется в management-кластере, а часть — в tenant-кластере. Место выполнения определяется тем, какие API и какие права нужны компоненту.

Пользователь в итоге получает kubeconfig, обычный Kubernetes API, постоянные тома и работающие балансировщики. А платформа обслуживает цепочку от его декларативного заказа до Pod'ов control plane, рабочих VM и инфраструктурных интеграций.

Установка в закрытом контуре

Ещё один практический вопрос — можно ли установить платформу без доступа к внешним сервисам.

Для деплоя платформы в air-gap единственная внешняя зависимость — хранилище образов и артефактов, например Nexus. «Внешняя» здесь означает внешняя по отношению к Cozystack: сам registry может находиться внутри закрытого контура и не иметь доступа в интернет.

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

Учёт ресурсов отдельный слой

Для хостинга и сервис-провайдера мало дать пользователю возможность заказать VM или базу данных. Нужно ещё понимать, сколько ресурсов он использовал.

В Enterprise-версии у нас есть компонент учёта потребления, который предоставляет отчёты через Kubernetes API. На слайдах видно, как это устроено: клиент отправляет UsageReport в группе billing.aenix.io/v1alpha1, а billing-apiserver обращается к VictoriaMetrics.

Запрос отчёта о потреблении ресурсов

Запрос задаёт tenant, workload и временной интервал через startTimestamp и endTimestamp.

В ответе появляется report.consumers: записи связаны с тенантом, конкретной нагрузкой, её типом и интервалом. Внутри consumptions перечислены количества ресурсов. В примере это vCPUHours, MemoryGiBHours и EphemeralStorageGiBHours — ресурсы с учётом времени, а не просто мгновенный снимок CPU и памяти.

Ответ API с потреблением отдельных нагрузок

Отчёт содержит потребление ClickHouse и worker-машины managed Kubernetes.

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

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

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

Bare-metal provisioning

Для предоставления физических серверов рассматриваем Tinkerbell. Это отдельная задача: управлять подготовкой машины, установкой системы и передачей её пользователю. На момент разговора этот сценарий не был готовой реализованной функцией платформы.

GPU проброс, контейнеры и совместное использование

В задачах с GPU важно различать проброс устройства в виртуальную машину, использование GPU контейнерными нагрузками и разделение устройства на части. В разговоре я упоминал HAMi: он предоставляет механизмы совместного использования GPU контейнерными нагрузками через Kubernetes. Это другой уровень, чем передача GPU виртуальной машине. Наличие одного механизма не означает автоматической поддержки всех остальных. Здесь остаются вопросы к драйверам, аппаратным возможностям и конкретному способу интеграции.

Практические шаги описаны в документации Cozystack: GPU passthrough для виртуальных машин и GPU для контейнерных нагрузок.

Как мы работаем с заказчиками

Вопрос из зала: что именно вы поддерживаете и как устроена работа с заказчиком?

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

При этом мы заранее разделяем ответственность: договариваемся, какую часть инфраструктуры обслуживаем мы, а какая остаётся у команды заказчика. Для согласованного объёма предоставляем поддержку с гарантиями по SLA — SLA-guaranteed support.

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

AI ускорил разработку. Как теперь проверять результат

В конце митапа разговор неожиданно ушёл от сетей и хранилища к организации разработки. Но для инфраструктурного проекта это вполне связанная тема.

Мы активно используем AI-инструменты, и это очень сильно повысило производительность команды.

Вместе со скоростью изменилось и узкое место. Написать код становится проще, а определить, что именно нужно сделать, правильно спроектировать изменение и проверить результат — по-прежнему сложно.

Особенно в инфраструктуре. Ошибка здесь может проявиться только при отказе узла, редкой последовательности событий или восстановлении после сбоя. Убедительный код и успешный простой запуск ещё не доказывают, что механизм корректен.

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

Один из упомянутых открытых проектов — lexfrei/ccc.

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

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

Мы также смотрим в сторону организации работы через Special Interest Groups (SIG) по постоянным направлениям и временные Working Groups под конкретные бизнес-задачи. У направления есть ответственность за свою часть системы; у проекта — задача собрать нужных участников и довести изменение до результата.

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

У Aeman есть MCP-интерфейс, поэтому в планировании участвуют и AI-агенты: через него можно работать с задачами и обновлять план. Подробнее о том, как мы это устроили, рассказали в статье на Хабре; исходный код доступен на GitHub.

Где посмотреть код и продолжить обсуждение

Платформа развивается открыто. Cozystack находится в CNCF Sandbox, и для нас важно участие других компаний и независимых разработчиков. Хочется, чтобы продукт мог развиваться шире одной команды и одного коммерческого предложения.

Исходный код платформы — github.com/cozystack/cozystack, сайт проекта — cozystack.io. В тексте выше оставлены ссылки на отдельные технологии и провайдеры, чтобы можно было перейти от схемы к их реализации.

Присоединиться к встречам и найти можно на странице сообщества Cozystack. Формат встреч и порядок добавления тем описаны в community_meeting.md.

Хабр Курсы для бэкендеров

Сколько же близких звёзд мы проглядели?

wmlab — Sun, 04 Oct 2026 00:38:57 +0000

wmlab1 час назад

Простой

7 мин

инфракрасный обзор неба, WISE

Спросите любого образованного человека, далёкого от астрономии, какая звезда ближайшая к Солнцу, и он ответит, не задумываясь: «Альфа Центавра, конечно!» Воспетая фантастами и популяризаторами науки первая остановка за пределами Солнечной системы! Те, кто в теме, уточнят, что это не одна звезда, а три: A, B и Проксима, или «Ближайшая» на латыни. А какая вторая? Навскидку, без гугла, википедии и ChatGPT, немногие вспомнят звезду Барнарда, самую быстродвижущуюся звёздочку на нашем небосводе, хотя и очень тусклую. А какая третья? Кто-то вытащит из закоулков памяти Вольф 359, упомянутый в «Стартреке», и ошибётся. Потому что Вольф уже не третий и даже не четвёртый. Вот только-только обнаружены почти невидимые в оптические телескопы чёрные солнца — «коричневые карлики», как их называют астрономы, которые не светят, но греют. Обнаружены случайно, среди старых инфракрасных панорам неба, на домашних ноутбуках. А ведь писали фантасты про них, давно писали: и Ефремов в «Туманности Андромеды» (помните Железную звезду?), и Гуревич в «Инфра Дракона». Пусть в этих системах почти нет света, зато тепло, а где есть тепло, может существовать и жизнь. И кто его знает, сколько ещё чёрных звёзд в окрестностях Солнца прячется до поры? Может, они совсем рядом, ближе Ближайшей, и лететь далеко не придётся?

Главу о звёздах в учебниках астрономии не переписывали почти век. С 1916 года, когда Эдвард Барнард открыл свою «летящую звезду», список ближайших соседей Солнца казался отлитым в бронзе: тройная Альфа Центавра (4,37 светового года), одинокий тусклый красный карлик Барнарда (5,96) и Вольф 359 (7,86). Если что-то и могло прятаться у нас под носом незамеченным, то разве что ледяные булыжники облака Оорта.

И вдруг в марте 2013 года, прямо между звездой Барнарда и Вольфом 359, на дистанции 6,5 светового года (всего два парсека, Карл!), обнаружили новую звёздную систему. Это было всё равно что посреди оживлённого Ла-Манша наткнуться на неупомянутый в лоциях архипелаг. Кевин Луман из Пенсильванского университета методично перелопачивал терабайты архивов инфракрасного телескопа WISE. WISE крутился на околоземной орбите с декабря 2009-го по февраль 2011 года и дважды отснял всё небо в среднем инфракрасном диапазоне. Луман сравнивал снимки, сделанные с разницей в полгода. Из-за параллакса и собственного движения близкие к нам звёзды ползут по небесной сфере заметно быстрее далёких. В созвездии Парусов Луман засёк тусклый объект, который нёсся по небу со скоростью 2,79 угловой секунды в год. Просто чтобы оценить скорость: открытое небесное тело пересекло бы видимый диск Луны всего за 650 лет. Быстрее на всём небосводе несутся лишь считанные единицы звёзд во главе со звездой Барнарда.

Почему же мы его не замечали? В оптическом диапазоне объект практически невидим. Когда, уже зная точные координаты, астрономы подняли старые фотопластинки, вскрылся конфуз: система десятилетиями позировала на обзорных снимках! Её нашли и на фотопластинках Паломарского обзора 1978 года, и в коллекциях Schmidt, DENIS и 2MASS. Призрак маячил у нас перед глазами тридцать пять лет, но на него никто не обращал внимания, он выглядел слабой точкой на пределе видимости, больше похожей на дефект эмульсии.

Luhman 16 A&B

Когда на объект навели тяжеловес VLT, точка распалась надвое. Так мы познакомились с нашими соседями — двойной системой Luhman 16 (A и B). Строго говоря, это не совсем звёзды. Это пара коричневых карликов — космических неудачников, застрявших между планетами-гигантами и настоящими звёздами. Больший в паре весит как 35 Юпитеров, его меньший брат тянет на 29. Чтобы в недрах протозвезды запустился термоядерный синтез, газовому шару требуется накопить минимум 75–80 масс Юпитера. Братья не собрали и половины нужного веса. Единственное, на что их хватило в ранней юности, так это на короткую вспышку горения дейтерия. Но его запасы ничтожны, они прогорели за считанные миллионы лет, слегка подогрев обоих, и на этом всё.

В их спектрах чётко прорисовались линии поглощения лития. В настоящих звёздах конвекция уносит литий в ядро, где он мгновенно сгорает. Если в спектре карлика есть литий, значит, термоядерный реактор в его недрах так и не заработал. Тем не менее холодными эти миры назвать нельзя. Температура поверхности 16A — примерно 1000 °C, 16B — около 900 °C. Вблизи они выглядят как слабо тлеющие угли размером с Юпитер. Среди коричневых карликов вообще не принято расти в размерах при увеличении массы, они просто становятся плотнее.

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

реальный скан облачности

И эта система была только первой ласточкой в серии открытий. Спустя всего год, в апреле 2014-го, окрылённый успехом Луман в тех же данных WISE отыскал четвёртого по близости соседа Солнца — объект WISE 0855−0714 на расстоянии 7,2 светового года. Это одинокий коричневый карлик массой всего 10 Юпитеров, чья температура колеблется от –50 до –10 °C, а, скорее, планета-гигант, летящая в межзвёздной пустоте и укутанная облаками из настоящего водяного льда.

WISE 0855−0714

Окрестности Солнца оказались набиты призрачными мирами. Казалось бы, раз уж мы проморгали пару звёздных систем в двух шагах от дома, пора расчехлить наш флагман — «Джеймс Уэбб», тем более что он как раз специализируется на инфракрасном диапазоне. Пусть он методично осмотрит ближний космос! Но вот парадокс: наш самый продвинутый телескоп для этой задачи непригоден. «Уэбб» — это снайперская винтовка, а не радар кругового обзора. Его камера NIRCam видит лишь крошечный пятачок неба размером в две с половиной угловые минуты; это всё равно что разглядывать ночной небосвод через соломинку для коктейля. «Уэбб» уже наблюдал Luhman 16, зная его точные координаты: анализировал спектры бегущих облаков и пытался разглядеть экзопланеты. Чтобы просканировать «Уэббом» всё небо в поисках неизвестных соседей, потребовались бы тысячи лет непрерывных наблюдений.

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

Тогда NASA решилось на беспрецедентный шаг: позвало на помощь армию любителей. В феврале 2017 года агентство запустило проект Backyard Worlds: Planet 9 («Миры на наших задворках: Девятая планета»). Скачанное приложение показывало короткую анимацию из четырёх инфракрасных кадров одного и того же участка неба. Фон из сотен неподвижных звёзд вычитался, а пользователю оставалось лишь вглядываться в экран и искать точку, которая слегка смещалась между кадрами. Это был триумф распределённого анализа. Армия из 150 тысяч энтузиастов со всего мира, школьников, пенсионеров, бухгалтеров, таксистов, всех, кто хоть немного интересовался космосом, сделала то, на что у профессионалов ушли бы десятилетия.

интерфейс приложения

Листая снимки в свободное время, энтузиасты открыли больше 4000 невидимых глазу объектов. Один из них, холодный субкарлик Ross 19B, нашли одновременно четверо — обычные парни, никогда не смотревшие в телескоп, в одночасье стали соавторами статьи в The Astrophysical Journal. Другой любитель выловил уникальный объект, получивший прозвище «Случайный» — древнейший коричневый карлик возрастом в 10 миллиардов лет, несущийся сквозь нашу Галактику со скоростью 200 километров в секунду.

Значит ли это, что теперь-то окрестности Солнца тщательно осмотрены? Ничуть. Даже меньше, чем на четверть. Ведь метод сравнительных снимков держится на двух фундаментальных допущениях: тело обязано излучать достаточно тепла и обязано быстро смещаться. А если звезда холодная? А если звезда несётся не поперёк нашего взгляда, а почти вдоль луча зрения — прямо на нас или от нас? Тогда на покадровой анимации такой объект не сдвинется вовсе и не продемонстрирует тот единственный признак, по которому его ищут.

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

Поиск по инфракрасным картам эту гипотезу опроверг: нет, столь массивного спутника у Солнца нет. Любой газовый гигант массой с Юпитер исключён вплоть до расстояния в 82 000 а.е. (примерно 1,3 светового года). Объект поменьше, размером с Сатурн, не может прятаться ближе 28 000 а.е. (0,44 светового года).

Но между внешней границей этого поиска и Проксимой лежит бездна протяжённостью в три световых года, и там добровольцы на снимках WISE не разглядели ничего. Пара Luhman 16, находящаяся гораздо дальше, весит как три десятка Юпитеров и всё ещё пылает жаром в тысячу градусов, сияя в инфракрасных лучах как маяк. А вот холодные или небольшие миры, тела, летящие вдоль луча зрения, с помощью архива WISE не отыскать. И там, дальше светового года от нас, может скрываться всё что угодно.

Небо с тех пор не переснималось ни разу, все что у нас есть, это снимки этого уже исторического WISE/NEOWISE. За эти годы чувствительность детекторов выросла в разы, методы обработки сигнала тоже ушли вперёд, а вот основной источник данных для поиска тёмных соседей остался прежним. А значит, мы судим о наших окрестностях по железке пятнадцатилетней давности. Что изменилось бы, если бы тот же поиск провести сегодня, с более чувствительным приёмником или с более длинной базой наблюдений, растянутой не на полгода, а на несколько лет сразу? Сдвинулась бы граница в 26 000 астрономических единиц до 50 000? До 100 000? Никто пока не повторил поиск с новым оборудованием. Метод работает, а инструмент давно устарел.

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

Четыре с лишним световых года до системы Альфы Центавра непреодолимы с современными технологиями. Даже для полуфантастических проектов вроде Breakthrough Starshot, планирующих разогнать микрозонды лазерами до 20% скорости света, это путь длиной в четверть века плюс гора нерешенных технических проблем. Но если тёмное солнце с тёплой планетой прячется в дальних окресностях Солнца, вся бухгалтерия межзвёздных путешествий меняется на глазах. И увидеть чужой мир на снимках имеем шанс если не мы, то наши праправнуки. И если в следующий раз, услышав уверенное «Альфа Центавра, конечно!», не спешите соглашаться. Возможно, первая остановка за пределами Солнечной системы ждёт нас прямо за порогом, в темноте, где мы еще не пошарили как следует.

Хабр Курсы для всех

Налоги для ИТ-компаний в 2027 году: что меняет новый законопроект для ИТ-льгот, КИК и цифровых платформ

Jul_tsal — Sat, 03 Oct 2026 23:23:52 +0000

Jul_tsal1 час назад

Средний

14 мин

Обзор

30 сентября Правительство направило в Государственную Думу масштабный законопроект, состоящий из 204 страниц поправок в Налоговый кодекс. Документ охватывает широкий спектр вопросов: от НДФЛ и налога на прибыль до регулирования контролируемых иностранных компаний (КИК), трансфертного ценообразования (ТЦО), деятельности цифровых платформ и страховых взносов, а также содержит множество узкоспециализированных изменений.

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

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

Важно отметить, что речь идет о законопроекте, а не об уже действующем законе, поэтому текст может претерпеть изменения. Более того, в части ИТ-льгот уже сейчас наблюдается существенное расхождение между пояснительной запиской и самим проектом нормативного акта, что будет рассмотрено далее.

Что я бы вынесла уже сейчас к обсуждению на уровень CEO, CFO и собственников ит-бизнеса

Изменение	Кого касается	Что меняется для бизнеса
Новый вид профильного ИТ-дохода	провайдеры цифрового контента	продажи электронных книг, публикаций и изображений смогут попадать в 70% профильную выручку
Бухгалтерская отчетность становится условием ИТ-льгот	все ИТ-компании, использующие налоговые ит-льготы	ошибки в бухгалтерской отчетности создают прямой налоговый риск, так как соблюдение порядка отчетности становится обязательным условием
В пояснительной записке заявлена борьба с искусственным цвеличением 70% внутри группы компаний	Дочерние ит-структуры в группах компаний	необходимо проверять насколько налоговые ит-льготы зависят от внутригрупповой выручки
Платформы включаются непосредственно в налоговое администрирование	маркетплейсы и посреднические цифровые платформы	соблюдение налоговых требований становится частью ИТ-продукта и ИТ-инфраструктуры
Меняются правила КИК	владельцы международных ИТ-холдингов	формальный порог владения смягчается, однако порог прибыли КИК предлагается исключить
Консолидация (объединение) доходов физлица под шкалу 13–22%	собственники и топ-менеджмент	зарплата, дивиденды, инвестиционные и часть иных доходов начинают суммироваться для расчета НДФЛ
Растут налоговые штрафы	весь бизнес	стоимость нарушения налоговых обязанностей увеличивается

1. ИТ-льготы сохраняются. Но появляется новое условие

На текущий момент аккредитованные российские IT-компании, соответствующие установленным критериям, имеют право использовать пониженную ставку налога на прибыль, где основным условием является доля профильного дохода от ИТ-деятельности не менее 70%.

Предлагаемый законопроект не предусматривает отмену данных льгот. Дополняют виды профильной ит-выручки.

Электронные книги и другой цифровой контент смогут попасть в профильную выручку

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

электронным книгам;
другим электронным публикациям;
графическим изображениям.

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

2. Бухгалтерская отчетность становится элементом ИТ-льготы

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

Ранее при проверке соответствия льготной деятельности фокус смещался преимущественно на наличие аккредитации, характер деятельности, профиль продукта, условия договоров и долю доходов, превышающую 70%. То есть схема проверки выглядела так:

аккредитация → деятельность → продукт → договор → 70% доходов.

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

Для зрелой компании сама по себе своевременная сдача отчетности кажется технической задачей. Однако, учитывая, что статус ИТ-резидента способен приносить экономический эффект в десятки миллионов рублей ежегодно, любые неточности в отчетах перестают быть лишь внутренней проблемой бухгалтерского отдела. Эти проблемы становятся явным финансовым риском для топ-менеджмента и CFO.

Поэтому контроль ИТ-льгот постепенно должен выглядеть не как: «В конце квартала бухгалтер проверит 70%», а эволюционировать в комплексную систему контроля:

аккредитация → квалификация доходов → отчетность → подтверждающие документы → регулярная проверка → передача критических вопросов руководству.

3. Самая интересная поправка, которой пока нет в тексте закона

Для группы компаний это положение имеет особое значение.

В пояснительной записке Правительство декларирует еще одну цель: предотвратить искусственное завышение доли льготируемых доходов за счет сделок между аффилированными лицами. Аналогичная формулировка приведена и в разделе, посвященном страховым взносам ИТ-организаций.

Механизм действий здесь очевиден. Представим типичную группу компаний:

Материнская компания (80 млн руб. ИТ-услуг)

↓

ИТ-дочка

/ \

внешние ИТ-доходы прочие доходы

10 млн 10 млн

Формально у ИТ-дочки образуется 90 млн профильных доходов (100 млн всех доходов = 90%. И конечно же условие 70% выполняется с запасом. Но 80% всей экономики ИТ-компании сформировано внутри группы.

Согласно ожидаемым изменениям, возникает очевидный вопрос: «Существует ли здесь самостоятельный ИТ-бизнес или группа сформировала необходимую долю выручки с помощью внутригрупповых операций?»

Судя по пояснительной записке, именно такие конструкции находятся в поле внимания законодателя.

Обратите внимание на существенную деталь!

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

- новый цифровой контент

- требование о предоставлении бухгалтерской отчетности.

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

Какие последствия это несет для ИТ-компаний в текущий момент?

Если более 70% выручки формируется за счет материнской структуры или аффилированных лиц, целесообразно уже сейчас просчитать несколько сценариев.

Например: Общая выручка ИТ-компании 100 млн руб.
В том числе:
- профильные внешние клиенты 15 млн руб.;
- профильные сделки внутри группы 70 млн руб.;
- прочие доходы 15 млн руб.

Текущая доля профильной деятельности составляет 85%. Однако, если законодатель ограничит учет внутригрупповых операций, итоговый показатель может существенно измениться.

В настоящее время остаются открытыми следующие вопросы:

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

Поэтому задача финансового директора сейчас не в том, чтобы срочно перестраивать группу, а оценить степень зависимости права на получение льготы от объема внутригрупповой выручки. Задача понять, насколько право на льготу зависит от внутригрупповой выручки.

4. Для маркетплейсов происходит изменение гораздо масштабнее

Если прошлые поправки лишь уточняли правила применения налоговых льгот, то данный законопроект фундаментально трансформирует статус ИТ-продуктов на посреднических цифровых площадках. Платформа теперь интегрируется в систему налогового контроля.

Проект предлагает новую ст. 86.6 НК РФ, согласно которой оператор платформы должен будет:

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

При этом продавцу дается срок до 30 календарных дней для предоставления доказательств, опровергающих выявленный риск.

Таким образом, формируется новый алгоритм налогового администрирования:

ФНС (направляет запрос о налоговом риске / требование / вызов)

↓

Цифровая платформа (передает уведомление и запрашивает документы)

↓

Продавец (предоставляет пояснения и доказательства)

↓

Цифровая платформа

↓

ФНС

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

5. Через платформу можно будет остановить продажи

Данная норма считается одной из самых строгих в рамках законопроекта.
В случае, если продавец:

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

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

Причем поручение будет распространяться на все площадки, где ведет деятельность нарушитель. Оператор обязан выполнить это требование в течение 48 часов. После выполнения задачи налоговый орган обязан выдать указание о возобновлении работы карточек и приема заказов.

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

требование налогового органа → нет реакции → поручение ФНС → приостановление карточек и приема заказов → остановка поступления выручки

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

6. Для самой платформы налоговый контроль становится частью продукта

Этому аспекту необходимо уделить особое внимание CTO и CPO. В случае принятия законодательных изменений делегирование задач исключительно юристам или бухгалтерии станет недостаточным. Платформам потребуется внедрить комплекс технических решений, включающий:

интеграцию с ФНС;
идентификацию партнера;
фиксацию налоговых рисков;
систему уведомлений;
фиксацию момента получения сообщения;
хранение подтверждающих документов;
порядок подготовки и передачи ответа;
нормативы сроков обработки;
журналирование действий;
порядок передачи критических ситуаций ответственным руководителям;
механизм приостановления и возобновления продаж.

Проект предусматривает специальный штраф 100 тыс. рублей за неисполнение оператором поручения ФНС или обязанностей налогового контроля.

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

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

7. Для ИТ-групп с иностранными компаниями меняются правила КИК

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

С одной стороны, законопроект смягчает один из формальных критериев: порог прямого или косвенного участия для определения контролирующего лица повышается с 25% до 50%. Это должно сократить число миноритарных акционеров, автоматически признаваемых контролирующими.

Однако нельзя делать вывод, что при доле владения 49% статус КИК автоматически теряется. Налоговый кодекс РФ предусматривает и иные основания для признания контроля. Более того, закон прямо приравнивает единоличный контроль над иностранной организацией к 100% участию.

Таким образом, ключевым фактором становится реальное влияние на компанию, а не только формальный процент акций.

С другой стороны, проект закона предлагает отменить текущий необлагаемый порог прибыли КИК в размере 10 млн рублей. Пояснительная записка прямо указывает на необходимость исключения этого лимита.

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

Для международных ИТ-групп это сигнал к своевременному пересмотру структуры владения.

8. Трансфертное ценообразование станет административно дороже

Есть еще одно изменение, которое несложно упустить из виду. Законопроект обязывает нотариально заверять перевод на русский язык документов по трансфертному ценообразованию, если они составлены на иностранном языке. Это требование планируется зафиксировать сразу в нескольких статьях Налогового кодекса РФ, касающихся документации по контролируемым сделкам и международным операциям.

Хотя экономическая суть сделки от этого не меняется, для международных технологических групп это означает дополнительные:

расходы;
сроки;
требования к документообороту;
требования к хранению документов.

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

Нормы по КИК и трансфертному ценообразованию проект предлагает вводить с 1 января 2027 года.

9. У собственников ИТ-компаний меняется логика НДФЛ

Значимые нововведения касаются не только специальных льгот для IT-сектора, но и общих правил налогообложения физических лиц. Законопроект предусматривает консолидацию различных видов доходов граждан для применения прогрессивной налоговой шкалы в диапазоне от 13% до 22%.

В единую совокупность доходов, подлежащих обложению по новым правилам, войдут:

зарплату и иные обычные доходы;
дивиденды;
доходы по ценным бумагам;
доходы от реализации долей;
проценты по банковским вкладам;
прибыль КИК;
доходы от майнинга;
операции с цифровой валютой.

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

Визуально это выглядит так:

Зарплата + Дивиденды + Продажа долей / ценных бумаг + Проценты + Прибыль КИК + Цифровая валюта = Совокупность налоговых баз

↓

13% → 15% → 18% → 20% → 22%

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

10. Дорожает сама налоговая ошибка

Законопроект предусматривает существенное повышение размеров финансовых санкций за различные налоговые проступки. Например:

Нарушение	Действующий размер	Предлагаемый
нарушение срока постановки на учет	10 000	30 000
деятельность без постановки на учет	40 000	121 000
минимальный штраф за непредставление декларации	1 000
отдельные нарушения по представлению документов	200	560

Также возрастут штрафы за международные налоговые правонарушения: суммы увеличатся с 500 тысяч до 754 тысяч рублей, а также с 1 миллиона до 1,51 миллиона рублей.

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

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

Какие последствия скрываются за этими поправками?
Если исключить ссылки на конкретные статьи Налогового кодекса, картина изменений системы выглядит довольно логичной.

Ранее схема была прямой:
Наличие ИТ-аккредитации? → Доля профильных доходов превышает 70% → Применяется льготный режим.

В будущем процесс усложнится и станет многоуровневым:
Какая реальная деятельность ведется бизнесом? → Происхождение выручки → Идентификация контрагентов? → Архитектура холдинговой структуры? → Содержание бухгалтерской и налоговой отчетности? → Информация из цифровых источников? → Наличие подтверждающих доказательств? → И лишь затем определяется
налоговый режим.

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

ФНС наращивает возможности для сверки:
договоров ↔ денежных потоков ↔ бухгалтерского учета ↔ структуры группы ↔ данных цифровых платформ ↔ реальной хозяйственной деятельности.

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

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

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

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

2. Аудит процесса сдачи бухгалтерской отчетности
Критически важно формализовать процедуру, четко определив:

ответственного исполнителя;
жесткие сроки;
механизм подтверждения факта отправки документов;
алгоритм эскалации проблем к топ-менеджменту

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

3. Интеграция налоговых требований в продукт для цифровых платформ
Командам по налогам, юридическому сопровождению, продукту и ИТ необходимо разработать единый регламент, который охватывает:

текущий объем собираемых данных и выявление пробелов;
механизмы идентификации налоговых рисков;
процессы уведомления продавцов и фиксации их получения;
правила архивного хранения документации;
распределение зон ответственности за передачу информации;
технические и организационные процедуры приостановки и возобновления продаж.

4. Ревизия зарубежной структуры владения
Для каждой иностранной юрисдикции требуется провести углубленный анализ по следующим параметрам:

доля участия;
уровень фактического контроля;
финансовая прибыль;
наличие льготных режимов;
статус КИК;
перечень контролируемых сделок;
язык оригиналов документов.

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

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

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

Главная интрига законопроекта № 617-9 кроется вовсе не в электронных книгах или росте штрафных санкций. Для меня существеннее иной аспект: налоговые преференции утрачивают статус простого атрибута юридического лица, превращаясь в следствие комплексной системы.

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

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

Истинная сложность заключается в архитектуре самого бизнеса.

Хабр Курсы для всех

[Перевод] 18 изображений раскроют нам, как безмерно велик наш космос

avshkol — Sat, 03 Oct 2026 21:06:14 +0000

avshkol1 час назад

Простой

8 мин

Обзор

Перевод

По мере развития инфляции будет порождена серия вселенных, причем каждая из них будет полностью отрезана от всех остальных, разделенных продолжающимся расширением пространства. Один из этих «пузырей», где инфляция закончилась, дал начало нашей Вселенной около 13,8 миллиардов лет назад, с очень низкой плотностью энтропии, но без какого‑либо нарушения второго начала термодинамики. Источник: Николл Рейджер Фуллер

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

Итан Сигел, 28 сентября 2026

Ключевые тезисы:

Здесь, на Земле, диаметр нашей планеты составляет чуть менее 13 000 километров, или примерно на семь порядков больше размера отдельного человеческого существа.
Но по мере того, как мы поднимаемся ко все более крупным масштабам, мы обнаруживаем, что звезды, звездные системы, звездные скопления, галактики, скопления галактик и многое другое показывают нам, насколько незначительными на самом деле являются человеческие и даже планетарные масштабы.
Даже при всем том, что мы знаем, огромная бездна ненаблюдаемой Вселенной больше, чем совокупность всего, что мы можем видеть. Эти изображения показывают, насколько велика наша Вселенная в истинно космических масштабах.

В космическом масштабе человечество — всего лишь капля в огромном океане Вселенной.

Это изображение, сделанное с Международной космической станции астронавтом Карен Найберг в 2013 году, показывает два крупнейших острова в южной части Маскаренского плато: Реюньон на переднем плане и Маврикий, частично покрытый облаками. Чтобы увидеть человека на Земле с высоты МКС, потребовался бы телескоп размером с «Хаббл». Масштаб человека составляет менее 1/5 000 000 масштаба Земли, но Земля — всего лишь капля в космическом океане, ее диаметр составляет чуть более 10 000 километров. Источник: NASA/Karen Nyberg

Весь опыт нашей цивилизации, за исключением космических полетов, ограничен нашей планетой: 13 000 км в поперечнике.

Этот вид Земли предоставлен нам космическим аппаратом NASA MESSENGER, которому пришлось совершить облеты Земли и Венеры, чтобы сбросить достаточно энергии для достижения конечной цели: Меркурия. Несколько сотен изображений, сделанных широкоугольной камерой в системе визуализации Меркурия (MDIS) аппарата MESSENGER, были смонтированы в фильм, документирующий вид с MESSENGER при его удалении от Земли. Земля, сплюснутый сфероид, вращается примерно один раз каждые 24 часа вокруг своей оси и движется в пространстве по эллиптической орбите вокруг нашего Солнца. Источник: NASA/MESSENGER

Даже другие планеты обычно занимают объем, в тысячи раз превышающий объем Земли.

Из восьми планет нашей Солнечной системы четыре газовых гиганта обладают наименьшей плотностью, менее половины от плотности наименее плотной каменистой планеты (Марса), а Сатурн даже менее плотный, чем вода. Источник: NASA/Lunar and Planetary Institute

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

Коричневые карлики, с массами от примерно 0,013 до 0,080 массы Солнца, будут синтезировать протоны+дейтроны или дейтроны+дейтроны в гелий-3 или тритий, оставаясь примерно того же размера, что и Юпитер, но достигая гораздо больших масс. Красные карлики лишь немного крупнее, но они действительно запускают протон‑протонную реакцию синтеза, однако даже показанная здесь звезда, подобная Солнцу, изображена не в масштабе; она имела бы диаметр примерно в 7 раз больше, чем звезда малой массы. В нашей Вселенной звезды могут достигать почти 2000-кратного диаметра нашего Солнца. Источник: NASA/JPL‑Caltech/UCC

Диаметры крупнейших звезд‑сверхгигантов превышают миллиарды километров.

Эта иллюстрация показывает некоторые из крупнейших звезд Вселенной вместе с орбитами Сатурна (коричневый эллипс) и Нептуна (синий эллипс) для сравнения. Звезды, слева направо: крупнейший голубой гипергигант, желтый гипергигант, оранжевый гипергигант, а затем две самые большие звезды из всех: красные гипергиганты UY Щита и Stephenson 2–18. Крупнейшие звезды примерно в 2000 раз превышают диаметр нашего Солнца, но температуры на поверхностях этих звезд варьируются от всего нескольких тысяч К вплоть до звезд Вольфа‑Райе с температурами ~200 000 К. Источник: SkyFlubler/Wikimedia Commons

По масштабу они сравнимы с горизонтами событий самых тяжелых сверхмассивных черных дыр.

Эта диаграмма показывает относительные размеры горизонтов событий двух сверхмассивных черных дыр, обращающихся друг вокруг друга в системе OJ 287. Большая из них, с массой ~18 миллиардов масс Солнца, в 12 раз превышает размер орбиты Нептуна; меньшая, с массой 150 миллионов масс Солнца, примерно равна размеру орбиты астероида Церера вокруг Солнца. Самая тяжелая известная черная дыра лишь в несколько раз массивнее (а значит, и в несколько раз больше по радиусу), чем большая в OJ 287. Источник: NASA/JPL‑Caltech/R. Hurt (IPAC)

Но даже самые крупные отдельные объекты не идут ни в какое сравнение с протяженными, составными системами.

Логарифмическая диаграмма расстояний, показывающая планеты, космические аппараты «Вояджер», облако Оорта и нашу ближайшую звезду, Проксиму Центавра. Если мы представим строительство все более крупных ускорителей частиц, каждый десятикратный рост радиуса дает нам еще один десятикратный рост энергии, но обычно за счет стократного увеличения стоимости. В планетарных и звездных масштабах это может очень быстро стать запретительно большим. Источник: NASA/JPL‑Caltech

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

Иллюстрация формы внутреннего и внешнего облака Оорта, окружающего наше Солнце. В то время как внутреннее облако Оорта имеет тороидальную форму, внешнее облако Оорта сферическое. Истинная протяженность внешнего облака Оорта может быть менее 1 светового года или более 3 световых лет, здесь существует огромная неопределенность. Любой массивный объект, проходящий через облако Оорта, имеет большую вероятность возмутить объекты в его окрестностях. Источник: Pablo Carlos Budassi/Wikimedia Commons

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

В этом плотном звездном поле слева можно выделить несколько вероятных членов отдельной структуры — либо остатка шарового скопления, либо очень маломассивной карликовой галактики, путем сортировки звездных свойств объектов внутри нее. Источник: CFHT / S. Gwyn / S. Smith

Крошечные галактики содержат тысячи звезд и простираются на сотни световых лет.

Гигантское скопление галактик Abell 2029 содержит в своем ядре галактику IC 1101. При поперечнике от 5,5 до 6,0 миллионов световых лет, более 100 триллионах звезд и массе почти квадриллион солнц, это крупнейшая известная галактика по многим параметрам. Обзор самой яркой галактики во всех скоплениях Abell выявляет космическое движение, которое не согласуется с диполем реликтового излучения. Источник: Digitized Sky Survey 2; NASA

Крупнейшие галактики содержат более 100 триллионов звезд.

Композиция из галактик от самой маленькой до самой большой, показанных (приблизительно) в реальном размере. Гигантская эллиптическая галактика в сердце скопления Abell 2029, IC 1101, является крупнейшей известной галактикой во Вселенной, по крайней мере, по звездной протяженности. Она гораздо, гораздо больше Млечного Пути или Андромеды (или любой спиральной галактики), и возвышается даже над другими типичными гигантскими эллиптическими галактиками. Источник: E. Siegel

Джеты квазаров имеют еще большие размеры: Парфирион простирается на беспрецедентные 24 миллиона световых лет.

Эта анимация демонстрирует Парфирион, его протяженность и особенности, наблюдаемые в радиодиапазоне с помощью LOFAR и GMRT. Это крупнейшая система джетов черной дыры, обнаруженная на сегодняшний день. Источник: Susanne Landis & Konrad Rappaport (Science Communication Lab)

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

Впечатляюще огромное скопление галактик MACS J1149.5+223, свет от которого шел до нас более 5 миллиардов лет, является одной из крупнейших связанных структур во всей Вселенной. В более крупных масштабах близлежащие галактики, группы и скопления могут казаться связанными с ним, но из‑за темной энергии они удаляются от этого скопления; сверхскопления — это лишь кажущиеся структуры, но крупнейшие связанные скопления галактик все еще могут достигать сотен миллионов и, возможно, даже миллиарда световых лет в поперечнике. Источник: NASA, ESA, and S. Rodney (JHU) and the FrontierSN team; T. Treu (UCLA), P. Kelly (UC Berkeley), and the GLASS team; J. Lotz (STScI) and the Frontier Fields team; M. Postman (STScI) and the CLASH team; and Z. Levay (STScI)

Крупнейшие сверхскопления, войды и филаменты (хотя и не будучи связанными гравитационно) простираются на 1,4 миллиарда световых лет.

Великая стена Слоуна — одна из крупнейших кажущихся, хотя, вероятно, временных структур во Вселенной, ее поперечник составляет около 1,37 миллиарда световых лет. Возможно, это просто случайное выравнивание нескольких сверхскоплений, но наблюдения определенно указывают на то, что это не единая гравитационно связанная структура, поскольку темная энергия разрывает ее. Галактики Великой стены Слоуна изображены справа. Источник: Willem Schaap (L); Pablo Carlos Budassi ®/Wikimedia Commons

В целом, наша наблюдаемая Вселенная имеет размер 92 миллиарда световых лет.

Размер нашей видимой Вселенной (желтый), а также область, которую мы можем достичь (пурпурный), если бы мы отправились сегодня в путешествие со скоростью света. Предел видимой Вселенной составляет 46,1 миллиарда световых лет, так как это предел того, насколько далеко находился бы объект, испустивший свет, который только сейчас доходит до нас, после расширения Вселенной в течение 13,8 миллиардов лет. Все, что происходит прямо сейчас в пределах радиуса 18 миллиардов световых лет от нас, в конечном итоге достигнет и повлияет на нас; все, что за этой точкой, — нет. Каждый год еще около 20 миллионов звезд пересекают этот порог достижимости. Источник: Andrew Z. Colvin and Frederic Michel, Wikimedia Commons; Annotations: E. Siegel

Но ненаблюдаемая Вселенная должна быть, по крайней мере, в сотни раз больше.

Эта симуляция показывает крупномасштабную структуру Вселенной в масштабах фактического космического горизонта: примерно 93 миллиарда световых лет в поперечнике. На этом уровне даже крупнейшие космические структуры сводятся к простым точкам, демонстрируя, насколько однородна, гладка и равномерна Вселенная в самых крупных космических масштабах. Источник: The Millennium Simulation, V. Springel et al.; Modifications: E. Siegel

Насколько нам известно, Вселенная может быть даже бесконечной.

Мы можем представить себе очень большое число возможных исходов, которые могли бы возникнуть из условий, с которыми родилась наша Вселенная. Тот факт, что все 10⁹⁰ частиц, содержащихся в нашей Вселенной, с взаимодействиями, которые они испытали, и результатами, к которым они пришли за последние 13,8 миллиардов лет, привел ко всем тонкостям нашего опыта, включая само наше существование. Возможно, если бы было достаточно шансов, это могло бы произойти много раз, приводя к сценарию, который мы называем «бесконечными параллельными Вселенными», содержащими все возможные исходы, включая пути, по которым наша Вселенная не пошла. Источник: MUSTAFABULENT / Adobe Stock

Mostly Mute Monday рассказывает астрономическую историю в изображениях, визуальных материалах и не более чем 200 словах.

Эта статья была опубликована в мае 2022 года. Обновлена в сентябре 2026 года.

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

Что вы думаете об истинных размерах Вселенной?

0%Наша Вселенная конечна и единственна (Мультивселенной не существует)0

Наша Вселенная конечна, но не единственна (Мультивселенная существует)1

50%Наша Вселенная бесконечна, но единственна (Мультивселенной не существует)4

25%Наша Вселенная бесконечна, но не единственна (Мультивселенная существует)2

Свой вариант в комментариях1

Проголосовали 8 пользователей. Воздержавшихся нет.

Хабр Курсы для всех