Все публикации подряд на Хабре

Шестидесятые: десятилетие, когда мы придумали будущее

Tue, 15 Sep 2026 05:23:54 +0000

В двадцатом веке, который закончился будто совсем недавно, было много крутых и странных десятилетий. Но мое любимое, конечно, шестидесятые — декада, когда люди придумали, кажется, абсолютно все, от интернета и покорения космоса до стереозвука и нейросетей. Да, изначально все это были по большей части proofs of concept — но какие идеи, какие смелые эксперименты и какие немыслимые результаты! Кажется, люди склонны ретроспективно недооценивать 1960-е, думая, что это просто время хиппи, странной музыки и огромных ящиков с мигающими огоньками. Постараюсь набросать дорожную карту и объяснить, что именно меня так восхищает вот конкретно в этом десятилетии, куда (или, точнее, когда) я бы с удовольствием переселился отсюда.

Эта статья — первая в цикле про десятилетия, которые сформировали наш мир. Лайкайте, если понравилось и хотите следующие.

Футуристические дизайны домов 60-х на обложке, здесь и далее — Чарльз Шридде для компании Motorola

Панорама

Шестидесятые были настолько богаты явлениями и откровениями, что их сложно свести к нескольким знаменитым событиям — столько всего: космическая гонка, высадка человека на Луну, The Beatles, холодная война, студенческие революции и контркультура!.. А еще — несколько ключевых технологических трендов; в общем, все и не перечислишь. Но я попытаюсь.

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

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

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

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

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

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

Первая нейронка

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

Речь, конечно, про перцептрон (ранее я кратко упоминал о нем в статье про суперкомпьютеры Mark).

Фрэнк Розенблатт с компьютером Mark I Perceptron в 1960 году

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

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

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

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

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

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

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

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

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

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

Ее сопровождала другая, не менее радикальная идея: что, если сосредоточиться не на том, чтобы делать отдельную машину умнее, а на том, чтобы соединить множество машин так, чтобы они образовали качественно новую среду?

ARPANET, 60-е

Как мир попал в паутину

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

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

Обмениваться файлами? Передавать результаты вычислений? Использовать ресурсы друг друга? Работать как единая система?

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

Эта перспектива оправдалась, сегодня она называется интернет.

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

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

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

Любопытно, что идея пакетной коммутации не возникла как единое изобретение одного человека в одном месте. В США Пол Бэран исследовал устойчивые распределенные коммуникационные системы, в Великобритании Дональд Дэвис разрабатывал собственные концепции передачи информации небольшими блоками и, собственно, ввел широко известный термин packet.

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

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

Самый первый запуск ARPANET в 1969 году обернулся комичной историей: при попытке передать команду с компьютера в Калифорнийском университете в Лос-Анджелесе на удаленную машину в Стэнфордском исследовательском институте система успела передать только две буквы из слова LOGIN — LO. После этого соединение прервалось.

В английском языке «Lo» с восклицательным знаком («Lo!») это старое выражение, означающее «внемлите!» или «узрите!».

И мир внял и узрел.

Когда связь выходит за пределы Земли

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

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

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

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

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

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

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

К концу 60-х эта инфраструктура уже начала менять не только техническую сторону коммуникаций, но и само представление о публичном событии. Одним из наиболее ярких моментов стал международный телепроект Our World 25 июня 1967 году — первая крупная глобальная телетрансляция с участием The Beatles, объединившая аудиторию сразу нескольких стран.

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

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

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

(Ричард Линклейтер в фильме Apollo 10 1/2 (2022) про свое детство близ космопорта в Хьюстоне вспоминает, как это было невероятно: одновременно видеть в кино фильм Кубрика про покорение космоса и видеть по телевизору, как люди реально покоряют Луну. Все буквально казалось возможным, реальность стала пластичной, пусть и лишь на какой-то миг)

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

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

Когда в мае 1961 года Джон Кеннеди объявил, что Соединенные Штаты намерены до конца десятилетия высадить человека на Луну и вернуть его обратно, это выглядело настоящим челленджем. Первый американский астронавт совершил суборбитальный полет всего несколькими неделями ранее. До Луны оставалось почти 400 тысяч километров, а компьютеры, которым предстояло участвовать в управлении будущим космическим кораблем, по современным меркам были невероятно ограниченными.

И все же, к концу десятилетия задача была выполнена, и кадры с Нилом Армстронгом, шагающим по Луне, стали одним из самых известных образов XX века (и объектом бесчисленных теорий заговора, настолько сегодня невозможно поверить, что это произошло с тем уровнем технологий, что был в 1960-е).

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

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

Особенно интересна история Apollo Guidance Computer — бортового компьютера, разработанного для управления полетом. С точки зрения современного пользователя, его характеристики выглядят сегодня совершенно неправдоподобно — тактовая частота: около 0,043 МГц, производительность: около 12 250 операций с плавающей запятой в секунду, оперативная память (RAM): 4 КБ.

Гугл сообщает, что iPhone 18 мощнее Apollo Guidance Computer в 100 миллионов раз (в СТО МИЛЛИОНОВ РАЗ, Карл). А как там дела с лунной базой? Выбранный человечеством путь развития виден очень наглядно

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

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

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

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

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

От луча, который «ничего не мог», к звуку, который можно собрать

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

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

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

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

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

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

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

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

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

Эта логика особенно хорошо видна на примере музыкальной революции второй половины шестидесятых (пожалуй, пионером новой оркестровки стал Брайан Уилсон из Beach Boys, у которого довольно быстро технические новинки подрезали Pink Floyd и The Beatles).

К 1967-69 годам уже буквально каждая пластинка стремилась переплюнуть конкурентов по части эксперимента (в чем, вероятно, сыграли свою роль также запрещенные вещества, но мы это осуждаем и обсуждать не будем)

В массы новый звук пошел во многом благодаря тому, что эпицентром авангарда оказалось британское государственное телевидение, BBC. Его звукорежиссерское подразделение, основанная в 1958 году лаборатория BBC Radiophonic Workshop, изначально занималось созданием необычных звуков для радио и телевидения, причем его сотрудники изначально работали не столько с готовыми музыкальными инструментами, сколько с самой природой звука.

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

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

Одним из самых известных примеров стала работа Делии Дербишир над темой Doctor Who: исходный материал был собран из отдельных электронных сигналов и звуков, записанных на пленку, после чего подвергался монтажу и обработке.

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

(проигрыш в начале трека «Strange Days» (1967) группы The Doors стал, кажется, первым применением синтезатора Moog в суперпопулярной музыке)

Придумали все полимеры

«Всего одно слово — ПЛАСТИК. За этим будущее» (реклама, 1960)

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

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

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

Ноу-хау десятилетия — пластиковая пленка для сэндвичей! Реклама, декабрь 1960

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

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

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

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

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

Первые такие соединения появились уже после шестидесятых: флуоксетин был синтезирован и исследован в начале 1970-х, а первым СИОЗС, вышедшим на рынок, стал зимелидин, разработанный в 1971 году и выпущенный в Швеции в 1982-м. Флуоксетин, который позднее стал известен как Prozac, получил одобрение FDA в 1987 году.

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

Жить внутри новых структур

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

Фуллера интересовал гораздо более широкий вопрос: можно ли рассматривать всю человеческую среду как систему, которую можно перепроектировать?

(Ремарка в сторону: можно, наверное, назвать итогом шестидесятнических экспериментов в области функционального дизайна то, что было показано на легендарной выставке OSAKA EXPO 70)

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

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

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

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

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

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

Геодезический купол Бакминстера Фуллера, спроектированный для выставки «Экспо-67» в Монреале, сегодня служит «Биосферой» — культурно-просветительским центром, посвященным вопросам окружающей среды.

Фуллер, которому в 60-х было уже немало лет (он родился в 1895 году), оказался удивительно созвучен с эпохой. Он хотел показать, что привычная организация человеческой среды не является естественной и неизбежной. Дом может быть спроектирован иначе. Город может быть устроен иначе. Ресурсы можно распределять иначе.

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

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

Для ответа на эти вопросы понадобились такие революционные мыслители 60-х, как Маршалл Маклюэн (которому я посвятил отдельную объемную статью) и Мишель Фуко.

Структуры внутри новой жизни

Коллективный научный сборник «Лингвистический поворот» (1967)

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

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

На первый взгляд (особенно хабровский), структурализм кажется чисто гуманитарной историей, которая плохо сочетается с рассказом о ракетах, компьютерах и интегральных схемах. Но в контексте шестидесятых он выглядит совершенно иначе. Структурное мышление возникало в мире, который сам все больше становился миром систем. Инженеры учились работать со сложным комплексом взаимосвязанных элементов. Биологи обнаруживали механизмы кодирования и передачи наследственной информации. Лингвисты исследовали язык как систему отношений. Кибернетика предлагала модели обратной связи и управления.

Структурализм был гуманитарным выражением той же интеллектуальной эпохи.

Из лингвистики этот принцип быстро распространился на антропологию, философию, литературоведение и психоанализ. Структурализм стал особенно заметен во Франции в середине шестидесятых: его методы использовали Клод Леви-Стросс, Ролан Барт, Жак Лакан, Луи Альтюссер, а затем в этот широкий интеллектуальный контекст стали включать и Мишеля Фуко.

В 1966 году международный симпозиум в Балтиморе собрал вокруг проблемы структурализма целый ряд французских интеллектуалов, а к концу десятилетия он уже превратился из специального метода в одну из главных интеллектуальных мод того времени. Особенно показателен здесь Клод Леви-Стросс (доживший аж до 2009 года и почтенного возраста в 100 лет). Его антропологические исследования предлагали смотреть на мифы и культуры как на сложные системы, внутри которых действуют определенные правила организации.

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

Леви-Стросс начал формировать свою структурную антропологию задолго до шестидесятых: его «Элементарные структуры родства» вышли еще в 1949 году, а «Структурная антропология» — в 1958-м. Но именно шестидесятые сделали его фигурой европейского масштаба. В 1962 году появились сразу «Тотемизм» и «Первобытное мышление», а с 1964 года началась публикация четырехтомных «Мифологик», в которых Леви-Стросс пытался обнаружить за многообразием мифов и обычаев скрытую систему отношений.

Молодой Леви-Стросс в полевой экспедиции в Бразилии (1930-е)

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

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

Как мы знаем, что мы что-то знаем?

Жан-Поль Сартр (слева), Жиль Делёз (на заднем плане) и Мишель Фуко, Париж, 1968

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

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

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

И здесь как раз и появляется Мишель Фуко, у которого в 1960-е вышли две важнейшие работы: революционная «Слова и вещи. Археология гуманитарных наук» (1966) и совсем уже трудноосмыслимая «Археология знания» (1969).

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

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

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

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

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

Как, например, в шестидесятые, когда эти книги были написаны.

Вместо послесловия

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

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

Они сначала должны стать мыслимыми.

Именно это имелось в виду под одним из самых известных лозунгов революционного мая 68 года в Париже — «Вся власть воображению!» (L'imagination au pouvoir).

[Перевод] Сжимаем флаги стран в 11 бит

PatientZero — Tue, 15 Sep 2026 05:09:53 +0000

Недавно я посмотрел интересное видео YouTube‑канала «Physics for the Birds». Это видео посвящено матрицам, но для объяснения некоторых операций с матрицами автор использовал флаги:

Скриншот из видео

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

Однако это видео дало мне вдохновение: часто флаги бывают очень простыми — несколько разноцветных полос, распространённые элементы наподобие звезды, полумесяца или креста. Если использовать какую‑нибудь схему кодирования, то удастся ли описать флаг Франции

в формате «три полосы: синяя, белая, красная», чтобы декодеру и рендереру достаточно было всего нескольких бит? Как может выглядеть такое кодирование?

Я решил создать нечто подобное.

Требования

Для начала я сформулировал критерии соответствия моей кодировки:

Декодированный флаг должен быть «достаточно узнаваемым»
- Детали не обязаны быть точными. Вполне допустимы небольшие отклонения и неточности; достаточно, чтобы человек посмотрел на результат и сказал: «О, да это же тот флаг!»
- В том числе это относится к и точному расположению и форме объектов.
- Это относится и к точности цвета. Я знаю, как сильно гордится Франция своим новым оттенком синего, но при кодировании мы можем свести любой оттенок синего к какому‑нибудь среднему синему

Только флаги стран
- Никаких флагов штатов, городов и других вексиллологических дизайнов

Без Непала
- Прости, Непал, мне нравится твой непрямоугольный флаг, но он бы всё усложнил

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

Без гербов
- На флагах наподобие флага Андорры содержатся их гербы, для рендеринга которых потребовались бы растровые/векторные изображения. Из‑за этого пришлось бы встроить в наш крошечный формат SVG или что‑то подобное, так что нет

Что делает флаг флагом?

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

Во‑первых, выяснилось, что флаги разнообразнее, чем я думал. Да, есть простые полосатые флаги, например, у Франции, Италии или Германии. Также есть дизайны наподобие флагов Бурунди или Боснии со звёздами, отдельными частями и тому подобным. На флагах Северной Македонии и Сейшельских Островов есть радиальные полосы. У Чехии, Багамских Островов и других стран на флагах есть треугольники слева. И таких различий ещё много.

Так что же общего у большинства флагов? Насколько я понял:

Полосы
1. Полосы, много полос: горизонтальные, вертикальные, две полосы, три полосы, тринадцать полос, полосы разной ширины, полосы под углом
Стандартные фигуры
1. Звёзды, полумесяцы, круги
2. Разных размеров и в разных местах, одна фигура или несколько
Треугольник слева
1. На удивление распространён и представлен в разных цветах, но часто имеет одинаковую общую форму, см. Коморы, Багамские Острова и Чехия
Цветной левый верхний угол
1. Какой‑нибудь прямоугольник в левой верхней части: США, Греция
Флаг Великобритании
1. Великобритания, Австралия, Новая Зеландия, Тувалу
И ещё есть страны Северной Европы
1. Их добавление явно станет большим плюсом: Норвегия, Швеция, Дания, Финляндия

Анализируем флаг

Я решил, что протокол должен определять следующие параметры:

Соотношение сторон
1. У всех флагов соотношение сторон индивидуально, но присутствуют явные паттерны: примерно 45% флагов имеет соотношение 2:3, примерно 28% — 1:2, примерно 9% — 3:5, а дальше идёт длинный хвост иных форматов
Цветовая палитра
1. Как уже говорилось, вместо копирования точного кода цвета мы ограничимся общими тонами, то есть цветовыми группами наподобие синего, зелёного и жёлтого
2. Тут тоже наблюдается похожая картина: неожиданно много красного, потом по убыванию идут белый, синий, жёлтый/золотой, зелёный, чёрный и оранжевый с длинным хвостом других цветов
Слои
1. Я думаю, логично задавать содержимое при помощи нескольких «слоёв» вместо того, чтобы пытаться закодировать все распространённые элементы по отдельности. Каждый слой сможет определять собственный список поддерживаемых опций
2. Это должно работать как в Photoshop и других приложениях: например, во флаге США у нас сначала будет слой с полосами, затем слой для синего прямоугольника и на нём слой звёзд
3. Самым общим слоем будет слой «Полосы». Он может иметь опции количества полос и их цветов, направления, чётного или нечётного распределения и повторяющихся паттернов
4. Слой «Фигуры» должен содержать звёзды, полумесяцы и тому подобное, определяя позицию и поворот. Слои «Интервал» и «Область» позволят закрашивать конкретный прямоугольник

Превращаем данные в биты

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

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

Вот пример полного дерева Хаффмана для соотношения сторон флага:

graph TD
    %% Внутренние узлы
    root((Root))
    n1(( ))
    n11(( ))
    n110(( ))
    n1101(( ))
    n11011(( ))
    n111(( ))
    n1110(( ))
    n11100(( ))
    n111001(( ))
    n11101(( ))
    n111010(( ))
    n111011(( ))
    n1111(( ))
    n11110(( ))
    n111100(( ))
    n111101(( ))
    n11111(( ))
    n111110(( ))
    n1111100(( ))
    n1111101(( ))
    n111111(( ))
    n1111110(( ))
    n1111111(( ))
    n11111111(( ))

    %% Узлы листьев (соотношения)
    L_2_3[2:3]
    L_1_2[1:2]
    L_3_5[3:5]
    L_5_8[5:8]
    L_10_19[10:19]
    L_3_4[3:4]
    L_4_7[4:7]
    L_1_1[1:1]
    L_7_10[7:10]
    L_8_11[8:11]
    L_11_18[11:18]
    L_11_20[11:20]
    L_11_28[11:28]
    L_18_25[18:25]
    L_1_phi[1:φ]
    L_4_5[4:5]
    L_6_7[6:7]
    L_10_17[10:17]
    L_13_15[13:15]
    L_15_22[15:22]
    L_16_25[16:25]
    L_189_335[189:335]
    L_28_37[28:37]
    L_5_7[5:7]
    L_7_11[7:11]
    L_CUSTOM[CUSTOM]

    %% Левая ветвь (0...)
    root -- 0 --> L_2_3
    root -- 1 --> n1
    
    n1 -- 0 --> L_1_2
    n1 -- 1 --> n11
    
    %% Ветвь 110... 
    n11 -- 0 --> n110
    n110 -- 0 --> L_3_5
    n110 -- 1 --> n1101
    n1101 -- 0 --> L_5_8
    n1101 -- 1 --> n11011
    n11011 -- 0 --> L_10_19
    n11011 -- 1 --> L_3_4

    %% Ветвь 111...
    n11 -- 1 --> n111
    n111 -- 0 --> n1110
    
    %% Подветви 1110...
    n1110 -- 0 --> n11100
    n11100 -- 0 --> L_4_7
    n11100 -- 1 --> n111001
    n111001 -- 0 --> L_1_1
    n111001 -- 1 --> L_7_10
    
    n1110 -- 1 --> n11101
    n11101 -- 0 --> n111010
    n111010 -- 0 --> L_8_11
    n111010 -- 1 --> L_11_18
    n111011 -- 0 --> L_11_20
    n111011 -- 1 --> L_11_28
    n11101 -- 1 --> n111011

    %% Ветвь 1111...
    n111 -- 1 --> n1111
    n1111 -- 0 --> n11110
    
    %% Подветви 11110...
    n11110 -- 0 --> n111100
    n111100 -- 0 --> L_18_25
    n111100 -- 1 --> L_1_phi
    n1111001(( ))
    n11110 -- 1 --> n111101
    n111101 -- 0 --> L_4_5
    n111101 -- 1 --> L_6_7

    %% Ветвь 11111...
    n1111 -- 1 --> n11111
    n11111 -- 0 --> n111110
    
    %% Подветви 111110...
    n111110 -- 0 --> n1111100
    n1111100 -- 0 --> L_10_17
    n1111100 -- 1 --> L_13_15
    n111110 -- 1 --> n1111101
    n1111101 -- 0 --> L_15_22
    n1111101 -- 1 --> L_16_25

    %% Самая глубокая ветвь 111111...
    n11111 -- 1 --> n111111
    n111111 -- 0 --> n1111110
    n1111110 -- 0 --> L_189_335
    n1111110 -- 1 --> L_28_37
    
    n111111 -- 1 --> n1111111
    n1111111 -- 0 --> L_5_7
    n1111111 -- 1 --> n11111111
    n11111111 -- 0 --> L_7_11
    n11111111 -- 1 --> L_CUSTOM

    %% Стилизация для удобства чтения
    classDef leaf fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
    classDef internal fill:#eceff1,stroke:#607d8b,stroke-width:1px;
    
    class L_2_3,L_1_2,L_3_5,L_5_8,L_10_19,L_3_4,L_4_7,L_1_1,L_7_10,L_8_11,L_11_18,L_11_20,L_11_28,L_18_25,L_1_phi,L_4_5,L_6_7,L_10_17,L_13_15,L_15_22,L_16_25,L_189_335,L_28_37,L_5_7,L_7_11,L_CUSTOM leaf;
    class root,n1,n11,n110,n1101,n11011,n111,n1110,n11100,n111001,n11101,n111010,n111011,n1111,n11110,n111100,n111101,n11111,n111110,n1111100,n1111101,n111111,n1111110,n1111111,n11111111 internal;

То есть для 45% флагов с соотношением сторон 2:3 достаточно присвоить первому биту значение 0.

Формат содержит деревья Хаффмана для:

Соотношения сторон (самые распространённые: 2:3, 1:2, 3:5)
- Особое соотношение ширина : высота для длинного хвоста

Размер цветовой палитры (самые распространённые: 3, 2, 4, 5)
- Особое значение «Count — 7» для длинного хвоста, потому что дерево уходит вверх на 7 уровней

Цвет (самые распространённые: красный, белый, синий)
- Особые цвета можно задавать в виде компактной 10-битной RGB‑аппроксимации (RRR GGGG BBB)

Количество слоёв

Тип слоя (полосы, фигура, области, пересечение, интервал, внутренний)

Ещё несколько специализированных поддеревьев
- например, количество точек на звезде, расположение фигуры

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

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

Соотношение сторон 2:3 (1 бит) → 0
- самое распространённое соотношение сторон

Палитра из двух цветов (2 бита) → 10
- Это единственный параметр, в котором мы немного теряем, потому что самое распространённое в дереве количество цветов — три

Определяем 2 цвета: красный (2 бита) → 00 и белый (2 бита) → 01
- Два самых распространённых цвета в дереве

1 слой (1 бит) → 0
- вершина дерева

Слой полос (1 бит) → 0, режим «равенство палитры» (то есть каждому цвету в палитре даётся одна одинаковая полоса, 1 бит) → 0 и горизонтальные полосы (1 бит) → 0
- Всё это находится на вершинах соответствующих деревьев Хаффмана

→ Соединяем всё вместе: 0 10 00 01 0 0 0 0, или QgA= в кодировке base64

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

Самый длинный — это флаг Катара, 420 бит: #gHR1Y$?-+]m.0xS3F!0{.UH{uDppW5u2^+s|6~(p@GwHH<N:?57K99\(s)~!G4`!. Я бы сказал, что этот флаг едва умещается в нашу кодировку: сбоку у него есть зигзагообразный край, который я закодировал в виде 11 отдельных слоёв прямоугольников.

Флаг Великобритании

Можно сказать, что с ним я сжульничал. «Юнион Джек» сильно распространён, но его так сложно собирать из слоёв, что я просто сделал его встроенной в протокол фигурой. То есть он не собирается из частей, а для флага мы указываем «Слой „Юнион Джек“ в левом верхнем углу».

Кодируем флаги

Поначалу я использовал base64, чтобы просто превращать биты в сохраняемый текст. При 6 битах полезной нагрузки на один байт ASCII на усреднённое определение флага требуется 14 с медианой 12 символов. Самый короткий код флага — это QgA= (Индонезия).

Однако для повышения эффективности кодирования я решил воспользоваться кодировкой Base94, которая задействует все видимые однобайтовые символы ASCII с «!» по «~».

Думал я и о кодировании на основе эмодзи, но поскольку для сохранения каждого символа всё равно понадобится больше 1 байта, уменьшившееся количество символов, вероятно, всё равно потребует суммарно больше бит. (А ещё я не хотел рисковать тем, что флаг страны окажется закодированным в «💩🤮👎» или нечто подобное…)

В результате мы уменьшили усреднённое значение до 12 символов на флаг с медианой 9 символов. Индонезия осталась самым коротким кодом: <F.

Рендеринг

При помощи ChatGPT Codex я превратил этот формат в двухэтапную систему: кодировщик/декодер и SVG‑рендерер.

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

{
  "aspectRatio": {
    "kind": "rational",
    "height": "2",
    "width": "3"
  },
  "palette": [
    {
      "r": 210,
      "g": 16,
      "b": 52
    },
    {
      "r": 255,
      "g": 255,
      "b": 255
    }
  ],
  "layers": [
    {
      "kind": "stripes",
      "direction": "horizontal",
      "stripes": [
        {
          "color": 0
        },
        {
          "color": 1
        }
      ]
    }
  ]
}

Затем рендерер превращает этот декодированный флаг в код SVG:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1.5 1">
	<rect x="0" y="0" width="1.5" height="0.5" fill="#d21034"/>
	<rect x="0" y="0.5" width="1.5" height="0.5" fill="#fff"/>
</svg>

Код довольно красив, в нём есть отдельный класс и интерфейсы для закодированных двоичных частей и слоёв. Однако даже при tsc‑компиляции кодировщик/декодер занимает 27 КБ, а рендерер — 12,5 КБ; наверно, это перебор, учитывая такую сильную оптимизацию исходного формата…

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

Благодаря этому мы получили 470-строчный файл TypeScript, после компиляции превратившийся в 5,29 КБ (2,66 КБ после сжатия gzip).

Флаги, не поместившиеся в формат

С разной степенью успешности мне удалось закодировать в этот довольно примитивный формат 128 флагов.

Но осталось 67 флагов, которые мне закодировать не удалось. Наиболее примечательные из них:

Испании, Экваториальной Гвинеи, Андорры, Белиза, Брунея, Камбоджи, Коста‑Рики, Хорватии, Доминиканской Республики, Эквадора, Сальвадора, Фиджи, Гаити, Мексики, Молодовы, Черногории, Никарагуа, Омана, Парагвая, Португалии, Сан‑Марино, Сербии, Словакии, Словении, Венесуэлы
- Содержащие герб, символ или национальную эмблему (25)

Анголы, Барбадоса, Эсватини, Гватемалы, Кении, Лесото, Лихтенштейна, Мальты, Мозамбика, Таджикистана, Ватикана
- С глифами‑объектами: оружием, инструментами, коронами, щитами или головным убором (11)

Албании, Бутана, Доминики, Египта, Кирибати, Папуа — Новой Гвинеи, Шри‑Ланки, Уганды, Замбии, Зимбабве
- С глифами‑животными, в основном орлами и другими птицами (10)

Канады, Кипра, Эритреи, Гренады, Ливана
- С растительными глифами: листьями, ветвями или мускатным орехом (5)

Антигуа и Барбуды, Бразилии, Непала, ЮАР, Вануату
- С геометрией, которую не может выразить модель слоёв, например, Y‑образной, V‑образной, завитком или непрямоугольным контуром (5)

Афганистана, Ирана, Ирака, Саудовской Аравии
- С текстом или каллиграфией на арабском (4)
- Здесь бы могло помочь добавление специального слоя текста

Индии, Кыргызстана, Монголии, Республики Корея
- С религиозными или культурными символами: колесом Ашоки, юрты‑тюндюка, соёмбо или тхэгыкки (4)

Беларуси, Казахстана, Туркменистана
- С орнаментальными узорами по краю

→ То есть практически все, содержащие особый глиф или текст, которые нелегко представить в виде геометрических слоёв

Случайные флаги!

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

Да, у какой‑нибудь страны вполне мог бы быть подобный флаг!

Подведём итог

Я уверен, что кто‑то ещё сможет найти более экономные или совершенно иные способы сжатия или структурирования данных. Однако мне всё равно было очень интересно взять полный список флагов, искать в них общие элементы и находить способы упаковки в биты максимального объёма данных. Здорово было и наконец‑то воспользоваться своими знаниями кода Хаффмана, полученными в рамках бакалавриата, а также писать код на битовом уровне.

Готовую страницу со всеми флагами можно найти здесь: https://vantezzen.github.io/miniflags/, а исходный код — здесь: https://github.com/vantezzen/miniflags. Не ожидайте увидеть там особо чистый код — в конце концов, по большей мере я его вайбкодил, исходя из своих мыслей о формате.

Сайт не открывается из России, хотя сервер в Москве

Vadtop — Tue, 15 Sep 2026 05:01:40 +0000

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

Сервер при этом в Москве, у российского хостера. И с ним всё в порядке.

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

Симптомы

Сайт статический, Next.js, отдаётся через nginx. Рядом два Docker‑контейнера: чат‑виджет и API для демок. Сервер 2 CPU, 4 ГБ, Москва.

Что я видел:

через VPN сайт открывался, но через раз;
без VPN не открывался вообще;
с телефона по мобильному тоже нет;
ping до сервера при этом шёл идеально.

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

Первое, что я сделал не так

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

Первая версия была про VPN. Внешний адрес показывал Франкфурт, трафик до Москвы шёл через Германию, задержка 100 мс. Вроде логично: туннель теряет пакеты, отсюда и «через раз».

$ curl -s https://ipinfo.io/json
{
  "ip": "203.0.113.10",
  "city": "Frankfurt am Main",
  "country": "DE",
  "org": "AS47447 23M GmbH"
}

Версия красивая. И неверная. Без VPN сайт не открывался вообще, а этого она не объясняла.

Вывод, до которого я дошёл поздно: если у гипотезы остаётся симптом, который она не объясняет, гипотеза неверна. Не «почти», не «частично». Неверна.

Как надо было: мерить серией

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

ok=0; fail=0
for i in $(seq 1 25); do
  c=$(curl -s -o /dev/null -m 10 -w "%{http_code}" https://titov-ai.ru/)
  [ "$c" = "200" ] && ok=$((ok+1)) || fail=$((fail+1))
done
echo "ok=$ok fail=$fail"

Через VPN получилось ok=18 fail=7. Двадцать восемь процентов запросов не проходит.

Дальше нужна контрольная группа. Без неё замер не значит ничего. Проверяем другие хосты через тот же канал:

google.com    → 15 из 15
timeweb.com   → 12 из 12   (сайт моего же хостера)
мой сервер    → 18 из 25

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

Странность, которая всё запутала

Разложил проверку по уровням и получил картину, которая противоречит сама себе:

ping (30 пакетов)        → 0% потерь
чистый TCP-коннект :443  → 20 из 20
чистый TCP-коннект :22   → 20 из 20
SSH-сессия               → работает
curl HTTPS               → 6 провалов из 20
curl HTTP :80            → 5 провалов из 15

TCP устанавливается всегда. SSH работает. А обычный HTTP‑запрос падает в трети случаев.

Отказ выглядел так:

curl: (28) Connection timed out after 10000 milliseconds
time_connect = 0.000000

Ноль в time_connect значит, что соединение не установилось вообще. SYN ушёл, ответа нет. Не разрыв на середине передачи. Молчание.

Шесть версий, которые не подтвердились

Все проверил и выбросил. Пишу целиком, потому что отрицательный результат тоже результат.

Авария на ноде хостера. В панели реально висело уведомление об аппаратном сбое. Отпала, когда я зашёл на сервер: load average 0.00, память свободна, nginx с нулём перезапусков, контейнеры Up 10 часов. Сбоило бы железо, страдал бы и SSH. Не страдал.

Nginx или Docker не принимают соединения. Разумно, если бы падал только веб. Но чистый TCP‑коннект на 443 давал 20 из 20. При переполнении accept‑очереди он бы тоже падал.

MTU и фрагментация. Path MTU до сервера оказался 1300 вместо 1500, типичная подпись туннеля. Отпала на контрольном замере: до старого хостинга MTU был точно такой же, и там всё работало.

Сертификат. Отпала сразу. Нулевой time_connect значит, что до TLS дело не доходит, а сертификат читается уже после установки соединения.

Отсутствие AAAA‑записи. У моей машины IPv6 вообще нет, curl -6 не находит адреса. Все замеры шли по IPv4, форсированный curl -4 давал те же потери.

IP в чёрных списках. Шесть DNSBL, включая Spamhaus и SpamCop. Все чистые.

Что дало ответ

Вот это надо было делать первым. Заходим на сервер и снимаем дамп трафика, пока снаружи бьём запросами:

# на сервере
systemd-run --unit=cap --collect \
  tcpdump -i any -nn -c 3000 -w /tmp/cap.pcap tcp port 443

systemd-run тут не для красоты. SSH‑сессия рвалась каждые пару минут, а так процесс переживает обрыв.

Снаружи запускаю двадцать пять запросов, три падают. Смотрим, что видел сервер в момент падения:

09:01:32.377365  In   IP 203.0.113.10 > сервер.443: Flags [S]
09:01:32.377468  Out  IP сервер.443 > 203.0.113.10: Flags [S.]
09:01:32.476632  In   IP 203.0.113.10 > сервер.443: Flags [.] ack

SYN пришёл. Сервер ответил SYN‑ACK через одну десятитысячную секунды. Рукопожатие завершилось. А curl на моей стороне в этот момент показывал таймаут.

Всего пришло 25 SYN на 25 запросов. Ни один не потерялся по пути туда. Сервер ответил на все. Терялся ответ, обратно.

Развязка

Оставалось проверить очевидное, до чего я дошёл последним: как ведёт себя сервер с реального канала, мимо VPN. В Windows это делается флагом --interface:

# 192.168.1.50 это реальный интерфейс, не туннель
curl --interface 192.168.1.50 https://titov-ai.ru/

Результат:

ping до сервера       → 6 из 6, 16 мс, 0% потерь
TCP на 443            → 0 из 10
TCP на 443 по IP      → 0 из 8
google.com            → 3 из 3
timeweb.com           → 3 из 3

ICMP проходит идеально. TCP на 80 и 443 не проходит ни разу. Другие сайты с того же интерфейса работают.

Это фильтрация. Не потери, не перегрузка. Избирательная блокировка TCP к конкретному адресу при живом ICMP.

Хостер подтвердил, когда я прислал замеры. Их проверка снаружи: порт открывается, nc -zv отвечает succeeded, но соединение рвётся на TLS‑хэндшейке. Curl виснет сразу после Client hello, браузер даёт ERR_CONNECTION_RESET. Изнутри их сети сайт при этом отдаёт HTTP/2 200.

Ответ поддержки: «изменения в настройках фильтрации со стороны магистральных провайдеров, повлиять на это мы не можем».

Почему именно мой адрес

Вот тут самое интересное. Ради этого стоило копать.

Смотрим, кому принадлежит блок:

$ curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=201.x.x.x" \
  | jq '.data.block.desc, .data.asns'

"LACNIC (Status: ALLOCATED)"
[{"asn": 9123, "holder": "TimeWeb-AS JSC \"TIMEWEB\""}]

LACNIC это регистратор Латинской Америки. Адрес российского хостера, физически стоящий в Москве, формально принадлежит латиноамериканскому диапазону 201.0.0.0/8.

Хостеры выкупают такие блоки легально. Свободных адресов в RIPE давно нет, а IPv4 нужны. Юридически всё чисто: в базе RIPE запись TW-Cloud, страна RU, организация в Петербурге.

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

Попросил у хостера другой адрес. Выдали из семейства 200.x. Проверяю:

$ curl -s https://ipinfo.io/200.x.x.x/json
{
  "city": "Ji Paraná",
  "region": "Rondônia",
  "country": "BR"
}

Бразилия. Снова LACNIC. Те же грабли.

Чем кончилось

Переехал к другому хостеру. Перед оплатой проверил их диапазоны через 2ip.io/ru/as/: RIPE, зарегистрированы на Россию. Потом проверил доступность их сетей со своего канала. Пять из пяти.

После переезда тот же замер:

до:    0 из 10     задержка 100 мс
после: 12 из 12    задержка 25 мс

Перенос занял часа три. Всё было в Docker, так что механика простая: два архива с проектами, .env с ключами, сертификат (он привязан к домену, перевыпускать не надо), статика сайта, DNS.

Методика, если симптомы похожие

По шагам. Первые три занимают пять минут и отсекают половину версий.

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

Берите контрольную группу. Другие хосты через тот же канал. Без этого замер ничего не доказывает.

Разложите по уровням: ICMP, чистый TCP, TLS, HTTP. Место, где ломается, сужает круг втрое. Ping не идёт, значит маршрут или хост лежит. Ping идёт, TCP нет, это фильтрация. TCP идёт, TLS рвётся, это фильтрация по SNI или DPI. Всё идёт, падает только HTTP, вот тогда смотрите свой сервер.

Проверьте обходной путь. Есть VPN, сравните с ним и без него. В Windows реальный интерфейс задаётся через curl --interface, адреса смотреть в ipconfig.

Снимайте tcpdump на сервере. Он отвечает на главный вопрос: доходят ли SYN и отвечает ли сервер. Остальное догадки.

Проверьте, чей диапазон. Одна команда:

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=ВАШ\\_IP" | jq .data.block

Увидели LACNIC, AFRINIC или APNIC у российского хостера, причина скорее всего найдена. Просите адрес из RIPE.

Что вынес

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

Дамп с сервера стоит часа гаданий. Полдня я перебирал версии снаружи, хотя SSH работал с самого начала. Одна команда tcpdump дала однозначный ответ там, где шесть гипотез дали шесть тупиков.

Хостер видит только свою сеть. Первая линия честно пропинговала сервер изнутри стойки, получила 0,68 мс и написала, что всё работает. Формально они правы. Сдвинулось, только когда я прислал таблицу: столько успешных, столько таймаутов, вот трассировка, вот дамп. С цифрами не поспоришь.

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

Почему мы готовим шестиклассников к олимпиаде за 9 класс

Ingir_Max — Tue, 15 Sep 2026 04:50:55 +0000

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

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

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

Сентябрь, новый учебный год и наш очередной заход

В этом году мы решили зайти основательно: связались с несколькими местными школами и объявили набор в бесплатные группы подготовки к олимпиадам с 5 по 9 класс, сразу обозначив, что история будет многолетняя, а не в духе «подготовились, никуда не прошли, разошлись».

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

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

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

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

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

Почему я вообще считаю, что олимпиада того стоит

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

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

Тут есть момент, который многие путают, я сам был уверен в обратном. Порога ЕГЭ в 75 баллов для победителей всероссийской олимпиады попросту не существует — подтверждать свой результат экзаменом не нужно, и вуз обязан зачислить такого абитуриента.

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

Разброс между регионами оказался диким. Москва платит победителю 500 тысяч рублей, призёру 300 тысяч, и это единственный регион, где деньги получает вообще каждый, кто дошёл до финала — даже участнику без диплома причитается 100 тысяч рублей. Подмосковье идёт ровно по той же сетке, а в Якутии победителю дают те же 500 тысяч, но призёру уже только 100, и такого резкого разрыва между первым и вторым местом я не встретил больше нигде.

У меня в Краснодарском крае суммы поскромнее: 150 тысяч за победу и 100 тысяч призёру. Повысили их только в прошлом году, а до этого вместо премий за олимпиаду в крае работал отдельный конкурс на сто одарённых школьников по 50 тысяч рублей. Татарстан и Петербург дают 200 тысяч победителю и 100 призёру, Свердловская область — 100 и 70 соответственно.

А дальше идёт то, о чём обычно не пишут. По открытым сводкам в Саратовской области победителю всероссийской олимпиады платят 7 500 рублей, а в Липецкой 5 500 — столько же, сколько призёру. То есть между Москвой и Липецком разница получается почти в сто раз, причём за победу в одной и той же олимпиаде одного и того же уровня сложности.

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

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

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

До 9 класса олимпиада почти ничего не даёт

Чтобы был понятен масштаб, приведу воронку прошлого сезона по официальным цифрам министерства. Школьный этап собрал 8,3 миллиона человек, муниципальный уже 1,7 миллиона, региональный 153 тысячи, а до заключительного дошло чуть больше девяти тысяч участий. Дипломов в итоге выдали 4 241, из них 732 победителя.

То есть от школьного этапа до финала доходит примерно один человек из девятисот.

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

С 5 по 8 класс ребёнок может участвовать только в школьном и муниципальном этапах. Дальше дороги нет никакой, потому что региональный этап проводится только для 9-11 классов, и это прямо прописано в порядке проведения олимпиады.

Что ученик получает по итогам? Опыт участия, который сам по себе действительно ценен, и грамоту на стену. Родители радуются, ребёнок радуется, и больше эта грамота не даёт ничего — ни льгот, ни денег, ни зачёта где-либо.

И вот тут примерно с 2022 года в эту картину пришли нейросети, которые на тот момент были ещё в зачаточном состоянии.

Что нейросети сделали со школьным этапом

Школьный этап проводится дистанционно, то есть ребёнок спокойно пишет его из дома, и никакого контроля за ним в этот момент нет в принципе.

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

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

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

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

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

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

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

В итоге получается, что с 5 по 8 класс олимпиада за свой класс — это соревнование с достаточно размытыми результатами ради грамоты на стену, и больше ничего оно не даёт.

Стратегия, к которой мы пришли: писать за 9 класс с пятого

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

То есть пятиклассник имеет полное право писать олимпиаду за 9 класс, и никакого нарушения правил в этом нет.

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

Что это в итоге даёт. Ребёнок начинает участвовать в олимпиаде за 9 класс, находясь в пятом. Выиграть всероссийский этап в 5 классе практически нереально, но задача на этом шаге совершенно другая. В 6-7 классе при нормальной подготовке он уже вполне способен пройти на региональный этап, а в 7-8 классе имеет смысл пробиваться на заключительный и показывать там уже какой-то осмысленный результат.

Итого получается пять попыток написать олимпиаду за 9 класс — в 5, 6, 7, 8 и 9 классе, вместо одной-единственной попытки в девятом классе без какой-либо серьёзной подготовки за спиной.

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

Про БВИ стоит сказать отдельно. Льгота действует четыре года, поэтому побеждать имеет смысл где-то с 8 класса, чтобы к моменту поступления она ещё работала. Победа в 5-6 классе даёт респект, опыт и деньги, но к поступлению её уже не приложишь. И это не теория: в 2023 году финал по математике в программе десятых классов выиграл семиклассник из Москвы Пётр Ким, а призёром в программе девятых классов стал двенадцатилетний Георгий Шкурихин из Петербурга. Случаев побед именно пятиклассников я при этом не нашёл, так что ожидания тут всё-таки стоит держать в каких-то разумных рамках.

Насколько велик разрыв между этапами

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

Уровень муниципального этапа по робототехнике оказался, прямо скажем, достаточно низким, и это было для меня неожиданностью. Реальное задание за 9 класс сезона 2023/24 звучит так. Определить по фотографии сельскохозяйственную культуру и посчитать, сколько Маша заплатила за авокадо со скидкой 15 процентов. Ребёнок, который готовился к региональному этапу, проходит такие задания почти автоматически, поэтому вкладывать в них основные силы совершенно бессмысленно.

Региональный этап — это уже сто баллов за два дня, где теория даёт 40 баллов, практика на Arduino ещё 35 и проектный тур оставшиеся 25, то есть 60 баллов из 100 требуют реального железа, собранного своими руками.

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

От авокадо до RANSAC — и это, стоит держать в уме, одна и та же олимпиада, один и тот же класс и соседние между собой этапы.

И вот здесь стоит отметить отдельно то, на чём держится вся наша ставка. С сезона 2025/26 информатика в ВсОШ проводится сразу по четырём профилям: программирование, информационная безопасность, робототехника и искусственный интеллект. Раньше робототехника жила внутри предмета «Технология», а теперь переехала в информатику, и сезон 2025/26 стал первым, когда олимпиада прошла сразу по всем четырём профилям.

Значение у этого простое и достаточно большое. Победа или призёрство по профилю информационной безопасности или робототехники даёт ровно тот же самый БВИ, что и по математике или физике. В финале 2026 года по информатике участвовало 1 227 человек, дипломов выдали 562 — это самый массовый предмет заключительного этапа.

Почему мы делаем упор на робототехнику и безопасность

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

Мы разобрали задания по информационной безопасности за 9 класс с 2024 по 2026 год и получили достаточно любопытную картину. Криптография появилась в перечне тем девятого класса только в 2026 году. RSA у девятиклассников встречается ровно один раз, на заключительном этапе 2026 года, и решается одной командой openssl с готовым ключом. При этом тесты простоты, Миллер-Рабин, теоремы Ферма и Эйлера, шифры Цезаря и Виженера — ровно ноль упоминаний за все три года.

Что происходит, когда группа всё-таки набрана

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

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

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

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

Отдельная история про мотивацию

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

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

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

Кто в итоге остаётся

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

Эти ребята ещё в 4-5 классе поднимали свои Майнкрафт-серверы на моём домашнем сервере. Я заводил под них отдельную виртуальную машину, пробрасывал порты и давал доступ по SSH, а дальше они настраивали систему полностью сами. Разбирались с командами консоли, с докером и с тем, как вообще всё это устроено изнутри.

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

Что я обо всём этом думаю

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

Моя рабочая версия в том, что дело тут совершенно не в лени и не в детях. Олимпиада — это отложенный результат в горизонте нескольких лет, без гарантий и с непонятной для родителя пользой на старте. Конкурировать с кружком, где через месяц получается готовая поделка, она попросту не может. Плюс в маленьком городе про БВИ мало кто вообще знает, и для большинства родителей олимпиада — это по-прежнему про грамоту на стену, а не про поступление в МФТИ без вступительных экзаменов.

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

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

Навигация мобильного робота для сбора клубники

wowa144 — Tue, 15 Sep 2026 04:25:04 +0000

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

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

Полноценный робот-сборщик — достаточно большая система. В неё должны входить как минимум:

мобильная платформа        +
система навигации        +
лидар / датчики        +
техническое зрение        +
поиск спелой клубники        +
манипулятор        +
захват ягоды

Поэтому разработку я решил разбить на отдельные модули.

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

Для разработки используются ROS 2, Python и Webots.

Постановка задачи

На первом этапе движение робота по теплице сильно упрощено.

Рабочая область представлена сеткой 5×5:

20 21 22 23 24
15 16 17 18 19
10 11 12 13 14 5  6  7  8  9 0  1  2  3  4

Каждый номер соответствует возможной позиции мобильной платформы.

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

где находится робот?        ↓
куда ему нужно приехать?        ↓
какой маршрут короче?        ↓
как выполнить этот маршрут?        ↓
что делать, если дорога перекрыта?

Например:

START  = 0
TARGET = 22

Робот должен построить маршрут от 0 до 22, выполнить его и остановиться в целевой позиции.

После этого в симуляции появляется препятствие.

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

Робот получает данные лидара, определяет занятую область и при возвращении уже не должен использовать её.

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

старт  ↓
построение маршрута  ↓
движение по теплице  ↓
рабочая позиция  ↓
обнаружение нового препятствия  ↓
изменение доступной карты  ↓
перепланирование  ↓
возвращение другим маршрутом

Что реализовано

Программа разделена на четыре основных компонента:

Graph
│
├── карта поля
├── координаты маркеров
└── соседние позиции
Planner
│
├── BFS
├── кратчайший маршрут
└── минимизация количества поворотов
Motion
│
├── Odometry
├── управление скоростью
└── движение между маркерами
ObstacleDetector
│
├── LaserScan
├── сравнение сканов
└── определение занятой клетки

Главный модуль связывает эти части в единый сценарий.

[Далее основная часть статьи: описание Graph, BFS, минимизации поворотов, Motion, Odometry, Twist, LaserScan и определения препятствия.]

Как это связано со сбором клубники

На данном этапе робот ещё не собирает ягоды.

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

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

                 РОБОТ-СБОРЩИК                       │        ┌──────────────┼──────────────┐        │              │              │        ↓              ↓              ↓   Навигация      Тех. зрение    Манипулятор        │              │              │        ↓              ↓              ↓   куда ехать     где клубника    как сорвать

Навигационный модуль отвечает за перемещение платформы.

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

Камера определяет ягоды:

изображение    ↓
поиск клубники    ↓
определение спелости    ↓
координаты ягоды

После этого координаты передаются манипулятору:

координаты ягоды       ↓
планирование движения       ↓
подвод захвата       ↓
срыв       ↓
укладка ягоды

После завершения сбора в данной позиции мобильная платформа переезжает дальше.

То есть в перспективе полный рабочий цикл должен выглядеть так:

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

Разбираем программу по частям

Теперь перейдём к самой интересной части — реализации.

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

main.py
│
├── graph.py
│      └── представление поля
│
├── planner.py
│      └── поиск маршрута
│
├── motion_controller.py
│      └── физическое движение робота
│
└── obstacle_detector.py       └── обработка лидара

Это разделение не случайно.

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

Контроллеру движения, наоборот, неважно, каким алгоритмом был найден маршрут. Для него:

[0, 1, 2, 7, 12]

— просто последовательность точек, которые нужно посетить.

А детектор препятствий вообще решает третью задачу: превращает показания лидара в номер занятой клетки.

Так появляется разделение ответственности:

Graph
"Где вообще можно ехать?"
Planner
"Как лучше туда доехать?"
Motion
"Как физически проехать маршрут?"
ObstacleDetector
"Где появилось препятствие?"
main
"В каком порядке всё это запустить?"

Начнём с самого нижнего уровня.

1. graph.py — как представить теплицу в программе

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

Используется поле 5×5:

20 21 22 23 24
15 16 17 18 19
10 11 12 13 14 5  6  7  8  9 0  1  2  3  4

Расстояние между соседними маркерами принимается равным одному метру.

В программе карта представлена классом:

class Graph:

Почему класс?

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

проверить маркер
получить его координаты
получить соседей
определить направление
найти ближайший маркер

Их удобно объединить в один объект.

Размер карты

Внутри класса записано:

SIZE = 5

Это размер одной стороны сетки.

Здесь SIZE является атрибутом класса. Его можно использовать внутри методов:

self.SIZE

self в Python означает текущий объект.

Например:

graph = Graph()

После этого при вызове:

graph.position(12)

внутри position() переменная self будет ссылаться именно на объект graph.

Проверяем существование клетки

Первый метод:

def valid(self, marker):    return 0 <= marker < 25

У нас 25 клеток:

0 ... 24

Поэтому:

graph.valid(12)

вернёт:

True

а:

graph.valid(30)

вернёт:

False

Запись:

0 <= marker < 25

в Python является сокращённой формой:

0 <= marker and marker < 25

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

Перевод номера маркера в координаты

Следующая задача интереснее.

Робот физически не понимает команду:

едь к маркеру 12

Контроллеру нужны координаты:

X = ?
Y = ?

Для этого используется:

def position(self, marker):    x = marker % self.SIZE    y = marker // self.SIZE    return float(x), float(y)

Разберём две операции.

% — остаток от деления.

// — целочисленное деление.

Возьмём маркер 12:

x = 12 % 5

Получим:

А:

y = 12 // 5

даст:

Следовательно:

marker 12 → (2, 2)

Для маркера 17:

17 % 5  = 2
17 // 5 = 3

получаем:

marker 17 → (2, 3)

То есть номер клетки одновременно кодирует её положение на сетке.

Это позволяет не хранить отдельную таблицу:

{    0: (0, 0),    1: (1, 0),    2: (2, 0),    ...
}

Как найти соседние клетки

Для BFS нужно знать, куда можно перейти из текущей клетки.

Для этого существует:

def neighbors(self, marker, blocked=None):

Сначала:

if blocked is None:    blocked = set()

blocked — множество запрещённых клеток.

Например:

blocked = {7, 12}

означает:

в клетки 7 и 12 заезжать нельзя

Почему используется set, а не список?

Потому что нам постоянно нужна операция:

m not in blocked

То есть проверка принадлежности.

Для множества это естественная операция.

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

row = marker // self.SIZE
col = marker % self.SIZE

Для 12:

row = 2
col = 2

Теперь можно проверить четыре направления.

Вправо:

if col < self.SIZE - 1:    result.append(marker + 1)

Если мы не на правой границе, сосед справа имеет номер:

marker + 1

Для 12 это:

Вверх:

if row < self.SIZE - 1:    result.append(marker + self.SIZE)

Получаем:

12 + 5 = 17

Влево:

if col > 0:    result.append(marker - 1)

Получаем:

Вниз:

if row > 0:    result.append(marker - self.SIZE)

Получаем:

Следовательно:

graph.neighbors(12)

даст:

[13, 17, 11, 7]

Зачем нужны проверки границ

Можно было бы просто написать:

[    marker + 1,    marker + 5,    marker - 1,    marker - 5
]

Но тогда для клетки 4:

0 1 2 3 4

операция:

4 + 1 = 5

якобы сказала бы, что 5 находится справа от 4.

Но на карте:

5 6 7 8 9
0 1 2 3 4

5 находится совсем в другой строке.

Поэтому проверки:

col < SIZE - 1
col > 0
row < SIZE - 1
row > 0

не позволяют «провалиться» через край сетки.

Исключаем препятствия

В конце:

return [    m for m in result    if m not in blocked
]

Это list comprehension — компактная запись формирования нового списка.

Например:

result = [13, 17, 11, 7]
blocked = {17}

получим:

[13, 11, 7]

Для планировщика клетки 17 теперь просто не существует как допустимого перехода.

Это очень удобное решение: самому BFS не нужно специально объяснять, что перед роботом появился ящик или другое препятствие.

Достаточно убрать вершину из доступных соседей.

Определяем направление движения

В Graph есть ещё один небольшой метод:

def direction(self, a, b):

Он нужен не для управления роботом, а для оценки маршрута.

Например:

11 → 12

Координаты:

11 = (1, 2)
12 = (2, 2)

Так как:

bx > ax

возвращается:

"RIGHT"

Аналогично определяются:

LEFT
UP
DOWN

Позже планировщик будет использовать эту информацию для подсчёта поворотов.

Как лидар связывается с графом

Последний метод:

nearest_marker()

решает важную задачу.

Лидар ничего не знает о наших номерах:

0, 1, 2, 3...

После обработки лидара мы можем получить реальную координату препятствия:

(2.08, 3.11)

Нужно понять, какой клетке она соответствует.

Перебираем все 25 маркеров:

for marker in range(25):

Получаем координаты:

mx, my = self.position(marker)

И вычисляем евклидово расстояние:

distance = math.hypot(    x - mx,    y - my
)

Фактически это:

d = √((x-mx)² + (y-my)²)

Запоминается маркер с минимальным расстоянием.

Если ближайший маркер слишком далеко:

if best_distance > max_distance:    return None

мы считаем, что lidar-точка вообще не относится к нашей сетке.

Таким образом Graph связывает три представления:

номер клетки    ↕
координаты X/Y    ↕
данные лидара

2. planner.py — строим маршрут

Теперь карта есть.

Следующий вопрос:

Как роботу добраться из клетки 0 в клетку 22?

Для этого используется класс:

class Planner:

При создании он получает граф:

def __init__(self, graph):    self.graph = graph

Поэтому планировщик сам не знает, что карта имеет размер 5×5.

Он просто спрашивает:

self.graph.neighbors(...)

Это хороший принцип разделения ответственности.

Почему BFS

Для поиска используется Breadth-First Search — поиск в ширину.

Импортируется:

from collections import deque

deque — двусторонняя очередь.

Для BFS нам важны две операции:

queue.append(...)

положить элемент в конец и:

queue.popleft()

забрать элемент из начала.

Получается FIFO:

First In → First Out

Именно благодаря этому BFS рассматривает карту слоями.

Как распространяется BFS

Пусть:

START = 0

Сначала очередь:

[0]

Из 0 доступны:

1, 5

Затем рассматриваются пути:

[0, 1]
[0, 5]

Следующий слой:

[0, 1, 2]
[0, 1, 6]
[0, 5, 6]
[0, 5, 10]

То есть алгоритм сначала исследует все пути длины 1, потом длины 2, затем 3 и так далее.

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

Почему в очереди лежат целые маршруты

В коде:

queue.append([start])

Обратите внимание: кладётся не просто:

а:

[0]

То есть список — уже готовый маршрут.

При расширении:

new_route = route + [next_marker]

Например:

route = [0, 1, 2]
next_marker = 7

получим:

[0, 1, 2, 7]

Для большой карты это не самый экономный по памяти вариант BFS, но для поля 5×5 он очень нагляден.

Не требуется отдельно хранить таблицу родителей и потом восстанавливать маршрут.

Не ходим по кругу

Есть проверка:

if next_marker in route:    continue

Представим:

0 → 1

Из 1 можно снова попасть в 0.

Без проверки алгоритм мог бы строить:

0 → 1 → 0 → 1 → 0 ...

Поэтому запрещается добавлять клетку, которая уже присутствует в текущем маршруте.

continue означает:

прекратить текущую итерацию цикла и перейти к следующему соседу.

Почему сохраняются несколько маршрутов

Обычный BFS часто завершают сразу после нахождения цели.

Но здесь этого делать нельзя.

Нам нужен не просто первый кратчайший маршрут.

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

Поэтому:

found_routes = []
shortest_length = None

Когда достигаем цели:

if current == target:    shortest_length = len(route)    found_routes.append(route)    continue

Первый найденный маршрут задаёт минимальную длину.

Но обработка остальных маршрутов того же уровня продолжается.

Когда очередь переходит к более длинным:

if shortest_length is not None:    if len(route) > shortest_length:        break

поиск заканчивается.

Считаем повороты

Возьмём маршрут:

0 → 1 → 2 → 7 → 12 → 17 → 22

Направления:

RIGHT
RIGHT
UP
UP
UP
UP

Изменение направления произошло только один раз:

RIGHT → UP

Значит:

turns = 1

В коде сначала определяется первое направление:

old_direction = self.graph.direction(    route[0],    route[1]
)

Потом последовательно сравниваются остальные:

if new_direction != old_direction:    turns += 1

После сравнения:

old_direction = new_direction

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

Выбираем лучший маршрут

После BFS у нас может быть несколько вариантов.

Используется:

best_route = min(    found_routes,    key=lambda route: (        self.count_turns(route),        route    )
)

Это одна из менее очевидных конструкций Python.

min() здесь ищет минимальный элемент не непосредственно по самому списку, а по ключу.

Для каждого маршрута ключ имеет вид:

(    количество_поворотов,    сам_маршрут
)

Например:

route A → (3, [0, 1, 6, ...])
route B → (1, [0, 5, 10, ...])

Сначала Python сравнит:

3 и 1

и выберет второй маршрут.

Если число поворотов совпадает, сравниваются сами списки маркеров.

Это делает выбор детерминированным.

Что возвращает Planner

В конце:

distance = len(best_route) - 1
turns = self.count_turns(best_route)
return best_route, distance, turns

Почему:

len(route) - 1

Потому что маршрут:

[0, 1, 2]

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

0 → 1
1 → 2

Поэтому расстояние в нашей условной метрической сетке равно двум.

3. motion_controller.py — превращаем маршрут в движение

До этого всё происходило только внутри Python.

Планировщик вернул:

[0, 1, 2, 7, 12]

Но реальный или виртуальный робот от списка Python никуда не поедет.

Нужно перейти от дискретного маршрута к управлению скоростями.

За это отвечает:

class Motion:

Связь с ROS 2

Контроллер создаёт publisher:

self.publisher = node.create_publisher(    Twist,    "/RMC2/cmd_vel",    10
)

Publisher можно представить как отправителя сообщений.

Он публикует сообщения типа:

geometry_msgs/msg/Twist

в topic:

/RMC2/cmd_vel

Через Twist задаются линейные и угловые скорости.

Нас интересуют:

command.linear.x
command.angular.z

Первая величина отвечает за движение вперёд.

Вторая — за вращение вокруг вертикальной оси.

Получаем обратную связь

Одновременно создаётся subscriber:

node.create_subscription(    Odometry,    "/RMC2/odometry",    self.odom_callback,    10
)

Это уже обратный канал:

робот  ↓
/RMC2/odometry  ↓
Motion

При поступлении нового сообщения ROS вызывает:

self.odom_callback

Это callback-функция.

Её не нужно самостоятельно запускать циклом.

ROS вызывает её, когда приходит новое сообщение.

Что берём из Odometry

В callback:

self.x = msg.pose.pose.position.x
self.y = msg.pose.pose.position.y

Получаем текущие координаты робота.

Но ориентация приходит в виде кватерниона:

msg.pose.pose.orientation

Для плоского движения четыре компонента кватерниона нам непосредственно не нужны.

Поэтому используется функция:

quaternion_to_yaw()

и получаем один понятный угол:

yaw

Например:

0°   → робот смотрит вдоль +X
90°  → вдоль +Y
180° → вдоль -X

Зачем angle_to_pi

Представим:

текущий угол = +179°
целевой угол = -179°

Обычное вычитание даст:

-358°

Хотя физически роботу нужно повернуться всего на:

2°

Поэтому ошибка приводится к диапазону:

[-π, +π]

Функция:

while angle > math.pi:    angle -= 2 * math.pi
while angle < -math.pi:    angle += 2 * math.pi

убирает неоднозначность перехода через ±π.

Почему управление работает через таймер

В конструкторе:

node.create_timer(    0.05,    self.control
)

ROS будет вызывать:

self.control()

примерно каждые:

0.05 секунды

то есть:

20 раз в секунду

Это и есть простой цикл управления.

Каждый цикл контроллер заново спрашивает:

Где я сейчас?
Куда мне нужно?
Как далеко осталось?
Куда я повернут?
Какую скорость отправить?

Начало движения

Когда main.py вызывает:

motion.start(route)

маршрут сохраняется:

self.route = route

и:

self.index = 1

Почему не 0?

Если маршрут:

[0, 1, 2, 7]

робот уже находится в 0.

Поэтому первая настоящая цель:

route[1] = 1

Вычисляем направление на цель

Пусть следующая цель — маркер 7.

Получаем:

target_x, target_y = self.graph.position(target)

После этого:

dx = target_x - self.x
dy = target_y - self.y

Это вектор от робота до цели.

Расстояние:

distance = math.hypot(dx, dy)

Требуемый угол:

target_yaw = math.atan2(dy, dx)

atan2() удобен тем, что сразу учитывает знаки dx и dy и правильно определяет квадрант.

Ошибка ориентации

Теперь известно:

куда робот смотрит сейчас

и:

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

Поэтому:

error = angle_to_pi(    target_yaw - self.yaw
)

Если:

error ≈ 0

робот смотрит практически точно на цель.

Если ошибка большая — сначала нужно повернуться.

Логика «сначала повернись, потом езжай»

В программе используется очень простой контроллер.

Если:

abs(error) > self.angle_tolerance

то:

command.linear.x = 0.0

Робот не движется вперёд.

В зависимости от знака ошибки:

command.angular.z = +0.60

или:

command.angular.z = -0.60

То есть робот поворачивается на месте.

Когда угол становится достаточно точным, выполняется ветка else:

command.linear.x = self.linear_speed

и платформа начинает ехать вперёд.

Коррекция курса

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

Поэтому во время движения:

command.angular.z = 1.2 * error

Это простейший пропорциональный регулятор.

Можно записать:

ω = Kp × e

где:

ω  — угловая скорость
Kp — коэффициент 1.2
e  — ошибка направления

Чем сильнее робот отклонился, тем сильнее он корректирует курс.

Но бесконечно большую команду давать нельзя.

Поэтому:

if command.angular.z > 0.30:    command.angular.z = 0.30
if command.angular.z < -0.30:    command.angular.z = -0.30

Получается ограничение:

-0.30 ≤ angular.z ≤ 0.30

Как робот понимает, что приехал

Используется:

if distance < self.distance_tolerance:

где:

self.distance_tolerance = 0.12

То есть попадать математически точно в:

(2.000000, 3.000000)

не требуется.

Достаточно оказаться ближе 12 сантиметров.

После этого:

self.index += 1

и следующая клетка маршрута становится новой целью.

4. obstacle_detector.py — находим новое препятствие

Теперь самая интересная сенсорная часть.

Робот приехал к растениям.

Мы хотим смоделировать ситуацию:

Пока робот выполнял работу, на пути появился новый объект.

Для этого используется LaserScan.

Подписка на лидар

В конструкторе:

node.create_subscription(    LaserScan,    "/RMC2/scan",    self.scan_callback,    qos_profile_sensor_data
)

При каждом новом скане вызывается:

scan_callback()

А callback просто сохраняет последнее сообщение:

self.scan = msg

То есть объект ObstacleDetector всегда содержит самый свежий доступный скан.

Что такое LaserScan

Упрощённо лидар возвращает массив расстояний:

ranges = [    2.31,    2.29,    2.25,    ...
]

Каждый элемент соответствует определённому углу.

Угол луча с индексом i:

angle = (    scan.angle_min    + i * scan.angle_increment
)

То есть лидар фактически даёт набор полярных координат:

(угол, расстояние)

Сохраняем фон

До установки препятствия:

self.baseline = list(    self.scan.ranges
)

baseline — снимок окружающей среды.

Например:

луч №120 → 3.8 м
луч №121 → 3.9 м
луч №122 → ∞

После установки ящика:

луч №120 → 1.7 м
луч №121 → 1.72 м
луч №122 → 1.75 м

Теперь можно искать разницу.

Фильтрация неправильных измерений

Перед анализом проверяется:

math.isfinite(new_range)

Потому что лидар может возвращать:

inf

если препятствие не обнаружено.

Также проверяются физические пределы датчика:

new_range < self.scan.range_min
new_range > self.scan.range_max

Такие измерения пропускаются через:

continue

Как определяется новый объект

Есть два варианта.

Первый:

if not math.isfinite(old_range):    new_object = True

Раньше:

∞

а теперь:

1.8 м

Значит перед лидаром действительно что-то появилось.

Второй:

elif old_range - new_range >= self.min_change:    new_object = True

где:

self.min_change = 0.20

Например:

раньше = 3.4 м
сейчас = 1.9 м
3.4 - 1.9 = 1.5 м

Изменение намного больше 20 см, значит луч считается принадлежащим новому объекту.

Из полярных координат в декартовы

Допустим, лидар сообщает:

range = r
angle = α

Получаем:

local_x = new_range * math.cos(angle)
local_y = new_range * math.sin(angle)

Это координаты относительно самого робота.

Если объект находится прямо перед ним:

local_x > 0
local_y ≈ 0

Если слева:

local_y > 0

Но есть проблема.

Наш граф существует не в системе координат робота, а в мировой системе Webots/одометрии.

Переход в мировую систему координат

Мы знаем:

robot_x
robot_y
robot_yaw

Поэтому выполняем поворот и перенос:

world_x = robot_x + (    local_x * math.cos(robot_yaw)    - local_y * math.sin(robot_yaw)
)
world_y = robot_y + (    local_x * math.sin(robot_yaw)    + local_y * math.cos(robot_yaw)
)

Это обычное двумерное преобразование координат.

В матричной форме:

[world_x]   [robot_x]   [ cosθ  -sinθ ] [local_x]
[world_y] = [robot_y] + [ sinθ   cosθ ] [local_y]

Теперь точка лидара находится в той же системе координат, что и маркеры нашего Graph.

И это ключевой момент всей связки:

LaserScan   ↓
локальная точка относительно робота   ↓
положение и yaw робота   ↓
мировая координата   ↓
ближайший маркер графа

Почему используется голосование

Предположим, ящик перекрыл маркер 12.

Лидар увидит не одну точку, а целое облако:

(1.93, 2.04)
(1.97, 2.08)
(2.01, 2.05)
(2.06, 1.99)
...

Каждая точка переводится в ближайший маркер:

marker = self.graph.nearest_marker(...)

И затем:

votes[marker] = votes.get(marker, 0) + 1

dict.get(marker, 0) означает:

если такой ключ уже есть — взять его значение; если нет — использовать 0.

Например:

первый луч:
votes[12] = 1
второй:
votes[12] = 2
третий:
votes[12] = 3

В итоге:

{    11: 1,    12: 14,    13: 2
}

Выбираем:

best_marker = max(    votes,    key=votes.get
)

Получаем:

Защита от случайных точек

Одного голоса недостаточно:

if votes[best_marker] < self.min_votes:    return None

В программе:

self.min_votes = 3

То есть минимум три lidar-точки должны подтвердить гипотезу.

Это простейшая фильтрация шума.

5. main.py — собираем систему целиком

Теперь у нас есть четыре отдельных механизма.

main.py превращает их в единый эксперимент.

Сначала:

rclpy.init(args=args)

инициализируется ROS 2.

Создаётся node:

node = Node("module_b_navigation")

Нода — участник ROS-системы, через который мы создаём publisher, subscriber, timer и работаем с параметрами.

Параметры start_id и target_id

Вместо жёстко прописанных:

start = 0
target = 22

используются ROS-параметры:

node.declare_parameter("start_id", 0)
node.declare_parameter("target_id", 22)

Значения 0 и 22 являются значениями по умолчанию.

При запуске их можно заменить:

ros2 run ... --ros-args \    -p start_id:=5 \    -p target_id:=24

Код при этом менять не потребуется.

Создание модулей

graph = Graph()
planner = Planner(graph)
motion = Motion(node, graph)
detector = ObstacleDetector(node, graph)

Здесь хорошо видно зависимости.

Planner получает Graph:

Planner → Graph

Motion нужны:

ROS Node + Graph

потому что ему нужны ROS topics и координаты маркеров.

ObstacleDetector также нужны:

ROS Node + Graph

потому что он получает LaserScan и переводит точки в клетки карты.

Этап 1. Планирование

Сначала препятствий нет:

blocked = set()

Строим маршрут:

route, distance, turns = planner.plan(    start,    target,    blocked
)

Например:

route    = [0, 1, 2, 7, 12, 17, 22]
distance = 6
turns    = 1

Этап 2. Движение

Передаём маршрут контроллеру:

motion.start(route)

Но здесь появляется важный момент ROS.

Контроллер работает через callback и timer.

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

Поэтому:

while motion.active and rclpy.ok():    rclpy.spin_once(        node,        timeout_sec=0.1    )

spin_once() говорит ROS:

обработай ожидающие события один раз.

Благодаря этому продолжают работать:

Odometry callback
LaserScan callback
Motion timer

Пока:

motion.active == True

робот продолжает выполнять маршрут.

Этап 3. Сохраняем состояние лидара

Когда робот приехал:

detector.save_baseline()

фиксирует состояние окружающей среды.

Это очень важно сделать до появления нового объекта.

Этап 4. Добавляем препятствие

В экспериментальной версии это сделано вручную.

Программа выводит:

Поставьте ОДНО препятствие в Webots.
После этого введите y и нажмите Enter.

После:

программа продолжает работу.

Почему так?

Потому что на данном этапе задача — проверить сам алгоритм:

старый scan
+
новый scan
→
найти изменение

Автоматическое появление объекта в Webots здесь не является основной частью эксперимента.

Этап 5. Получаем свежий scan

После нажатия Enter нельзя сразу использовать:

detector.scan

В нём теоретически ещё может лежать предыдущее сообщение.

Поэтому несколько раз вызывается:

rclpy.spin_once(...)

чтобы ROS успел получить свежие сообщения лидара.

Этап 6. Определяем препятствие

Теперь:

blocked_marker = detector.find_obstacle(    motion.x,    motion.y,    motion.yaw,    excluded={start, target}
)

Передаются:

текущий X робота
текущий Y
текущий yaw

Они нужны для перевода lidar-точек в мировую систему координат.

Также:

excluded={start, target}

не позволяет принять стартовую или целевую клетку за новое препятствие.

Если обнаружен:

blocked_marker = 12

создаём:

blocked = {12}

Этап 7. Повторное планирование

И здесь проявляется преимущество разделения программы на модули.

Нам не нужен второй алгоритм.

Снова вызывается тот же:

planner.plan()

только теперь:

START  = предыдущая цель
TARGET = первоначальный старт
BLOCKED = {12}

То есть:

return_route, distance, turns = planner.plan(    target,    start,    blocked
)

BFS автоматически перестаёт рассматривать клетку 12, потому что Graph.neighbors() её отфильтрует.

Получается цепочка:

ObstacleDetector        ↓      12        ↓
blocked = {12}        ↓      Graph        ↓
neighbors() не возвращает 12        ↓     Planner        ↓
строит другой маршрут

Это, пожалуй, наиболее важное архитектурное место всей программы.

Этап 8. Возвращение

Новый маршрут снова передаётся:

motion.start(return_route)

и тот же Motion выполняет его.

То есть ни контроллер движения, ни планировщик не имеют отдельных режимов:

"ехать туда"
"ехать обратно"

Для них это просто разные списки координат.

Зачем finally

В конце используется:

finally:    motion.stop()    node.destroy_node()    rclpy.shutdown()

finally выполняется независимо от того, как завершился блок try.

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

Ctrl+C

Это вызывает:

KeyboardInterrupt

который перехватывается:

except KeyboardInterrupt:    pass

Но затем всё равно выполняется finally.

Особенно важен:

motion.stop()

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

Как все пять файлов работают вместе

Теперь можно собрать всю систему в одну схему:

                 main.py                    │                    ↓             start=0 target=22                    │                    ↓                Planner                    │                    ↓                  Graph                    │                    ↓       [0,1,2,7,12,17,22]                    │                    ↓                 Motion              ↙            ↘      /RMC2/odometry    /RMC2/cmd_vel              ↘            ↙              мобильный робот                    │                    ↓                  цель                    │                    ↓            ObstacleDetector                    ↑              /RMC2/scan                    │                  LIDAR                    │                    ↓          новая точка препятствия                    │                    ↓             world X / world Y                    │                    ↓                  Graph                    │                    ↓           ближайший marker = 12                    │                    ↓              blocked={12}                    │                    ↓                 Planner                    │                    ↓             новый маршрут                    │                    ↓                 Motion                    │                    ↓             возврат робота

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

Это не просто:

найти путь

а цикл:

восприятие среды      ↓
представление пространства      ↓
принятие решения      ↓
управление      ↓
движение      ↓
новое восприятие среды      ↓
изменение решения

Именно такой цикл затем можно развивать для робота-сборщика клубники.

Как это будет развиваться для клубники

Текущая версия решает только задачу мобильной навигации.

Но архитектура уже позволяет сверху добавить следующий уровень.

Когда Motion сообщает о завершении маршрута:

ROBOT AT WORK POSITION

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

камера  ↓
изображение растения  ↓
детектор ягод  ↓
спелая / неспелая  ↓
координаты центра ягоды  ↓
оценка XYZ

После этого управление получает манипулятор:

XYZ ягоды   ↓
траектория манипулятора   ↓
подвод захвата   ↓
срыв   ↓
перенос в контейнер

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

манипулятор закончил        ↓
навигация получает следующую цель        ↓
Planner        ↓
Motion        ↓
следующий участок растений

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

В перспективе полный цикл робота для сбора клубники будет выглядеть примерно так:

             КАРТА ТЕПЛИЦЫ                    │                    ↓              PLANNER                    │                    ↓               MOTION                    │                    ↓           рабочая позиция                    │                    ↓                КАМЕРА                    │                    ↓          обнаружение клубники                    │                    ↓          определение спелости                    │                    ↓             координаты XYZ                    │                    ↓              МАНИПУЛЯТОР                    │                    ↓               сбор ягоды                    │                    ↓         есть ещё спелые ягоды?              ↙             ↘            да               нет            ↓                 ↓       следующая ягода    следующий участок                              │                              ↓                           PLANNER

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

После этого отдельные простые компоненты можно постепенно заменять более серьёзными:

сетка 5×5    ↓
карта теплицы / occupancy grid
BFS    ↓
A* / Nav2 planner
простое движение по точкам    ↓
локальный контроллер Nav2
baseline LaserScan    ↓
постоянное обнаружение препятствий
фиксированные рабочие точки    ↓
точки, определяемые картой рядов
ручной этап сбора    ↓
камера + нейросеть + манипулятор

Результат

На текущем этапе реализован прототип навигационного модуля робота-сборщика клубники.

Робот умеет:

работать с дискретной картой 5×5;
определять соседние доступные позиции;
искать кратчайший маршрут;
при одинаковой длине маршрутов выбирать вариант с меньшим количеством поворотов;
двигаться по маршруту с использованием одометрии;
управляться через Twist;
получать данные 2D-лидара;
обнаруживать появление нового препятствия;
определять занятую клетку;
исключать её из дальнейшего планирования;
строить новый маршрут.

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

Исходный код

Весь пример разделён на несколько Python-файлов:

module_b_navigation/
│
├── __init__.py
├── main.py
├── graph.py
├── planner.py
├── motion_controller.py
└── obstacle_detector.py

graph.py содержит модель поля 5×5, координаты 25 маркеров и получение доступных соседних клеток.

planner.py содержит BFS-планировщик. Сначала выбирается минимальная длина маршрута, затем минимальное количество поворотов.

motion_controller.py отвечает за фактическое движение мобильной платформы. Положение получается из:

/RMC2/odometry

а команды отправляются в:

/RMC2/cmd_vel

obstacle_detector.py получает:

/RMC2/scan

сохраняет исходный LaserScan, сравнивает его с новым сканом и определяет, возле какого маркера появилось препятствие.

main.py объединяет всё в один эксперимент:

построение маршрута
→ движение
→ сохранение лидара
→ появление препятствия
→ определение занятого маркера
→ перепланирование
→ возвращение

Запуск

Стартовый и конечный маркеры передаются параметрами ROS 2.

Например:

ros2 run <package_name> <executable_name> --ros-args \    -p start_id:=0 \    -p target_id:=22

После запуска робот строит маршрут и начинает движение.

В целевой точке программа предложит установить препятствие в Webots:

РОБОТ ОСТАНОВИЛСЯ В ЦЕЛЕВОЙ ТОЧКЕ
Поставьте ОДНО препятствие в Webots.
После этого введите y и нажмите Enter.
Препятствие установлено? [y]:

После ввода:

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

Что дальше

Следующий этап — приблизить модель к реальной задаче сбора клубники.

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

робот движется      ↓
постоянно работает lidar      ↓
обнаружено препятствие?    ↙           ↘  нет            да   ↓              ↓
едем дальше    остановка                  ↓             обновление карты                  ↓             новый маршрут

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

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

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

НАВИГАЦИЯ    ↓
робот приехал к кусту    ↓
ТЕХНИЧЕСКОЕ ЗРЕНИЕ    ↓
найдена спелая клубника    ↓
МАНИПУЛЯТОР    ↓
ягода собрана    ↓
НАВИГАЦИЯ    ↓
следующая рабочая позиция

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

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

Ниже приведу полный код навигационной части прототипа робота для сбора клубники.

Проект разделён на несколько небольших модулей:

module_b_navigation/
│
├── __init__.py
├── main.py
├── graph.py
├── planner.py
├── motion_controller.py
└── obstacle_detector.py

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

graph.py

Первый модуль описывает наше условное поле теплицы.

import math


class Graph:
    """
    Простая карта поля 5x5.

    Нумерация маркеров:

        20 21 22 23 24
        15 16 17 18 19
        10 11 12 13 14
         5  6  7  8  9
         0  1  2  3  4

    Расстояние между соседними маркерами принимаем равным 1 метру.
    """

    SIZE = 5

    def valid(self, marker):
        """Проверяет, существует ли такой маркер."""
        return 0 <= marker < 25

    def position(self, marker):
        """
        Возвращает координаты маркера.

        Например:
        marker = 12

        x = 12 % 5  = 2
        y = 12 // 5 = 2

        Значит маркер 12 находится в точке (2, 2).
        """
        x = marker % self.SIZE
        y = marker // self.SIZE
        return float(x), float(y)

    def neighbors(self, marker, blocked=None):
        """
        Возвращает соседние клетки.

        Порядок:
        вправо -> вверх -> влево -> вниз.
        """

        if blocked is None:
            blocked = set()

        row = marker // self.SIZE
        col = marker % self.SIZE

        result = []

        # Вправо
        if col < self.SIZE - 1:
            result.append(marker + 1)

        # Вверх
        if row < self.SIZE - 1:
            result.append(marker + self.SIZE)

        # Влево
        if col > 0:
            result.append(marker - 1)

        # Вниз
        if row > 0:
            result.append(marker - self.SIZE)

        # Убираем занятые клетки
        return [m for m in result if m not in blocked]

    def direction(self, a, b):
        """
        Возвращает направление движения между двумя соседними маркерами.
        Нужно только для подсчёта поворотов.
        """

        ax, ay = self.position(a)
        bx, by = self.position(b)

        if bx > ax:
            return "RIGHT"
        if bx < ax:
            return "LEFT"
        if by > ay:
            return "UP"
        if by < ay:
            return "DOWN"

    def nearest_marker(self, x, y, max_distance=0.75, excluded=None):
        """
        По координатам точки ищет ближайший маркер.

        Это используется для лидара:
        лидар дал координату препятствия -> определяем номер клетки.
        """

        if excluded is None:
            excluded = set()

        best_marker = None
        best_distance = 999999.0

        for marker in range(25):

            if marker in excluded:
                continue

            mx, my = self.position(marker)

            distance = math.hypot(x - mx, y - my)

            if distance < best_distance:
                best_distance = distance
                best_marker = marker

        if best_distance > max_distance:
            return None

        return best_marker

planner.py

Следующий модуль занимается поиском маршрута.

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

from collections import deque


class Planner:
    """
    Строит маршрут по клеткам.

    Критерии:
    1. Сначала ищем самый короткий маршрут.
    2. Если коротких маршрутов несколько,
       выбираем маршрут с меньшим количеством поворотов.
    3. Если и это одинаково,
       выбираем маршрут с меньшими ID маркеров.
    """

    def __init__(self, graph):
        self.graph = graph

    def count_turns(self, route):
        """Считает количество поворотов в маршруте."""

        if len(route) < 3:
            return 0

        turns = 0

        old_direction = self.graph.direction(
            route[0],
            route[1]
        )

        for i in range(1, len(route) - 1):

            new_direction = self.graph.direction(
                route[i],
                route[i + 1]
            )

            if new_direction != old_direction:
                turns += 1

            old_direction = new_direction

        return turns

    def plan(self, start, target, blocked=None):
        """
        Возвращает:

            route, distance, turns

        Например:

            [0, 1, 2, 7, 12, 17, 22], 6, 1
        """

        if blocked is None:
            blocked = set()

        if not self.graph.valid(start):
            raise ValueError("Неверный стартовый маркер")

        if not self.graph.valid(target):
            raise ValueError("Неверный целевой маркер")

        if start in blocked:
            raise ValueError("Стартовая клетка занята")

        if target in blocked:
            raise ValueError("Целевая клетка занята")

        if start == target:
            return [start], 0, 0

        # В очереди лежат целые маршруты.
        queue = deque()
        queue.append([start])

        # Здесь будем хранить все самые короткие маршруты до цели.
        found_routes = []
        shortest_length = None

        while queue:

            route = queue.popleft()

            # Если уже нашли более короткий маршрут,
            # этот маршрут продолжать бессмысленно.
            if shortest_length is not None:
                if len(route) > shortest_length:
                    break

            current = route[-1]

            if current == target:
                shortest_length = len(route)
                found_routes.append(route)
                continue

            for next_marker in self.graph.neighbors(current, blocked):

                # Не заходим второй раз в клетку,
                # которая уже есть в этом маршруте.
                if next_marker in route:
                    continue

                new_route = route + [next_marker]
                queue.append(new_route)

        if not found_routes:
            raise RuntimeError("Маршрут не найден")

        # Из всех кратчайших маршрутов выбираем:
        # сначала по количеству поворотов,
        # потом по самим ID маркеров.
        best_route = min(
            found_routes,
            key=lambda route: (
                self.count_turns(route),
                route
            )
        )

        distance = len(best_route) - 1
        turns = self.count_turns(best_route)

        return best_route, distance, turns

motion_controller.py

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

Он получает положение из одометрии и отправляет команды скорости через Twist.

import math

from geometry_msgs.msg import Twist
from nav_msgs.msg import Odometry


def angle_to_pi(angle):
    """
    Приводит угол к диапазону от -pi до +pi.
    """

    while angle > math.pi:
        angle -= 2 * math.pi

    while angle < -math.pi:
        angle += 2 * math.pi

    return angle


def quaternion_to_yaw(q):
    """
    ROS хранит ориентацию как quaternion.
    Для движения по плоскости нам нужен только угол вокруг Z (yaw).
    """

    sin_yaw = 2 * (q.w * q.z + q.x * q.y)
    cos_yaw = 1 - 2 * (q.y * q.y + q.z * q.z)

    return math.atan2(sin_yaw, cos_yaw)


class Motion:
    """
    Простое движение робота по готовому маршруту.

    Класс:
    - получает odometry;
    - знает положение робота;
    - поворачивает робота к следующему маркеру;
    - едет к нему;
    - после достижения переходит к следующему.
    """

    def __init__(self, node, graph):

        self.node = node
        self.graph = graph

        # Команды скорости робота
        self.publisher = node.create_publisher(
            Twist,
            "/RMC2/cmd_vel",
            10
        )

        # Положение робота
        node.create_subscription(
            Odometry,
            "/RMC2/odometry",
            self.odom_callback,
            10
        )

        # Управление вызывается каждые 0.05 секунды
        node.create_timer(
            0.05,
            self.control
        )

        self.x = None
        self.y = None
        self.yaw = None

        self.route = []
        self.index = 0

        # Пока active == True, робот выполняет маршрут.
        self.active = False

        # Скорости
        self.linear_speed = 0.20
        self.angular_speed = 0.60

        # Допуски
        self.distance_tolerance = 0.12
        self.angle_tolerance = math.radians(5)

    def odom_callback(self, msg):
        """Получаем текущее положение робота."""

        self.x = msg.pose.pose.position.x
        self.y = msg.pose.pose.position.y
        self.yaw = quaternion_to_yaw(
            msg.pose.pose.orientation
        )

    def start(self, route):
        """Запускает движение по маршруту."""

        self.route = route

        # route[0] — клетка, где робот уже находится.
        # Поэтому начинаем с route[1].
        self.index = 1

        if len(route) < 2:
            self.active = False
            return

        self.active = True

        self.node.get_logger().info(
            f"movement_start route={route}"
        )

    def stop(self):
        """Посылает нулевую скорость."""
        self.publisher.publish(Twist())

    def finish(self):
        """Останавливает робот и завершает маршрут."""

        self.stop()
        self.active = False

        self.node.get_logger().info(
            "movement_stop"
        )

    def control(self):
        """
        Основной алгоритм движения.

        1. Берём следующий маркер.
        2. Вычисляем, где он находится.
        3. Если робот смотрит не туда — поворачиваемся.
        4. Если смотрит туда — едем прямо.
        5. Если приехали — берём следующий маркер.
        """

        if not self.active:
            return

        # Ждём первую odometry.
        if self.x is None:
            return

        # Если маршрут закончился.
        if self.index >= len(self.route):
            self.finish()
            return

        target = self.route[self.index]

        target_x, target_y = self.graph.position(target)

        dx = target_x - self.x
        dy = target_y - self.y

        distance = math.hypot(dx, dy)

        # Угол, куда нужно смотреть.
        target_yaw = math.atan2(dy, dx)

        # Ошибка по углу.
        error = angle_to_pi(
            target_yaw - self.yaw
        )

        # --------------------------------------------------
        # Уже приехали к маркеру
        # --------------------------------------------------

        if distance < self.distance_tolerance:

            self.node.get_logger().info(
                f"marker_reached: {target}"
            )

            self.stop()
            self.index += 1

            if self.index >= len(self.route):
                self.finish()

            return

        command = Twist()

        # --------------------------------------------------
        # Сначала поворачиваемся
        # --------------------------------------------------

        if abs(error) > self.angle_tolerance:

            command.linear.x = 0.0

            if error > 0:
                command.angular.z = self.angular_speed
            else:
                command.angular.z = -self.angular_speed

        # --------------------------------------------------
        # Потом едем прямо
        # --------------------------------------------------

        else:

            command.linear.x = self.linear_speed

            # Небольшая коррекция курса.
            command.angular.z = 1.2 * error

            # Ограничиваем скорость поворота.
            if command.angular.z > 0.30:
                command.angular.z = 0.30

            if command.angular.z < -0.30:
                command.angular.z = -0.30

        self.publisher.publish(command)

obstacle_detector.py

Этот модуль отвечает за лидар.

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

import math

from rclpy.qos import qos_profile_sensor_data
from sensor_msgs.msg import LaserScan


class ObstacleDetector:
    """
    Ищет ОДНО новое препятствие.

    Идея очень простая:

    1. До появления препятствия запоминаем lidar.
    2. Пользователь ставит препятствие.
    3. Получаем новый lidar.
    4. Ищем лучи, у которых расстояние сильно уменьшилось.
    5. Переводим эти точки в координаты мира.
    6. Смотрим, возле какого маркера больше всего таких точек.
    """

    def __init__(self, node, graph):

        self.node = node
        self.graph = graph

        # Последнее сообщение лидара.
        self.scan = None

        # Расстояния до появления препятствия.
        self.baseline = None

        node.create_subscription(
            LaserScan,
            "/RMC2/scan",
            self.scan_callback,
            qos_profile_sensor_data
        )

        # Если расстояние уменьшилось минимум на 20 см,
        # считаем, что появился новый объект.
        self.min_change = 0.20

        # Насколько далеко точка может быть от центра клетки.
        self.max_marker_distance = 0.75

        # Минимум lidar-точек, чтобы поверить результату.
        self.min_votes = 3

    def scan_callback(self, msg):
        """Просто сохраняем самый свежий scan."""
        self.scan = msg

    def save_baseline(self):
        """
        Запоминаем lidar до появления препятствия.
        """

        if self.scan is None:
            return False

        self.baseline = list(self.scan.ranges)
        return True

    def find_obstacle(self, robot_x, robot_y, robot_yaw, excluded=None):
        """
        Возвращает номер занятой клетки.
        Если препятствие не найдено — возвращает None.
        """

        if excluded is None:
            excluded = set()

        if self.scan is None:
            return None

        if self.baseline is None:
            return None

        if len(self.baseline) != len(self.scan.ranges):
            return None

        # votes:
        # ключ   = номер маркера
        # значение = сколько lidar-точек попало возле него
        votes = {}

        # Для красивого лога сохраняем координаты точек.
        points = {}

        for i in range(len(self.scan.ranges)):

            old_range = self.baseline[i]
            new_range = self.scan.ranges[i]

            # Текущая дальность должна быть нормальной.
            if not math.isfinite(new_range):
                continue

            if new_range < self.scan.range_min:
                continue

            if new_range > self.scan.range_max:
                continue

            # Проверяем, появился ли здесь новый объект.
            new_object = False

            # Раньше лидар ничего не видел,
            # а теперь увидел объект.
            if not math.isfinite(old_range):
                new_object = True

            # Или объект стал как минимум на 20 см ближе.
            elif old_range - new_range >= self.min_change:
                new_object = True

            if not new_object:
                continue

            # Угол конкретного луча лидара.
            angle = (
                self.scan.angle_min
                + i * self.scan.angle_increment
            )

            # ------------------------------------------
            # Координаты точки относительно робота
            # ------------------------------------------

            local_x = new_range * math.cos(angle)
            local_y = new_range * math.sin(angle)

            # ------------------------------------------
            # Переводим точку в координаты мира
            # ------------------------------------------

            world_x = robot_x + (
                local_x * math.cos(robot_yaw)
                - local_y * math.sin(robot_yaw)
            )

            world_y = robot_y + (
                local_x * math.sin(robot_yaw)
                + local_y * math.cos(robot_yaw)
            )

            # Определяем ближайший маркер.
            marker = self.graph.nearest_marker(
                world_x,
                world_y,
                self.max_marker_distance,
                excluded
            )

            if marker is None:
                continue

            # Голосуем за этот маркер.
            votes[marker] = votes.get(marker, 0) + 1

            if marker not in points:
                points[marker] = []

            points[marker].append(
                (world_x, world_y)
            )

        if not votes:
            return None

        # Маркер с максимальным количеством голосов.
        best_marker = max(
            votes,
            key=votes.get
        )

        self.node.get_logger().info(
            f"obstacle_votes={dict(sorted(votes.items()))}"
        )

        if votes[best_marker] < self.min_votes:
            return None

        # Средняя координата lidar-точек,
        # которые проголосовали за победивший маркер.
        best_points = points[best_marker]

        avg_x = sum(p[0] for p in best_points) / len(best_points)
        avg_y = sum(p[1] for p in best_points) / len(best_points)

        self.node.get_logger().info(
            f"obstacle_world_position≈({avg_x:.3f}, {avg_y:.3f})"
        )

        return best_marker

main.py

И наконец главный файл.

Он объединяет планировщик, контроллер движения и лидар в один эксперимент.

import time

import rclpy
from rclpy.node import Node

from module_b_navigation.graph import Graph
from module_b_navigation.planner import Planner
from module_b_navigation.motion_controller import Motion
from module_b_navigation.obstacle_detector import ObstacleDetector


def wait_robot(node, motion):
    """
    Пока робот едет, даём ROS обрабатывать сообщения.

    spin_once означает:
    "обработай новые сообщения ROS один раз".
    """

    while motion.active and rclpy.ok():
        rclpy.spin_once(
            node,
            timeout_sec=0.1
        )


def wait_for_new_scan(node):
    """
    После того как пользователь поставил препятствие,
    несколько раз обрабатываем ROS-сообщения,
    чтобы точно получить свежий lidar scan.
    """

    for i in range(10):
        rclpy.spin_once(
            node,
            timeout_sec=0.1
        )


def print_route(title, start, target, blocked, route, distance, turns):
    """Красиво печатает найденный маршрут."""

    print()
    print("========================================")
    print(title)
    print("========================================")
    print("Start marker :", start)
    print("Target marker:", target)
    print("Blocked      :", sorted(blocked))
    print()
    print("ROUTE    :", route)
    print("DISTANCE :", distance)
    print("TURNS    :", turns)
    print("========================================")
    print()


def main(args=None):

    # ------------------------------------------------------
    # Запускаем ROS
    # ------------------------------------------------------

    rclpy.init(args=args)

    node = Node("module_b_navigation")

    # ------------------------------------------------------
    # Параметры запуска
    #
    # ros2 run ... --ros-args
    #     -p start_id:=0
    #     -p target_id:=22
    # ------------------------------------------------------

    node.declare_parameter("start_id", 0)
    node.declare_parameter("target_id", 22)

    start = node.get_parameter("start_id").value
    target = node.get_parameter("target_id").value

    # ------------------------------------------------------
    # Создаём основные части программы
    # ------------------------------------------------------

    graph = Graph()
    planner = Planner(graph)
    motion = Motion(node, graph)
    detector = ObstacleDetector(node, graph)

    try:

        # ==================================================
        # 1. СТРОИМ МАРШРУТ ТУДА
        # ==================================================

        blocked = set()

        node.get_logger().info(
            "OUTBOUND_PLANNING_START"
        )

        route, distance, turns = planner.plan(
            start,
            target,
            blocked
        )

        print_route(
            "OUTBOUND ROUTE",
            start,
            target,
            blocked,
            route,
            distance,
            turns
        )

        # ==================================================
        # 2. ЕДЕМ К ЦЕЛИ
        # ==================================================

        node.get_logger().info(
            "OUTBOUND_MOVEMENT_START"
        )

        motion.start(route)

        wait_robot(
            node,
            motion
        )

        node.get_logger().info(
            "OUTBOUND_MOVEMENT_STOP"
        )

        # ==================================================
        # 3. ЗАПОМИНАЕМ ЛИДАР ДО ПРЕПЯТСТВИЯ
        # ==================================================

        if not detector.save_baseline():

            node.get_logger().error(
                "BASELINE_SCAN_NOT_AVAILABLE"
            )

            return

        node.get_logger().info(
            "BASELINE_SCAN_CAPTURED"
        )

        # ==================================================
        # 4. ПОЛЬЗОВАТЕЛЬ СТАВИТ ПРЕПЯТСТВИЕ
        # ==================================================

        print()
        print("========================================")
        print("РОБОТ ОСТАНОВИЛСЯ В ЦЕЛЕВОЙ ТОЧКЕ")
        print("========================================")
        print("Поставьте ОДНО препятствие в Webots.")
        print("После этого введите y и нажмите Enter.")
        print("========================================")

        while True:

            answer = input(
                "Препятствие установлено? [y]: "
            )

            if answer.lower().strip() == "y":
                break

        # ==================================================
        # 5. ПОЛУЧАЕМ СВЕЖИЙ ЛИДАР
        # ==================================================

        wait_for_new_scan(node)

        # ==================================================
        # 6. ИЩЕМ ЗАНЯТУЮ КЛЕТКУ
        # ==================================================

        node.get_logger().info(
            "OBSTACLE_SCAN_START"
        )

        blocked_marker = detector.find_obstacle(
            motion.x,
            motion.y,
            motion.yaw,
            excluded={start, target}
        )

        if blocked_marker is None:

            print()
            print("Препятствие не найдено.")
            print()

            return

        print()
        print("========================================")
        print(
            "OBSTACLE DETECTED ON MARKER",
            blocked_marker
        )
        print("========================================")
        print()

        # Теперь эта клетка запрещена для планировщика.
        blocked = {blocked_marker}

        # ==================================================
        # 7. СТРОИМ ОБРАТНЫЙ МАРШРУТ
        # ==================================================

        node.get_logger().info(
            "RETURN_PLANNING_START"
        )

        return_route, distance, turns = planner.plan(
            target,
            start,
            blocked
        )

        print_route(
            "RETURN ROUTE",
            target,
            start,
            blocked,
            return_route,
            distance,
            turns
        )

        # ==================================================
        # 8. ЕДЕМ ОБРАТНО
        # ==================================================

        node.get_logger().info(
            "RETURN_MOVEMENT_START"
        )

        motion.start(return_route)

        wait_robot(
            node,
            motion
        )

        node.get_logger().info(
            "RETURN_MOVEMENT_STOP"
        )

        node.get_logger().info(
            "MODULE_B_DONE"
        )

        print()
        print("========================================")
        print("MODULE B COMPLETE")
        print("Robot returned to the start marker.")
        print("========================================")
        print()

    except KeyboardInterrupt:
        pass

    finally:

        # На всякий случай всегда останавливаем робот.
        motion.stop()

        node.destroy_node()
        rclpy.shutdown()


if __name__ == "__main__":
    main()

Что происходит после запуска

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

робот для сбора клубники          ↓     START = 0          ↓         BFS          ↓   маршрут к растениям          ↓       движение          ↓     TARGET = 22          ↓   сохранение LaserScan          ↓  появление препятствия          ↓ сравнение двух сканов          ↓
определение занятой клетки          ↓ blocked = {marker}          ↓     повторный BFS          ↓   обход препятствия          ↓
возвращение к START

Конечно, это пока только навигационная часть будущего робота-сборщика. Здесь ещё нет распознавания ягод, определения спелости и управления манипулятором.

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

Следующим этапом эту систему можно связать с техническим зрением и манипулятором:

НАВИГАЦИЯ     ↓
приехали к растениям     ↓
ТЕХНИЧЕСКОЕ ЗРЕНИЕ     ↓
нашли спелую клубнику     ↓
получили координаты ягоды     ↓
МАНИПУЛЯТОР     ↓
сорвали ягоду     ↓
НАВИГАЦИЯ     ↓
следующая рабочая позиция

Таким образом, приведённый пример является первым самостоятельным модулем более крупного проекта — мобильного роботизированного комплекса для автоматизированного сбора клубники.

UDP-прокси и протокол QUIC — как утекает реальный IP

Tue, 15 Sep 2026 02:19:15 +0000

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

А какая страшилка при прочих равных будет чуточку страшнее остальных? Та, которая основана на реальных событиях. Вот и в утверждении выше все-таки есть доля правды.

Реальный IP-адрес и правда может утечь.

Один из возможных сценариев — вы купили прокси с поддержкой UDP, но используемый вами антидетект-браузер не умеет корректно работать с UDP-трафиком.

При этом утверждение «нет поддержки UDP, и ваш IP 100% утекает» некорректно. Правильнее сказать так: «нет поддержки UDP — появляется неконтролируемое сетевое поведение».

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

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

При использовании отдельного сетевого маршрута и возникает риск утечки реального адреса, когда часть трафика может пойти другим путем и потенциально раскрыть ваш реальный IP-адрес.

Привет! Я Александр, пишу для антидетект-браузера Aurorium и по совместительству являюсь специалистом в вопросах автоматизации и парсинга. В этом материале мы рассмотрим, что такое UDP-прокси, чем протокол UDP отличается от TCP и как ваш реальный IP-адрес может утечь, если антидетект-браузер не умеет работать с UDP. По традиции сварите себе чашечку кофе или заварите чай, приготовьте пару бутербродов — мы начинаем!

Что такое UDP-прокси?

Что такое прокси-сервер, знают уже даже наши родители и родители наших родителей — это посредник между вашим устройством и целевым сайтом.

Исторически так сложилось, что большинство базовых прокси (HTTP/HTTPS) умеют маршрутизировать только TCP-трафик, и на этом уровне они отлично справляются с загрузкой текстовых данных, HTML-кода или картинок.

Но такие прокси не подходят для решения специфических задач — стриминга, звонков, онлайн-игр или работы современных сетевых протоколов (где как раз и используется протокол UDP). Прокси, поддерживающие TCP-трафик, физически не умеют передавать такие пакеты.

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

И вот тут возникает второй закономерный вопрос: зачем вообще браузеру нужен UDP и откуда берется этот отдельный сетевой маршрут? И не проще ли просто модернизировать (как-то докрутить) и использовать TCP вообще для любых подключений?

Давайте разбираться!

Зачем браузеру нужен UDP?

Итак, где именно поддержка UDP становится важна для браузера и, соответственно, для антидетект-браузера?

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

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

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

Самый очевидный пример — протокол HTTP/3. В отличие от HTTP/1.1 и HTTP/2, он работает не поверх TCP, а поверх протокола QUIC. А QUIC, в свою очередь, использует UDP.

Выглядит это так:

HTTP/1.1 → TCP
HTTP/2   → TCP
HTTP/3   → QUIC → UDP

HTTP/3 — это новая версия HTTP, как и HTTP/1.1 или HTTP/2, но с другим транспортом. Это не «ускоренный UDP», а HTTP, работающий поверх протокола QUIC.

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

HTTP/3 → QUIC → UDP → IP.

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

HTTP/3 не единственный пример; есть еще более опасный (с точки зрения утечек IP-адреса) — WebRTC. Когда сайт устанавливает голосовое или видеосоединение, браузер использует ICE для поиска подходящего сетевого пути. В этом процессе может использоваться UDP-соединение со STUN/TURN-серверами.

ICE (Interactive Connectivity Establishment) — механизм поиска и выбора подходящего сетевого пути между участниками WebRTC. В процессе ICE браузер собирает и проверяет различные варианты соединения, в том числе адреса, полученные через STUN, и relay-адреса TURN.

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

Может возникнуть такая ситуация, что весь трафик будет идти через прокси, а UDP пойдет через ваш реальный IP-адрес.

TCP против UDP, а может просто заменить один на другой?

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

TCP отвечает за надежную и упорядоченную передачу данных. В процессе работы происходит:

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

Поверх TCP-протокола все время строилась и продолжает строиться большая часть привычного веб-трафика.

UDP устроен иначе. Он не устанавливает соединение, как это делает TCP, не гарантирует доставку каждой отдельной датаграммы и не контролирует порядок их получения.

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

Именно так и работает QUIC.

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

Получается что QUIC — это TCP на максималках, построенный поверх UDP. Так это выглядит, да, но у него уже нет тех ограничений, которые присущи TCP.

Для большей наглядности сравним два протокола по отношению друг к другу в таблице:

Параметр	TCP	UDP
Установка соединения	Да	Нет
Доставка данных	Надежная	Не гарантируется
Порядок	Обеспечивает упорядоченную доставку	Нет
Повторная передача	Реализована	Не предусмотрена
Тип данных	Поток байтов	Датаграммы

Почему QUIC — это не тоже самое, что и TCP-протокол и чем он опасен для прокси?

QUIC проектировался так, чтобы взять все лучшее от TCP (надежность), но убрать его ограничения. Вот что получил QUIC:

0-RTT — QUIC объединяет транспортное и криптографическое рукопожатие. При повторном подключении к сайту браузер начинает передавать данные почти мгновенно.
Независимые потоки — в TCP потеря одного пакета (например, куска CSS) блокирует загрузку всего остального (HTML, скриптов). В QUIC потоки независимы: потеряли картинку — остальной сайт продолжает грузиться.
Миграция соединения — в TCP-протоколе сессия привязана к IP-адресу. Переключились с Wi-Fi на LTE — соединение оборвется. В QUIC сессия привязана к Connection ID. Вы можете менять сети, а условное видео на YouTube продолжит воспроизводиться без потери качества и переподключения.

Способность QUIC «выживать» при смене сетей и восстанавливать сессии означает, что протокол умеет переживать изменение сетевого пути. Если ваше соединение с прокси на секунду моргнет, браузер (в рамках миграции соединения QUIC) может попытаться восстановить сессию напрямую через ваш реальный сетевой интерфейс, в обход отвалившегося прокси. Если антидетект не контролирует сетевой слой, ваш реальный IP-адрес улетит серверу, а значит, и антифрод сможет его увидеть.

WebRTC — где появляется риск утечки IP

Если прокси умеет работать только с TCP, браузер не сможет провести через него QUIC-трафик привычным способом. HTTP/3 в такой ситуации просто не поднимется, а браузер продолжит работу через HTTP/2.

Вроде ничего критичного, откатился и откатился, что бубнить-то? Но если смотреть с точки зрения антифрода, тут есть за что зацепиться.

Когда сайт поддерживает протокол HTTP/3 (а у серверов Google и Meta он стоит по умолчанию), обычный пользователь с прямым интернет-подключением зайдет на него именно по QUIC (UDP). Если же браузер из-за настроенного прокси не справляется с UDP и внезапно откатывается на устаревший протокол поверх TCP — антифрод видит сетевую аномалию и, скорее всего, ваш Fraud Score станет хуже.

С WebRTC ситуация интереснее.

Представим обычный профиль созданный в антидетект-браузере, с установленным прокси:

Реальный IP:
91.xxx.xxx.xxx
IP прокси:
185.xxx.xxx.xxx

При открытии сайта он увидит не ваш IP, а адрес прокси:

Браузер
  ↓
Прокси
  ↓
 Сайт
Сайт видит:
185.xxx.xxx.xxx

С точки зрения пользователя все логично и максимально защищено — реальный IP скрыт. С точки зрения сайта, кстати, тоже.

Усложняем ситуацию и добавляем новую вводную — на странице используется WebRTC.

Что делает WebRTC

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

Для этого используется ICE.

С помощью ICE браузер собирает возможные комбинации IP-адресов и портов, через которые можно установить соединение. Среди них может быть и ваш реальный IP-адрес.

Условно:

ICE
 ├── локальный адрес
 ├── публичный адрес через STUN
 └── адрес relay через TURN

Затем ICE проверяет доступные варианты и выбирает рабочую пару адресов. В базовом варианте ICE для таких проверок используется UDP.

Где здесь появляется прокси

А теперь возвращаемся к антидетекту.

Если ваш антидетект-браузер умеет проксировать только HTTP/TCP, он физически не может контролировать UDP-трафик, который использует WebRTC.

В результате браузер разделяет трафик на два независимых маршрута:

1. Обычный HTTPS-трафик (идет через прокси):

Браузер
   ↓ TCP
Прокси
   ↓
Сайт
(Сайт видит IP прокси: 185.xxx.xxx.xxx)

2. WebRTC-трафик (идет в обход прокси):

WebRTC:
Браузер
 ↓ UDP
Сетевой интерфейс
  ↓
STUN / WebRTC

И это может привести к такой картине, где возникает потенциальная утечка реального IP-адреса:

HTTP:
185.xxx.xxx.xxx  ← IP прокси
WebRTC:
(Сайт видит ваш реальный домашний IP: 91.xxx.xxx.xxx)

И вот ваш реальный IP-адрес утек. Мало того, что сайт видит две разные сетевые идентичности в рамках одного профиля, так еще и антифрод замечает использование прокси и блокирует (или ограничивает) аккаунт. Но и это не всё. Если у вас несколько аккаунтов и все они будут связаны по вашему реальному IP-адресу в сеть, вы оказываетесь в той точке, где ситуация перестает быть томной.

Вот как выглядит утечка

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

Когда у тебя 80 профилей под фарминг, и в каждом WebRTC показывает один и тот же адрес твоего роутера

Фейковая галочка vs Реальная маршрутизация

Проблема рынка в том, что многие расширения и базовые антидетект-браузеры указывают, что поддерживают UDP, хотя на деле просто принудительно отключают WebRTC в браузере или откатываются на HTTP/2 при встрече с HTTP/3 (для пользователя это же вообще незаметно).

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

Чтобы WebRTC-кандидаты не смогли «нащупать» ваш реальный Wi-Fi или Ethernet, антидетект-браузер должен использовать виртуальный сетевой интерфейс (TUN-режим) или глубокий перехват сокетов. В таком сценарии весь трафик системы (и TCP, и UDP) принудительно заворачивается в туннель. ICE-кандидаты просто не видят вашего реального железа — для них существует только туннель к вашему прокси (который, конечно же, тоже должен поддерживать UDP, например, SOCKS5).

И здесь мы сталкиваемся с главной проблемой рынка прокси — дефицитом и дороговизной решений с реальной поддержкой UDP-протокола. Большинство поставщиков либо вообще не поддерживают UDP, либо продают такие прокси по завышенным тарифам. Но даже если вы нашли провайдера с честным UDP, появляется проблема: движок Chromium «из коробки» умеет работать с UDP напрямую, но не умеет его проксировать через стандартный SOCKS5. Без глубокой проработки движка любой базовый антидетект-браузер будет отправлять через SOCKS5 обычный TCP-трафик.

Как мы решили эту проблему в Aurorium Browser

Мы переработали сетевой стек и добавили честную поддержку UDP-протокола. Наша архитектура имеет нативную поддержку UDP-протокола. Если ваш прокси изначально умеет передавать UDP-пакеты, Aurorium автоматически распознает протокол и направляет QUIC и WebRTC-трафик напрямую через прокси без потерь.

В результате целевой сайт видит естественное поведение: сессии поднимаются по HTTP/3 (QUIC), WebRTC отрабатывает без ошибок, а ваш реальный IP не утекает и остается скрыт за туннелем.

Как проверить свой антидетект-браузер прямо сейчас:

Включите ваш рабочий профиль с прокси.
Если хотите проверить QUIC, перейдите на страницу — https://browserleaks.com/quic, для тестирования UDP — https://networktest.twilio.com/.

Если QUIC поддерживается вы увидите примерно такую картину.

Если QUIC не поддерживается, то такую:

Когда проверяете UDP то видите примерно такую картину, если UDP поддерживается

Проксируйте трафик с умом и проверяйте инструменты, которыми пользуетесь.

Найм умирает. Может, теперь делать свой продукт не такая уж плохая идея?

vital_pavlenko — Mon, 14 Sep 2026 23:38:35 +0000

Комментарию к видео @fillpackart

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

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

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

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

Средний этаж исчезает

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

Сейчас этот этаж начинает исчезать.

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

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

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

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

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

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

Два пути внутри компании

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

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

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

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

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

Пока общепринятых паттернов здесь почти нет. Каждая компания собирает свою систему из отдельных инструментов и собственных правил. Но когда-то так же было с CI/CD, мониторингом и релизными процессами. Со временем появились стандартные подходы. Скорее всего, появится и отдельная роль, условный AI Ops, который будет отвечать за всю эту систему.

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

Работы стало больше, но ценности в ней чувствуешь меньше

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

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

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

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

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

Только стабильность в этом сравнении была аксиомой. Сейчас она перестала ею быть.

Риски найма и своего продукта сближаются

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

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

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

Это график поступлений за все время существования приложения

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

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

Я не знаю, насколько далеко получится дойти с этим приложением. $600 могут превратиться в $6k или больше, вопрос времени. Главное, что теперь здесь хотя бы появился измеримый результат и какие-то работающие пути продвижения, которые можно просто усиливать и повторять.

В своем проекте часы перестают равняться деньгам

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

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

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

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

Когда делаешь продукт сам, невозможно сказать: "Этим должен заниматься другой отдел". Другого отдела нет. Если приложение не покупают, недостаточно написать хороший код и считать свою часть работы выполненной. Приходится разбираться, почему люди не доходят до оплаты, что они не понимают, где уходят и как вообще рассказать им о продукте.

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

Придется научиться долго выглядеть глупо

У собственного проекта есть неприятная особенность: окружающие постоянно объясняют тебе, почему он никому не нужен.

Я уже не могу посчитать, сколько раз слышал вопрос: "Зачем ты делаешь это приложение, если уже есть [подставь любое похожее]?" Мне говорили, что это копия одного продукта, потом копия второго, потом копия третьего. Писали, что идея банальная, рынок переполнен, а реализованная функция никому не нужна.

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

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

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

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

Так свой продукт все еще рискованнее найма или уже нет?

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

Но само соотношение рисков изменилось.

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

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

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

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

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

Это, конечно, не гарантия. Можно даже сказать, что это просто диверсификация рисков, если делать все параллельно.

Cимулируем жизнь 30 млн микробов в браузере

KogerCoder — Mon, 14 Sep 2026 22:17:27 +0000

WebGPU даёт прямой доступ к современным возможностям видеокарты: не только к рендерингу, но и к вычислениям общего назначения через compute shaders.

Но насколько далеко это можно довести в обычном браузере? Что произойдёт, если вычисления — это полноценная симуляция с десятками миллионов объектов? Разберемся в этой статье.

Предыстория

Для эксперимента попробуем воскресить симулятор эволюции, написанный много лет назад, и переписать его логику с CPU на GPU. Подробней об этом проекте я рассказывал в другой статье, но читать её необязательно — важные моменты я перескажу.

Мой клеточный симулятор был написан на C# и устроен вполне естественно: двумерная матрица объектов, отдельный список живых клеток и foreach, который на каждом тике вызывал их логику. Клетка смотрела по сторонам, выбирала действие и сразу меняла общий мир. Этого хватало, чтобы на экране возникали популяции, которые борются между собой и эволюционируют.

Веб-версия того симулятора позволяла создавать миры максимум 200 × 200. Попробуем поднять планку до 8192 × 4096. Это около 33 млн ячеек, каждая из которых потенциально может быть занята живой клеткой.

Сначала разберёмся с памятью

Если на каждую из 33 млн позиций выделить всего одно 32-битное число, получится уже 128 MiB. А одного числа недостаточно: нужно где-то хранить возраст клетки, вид, энергию, индивидуальные признаки и ещё промежуточные данные, необходимые во время расчёта следующего состояния мира.

На CPU всё это удобно собрать в один объект типа Cell. Но на таком масштабе привычный ООП-подход становится довольно дорогим. Добавили к каждой позиции ещё одно поле размером 4 байта — потенциально получили ещё 128 MiB..

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

Организация памяти

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

От последовательного тика к параллельному

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

То есть порядок обхода незаметно становился частью правил симуляции.

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

Поэтому теперь один тик разбит на несколько последовательных стадий.

Сначала клетки только принимают решения и записывают свои Intent — что именно они хотят сделать. При этом само состояние мира ещё не меняется.

Затем появляются Claim — заявки на то, за что клетки конкурируют. Если несколько клеток претендуют на одну позицию, конфликт разрешается отдельно по заранее определённому правилу.

И только после разрешения конфликтов начинается стадия Apply, которая действительно изменяет состояние мира.

Порядок вычислений

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

Как показать 33 млн ячеек

К этому моменту мир уже живёт и изменяется на GPU. И тут возникает довольно естественный вопрос: зачем вообще возвращать его на CPU только ради картинки?

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

По этой причине полной CPU-копии мира в новой версии нет. Рендеринг читает необходимые данные прямо из GPU-буферов, а JavaScript в основном занимается интерфейсом, камерой и отправкой команд.

Симуляция на крупном масштабе

При сильном отдалении возникает другая проблема: отдельная клетка становится меньше одного пикселя. Рисовать её как самостоятельный объект уже бессмысленно.

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

Что получилось

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

Даже в таком режиме на моём компьютере симуляция просчитывает примерно 5–10 полных тиков в секунду.

Конечно, 5–10 тиков/с — не универсальная характеристика WebGPU. Скорость зависит от видеокарты, браузера, настроек симуляции и количества живых клеток. Но для меня важнее сам принцип: симуляция на десятках миллионов активных объектов оказывается вполне работоспособной прямо в обычной вкладке браузера.

Итоги

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

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

Если хочется посмотреть на симуляцию вживую, текущая версия доступна здесь: The Strongest Survives на itch.io.

Что за зверь «internal OpenAI model» и почему DeepSeek догоняет OpenAI?

a_mongush — Mon, 14 Sep 2026 21:31:53 +0000

Публике не доступны внутренние модели фронтиер лабораторий. Я не очень верю про конспирологию в духе «у OpenAI в подвале сидит настоящий AGI, а наружу выдают обрезанный ChatGPT». Модель, которой пользуются её собственные исследователи, и модель, которую она продает вам через API, не обязаны быть одной и той же. Фронтиер лаба создает не одну нейросеть, а фабрику моделей: research-чекпоинты > экспериментальные модели > reward-модели > модели-учителя > модели для генерации синтетических данных > модели-evaluators > дистиллированные студенты > production-модели, и наружу попадает только последний элемент цепочки.

Зачем нужна дистилляция

Допустим, вы обучили чудовищно дорогую модель, которая хорошо рассуждает, пишет код и решает математику, но каждый запрос к ней стоит огромных вычислений. Для исследователя внутри компании это рабочий инструмент, и он того стоит, если на кону триллионные рынки. Для продукта со 100 млн пользователей масштабировать доступ к таким моделям выгодно, поэтому вместо того чтобы гонять её на каждом запросе, её делают учителем: она генерирует качественные ответы, решения, траектории ризонинга, синтетические данные, иногда сами распределения вероятностей, а на этом поведении обучается студент поменьше, которому не нужно воспроизводить учителя целиком, достаточно перенести нужные возможности. Это одна из форм дистилляции знаний, и практика настолько распространенная, что OpenAI прямо предоставляет разработчикам официальный Model Distillation workflow: брать ответы более сильной модели, например GPT-4o или o1-preview, и обучать на них модель дешевле. Формулировка самой OpenAI довольно точная: взять продвинутую модель и получить сопоставимое качество на конкретной задаче при существенно меньшей стоимости. Из этого следует довольно простая вещь: лучшая research-модель и лучшая production-модель оптимизируются по разным функциям, потому что research-модель максимизирует возможности, а production-модель приходится одновременно вытягивать по intelligence, latency, стоимости GPU, throughput, reliability и safety.

Публичных примеров такой схемы за последние два года накопилось довольно много. Apple описывала внутреннего Mixture-of-Experts учителя, которого использовала при обучении своей небольшой on-device foundation model. Google обучала EmbeddingGemma с помощью более мощного учителя Gemini. Meta использовала логиты Llama 3.1 8B и 70B при создании маленьких Llama 3.2 1B и 3B. Microsoft прямо писала, что ранние Phi в значительной степени дистиллировали возможности GPT-4. DeepSeek после обучения R1 выпустила линейку дистиллированных моделей от 1.5B до 70B. Схема «сильный учитель > дешёвый студент» реальна и хорошо задокументирована.

Чего отсюда не следует

Здесь будто бы следует неправильный вывод: якобы любая публичная модель является урезанной версией секретной супермодели. Иногда учитель вообще публичный, Meta использовала публичные Llama 3.1, DeepSeek выложила и большую R1, и дистиллированные из нее модели, причём студент иногда обходит своего учителя на конкретном бенче или узкой задаче за счет специализации и пост-трейнинга. То есть не совсем верно утверждать, что весь open source является специально ухудшенной дистилляцией секретных моделей. А вот более слабое утверждение подтверждается вполне: публичный каталог моделей почти наверняка не показывает весь фронтиер возможностей конкретной лаборатории.

«An internal model at OpenAI»

В 2026 году в математических статьях начала регулярно появляться очень необычная формулировка. 31 марта группа математиков опубликовала работу с решениями трёх задач Эрдёша, где в abstract прямо написано: “in each case, the proof is due entirely to an internal model at OpenAI.” Это не единичный случай: в феврале внутренняя модель OpenAI построила новое решение задачи Эрдёша, Нешетрила и Рёдля, в апреле вышла ещё одна работа с пятью доказательствами, полученными таким же образом, а затем внутренняя модель OpenAI нашла контрпример к гипотезе Эрдёша о unit distances, открытой около восьмидесяти лет, и доказательство проверили внешние математики. В сопутствующей статье указано, что первоначальный математический результат был сгенерирован в один проход внутренней моделью, после чего люди переработали изложение через Codex. W. T. Gowers написал, что если бы такое доказательство прислал человек, он без колебаний рекомендовал бы его к публикации в Annals of Mathematics. Mehtaab Sawhney в Twitter сформулировал это ровно так: “the solution was found by an internal model at OpenAI”, а Kevin Weil, тогда один из руководителей OpenAI, репостнул с комментарием, что AI решает всё больше открытых задач и доказательства становятся элегантнее по мере улучшения моделей. То есть существование моделей, которыми компания пользуется внутри задолго до публичного релиза, здесь уже не спекуляция, оно написано в математических статьях.

При этом несколько месяцев спустя Noam Brown из OpenAI рассказывал эту историю иначе, чем ее обычно пересказывают: компания просто обучила новую внутреннюю модель и решила посмотреть, что она умеет, контрпример нашёлся при относительно небольшом бюджете на инференс, но после публикации люди обнаружили, что примерно тот же путь вытаскивается и из уже публичной GPT-5.5, если правильно построить scaffolding. Значит, между «внутренняя модель умеет это» и «публичная модель не умеет этого» жёсткой границы может не быть вовсе: возможность уже находится внутри публичных весов, но остается латентной, пока не подобран правильный prompt, search strategy, верифайер или test-time compute. Отсюда следует, что «насколько умна модель» перестает быть свойством одних только весов и становится свойством связки модель + scaffolding + инструменты + бюджет на инференс + верифайер + search strategy + пост-трейнинг, а обычный чат-интерфейс оказывается довольно плохим прибором для измерения реального фронтиера возможностей.

Что тогда с Astra

С Astra получился почти естественный эксперимент. До публичного релиза OpenAI уже использовала очень сильные внутренние модели в research, а 3 сентября 2026 года выпустила GPT-6 Astra и назвала её the most capable broadly deployed model: 98% на FrontierMath Tier 4 и, по заявлению компании, участие в решении давних математических задач. Вполне возможно, что то, что несколько месяцев назад в статье называлось просто внутренней моделью, относится к той же технологической линии, которая позже стала Astra. Но это мой вывод по косвенным признакам: OpenAI не раскрыла происхождение этих чекпойнтов настолько подробно, чтобы можно было честно провести стрелку от конкретной внутренней математической модели к Astra. Тем более из этого не следует, что где-то внутри уже существует модель на поколение сильнее Astra. Это вполне возможно, но доказательств этого пока нет.

Обратная сторона дистилляции или феномен DeepSeek

Вы потратили миллиарды на вычисления, исследователей, RL, синтетические данные и eval infrastructure, а конкуренту для воспроизведения заметной части результата достаточно вытянуть несколько миллионов качественных ответов вашей модели через API. Ему не нужны ваши веса и необязательно понимать вашу архитектуру, он использует вашу модель как учителя, генерирует миллионы заданий, собирает ответы, фильтрует лучшие траектории ризонинга, обучает свою модель, потом использует вашу же модель как судью и повторяет цикл. Экономика получается перекошенная: вы платите за создание intelligence, конкурент платит за API-токены, чтобы этот intelligence перенести.

Ещё в 2025 году OpenAI заявляла, что обнаружила признаки использования её моделей для дистилляции. В феврале 2026 года Anthropic опубликовала намного более конкретные данные: по её утверждению, DeepSeek, Moonshot и MiniMax вели против Claude дистилляционные кампании промышленного масштаба, более 24 000 фродовых аккаунтов и более 16 миллионов exchanges, и извлекались не случайные ответы, а дорогие кластеры возможностей: coding, reasoning, tool use, agents, grading, computer use. В Twitter Anthropic написала почти теми же словами: “16 million exchanges with Claude, extracting its capabilities to train and improve their own models.” Термин knowledge extraction здесь точнее, чем model stealing, потому что копировать веса никто не обязан, достаточно скопировать полезную функцию.

Отсюда возникает неудобная конструкция: фронтиер лабы сами постоянно используют дистилляцию, потому что это лучший известный способ сделать дорогой intelligence дешёвым, и одновременно стараются не дать дистиллировать себя. На техническом уровне это не лицемерие, разница в том, кто владеет учителем и имеет ли право использовать его ответы для обучения конкурента, но с точки зрения самой технологии происходит одно и то же: сильная модель производит supervision, на котором становится сильнее другая модель. Поэтому API перестал быть просто интерфейсом к продукту и стал каналом утечки возможностей, и чем больше вы отдаёте наружу (сырые логиты, пути ризонинга, оценки судьи, миллионы unrestricted-запросов), тем дешевле конкуренту построить студента. Ограничения API, rate limits, скрытые chain-of-thought, мониторинг координированных аккаунтов и запреты на competitive model training в лицензиях получают вполне понятную экономическую причину. Clément Delangue, CEO Hugging Face, в этом году писал, что его не удивит сценарий, где фронтиер лабы начнут сильнее ограничивать API и направят дефицитные вычисления прежде всего на собственные продукты.

Что из этого следует

Мы привыкли читать названия GPT, Claude, Gemini, Llama как отдельные законченные сущности: компания обучила GPT-6, значит GPT-6 и есть её intelligence. Реальности это соответствует всё хуже, потому что лаборатория выглядит скорее как непрерывный конвейер интеллекта: огромные training runs > чекпойнты > reinforcement learning > синтетические данные > учителя > критики > верифайеры > дистилляция > tool scaffolding > test-time compute > production deployment, а название модели, которое видит пользователь, это одна точка на этом конвейере, выбранная по соображениям стоимости и риска.

Поэтому формулировка вопроса «какая сегодня самая умная модель» не очень удачная. Содержательные вопросы другие: какой максимум возможностей уже существует внутри лаборатории, какая его часть есть в research-чекпойнтах, какая уже скрыта в публичных весах и ждёт нормального scaffolding, какую часть удалось дёшево дистиллировать в production. И главный: насколько далеко реальный фронтиер ушёл вперёд от того, что видит человек, открывающий новый чат — лидерборд публичных моделей не является показателем возможностей AI.

Больше полезного контента в моем тг‑канале: t.me/airamongush

Как я перенёс 7 000 треков из Яндекс Музыки в Spotify, хотя у одного нет API, а другой урезал квоту

23RIRI — Mon, 14 Sep 2026 20:43:46 +0000

Понадобилось переехать с Яндекс Музыки на Spotify вместе с библиотекой: 7 000 лайков, сотня плейлистов, альбомы, подписки на артистов. Казалось, задача на десять минут — сервисов переноса полно. Оказалось, что все они держатся на честном слове, а у Spotify с 2025 года такие ограничения для приложений, что «просто взять API» не получится. В итоге взял открытый скрипт с GitHub, переписал в нём половину и по дороге разобрался, как устроены лимиты обоих сервисов. Делюсь разбором и кодом.

Почему не работают готовые сервисы

У Яндекс Музыки нет открытого API. Зарегистрировать OAuth-приложение со scope на музыку невозможно — Яндекс такого не выдаёт. Поэтому каждый сервис-посредник делает одно из двух:

Просит логин и пароль от Яндекс ID и логинится за вас с своих серверов. Так работают TuneMyMusic, Soundiiz, MusConv. С двухфакторкой или входом по QR это не проходит, а у Soundiiz в саппорте прямо написано: «Yandex does not provide an official API, the workaround doesn’t work for all users». На Trustpilot есть отзывы, где после переноса приходило письмо от Яндекса о подозрительном входе из Северной Каролины.
Парсит публичную страницу плейлиста — так делают телеграм-боты вроде YMusicExport. Работает только для открытых плейлистов, «Мне нравится» так не вытащить, и боты регулярно ловят баны.

Плюс лимиты бесплатных версий: 200–600 треков, дальше платно и только иностранной картой.

Есть третий путь, которым пользуется библиотека yandex-music-api: OAuth-токен самого приложения Яндекс Музыки. Открываете oauth.yandex.ru/authorize?response_type=token&client_id=23cabbbdc6cd418abb4b39c32c41195d, логинитесь как обычно — и получаете в адресной строке токен с годовым сроком жизни. client_id здесь — публичный идентификатор официального клиента, не секрет. Пароль никуда не уходит, токен отзывается в Яндекс ID. С этим токеном библиотека отдаёт лайки, плейлисты, альбомы и артистов с полными метаданными, включая duration_ms — это пригодится.

Что изменилось у Spotify

Со Spotify ситуация обратная: API официальный и хорошо документированный, но в 2025 году Spotify резко закрутил гайки для сторонних приложений.

Любое новое приложение стартует в Development mode. Из документации:

максимум 5 авторизованных пользователей, каждого нужно вручную добавить в allowlist;
владелец приложения обязан иметь Premium;
есть квота запросов на аккаунт разработчика — при превышении API отдаёт 429 с "reason": "QUOTA_EXCEEDED" и Retry-After в сутки.

Выйти из Development mode в Extended quota mode с 15 мая 2025 могут только юрлица с действующим продуктом и минимум 250 000 MAU. Для pet-проекта это закрытая дверь. Практический вывод: любой «сервис переноса в Spotify», который вы можете написать, по правилам обслужит пять человек — включая вас. Единственная легальная схема — каждый пользователь создаёт своё приложение и работает под своей квотой.

Квота на практике — примерно 700 треков в сутки: каждый трек это один запрос search, плюс один запрос на сохранение пачки. Уперлись — ждите 24 часа.

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

Скрипт: что было и что стало

Основа — MarshalX/yandex2spotify, простой скрипт 2020 года: взять лайки из Яндекса, для каждого сделать search в Spotify, взять первый результат, сохранить. Для библиотеки в 200 треков — прекрасно. Для 7 000 — четыре проблемы.

1. Rate limit: почему нельзя отдавать 429 на откуп urllib3

Spotipy умеет ретраить через urllib3.Retry, и по умолчанию 429 в списке status_forcelist. Звучит удобно, но на суточной блокировке это катастрофа: urllib3 отретраит с экспоненциальным бэкоффом, исчерпает попытки и бросит исключение, в котором уже нет заголовка Retry-After — понять, сколько ждать, невозможно.

Поэтому 429 исключён из forcelist намеренно, а обработка вынесена в декоратор:

# 429 исключён: пусть urllib3 его НЕ перехватывает, иначе spotipy отдаёт
# исключение без Retry-After. 5xx по-прежнему ретраятся штатно.
RETRY_STATUS_FORCELIST = (500, 502, 503, 504)
MAX_RATE_LIMIT_WAIT = 300

def handle_spotify_exception(func):
    def wrapper(*args, **kwargs):
        while True:
            try:
                return func(*args, **kwargs)
            except SpotifyException as exception:
                if exception.http_status != 429:
                    raise
                headers = exception.headers or {}
                raw = headers.get('retry-after') or headers.get('Retry-After')
                if raw is None:
                    raise RateLimitExceeded(None)   # длительность неизвестна — не крутимся вслепую
                retry_after = int(float(raw))
                if retry_after > MAX_RATE_LIMIT_WAIT:
                    raise RateLimitExceeded(retry_after)   # суточная квота — выходим
                sleep(retry_after + 1)                     # обычный throttling — ждём
    return wrapper

Короткие троттлинги (секунды) скрипт пересиживает сам. Всё, что больше пяти минут, — это квота: скрипт печатает, когда возвращаться, и выходит с кодом 2.

2. Журнал прогресса вместо «запустить заново»

Раз скрипт живёт несколько дней, ему нужна память. Append-only JSONL с fsync после каждой записи — переживает Ctrl+C, падения и выключение ноутбука:

class Progress:
    def mark(self, key, not_found=None):
        if key is None or key in self.done:
            return
        self.done.add(key)
        rec = {'t': 'item', 'k': key}
        if not_found is not None:
            self.not_found[key] = not_found   # название — для итогового отчёта
            rec['nf'] = not_found
        self._append(rec)   # json.dumps + flush + os.fsync

Ключи — like:<id>, pl:<kind>:<id>, album:<id>, artist:<id>. Важная деталь: трек помечается «сделанным» только после того, как Spotify подтвердил запись пачки, а не после успешного поиска. Иначе при падении между поиском и сохранением трек теряется навсегда.

Плейлисты журналируются отдельно (kind → spotify_id), чтобы при повторном запуске не создать дубли, а обложка — ещё отдельнее: если её загрузка упала на 429, при следующем запуске плейлист переиспользуется, а обложка догружается.

Список «не найдено» тоже пишется в журнал с названием трека. Без этого отчёт в конце многодневного переноса показывал бы только последний день — я на это наступил.

3. Матчинг: первый результат поиска — это лотерея

search("Земфира Искала") возвращает десять кандидатов, и первый — не обязательно то, что нужно. Караоке-версии, каверы, live-записи, «Tribute to» — всё это выше оригинала бывает регулярно. Для платного сервиса это жалобы, для себя — мусор в библиотеке.

Яндекс отдаёт duration_ms, Spotify — тоже. Длительность — сигнал, независимый от языка написания артиста («Земфира» у Яндекса и «Zemfira» у Spotify — обычная история). Плюс сверка имени артиста, плюс название как tie-breaker:

def pick_match(item, candidates):
    best_id, best_score = None, 0
    for cand in candidates:
        score = 0
        if abs(cand['duration_ms'] - item.duration_ms) <= 3000:   # ±3 с
            score += 2
        if _names_overlap(item.artists, cand['artists']):
            score += 2
        if label_key(item.title) == label_key(cand['name']):
            score += 1
        if score > best_score:
            best_id, best_score = cand['id'], score
    return best_id if best_score >= 2 else None

Одного совпадения названия недостаточно (у караоке-версии оно такое же), а длительности или артиста — достаточно. Для альбомов вместо длительности — число треков: total_tracks у Spotify против track_count у Яндекса, это отсекает deluxe-издания и трибьюты. Ничего не набрало два балла — честно в «не найдено», а не первое попавшееся.

Отдельная ловушка в _names_overlap: сравнение подстрокой нужно для случаев вида KINO (Кино), но артист с именем «Ю» совпадёт с любой Юлией. Подстрока — только от трёх символов.

На моей библиотеке после этого не нашлось меньше процента треков — мелкие лейблы и VK-релизы, которых в Spotify просто нет.

4. Тихая потеря данных

В оригинале любая ошибка Spotify при обработке трека ловилась одним except SpotifyException и трек помечался обработанным. То есть 502 после исчерпания ретраев, 400 на кривом запросе или 403 «пользователь не в allowlist» — и трек навсегда считался перенесённым. Ни в отчёте, ни в Spotify.

Теперь транзиентные ошибки не помечают трек — он попадёт в следующий запуск. А 401/403 — это не проблема трека, а проблема авторизации: скрипт прерывает прогон сразу вместо того, чтобы 7 000 раз написать «NO».

Там же нашлась ещё одна: если запрос сохранения пачки падал, буфер не очищался, и каждый следующий трек снова дёргал падающий save с растущей пачкой. Для альбомов, где лимит 20 id на запрос, это гарантированный 400 навсегда. Упавшая пачка теперь сбрасывается целиком без отметки — и повторяется на следующий день.

Кстати о лимитах на запрос: у Spotify они разные по эндпоинтам — 50 id для сохранения треков, 20 для альбомов, 50 для подписок, 100 для добавления в плейлист. Один общий --chunk на всё в оригинале ломал импорт альбомов на 21-м.

Тесты

Весь матчинг и обработка ошибок покрыты unittest — 36 тестов на stdlib, без зависимостей. Фейковый Spotify-клиент отдаёт заранее заданные результаты поиска, фейковый Яндекс — треки с нужными duration_ms. Каждый описанный выше баг сначала воспроизведён тестом, потом починен. Например, каскад падающих пачек:

def test_failed_batch_is_dropped_and_later_batches_still_save(self):
    spotify, importer = self.make([SpotifyException(400, -1, 'invalid id')])
    importer.import_likes()
    self.assertEqual(spotify.saved, [['sp1', 'sp0']])           # вторая пачка дошла
    self.assertFalse(importer.progress.is_done('like:3'))       # из первой — не помечены

Как пользоваться

Коротко, подробный гайд — в GUIDE.md репозитория.

Создать приложение в Spotify Dashboard, redirect URI https://open.spotify.com, взять Client ID и Secret. Нужен Premium.
Получить токен Яндекса по ссылке выше.
Запустить:

export SPOTIFY_CLIENT_ID=... SPOTIFY_CLIENT_SECRET=... YANDEX_TOKEN=...
python3 importer.py -u any_name

Через ~700 треков скрипт остановится с точным временем возврата. Та же команда завтра — продолжит. 7 000 треков — десять дней по одному запуску, участия не требуется.

Что не решено

Плейлисты создаются публичными — scope playlist-modify-public; приватные — следующим шагом.
Артисты матчатся по первому результату — там кроме имени сигналов нет, а транслитерация делает точное сравнение бесполезным.
Квота — на аккаунт разработчика, не на приложение. Ускорить перенос нельзя ни вторым приложением, ни параллельными запусками. Только ждать.
Обратный перенос (Spotify → Яндекс) не реализован, у Яндекс Музыки для этого есть встроенный импорт.

Код: github.com/BuevichRoman/yandex2spotify, MIT, форк MarshalX/yandex2spotify. Issues и PR приветствуются — особенно если у кого-то есть идея, как матчить артистов с транслитерацией.

Что можно сделать с массивом массивов

dalerank — Mon, 14 Sep 2026 20:19:00 +0000

На одном из проектов (4Х историческая стратегия) появилась задача убрать часть логики в потоки, отдав им снапшот игрового состояния, чтобы пока основной поток считает свой тик, остальные (AI, поиск пути, UI и др) могли крутить свою логику, вроде "кто стоит в этой локации" и делать это без блокировок или риска увидеть половину чужой записи. Чтобы реализовать такую систему, надо придумать как получить обратный индекс полка по локации, причем сделать поиск дешевым для потоков, т.е. у потока должен быть свой снапшот состояния некоторой части игрового мира на момент старта апдейта (кадра, тика логики, дня, месяца и т.д)

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

struct Regiment {
    unsigned int location;
    float        health;
    float        mood;
    float        speed;
};

std::vector<Regiment> regiments; // все полки мира
std::vector<std::vector<unsigned int>> by_location(location_count);

for (unsigned int r = 0; r < regiment_count; ++r) {
    by_location[regiment_location[r]].push_back(r);
}

... тут мы что-то делаем с полученным массивом

Такая структура (regiments) называется jagged array, массив массивов (зачем она и как с ней работать я показывал в книге Game++), или, если вам ближе академическая терминология, CSR (compressed sparse row) немного другая форма записи таких массивов, либо разреженные матрицы. И такие стуктуры довольно частое явление в играх, если у вас много локаций и вам надо:

узнать какой лут разложен в каждой локации, какие армии принадлежат каждой области;
или какие монстры живут в локации, какие локации входят в область, какие области в регион;
или почекать соседей локации на карте, adjacency region, на чем строится pathfinding и вся заливка областей в глобальных стратегих;
или найти узлы в иерархии сцены или в скелете;
поискать сущности по чанку мира, компоненты по сущности, entity по архетипу в ECS;
найти подписчиков по типу события, активные модификаторы по объекту
походить по соседям локации и пособирать метрики
выбрать полки по армии / корпусу, чтобы посчитать суммарный health и средний mood соединения;
то же отношение "владелец → набор сущностей" для зданий в локации, ордеров на рынке, модификаторов на стране, соседей на карте, entity по чанку в ECS.
и еще много чего...

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

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

Идея vs реальная жизнь

И вроде всё хорошо, пока у вас этот массив массивов маленький, но для нашего кейса использования выяснилось, что снапшот такой структуры после середины игры стоит дороже, чем вся работа, ради которой его делали и например скопировать std::vector<std::vector<unsigned int>> на миллион локаций - это глубокая копия миллиона векторов занимает 90 миллисекунд (на моей машине, на цифры не смотрите он показательные и важно отношение одного к другому, а не абсолютное время). Полный обход этой же структуры, ради которого снапшот и нужен, занимает 14 миллисекунд, т.е. мы собирались распараллелить работу на 14 мс и заплатили 90 мс просто, чтобы начать. Для тестов я взял миллион элементов во внешнем массиве и шесть миллионов элементов суммарно во внутренних, то есть в среднем шесть на список, что на самом деле немного и столько суммарно набегает в разных системах к середине сессии где-нибудь в Victoria3/EU4.

Давайте посчитаем, за что мы заплатили. Cам внешний массивstd::vector на 64-битной системе будет 24 байта (три указателя, либо указатель плюс два размера) и миллион элементов занимает 24 мегабайта только на служебную обвязку, ещё до всяких данных, причём эти 24 байта платятся за каждую локацию, включая пустые. И если юниты стоят в пяти процентах локаций карты, то остальные 95% честно занимают свои 24 байта, но, что хуже, занимают и место в кэше, когда вы по этому массиву массивов проходите.

Еще одно неявное свойство, которое часто упускают - это запас (capacity) и реальный размер блока памятиvectorа растёт быстрее, чем реальный размер вектора, и наши 6 элементов, на самом деле занимают восемь "объемов" данных.

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

Но и это еще не все, и чтобы дойти до capacity 8, вектор аллоцируется четыре раза, и три раза при этом копирует уже накопленное, поэтому на постройку миллиона списков у нас будет примерно четыре миллиона malloc и три миллиона free. Пусть это уже не про память и это все растянуто по фреймам, но это чистое время, которое вынуждены забрать у игры, я называю это "размазаным" перфом, в смысле что мы "размазали" наше время кадра по множеству мелких мест. Итого получаем на элемент (~примерно): 24 байта на внешний vector, 48 байт на блок в куче и семьдесят два байта, чтобы сохранить двадцать четыре.

Наивная схема, миллион локаций:
regiments[]                   куча (блоки разбросаны)
+----------------+            +--------------------------+
| ptr size cap   | ---------> | hdr | 7 idx | 2 unused  |  48 байт
+----------------+            +--------------------------+
| ptr size cap   | ---------> | hdr | 4 idx | 2 unused  |  48 байт
+----------------+            +--------------------------+
| ptr size cap   | --> nullptr   (локация пустая, но 24 байта урплочены)
+----------------+
   24 байта              +          48 байт          = 72 байта на 24 полезных 
// примерно, зависит от режима сборки

regiments[]  [ {loc, health, mood, speed}, ... ]   // плотный массив сущностей

И вот возникает важный момент, из-за которого вообще имело смысл лезть внутрь этого кода и что-то чинить внутри массива массивов, и вся эта математика с байтами выше и разговор про размер памяти это всего лишь следствие, а главная причина - опять кеш. Когда игровой апдейт идет по локациям и для каждого полка читает mood и speed, процессор на каждый список делает минимум два обращения за индексом: одно в by_location[i], второй по указателю в кучу, потом еще один за данными. Но второй и (особенно) третий прыжок будет почти гарантированным промахом, когда cpu придется остановить работу сходить в L2/L3 или вообще в оператику, потому что блоки лежат вразнобой (может быть между чужими аллокациями других подсистем игры) и пока процессор ждёт ответа от памяти, он не делает ничего, что превращает такие пустые такты в просадку кадра, когда "у вас всего миллион объектов".

Замеры, чтобы дальше было с чем сравнивать

Дальше по тексту я буду возвращаться к первому бенчмарку (миллион локаций, шесть миллионов структур, случайное распределение по локациям с длинным хвостом, x86-64, MSVC 19.4 в релизе). Длинный хвост означает, что часть ваших данных выпадает из кеша и за ними приходится идти в оперативку. Меряется отдельно:

build - построить индекс локация → сущности с нуля;
query - пройти все списки по порядку локаций (прочитать health / mood / speed) и выполнить какую-то логику над ними;
query random - то же самое, что и build, но локации обходятся в случайном порядке (так выглядит реальный запрос из геймплея, когда игрок что-то делает в процессе игры);
snapshot - глубокая копия индекса для другого потока (начало кадра, раскидываем данные по потокам);
teardown - освободить индекс (редко, такое надо откладывать на конец фрейма).

Вариант	Память	Аллокаций	Build	Query	Query random	Snapshot	Teardown
`vector<vector<uint>>`	63.1 МБ	3.42М	1045 мс	14.5 мс	96.8 мс	96.7 мс	61.8 мс

Почему аллокаций так много? А потому что мы не знаем длину каждого списка заранее, отсюда получаем и рост capacity, и цепочку реаллокаций, и запас в буфере.

Хак первый

Но нам никто не мешает узнать у каждой сущности location - данные-то уже есть и надо просто пройти по ним лишний раз и посчитать, поэтому...

struct RegimentList {
    unsigned int count   = 0;
    unsigned int written = 0;
    unsigned int* data   = nullptr;
};

std::vector<RegimentList> by_location(location_count);

// проход 1: сколько полков в каждой локации
for (unsigned int r = 0; r < regiment_count; ++r)
    by_location[regiments[r].location].count++;

// проход 2: выделить ровно столько, сколько надо
for (unsigned int i = 0; i < location_count; ++i)
    if (by_location[i].count > 0)
        by_location[i].data = new unsigned int[by_location[i].count];

// проход 3: разложить индексы
for (unsigned int r = 0; r < regiment_count; ++r) {
    RegimentList& list = by_location[regiments[r].location];
    list.data[list.written] = r;
    list.written++;
}

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

Заодно мы выбросили std::vector из внутренних списков и нам стали не нужны его size и capacity, длину мы уже знаем, а расти список больше не будет до следующего апдейта. Там осталась только структура на 16 байт вместо 24 и один блок в куче на непустой.

Отдельно скажу про соблазн заменить всё это на reserve() с угаданным числом. Работать это не будет, угадали мало и вернулись к реаллокациям, угадали много и заплатили памятью за все миллион списков сразу, а тут мы не угадываем, мы считаем сколько будет у нас в памяти и раскладываем эти данные. Давайте посмотрим, что получилось после этого трюка:

Вариант	Память	Аллокаций	Build	Query	Query random	Snapshot	Teardown
`vector<vector<uint>>`	63.1 МБ	3 409 088	1045 мс	14.5 мс	96.8 мс	96.7 мс	61.8 мс
Посчитать, потом выделить	46.7 МБ	650 599	153 мс (-x6.6)	13.7 мс (-x1.10)	40.8 мс	44.0 мс	28.0 мс

А получилось очень интересно, мы и build ускорилил и память упала в полтора раза, а вот query почти не изменился, что логично, поскольку мы всё ещё делаем два прыжка по памяти на список, прежде чем добраться до regiments[id].mood. Зато улучшилось время рандомной выборки, потому что данные лежат плотнее и их больше влезает в кеш.

Хак второй

Заметили что каждый список все равно остался жить в своей аллокации? Пусть вектора мы убрали, но сами аллокации никуда не делись, поэтому остались и метаданные кучи, и разбросанность в памяти, и необходимость таскать в каждой записи 8-байтовый указатель.

Если мы на первом шаге посчитали размеры, почему теперь не выделить и один большой буфер под все списки и разложить их в нём подряд? Тогда мы получим только одну аллокацию и разложенные по смещениям списки, и указатель оказывается не нужен и будет достаточно смещения, и если вы не будете аллоцировать за 4Гб, то смещение прекрасно живёт в 32 битах. Как вы видите данных у нас всего-то 48Мб и нам это вполне подходит.

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

struct RegimentList {
    unsigned int count  = 0;
    unsigned int offset = 0;
};

std::vector<RegimentList> by_location(location_count);
for (unsigned int r = 0; r < regiment_count; ++r)
    by_location[regiments[r].location].count++;

// префиксная сумма: где начинается список каждой локации
unsigned int sum = 0;
for (unsigned int i = 0; i < location_count; ++i) {
    by_location[i].offset = sum;
    sum += by_location[i].count;
}

// одна аллокация на все индексы сразу
std::vector<unsigned int> data(sum);
for (unsigned int r = 0; r < regiment_count; ++r) {
    RegimentList& list = by_location[regiments[r].location];
    data[list.offset] = r;
    list.offset++;
}

// offset уехал вперед на длину списка, надо вернуть на место
for (unsigned int i = 0; i < location_count; ++i)
    by_location[i].offset -= by_location[i].count;

Как теперь наши данные будут лежать в памяти:

Слитая схема:
regiments[]                  blob[] — один буфер на всё
+---------------+            +---+---+---+---+---+---+---+---+---+---+---+
| cnt=1 off=0   |----------> | 0 |                                       |
+---------------+            +---+---+---+---+---+---+---+---+---+---+---+
| cnt=6 off=1   |--------------->| 1 | 2 | 3 | 4 | 5 | 6 |
+---------------+                +---+---+---+---+---+---+---+---+
| cnt=5 off=7   |--------------------------------------->| 7 | 8 | ...
+---------------+                                        +---+---+
   8 байт            +        24 байта данных      = 32 байта на 24 полезных

// данные лежат отдельно
regiments[]  [ {loc, health, mood, speed}, ... ]

И что получится по времени:

Вариант	Память	Аллокаций	Build	Query	Query random	Snapshot	Teardown
`vector<vector<uint>>`	63.1 МБ	3 409 088	1045 мс	14.5 мс	96.8 мс	96.7 мс	61.8 мс
Посчитать, потом выделить	46.7 МБ	650 599	153 мс (x6.6)	13.7 мс (x1.10)	40.8 мс	44.0 мс	28.0 мс
Один буфер, count + offset	30.5 МБ	2	75.6 мс (x15)	13.2 мс (x1.2)	31.7 мс	5.3 мс	2.2 мс

Пятнадцать раз... не процентов, с этим можно идти хоть к техлиду, хоть на конференцию и гордо нести флаг превозмогания. Аллокаций стало две - на массив описаний и на буфер индексов, но снапшот индекса перестал быть глубокой копией миллиона векторов и стал двумя memcpy с 5мс вместо 90 и освобождение тоде два free вместо сотен тысяч. Случайный обход ускорился примерно втрое относительно первой версии, потому что соседние списки полков теперь лежат в плотно, и префетчер успевает подтаскивать нужные данные для расчетов. Сами сущности при этом можно снапшотить отдельно, одним копированием плотного массива, а можно и не снапшотить... главное в процессе расследования не выйти на самих себя :) Оказывается, что дорогим была именно удобная реализация jagged index через стандартные контейнеры, а не доступ к массиву сущностей.

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

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

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

Хак третий

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

count:   [ 1   7   4   4  5  ]
offset:  [ 0   1   8  12  16 ]

А теперь, что получается в массиве смещений:

offset:  [ 0   1   8  12  16 ]
   count:  [ 1   7   4   4  ... ]

Длина списка i будет разностью двух соседних смещений count[i] == offset[i + 1] - offset[i]. Так получается потому, что все списки лежат в одном буфере подряд, и конец одного списка есть начало следующего, а значит, поле длины можно не хранить и надо только дописать в массив смещений один элемент в конец, который показывает на конец последнего списка. Остается один массив на N + 1 элемент.

// N + 1 элемент: полки локации i лежат между offsets[i] и offsets[i + 1]
std::vector<unsigned int> offsets(location_count + 1);

// offsets[0] стартует с нуля и нулем остается
unsigned int* offsets1 = &offsets[1];

// проход 1: считаем длины, но пишем их со сдвигом на единицу
for (unsigned int r = 0; r < regiment_count; ++r)
    offsets1[regiments[r].location]++;

// проход 2: превращаем длины в смещения на месте
unsigned int sum = 0;
for (unsigned int i = 0; i < location_count; ++i) {
    unsigned int count = offsets1[i];
    offsets1[i] = sum;
    sum += count;
}

// проход 3: раскладываем индексы; смещения сами доезжают до правильных значений
std::vector<unsigned int> blob(sum);
for (unsigned int r = 0; r < regiment_count; ++r) {
    const unsigned int location = regiments[r].location;
    blob[offsets1[location]] = r;
    offsets1[location]++;
}

// четвертый проход не нужен: offsets1[i] доехал ровно до offsets[i + 1]

А обходить мы такой массив будем так:

const unsigned int begin = offsets[location];
const unsigned int end   = offsets[location + 1];
for (unsigned int i = begin; i < end; ++i) {
    const Regiment& regiment = regiments[data[i]];
    if (regiment.mood < 0.25f || regiment.health <= 0.0f) {
        continue;
    }
    travel_budget += regiment.speed;
}

Финальная схема:
offsets[]  [ 0 | 1 | 8 | 12 | 16 | 21 ]        N + 1 элемент, по 4 байта
             \___/\___/\__/
              loc0 loc1  loc2
blob[]     [ 0 | 1 2 3 4 5 6 7 | 8 9 10 11 12 | ... ]
   4 байта     +     24 байта данных     = 28 байт на 24 полезных

Вариант	Память	Аллокаций	Build	Query	Query random	Snapshot	Teardown
`vector<vector<uint>>`	63.1 МБ	3 409 088	1045 мс	14.5 мс	96.8 мс	96.7 мс	61.8 мс
То же, фрагментированная куча	174.3 МБ	3 409 088	1308 мс	14.9 мс	95.5 мс	99.2 мс	117.3 мс
Посчитать, потом выделить	46.7 МБ	650 599	153 мс	13.7 мс	40.8 мс	44.0 мс	28.0 мс
Один буфер, count + offset	30.5 МБ	2	75.6 мс	13.2 мс	31.7 мс	5.3 мс	2.2 мс
Только offsets (CSR)	26.7 МБ	2	59.9 мс	12.4 мс	26.8 мс	4.2 мс	1.9 мс

Убрав всего четыре байта на элемент ( и четырех мегабайт на все сущности ) получили структуру как её в академической литературе описывает CSR... помимо всего прочего, получили формат, который понимают библиотеки разреженной линейной алгебры. Это нам, правда, не сильно помогло, потому что непропатченый Eigen работает раза в два медленнее нашей собственной математики, но об этом в другой раз...

На маленьких размерах (100 и 1k) все варианты почти неотличимы, потому что данные целиком в кеше и разрыв мы получаем ближе к 64k-128k, и становится достаточно большим при достижении миллиона объектов.

Относительно последнего варианта сборка быстрее в 17 раз, снапшот в 23 раза, освобождение в 32 раза, случайный обход в 3.6 раза, памяти в 2.4 раза меньше, аллокаций две вместо трех с половиной миллионов.

Почему выигрыш в реальном коде будет даже больше

Вы заметили строку с фрагментированной кучей? Такое происходит, если во время сборки нашего массива массивов, другая подсистема игры успевает аллоцировать свои блоки между нашими массивами, что происходит в 99% случаев в большой игре и потом половина из них остается в виде дыр, и вместо 63 МБ где-то в близком блоке памяти, мы получаем в три раза большую область, на которой раскиданы блоки, что выразится уже в стоимости работы всего алгоритма, и такая фрагментация бьет и по скорости чтения, и по стоимости жизненного цикла.

В наивной версии, которая пришла на ревью, на каждый список процессор делает два независимых обращения к памяти и эти обращения связаны, а префетчер их все равно не видит. Кэш-линия всего 64 байта, и в неё влезает либо два с половиной внешних vector, либо шестнадцать индексов, то есть в наивной схеме мы на каждый список запрашиваем в кэш минимум две линии, из которых используем только 24 байта из 128. А в последнем варианте одна линия blob[] покрывает уже два-три списка целиком, а offsets[] читается последовательно и префетчер просто подкладывает следующие блоки данных в кеш L1, т.е. мы получаем выигрыш от того, что правильно оптимизировали данные под структуру процессора

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

Почему миллион

В глобальных стратегиях вроде Civilazation, Stellaris, Victoria, Humankind будет не "миллион провинций на карте". Карта редко превышает 16 тысяч локаций (~12k суша, ~3k море), но каждая страна имеет свой снапшот локаций, каждый режим отображения добавляет еще один слой, чтобы вы могли быстро переключиться с общего вида на леса, или дороги, или прибыльность. И миллион набегает как сумма живых объектов симуляции, а не как размер одного массива locations[].

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

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

А еще есть временные и производные объекты, вроде модификаторов на страну/локацию/армию/персонажа, подписчики на события, пути. Вы их никогда не увидите на карте, но в памяти и в индексах они есть в виде «владелец → набор сущностей».

Поэтому в бенче «миллион слотов снаружи, шесть миллионов индексов внутри» это не буквальный размер карты стратегии, но порядок числа объектов, до которого вырастает игра к середине длинной партии. Поэтому в следущий раз открывая диспетчер задач и удивляясь почему игра заняла 24 гигабайта оперативки... не удивляйтесь, вот по названным выше причинам. И надо еще как-то заставить все эти гигабайты шевелиться :)

Это было еще до игр и ECS

Придумано это было задолго до нас, и даже не в геймдеве. Раскладку в виде "посчитать, префиксная сумма, разложить" известна вообще с середины 1950-х и идея хранить разреженную структуру парой массивов "смещения плюс данные" пришло из линейной алгебры конца 1960-х, как я уже упоминал про CSR и Yale format. Мы просто "придумали" и применили к нашим проблемам и поиску локациям "немного" численных методов из работы с матрицами.

Этот приём, который возможно вам понравится и вы возьмете его себе в проект, вообще не про jagged arrays. Он про разделение операции на build и query, чтобы появилась возможность построить данные в форме, которая радикально лучше подходит для чтения. Это работает не только со списками и так устроены навигационные меши, так работают архетипы в ECS, так живут вершинные буферы, и получается что мы платим за структуру один раз на этапе сборки, чтобы не платить каждый раз на чтении.

Когда я с коллегами готовил презентацию этого решения для команды, то наткнулся на статью Efficient jagged arrays 2023 года, где он пришел к той же укладке для вертексов в меше для своего проекта. Мы шли со стороны игровых сущностей и снапшота между потоками, а он со стороны индексов треугольников, но в итоге пришли к одной и той же схеме. Само по себе это хороший признак, что задача встречается в разработке достаточно часто, чтобы не изобретать ее заново и найти какое-то более переиспользуемое решение. К сожалению, я такого в открытом доступе не нашел... возможно плохо искал.

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

Выполняю тестовое задание для DevOps Cloud.ru Camp 2025

seobuster — Mon, 14 Sep 2026 19:48:44 +0000

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

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

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Web приложение на Python/Golang

Цель

Написать простейший echo-server на Python или Go

Задача

Требуется написать простое веб-приложение на Python/Go, которое слушает входящие соединения на порту 8000 и предоставляет страницу с информацией:

    имя хоста
    ip адрес хоста
    имя автора, которое передаётся через переменную окружения $AUTHOR

Для приложения написать Dockerfile и запушить образ в докер хаб* (запушить в приватный регистри - пройти регистрацию в докер хаб, сделать регистри приватным).

В ответе к задаче приложить:

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

Полученный артефакты положить в папку /01-application

На первом пункте уже кроется подвох. Python или Go , здесь нужно знать контекст, потому что при грамотной сборке на го, образ получится около 2 мб, вместо около 20 на пайтоне. С другой стороны, на питоне докерфайл писать легче, потому как мультистэйдж сборка здесь не прокатит.

Для чистоты эксперимента, я сделаю 2 варианта, начну с го.

Создаем папку 01-application, в ней 2 файла main.go, go.mod.

// main.go
package main

import (
	"fmt"
	"net"
	"net/http"
	"os"
)

func envOr(key, fallback string) string {
	if v := os.Getenv(key); v != "" {
		return v
	}
	return fallback
}

// IP контейнера в его собственном network namespace.
func getContainerIP() string {
	conn, err := net.Dial("udp", "8.8.8.8:80")
	if err != nil {
		return "unknown"
	}
	defer conn.Close()
	return conn.LocalAddr().(*net.UDPAddr).IP.String()
}

func handler(w http.ResponseWriter, r *http.Request) {
	containerHost, _ := os.Hostname()   // имя из UTS namespace = ID контейнера
	containerIP := getContainerIP()     // адрес из network namespace

	// Данные ХОСТА не добываются — они приходят снаружи.
	hostHost := envOr("HOST_HOSTNAME", "(not injected)")
	hostIP := envOr("HOST_IP", "(not injected)")
	author := envOr("AUTHOR", "anonymous")

	w.Header().Set("Content-Type", "text/html; charset=utf-8")
	fmt.Fprintf(w, `<!DOCTYPE html>
<html><head><title>Echo Server</title></head>
<body style="font-family:monospace">
  <h1>Echo Server</h1>
  <ul>
    <li><b>Container hostname:</b> %s</li>
    <li><b>Container IP:</b> %s</li>
    <li><b>Host hostname:</b> %s</li>
    <li><b>Host IP:</b> %s</li>
    <li><b>Author:</b> %s</li>
  </ul>
</body></html>`, containerHost, containerIP, hostHost, hostIP, author)
}

func healthz(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintln(w, "ok")
}

func main() {
	http.HandleFunc("/", handler)
	http.HandleFunc("/healthz", healthz)
	http.ListenAndServe(":8000", nil)
}

// go.mod
module echo-server

go 1.23

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

# ---- Этап 1: сборка ----
FROM golang:1.23-alpine AS builder
WORKDIR /src
COPY go.mod ./
COPY main.go ./
# CGO_ENABLED=0 — статическая линковка, чтобы бинарник
# жил в scratch без единой системной библиотеки.
# -ldflags="-s -w" срезает отладочные символы (меньше вес).
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /echo-server .
RUN echo 'appuser:x:10001:10001::/:' > /etc/passwd

# ---- Этап 2: финальный образ ----
FROM scratch
COPY --from=builder /echo-server /echo-server
COPY --from=builder /etc/passwd /etc/passwd
USER appuser
EXPOSE 8000
ENV AUTHOR="alfabuster"
ENTRYPOINT ["/echo-server"]

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

# 1. Логинимся (введёт логин и Access Token — не пароль, пароли уже немодно)
docker login -u <ваш_логин>

# 2. Собираем с правильным тегом: <логин>/<репозиторий>:<версия>
docker build -t <ваш_логин>/echo-server:1.0 .

# 3. Проверяем локально, что оно вообще дышит
docker run --rm -p 8001:8000 \
  -e AUTHOR="alfabuster" \
  -e HOST_HOSTNAME="$(hostname)" \
  -e HOST_IP="$(ip -4 route get 1.1.1.1 | grep -oP 'src \K\S+')" \
  <ваш_логин>/echo-server:1.0
#    открываем http://localhost:8001 — должны увидеть hostname/IP/author

Если все сделали правильно, то увидим инфу о контейнере и хосте.

# 4. Пушим в приватный регистри
docker push <ваш_логин>/echo-server:1.0

Теперь проделаем, все тоже самое, но для пайтона.

В папке созаем server.py с таким кодом.

#!/usr/bin/env python3
import os
import socket
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer


def env_or(key, fallback):
    return os.getenv(key) or fallback


def get_container_ip():
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    try:
        s.connect(("8.8.8.8", 80))
        return s.getsockname()[0]
    except Exception:
        return "unknown"
    finally:
        s.close()


class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == "/healthz":
            self.send_response(200)
            self.send_header("Content-Type", "text/plain")
            self.end_headers()
            self.wfile.write(b"ok\n")
            return

        container_host = socket.gethostname()      # ID контейнера
        container_ip = get_container_ip()
        host_host = env_or("HOST_HOSTNAME", "(not injected)")
        host_ip = env_or("HOST_IP", "(not injected)")
        author = env_or("AUTHOR", "anonymous")

        body = f"""<!DOCTYPE html>
<html><head><title>Echo Server</title></head>
<body style="font-family:monospace">
  <h1>Echo Server (Python)</h1>
  <ul>
    <li><b>Container hostname:</b> {container_host}</li>
    <li><b>Container IP:</b> {container_ip}</li>
    <li><b>Host hostname:</b> {host_host}</li>
    <li><b>Host IP:</b> {host_ip}</li>
    <li><b>Author:</b> {author}</li>
  </ul>
</body></html>"""

        self.send_response(200)
        self.send_header("Content-Type", "text/html; charset=utf-8")
        self.end_headers()
        self.wfile.write(body.encode("utf-8"))

    def log_message(self, *args):
        pass


if __name__ == "__main__":
    ThreadingHTTPServer(("0.0.0.0", 8003), Handler).serve_forever()

Напишем простой докерфайл. А теперь ключевой момент, ради которого всё затевалось. Помните элегантный финал Go-версии — FROM scratch, образ из чистой пустоты весом в мегабайты? С Python так не выйдет никогда. Python — язык интерпретируемый: чтобы запустить server.py, в образе обязан жить сам интерпретатор со всей его свитой. В пустоту его не положишь, multi-stage тут бесполезен — выкидывать нечего, рантайм нужен целиком.

FROM python:3.12-alpine
WORKDIR /app
RUN adduser -D appuser 
COPY --chown=appuser:appuser app.py .
COPY server.py .
EXPOSE 8003
ENV AUTHOR="alfabuster"
ENTRYPOINT [ "python3" , "server.py"]

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

Теперь сравним размер полученных из билда образов.

alt text

Как видно разница примерно в 10 раз. Здесь однозначно выигрывает go.

А что на счет безопасности? Образ на scratch — это крепость без дверей: там нет sh, нет apt, нет curl, нет вообще ничего, кроме бинарника. Злоумышленник, пробравшийся в такой контейнер, оказывается в пустой бетонной коробке — ни закрепиться, ни осмотреться, ни подтянуть инструменты. Однако scratch не является защитой от RCE, при определенных условиях можно использовать загруженные/встроенные бинарники или эксплуатировать уязвимости ядра/процесса.

В python:3.12-alpine sh присутсвует. Также содержит сам Python, поэтому при RCE атакующий может использовать Python как инструмент, даже если каких-то Unix-команд нет.

Справедливости ради — у Python есть и козыри. Dockerfile проще (никакой стадии сборки), правки на лету без перекомпиляции, а внутрь можно зайти и потыкать палкой, когда что-то пошло не так. Go-scratch за свою неприступность расплачивается тем, что отлаживать его — как чинить запечатанные часы: удобной дверцы нет. Это классический размен безопасность против удобства.

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

Тем временем первая задача выполнена, переходим ко второй.

Ansible playbook или роль

Цель

Автоматизация конфигурации на Ansible
Задача

Требуется поднять Виртуальную Машину (VM) с ОС Ubuntu 22.04. Возможные сценарии: локально через Virtual Box (или любое другое средство виртуализации), либо воспользовавшись Free-tier предложением от cloud.ru - https://cloud.ru/offers/free-tier.

Выполнить следующие задачи, используя Ansible:

    На VM установить пакет docker-ce;
    Запустить на docker контейнеры c подготовленным Web-приложением из первой задачи в 3-х экземплярах. Для развёртывания использовать приватный регистри из первой задачи;
    Настроить балансировщик на nginx, который будет отвечать при обращении к хосту и прокидывать запрос на запущенные контейнеры. Выбрать алгоритм балансировки для приложения и обосновать свой выбор.

В ответе к задаче приложить:

    исходный код Ansible
    текстовое обоснование выбранного алгоритма балансировки

Полученные артефакты положить в папку /02-ansible

Ок, приступим. Поскольку хостовая система у меня Void Linux, вручную качать и устанавливать ubuntu, я не буду, воспользуюсь утилитой vagrant.

Для установки, установлю пакетный менеджер Brew.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Он рассчитан на bash, но у меня оболочка fish, поэтому, то что советует установщик в выводе в моем случае не сработает.

Нужно добавить Homebrew в PATH fish

fish_add_path /home/linuxbrew/.linuxbrew/bin
fish_add_path /home/linuxbrew/.linuxbrew/sbin

После этого можно устанавливать сам Vagrant.

brew tap hashicorp/tap
brew install hashicorp/tap/vagrant

На хосте создаю любую папку, в ней создаю файл Vagrantfile.

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/jammy64"
  config.vm.network "private_network",
  ip: "10.0.0.7",
  virtualbox__intnet: "intnet"
  config.vm.provider "virtualbox" do |vb|
    vb.memory = 2048
    vb.cpus   = 2
  end
end

Этим файлом я создал машину во внтуренней сети, которая у меня уже была.

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

Теперь можно создавать плейбук через Ansible.

В папке 02-ansible создаем пару файлов ansible.cfg и inventory.ini.

[defaults]
inventory = inventory.ini
remote_user = vagrant
private_key_file = ~/.ssh/id_ed25519

[web]
web-vm ansible_host=10.0.0.7

[web:vars]
ansible_python_interpreter=/usr/bin/python3

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

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

Нам нужно, установить docker, залогиниться в приватный докер репозиторий, запустить 3 контейнера и накрыть балансировщиком на nginx.

Возможно руками, залезь на 1 сервак, там установить докер и запустить 3 контейнера будет быстрее. Но задание требует именно ansible, поэтому файл будет достаточно большим.

Начало плейбука

---
- name: Deploy echo-server behind an nginx load balancer
  hosts: web
  become: true          # выполнять с sudo — иначе apt ругнется на permission

  vars:
    docker_image: "<ваш_логин>/echo-server:1.0"
    author_name: "alfabuster"
    container_count: 3
    base_port: 8000                  # контейнеры сядут на 8001, 8002, 8003
    registry_user: "<ваш_логин>"
    registry_password: "{{ vault_registry_token }}"   # прячем в vault, создадим далее

Далее установим сам докер

  tasks:
    - name: Install prerequisites
      apt:
        name: [ca-certificates, curl, gnupg, python3-pip]
        state: present
        update_cache: true

    - name: Create apt keyrings directory
      file:
        path: /etc/apt/keyrings
        state: directory
        mode: '0755'

    - name: Download Docker's GPG key
      get_url:
        url: https://download.docker.com/linux/ubuntu/gpg
        dest: /etc/apt/keyrings/docker.asc
        mode: '0644'

    - name: Add Docker apt repository
      apt_repository:
        repo: "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu {{ ansible_distribution_release }} stable"
        filename: docker
        state: present

    - name: Install docker-ce
      apt:
        name: [docker-ce, docker-ce-cli, containerd.io]
        state: present
        update_cache: true

    - name: Install Docker SDK for Python
      pip:
        name: docker
        state: present

    - name: Ensure docker is running and enabled
      service:
        name: docker
        state: started
        enabled: true

Обратите внимание на ansible_distribution_release — это факт, который Ansible сам собирает о хосте перед стартом (для 22.04 подставит jammy).

Модуль docker_container работает не через CLI, а через Python-библиотеку docker. Поэтому мы ставим pip install docker — без неё модуль выдаст загадочную ошибку.

Приватный реджистри и запуск трех контейнеров

- name: Log in to the private registry
  community.docker.docker_login:
    username: "{{ registry_user }}"
    password: "{{ registry_password }}"

- name: Pull the application image
  community.docker.docker_image:
    name: "{{ docker_image }}"
    source: pull

- name: Run echo-server containers
  community.docker.docker_container:
    name: "echo-{{ item }}"
    image: "{{ docker_image }}"
    state: started
    restart_policy: unless-stopped
    published_ports:
      - "127.0.0.1:{{ item }}:8000"
    env:
      AUTHOR: "{{ author_name }}"
  loop:
    - 8001
    - 8002
    - 8003

published_ports привязан к 127.0.0.1, а не к 0.0.0.0. Контейнеры слушают только локально — снаружи к ним не достучаться, единственная дверь наружу — через nginx.

Nginx и его конфиг через шаблон.

    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Deploy the load-balancer config
      template:
        src: nginx-lb.conf.j2
        dest: /etc/nginx/sites-available/echo-lb.conf
      notify: Reload nginx

    - name: Enable the site
      file:
        src: /etc/nginx/sites-available/echo-lb.conf
        dest: /etc/nginx/sites-enabled/echo-lb.conf
        state: link
      notify: Reload nginx

    - name: Remove the default nginx site
      file:
        path: /etc/nginx/sites-enabled/default
        state: absent
      notify: Reload nginx

    - name: Ensure nginx is running and enabled
      service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      service:
        name: nginx
        state: reloaded

handlers — механизм, который отличает Ansible от тупого шелл-скрипта. notify: Reload nginx не перезагружает nginx немедленно. Он ставит галочку «надо будет перечитать конфиг» и делает это один раз в конце, и только если конфиг реально изменился.

Шаблон templates/nginx-lb.conf.j2

upstream echo_backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

server {
    listen 80 default_server;
    server_name _;

    location / {
        proxy_pass http://echo_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    }
}

Обоснование алгоритма

А теперь ради чего всё затевалось. У nginx есть несколько алгоритмов балансировки, и вот полный расклад, кто есть кто:

round-robin (по умолчанию) — раздаёт запросы по кругу: первый на 8001, второй на 8002, третий на 8003, четвёртый снова на 8001.
least_conn — отдаёт тому бэкенду, у кого меньше активных соединений.
ip_hash — привязывает клиента к бэкенду по хешу его IP (липкие сессии).
hash / random — экзотика для особых случаев.

Поскольку у нас простое stateless приложение, нет ни куков, ни личного кабинета, ни сессий. Все 3 контейнера равнозначны и идентичны. Поэтому равномерное распределение по кругу будет оптимальным вариантом в данной ситуации.

Least_conn здесь не станет преимуществом, потому как нагрзука в условии не указана. ip_hash в данной топологии противопоказан, так как весь трафик приходит с localhost и был бы прикован к одному контейнеру.

Поэтому выбираем round-robin.

Создаем vault и запускаем плейбук

Создание vault и пароля к нему.

ansible-vault create group_vars/web/vault.yml

Внутри одна строка с токеном из докера

vault_registry_token: "docker_token"

Далее можем запускать наш плейбук.

ansible-playbook playbook.yaml --ask-vault-pass

Тут не все прошло гладко, вылезла ошибка.

fatal: [web-vm]: FAILED! => {"changed": false, "msg": "Error connecting: Error while fetching server API version: Not supported URL scheme http+docker"}

Это произошло потому что, я давно не обновлял коллекции из ansible. Чиним.

ansible-galaxy collection install community.docker --upgrade

Запускаем плейбук еще раз и все заработало.

Проверяем сервак.

Балансировщик работает, второе задание выполнено.

Kubernetes manifest

Цель

Деплой приложения в Kubernetes
Задача

Требуется написать манифест для запуска приложения из первой задачи в Kubernetes в отдельном неймспейсе в виде Deployment с 3 репликами и сервиса с типом ClusterIP.

Выполнить следующие задачи:

    Для приложения организовать проброс значения переменной AUTHOR;
    Реализовать readiness- и liveness- пробы;
    Использовать образ из приватного регистри из задачи 1;
    опционально: поднять ingress-controller и создать правило ingress;
    опционально: использовать helm-chart, а не raw манифест.

В ответе к задаче приложить:

    исходный код всех манифестов

Полученные артефакты положить в папку /03-kubernetes

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

У меня на убунту для тестов как раз стоит кубер и 2 воркер ноды версии v1.31.14. Поэтому я применю написанные манифесты.

Недавно проходил курс Certified Kubernetes Administrator от kodekloud, там подсмотрел полезную тему для генерации манифестов.

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

alias k=kubectl

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

--dry-run=client -o yaml

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

Создаем namespace

k create ns cloud --dry-run=client -o yaml

В выводе будет лежать готовый манифест.

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: cloud
spec: {}
status: {}

Конечно врядли, кто пишет манифест для создания namespace, его проще создать командой k create ns name. Однако в задании нужен именно манифест.

Секрет

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

Создаётся секрет императивно, чтобы не хранить токен в git.

kubectl create secret docker-registry regcred \
  --docker-server=https://index.docker.io/v1/ \
  --docker-username=<ваш_логин> \
  --docker-password=<ваш_access_token> \
  --namespace=cloud

Секрет живёт внутри неймспейса cloud — в другом неймспейсе он невидим.

Configmap

Можно было впихнуть AUTHOR прямо в манифест как value: “alfabuster”. Но задание просит «организовать проброс», а по-взрослому переменные конфигурации живут в ConfigMap — отдельно от кода деплоя:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: cloud-configmap
  namespace: cloud
data:
  AUTHOR: alfabuster

Deployment

Собственно дальше идет деплоймент с 3 репликами и пробами. Генерируем шаблон, а дальше правим руками.

k create deploy cloud-deploy --image=alfabuster/echo-server:1.0 --replicas=3 --port=8000 -n cloud --dry-run=client -o yaml

Итоговый манифест получился такой.

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: cloud-deploy
  name: cloud-deploy
  namespace: cloud
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cloud-deploy
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: cloud-deploy
    spec:
      imagePullSecrets:
        - name: regcred
      containers:
      - image: alfabuster/echo-server:1.0
        name: echo-server
        ports:
        - containerPort: 8000
        env:
          - name: AUTHOR
            valueFrom:
              configMapKeyRef:
                name: cloud-configmap
                key: AUTHOR
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8000
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8000
          periodSeconds: 5

livenessProbe отвечает на вопрос «пациент вообще жив?». Если проба падает — Kubernetes перезапускает контейнер. Это лекарство от зависших процессов и дедлоков.
readinessProbe отвечает на вопрос «пациент готов принимать посетителей?». Если проба падает — под не перезапускается, его просто исключают из эндпоинтов Service, то есть перестают слать трафик, пока он не оклемается.

Service

Service в Kubernetes — это тоже балансировщик. ClusterIP раскидывает входящие соединения по всем готовым подам.

apiVersion: v1
kind: Service
metadata:
  name: cloud-deploy
  namespace: cloud
spec:
  type: ClusterIP
  selector:
    app: cloud-deploy
  ports:
    - port: 80
      targetPort: 8000
      protocol: TCP

Ingress

Создаем уже привычным способом, через генератор.

k create ingress cloud-ingress --rule="cloud.local/*=cloud-deploy:80" -n cloud --dry-run=client -o yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  creationTimestamp: null
  name: cloud-ingress
  namespace: cloud
spec:
  rules:
  - host: cloud.local
    http:
      paths:
      - backend:
          service:
            name: cloud-deploy
            port:
              number: 80
        path: /
        pathType: Prefix
status:
  loadBalancer: {}

Домен cloud.local надо прописать в /etc/hosts, указав на IP кластера (minikube ip или адрес ноды). Без этой записи браузер будет искать cloud.local в интернете.

alt text

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

alt text

Запереть контейнер изнутри*

Цель

Проверить навыки администрирования *nix
Задача

    Создать ВМ с ОС Ubuntu 22.04;
    Установить пакет docker-ce;
    Выполнить команду docker run -it --rm ubuntu -- bash;
    Не покидая контейнер, не меняя флаги запуска и настройки демона, выполнить задачи:
    4.1. сделать apt-get update, показать, что команда выполняется успешно;
    4.2. изнутри контейнера заблокировать ему выход в сеть интернет, команды блокировки с описанием приложить к задаче;
    4.3. показать, что apt-get update больше не работает.
    Доп. задача - найти ещё +1 способ выполнить подобную блокировку изнутри контейнера.

В ответе к задаче приложить:

    текстовое описание применённых конфигураций

Полученные артефакты положить в папку /04-unix

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

alt text

Вот в чём фокус: Docker по умолчанию запускает контейнеры с урезанным набором Linux capabilities, выбрасывая большинство привилегий, даже когда внутри вы root.

Root внутри контейнера не равняется рут на хосте.

Из очевидного в голову приходит установить iptables и запретить исходящий трафик. Установить можем, однако для правки таблицей маршрутизации рута недостаточно.

root@d79ba688c2c9:/# iptables -A OUTPUT -j DROP
iptables v1.8.11 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root)

Контейнер работает под root, но демон docker по умолчанию сбрасывает все capabilities, кроме дефолтного набора. А в таком списке отсутсвует привелегия NET_ADMIN, без которой вы не можете ни трогать iptables, ни гасить интерфейсы, ни править таблицу маршрутизации.

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

Нам нужно заблокировать интернет именно для утилиты apt.

Способ №1 - nsswitch.conf

Начну не с самого очевидного варианта файла /etc/nsswitch.conf, я о нем сам недавно узнал, принимая участие в одном CTF.

NSS расшифровывается как Name Service Switch. Это механизм, встроенный в стандартную библиотеку C (glibc). Когда любая программа пытается узнать IP-адрес по доменному имени или проверить, существует ли в системе определенный пользователь, она обращается к glibc. А glibc первым делом читает /etc/nsswitch.conf, чтобы понять, где именно искать ответ.

В структуре этого файла есть строка hosts: files dns

Убрав dns из строки hosts:, вы вообще запрещаете системе обращаться к DNS — резолвиться будет только то, что явно прописано в /etc/hosts.

Кстати NSS управляет не только хостами. В файле прописаны правила для десятка системных баз данных.

Но в данном таске нас интересует dns, поэтому редактируем файл и получаем неработающий apt.

alt text

Способ №2 - resolv.conf

Второй способ, аналогичен первому, только на этот раз править будем файл /etc/resolv.conf.

Если /etc/nsswitch.conf решает, нужно ли вообще делать DNS-запрос, то /etc/resolv.conf указывает системе, к кому именно с ним обращаться. Это главный конфигурационный файл DNS-резолвера. Он часто генерируется networkmanager’ом, поэтому при следующем подключении вероятнее всего он затрется, но для демонстрации в контейнере, хватит обычной правки через vim или nano.

> /etc/resolv.conf

alt text

Снова получаем неработающий интернет.

Способ 3 - /etc/hosts

/etc/hosts — это простейший локальный справочник, который жестко связывает IP-адреса с доменными именами.

В него можно прописать локальный ip адрес серверов убунту и обновление не пройдет.

127.0.0.1 archive.ubuntu.com
127.0.0.1 security.ubuntu.com
127.0.0.1 ports.ubuntu.com

alt text

Способ 4 - apt proxy

У APT есть собственная настройка HTTP/HTTPS-прокси. Можно попробовать для всех HTTP-запросов использовать прокси 127.0.0.1:9.

Порт 9 используется для протокола Discard (RFC 863), который является сетевым эквивалентом черной дыры (/dev/null). Любые данные, отправленные на этот порт по TCP или UDP, просто уничтожаются сервером без какого-либо ответа или подтверждения.

cat > /etc/apt/apt.conf.d/99-block-network <<'EOF'
Acquire::http::Proxy "http://127.0.0.1:9";
Acquire::https::Proxy "http://127.0.0.1:9";
EOF

alt text

Как итог

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

Выполнил и выложил на гитхаб alfabuster.

Как гаражная разработка шведских любителей обошла стартап Бэббиджа с бюджетом в 30 паровозов

Mon, 14 Sep 2026 19:12:15 +0000

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

Математик Чарльз Бэббидж предложил автоматизировать расчеты и спроектировал механическую Разностную машину.

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

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

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

От ручных расчетов к механическим

Механические счетные устройства существовали и до Бэббиджа: часы Шиккарда, арифмометр Паскаля, барабан Лейбница и перфокарты Жаккара. Однако они подходили лишь для простых задач и не справлялись с объемами вычислений, необходимыми флоту, страхованию и инженерии.

Французский математик Гаспар де Прони предложил конвейерный метод расчетов, разделив процесс на три уровня:

Архитекторы: ученые разбивали сложные уравнения на простые операции (сложение и вычитание).
Менеджеры: распределяли задачи и контролировали порядок действий.
Исполнители: наемные работники без специального образования (их называли computers) вручную вели однотипные расчеты на бумаге.

Метод де Прони ускорил работу, но не решил проблему ошибок: из‑за монотонного труда и усталости люди регулярно ошибались в таблицах.

Изучая эти неточности, Чарльз Бэббидж пришел к выводу: базовые рутинные операции третьего уровня можно полностью передать механизму. Объединив идеи де Прони с наработками предшественников, он приступил к созданию первого специализированного вычислителя — Разностной машины.

Чарльз Бэббидж: изобретатель и ученый

Чарльз Бэббидж (1791–1871) известен прежде всего как математик, астроном и создатель проекта первого механического компьютера. Он занимал кафедру Лукасовского профессора ^{(примеч1)} в Кембридже и получил первую Золотую медаль Королевского астрономического общества.

Хотя Чарльз Бэббидж вошел в историю как «отец компьютера», он был ученым‑универсалом. Его разработки повлияли на многие сферы:

Математика: основал «Аналитическое общество», внедрив в Британии европейскую систему дифференциального исчисления Лейбница (dy/dxdy/dx).
Транспорт и связь: разработал для поездов путеочиститель («скотосбрасыватель»), сигнальные огни и вагон‑лабораторию, а его экономические расчеты легли в основу почтовой реформы с единым тарифом (Penny Post).
Медицина и геология: создал офтальмоскоп и предложил физико‑математическое обоснование смещения изотерм и поднятия земной коры.
Производство: усовершенствовал металлорежущие станки и ввел стандарты механических допусков для точной обработки деталей.

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

Разностная машина Чарльза Бэббиджа

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

Принцип работы

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

В 1822 году Бэббидж построил действующий прототип, считавший квадратичные функции до восьмого знака. Адмиралтейство оценило пользу для морской навигации, и казначейство выделило средства на полноразмерный аппарат. Общие вложения превысили 17 000 фунтов стерлингов (около 2 миллионов фунтов в современных ценах).

Разностная машина задумывалась как механический вычислитель для автоматизации рутинных расчетов и замены людей‑вычислителей.

Разностная машина № 1

Проект предполагал устройство весом 4 тонны из 25 000 деталей с точностью до 20 знаков и печатным блоком. Постройку свернули по трем причинам:

Сложность производства: детали вытачивали вручную без общих стандартов, и малейшие люфты клинили сложный механизм.
Конфликт с мастером: в 1833 году Бэббидж поссорился с механиком Джозефом Клементом из‑за оплаты и прав на инструменты, после чего работы остановились.
Смена планов: изобретатель постоянно вносил правки, а в 1834 году увлекся более сложной Аналитической машиной.

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

Разностная машина № 2 и итоги

В 1840-х годах Бэббидж переработал чертежи: повысил точность до 31 знака и сократил число деталей до 8000. Из‑за прошлых неудач власти отказались финансировать сборку.

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

Code review: проверка работоспособности через 150 лет

Долгое время считалось, что построить машину Бэббиджа в XIX веке мешали несовершенные технологии, трение и люфты деталей.

В 1985 году куратор Лондонского музея науки Дорон Свейд решил собрать Разностную машину № 2 по оригинальным чертежам автора.

Правила сборки:

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

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

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

Разностная машина Шойцев: от идеи до банкротства

Шведский издатель Георг Шойц часто сталкивался с опечатками наборщиков в таблицах. Узнав об идее Чарльза Бэббиджа, он вместе с сыном‑студентом Эдвардом решил собрать машину, которая сама считает данные и делает печатные формы.

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

1843 год: Эдвард собрал первый металлический образец. Он считал 5-значные числа и выбивал результаты на свинцовых пластинах.
1853 год: На господдержку под гарантии поручителей семья построила полноразмерную машину, работавшую уже с 15-значными числами.
1855 год: Бэббидж высоко оценил шведский аппарат и помог представить его на Всемирной выставке в Париже, где изобретение получило золотую медаль.

Продажи и разорение

Всего удалось продать два экземпляра:

В 1856 году — американской обсерватории Дадли за £1 000 для расчета орбит.
В 1859 году — британскому ведомству ЗАГС за £1 200 для печати демографических таблиц English Life Tables.

Несмотря на рабочий продукт, Шойцы разорились:

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

Выводы

Идея Бэббиджа работала. Копия Разностной машины, собранная Музеем науки в Лондоне строго по чертежам автора, подтвердила: викторианских технологий было достаточно. Бэббиджу помешали не законы физики, а постоянное стремление Бэббиджа к улучшению, изменение требований и проектных решений, перерасход бюджета и конфликты с инвесторами.
Шойцы доказали реализуемость на практике. Отец и сын создали первый действующий механический вычислитель, подтвердив точность математических расчетов Бэббиджа доступными в XIX веке средствами.
Рабочий продукт не равен прибыли. Успешная сборка и признание ученых не спасли проект Шойцев от банкротства: технология опередила свое время, а рынок для таких сложных и дорогих машин еще не сформировался.
Оправданный перфекционизм Бэббиджа. Поломки шведской машины доказали: жесткие требования Бэббиджа к металлу и точности не были блажью. Шойцы сэкономили на материалах и допусках, и к первому калькулятору у американской обсерватории были серьезные претензии: клинило из‑за малейших перепадов температуры, повышения влажности — разнородные металлы расширялись неравномерно и сбивали вычисления.
Опыт показал, что компромиссы здесь не работали: сложнейшая механика требовала именно той прецизионной обработки и сплавов, на которых настаивал британский ученый.

Что было дальше: шаг в бесконечность

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

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

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

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

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

Примечания

Лукосовский профессор — одна из самых престижных именных профессорских должностей в мире. Среди лукосовских профессоров — Исаак Ньютон, Поль Дирак и Стивен Хокинг.

А пока предлагаю обсудить (пишите в комментариях):

Как вы считаете, был ли у Бэббиджа шанс вовремя остановиться на работающем прототипе, или гениальность всегда граничит с неумением завершать проекты?
Какие современные IT‑стартапы напоминают вам эту историю: сжигают миллионы инвесторских денег ради опережающей время идеи, но в итоге меняют индустрию?
Что, на ваш взгляд, важнее для прорыва — инженерная база эпохи или смелость концептуальной идеи?

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

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

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

23 сентября в 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться
22 октября в 20:00. «Управление изменениями требований». Записаться

Полный список бесплатных уроков сентября собран в дайджесте.

А чё, так можно было? Три недооценённых атрибута.NET

Geronom — Mon, 14 Sep 2026 18:53:10 +0000

Три атрибута, которые меняют результат компиляции. Один запускает метод раньше Main. Второй передаёт текст выражения вместо результата. Третий ускоряет stackalloc в 50 раз.

Все три описаны в документации и применяются внутри .NET. За его пределами их практически не найти.

Процессор	Система
Intel Core i9-10900KF 3.70GHz, 10 ядер	Windows 10 22H2
AMD Ryzen 9 5950X 3.39GHz, 16 ядер	Windows 10 1809
Intel Xeon W-2255 3.70GHz, 10 ядер	Windows Server 2022
Intel Xeon Silver 4314 2.40GHz, 2 CPU, 32 ядра	Windows Server 2022

Все машины x64

Рантаймы .NET 8, 9 и 10 — все три в одном запуске BenchmarkDotNet 0.15.8.

1. Код, который выполняется до Main

Исходник

Метод помечен атрибутом и больше нигде не встречается:

internal static class Startup
{
    [ModuleInitializer]
    internal static void Init()
    {
        Order.Add("инициализатор модуля");
    }
}

В Main его нет. Там только своя отметка первой строкой:

private static int Main(string[] args)
{
    Startup.Order.Add("точка входа");
    // ...
}

Что выводит отчёт

Порядок событий:
 
  1. инициализатор модуля
  2. точка входа

Одинаково на четырёх машинах и трёх рантаймах.

Причина

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

К методу есть требования: статический, без параметров, возвращает void, не обобщённый и не внутри обобщённого типа, доступность internal или public. Любое нарушение — ошибка сборки.

Где встречается

В библиотеке классов такой метод один, в EventSource. Основное применение — генераторы исходного кода: настройка выполняется до Main.

Где легко ошибиться

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

Бросить исключение. Программа падает до точки входа, и Main не выполняется:

Unhandled exception. System.TypeInitializationException:
  The type initializer for '<Module>' threw an exception.
 ---> System.InvalidOperationException: из инициализатора

Применять в библиотеке. Начиная с .NET 10 включено правило CA2255: библиотека меняет порядок запуска приложения и мешает выбросить неиспользуемый код при публикации.

2. Текст выражения вместо значения

Исходник

Второй параметр помечен атрибутом и получает значение по умолчанию:

static void Check(bool condition,
    [CallerArgumentExpression(nameof(condition))] string? text = null)
{
    Console.WriteLine(text + " = " + condition);
}

Что выводит отчёт

Что попадает в text при разных вызовах:
 
  a + b > 10                            ложь
  a * b == 6                            истина
  empty is null                         истина
  !string.IsNullOrEmpty(empty)          ложь

В параметр приходит не результат, а то, что написано в месте вызова.

Причина

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

Замер это подтверждает. Библиотечная проверка и такая же, написанная явно, исключений в замере нет:

Способ	i9-10900KF	Ryzen 9 5950X	Xeon W-2255	Xeon Silver 4314
из библиотеки	0,3944	0,2656	0,7058	0,6679
вручную	0,3969	0,2646	0,6427	0,7231

Наносекунды, .NET 10

Где встречается

В 21-м месте библиотеки классов. Например, ArgumentNullException.ThrowIfNull:

public static void ThrowIfNull([NotNull] object? argument,
    [CallerArgumentExpression(nameof(argument))] string? paramName = null)
{
    if (argument is null)
    {
        Throw(paramName);
    }
}

Поэтому исключение показывает имя переменной из места вызова, а не имя параметра argument. Отчёт это подтверждает:

  ArgumentNullException             имя аргумента: empty
  ArgumentOutOfRangeException       имя аргумента: a - 5

Во втором случае именем аргумента стало целое выражение — то, что передали.

Где легко ошибиться

Передать текст вторым аргументом. Тогда компилятор ничего не подставляет и берёт то, что написано:

Check(a + b > 10);                       // текст: a + b > 10
Check(a + b > 10, "передано вручную");   // текст: передано вручную

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

3. Отказ от обнуления памяти

Исходник

Два одинаковых метода, различаются одной строкой:

[MethodImpl(MethodImplOptions.NoInlining)]
internal static int StackWithInit(int size)
{
    Span<byte> buffer = stackalloc byte[size];
    buffer[0] = 1;
    buffer[^1] = 2;
 
    return buffer[0] + buffer[^1];
}
 
[SkipLocalsInit]
[MethodImpl(MethodImplOptions.NoInlining)]
internal static int StackWithoutInit(int size)
{
    // тело то же самое
}

Что показывает замер

Буфер	i9-10900KF	Ryzen 9 5950X	Xeon W-2255	Xeon Silver 4314
64 байта	2,452 / 1,765	2,082 / 4,695	2,793 / 2,419	5,409 / 4,512
256 байт	6,475 / 1,729	5,741 / 4,691	8,530 / 2,208	13,015 / 4,501
1024 байта	25,505 / 1,769	17,712 / 4,703	31,281 / 2,574	48,282 / 4,566
4096 байт	103,474 / 2,043	71,811 / 4,939	126,066 / 2,685	189,264 / 4,827

Наносекунды, с обнулением и без, .NET 10

На четырёх килобайтах разница от 14,5 до 50,6 раза. С обнулением время растёт вместе с буфером, без обнуления — не меняется.

Причина

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

Отсюда и числа в таблице: чем больше буфер, тем дольше заполнение, а без него размер не важен.

Где встречается

Атрибут прописан не в коде, а в общем файле сборки: свойство SkipLocalsInit включено для каждого проекта, входящего в .NET.

Где легко ошибиться

Поставить атрибут ради небольшого буфера. На 64 байтах выигрыш в лучшем случае 1,39 раза, а на Ryzen 9 5950X версия без обнуления медленнее: 4,695 против 2,082.

На этой машине результат отличается от остальных: без заполнения нулями с ростом буфера время не меняется и составляет около 4,7 наносекунды, а на других процессорах оно в пределах 1,7–2,7.

Прочитать буфер раньше, чем в него что-то записали. Атрибут не заполняет память нулями и не требует этого от рантайма — в буфере будут данные от предыдущих вызовов.

Забыть про файл проекта. Без небезопасного контекста атрибут не работает: сборка упадёт с ошибкой CS0227.

Границы замеров

Все замеры сняты на x64 под Windows, на .NET 8, 9 и 10.

У всех измеряемых методов запрещено встраивание. Иначе компилятор перенесёт код метода в замер, а вместе с ним заполнение памяти нулями.

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

В замере на вход всегда передаётся непустая строка, поэтому проверка на null ни разу не срабатывает. Так в замер попадает только сама проверка, без обработки исключения.

Код из статьи

AttributeProof — замеры, отчёты и выгрузки с четырёх машин

Ссылки

Всем удачи и до новых встреч!

Промпт‑инжиниринг для моделей надежности отказоустойчивого кластера

avers_52 — Mon, 14 Sep 2026 18:25:42 +0000

Ранее в «Базовые модели надежности отказоустойчивого кластера» [2] были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous-Time Markov Chain) отказоустойчивого кластера (fault-tolerant cluster).

Предлагаемый ниже практикум «Промпт-инжиниринг для моделей надежности отказоустойчивого кластера» имеет цель популяризации практических расчетов надежности «подручными средствами» - через ИИ/AI (искусственный интеллект через AI-чат, например, ChatGPT). Задача – формализовать промпты для формирования модели надежности и проведения по ней расчета стационарного коэффициента готовности, Кг.

Промпт (prompt) - запрос, текстовая инструкция, которую пользователь даёт нейросети.

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

Коэффициента готовности, напомним [1], что Кг – численно равен вероятности застать систему (в данном случае кластер) в одном из ее работоспособных состояний (сложение вероятностей каждого такого состояния). Предлагаемые подходы могут быть применены и для других сложных резервируемых структур с учетом ограничений СТМС: случайный процесс «без памяти» с дискретными состояниями и непрерывным временем, а также экспоненциальное распределение времён до отказа/восстановления, независимость отказов компонентов, см. [6], [7].

Специализированные для расчетов надёжности пакеты RAS (Reliability, Availability, and Serviceability) типа SHARPE, MEADEP, RAScad, CARMS, RAPTOR и т.п. позволяют строить и рассчитывать сложные модели. Есть более простые системы (и бесплатные), которые можно использовать для рассмотренных ранее моделей надежности отказоустойчивого кластера, например, relind.ru. Можно использовать универсальные средства (не специализированные под расчет надёжности), например, для расчета марковских цепей, или расчеты делать непосредственно в Matlab и Mathcad и подобных. Однако все это требует достаточно высокий «порог входа» и имеет встроенные в конкретный soft-продукт ограничения, как, по существу, так и по визуализации.

Рассмотрим вариант «быстрого \ легкого старта» при поддержке ИИ, причем не только для расчёта показателя надежности (Кг), но и визуализации модели и оформления результатов.

Последовательность действий:

- вводим базовый промпт (запрос) и оцениваем результат - как проверка адекватности ИИ на основе объемной постановки задачи: реализация промпта с описанием в нем деталей, включая формат представления результата;

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

Визуализацию графа переходов (марковскую цепь) можно реализовать на технологии «Диаграммы как код» (DaC, Diagram-as-Code): Graphviz (dot), Mermaid, PlantUML и даже RDF Grapher (Resource Description Framework). Публикацию результата предлагается осуществлять непосредственно в github (или githubPages), что потребует учетной записи (бесплатно для создания публичных репозитариев). Для просмотра публичного репозитария учетной записи не требуется. Если используем github, то в качестве DaC логичнее выбрать Mermaid (имеется встроенная поддержка, см. «Рисуем диаграммы Mermaid.js в README-файлах GitHub»). Для просмотра и редактирования Mermaid также можно использовать online-сервис mermaid.live.

В статье приведены принципы, ключевые описания, выводы, но на объемную «текстовку» промптов и их результатов будут даны ссылки на проект на github.

1 Трёхпозиционная модель (модель 3/2)

1.1 Базовый промпт «Трёхпозиционная модель»

В [2] на "Рис. 1 Простейшая модель надежности отказоустойчивого кластера из двух узлов (дублированная группа)» была приведена классическая (упрощенная) модель кластера. Задача базового промпта – воспроизвести модель эту модель.

Схема (граф) продублирована на рис.1 в DaC Mermaid. Напомним, что это случай (тип модели): нагруженный резерв (2* λ), одна ремонтная бригада (1* µ), без учета необнаруженного отказа и без failover & failback.

Рис. 1. Граф Трехпозиционной модели двухузлового кластера

Код mermaid:

```mermaid

flowchart LR

S2((S2))

S1((S1))

S0_fail([S0_fail])

S2 -->|"2λ"| S1

S1 -->|"μ"| S2

S1 -->|"λ"| S0_fail

S0_fail -->|"μ"| S1

```

Примеры также можно смотреть (редактировать) на mermaid.live.

Работоспособные состояния:

S2 — оба узла работоспособны, отказов нет;

S1 — один узел работоспособен, второй узел отказал или находится в ремонте.

Неработоспособное состояние:

S0_fail — оба узла отказали, кластер неработоспособен.

хотя ИИ его может построить по описанию самостоятельно.

Хотя LLM способны генерировать Mermaid-код по описанию (языком человека), в состав промпт был добавлен код mermaid (граф). Рекомендуется предоставлять явный шаблон для обеспечения воспроизводимости и корректности синтаксиса, хотя бы в стартовом промпт – это снизит число итераций (не потребует корректирующих синтаксис промптов).

Первый блок кода mermaid определяет легенду: работоспособные состояния – отображать кругом (двойные скобки «((»), а неработоспособные – овалом («([»). Далее показаны переходы с подписью интенсивностей.

Базовый промпт (Исходная модель базового промпта три состояния двухузлового кластера размещен в m3-prompt_full.md.

Его задача задать основу модели и правила оформления результата. Он задает формат DaC, как располагать базовые элементы (узлы графа S0, S1, S2_fail), формат (графической) легенды. Так как состояний у модели (графа) – три, то в названии «Трёхпозиционная модель».

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

Вариант 1 «Формулы записывай линейным текстом с использованием Unicode-символов» обусловлен:

а) GitHub Markdown и другие понимают не весь перечень команд LaTeX-обертки (т.е. будут ошибки на станице github при рендеренге LaTeX);

б) перенос в другую систему публикации потребует поддержки LaTeX, точнее всего набора команд LaTeX-обертки, сгенерированного конкретной ИИ – моделью (LLM)

Т.е. могут возникнуть сложности при переносе содержания LaTeX для публикации на иных ресурсах (даже если они имеют поддержку LaTeX).

Вариант 2 «Оформи ответ в режиме GitHub Markdown, формулы в LaTeX-обертке» - как дублирующий вариант.

Для прямого копирования ответа в github markdown некоторым моделям ИИ (например, perplexity.ai) нужно явно указывать, чтобы ИИ представил ответ в формате, совместимом с github mermaid, а при использовании LaTeX формулы обёртывал в $...$ и $$...$$.

Более того:

- проблема 1: GitHub Markdown некорректно отображает многострочные формулы с \\ и + на новых строках внутри одного $$...$$. Решение — записывать всю формулу в одну строку без переносов.

- проблема 2: GitHub Markdown некорректно отображает длинные формулы с \cdot, \left(, \right) и разрывами строк внутри $$...$$. Поэтому ИИ нужно также указывать чтобы все длинные формулы были разбиты на короткие однострочные выражения, без \left(, \right), без \cdot внутри дробей, и без переносов внутри $$...$$.

Подобное устраняется новым запросом с указанием неверного отображения информации в ответе.

1.2 Результат базового промпт

Выполнение ИИ – моделью (LLM) базового промпта должно выдать результат (perplexity.ai) с эталонным, см. m3-report.md

Формула Кг (стационарный коэффициент готовности, Unicode):

Кг = (μ² + 2λμ) / (μ² + 2λμ + 2λ²)

Или LaTeX:

Для сравнения см. формулу в [3]

Пример расчета Кг. Для данных:

- MTBF = 30 000 часов;

- MTTR = 24 часа.

Получим Кг = 0,999 998 72

2 Пятипозиционная модель (модель 5/2)

Напомним расширение \ развитие трехпозиционной модели.

В [2] на «Рис. 2 ClusterFail Failover / Failback модель надежности отказоустойчивого кластера» была показана модель 5/2, которая включает состояния Failover / Failback. На рис. 2 настоящей статьи продублируем граф с дополнительными обозначениями.

Рис. 2. Граф Пятипозиционной модели двухузлового кластера

Модель 5/2 отражает режим Nontransparent recovery, nontransparent repair и добавляет состояния Failover / Failback. В [2] рассмотрены четыре комбинации nontransparent / transparent & recovery / repair.

Эту модель (5/2) «промптить» не будем, но она важна как промежуточная для более понятного перехода к восьмипозиционной, в которую (8/2) уже будут включены состояния сбоя (Transient fault) и скрытого отказа (latent).

3 Восьмипозиционная модель (модель 8/2)

3.1 Промпт и результат

Ставится задача: Базовую Трёхпозиционную модель дополнить состояниями (позициями):

- Failover / Failback;

- состояния сбоя (для каждого узла кластера, т.е. дополнительно два состояния S2_tf и S1_tf)

- скрытого отказа (S_latent).

Рис. 3. Граф Восьмипозиционной модели двухузлового кластера

Модель 8/2 на mermaid.live.

Необнаруженный отказ был рассмотрен в разделе «4 Необнаруженный отказ» [3], например, ⴄ = 0,99 означает, что из 100 отказов один будет необнаруженный и обнаружение внешними средствами (внешним контролем) «необнаруженного» отказа (необнаруженного средствами кластера, т.е. внутри кластерным контролем) задерживается на время 1/ θ (в среднем).

В модели считается, что в состоянии сбоя узла (Transient fault) кластер находится в состоянии отказа (как и в Приложении 1 к [2]).

Проведем расчет Кг для прежних MTBF и MTTR и «малых» Failover / Failback (30 / 90 секунд соответственно). Другие величины:

- Среднее время перезапуска после временного сбоя Ttr = 180 секунд;

- Среднее время обнаружения скрытого отказа = 8 часов;

- Среднее время между временными сбоями одного узла = 1 год (8 760 часов).

Кг = 0,999 963

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

3.2 Другие расширения базовой модели

Могут быть иные установки / допущения, например, можно считать, что S2_tf – состояние работоспособности. Можно определить, что failover с некой вероятностью может быть неуспешным и тогда дополнительно будет переход из него в S0_fail (в восьмипозиционной модели) или можно предусмотреть особое состояние, например, Единая точка отказа, Single Point of Failure, SPF, см. Приложение 1 к [2], как вариант - отказ «переключателя на резерв» (виртуального).

Аналогично failover могут быть неуспешными failback или восстановление после сбоя (T_tr) и тогда должны быть предусмотрены переходы из этих состояний в состояние отказа, например, в S0_fail.

Можно добавлять внешние, в том числе, инфраструктурные, составляющие, например, в критерии отказа кластера можно учитывать отказ сетевой инфраструктуры (LAN/WAN), при этом на общей надежностной схеме вычислительная структура кластера будет размещена последовательно сетевой инфраструктуре, т.е. на схеме будут два последовательно соединенных структурных элемента, а в случае распределенного кластера, например, гео-кластера, – четыре: дублированная пара «узел кластера + сеть» (или более сложные конфигурации: магистральный участок + «последняя миля» и т.п.).

Может быть иной набор состояний, иная конфигурация кластера и допущения. Вариант модели с узлами активный \ пассивный рассмотрен в [5] и [11] (Тёплый резерв, warm standby).

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

3.3 Server vs Server

Статьи про надёжность могут писать ИТ-шники, а могут математики. При этом будет различаться терминология, например, «Server». Математики в статьях по теории «Систем массового обслуживания», СМО (например, [9]) в части моделирования вычислительных систем под сервер вводить «Server», например, «Server vacation», это Ремонтник (а не вычислительный сервер), например, «Отдых ремонтника» (repairman). В такой трактовке Отказ сервера – это Отказ Ремонтника. В этой конкретной статье «Server» (Сервер) — это не узел вычислительного кластера, а ремонтный прибор (ремонтник / ремонтная бригада), который восстанавливает отказавшие рабочие элементы системы. Возникает классическая путаница терминов теории СМО: авторы рассматривают задачу о ремонте машин (Machine Repair Problem). В ней «клиентами» (заявками в очереди) являются отказавшие узлы кластера (units / machines) а «сервером» (server) называют того, кто их обслуживает (ремонтирует). Авторы используют слова Server и Repairman как синонимы.

Вариант модели, когда выделены разные состояния для ремонтной бригады (vacation, busy, broken) показан в [9], «Ремонтник также может отказать и потребовать ремонта» («The repairman may also break down and require repair»). Смотрится странно, когда первую сломанную ремонтную бригаду начинает чинить вторая ремонтная бригада с такой-то интенсивностью. Это к вопросу разных взглядов на процесс ИТ-шника и математика.

Полагаю, что подобное (как «ремонт сломанной ремонтной бригады», так и заболел, ушел в отпуск и т.п.) - неоправданное усложнение задачи, т.к. подобное можно заложить (учесть) в μ (Repair rate, интенсивность ремонта, 1/MTTR), тем более с учетом редких отказов (узлы кластера - высоконадёжные элементы). Условные «Иванов и Петров» могут заболеть, но ремонтная бригада – нет (есть замещение и т.п.).

4 Двенадцатипозиционная модель (модель 12/3)

4.1 Полный промпт и результат

Рассмотрим трехузловый кластер: промпт prompt12_full.md, результат: report12_full.md.

Граф показан на рис. 4., в двенадцатипозиционной модели добавлен узел и соответствующие новому узлу три состояния: сбоя, failover (переконфигурирование) и failback (переключение после восстановления узла).

Рис. 4. Граф Двенадцатипозиционной модели трехузлового кластера

Модель 12/3 на mermaid.live.

Кг = 0,999 947

Аналогичным образом можно увеличивать кратность резерва.

4.2 Кумулятивный запрос

Выше были показаны полные промпты. Однако можно использовать кумулятивный запрос (cumulative - «накопительный»), т.е. на основе Базового промпта (такого-то) сделай … и далее второй промпт с уточнением новой конфигурации.

Эксперимент. Выбираем новую ИИ-модель, например, deepseek (ранее использовал perplexity). Ставим задачу исполнить prompt8_full.md

Смотрим и видим, что в ответе проблемы с LaTeX. Даем технический промпт – доработку:

Ты не учел «Важные требования к LaTeX-формулам для GitHub Markdown:». При копировании и вставке в GitHub не отображается LaTeX, т.е. нужно добавить $$ … $$ и для inline-формул использовать $...$. Исправь ответ.

Смотрим результат report8_full_deepseek.md и сверяем с report8_full.md. Убеждаемся, что «все хорошо». Далее даем на выполнение кумулятивный промпт:

Составь модель и выполни расчет Двенадцатипозиционной модели трехузлового кластера (модель 12/3).

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

- S3 — три узла работоспособны, отказов нет;

- S3_tf — временный сбой одного из трех узлов, два узла работоспособны, но считаем, что кластер в состоянии отказа (на время перезагрузки после сбоя);

- S3_failover при переходе из S3 в S2 (переконфигурирование)

- S2_failback при переходе из S2 в S3

Требования к оформлению оставь прежними (как и для Восьмипозиционной модели).

Для примера расчета используй те же значения, что и для Восьмипозиционной модели.

Сверяем прежний report12_full.md (на основе полного промпт prompt12_full.md) с полученным report12_cum_deepseek.md. Убеждаемся, что «все хорошо».

5 Краткий анализ полученных моделей

Сравним Кг моделей m3, m8, m12.

Сравнение Кг показывает, что при усложнении модели (повышение адекватности модели) значение Кг начинает снижаться и «заветные» для высоконадёжного кластера «пять девяток», получаемые в явно упрощенных моделях, начинают снижать цифру (показатель).

- модель 3/2 (базовая): 0,999 998 7, ожидаемый простой за год ~40 с.

- модель 8/2 (расширенная): 0,999 963, ожидаемый простой за год ~19 мин.

- модель 12/3 (расширенная): 0,999 947, ожидаемый простой за год ~28 мин.

Некоторые выводы:

1 Базовая модель 3/2 имеет наивысшую готовность (~40 секунд простоя в год), так как не учитывает transient faults, latent failures, failover и failback.

2 Модель 8/2 имеет готовность ниже на порядок (~19 минут простоя в год) из-за дополнительных неработоспособных состояний.

3 Модель 12/3 имеет ещё более низкую готовность (~28 минут простоя в год), чем 8/2, при тех же параметрах.

3.1 Феномен «двухузловая архитектура может быть предпочтительнее трёхузловой»: при η=0.99 и Tdetect=8 ч двухузловая расширенная модель (8/2) обеспечивает лучшую готовность, чем трёхузловая (12/3).

3.2 Причина: в 12/3 больше комбинаций скрытых отказов (3 узла вместо 2), что увеличивает вклад S_latent и связанных состояний в неготовность.

3.3 Вывод: Для систем с неполным диагностическим охватом (η<0.999) и длительным временем внешнего контроля (T_detect>1 ч) двухузловая архитектура может быть предпочтительнее трёхузловой с точки зрения стационарной готовности, даже при наличии одного дополнительного резервного узла.

Сравнение Кг и подробный анализ феномена (с анализом подобных исследований) рассмотрен в analysis.md.

Заключение

ИИ меняет привычный мир. Он позволяет заменить специализированные программы (калькуляторы) расчета надёжности: частично в части построения модели и на 100% в части расчета имеющейся модели, включая, формирование по графу системы уравнений, ее решение, подстановку значений и т.п.

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

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

Для повышения доверия: один и тот же промпт задать на исполнение разным моделям ИИ (LLM), а отдельной группе ИИ – сравнить полученные результаты.

Рекомендуется в промпт добавлять «Приведи замечания к промпт».

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

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

Однако, использование ИИ-модели для расчета надёжности сложных систем является наиболее легким стартом и эффективным инструментом, включающим мощнейший мыслящий механизм (AI). Среди простых советов его использования можно привести: на старте исследования использование типовых промпт с эталоном – ответом (дать ИИ «Точку опоры»); ответы по дальнейшим запросам сверять разными ИИ-моделями («Доверяй, но проверяй»); в сам промпт вставлять задачу оценки полноты и качества (неточности, противоречия и т.п.) текущего промпт (с описанием модели) и самой ИИ-модели скорректировать промпт (Обратная связь). Идеальные ответы от ИИ бывают не всегда, иногда нужно ИИ поправлять, например, дать корректирующий промпт. Однако в отличие от готовых программ не нужно вникать в часто сложную (непонятную) логику программы, странности ее интерфейса, а можно задать в промпте требования к формату представления ответа и запрашивать любой уровень детализации (пояснений) полученного ответа. Обсуждение модели, ее модификация, поиск подобных исследований и все это «человеческом» языком и все это бесплатно и на высоком инженерном уровне. В исследовании приведены артефакты от ИИ perplexity и deepseek, но при тестировании использовались и другие ИИ-модели.

Одним из направлений развития концепта может служить «семантическая версия», когда вначале создается базовая онтология надежности кластера, а потом на ее основе строится моделирование конкретной конфигурации кластера. Это позволит систематизировано и на формальном языке знаний фиксировать параметры модели. Концепт такой формализации (на основе строгого формализма) кроме онтологии позволит использовать штатные механизмы \ инструменты \ возможности Linked Data, включая языки запросов и верификации, reasoned etc. Кроме того, формализации модели в RDF (Resource Description Framework, «среда описания ресурса») является также DaC-технологией, где с помощью фильтров может быть получено привычное отображение марковской цепи / графа, т.е. управление визуализацией (RDF grapher) с использованием фильтров видимости: «тип сущности», «предикат» и др.

Материалы

Список файлов проекта cluster_dependability (число состояний модели / число узлов кластера),

- Модель 3/2:

-- промпт полный prompt3_full.md

-- результат report3_full.md

- Модель 8/2:

-- промпт полный prompt8_full.md

-- результат report8_full.md

-- результат (deepseek) report8_full_deepseek.md

- Модель 12/3:

-- промпт полный prompt12_full.md

-- результат report12_full.md

-- промпт кумулятивный и результат (deepseek) report12_cum_deepseek.md

- Анализ

-- Анализ Кг и феномена analysis.md

Источники:

[1] Надёжность, устойчивость, доступность

[2] Базовые модели надежности отказоустойчивого кластера

[3] Подход к оценке надежности кластерных структур. Научные ведомости 2010 № 13 (84). Выпуск 15/1 (УДК 519.223.42)

[4] Резервный центр обработки данных. Оценка надежности. Электроника НТБ. Выпуск 4/20

[5] МОДЕЛЬ НАДЕЖНОСТИ ДВУХУЗЛОВОГО КЛАСТЕРА ВЫСОКОЙ ГОТОВНОСТИ

[6] ТЕОРИЯ СЛУЧАЙНЫХ ПРОЦЕССОВ. Часть 2. Марковские процессы

[7] Краткое введение в цепи Маркова

[8] Boyd M.A. "An Introduction to Markov Modeling: Concepts and Uses". NASA, 1998.

Руководство по марковскому моделированию с примерами imperfect coverage

[9] Jain M., Meena R.K. "Fault tolerant system with imperfect coverage, reboot and server vacation". Journal of Industrial Engineering International, 2017

Модель fault-tolerant системы с imperfect coverage и reboot

[10] Comparative analysis of the machine repair Problem with imperfect coverage and service pressure condition

[11] Comparative analysis of the machine repair Problem with imperfect coverage and service pressure condition

Machine Repair Problem (MRP) — Задача о ремонте машин. M/M/R – Markovian/ Markovian/ Repairmen.

On-Line ресурсы mermaid:

https://mermaid.live

https://toolact.com/ru/mermaid

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

sonikdixi — Mon, 14 Sep 2026 17:45:38 +0000

Привет, Хабр! Сразу расставлю точки над «i»: я не программист. По образованию я компьютерщик (первый диплом «Компьютерные сети») и специалист по прикладной информатике (диплом в вузе вообще был по автоматизации на 1С).

Работаю системным администратором: начинала в небольшой провинциальной компании, где ты многорукий Шива, сейчас администрирую в компании покрупнее, и нас таких многоруких уже двое. Как устроены компьютеры, сети, операционные системы и железо — я понимаю в теории и на практике. Но мобильные приложения (да и десктопные) на Flutter и Dart никогда раньше не делала. Максимум — скрипты на Python и PowerShell для решения прикладных задач.

Этот пост — история о наболевшей сисадминской рутине, долгой упорной сборке по вечерам и тренажёре‑симуляторе «Проводник», который на днях вышел в RuStore. Сразу предупрежу: описание получилось подробным. За полгода работы над проектом мне стало казаться важным буквально всё, поэтому выделить главное оказалось неожиданно сложно.

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

Ступор перед словом «Ошибка»: Посреди экрана выскакивает стандартное предупреждение: «Введите дату в формате ДД.ММ.ГГГГ». Человек даже не пытается прочитать текст. Мозг блокируется незнакомым окном, руки опускаются: «Оно сломалось, сделайте что‑нибудь!».
Архивный бермудский треугольник: Человек получает по почте .zip, дважды кликает по вложенному файлу, полдня вносит правки в таблицу, жмет «Сохранить», закрывает… а назавтра в слезах: «Куда пропал отчет?!». А документ остался во временной системной папке Temp, которую Windows благополучно вычистила. Объяснить на словах, почему архив — это сжатая коробка, а не обычная папка, получается далеко не с первого раза.
Страх нажать «не туда»: На рабочем компьютере крутятся важные файлы, 1С, клиент‑банки. Пользователь панически боится тыкать в кнопки: «А вдруг я сейчас нажму правой кнопкой мыши и всё сломаю?».

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

Интерфейс программы на десктопе

Как устроен симулятор изнутри: честная виртуальная система

Чтобы симулятор действительно учил, а не водил пользователя «по рельсам», пришлось с нуля воссоздать в памяти логику операционной системы:

Компонент	Что внутри
Оболочка обучения	Курсы, квесты ситуаций, квизы, профиль, магазин тем
Ядро симулятора	Виртуальная файловая система, системные события, оконный менеджер (перетаскивание, фокус), подсказки
Окружения рабочего стола	Эмуляция интерфейсов Windows 11, Windows 10 и Astra Linux
Экосистема программ	20+ утилит: проводник, браузер со сценариями, диспетчер задач, параметры, терминал, офис, антивирус, периферия
Интерактивные мини‑игры	Детектор фишинга, кабели ПК, сортировка файлов, спринт горячих клавиш

Пример урока

Честная файловая система в памяти

В оперативной памяти крутится реальная структура файлов:

Диски и пути: Для Windows поддерживаются диски C:\, D:\, папки «Рабочий стол», «Документы», «Загрузки». Для Astra Linux — домашний каталог /home/user.
Файлы и расширения: У каждого файла есть имя, размер и расширение (.docx, .xlsx, .zip, .exe, .pdf, .txt, .mp3). Если стереть расширение .docx, файл честно теряет привязку к программе, а симулятор наглядно показывает, почему он перестал открываться.
Полноценная Корзина: При удалении файлы перемещаются в Корзину с сохранением исходного пути. Их можно восстановить на прежнее место или очистить Корзину насовсем.
Архивация ZIP: Можно нажать правой кнопкой по папке, выбрать «Сжать в ZIP‑архив», а затем реально распаковать его в обычную директорию.

Окна и рабочий стол

Любое окно свободно перетаскивается пальцем за заголовок, сворачивается в панель задач, разворачивается и закрывается.
Нажатие на фоновое окно выдвигает его на передний план.
Полноценная панель задач с запущенными приложениями, часами, регулятором громкости, переключением языка (RU/EN) и меню «Пуск».
Окна подтверждения прав администратора (UAC) с затемнением экрана — чтобы приучить человека читать, что именно пытается запуститься в системе.

Интерфейс симулятора при прохождении урока

Программы: здесь не только проводник

В симуляторе воссоздано более 20 утилит, с которыми офисный сотрудник сталкивается каждый день:

Проводник (File Explorer): Настоящий файловый менеджер. Хлебные крошки в адресной строке (Этот компьютер > Диск C > Документы), смена вида (плитка или таблица со свойствами), контекстное меню («Создать папку», «Переименовать», «Копировать», «Вставить», «Свойства»), поиск файлов по названию. Поддерживает также сетевые папки.
Диспетчер задач: Разделен на вкладки «Процессы» и «Автозагрузка». Процессы симулируют нагрузку на процессор и память. В уроках нужно найти зависшую программу со статусом «Не отвечает» и снять задачу (не задев системные службы), а также отключить лишнее из автозагрузки для ускорения старта ПК.
Параметры Windows / Панель управления Astra Linux:
- Вкладка «Память» — поиск временных файлов и штатная очистка диска вместо опасного ручного удаления системных папок.
- Вкладка «Приложения» — корректное удаление программ через деинсталлятор вместо перетаскивания ярлыка в корзину.
- «Центр обновления» — проверка обновлений, загрузка KB‑пакетов и штатный перезапуск системы.
Офисный пакет и просмотрщики:
- Блокнот: редактирование текста, меню «Файл > Сохранить как...», выбор кодировок и ассоциации файлов.
- Office Writer: симулятор текстового редактора для документов .doc, .docx и .odt.
- Таблицы: просмотр и проверка табличных файлов .xlsx и .csv.
- Просмотр PDF: открытие договоров, счетов и официальных бланков.
- Графика: просмотр фото и редактор Paint.
Антивирус («Антивирус РФ»): Программа с кнопкой полного сканирования, бегущей полосой проверки файлов виртуального диска, отчетом о найденных подозрительных .exe и возможностью отправить их в карантин или удалить.
Офисная периферия:
- Очередь печати: окно принтера, где зависает поврежденный документ и блокирует печать всей компании (учимся очищать очередь).
- Сканирование: интерфейс сканера с предпросмотром документа и сохранением в систему.
Командная строка и Linux‑терминал: Для уроков по отечественной Astra Linux. Поддерживает ввод консольных команд: ls, cd, dir, cat, mkdir, rm, ping, вызов справки и запуск через sudo.
Установщики программ: Пошаговые мастера установки (.exe, пакеты .msi и .deb для Linux) с лицензионными соглашениями, выбором папки и окнами контроля учетных записей (UAC).
Калькулятор и медиаплеер: Для воспроизведения звуковых файлов и базовых расчетов.

Виртуальный браузер со сценариями из жизни

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

Интерфейс: Вкладки (открытие, закрытие, переключение), адресная строка с индикатором безопасности (замочек HTTPS), кнопки навигации («Назад / Вперед / Обновить»), закладки и режим «Инкогнито».
Служебные разделы: История просмотров (с кнопкой очистки), менеджер сохраненных паролей, список загрузок и настройки.
Встроенный поисковик: Учебный поиск, который процедурно генерирует списки сайтов и краткие ответы под запросы.
Интерактивные учебные сайты и сервисы:
- Почтовый клиент: Письма от коллег, спам‑рассылки о «выигрышах 500 000 рублей», фальшивые акты сверки со вложенными вирусами Счет_на_оплату.exe. Учимся распознавать подвох и отправлять письма в Спам.
- Портал Госуслуг.
- Энциклопедия (Википедия) и социальная сеть «ВОбщении».
- Фейковые интернет‑магазины.
- Ловушки с подписками.

Симуляция работы сетевой карты и сетевых возможностей ОС

В симуляторе реализована полноценная модель сетевой карты и сетевого адаптера, позволяющая гибко управлять параметрами подключения виртуального ПК: вручную задавать IP‑адрес, маску подсети, основной шлюз и предпочитаемый DNS‑сервер.

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

«Сценарии реальных ситуаций»: спасаем коллег от паники

В приложении есть режим «Практические ситуации» — сюжетные квесты с жизненными офисными героями, например:

«Порядок на столе» (Менеджер Олег): На рабочем столе каша из отчетов за разные месяцы и картинок с котиками. Создаем структуру папок, наводим порядок и удаляем мусор.
«Случайное удаление» (Стажёр Алексей): Паника: «Шеф меня убьет, я стёр договор!». Задача — зайти в Корзину, спасти нужный документ и очистить Корзину от остального мусора (а если случайно очистить Корзину вместе с договором — симулятор вовремя остановит).
«Файлы для налоговой» (Главбух Марина): Подключить флешку, упаковать отчетность в ZIP‑архив, скопировать на накопитель и безопасно извлечь флешку.
«Странный рецепт» (Дедушка Иван): Прислали файл без расширения (.abc). Учимся смотреть свойства файла и открывать его через «Открыть с помощью...» в Блокноте.
«Завис фотоальбом» (Архивариус Анна): Программа зависла со статусом «Не отвечает». Задача — открыть Диспетчер задач и снять только зависшее приложение, не уронив систему.

Магазин обоев и тем оформления

За прохождение уроков и квестов начисляются внутриигровые монеты. Их можно потратить во встроенном Магазине оформления:

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

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

Как я это собирала: нейросети как напарник и бесконечные тесты

Так как мобильные приложения я раньше никогда не делала, разработку вела в связке с нейросетями (в основном писала запросы в DeepSeek и Gemini). Но хочу сразу развеять иллюзию про «нажала кнопку — нейросеть сделала готовое приложение»:

Нейросеть не понимает сути за вас: Если просто попросить её «сделай симулятор ПК», получится нерабочая пустышка. Мне приходилось детально продумывать каждый шаг: как должна вести себя система при клике на файл, какие параметры передавать при перетаскивании окна, как реагировать на отключение флешки.
Метод проб и ошибок: Я описывала задачу обычными словами, забирала код, собирала проект на телефоне, находила баги (например: окно свернули, а клики сквозь него все равно нажимаются на рабочем столе), возвращалась с текстом ошибки и просила переписать конкретный кусок.
Бесконечное ручное тестирование: 95% каждого сценария, кнопки и меню я сотни раз протыкала пальцем на своих устройствах. На всё ушло около полугода (и это только начало).

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

Что есть сейчас и что дальше

В приложении уже доступно:

3 курса:
- Файловые системы (30 уроков: от файлов и папок до прав и архивов).
- Безопасность и интернет (15 уроков: фишинг, спам, надежные пароли).
- Скорая помощь ПК (15 уроков: диспетчер задач, автозагрузка, очистка диска, обновления).
  В ближайшем обновлении появятся курсы для начала работы с отечественными Linux для новичков, объясняющими отличия от привычной Windows и базовой работы с ними. В будущем курсы будут появляться и более продвинутые.
Свободный режим с чистыми рабочими столами подобными Windows 10, Windows 11 и Astra Linux.
Практические ситуации с офисными героями.
4 мини‑игры: проверка писем на фишинг, подключение проводов к системному блоку, сортировка файлов на скорость и спринт горячих клавиш.

Мини‑игра

Нужен ваш краш‑тест!

Приложение полностью бесплатное и уже доступно в каталоге.

👉 Ссылка на «Проводник» в RuStore: https://www.rustore.ru/catalog/app/ru.provodnik.app

Огромная просьба:

Напишите, какие у вас есть предложения и замечания, может просто вопросы по архитектуре.
Покажите тем, кто боится техники: Если у вас на работе есть начинающие коллеги, а дома — родители, бабушки или дети, дайте им немного попробовать Проводник. Посмотрите со стороны: где они спотыкаются? Что вызывает трудности?
Напишите в комментариях: С какими еще типичными проблемами и курьезными ошибками пользователей вы сталкиваетесь на работе? Буду рада добавить новые сценарии в обновления!

P. S. В первый раз пишу статью. Извините за примитивное оформление. Я старалась)

Сколько данных нужно, чтобы обучить модель для стройки?

Arkadiy_Froym — Mon, 14 Sep 2026 16:54:26 +0000

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

Минимальный объём данных, необходимых для работы

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

Сложность классов, а также разнообразие условий здесь играют важную роль. Если объект крупный и его легко различить, то нам потребуется одно покрытие. Если же объект маленький и находится на заднем плане, то в таком случае необходимо другое покрытие. Иногда приходится использовать сотни тысяч реальных размеченных кадров, и тогда, как правило, применяется аугментация. Чтобы проверить, готова ли модель к production, нужно прогнать её на тестовой выборке. Если данных много - это хорошо, но важно понимать, представлены ли в этих данных условия, в которых системе предстоит работать.

Различия в моделях при разном количестве размеченных примеров

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

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

Самые сложные классы для сбора данных

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

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

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

Разметка данных

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

Внутри нашей инфраструктуры был развёрнут CVAT, который связан с инструментами автоматического сбора датасета. Когда появляются новые материалы, то они направляются на очередные итерации разметки и дообучения. При этом подготовленная разметка проходит внутреннюю валидацию с участием специалистов, лишь после чего используется в обучении. При большом масштабе очень важно следить за качеством разметки. Мы не рассматриваем её как вспомогательную операцию. Она является самостоятельной частью разработки модели. Если появляются ошибки в классах, обнаруживаются пропущенные объекты и неправильно обозначенные границы, то создаются неверные обучающие сигналы. Разметка - это непрерывный цикл, и эта непрерывность показана на отрисованной мной схеме:

Датасет и специфика стройки

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

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

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

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

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

Дообучение и адаптация моделей

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

Чтобы дать техническую оценку, мы используем precision (это доля правильных срабатываний), recall (доля обнаруженных целевых объектов или событий) и F1 (объединяется precision и recall в одном показателе). Качество измеряется на отдельной тестовой выборке, которая не участвует в обучении. Эти значения необходимо приводить вместе с описанием задачи и правил оценки. Помимо внутренних замеров, мы также сравниваем модели с другими российскими командами на общей выборке китайского строительного датасета.

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

Вебхук ЮKassa принимал payment.succeeded на веру. Подделать оплату брони можно было одним curl

r_o_m_k_o_l_a — Mon, 14 Sep 2026 16:29:07 +0000

Разбираю находку из технического аудита сервиса аренды авто: вебхук /payments/webhook/yukassa помечал бронь оплаченной по одному полю из тела запроса, которое присылает клиент, а не банк. Файл аудита датирован 5 июля 2026, фикс смержен 8 июля — привожу код до и после, тесты и то, что мы сознательно не стали чинить в этом же PR.

Как это выглядело до

Обработчик вебхука был устроен предельно просто:

async def handle_yukassa_webhook(self, payload: dict, db: AsyncSession) -> None:
    """Обрабатывает входящий webhook от ЮKassa."""
    event_type = payload.get("event")
    payment_data = payload.get("object", {})
    gateway_payment_id = payment_data.get("id")

    if not gateway_payment_id:
        return

    result = await db.execute(
        select(Payment).where(Payment.gateway_payment_id == gateway_payment_id)
    )
    payment = result.scalar_one_or_none()
    if not payment:
        return

    if event_type == "payment.succeeded":
        payment.status = PaymentStatus.succeeded
        # обновление брони, отправка уведомления...

Единственная проверка — что такой gateway_payment_id вообще существует в нашей базе. Дальше код верит полю event из тела запроса. Значит запрос вида

POST /payments/webhook/yukassa
{"event": "payment.succeeded", "object": {"id": "<gateway_payment_id уже созданной pending-брони>"}}

без единого заголовка авторизации переводил бронь в статус «оплачено». gateway_payment_id не секрет — он приходит клиенту сразу после создания платежа, в ответе на POST /bookings/{id}/pay. То есть у обычного пользователя, который просто открыл бронь и не заплатил, на руках было всё, что нужно для подделки.

Почему не помогает «просто добавить подпись»

Первая мысль — проверять подпись вебхука, как у Stripe или у большинства эквайеров. Полез разбираться, что у ЮKassa с этим есть. Официальная документация ЮKassa действительно описывает заголовок Webhook-Signature с HMAC-SHA256 по webhook_key из личного кабинета — но как дополнительный, не обязательный механизм. Базовая рекомендация ЮKassa — два других способа: проверка по IP-адресу отправителя и сверка статуса через обратный запрос к API. Наша интеграция на момент аудита webhook_key не заводила вообще, то есть подписи в заголовках попросту не было — только тело и IP.

От IP-фильтра отказались: инфраструктура за реверс-прокси, IP клиента до бэкенда доходит через цепочку заголовков, и сверять его с диапазоном ЮKassa означало бы держать этот список в актуальном состоянии и доверять X-Forwarded-For — то есть менять модель доверия на другую модель доверия. Обратный запрос надёжнее: спросить у самой ЮKassa, что происходит с этим платежом, вместо того чтобы гадать по заголовкам.

Что сделали вместо

async def _fetch_gateway_payment(self, gateway_payment_id: str) -> dict:
    """Запрашивает актуальное состояние платежа у ЮKassa.

    Бросает исключение при недоступности API — вебхук ответит 5xx,
    и ЮKassa повторит уведомление позже (fail-closed).
    """
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"https://api.yookassa.ru/v3/payments/{gateway_payment_id}",
            auth=(settings.YUKASSA_SHOP_ID, settings.YUKASSA_SECRET_KEY),
            timeout=30,
        )
        resp.raise_for_status()
        return resp.json()

Дальше в handle_yukassa_webhook статус и сумма берутся только из ответа этого запроса, тело входящего вебхука используется исключительно как триггер «сходи проверь»:

gateway_status читается из ответа API, не из payload["event"];
сумма и валюта сверяются с записью Payment в нашей базе — при расхождении статус не меняется, инцидент уходит в лог, а gateway_response сохраняется целиком для разбора;
если запрос к API ЮKassa падает (таймаут, 5xx на их стороне) — вебхук отвечает 5xx, ЮKassa переотправит уведомление позже. Это fail-closed: лучше временная задержка подтверждения, чем тихое принятие на веру;
финальные статусы (succeeded, failed) повторным вебхуком не переписываются — без этого повторная доставка того же события просто лишний раз дергала бы API ЮKassa.

Дев-режим без ключей ЮKassa (YUKASSA_SHOP_ID/YUKASSA_SECRET_KEY пустые) оставили как было — доверяет телу запроса, потому что реального шлюза там нет и подделывать нечего.

Диф вышел небольшим: payment_service.py — +62/-5 строк, новый файл тестов — 205 строк.

Тесты

Файл tests/test_payment_webhook.py, 6 новых сценариев, эквайер замокан:

Сценарий	Что проверяет
`test_forged_webhook_ignored_when_gateway_says_pending`	подделанный `payment.succeeded`, но у ЮKassa платёж ещё `pending` → статус в базе не меняется
`test_webhook_amount_mismatch_ignored`	ЮKassa подтверждает `succeeded`, но сумма не совпадает (1 ₽ вместо 2300 ₽) → статус не меняется
`test_webhook_confirmed_success_marks_paid`	сумма и статус совпадают → бронь переходит в `paid`
`test_webhook_canceled_marks_failed`	отмена подтверждена шлюзом → `failed`
`test_webhook_final_status_not_rewritten`	вебхук по уже `succeeded` платежу — `_fetch_gateway_payment` не должен вызываться вовсе (замокан на `AssertionError` при вызове)
`test_webhook_unknown_payment_ignored`	неизвестный `gateway_payment_id` — тоже не должен трогать API

Локально пакет тестов прошёл зелёным, ruff без замечаний. Отдельно стоит сказать, что именно поэтому баг до аудита не поймали: юнит-тесты проверяли логику обработчика саму на себя — с точки зрения теста «вебхук с payment.succeeded переводит бронь в paid» было ожидаемым поведением, а не дырой. Отсутствие проверки источника события не тестируется тестами, которые сами же и формируют доверенный вход. Нашли не автотестом, а при ручном чтении кода в рамках аудита.

Что не стали чинить в этом же PR

Три вещи сознательно оставлены на потом, обе — в описании PR:

IP-allowlist так и не добавлен — второй официально рекомендованный ЮKassa способ. Сейчас единственная линия защиты — обратная проверка через API, и это, строго говоря, делает вебхук почти декоративным: он всего лишь сигнал «сходи спроси у ЮKassa», а не источник истины. Работает, но лишний слой не помешал бы.
webhook_key и HMAC-подпись не подключены. Раз уж заголовок Webhook-Signature существует — его игнорирование означает один лишний сетевой запрос к ЮKassa на каждое уведомление, который можно было бы не делать, если бы подпись проверялась локально.
Рядом, в соседнем PR (идемпотентность initiate_payment, аудит HIGH №11), нашли ещё один смэлл: get_db коммитит транзакцию в конце запроса, а сервис вдобавок коммитит явно сам — двойной commit(). Решили не трогать: повторный коммит уже пустой транзакции безвреден, а разносить ответственность за транзакции — отдельная задача, и в PR с критической уязвимостью лишний рефакторинг только повышает шанс что-то сломать в неподходящий момент.

Изначально хотелось закрыть всё сразу — signature, IP-фильтр и двойной коммит заодно с основной дырой. Оставили только реверс-проверку, потому что диф с четырьмя параллельными изменениями в одном платёжном файле труднее ревьюить и опаснее откатывать, если что-то не так. Минимальный диф на критичном участке дороже одной строки в чейнджлоге.

Проверить, эксплуатировали ли дыру до фикса, задним числом нельзя: подделанный запрос от обычного payment.succeeded в логах ничем не отличается — оба просто POST на тот же путь. Единственная граница, которая появилась после фикса, — теперь у каждого такого события есть подтверждающий ответ ЮKassa, который можно поднять и сверить.

Код как борьба. Кратчайшая история IT. 5. Гэри Килдалл

magnusroot — Mon, 14 Sep 2026 16:00:03 +0000

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

Прошлые статьи цикла:

Точка входа

0. Лейбниц, Бэббидж и Лавлейс

1. Алан Тьюринг

2. Джон фон Нейман

3. Клод Шеннон

4. Кен Томпсон и Деннис Ритчи

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

А потом мы разберём, что из этого правда.

Это шестая статья цикла “Код как борьба: Кратчайшая история IT”. И сегодня будет необычный формат - не просто биография, а разоблачение. Потому что самая знаменитая деталь в истории нашего сегодняшнего героя оказалась мифом. Причём мифом, задокументированно опровергнутым самими историческими источниками.

Погнали.

Часть первая. Изобретение, о котором обычно даже не вспоминают

Гэри Килдалл родился в 1942 году в Сиэтле, в семье, державшей мореходную школу. Получил докторскую степень по информатике в Вашингтонском университете в 1972 году - на тот момент одну из первых подобных степеней в стране вообще.

Преподавал в Военно-морской аспирантуре в Монтерее, одновременно консультировал Intel по языку программирования PL/M и ранним встроенным системам. А в 1974 году пишет CP/M - Control Program for Microcomputers, операционную систему для одних из первых микропроцессоров Intel.

Вместе с женой, Дороти Килдалл, он основывает компанию Digital Research для коммерциализации CP/M. И вот здесь стоит сразу подчеркнуть, Дороти - это не просто “жена изобретателя” где-то на заднем плане. Она содиректор компании и, по многим свидетельствам, куда более жёсткий и опытный переговорщик в деловых вопросах, чем сам Гэри, склонный скорее к инженерному, чем коммерческому складу мышления. Это важная деталь, к которой мы ещё вернёмся.

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

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

И вот по мере того, как множество разных производителей начинают лицензировать CP/M для своих несовместимых друг с другом машин, Килдалл вводит концепцию BIOS - Basic Input/Output System. Небольшой, специфичный для конкретного железа программный слой, отделяющий аппаратно-зависимый код от основной, единой для всех машин части операционной системы.

Это позволяет CP/M работать на множестве разных компьютеров с минимальной адаптацией. Производителю железа достаточно написать сравнительно небольшой BIOS под свою конкретную машину, а не переписывать всю операционную систему с нуля.

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

К началу восьмидесятых CP/M становится де-факто отраслевым стандартом операционной системы для микрокомпьютеров. Digital Research продаёт сотни тысяч лицензий. И на определённом историческом отрезке именно Килдалл, а не кто-либо ещё, выглядит наиболее вероятным кандидатом на роль человека, который определит, какая операционная система будет доминировать в грядущую эпоху персональных компьютеров.

Часть вторая. Легенда, которую вы, скорее всего, уже слышали

А теперь давайте я перескажу миф в его самой распространённой форме так, как его годами тиражировали, в том числе крупные издания вроде Bloomberg.

Летом 1980 года представители IBM прибывают в штаб-квартиру Digital Research в Пасифик-Гроув, Калифорния. Обсудить лицензирование CP/M для готовящегося IBM PC, потенциально одну из крупнейших сделок в истории компьютерной индустрии.

Но в этот самый день Гэри Килдалл, вместо того чтобы вести переговоры лично, решает покататься на собственном самолёте для развлечения. И, вернувшись, упускает возможность заключить сделку. Разочарованные представители IBM, не сумев договориться с Digital Research, обращаются к молодой компании Microsoft Билла Гейтса и та соглашается предоставить операционную систему, ставшую в итоге MS-DOS. Определившую судьбу компьютерной индустрии на десятилетия вперёд.

Знакомая история, правда? И вот важная деталь, именно эту версию годами растиражировал сам Билл Гейтс в многочисленных интервью - в частности, в уже упомянутой в прошлом эпизоде книге “Fire in the Valley” приводится его прямая формулировка: “в тот день Гэри катался на самолёте”. То есть версию истории, крайне выгодную для нарратива о собственном успехе Microsoft - упорный, серьёзный подход Гейтса против беспечности конкурента, запустил в оборот прямой конкурент и бенефициар исхода этих переговоров. Эта версия была настолько общепринята, что даже известные технологические авторы, вроде Питера Нортона, ошибочно включали её в свои книги как фактическую историю.

А теперь, что произошло на самом деле.

Часть третья. Разбираем миф по косточкам

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

Что действительно произошло в тот день. Представители IBM позвонили в Digital Research 21 августа 1980 года, а сама встреча состоялась на следующий день, 22 августа - и действительно по инициативе самого Билла Гейтса, который в разговоре с представителем IBM Джеком Сэмсом сам порекомендовал обратиться к Килдаллу за операционной системой, поскольку у Microsoft на тот момент своей ОС попросту не было. Килдалл в этот день действительно отсутствовал в офисе. Но, по одной из версий, изложенной в его собственных воспоминаниях, он вместе с коллегой Томом Роландером был занят доставкой программного обеспечения клиенту на собственном самолёте. По другой версии, речь шла о встрече с Hewlett-Packard тем же утром. Это была деловая, а не исключительно развлекательная поездка. Уже меняет тональность истории, правда?

Переговоры в его отсутствие вела его жена и деловой партнёр Дороти Килдалл вместе с юрисконсультом компании. И IBM настаивала на подписании соглашения о неразглашении ещё до того, как объяснить цель визита. Дороти, действуя строго в рамках корпоративных процедур, отказалась подписывать документ такого рода без консультации с Гэри.

И вот это, на минуточку, разумное, профессиональное деловое поведение. А не досадная помеха, как это представлено в упрощённой версии мифа.

Что случилось дальше, тут версии расходятся даже в наиболее авторитетных источниках. По одной версии, Килдалл, вернувшись позже в тот же день, лично встретился с представителем IBM и возобновил переговоры. Сам Джек Сэмс впоследствии утверждал, что личной встречи между ними вообще не произошло.

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

Дети Килдалла, публикуя посмертные воспоминания отца через Музей компьютерной истории в 2016 году, прямо назвали историю про самолёт мифом, который несправедливо превращает их отца в фигуру “мог бы, да не смог” и заслоняет собой его реальный вклад как изобретателя ключевых технологий, на которых до сих пор работают компьютерные платформы.

Часть четвёртая. Как Microsoft всё-таки получила операционную систему

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

После того как переговоры с Digital Research не привели к соглашению, IBM обращается обратно к Microsoft. Гейтс на тот момент не располагает собственной операционной системой, но приобретает права на систему 86-DOS, разработанную программистом Тимом Патерсоном в компании Seattle Computer Products. Сама 86-DOS, кстати, структурно и функционально во многом напоминала CP/M, вопрос о степени заимствования идей, а возможно, и кода, стал позже предметом отдельных юридических и исторических споров, до конца не разрешённых.

Microsoft дорабатывает систему, лицензирует IBM права на неё, но сохраняет за собой права лицензировать ту же систему и другим производителям персональных компьютеров под именем MS-DOS.

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

Смотрите на разницу в стратегии. Digital Research лицензировала CP/M как основной, эксклюзивный продукт компании. А Microsoft сознательно сохранила право лицензировать MS-DOS широкому кругу производителей клонов IBM PC. Именно эта стратегическая, а не техническая разница в итоге определила, почему Microsoft, а не Digital Research, оказалась в позиции контролировать стандарт операционной системы для будущего массового рынка персональных компьютеров.

Итог

Подлинная история поражения Digital Research в конкуренции за операционную систему для IBM PC - это история о деловой стратегии, лицензионных условиях и организационных решениях, растянутых на месяцы переговоров. А вовсе не одномоментная драма об одном полёте

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

И, если уж говорить о том, как реальность обрастает легендами - тот же механизм сработал и с его смертью. Килдалл умер в 1994 году, в 52 года, после травмы головы, полученной в баре в Монтерее. Точные обстоятельства до сих пор не установлены: свидетели расходятся в показаниях, было ли это падение, драка или что-то ещё, полиция рассматривала версию убийства, но обвинений так и не предъявила, а вскрытие указало на черепно-мозговую травму на фоне хронического алкоголизма как способствующего фактора. Даже финал жизни человека, чья слава основана на непроверенном мифе, сам оказался историей с несколькими версиями и без окончательного ответа.

Вопросы, чтобы обсудить в комментариях

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

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

Третье — многие историки указывают, что CP/M на определённом этапе была технически зрелее и дольше на рынке, чем ранние версии MS-DOS. Как часто в истории технологий побеждает не лучшая технология, а лучшая лицензионная и дистрибьюторская стратегия?

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

Источники и ссылки по фактам из статьи

Хронология переговоров IBM и Digital Research (звонок 21 августа, встреча 22 августа 1980 года), роль Гейтса в направлении IBM к Килдаллу - The Peak and Collapse of Digital Research
Альтернативная версия про встречу с Hewlett-Packard в то же утро - История DOS, Remi’s Classic Computers
Публикация посмертных воспоминаний Килдалла Музеем компьютерной истории в 2016 году и точная формулировка его детей о мифе - Computer History Museum: In His Own Words - Gary Kildall
Обстоятельства смерти Килдалла в 1994 году - Wikipedia: Gary Kildall, материалы расследования, Generation Amiga

Дополнительное чтение к данной статье

Посмертные воспоминания Гэри Килдалла, опубликованные Музеем компьютерной истории (Computer History Museum) в 2016 году с разрешения его детей Кристин и Скотта Килдалл Ключевой первоисточник для разоблачения мифа. Доступен на сайте музея (computerhistory.org), стоит прочитать в оригинале, если позволяет английский.

Гарольд Эванс - “They Made America: From the Steam Engine to the Search Engine” (2004) Содержит одну из наиболее взвешенных версий истории Килдалла среди научно-популярных книг об истории американских изобретателей.

Пол Фрайбергер, Майкл Свейн - “Fire in the Valley: The Making of the Personal Computer” (1984, переиздания) Одна из самых ранних и подробных книг об истории персональных компьютеров, включая раннюю, ещё не до конца мифологизированную версию истории Килдалла и IBM и одновременно источник самой формулировки Гейтса про полёт на самолёте, если хочется увидеть её в оригинальном контексте.

Статья Bloomberg “The Man Who Could Have Been Bill Gates” (2004) Хороший источник именно для канонической версии мифа. Полезно прочитать её саму, чтобы увидеть, как убедительно и складно звучит версия, которую мы разобрали.

Материалы эфира программы Computer Chronicles (1995 год, соведущим которой был сам Килдалл) Наиболее подробная версия событий 1980 года из уст самого их участника. Записи доступны в архивах на YouTube и в Internet Archive.

100501-я версия латиницы для русского языка

MonteDegro — Mon, 14 Sep 2026 15:54:34 +0000

100501-я версия латиницы для русского языка

Периодически попадаются мне на Хабре варианты латинизации / транслитерации русского языка (примеры: вот, вот, вот так вот, и даже вот так). Кроме того, существует великое множество официальных ГОСТовых стандартов. И так получилось, что они все очень сильно мне не понравились (как минимум, у них у всех есть фатальный недостаток). В данном случае уже существующих стандартов столько, что добавление ещё одного ситуацию не ухудшит, и поэтому решил разработать свой вариант. Я не считаю, что надо тратить время и деньги на переход с кириллицы на латиницу, просто захотел посоревноваться, кто придумает ловчее.

Для начала надо определиться с требованиями. Зачастую приоритет отдают двум вещам — точное соответствие русской кириллической орфографии и отсутствие диакритики. Это важно при разработке системы именно транслитерации, но я предлагаю полноценную латинизацию, поэтому эти требования изменю: возможность автоматического преобразования кириллического текста в латиницу без значимых фонетических искажений и минимум диакритики. Совсем без диакритики / диграфов не обойтись, и из двух этих зол, на мой взгляд, диакритика является меньшим (так‑то она и в нашей кириллице есть). Следующее важное требование: сохранение верховенства морфологического принципа письменности, как и в текущей кириллице (то есть слово пишется не так, как слышится (белорусский), и не так, как писалось раньше (французский), а так, чтобы сохранялось написание морфем (корней, приставок, суффиксов) независимо от их реального произношения). Далее, произношение латинских букв должно быть конвенциональным (никаких ‘w’ = ‘ш’). Буква ‘y’ может соответствовать звукам ‘и’ / ‘й’ (английский), ‘ю’ (немецкий), ‘ы’ (польский), но не может авторским произволом начать соответствовать ‘э’. Наконец, важна последовательность: если уж решили к примеру, что ‘y’ = ‘ы’, то в качестве ‘й’ надо применить что‑то другое.

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

А а	Б б	В в	Г г	Д д	З з	И и	К к	Л л	М м
A a	B b	V v	G g	D d	Z z	I i	K k	L l	M m

Н н	О о	П п	Р р	С с	Т т	У у	Ф ф	Ц ц
N n	O o	P p	R r	S s	T t	U u	F f	C c

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

Если надо передать не смягчение согласной, а йотирование гласной, то наиболее простое решение также классическое — использовать ‘j’ = ‘й’. Его же можно использовать и для мягкого знака, так как в современном русском ‘ь’ и ‘й’ выполняют одну и ту же функцию, просто в разных позициях в слове. Кроме того (хоть это и не назвать серьёзным достоинством), такой подход подчёркивает, что звуки ‘ь’ и ‘й’ в русском языке исторически происходят от ‘и’.

Буквы ‘е’ и ‘э’ в эту схему не вписываются, так как в кириллической русской письменности нет чёткого правила, что ‘е’ всегда смягчает предыдущую согласную. На самом деле, было бы логично использовать «ie / je» = ‘ѣ’ и ‘e’ = “е / э”, но для этого пришлось бы сначала откатиться на дореформенную орфографию, что есть абсурд. Компромиссное решение такое: в йотированных позициях использовать всегда «je», в нейотированных позициях — всегда ‘e’. Диграфы «ie» = ‘ѣ’ и «ae» = ‘э’ можно использовать в том случае, если надо передать нестандартное произношение («компьютѣр» вместо «компьютэр», стереотипный кавказский акцент и так далее)

Е	Ё ё	Й й	ь	Э э	Ю ю	Я я
Je e / je	Jo io / jo	J j	j	E e / ae	Ju iu / ju	Ja ia / ja

У такого классического подхода есть два минуса. Во‑первых, путаница с сочетаниями ‘и’ + нейотированная гласная: «idiot» это «идёт» или «идиот»? Решение такое: в сочетаниях согласная + ‘и’ + нейотированная гласная использовать не ‘i’, а ‘y’. “Идёт идиот” = «idiot idyot». Французкий вариант с диарезисом отбросил, потому что слишком большое количество точек засоряло бы текст. Во‑вторых, буква ‘j’ в тексте становится одной из самых частотных (а она довольно сильно бросается в глаза). Поэтому любое число идущих подряд ‘j’ склеивать в одну («вьюга» — «vjuga» вместо «vjjuga»).

В славянских языках дофигищща шипящщих, и их надо как‑то передать. Польский вариант, к счастью, никто всерьёз не рассматривает, так что конкурируют два подхода — диакритика ‘č’, ‘š’, ‘ž’ и диграфы «ch», “sh”, “zh”. И если честно, я не вижу ни малейших причин предпочесть здесь диграфы. Все системы с использованием этих диграфов, которые я видел, во‑первых, сами по себе громоздкие, во‑вторых вызывают проблемы с передачей буквы ‘х’ через наиболее интуитивную ‘h’ (поэтому обычно обозначают либо диграфом же «kh», что загромождает текст ещё сильнее, либо латинской ‘x’).

В том маловероятном случае, если нет возможности ввести с клавиатуры символы ‘č’, ‘š’, ‘ž’, от диграфов не отвертеться, но намного удобнее использовать другие — «cx», “sx”, “zx” (такой способ встречается, например, в эсперанто). Основные достоинства подхода: ‘x’ в естественных словах не бывает после согласной, то есть такие диграфы не путаются с сочетаниями отдельных букв, а также ‘x’ на раскладке соседствует с ‘c’, ‘s’, ‘z’. Дополнительный небольшой плюс — визуальное сходство ‘x’ с диакритическим знаком гачека.

Самый сложный в передаче шипящий, безусловно, ‘щ’. В современном стандартном русском произношении это смягчённый ‘ш’, и может возникнуть идея так и записывать: ‘š’ + ‘j’ / смягчающая гласная, и даже применить тот же принцип и к остальным шипящим (а то чего остальные гласные по твёрдости / мягкости чередуются, а эти нет?), но есть проблема. Дело в том, что с точки зрения русской орфографии это ‘ш’ и ‘ж’ мягкие, а ‘щ’ твёрдый. Поэтому для реализации такого подхода пришлось бы сначала кириллическую орфографию серьёзно перелопатить. Остаётся вариант «šč» = ‘щ’. Потенциальный тетраграф «sxcx» вызывает стойкие ассоциации с бобрами, поэтому на всякий случай упрощу его до «scx» (“сч” всё равно примерно так же произносится).

Ну и раз уж отказались от идеи сделать все согласные чередующимися по мягкости / твёрдости, то после шипящих (и примкнувшего к ним ‘c’) нет смысла писать «ia», “io”, “iu”, можно обойтись ‘a’, ‘o’, ‘u’.

Остались две нетривиальные буквы — ‘ъ’ и ‘ы’. В славянских латиницах часто передают ‘ы’ через ‘y’, но для русского языка это нарушает морфологический принцип («играть» — «подыграть», «igratj» — “podygratj”, добавление приставки изменило написание корня). Ситуация осложняется тем, что это ещё и работает не всегда, есть исключения («индустриальный» — «постиндустриальный»). Поэтому необходим способ передать визуально чередование ‘и’ / ‘ы’. Я расссматривал такой вариант: ‘y’ = ‘ъ’, «yi» = ‘ъ’ + ‘i’ = ‘ы’. Но это и нестандартное применение ‘y’, и выглядит громоздко. Поэтому решение такое: буква ‘ъ’ как гласный с нулевым звуком не записывается вовсе (она и в кириллице нашей уже помирает), но делает смягчающую гласную после себя йотированной, а ‘ы’ записывается через ‘ı’ (как в турецком). При невозможности ввести с клавиатуры диакритику вместо ‘ı’ использовать обычную ‘i’.

Ж ж	Х х	Ч ч	Ш ш	Щ щ	ы	ъ
Ž ž (zx)	H h	Č č (cx)	Š š (sx)	Šč šč (scx)	ı (i)

Пример записи текста такой системой.

Кириллица:

Майор авиации Цюрюпа Майя Ильинична ввела антиионизирующий диэлектрик в костьутиль Шауляйского стройуправления и, желая помочь жюри журнала «Жизнь Жюля Верна», наотмашь гильотинировала сумасшедший трёхъярусный подъёмник её конвейера жёлтых парашютов. Близстоящая госзаёмщица, получившая морзянкой это спецзадание от минюста, обошла безымянный танцзал сзади постиндустриального Кяхтинского сельисполкома, пытаясь, как гюрза, выучиться на переводчика с французского и возить майонез из Цюриха в Пюхяярви. Гэдээровские реперы предсказуемы, ведь они, фактически, синтезируют предсказуемый фактический темп. Парадоксально, но Антииисус почитается в антииудаизме. Со шхуны счастливо вещает веснушчатый иждивенец. Спецхрам им. Мустазхира Арзаханяна для сходок схимонахов в Цхинвали.

Latinica (s dyakritikoj):

Major avyacii Curiupa Maja Iljinična vvela antiioniziruiuščij dyelektrik v kostjutilj Šauliajskogo strojupravlenija i, želaja pomočj žuri žurnala “Žiznj Žulia Verna”, naotmašj giljotinirovala sumasšedšij triohjarusnıj podjomnik jejo konvejera žoltıh parašutov. Blizstojaščaja goszajomščica, polučivšaja morziankoj eto speczadanije ot miniusta, obošla bezımiannıj tanczal szadi postindustryaljnogo Kiahtinskogo seljispolkoma, pıtaiasj, kak giurza, vıučitjsia na perevodčika s francuzskogo i vozitj majonez iz Curiha v Piuhiaiarvi. Gedeerovskije reperı predskazujemı, vedj oni, faktičeski, sintezirujut predskazujemıj faktičeskij temp. Paradoksaljno, no Antiiisus počitajetsia v antiiudaizme. So šhunı sčastlivo veščajet vesnuščatıj iždivenec. Spechram im. Mustazhira Arzahaniana dlia shodok shimonahov v Chinvali.

Latinica (bez dyakritiki):

Major avyacii Curiupa Maja Iljinicxna vvela antiioniziruiuscxij dyelektrik v kostjutilj Sxauliajskogo strojupravlenija i, zxelaja pomocxj zxuri zxurnala “Zxiznj Zxulia Verna”, naotmasxj giljotinirovala sumassxedsxij triohjarusnij podjomnik jejo konvejera zxoltih parasxutov. Blizstojascxaja goszajomscxica, polucxivsxaja morziankoj eto speczadanije ot miniusta, obosxla bezimiannij tanczal szadi postindustryaljnogo Kiahtinskogo seljispolkoma, pitaiasj, kak giurza, viucxitjsia na perevodcxika s francuzskogo i vozitj majonez iz Curiha v Piuhiaiarvi. Gedeerovskije reperi predskazujemi, vedj oni, fakticxeski, sintezirujut predskazujemij fakticxeskij temp. Paradoksaljno, no Antiiisus pocxitajetsia v antiiudaizme. So sxhuni scxastlivo vescxajet vesnusxcxatij izxdivenec. Spechram im. Mustazhira Arzahaniana dlia shodok shimonahov v Chinvali.

Кириллица (после обратной конвертации):

Маёр авиации Цурюпа Мая Ильинична ввела антиионизирующий диэлектрик в костютиль Шауляйского строюправления и, желая помочь жури журнала «Жизнь Жуля Верна», наотмашь гильётинировала сумасшедший трёхьярусный подьёмник её конвеера жолтых парашутов. Близстоящая госзаёмщица, получившая морзянкой это спецзадание от минюста, обошла безымянный танцзал сзади постиндустриального Кяхтинского сельисполкома, пытаясь, как гюрза, выучиться на переводчика с французского и возить маёнез из Цуриха в Пюхяярви. Гедеэровские реперы предсказуемы, ведь они, фактически, синтезируют предсказуемый фактический темп. Парадоксально, но Антииисус почитается в антииудаизме. Со шхуны счастливо вещает веснущатый иждивенец. Спецхрам им. Мустазхира Арзаханяна для сходок схимонахов в Цхинвали.

Как видно, основной недостаток — искажения при попытке обратной конвертации в кириллицу. Кроме того, явно не логично написание слов «kostjutilj» (следовало бы «kostiutilj») и «miniust» (следовало бы «minjust»), но тут проблема в корявости исходного кириллического написания, и без введения словарных слов это не фиксится.

Лучший хостинг для Node.js-приложений и Next.js-сайтов с SSR в 2026

Mon, 14 Sep 2026 15:47:15 +0000

В статье мы рассмотрим такие специализированные PaaS-облака, как Vercel, Render, Railway и российское PaaS-облако Amvera для хостинга приложений на Node.js. В том числе особенности хостинга сайтов с SSR (рендерингом на стороне сервера) на React (Next.js, Remix, Astro), Vue (Nuxt.js, Quasar), Svelte и Angular. Рассмотрим сильные и слабые стороны сервисов. А также рассмотрим хостинг у VPS и Serverless-провайдеров. И приведём пример деплоя Node.js приложения с BullMQ.

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

Специализированные PaaS для хостинга Node.js

Рассмотрим решения, специально предназначенные для хостинга Node.js и сайтов на Next.js

Vercel – международный лидер для хостинга сайтов на Next.js. Компания является разработчиком Next и имеет самую тесную интеграцию своей инфраструктуры с этим фреймворком. Отдельно стоит отметить распределенную инфраструктуру с CDN, которая обеспечивает низкий пинг для глобальной аудитории.
Следует учитывать, что платные тарифы требуется оплачивать иностранными картами (российские карты сервис не принимает) и проекты, размещенные в Vercel, часто попадают под блокировки для российских пользователей, что затрудняет развертывание коммерческих проектов c аудиторией из России, где нужна гарантия доступности.
Amvera – российское PaaS-облако со встроенной поддержкой Node.js. В отличие от иностранных сервисов, Amvera можно оплачивать российской картой. В Amvera можно размещать приложения на серверах в ЦОД-ах в России (и в Европе и Америке), что даёт пинг для российских пользователей менее 30 мс и возможность соответствовать требованиям 152-ФЗ.
В Amvera есть встроенный CI/CD с деплоем через Git. Достаточно привязать репозиторий, сервис сам определит окружение, подберет конфигурацию, скачает зависимости из npm, pnpm или yarn, и запустит приложение или сайт в непрерывном контейнере. Постоянно работающие контейнеры позволят всегда держать код активным и избежать холодного старта.
Amvera это универсальное PaaS-облако с поддержкой Node.js (и других окружений), управляемыми PostgreSQL с бэкапами, Background Workers для BullMQ, возможностью деплоить как Frontend, так и Backend через коммиты в Git репозиторий или подключив Claude/Codex через MCP, Zero Downtime Deploy, мгновенные откаты сборок и другие функции ведущих PaaS-облаков. В сервисе можно развернуть как backend на Node.js, так и Frontend на Next.js без настройки и администрирования сервера.
Для работы с проектами прямо на платформе есть изолированный Sandbox с возможностью редактирования кода через встроенную online-IDE или специального ИИ-Помощника (AI App Builder) Polide.
В отличие от международных сервисов, таких как Vercel, проекты, размещенные в Amvera, не попадают под блокировки в России и всегда доступны российским пользователям.
По данным на сентябрь 2026 в Amvera было зарегистрировано 100 000 разработчиков, что делает Amvera лидером среди российских PaaS-сервисов.
Начать использовать Amvera можно бесплатно за счёт промобаланса, платные тарифы начинаются от 170 р. в месяц.
Render – универсальное PaaS облако, подходящее для веб-приложений на Node.js и имеющее сервис для Background Workers. Есть поддержка Node и деплой через Git. На бесплатном тарифе проекты засыпают через 15 минут неиспользования, а просыпаются около минуты, что делает не рекомендуемым использование бесплатного тарифа в проде. Платные тарифы начинаются от 7$ и требуют наличие иностранной карты (российские карты не поддерживаются).
Railway – ещё одно универсальное PaaS облако. По концепции очень похоже на Render и Amvera. Есть встроенный CI/CD и все основные функции PaaS-облаков. Есть триал в размере 5$ в первый месяц и 1$ начиная со второго. Уложиться в Free Tier с постоянно работающим приложением почти невозможно, лучше сразу перейти на один из платных тарифов, начинающихся от 5$. Как и в других международных PaaS-сервисах, российские карты не поддерживаются и требуется наличие иностранной карты для оплаты.

Скорость ответа сайтов, размещенных в Vercel, Amvera, Render, Railway

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

Я провел эксперимент, сделав с помощью сервиса ping-admin пинг с 10 случайных точек в России до сайтов, расположенных в Amvera, Vercel, Render и Railway. Чтобы не загромождать статью, я приведу здесь только средний показатель. Но вы можете провести эксперимент самостоятельно.

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

	Amvera	Vercel	Render	Railway
Общее время ответа сек.	0.223	0.859	0.385	0.494
Время ответа DNS сек.	0.054	0.462	0.120	0.333
SSL сек.	0.098	0.063	0.094	0.089
Ожидание ответа сек.	0.025	0.269	0.098	0.040

Как видно из таблицы скорости ответа сайтов для пользователей из России, лучший показатель у Amvera со средним значением 0,22 секунды. А худший у Vercel со значением 0,85 секунды. Render и Railway разместились посередине со значением в 0,38 и 0,49 секунды соответственно.

Хостинг Node.js на VPS-сервере

VPS-сервера позволяют запускать Node.js приложения, но обладают рядом недостатков.

Вам потребуется самостоятельно настраивать и администрировать сервер.
Это не специализированное решение, многие вещи придется делать самим.
VPS обычно не включает CDN и глобальную edge-инфраструктуру из коробки. Если CDN необходим, его придётся подключать и настраивать отдельно.
Вам потребуется подключать отдельные сервисы для мониторинга, CI/CD, бэкапов и многого другого.

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

Хостинг Node.js в Serverless

Альтернативой является использование Serverless-провайдеров, таких как Cloudflare Workers.

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

Serverless подходит для stateless HTTP-функций и проектов, которым не требуется постоянно работающий процесс. Но ограничения рантайм, времени выполнения, модели хранения состояния, сетевых возможностей и подключений к СУБД могут сделать serverless неудобным для ряда Node.js-приложений.

Важные функции, которые должны быть у хостинга Node.js

Следует отдельно оценить функции для сайтов на Next.js и Backend-приложений на Node.js.

Самыми важными функциями является встроенная поддержка Node.js и возможность доставки кода через коммиты в привязанный Git. Это избавит вас от необходимости настройки и администрирования сервера. Всё это есть в таких PaaS-облаках, как Vercel, Amvera, Railway, Render.
Наличие нужных регионов доступности и время пинга. Так, для международного рынка лучший пинг вы получите в Vercel, но если ваши пользователи из России, то лучший пинг будет у проектов, размещенных в Amvera.
Находятся ли проекты, размещенные у провайдера под региональными блокировками. Так, в России блокируются домены проектов, размещенных в Vercel и частично в Railway и Render.
Есть ли управляемые СУБД PostgreSQL и Redis с бэкапами. Такие СУБД есть в универсальных PaaS-облаках Railway, Render и Amvera.
Есть ли Zero Downtime Deploy и откаты сборок. Данные функции есть в Vercel, Amvera, Railway, Render.
Есть ли непрерывная работа кода или быстрый старт. Самый быстрый отклик после простоя будет в непрерывных контейнерах Railway и Amvera или у VPS-провайдеров. Но и специализированные решения, такие как Vercel или Cloudflare Workers могут обеспечить достаточно быстрый холодный старт.
Если вам нужен BullMQ, есть ли у провайдера сервис для запуска Background Workers. Такой сервис есть у Render и Amvera.
Есть ли поддержка npm, pnpm и yarn.
Возможность оплатить российской картой. Если у вас нет иностранной картой, лучше сразу рассмотреть такие российские облака, как Amvera.
Есть ли возможность горизонтального и вертикального масштабирования. Возможность есть в Vercel, Amvera, Railway, Render и у Serverless-провайдеров.

Что не подойдёт для хостинга Node.js

Если ваш сайт требует рендеринга на стороне сервера, вам не подойдут Shared-хостинги. Ваше приложение должно либо работать непрерывно, либо очень быстро подниматься. По этой же причине не подойдёт бесплатный тариф в Render, так как минутный запуск после “засыпания”, это очень долго.

Пример деплоя Node.js приложения с BullMQ

Я приведу пример деплоя Node.js в PaaS-облако Amvera.

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

Если у вас есть Node.js приложение, которое использует BullMQ, вам потребуется три проекта. Непосредственно для приложения, BullMQ и для Redis.

Для деплоя приложения вам потребуется привязать репозиторий в интерфейсе Amvera (делается одной кнопкой) или перетянуть файлы в интерфейсе.

Подключение репозитория для деплоя через Git

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

Для запуска BullMQ необходимо пройти те же шаги, только использовав код из другой инструкции.

Далее нужно запустить преднастроенный Redis – это делается “одной кнопкой” в интерфейсе. И прописать в переменной приложения с BullMQ его хост.

Деплой управляемого Redis

Будет примерно так

REDIS_URL=redis://:<пароль>@<внутренний-домен-redis>:6379/0

Все, буквально за пять минут и без настройки сервера мы успешно опубликовали Node.js приложение, BullMQ и Redis в Amvera.

На каком сервере разместить Node.js приложение и сайт с SSR в 2026

Если ваши пользователи из России, или у вас нет иностранной карты, и вы хотите получить все преимущества PaaS-облака, рассмотрите Amvera. Amvera – это российский сервис, где есть поддержка Node.js, деплой через Git, управляемые PostgreSQL, Redis и другие СУБД. А также подробные метрики и логи работы приложения, настраиваемые алерты с рестартами приложения при падениях, деплой без даунтайма, откаты сборок одной кнопкой, ИИ-помощник и встроенное IDE для редактирования кода прямо на сервере и регионы в России, Европе и Америке. А главное, в Amvera есть возможность оплаты российской картой, соблюдать местное законодательство о хранении данных и обеспечить надежный доступ для пользователей из России.

Если ваш проект, это сайт на Next.js, ваши пользователи не из России и у вас есть иностранная карта, хорошим выбором будет Vercel.

А если ваш проект, это Backend-приложение и вы и ваши пользователи не из России, хорошим выбором будет Render или Railway.

Сравнительная таблица хостингов для Node.js приложений и сайтов с SSR

	Amvera	Vercel	Render	Railway	VPS	Serverless
Встроенная поддержка Node.js	Есть	Есть, но сервис больше ориентирован именно на Next.js	Есть	Есть	Нет, максимум как предустановка	Частично есть
Встроенная поддержка Next.js c SSR	Есть	Есть	Есть	Есть	Нет	Частично есть
Управляемый PostgreSQL	Есть с бэкапами,такими расширениями как pgVector, PostgREST и возможностью запуска нескольких реплик для надежности	Нет	Есть	Есть	Нет, нужно подключать отдельно или поднимать самостоятельно	Нет, нужно подключать отдельно или поднимать самостоятельно
Управляемый Redis	Есть	Нет	Есть	Есть	Нет, нужно подключать отдельно или поднимать самостоятельно	Нет, нужно подключать отдельно или поднимать самостоятельно
Поддержка BullMQ	Есть	Нет	Есть	Нет (но можно запустить как приложение)	Нет, нужно подключать отдельно или поднимать самостоятельно	Нет, нужно подключать отдельно или поднимать самостоятельно
Git Deploy	Есть. Можно как подключить GitHub, GitLab, BitBucket, так и использовать выделенный репозиторий Amvera	Есть	Есть	Есть	Нет, нужно настраивать CI/CD	Зависит от вендора
Встроенный Rollback	Есть	Есть	Есть	Есть	Нет	Нет
Zero-Downtime Deploy	Есть	Есть	Есть	Есть	Нет, нужно настраивать самостоятельно	Нет
Оплата российскими картами	Есть	Нет	Нет	Нет	Да	Зависит от вендора
Российские регионы	Есть	Нет	Нет	Нет	Да, зависит от хостинга	Зависит от вендора
ИИ-помощник	Есть	Есть	Нет	Есть	Нет	Нет
Среднее время ответа проекта для пользователей из России (чем меньше, тем лучше)	0.223	0.859	0.385	0.494	Зависит от провайдера	Зависит от провайдера
Когда использовать	Если вам нужно развернуть сайт c SSR и/или Node.js приложение, вы хотите оплачивать российской картой и/или ваши пользователи из России	Для хостинга Next.js, если вы и ваши пользователи не из России	Для хостинга Backend если вы и ваши пользователи не из России	Для хостинга Backend если вы и ваши пользователи не из России	Если вас не затрудняет самостоятельная настройка и администрирование инфраструктуры	Если вы хотите платить исключительно за фактическое использование ресурсов и готовы к ограничениям Serverless

ИИ делает аналитику доступной каждому, но значит ли это, что аналитиков станет меньше?

prostoanalytics — Mon, 14 Sep 2026 15:47:02 +0000

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

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

Прощай часть работы

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

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

И вот такого рода задачи уже вполне можно отдавать ИИ.

И да, если раньше подразделению N требовалось пять аналитиков, потому что руководители постоянно приходили к ним с небольшими запросами, выгрузками, графиками и разрезами, то с ИИ (после пару кругов настройки интеграций между системами учета, хранилищем и BI) такие запросы можно через личный кабинет в BI инструменте решать.

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

Доступ к аналитике и сама аналитика не одно и то же

Едем дальше, уже непосредственно в аналитику.

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

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

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

Одна фундаментальная проблема

В большинстве своем пользователи не знают, что им нужно. И если модель ИИ, которую использует компания слабая, то на запрос в стиле "Глянь что с продажами происходит" получится очень неплохой бульон.

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

Да и далеко не каждый пользователь будет гонять ИИ с просьбой дополнительно сделать Z-оценку или убедиться в статистической значимости или аномальность изменений проверить через robust z.

Плохая аналитика стала дешевой

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

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

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

Если ИИ станет очень хорошим

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

И реально, большинство пользователей начинают самостоятельно получать большую часть нужной им аналитической информации по щелчку ЛКМ.

Такой апокалипсис для аналитика.

И тут, конечно много аналитиков попадет под удар. Вместо условных 50 аналитиков компании может будет нужно 15. Но скорее всего эти 15 будут сильными аналитиками: будут решать более сложные задачи и скорее всего будут стоить дороже (но это не точно).

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

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

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

EvertyDisplay: что я сделал и зачем

vaalimusic — Mon, 14 Sep 2026 15:32:49 +0000

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

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

Так появился EvertyDisplay.

Я сделал приложение для Windows, которое создаёт настоящие виртуальные дисплеи. Для системы это полноценные мониторы: у них есть собственное разрешение, координаты, на них можно переносить окна, запускать приложения в полноэкранном режиме и перемещать между ними курсор.

Но физически этих экранов рядом с вами нет.

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

Чтобы виртуальное пространство не превращалось просто в склад невидимых окон, я добавил Live PiP и полноэкранный Viewport. Можно быстро посмотреть содержимое виртуального дисплея или открыть его на физическом экране, не меняя расположение самих приложений.

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

Большая часть EvertyDisplay написана на Rust. Внутри много Win32, IPC, хуков ввода, Direct3D 11, DXGI и работы с состоянием Windows. Сам виртуальный видеоадаптер используется как отдельный подписанный компонент, а EvertyDisplay уже строит поверх него пользовательскую логику и рабочее пространство.

Но техническая часть для меня здесь всё-таки вторична.

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

Оказалось, что нет.

Если ты несколько раз отправил окно «влево», а потом возвращался туда курсором, мозг довольно быстро начинает воспринимать это место как существующее.

На столе там ничего нет.

А в компьютере — есть.

И именно это ощущение я хотел получить, когда начинал EvertyDisplay.

Я Артур Валиев, и не буду постить длинных философских статей. Просто делюсь крутой программой.

https://github.com/vaalimusic/EvertyDisplayLite
В релизах можно скачать exe и познакомиться с системными требованиями.

HR спрашивают, зачем я задаю вопрос о чувствах на собеседовании

dmitry-pivovarov — Mon, 14 Sep 2026 15:32:05 +0000

HR спрашивают, зачем я задаю вопрос о чувствах на собеседовании

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

До меня кандидаты доходят уже после технического интервью. На своём этапе я больше внимания уделяю социальным навыкам, soft skills. Один из вопросов, которые я традиционно задаю на собеседовании, касается чувств: «Назовите три чувства, которые прямо сейчас испытываете».

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

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

А зачем вы это спрашиваете?
С таким вопросом ко мне несколько раз приходили рекрутёры и даже HRBP.

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

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

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

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

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

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

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

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

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

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

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

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

А какие три чувства испытываете прямо сейчас вы?

Как автоматизировать VLESS + Reality на старом Intel iMac с macOS Catalina 10.15.8: AUTO Xray

OKTHEOK — Mon, 14 Sep 2026 15:18:47 +0000

Ранее я описал способ запуска VLESS + Reality на Intel iMac с macOS Catalina 10.15.8: «Как запустить VLESS + Reality на старом Intel iMac с macOS Catalina 10.15.8».

Решение через V2RayXS и Xray-core оказалось рабочим, но требовало много ручных действий: получить подписку, разобрать VLESS-ссылки, сформировать JSON-конфигурации, импортировать узлы и настроить системный proxy.

Схема выглядела примерно так:

subscription
    ↓
vless://
    ↓
разбор параметров
    ↓
JSON
    ↓
V2RayXS
    ↓
Xray
    ↓
macOS system proxy

Для разовой настройки этого достаточно. Для постоянного использования — не очень удобно.

Следующим шагом стала автоматизация этой цепочки.

Так появился AUTO Xray.

Теперь пользовательский сценарий выглядит так:

subscription URL
    ↓
Update subscription
    ↓
выбор региона или сервера
    ↓
Enable

AUTO Xray на iMac Late 2013 с macOS Catalina 10.15.8

Задача AUTO Xray

AUTO Xray не задумывался как универсальный VPN-клиент. Цель была значительно уже: сделать удобный клиент VLESS + Reality для старых Intel Mac, оставшихся на macOS Catalina.

Целевая конфигурация:

Intel x86_64
macOS Catalina 10.15.x
VLESS + Reality
macOS system proxy

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

Что получилось: AUTO Xray

AUTO Xray — небольшое приложение для строки меню macOS.

Состояние видно по иконке в строке меню: яркий голубь — ON, полупрозрачный — OFF.

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

Основное меню AUTO Xray: автоматический выбор RF / EU / World и ручной выбор узла

При обновлении подписки AUTO Xray самостоятельно разбирает полученные узлы и распределяет их по группам:

RF
EU
World

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

Что происходит под капотом

За работу с VLESS + Reality отвечает Xray-core. AUTO Xray управляет его конфигурацией, запуском и интеграцией с сетевыми настройками macOS.

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

HTTP/HTTPS → 127.0.0.1:9001
SOCKS5     → 127.0.0.1:2081

После запуска Xray AUTO Xray через штатный networksetup настраивает HTTP, HTTPS и SOCKS proxy для сетевых сервисов macOS.

В упрощённом виде маршрут трафика выглядит так:

Приложение
    ↓
macOS system proxy
    ↓
127.0.0.1
    ↓
Xray-core
    ↓
VLESS + Reality
    ↓
сервер

Из этой архитектуры следует важное ограничение: AUTO Xray — system proxy client, а не TUN VPN.

Программы, использующие системные proxy-настройки macOS, направляют трафик через Xray. Приложения, которые игнорируют системный proxy или используют собственный сетевой стек, могут работать напрямую.

Устойчивость на Catalina

Отдельная задача — поведение приложения при сетевых сбоях.

Например, после отключения и повторного подключения Wi-Fi процесс Xray может оставаться запущенным, но рабочий маршрут через proxy уже не гарантирован.

Поэтому в AUTO Xray есть supervisor, который периодически проверяет прохождение трафика через локальный SOCKS proxy. Если несколько проверок подряд завершаются ошибкой, runtime восстанавливается автоматически.

Есть и обратная проблема: Xray уже остановлен, а macOS продолжает считать системный proxy включённым. В этом случае приложения пытаются отправлять трафик на локальный адрес, где уже никто не слушает, и интернет фактически перестаёт работать.

AUTO Xray проверяет такое состояние и отключает оставшиеся HTTP, HTTPS и SOCKS proxy, если процесс Xray больше не работает.

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

Установка на Catalina

Основной способ установки — через DMG из GitHub Releases.

Установочный образ AUTO Xray 2.5.20

Порядок такой:

Скачать AUTO_Xray_Catalina_v2.5.20.dmg.
Открыть образ.
Запустить Install AUTO Xray.app через Control-click → Open.
Если Catalina в первом предупреждении показывает только Cancel, закрыть его и повторить Control-click → Open.
Во втором предупреждении подтвердить запуск кнопкой Open.

Повторный запуск через Control-click → Open позволяет подтвердить запуск в Gatekeeper

Приложение пока не подписано сертификатом Apple Developer ID, поэтому такой сценарий запуска ожидаем.

После установки AUTO Xray запускается в состоянии OFF.

Если DMG по какой-то причине не открывается или Gatekeeper продолжает блокировать запуск, в релизе есть резервный ZIP-инсталлятор:

AUTO_Xray_Catalina_Installer_v2.5.20.zip

Он содержит установочный скрипт INSTALL_AUTO_XRAY_CATALINA.command.

Состав релиза

В AUTO Xray включён Xray-core 1.8.4 — отдельно устанавливать или загружать его не требуется.

При сборке Xray-core проверяется по SHA-256 перед включением в пакет.

Вместе с каждым релизом публикуется SHA256SUMS.txt с контрольными суммами DMG и ZIP.

Итог

Текущая стабильная версия — AUTO Xray 2.5.20.

Проект и готовые сборки опубликованы на GitHub:

GitHub: https://github.com/eigenheit/auto-xray

Releases: https://github.com/eigenheit/auto-xray/releases

Если у вас остался Intel Mac с Catalina и есть возможность проверить AUTO Xray на другой конфигурации, результаты тестирования и найденные проблемы можно оставить в Issues проекта.

Как удалить объект с фото с помощью нейросети: тестируем 5 ИИ-сервисов и выбираем лучший

Mon, 14 Sep 2026 15:12:00 +0000

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

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

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

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

Как мы тестировали нейросети для удаления объектов

Для теста выбрали три сценария:

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

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

Кружка: «Удали красную кружку со стола. Реалистично восстанови поверхность стола и фон на ее месте. Остальные элементы изображения не изменяй».

Красная кружка на деревянном столе — исходное фото для теста нейросетей на удаление объектов.

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

Женщина в центре городской улицы — исходное фото для теста удаления человека нейросетью.

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

Велосипед у каменной стены и металлического ограждения — исходное фото для сложного теста удаления объекта.

Каждый сервис получил до пяти баллов по четырем критериям:

полнота удаления объекта;
качество восстановления фона;
сохранность деталей вне области редактирования;
удобство: скорость, количество действий, регистрация и ограничения.

Максимальная оценка — 20 баллов. Условия и цены проверены 10 сентября 2026 года и могут меняться в зависимости от страны, платформы и способа оплаты.

Результаты теста: коротко

Сервис	Удаление	Фон	Детали	Удобство	Итог
Nano Banana	5/5	5/5	5/5	5/5	20/20
ChatGPT	5/5	5/5	4/5	5/5	19/20
Photoroom Retouch	4/5	4/5	3/5	5/5	16/20
Cleanup.pictures	4/5	3/5	2/5	4/5	13/20
Pixelcut	3/5	2/5	2/5	4/5	11/20

Cleanup.pictures — быстро, но с потерей деталей

Качество: 2/5 на простых объектах, 2/5 на сложной геометрии.
Оригинальный размер: только в Pro; бесплатный экспорт ограничен 720 px.
Стоимость: бесплатно в низком разрешении; Pro — 5 $ в месяц или 36 $ в год.

Интерфейс Cleanup.pictures для удаления объектов с фотографии с помощью кисти.

Cleanup.pictures — минималистичный онлайн-инструмент без обязательной регистрации. После загрузки фотографии достаточно настроить размер кисти и провести по лишнему предмету: обработка начинается сразу после мазка.

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

Результат удаления кружки в Cleanup.pictures — на столе остались размытие и искажения текстуры.

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

Cleanup.pictures удалил женщину с фотографии, но размыл дорогу и детали фона.

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

Результат удаления велосипеда в Cleanup.pictures — размытая стена и искаженное металлическое ограждение.

Плюсы: не требует регистрации, быстро запускает обработку, не перегружен настройками.

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

Итог: 13/20. Подойдет, чтобы быстро убрать небольшой объект с относительно однородного фона, особенно если изображение будет использоваться в небольшом размере. При работе со сложным фоном, в особенности с пересечениями объектов, текстурами и другими деталями качество снижается до неудобоваримого.

Pixelcut — удобное выделение, слабое восстановление фона

Качество: 2/5 на простых объектах, 2/5 на сложной геометрии.
Оригинальный размер: только в Pro; бесплатный экспорт ограничен 720 px.
Стоимость: бесплатно в низком разрешении; Pro — 5 $ в месяц или 36 $ в год.

Интерфейс Pixelcut ИИ для выделения кистью и удаления объектов с фотографии.

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

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

Результат удаления кружки в Pixelcut — размытая текстура деревянного стола после обработки.

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

Pixelcut удалил женщину с улицы, но оставил сильное размытие дороги и фона.

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

Результат удаления велосипеда в Pixelcut — темное пятно, размытая стена и искаженное ограждение.

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

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

Итог: 11/20. Подойдет для небольших объектов, но первый результат на сложных сценах нельзя назвать готовым к использованию.

Photoroom Retouch — лучший сервис без промптов

Качество: 4/5 на простых объектах, 2/5 на сложной геометрии.
Оригинальный размер: да; в нашем тесте изображение скачалось без уменьшения и дополнительных условий.
Стоимость: есть бесплатный режим; Pro — 12,99 $ в месяц или 90 $ в год.

Интерфейс Photoroom Retouch для удаления ненужных объектов с фотографии.

Photoroom Retouch работает по знакомой схеме: загружаем изображение и закрашиваем лишний объект кистью. После обработки фотографию можно открыть в отдельном редакторе, обрезать, изменить размер или продолжить ретушь.

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

Результат удаления кружки в Photoroom Retouch — небольшое сглаживание текстуры деревянного стола.

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

Photoroom Retouch удалил женщину с фотографии с небольшим размытием дороги на месте объекта.

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

Результат удаления велосипеда в Photoroom Retouch — размытая стена и нарушенная геометрия металлического ограждения.

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

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

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

Что показали сервисы без текстового промпта

Cleanup.pictures и Pixelcut действительно удаляют выделенный объект, но качество восстановления фона оказалось слабым. Пока нейросети нужно продолжить относительно простой участок стола или дороги, результат еще можно принять. Когда в кадре появляются фактура камня, тонкие металлические линии и сложная геометрия, вместо них часто остается размытая или искаженная заплатка.

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

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

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

ChatGPT — качественное удаление объектов по текстовому промпту

Качество: 5/5.
Оригинальный размер: файл скачивается в полном размере генерации; разрешение результата может отличаться от исходного файла.
Стоимость: доступен бесплатный тариф с лимитами; ChatGPT Plus — 20 $ в месяц.

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

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

Получить 300 000 бесплатных токенов в BotHub

Тест 1 — кружка. ChatGPT полностью удалил кружку и естественно восстановил деревянную поверхность, сохранив направление текстуры. Вместе с чашкой исчез и поднимающийся от напитка пар, хотя отдельно мы об этом не просили. Модель поняла, что он относится к удаляемому объекту. Однако падающий свет корректно воспроизвести не получилось.

Результат удаления кружки в ChatGPT — кружка и пар удалены, деревянная поверхность стола восстановлена

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

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

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

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

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

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

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

Итог: 19/20. Все три первых результата пригодны для использования.

Nano Banana — лучший результат

Качество: 5/5 на простых сценах, 5/5 на сложной геометрии.
Оригинальный размер: скачивается полный результат модели, но разрешение может отличаться от исходника.
Стоимость: есть бесплатный доступ с лимитами; Google AI Pro — 19,99 $ в месяц, через BotHub отдельный аккаунт Google не требуется, цена от нескольких рублей за генерацию.

Nano Banana — модель Google для генерации и редактирования изображений по текстовой инструкции. Как и ChatGPT, она принимает фотографию целиком: пользователю не нужно вручную обводить объект.

Кружку модель удалила полностью и правдоподобно продолжила поверхность стола и освещения.

Nano Banana удалил красную кружку и восстановил текстуру деревянного стола и освещение.

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

Nano Banana удалил женщину с городской улицы и восстановил дорогу и окружающий фон.

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

Результат удаления велосипеда в Nano Banana — восстановлены каменная стена, дорожное покрытие и металлическое ограждение.

Это заметно лучше результатов обычных ИИ-ластиков и превосходит в детализации ChatGPT, не создавая лишних объектов или ошибок освещения.

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

Минусы: нужен аккаунт Google, действуют лимиты.

Итог: 20/20.

Какую нейросеть выбрать для удаления объектов с фото

По результатам теста победил Nano Banana. Это единственная модель, которая справилась со всеми тремя задачами без заметных ошибок и лучше остальных восстановила сложную геометрию. ChatGPT занял второе место среди моделей с текстовым управлением, а Photoroom Retouch стал лучшим вариантом для тех, кто предпочитает выделение объекта кистью.

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

Для редактирования изображений в BotHub доступны Nano Banana, GPT Image, Flux и другие модели.

Интерфейс платформы BotHub

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

При этом все модели работают из одного аккаунта и с общего баланса:

оплата российскими картами в рублях;
без VPN;
модели для генерации и редактирования изображений в одном интерфейсе;
возможность сравнить результат разных моделей на одном исходнике;
300 000 токенов для знакомства с сервисом по реферальной ссылке.

Получить 300 000 токенов для тестирования моделей

Частые вопросы

Можно ли удалить объект с фото нейросетью бесплатно?

Да. Cleanup.pictures, Pixelcut, Photoroom, ChatGPT и Nano Banana предлагают бесплатный доступ, но тарифы различаются: ограничения могут касаться разрешения, количества операций, числа генераций или экспорта.

Какая нейросеть лучше удаляет людей с фотографии?

В нашем тесте лучше всего справились ChatGPT и Nano Banana: они полностью удалили человека и восстановили дорогу с учетом перспективы. Для человека вдали на простом фоне достаточно Photoroom или Cleanup.pictures.

Почему после удаления объекта остается размытое пятно?

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

Как составить промпт для удаления объекта?

Назовите объект, опишите фон за ним и зафиксируйте элементы, которые нельзя менять. Базовая формула: «Удали [объект]. Восстанови [закрытый фон], сохрани [перспективу, фактуры, свет и соседние детали]. Остальные элементы изображения не изменяй».

Чем удаление объекта отличается от удаления фона?

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

Security Week 2638: опасные уязвимости в роутерах MikroTik

Mon, 14 Sep 2026 15:06:43 +0000

На прошлой неделе команда CERT из Польши обнародовала информацию о трех уязвимостях в роутерах MikroTik, две из которых активно используются в реальных атаках как минимум со второго сентября. Взлом роутеров возможен в том случае, если на устройстве разрешен доступ по протоколу SSH из Интернета. По данным на пятое сентября в сети наблюдалось более 122 тысяч потенциально уязвимых устройств.

Две наиболее опасные уязвимости имеют одинаковый рейтинг 9,2 балла по шкале CVSS. Проблема CVE-2026-67276 позволяет обойти аутентификацию по SSH в том случае, если атакующему известно имя пользователя и модуль публичного ключа. Ошибка CVE-2026-86060, в свою очередь, открывает возможность эскалации привилегий при использовании имени пользователя, содержащего некорректные символы.

Комбинация двух уязвимостей делает возможной полную компрометацию устройства. Третья обнаруженная проблема (CVE-2026-67277, CVSS 8.8) присутствует в службе проверки скорости интернет-соединения и в худшем случае может приводить к отказу в обслуживании. Примечательно, что польский CERT обнаружил две наиболее опасные уязвимости с использованием искусственного интеллекта, конкретно — с помощью моделей GPT 5.5 Cyber и GPT 5.6 Sol компании OpenAI. Автоматизированный процесс поиска уязвимостей сопровождался ручной проверкой обнаруженных потенциальных проблем.

Обнаружение багов в процессе «свободного поиска» обычно не сопровождается эксплуатацией уязвимостей. Но в данном случае атаки начались одновременно с публикацией патчей разработчиком роутеров MikroTik. Обновления стали доступны в версиях RouterOS 7.25beta3, 7.24.2, 7.23.4 и 6.49.21. Кроме того, был обновлен встроенный механизм, позволяющий определить, что устройство уже было скомпрометировано. По данным CERT Polska, зафиксированные атаки оставляют характерный след в логах роутера:

login failure for user -2 from "ip" via ssh

user "name" added by ssh:-2@"ip"

Что еще произошло

Примечательное исследование прошлой недели опубликовано командой Calif Research (новость на Хабре). С помощью ИИ-ассистента была обнаружена ошибка в VoIP-стеке приложения WeChat. Уязвимость можно задействовать, просто позвонив абоненту, причем с его стороны никаких действий не требуется. На основе данного бага в Calif разработали червь WeWorm: компрометация приложения позволяет распространить атаку по всем контактам пользователя. Компания Tencent, разработчик WeChat, закрыла уязвимость на момент публикации отчета.

Компания Microsoft выпустила рекордный набор патчей, содержащий 972 заплатки (997, если считать уязвимости браузерного движка Chromium). Из них 112 уязвимостей имеют критический рейтинг, а две являются проблемами нулевого дня. Всего в этом году Microsoft закрыла 2760 багов, что в два раза превышает показатель за весь 2025 год. Причина роста количества обнаруживаемых багов традиционная: их поиск все эффективнее автоматизируется с применением ИИ-ассистентов.

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

Критическая уязвимость в GitLab теоретически открывает доступ к приватным данным на серверах с использованием техники path traversal.

Опасная проблема закрыта в коммерческом ПО для интернет-магазинов Adobe Commerce и Magento.

Сотрудники не используют новые знания в работе: чек-лист по проектированию переноса обучения на практику

BadmaevLearning — Mon, 14 Sep 2026 15:04:42 +0000

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

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

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

«Даже при развитой инфраструктуре обучение во многих компаниях остается отдельной активностью, а не частью повседневной работы», — из исследования зрелости корпоративного обучения в России в 2026 г.

Авторы «шести дисциплин прорывного обучения» неиспользованное в работе обучение называют «браком», даже несмотря на то, что сама программа была проведена на 10 из 10. Также авторы приводят следующую статистику: только 10% затрат на обучение фактически приводят к его переносу в работу. Неиспользованное обучение дорого обходится бизнесу и часто является причиной восприятия функции L&D как центра затрат.

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

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

В этом лонгриде разбираю:

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

Что такое перенос обучения на практику?

Перенос обучения как процесс

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

Согласно модели переноса обучения Болдуина и Форда, процесс переноса включает «входные» факторы, результаты обучения и условия переноса (рис. 1). «Входные» факторы обучения — это классическая триада факторов, влияющих на эффективность обучения и переноса. К ним относятся характеристики участников обучения, дизайн программы обучения и рабочая среда.

Рисунок 1. Модель процесса переноса обучения Болдуина и Форда.

Программа обучения сама по себе напрямую влияет только на достижение учебных целей — с чем сотрудники возвращаются на свои рабочие места (1). Сами участники обучения и рабочая среда влияют на перенос как косвенно через результаты обучения (2,3), так и напрямую (4,5).

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

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

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

Рисунок 2. Динамическая модель переноса (адаптация модели Блума и коллег).

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

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

Перенос обучения как результат

Перенос обучения — степень, в которой сотрудники применяют полученные на обучении знания, навыки и установки, и улучшают результативность своей работы [4, 5].

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

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

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

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

Зачем перенос обучения нужен компании и сотрудникам?

Для компании перенос обучения — это обязательное промежуточное звено между обучением и бизнес-результатами.

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

По результатам исследования на базе крупной франшизы ресторанов быстрого питания были сделаны следующие выводы:

обучение гарантирует лишь 8% реального изменения поведения на рабочем месте. При этом обучение и организационный климат вместе определяют 54% успеха переноса.
прямая связь между успешным обучением и результативностью на рабочем месте крайне незначительна (0,02). То, как сотрудник учился, влияет на его попытки применить полученные знания и навыки в работе (0,28). Активность сотрудника на этапе переноса, в свою очередь, коррелирует с финальной оценкой его работы (0,52).
прибыльность или высокий рейтинг бизнес-юнита не гарантируют успешного внедрения обучения. Опять же решает не общая эффективность подразделения, а наличие управляемого процесса переноса.

Рисунок 3. Как обучение создает ценность для бизнеса.

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

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

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

Создаем фундамент для организации переноса

1. Учитывайте тип программы обучения

Дизайн переноса зависит от типа программы:

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

Для успешного переноса «открытых навыков» в целом наиболее важны рабочая среда (0,26), самоэффективность до начала обучения (0,23), знания после обучения (0,20) и мотивация (0,19).
Если смотреть конкретно лидерские программы и обучение по развитию гибких навыков, то факторы переноса распределяются иначе: самоэффективность после обучения (0,22), мотивация (0,20), рабочая среда (0,20) и знания после тренинга (0,16).
При этом связь этих факторов с программами по «закрытым навыкам» оказалась менее выраженной. Для обучения, в котором дается четкий алгоритм действий, решающим оказываются когнитивные способности участников обучения (0,41).

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

2. Интегрируйте перенос в операционную систему, в которой работают сотрудники

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

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

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

3. Сделайте запуск и поддержку переноса частью управленческой практики руководителей

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

Рисунок 4. Точки входа руководителя N+1 в процесс обучения и его переноса на практику.

Среди факторов переноса, на которые влияет руководитель, критичными [3, 4, 6] являются:

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

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

4. Обучите руководителей и сотрудников навыкам взаимного обучения

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

Поддержка руководителя (0,31) влияет на внедрение навыков более чем в два раза сильнее, чем поддержка коллег (0,14).В целом поддержка со стороны руководителя и коллег имеет умеренное влияние на перенос (0,21).

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

Чек-лист дизайна переноса обучения на практику

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

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

Точки контроля ДО обучения

1. Соберите информацию о рабочей среде, в которой работают сотрудники

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

В качестве фрейма для анализа среды используйте модель климата переноса или факторы среды из опросника Learning Transfer System Inventory (LTSI).
LTSI состоит из 16 факторов, влияющих на перенос результатов обучения в ежедневную рабочую практику сотрудников. Эти факторы были подтверждены результатами масштабного исследования с участием 5990 человек из 17 стран.

2. Внедрите план переноса

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

3. Зафиксируйте финальную точку обучения

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

4. Определите, как вы будете измерять изменение поведения и бизнес-результатов

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

Разделение поведения и результатов. Если поведение напрямую зависит от знаний, навыков и мотивации сотрудника, то бизнес-результаты — от системы управления, процессов и множества других факторов. Это необходимо учитывать в процессе оценки переноса и предоставления обратной связи, особенно на ранних этапах. Поведение — это индикатор использования навыка, а бизнес-результат — индикатор его эффективности.
Серия замеров, а не один статичный срез. Так как перенос — это процесс, растянутый во времени, один замер не покажет всю его картину. Например, сотрудник совершает 10 попыток применить навык за 10 недель. Первые 5 попыток были неудачными, а последние 5 — успешными. Замер на 5-й неделе покажет, что сотрудник не владеет навыком. Поэтому необходимо собирать данные на регулярной основе. Также рекомендуется уходить от субъективных оценок и собирать объективные цифровые следы действий сотрудников.

5. Сформируйте у сотрудников позитивные ожидания

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

Практика формирования позитивных ожиданий до обучения имеет умеренную связь с переносом (0,20). Также для переноса важен самостоятельный выбор обучения (0,34).

Точки контроля ВО ВРЕМЯ обучения

1. Включите в программу обучения проработку намерений (буду ли я?) и самоэффективности (могу ли я?) сотрудников

Задача тренера — перевести абстрактные цели по использованию обучения в конкретный план по схеме: «В рабочей ситуации X — я сделаю действие Y» с учетом анализа реального рабочего контекста.

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

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

Как влияют на перенос результаты обучения и реакция сотрудников на него. Полученные на обучении знания (0,24) и уверенность сотрудника в способности их применить в работе после обучения (0,20) имеют умеренную связь с переносом. Эти факторы стоит рассматривать как «гигиенические». Без них перенос невозможен в принципе, но сами по себе они успех не гарантируют.
Оценка сотрудниками полезности обучения влияет чуть сильнее (0,17), но общая реакция имеет незначительную связь с переносом (0,08). На практике это означает, высокая оценка обучения не равна внедрению навыков на рабочем месте.

Точки контроля ПОСЛЕ обучения

1. Детально спланируйте первую попытку применения

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

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

«Срок действия» результатов обучения. По мере увеличения времени между обучением и переносом самоэффективность сотрудника после обучения и полученные знания угасают. При этом связь переноса с рабочей средой, самоэффективностью до обучения и мотивацией от времени не зависит. На практике это означает, результаты обучения ослабевают со временем. Стабильными остаются только рабочая среда и мотивация, но если затянуть с внедрением, поддерживать им будет просто нечего.
Критичность первой попытки. Согласно динамической модели переноса, от первого опыта зависят все дальнейшие попытки применения обучения. В этот период необходимо обеспечить сотрудников сопровождением и поддержкой. Например, короткая сессия (after-action review) с руководителем сразу после первой попытки внедрить навык поможет сотруднику отрефлексировать опыт, сделать правильные выводы, сохранить намерение и мотивацию продолжить цикл.

2. Запланируйте серию коротких регулярных встреч руководителя с сотрудником

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

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

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

4. Внедрите систему триггеров в соответствии с планом

Короткие повторения, напоминания, микро-задания и тесты-викторины в чат-боте непосредственно на рабочем месте не дают кривой забывания пойти вниз.

5. Обеспечьте перенос поддерживающей информацией в моменте

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

6. Внедрите систему подкрепления

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

Если позитивные последствия использования обучения отсутствуют, мотивация к переносу будет низкой. Точно так же влияют на мотивацию к переносу и ситуации, когда сотрудник знает, когда сотрудник знает, что после обучения никто его не проверит и можно спокойно работать «как раньше» без каких-либо последствий [3,6].

7. Организуйте сбор обратной связи от самих сотрудников

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

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

Резюме

Следующий уровень зрелости корпоративного обучения в России — это переход от схемы «Обучение → реакции, знания и навыки» к формуле «Обучение + Перенос = Бизнес-результат», где перенос — обязательная часть программ обучения. Только так новые знания и навыки смогут стать частью ежедневной практики сотрудников, а компании получить максимальную отдачу от инвестиций в корпоративное обучение.

Если вы организуете обучение сотрудников по внешним программам, обсудите варианты поддержки переноса с провайдером и зафиксируйте их в техническом задании. Для внутреннего обучения — сделайте перенос стандартом разработки программ. При таком подходе команда L&D создает не просто курсы и тренинги, а проектирует экосистему обучения и развития сотрудников внутри компании.

Источники:

Зачем разделять роль и личность у виртуальных сотрудников

Mon, 14 Sep 2026 15:00:59 +0000

Привет, Хабр! Допустим, вы внедрили LLM-агента в финансовый отдел компании. Все хорошо, пока вы не решаете его подправить: добавить инструкцию или сделать тон дружелюбнее. С точки зрения классического инфобеза вам нужно все перевалидировать.

Личность вашего агента (инструкции, тон, самопрезентации и так далее) живет в одном доверительном домене с действиями агента. Если домен строгий, каждое изменение придется сертифицировать. Если же домен разрешительный, аудит только фиксирует действия в логах, но ничего не блокирует.

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

В этом материале расскажу о работе китайского исследователя Исена Си (Yisen Xi), который описал подход PES (Persona–Execution Separation), отделяющий «личность» виртуального агента от задач.

NB! PES требует ресурсов; это не «еще один уровень абстракции»; оно работает и заслуживает рассмотрения.

Промпты решают не все

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

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

С одной стороны, личность агента должна развиваться, для чего операторы настраивают инструкции, тон и привязку навыков. И конечно, не разово настраивают, а непрерывно улучшают.

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

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

На рынке эти подходы используют несколько моделей. Однодоменные агенты ChatGPT и ReAct замораживают личность. LangChain и Dify, наоборот, дают свободу личности с отслеживаемостью на уровне инструментов.

Готовим требования к агенту

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

G1 — свободный дрейф личности. Меняем инструкции, тон, навыки — никакой перевалидации.
G2 — полный аудит каждого действия. Привязан к стабильной идентичности.
G3 — разделение. Изменения личности не влияют на аудит.

Поговорим о реализации.

Один виртуальный сотрудник и два доверительных домена

Автор придумал простую, но не тривиальную схему: личность и исполнение не обязаны находиться в одном доверительном домене.

Предлагаемая архитектура PES состоит из трех частей: разрешающего домена, ограничивающего домена и управляемого контрактного моста. Рассмотрим их.

Разрешающий домен

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

Ограничивающий домен

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

Третий домен — управляемый контрактный мост

В этом случае два домена соединяются не произвольным API, а строгим контрактом, который пропускает только определенные типы трафика:

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

Соответственно, мост — это не туннель, а контрольно-пропускной пункт. Там проверяются разрешения в списке контроля доступа и в матрице утверждений, после чего вносится запись в аудит. А при необходимости на мосту мы будем предотвращать утечки конфиденциальных данных (Data Leakage Prevention).

Обращаю внимание читателя на пару интересных нюансов:

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

При этом аудиторский реестр привязан к базовому слою. И когда вы меняете тон общения — реестр стабилен.

Вы можете сказать: «Ну автор просто вынес исполнение в отдельный сервис, это же обычный паттерн». Не совсем так, или даже совсем не так. Обычный паттерн работает по принципу master-slave, то есть агент просто вызывает функцию. А архитектура PES предлагает контрольный контракт, определяющий утверждение, аудит и идентичность. При этом в PES один виртуальный сотрудник может работать в разных доверительных доменах.

Результаты проверки PES

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

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

Когда применять PES, а когда нет

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

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

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

Валидатор не нашёл поле is_admin, а Go его нашёл: пять ошибок при работе с JSON

Mon, 14 Sep 2026 14:50:58 +0000

Привет, Хабр!

На входе стоит валидатор: JSON Schema, которая знает про поле is_admin и снаружи выставлять его не даёт. Всё прочее схема считает лишним и пропускает не глядя.

За валидатором Go‑сервис, там структура с тегом json:"is_admin". Приходит тело, где ключ написан заглавными — IS_ADMIN.

Схема сравнивает строки побуквенно, такого имени не знает, пропускает. А json.Unmarshal знает и кладёт true куда надо.

Никто из двоих при этом не ошибся: схема отработала по спецификации, encoding/json — по своей документации, где регистр имён не различается с первых версий Go.

Разошлись они в другом: в том, какие ключи в этом теле вообще есть.

Go 1.27 вышел 19 августа, и encoding/json в нём переписали целиком, поверх encoding/json/v2.

Тот два релиза прожил под GOEXPERIMENT=jsonv2 и теперь стал основой. Семантику v1 сохранили намеренно, вплоть до регистра: поменялись тексты ошибок и скорость, поведение осталось прежним.

Поле is_admin отзывается на IS_ADMIN, Is_Admin и на знак Кельвина

Про регистр обычно помнят коротко примерно так:

Go не различает большие и маленькие буквы.

type User struct {
	Name  string `json:"name"`
	Admin bool   `json:"is_admin"`
}

bodies := []string{
	`{"NAME":"boris","IS_ADMIN":true}`,
	`{"Is_Admin":true}`,
	`{"is-admin":true}`,
	`{"is_admin":true,"IS_ADMIN":false}`,
}
for _, b := range bodies {
	var u User
	err := json.Unmarshal([]byte(b), &u)
	fmt.Printf("%-36s %+v err=%v\n", b, u, err)
}

Вывод:

{"NAME":"boris","IS_ADMIN":true}     {Name:boris Admin:true} err=<nil>
{"Is_Admin":true}                    {Name: Admin:true} err=<nil>
{"is-admin":true}                    {Name: Admin:false} err=<nil>
{"is_admin":true,"IS_ADMIN":false}   {Name: Admin:false} err=<nil>

Дефис и подчёркивание v1 всё‑таки различает, поэтому is-admin пролетел мимо.

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

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

Отсюда растёт вторая половина истории — повторы имён:

type Header struct {
	Typ string `json:"typ"`
	Alg string `json:"alg"`
}

var h Header
json.Unmarshal([]byte(`{"typ":"JWS","alg":"HS256","alg":"none"}`), &h)
fmt.Printf("%+v\n", h) // {Typ:JWS Alg:none}

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

Сравниваются имена по правилам Unicode simple folding, как в том же strings.EqualFold. Так во все это попадают буквы, которых в ASCII просто не бывает:

var c struct {
	Key string `json:"key"`
}
// U+212A KELVIN SIGN вместо обычной K
json.Unmarshal([]byte("{\"\u212Aey\":\"дошло\"}"), &c)
fmt.Printf("%+v\n", c) // {Key:дошло}

Знак Кельвина совпал с латинской k.

Длинная ſ (U+017F) точно так же совпадает с s, и paſsword доедет до поля password.

Валидатор, который сравнивает байты, ничего такого не увидит.

Фиксится это в 1.27 без единой правки в импортах.

Опция тега case:strict работает и в старом пакете:

type Strict struct {
	Admin bool `json:"is_admin,case:strict"`
}

var s Strict
json.Unmarshal([]byte(`{"IS_ADMIN":true}`), &s)
fmt.Printf("%+v\n", s) // {Admin:false}

Я бы вешал case:strict на всё, что решает про права и про деньги. Планируется миграция на v2 или нет — дела не меняет.

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

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

Nil‑слайс на выходе, null на фронтенде

В коде этого не видно совсем, вылезает у того, кто читает ваш ответ.

Nil‑слайс и nil‑карта сериализуются в null, а не в пустой массив и пустой объект:

type Page struct {
	Items []string          `json:"items"`
	Tags  map[string]string `json:"tags"`
}

var p Page
b, _ := json.Marshal(p)
fmt.Println(string(b)) // {"items":null,"tags":null}

p = Page{Items: []string{}, Tags: map[string]string{}}
b, _ = json.Marshal(p)
fmt.Println(string(b)) // {"items":[],"tags":{}}

Для клиента разница очень большая.

items.map(...) на null падает, items.length падает, а тип string[] в TypeScript этот null не описывает и от него не спасает.

И зависит всё не от логики, а от того, дошёл ли код до строчки, где слайс инициализируется.

Пустая выборка из базы вернёт nil, а выборка на одну строку, отфильтрованная до нуля элементов, вернёт нормальный слайс нулевой длины.

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

Фиксится либо дисциплиной на выходе из репозитория, где вместо nil возвращают []Item{}, либо переездом на v2, там nil‑коллекции по умолчанию кодируются как [] и {}.

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

Опечатка в имени поля ценой в бесконечный таймаут

Неизвестные ключи Unmarshal молча выбрасывает, и сигнала об этом нет никакого:

type Cfg struct {
	Retries   int `json:"retries"`
	TimeoutMS int `json:"timeout_ms"`
}

raw := []byte(`{"retries":5,"timeuot_ms":100}`)

var c Cfg
err := json.Unmarshal(raw, &c)
fmt.Printf("%+v err=%v\n", c, err) // {Retries:5 TimeoutMS:0} err=<nil>

Конфиг разобрался, ошибок нет. Что будет дальше, зависит от того, что этот ноль значит в вашем коде. У http.Client ноль означает «таймаута нет», и запрос будет висеть, пока не оборвётся соединение.

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

Запретить такое в v1 можно только через Decoder, у голого Unmarshal ничего подобного нет:

dec := json.NewDecoder(bytes.NewReader(raw))
dec.DisallowUnknownFields()
err = dec.Decode(&c) // json: unknown field "timeuot_ms"

Ошибка вернулась, а Retries к этому моменту уже записан. Декодер идёт по потоку и встаёт на первом неизвестном ключе, тело целиком он заранее не смотрит.

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

В v2 то же самое доступно одним вызовом, без обёртки:

err = jsonv2.Unmarshal(raw, &c, jsonv2.RejectUnknownMembers(true))
// json: cannot unmarshal JSON string into Go main.Cfg:
// unknown object member name "timeuot_ms"

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

Идентификатор...993 приезжает как...992

Ошибка вылезает только на больших числах, поэтому доживает до продакшена почти всегда. Когда целевой тип — interface{} или map[string]any, числа разбираются в float64: других вариантов у пустого интерфейса нет.

raw := []byte(`{"id":9007199254740993,"amount":12345678901234567}`)

var m map[string]any
json.Unmarshal(raw, &m)
fmt.Printf("%v %T\n", m["id"], m["id"]) // 9.007199254740992e+15 float64

out, _ := json.Marshal(m)
fmt.Println(string(out))
// {"amount":12345678901234568,"id":9007199254740992}

Прикинем масштаб.

Под мантиссу в float64 отведено 52 бита плюс неявная единица, целые представляются точно до 2^53 — это 9 007 199 254 740 992.

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

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

Получается, прокси, который принимает JSON, разбирает в map[string]any и отдаёт дальше, тихо портит идентификаторы и суммы.

Хотя сам он их не трогает и никакой арифметики не делает.

А еще есть места, где типы заранее неизвестны: логирование тела, ретрансляция вебхуков, generic middleware.

Со структурой всё в порядке:

var s struct {
	ID     int64 `json:"id"`
	Amount int64 `json:"amount"`
}
json.Unmarshal(raw, &s)
fmt.Printf("%+v\n", s) // {ID:9007199254740993 Amount:12345678901234567}

Когда типизировать нечего, поможетjson.Number — строка, которая помнит исходную запись числа и ни к чему её не приводит:

var m2 map[string]any
dec := json.NewDecoder(bytes.NewReader(raw))
dec.UseNumber()
dec.Decode(&m2)
fmt.Printf("%v %T\n", m2["id"], m2["id"]) // 9007199254740993 json.Number

out2, _ := json.Marshal(m2)
fmt.Println(string(out2))
// {"amount":12345678901234567,"id":9007199254740993}

Это единственное место из пяти, которое v2 не фиксит. jsonv2.Unmarshal в any тоже кладёт float64 и промахивается на тех же двух числах. Т.е поменять представление чисел по умолчанию значило бы сломать всех, кто рассчитывает на float64. Но и надеяться, что переезд сам всё исправит, не выйдет.

time.Time и вложенная структура, которых omitempty не видит

omitempty выбрасывает поле, если значение — false, 0, nil‑указатель, nil‑интерфейс либо пустые массив, слайс, карта или строка. Структур в этом списке нет и никогда не было.

type Page struct {
	Num  int `json:"num"`
	Size int `json:"size"`
}

type Filter struct {
	Q    string    `json:"q,omitempty"`
	From time.Time `json:"from,omitempty"`
	Page Page      `json:"page,omitempty"`
	N    int       `json:"n,omitempty"`
}

b, _ := json.Marshal(Filter{})
fmt.Println(string(b))
// {"from":"0001-01-01T00:00:00Z","page":{"num":0,"size":0}}

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

Дальше это едет в чужой API, который читает from буквально и начинает выборку с первого января первого года.

Или, если с валидацией там повезло, отвечает четырёхсотым на дату вне диапазона.

С Go 1.24 есть опция тега omitzero.

Она смотрит не на «пустоту», а на нулевое значение типа, и если у типа есть метод IsZero() bool, спрашивает его.

У time.Time метод есть:

type Filter2 struct {
	Q    string    `json:"q,omitzero"`
	From time.Time `json:"from,omitzero"`
	Page Page      `json:"page,omitzero"`
}

b, _ = json.Marshal(Filter2{})
fmt.Println(string(b)) // {}

На коллекциях две опции всё же расходятся.

omitempty выбрасывает слайс или карту нулевой длины, включая nil.
omitzero выбрасывает только nil, а инициализированный пустой слайс оставляет.

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

А если просто поменять импорт на v2?

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

Часть из них — то, ради чего переезжают. Имена сопоставляются точно, повтор ключа даёт ошибку, nil‑коллекции кодируются как [] и {}. Невалидный UTF-8 внутри строки тоже роняет разбор, а не подменяется тихо на символ замещения. Другая часть:

// v1 сортирует ключи карты, v2 — нет
m := map[string]int{"z": 1, "a": 2, "m": 3, "b": 4}
b1, _ := json.Marshal(m)   // {"a":2,"b":4,"m":3,"z":1}
b2, _ := jsonv2.Marshal(m) // {"b":4,"z":1,"a":2,"m":3} — и каждый раз по-новому

// time.Duration в v2 не имеет представления по умолчанию
type D struct {
	TTL time.Duration `json:"ttl"`
}
_, err := jsonv2.Marshal(D{TTL: 5 * time.Second})
fmt.Println(err)
// json: cannot marshal from Go time.Duration within "/ttl":
// no default representation

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

подписи запросов;
снапшот‑тесты;
сравнение конфигов.

Возвращается опцией jsonv2.Deterministic.

С time.Duration решение осознанное — в v1 она кодировалась числом наносекунд, что читателю JSON ни о чём не говорит, — но код, который на это опирался, упадёт в рантайме, а не на сборке.

Мельче калибром, но тоже ловится не сразу, ведь массив фиксированной длины в v2 требует такой же длины в JSON, а [N]byte кодируется в base64-строку вместо массива чисел.

Первое обычно к лучшему, второе меняет форму тела и ломает читателя на той стороне.

Обе штуки откатываются опциями UnmarshalArrayFromAnyLength и FormatByteArrayAsArray из пакета v1.

Но интереснее всего omitempty: у знакомой опции меняется смысл. В v2 поле выбрасывается, если кодируется в пустое JSON‑значение — null, пустая строка, пустой объект, пустой массив.

Ноль пустым JSON‑значением не считается:

b, _ := jsonv2.Marshal(Filter{})
fmt.Println(string(b))
// {"from":"0001-01-01T00:00:00Z","page":{"num":0,"size":0},"n":0}

Поле n с тем же самым тегом в v1 из вывода уходило, а в v2 остаётся.

Документация советует перевести все omitempty на булевых, числовых, указательных и интерфейсных полях в omitzero — эта опция в обеих версиях работает одинаково.

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

Переезжать при этом можно постепенно.

Опции в v2 применяются слева направо, поздние перекрывают ранние, а jsonv1.DefaultOptionsV1() собирает весь набор старого поведения одним аргументом:

var s struct {
	Admin bool `json:"is_admin"`
}
err := jsonv2.Unmarshal([]byte(`{"IS_ADMIN":true}`), &s,
	jsonv1.DefaultOptionsV1(),
	jsonv2.MatchCaseInsensitiveNames(false))
fmt.Printf("%+v err=%v\n", s, err) // {Admin:false} err=<nil>

Тут мы остались на семантике v1 целиком и выключили ровно одно поведение — сопоставление без учёта регистра.

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

Что со всем этим делать

Ни одно из пяти разобранных мест не является багом.

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

Регистр не различают, чтобы {"Name": ...} попадало в поле Name без всякого тега.

null вместо [] — потому что nil‑слайс в Go честно ничего не значит.

float64 для any — потому что других чисел у пустого интерфейса нет.

По отдельности всё объяснимо, а вместе получается пакет, документация которого в Go 1.27 говорит:

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

Порядок я бы выбрал такой.

Сначала теги, они бесплатные и работают в старом пакете:

case:strict на всё, что решает про права и деньги;
omitzero вместо omitempty на числах, булях и time.Time.

Потом DisallowUnknownFields на конфигах и внутренних ручках, но не на публичном входе.

Переезд на encoding/json/v2 — отдельной задачей, через DefaultOptionsV1() и по одному отличию за раз.

Первым делом проверить всё, что хеширует или сравнивает сериализованный результат.

Если поедет прямо на сборке, в 1.27 есть выход GOEXPERIMENT=nojsonv2, он возвращает старую реализацию целиком.

Насчет ресурсов, особо не разбирался, но в release notes было написано, что маршалинг примерно на уровне старого, а анмаршалинг заметно быстрее.

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

На открытых уроках разберём, как глубже понимать устройство Go‑приложений и проектировать надёжные микросервисные системы:

22 сентября в 20:00. «Горутины и каналы: под капотом и нюансы в продакшене». Записаться
22 октября в 19:00. «Основы проектирования бизнес‑логики в микросервисной архитектуре». Записаться

А полный список бесплатных уроков сентября вы найдете в дайджесте.

Выходит Java 27

Mon, 14 Sep 2026 14:47:44 +0000

15 сентября 2026 года вышла Java 27. Это не LTS-релиз, и новых возможностей языка, ради которых команды бросятся переписывать код, здесь немного. Зато поведение самой JVM меняется достаточно заметно.

Компактные заголовки объектов включаются по умолчанию, G1 становится стандартным сборщиком мусора даже в окружениях с небольшим количеством ресурсов, а Java Flight Recorder начинает автоматически скрывать пароли, токены и другие чувствительные значения.

Для Spring Boot-приложения это может означать меньше занятый heap без изменений в коде. А может означать неожиданно другой профиль потребления CPU в маленьком контейнере или неработающий стартовый скрипт из-за удалённого JVM-флага.

Разберёмся, что именно меняется и что стоит проверить до обновления.

Коротко

В Java 27 есть три важных изменения runtime:

Compact Object Headers включены по умолчанию. Во многих приложениях это способно сократить занятый heap на 10–20%, но результат зависит от структуры объектов.
G1 теперь выбирается по умолчанию во всех окружениях. Маленький контейнер, который раньше запускался с Serial GC, после обновления может получить другой профиль памяти, CPU и пауз.
JFR автоматически редактирует чувствительные данные в аргументах JVM, переменных окружения и системных свойствах.

Кроме того, удалены некоторые устаревшие JVM-флаги, изменился JSON-формат дампов потоков и появились новые диагностические возможности jcmd.

Откуда в Java-объекте лишние байты

Объект в heap состоит не только из объявленных нами полей. JVM хранит рядом служебную информацию:

состояние блокировки;
данные, связанные с identityHashCode;
возраст объекта для сборщика мусора;
ссылку на описание класса объекта.

В типичной 64-битной JVM с включёнными compressed class pointers заголовок объекта занимал 12 байт:

8 байт для mark word;
4 байта для ссылки на класс.

Из-за выравнивания объект без полей обычно занимал не 12, а 16 байт. Получалась любопытная ситуация: экземпляр пустого класса потреблял больше памяти на устройство JVM, чем на собственные данные.

final class Marker {
}

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

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

Что делают Compact Object Headers

Компактные заголовки объединяют compressed class pointer и mark word. В результате минимальный заголовок на 64-битной JVM уменьшается с 96–128 до 64 бит.

Фича прошла несколько стадий:

в JDK 24 она была экспериментальной;
в JDK 25 стала финальной, но требовала -XX:+UseCompactObjectHeaders;
в JDK 27 включается по умолчанию.

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

java -XX:-UseCompactObjectHeaders -jar application.jar

Проверить текущее значение параметра можно так:

java -XX:+PrintFlagsFinal -version | grep UseCompactObjectHeaders

Действительно ли heap уменьшится на 20%

В материалах OpenJDK и Inside Java встречается оценка экономии heap в диапазоне 10–20%. Но её нельзя читать как обещание уменьшить потребление любого приложения ровно на 20%.

Результат зависит от объектного графа.

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

Если же основную часть heap занимают большие массивы byte[], кэши с крупными значениями или несколько тяжёлых структур, относительная экономия окажется скромнее.

Есть и важное различие между размером live set и лимитом heap. Если контейнер запускается с -Xmx2g, Java 27 не превратит этот параметр в -Xmx1600m. Уменьшиться может объём памяти, который занимают живые объекты. Это потенциально даёт:

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

Сначала нужно сравнить метрики, и только затем менять лимиты контейнера.

Как проверить эффект на Spring Boot-приложении

Лучше всего сравнивать две конфигурации одной и той же Java 27:

java -XX:+UseCompactObjectHeaders -jar application.jar

и:

java -XX:-UseCompactObjectHeaders -jar application.jar

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

Во время теста стоит смотреть не только на максимальный RSS процесса, но и на:

размер live set после полной сборки;
частоту и длительность GC;
allocation rate;
количество старых объектов;
время прогрева;
p95 и p99 latency;
CPU на одинаковом профиле нагрузки.

Для анализа структуры отдельных классов можно использовать Java Object Layout:

System.out.println(
    org.openjdk.jol.info.ClassLayout
        .parseClass(OrderDto.class)
        .toPrintable()
);

Но JOL показывает layout конкретного объекта, а не экономику приложения целиком. Для итогового вывода всё равно понадобится профиль под реалистичной нагрузкой.

G1 теперь используется даже на маленьких машинах

G1 считается сборщиком мусора по умолчанию с JDK 9, но существовало исключение. Если JVM определяла окружение как машину с ограниченными ресурсами, она могла выбрать Serial GC.

В Java 27 это исключение убрали. Теперь G1 используется по умолчанию во всех окружениях, если сборщик не указан явно.

Узнать выбранный GC можно командой (или из GarbageCollectorMXBean):

java -Xlog:gc -version

В Java 27 без дополнительных параметров в журнале должна появиться строка о G1.

Для обычного серверного приложения это выглядит логично. G1 умеет параллельно обрабатывать части heap и стремится удерживать паузы в заданных пределах. Но более современный GC не означает «лучший GC для любого процесса».

Serial GC прост, использует меньше служебных структур и может быть вполне разумным выбором для маленьких утилит, однопроцессорных окружений и сервисов с очень небольшим heap.

Почему это важно для Kubernetes

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

Представим Spring Boot-сервис с такими ресурсами:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "384Mi"

На предыдущей версии JDK он мог автоматически получить Serial GC. После перехода на Java 27 тот же сервис без изменения параметров запуска получит G1.

Это способно изменить:

количество GC-потоков;
потребление CPU во время сборки;
служебные расходы GC;
длительность пауз;
поведение приложения при приближении к memory limit.

Если Serial GC был осознанным выбором, его лучше зафиксировать явно:

java -XX:+UseSerialGC -jar application.jar

Если сборщик никогда не указывался, перед обновлением нужно снять фактическую конфигурацию текущей JVM и сравнить её с Java 27. Иначе изменение будет незаметно в коде и манифестах, но проявится в продакшн-метриках.

JFR больше не должен записывать токены открытым текстом

Java Flight Recorder собирает подробную диагностическую информацию с небольшими накладными расходами. Это делает JFR удобным для использования не только локально, но и в продакшене.

Проблема в том, что вместе с полезными данными в запись могли попасть:

аргументы запуска JVM;
переменные окружения;
системные свойства.

Именно через эти механизмы приложения часто получают секреты:

export PAYMENT_API_TOKEN=super-secret-value

java \

  -Dspring.datasource.password=another-secret \

  -XX:StartFlightRecording=filename=application.jfr,duration=60s \

  -jar application.jar

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

В Java 27 JFR по умолчанию скрывает значения, названия которых похожи на:

password;
passwd;
token;
secret;
credential;
api-key;
private-key;
client-secret.

Сопоставление выполняется без учёта регистра и поддерживает glob-шаблоны.

Можно добавить собственное имя:

java \

  -XX:FlightRecorderOptions:redact-key=+dburl \
  -jar application.jar

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

Для аргументов JVM используется отдельный параметр:

java \
  -XX:FlightRecorderOptions:redact-arguments=@redact-patterns.txt \
  -jar application.jar

Посмотреть доступные настройки можно через встроенную справку -XX:FlightRecorderOptions.

Почему одной редактуры JFR недостаточно

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

Во-первых, фильтрация основана на именах и шаблонах. Переменная PAYMENT_API_TOKEN будет распознана, а условная переменная ACCESS может не попасть под стандартное правило.

Во-вторых, приложение способно самостоятельно записать чувствительное значение в пользовательское JFR-событие, лог или exception message.

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

Получается, что автоматическая редактура является дополнительным защитным слоем, а не заменой Vault, Kubernetes Secrets, IAM и нормальной политики доступа к диагностике.

Какие старые JVM-флаги перестанут работать

В Java 27 окончательно удалены:

-noclassgc
-noverify
-verifyremote
-Xverify:none

Для -noclassgc существует замена:

-Xnoclassgc

Для -verifyremote:

-Xverify:remote

У -noverify и -Xverify:none прямой замены нет.

Последние два флага нередко оставались в старых шаблонах запуска, Dockerfile и конфигурациях IDE как попытка ускорить старт. После перехода на Java 27 JVM завершит запуск с ошибкой, поэтому искать их нужно заранее:

grep -R --line-number \
  -e=-noverify \
  -e=-Xverify:none \
  -e=-noclassgc \
  -e=-verifyremote \
  .

Также параметр:

-XX:InitiatingHeapOccupancyPercent

переименован в:

-XX:G1IHOP

Старое имя пока работает, но уже помечено устаревшим.

Опция -XX:[+|-]UseCompressedClassPointers стала obsolete. JVM всегда использует compressed class pointers, а передача старого параметра приведёт к предупреждению.

Ещё несколько изменений для эксплуатации

В jcmd появилась команда, которая показывает активные security properties работающей JVM:

jcmd <pid> VM.security_properties

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

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

Изменился и JSON-формат thread dump. Идентификаторы потоков, их количество и PID теперь записываются числами, а не строками:

{
  "tid": 42
}

В корневом объекте появился formatVersion со значением 2.

Если внутренние инструменты разбирают JSON-дампы в строго типизированную модель и ожидают "tid": "42", после обновления они могут перестать работать. Это тот редкий breaking change, который затрагивает не приложение, а окружающую его диагностическую инфраструктуру.

Наконец, из JDK удалён экспериментальный JVM Compiler Interface, включая jdk.internal.vm.ci, встроенные компоненты Graal compiler и флаг -XX:+UseGraalJIT. Обычные Spring Boot-приложения этого не заметят, но нестандартные сборки и инструменты, которые полагались на JVMCI внутри OpenJDK, нужно проверить отдельно.

Стоит ли переходить

Java 27 не является LTS-релизом. Для большинства компаний основной production-версией останется Java 25, а следующей LTS станет Java 29.

Но пропускать Java 27 при тестировании не стоит.

Во-первых, Compact Object Headers уже стали финальной возможностью в Java 25. Java 27 показывает, каким будет стандартное поведение будущих версий.

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

В-третьих, автоматическая редактура данных JFR делает диагностику безопаснее и, вероятно, позволит большему числу команд использовать Flight Recorder постоянно.

Java 27 интересна не новым синтаксисом. Она меняет стоимость существующих объектов, правила выбора GC и безопасность эксплуатационных данных. Код может остаться прежним, но профиль приложения уже будет другим.

Именно поэтому этот релиз стоит проверять не глазами компилятора, а нагрузочными тестами, JFR и метриками контейнера.

Источники

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

«Агат», «ДВК», «Микроша»: на чём советские гики учились программировать? Часть 1

Mon, 14 Sep 2026 14:24:28 +0000

В начале 80-х мир захлестнула — по крайней мере его гиковскую часть — ПК-мания, и у «буржуев» набирали высоту BBC Micro, ZX Spectrum, MicroBee, Apple II и другие машинки, на которых миллионы западных школьников с упоением писали свои первые программы и игры.

А как дела обстояли в наших весях? Давайте чуть-чуть разберёмся — и да простят меня за неточности почтенные олды, заставшие те времена лично!

Вместо пролога.

«Микроша»

Первое появление: 1986
Статус: Звезда школьных ЭВМ-классов

«Микроша». Источник: red-innovations.su.

Имя «Микроша» — это портманто из слов «микрокомпьютер» и «школа». Надо сказать, он действительно оправдывал свой уменьшительно-ласкательный ник, так как весил всего лишь 3 килограмма. Автором схемотехники стал выдающийся МИЭМовский инженер Юрий Озеров, до этого отметившийся как «соавтор железа» для компьютера «Радио-86РК», на котором «Микроша» и был основан, а также для первого и, наверное, последнего компьютера целиком узбекского происхождения — «Согдиана-1».

Но и технические возможности «Микроши» были довольно лилипутскими. Компьютер базировался на однокристальном КР580ВМ80А, который был скопирован с интеловского чипа Intel 8080. Он работал с частотой 1,77 МГц, имея при этом 32 Кб оперативной и слезоточиво скромные 2 КБ постоянной памяти — у того же BBC Micro ПЗУ было от 32 до 48 Кб в зависимости от комплектации.

Видеоадаптер «Микроши» был монохромным, с поддержкой текстового режима в формате 64 × 25 символов. Сами же изображения на ходу ваялись алгоритмом псевдографики с разрешением 128 × 50 точек.

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

Промо-снимок «Микроши» из журнала «Радио», 1986 год. Источник: Архив журнала “Радио”.

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

Почти целый «Микроша» без двух клавиш, но в рабочем состоянии. Источник: red-innovations.su.

Его можно было подружить с телевизором. Источник: red-innovations.su.

Источник: red-innovations.su.

Но и без игр не обошлось! На «Микроше» они были, пускай и не такие зрелищные, как на зарубежных монстрах, но в каталоге можно было найти «Пакмэна» (оригинальное написание), «Удава», «Ксоникс», «Тетрис», «Клад», «Цирк» и другие. К слову, к «Микроше» выходили дополнительные кассеты, на которых можно было отрыть такие сокровища, как Pascal, макроассемблер с отладчиком, редактор структурных текстов и ещё пригоршню игр а-ля «Мешанина» или «Бармен».

Официальная кассета, прилагающаяся к «Микроше». Источник: webhamster.ru.

Стоил «Микроша» 500 полновесных советских рублей, и это, на самом деле, совсем не дёшево. Для контекста: за эти же деньги можно было купить большой холодильник «Минск», за две сотни сверху урвать огромный и цветной «Горизонт», а на 250 рэ съездить небольшой семьёй из трёх человек на юга (при наличии родственников, у которых можно было пожить).

Тем не менее юные программисты того времени «Микрошей» восхищались, хотя и находили некоторые изъяны. К примеру, по отзывам приобщившихся, клавиатура у него была ужасно неудобная и чугунно-тяжёлая, но зато, наверное, монолитная. Делать бы гвозди из этих QWERTY’ей!

«Агат»

Первое появление: 1984
Статус: Наш ответ ~~Чемберлену~~ Джобсу

«Агат». Источник: digitalstudionn.ru.

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

Один из прототипов компьютера «Агат». Источник: pcnews.ru.

Основная часть машины была честно срисована с американского Apple II Plus, и это был однокристальный центральный процессор MOS Technology 6502 с частотой 1 МГц. Но то ли у инженеров НИИВКа взыграла профессиональная гордость и обида за державу, то ли руководство опасалось обвинений в интеллектуальном хищничестве и репутационного ущерба советской науки, но остальные компоненты компьютера пилились буквально с нуля.

Не только фурычит, но и прекрасно себя чувствует. Источник: cyber-museum.ru.

«Агат» был настоящей зверь-машиной. С частотой в 1 МГц его восьмиразрядный процессор мог выполнять 500 000 операций в секунду. Постоянная память зиждилась на 2 Кб, а оперативка включала от 64 до 128 Кб, причём за счёт модульной модификации её можно было расширить аж до 640 Кб!

«Витринный» образец для демонстрации партийным функционерам. Источник: cyber-museum.ru.

Видеоконтроллер в «Агате» размещался прямо на системной плате, а в роли видеопамяти выступал один из участков базовой памяти, который выбирал сам программист. Поддерживались два основных текстовых режима — 32 × 32 и 64 × 32, а также несколько графических, от 64 × 64 до 512 × 256. Компьютер оснащался дисководом, через который ему можно было «скармливать» дискеты объёмом до 840 Кб.

Процессор MOS Technology, который закупался СССР специально для «Агатов».

Трагическим изъяном «Агата» была его полная несовместимость как с другими советскими персональными машинами, так и с его эппловским исходником — управление памятью в машинке осуществлялось иначе. А графическая система подвергалась переработкам. Зато чип в компьютере стоял подлинный, американский!

«Агат», вид изнутри. Источник: kerenskiy..

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

Об «Агате» даже знали по другую сторону занавеса, и в журнале Byte вышла статья за 1984 год, написанная Лео Борсом о том, является ли «Агат» плохим контрафактом по мотивам Apple II или нет. Из неё можно почерпнуть, что Пепси продавалась в каждом московском ларьке, клавиши Escape у «Агата» не было, а сам автор почему-то окрестил компьютер «yablochka». Здесь можно почитать перевод..

Занятная иллюстрация к статье Борса, журнал Byte. Источник: Internet Archive.

В довесок к персоналке в коммунистических тонах шёл дистрибутивный пакет с разным софтом и играми, наречённый «Школьницей». Его основой были учебно-производственный язык Рапира, вдохновлённый Паскалем и с ключевыми командами на русском (туше!), графическая система «Шпага», с помощью которой можно было рисовать и даже делать простые мультики, и язык Робик для младшеклассников.

Структура системы «Школьница». Источник: agatcomp.ru.

Среди прочего, с Робиком в комплекте шла та самая «Черепашка», почерпнутая из американской среды программирования KTurtle. Для тысяч школьников она стала первым знакомством с магией кода, когда по их инструкции черепашка, Том Сойер в амплуа маляра или муравей послушно ползали по экрану, рисуя таким образом разные узоры.

Игры на «Агате» тоже были. Помимо игры в Тома Сойера, красящего экран, ещё прилагались «Дежурик» про хлопотливого робота, наводящего порядок на экране, «Машинист», «Анацефал 1» с целым шахматным ИИ и другие. На картинке игра «Станок», на которой нужно было управлять токарным станком, избегая брака, — советский геймдев суров. Источник: bitblaze.ru.

В общем, «Агат» был одним из самых долгоиграющих советских ПЭВМ, причём и после распада страны. Стоил он сумасшедших денег — 3 900 рублей: для сравнения за 6 000 можно было купить однушку. Он активно использовался в 90-х, а по некоторым сведениям, в отдельных уголках нашей необъятной он продолжал работать в компьютерных классах даже в начале 2000-х. Вот что значит делать на века.

ДВК

Первое появление: 1983
Статус: Одна из самых тиражируемых машин СССР

Стильный, модный, комсомольский ДВК-2 (слева) рядом с венгерским компьютером Video-ton 340. Источник: Reddit.

Зеленоградский ДВК, он же Диалоговый вычислительный комплекс, был аппаратом поистине эпохальным. А за его появлением на свет стоял НИИ точной технологии, он же НИИТТ (не путать с «NEET»).

Архитектура PDP-11 была весьма почитаема в Советском Союзе. Подлинные причины неизвестны, но, возможно, всё дело крылось в простой и элегантной 16-разрядной системе команд, Unibus-шине, связавшей в единую упряжку процессор, память и периферию, и в том, как эффективно PDP-машины справлялись с управлением различных процессов. Ну или, может, это была просто сила привычки.

Ещё один ДВК-2. Источник: getbb.ru.

В любом случае в 1981 году архитектуру DEC PDP-11 решили по-мичурински адаптировать к родной айтишной почве, изготовив на её базе «ДВК». Только наш комплекс должен был быть ещё круче и продвинутее, будучи оснащённым шестнадцатиразрядным микропроцессором К1801ВМ1 — первым «однокристальником» для архитектуры PDP в мире, так-то.

ДВК-1 работал на процессоре с тактовой частотой 5 МГц. В него входили 48 Кбайт оперативной памяти, два дисковода для 5,25-дюймовых дискет и пузатый монитор, выводивший на тёмном фоне зелёные символы, словно приглашая непуганых советских прогеров в объятия «Матрицы».

Тот самый матричный фосфор на дисплее. Источник: getbb.ru.

В первых итерациях ДВК жёсткой памяти, увы, не было. Вместо этого в дисководы MX0: и MX1: вставлялись две дискеты. Первая содержала систему, вероятно ФОДОС, она же Файловая однопользовательская диалоговая операционная система, клон RT-11, которая использовалась PDP-машинами. Вторая содержала уже непосредственно программы и, в некоторых случаях, заветные игрушки.

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

Помимо дежурного Тетриса, на машине можно было насладиться неустановленной буржуйской игрой по мотивам «Стартрека», в переводе которой на русский фигурировали интересные реплики: «Внимание! В квадрате замечены семижопы!» Ещё прилагалась версия Loadrunner’а под названием «Специалист» и какой-то фиксированный шутер а-ля Galaxian, где во врагов нужно было стрелять вопросительными знаками.

Та самая игра по «Стартреку». Источник.

«Специалист» по мотивам Loadrunner. Источник.

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

Вид сбоку на корзину ДВК-3М. С их помощью можно было устанавливать сменные печатные платы по системной шине МПИ. Источник: retropc.org.

Плата контроллера жёстких магнитных дисков. Источник: retropc.org.

Вентилятор блока питания в ДВК-3М. Говорят, гудел страшно. Источник: retropc.org.

Всего зеленоградский «Квант» выпустил около 200 тысяч машин ДВК. Которые производились вплоть до 1993 года. Весьма впечатляющая цифра. Apple II, для сравнения, просуществовал на четыре года больше, продавался по всему миру и ушёл тиражом в районе 1,25 миллиона за это время.

Мой годовой опыт в разработке с ИИ агентами и главные выводы

ANTON62 — Mon, 14 Sep 2026 14:15:27 +0000

Этот пост для разработчиков, которые еще скептически относятся к кодингу с ИИ агентами и не используют его. Мир стремительно меняется, пора «проснуться» и поменять методику работы.

Ниже я расскажу личный опыт, чтобы было нагляднее.

Москва, Сколково. Хакатон Битрикс24, ноябрь 2025 г.

Моя история

ИИ тема хайповая, и я, конечно, следил за ней еще с 2019 г. Но это были классические, не генеративные модели. Затем в ноябре 2022 появляется ChatGPT, следом в июле 2023 года DeepSeek. И мне больше он понравился. Пока все это было в рамках «О, прикольно, он разговаривает».

Затем я в конце 2024 года ради прикола попросил DeepSeek сверстать HTML структуру для простого лендинга для медцентра — и он мне выдал чистенькую вёрстку, все теги и наименования классов четкие. Я, так сказать, испугался за свою профессию и хлеб. Это где ж такое видано, чтоб машина программировать начала. Ну, думаю, ладно, это еще не скоро и дальше иногда просто спрашивал в чате некоторые подсказки.

Затем в ноябре 2025 года я поехал на партнерскую конференцию Битрикс24, где проходил хакатон вайбкодинга. Я к нему до этого 3 недели готовился — надо отдать должное спецам из Битрикс24, они все материалы подготовили и нянчились с нами, как с малыми детьми, разжевывая, как все развернуть в докере, как оплатить зарубежные ИИ модели (советовали Sonnet, ну на крайняк ChatGPT) и как разрабатывать с помощью ИИ. В итоге на хакатоне я поучаствовал, попробовал со всеми поработать, получил стартовый пинок и интересный опыт.

После этого все изменилось

Я пару недель переваривал эту информацию и опыт, и начал более активно в этой теме разбираться, прошел все муки вайбкодера по поиску методов оплаты напрямую в Openapi и Anthropic, через провайдеров (Openrouter), в ход шли все инструменты — даже крипта. Это сейчас все просто, а год назад было сложнее).

В конце 2025 года ИИшка программировала, ну так средненько (конечно Sonnet и Opus делали свое дело, но это бешеные деньги и для меня не вариант был).

Все изменилось в начале 2026 года с появлением ChatGPT 5.3 — агент работал четко и по делу. С этого момента у меня консоль каждый день работала и пилила какие‑то мои пет‑проекты. Сейчас их в стадии MVP больше 30 штук. Из них публично запущен только один, а внутренних инструментов штук 5 работает, как отлажу до конца — поделюсь со всеми на GitHub/

То, что остальные не запущены, меня не расстраивает, я решил для себя, что просто получал опыт работы с ИИ агентами. Но зато я как разработчик ноября 2025 года и сейчас огромная разница в компетенциях ИИ кодинга. 16 лет опыта разработки + ИИ агент позволяет мне писать на любом языке React, Go, Rust, Python и делать сложные проекты с минимальной командой.

Теперь самая мякотка — выводы и ценные советы

Что я сейчас могу сказать. Парни, разработчики, если вы эту тему не пробовали, либо пробовали и не получилось — бросайте все и срочно изучайте, пробуйте, получайте опыт.

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

Все современные модели (OpenAI ChatGPT, Anthropic Sonnet, Opus, DeepSeek, GLM, Kimi) программируют лучше и быстрее мидла‑разработчика, как минимум на уровне сеньёра и в некоторых случаях лучше.

Если вы начинающий, то для работы берите сразу DeepSeek Harness, ну или на крайняк OpenCode или Pi Code. А Cursor, Windsurf и подобные решения даже не пробуйте.

Забудьте про IDE, не требуется она больше — консоль + ИИ агент ваш лучший друг.

Не запускайте агента хозяйничать на проде, не стоит оно того).

Изучите методологию Spec Driven Development, без этого агент будет творить на вашем проекте, что ему вздумается. А также изучите фреймворки OpenCpec и Spec Kit от GitHub. Идея простая: не позволяй ИИ идти от размытого требования сразу к коду. Сначала spec.md (что нужно), потом plan.md (как делать), потом tasks.md (на какие шаги разбить).

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

Какие профессии возможно появятся и к чему вам следует стремиться

1. Архитектор мультиагентных систем (Multi‑Agent Workflow Architect)

Специалист, который проектирует не просто код, а «команды ИИ‑агентов». Он настраивает пайплайны, где один ИИ пишет код, второй его тестирует, третий ищет уязвимости, а четвертый деплоит. От его настроек зависит, не сойдет ли ИИ с ума и не обрушит ли прод. Это новый уровень DevOps и Архитектуры.

2. Инженер по верификации ИИ‑кода и безопасности (AI Code Security & Compliance Engineer)

ИИ часто использует устаревшие или уязвимые библиотеки, а также может случайно «залить» в публичный репозиторий закрытые ключи или коммерческую тайну компании. Этот специалист создает барьеры (guardrails) и системы автоматического аудита сгенерированного кода.

3. Инженер по миграции легаси с помощью ИИ (AI Legacy Modernization Specialist)

В банках, госсекторе и на заводах лежат миллионы строк кода на COBOL, старых версиях Java, C# и PHP, которые люди боятся трогать. Этот специалист умеет правильно «кормить» ИИ контекстом старых систем, чтобы безопасно переписывать их на современные стеки.

4. Доменный RAG‑интегратор / Инженер корпоративного контекста (Enterprise Context Broker)

Базовые модели ничего не знают о внутренней кухне конкретной компании. Этот специалист настраивает локальные LLM и RAG‑системы (Retrieval‑Augmented Generation) так, чтобы ИИ‑агенты имели безопасный доступ к внутренней документации, базам данных и Jira, не нарушая периметра безопасности.

5. ИИ‑психолог / Дебаггер агентов (Agentic Debugging Specialist)

Когда сложный мультиагентный пайплайн заходит в тупик (агенты начинают бесконечно спорить друг с другом или генерировать бред), этот специалист читает «мысли» (chain of thought) моделей, находит логические ошибки в промптах и системных инструкциях, «лечит» workflow.

P. S.

Еще раз повторю — не теряйте время, изучайте ИИ‑кодинг, получайте опыт и вы останетесь в рынке. У кого есть вопросы, можете написать мне в Телегу или здесь в личку (все данные в профиле есть), чем смогу — помогу, расскажу.

Как разделить фронтенд на модули и связать их между собой: на примере маркетплейса

Mon, 14 Sep 2026 14:07:13 +0000

Вступление

Привет, меня зовут Иван Некипелов, я технический руководитель команды фронтенд-инфраструктуры в RWB.

Эта статья для frontend-разработчиков, которые хотят сделать растущее приложение проще в поддержке. На примере маркетплейса покажем, как разделить код на модули, связать сервисы и проверять бизнес-логику отдельно от интерфейса. Примеры написаны на React и TypeScript, но подход можно использовать с другим UI-фреймворком.

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

Мы используем собственное разбиение на feature-модули: каталог, корзину, доставку и другие части приложения. Это не реализация Feature-Sliced Design, хотя отдельные принципы могут совпадать. Разберём структуру директорий, допустимые зависимости, сборку сервисов через DI, хранение состояния и доступ к платформенным API.

Код примера доступен в репозитории. В нём есть работающий интерфейс, простой DI-контейнер, архитектурные ESLint-правила, ADR и инструкции для агентов.

Физическая организация модулей

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

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

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

Каждый feature-модуль владеет определённой бизнес-логикой. Например, всё, что относится к корзине, находится внутри basket, логика каталога — внутри catalog, а работа с избранным — внутри favorites. Благодаря этому структура проекта отражает устройство продукта, а код, изменяющийся по одной бизнес-причине, оказывается собран в одном месте.

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

Слой app отвечает за процессы всего приложения. Здесь находятся точки входа, глобальная конфигурация, провайдеры и composition root — место, в котором создаются общие зависимости и feature-модули связываются между собой.

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

Внутреннее устройство feature-модуля

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

Модуль создаёт только те роли, которые ему действительно нужны: небольшая фича может состоять из модели и одного хука, а более сложная — содержать собственные сервисы, состояние и UI.

Роль	Ответственность
model	Типы, схемы валидации, мапперы и доменные константы
services	Бизнес-операции, работа с backend и внешними API, обработка результатов
hooks	Координация пользовательских действий, состояния и сервисов в React
store	Локальное и UI-состояние фичи
ui	Компоненты интерфейса, принадлежащие фиче
utils	Чистые вспомогательные функции без обращений к внешнему состоянию
di	Токены и функции регистрации зависимостей

Каждая роль предоставляет свой публичный вход через index.ts: в нём экспортируем только то, что понадобится остальному приложению. Общий barrel-файл в корне фичи не создаём — по импорту должно быть видно, какую часть фичи мы используем.

Как модули взаимодействуют между собой?

Физического разделения кода по директориям недостаточно: границы модулей определяются не их расположением, а связями между ними. Поэтому мы явно задаём допустимое направление зависимостей:

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

Дополнительно запрещаем runtime-импорты между разными фичами и импорты между разными страницами.

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

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

Type-only зависимости

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

Поэтому type-only импорты между фичами разрешены:

В отличие от обычного импорта, import type удаляется при компиляции TypeScript и не создаёт runtime-связь между модулями. Код корзины может знать форму товара, но при этом не загружает сервисы, store или UI модуля product.

Как передавать зависимости между модулями

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

Рассмотрим упрощённый пример взаимодействия двух feature-модулей. При оформлении заказа модулю checkout необходимо рассчитать стоимость доставки, но сама логика расчёта принадлежит модулю delivery.

Для примера зафиксируем простой контракт: сервис получает сумму товаров и возвращает стоимость доставки.

Сначала вариант с прямым созданием зависимости:

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

Теперь CheckoutService получает сервис доставки снаружи, а не создаёт его самостоятельно. Такой подход называется внедрением зависимостей — Dependency Injection или DI.

В этом примере контракт принадлежит delivery и является частью его публичного API. В другом случае контракт может определяться потребителем: например, checkout может объявить минимальный интерфейс DeliveryCalculator, который реализует сервис доставки. Выбор зависит от того, кому по смыслу принадлежит контракт.

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

Где собираются зависимости?

Сервисы связываем в слое app. Здесь runtime-импорты нескольких фич допустимы: этот слой выбирает реализации и собирает из них приложение.

Для этого мы используем DI-контейнер.

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

В примерах контейнер доступен как di из @infra/di. Покажем простой API: register сохраняет готовый экземпляр, а get возвращает его по токену.

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

В app создаём сервис доставки и передаём его сервису оформления заказа.

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

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

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

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

Какую реализацию DI выбрать?

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

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

TSyringe — контейнер с внедрением через конструкторы и декораторами.
InversifyJS — позволяет связывать идентификаторы сервисов с реализациями и настраивать их создание.
Awilix — вариант без обязательных декораторов, с регистрацией классов, фабрик и готовых значений.
InferDI — контейнер с явной регистрацией сервисов и проверкой зависимостей на уровне типов TypeScript.

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

Жизненный цикл зависимостей тоже нужно определить. В клиентском приложении контейнер может существовать всё время работы приложения. При SSR сервисы с пользовательскими данными должны быть изолированы на запрос.

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

Где находятся пользовательские сценарии?

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

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

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

В учебном примере обойдёмся обычным useState. Предположим, что у CheckoutService есть метод placeOrder(input), который отправляет заказ и возвращает его идентификатор:

Компонент получает данные и функцию оформления заказа. Входные данные передаются при её вызове:

Где хранить состояние приложения?

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

Серверное состояние — товары, заказы, доступные способы доставки и другие данные с сервера. На клиенте хранится их копия, которая может устаревать. Для загрузки, кэширования и обновления можно использовать React Query, SWR или RTK Query.

Клиентское состояние — выбранные позиции корзины, черновик заказа и другие данные, которыми пользуются несколько компонентов. Для него подходят Zustand, Redux Toolkit или состояние общего родительского компонента, передаваемое через props либо Context.

Локальное состояние — раскрытый блок, значение поля или состояние операции, нужное только одному компоненту или хуку. Обычно достаточно встроенных useState и useReducer.

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

Как отделить логику от платформы?

До этого мы обсуждали зависимости между модулями приложения. Но у frontend-кода есть ещё один источник зависимостей — окружение, в котором он выполняется. Обращаясь к window, document, localStorage или браузерному SDK, мы неявно предполагаем, что код всегда будет работать в браузере и нужный API окажется доступен.

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

Под platform-agnosticподходом мы понимаем явное отделение логики приложения от таких платформенных возможностей. Это не означает, что React-компоненты автоматически смогут работать в любом runtime. Речь о том, чтобы зависимость от конкретного окружения была локализована и имела понятный контракт.

Доступ к платформенным API

В нашем приложении доступ к браузерным API сосредоточен в shared/platform. Например, вместо прямого обращения к localStorage используется функция, которая проверяет его доступность:

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

Если хранилище недоступно или сохранённого запроса нет, read() возвращает null. При записи обрабатываем возможную ошибку: например, превышение квоты. Поиск продолжает работать, даже если последний запрос не удалось сохранить.

Что остаётся зависимым от React?

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

Как проверить, что границы работают?

Архитектура полезна, если её правила можно проверить. В нашем случае ESLint ограничивает направление импортов, запрещает runtime cross-импорты между фичами и прямое обращение к браузерным глобальным объектам вне платформенного слоя. TypeScript проверяет соответствие реализаций контрактам, а тесты — их поведение. Правило no-restricted-globals само по себе не перекрывает все способы доступа, например globalThis.window: такие формы тоже нужно учитывать в конфигурации проверок.

Простой практический тест для DI — можно ли создать сервис без запуска приложения. В примере оформления заказа достаточно передать небольшой объект с методом calculate:

Тест не инициализирует React, не создаёт контейнер и не импортирует реализацию delivery. Мы проверяем именно правило checkout: доставка включается в итоговую сумму. Сам расчёт тарифа проверяется отдельно, внутри delivery. Дополнительный интеграционный тест должен проверять сборку контейнера: правильно ли зарегистрированы токены и удаётся ли получить готовый CheckoutService.

Цена такого подхода

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

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

Итоги

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

Это не универсальная схема и не набор обязательных папок.

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

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

Где HTTP/2 и HTTP/3 реально быстрее, а где не дают ничего

Mon, 14 Sep 2026 14:05:55 +0000

Про HTTP/2 и HTTP/3 написано столько, что вопрос кажется закрытым. Включаешь — и всё летает. Так, во всяком случае, рассказывают. Мультиплексирование убирает очередь из запросов, QUIC держится, когда пакеты теряются, рукопожатие укладывается в один круг вместо двух. Звучит складно. И, наверное, где-то так и есть.

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

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

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

❯ Что именно мы проверяем

HTTP/1.1 — это один запрос за раз в одном соединении. RFC 9113 прямо называет это причиной, по которой клиенты открывают к серверу сразу несколько соединений. Сколько именно — спецификация не фиксирует, браузеры сошлись на шести на хост. Не больше, не меньше.

HTTP/2 делает иначе: много запросов едут одновременно в одном TCP-соединении. Очередь на уровне HTTP исчезает. Но остаётся уровнем ниже — и это важно. TCP обязан отдать приложению байты строго по порядку. Поэтому, как только теряется сегмент, стек придерживает в приёмном буфере всё, что пришло после, и ждёт, пока потерянное не восстановят. Это и называют head-of-line blocking: встают все потоки соединения разом, даже те, чьи сегменты дошли целыми.

HTTP/3 переносит всё на QUIC поверх UDP. Порядок доставки гарантируется внутри каждого потока по отдельности — потерянный пакет блокирует только свой поток, соседей не трогает. Заодно QUIC складывает транспортное рукопожатие и TLS 1.3 в одну процедуру. Там, где TCP тратит круг на SYN и SYN-ACK, а TLS следом ещё один, QUIC укладывается в один.

Три обещания. Все три можно проверить измерением, а не верить слайдам.

❯ Стенд

Компонент	Что именно
Сервер	Caddy 2.11.4, один порт, протоколы `h1 h2 h3` одновременно
Клиент	curl 8.2.1-DEV: BoringSSL, nghttp2 1.52.0, quiche 0.18.0
ОС	Ubuntu 24.04, ядро 6.8.0
Сеть	loopback с MTU 1500, эмуляция `tc netem`, полоса 100 Мбит/с

Один и тот же бинарник curl обслуживает все три протокола — меняется только флаг. Это не мелочь. Сравнивать HTTP/2 из одной сборки с HTTP/3 из другой бессмысленно: разница между сборками перекроет разницу между протоколами, и вы будете измерять чужой код, а не транспорт.

Второй вопрос снимаю сразу — управление перегрузкой одинаково по обе стороны. В ядре net.ipv4.tcp_congestion_control = cubic, у quiche алгоритм по умолчанию тоже CUBIC. Значит, всё, что я увижу ниже, — это различия транспорта, а не выбора алгоритма.

И одна настройка, без которой замер вообще бессмыслен. QUIC работает поверх UDP, а стандартный приёмный буфер сокета его душит — Caddy при старте прямо жалуется в лог. Документация quic-go рекомендует поднять буфер до 7 МБ:

sudo sysctl -w net.core.rmem_max=7500000
sudo sysctl -w net.core.wmem_max=7500000

Если вам попадётся бенчмарк, где HTTP/3 проигрывает, первым делом спросите — поднимали ли там буфер. Обычно нет.

Профили сети. netem на loopback применяется к обоим направлениям, поэтому RTT равен удвоенной задержке — проверено замером времени TCP-рукопожатия. По той же причине удваиваются потери: в колонке «потери 1%» читайте «1% на каждое направление».

Сценарий	Настройка netem	Измеренный RTT
Дата-центр	Нет	0,15 мс
Проводной	`delay 20ms rate 100mbit`	40,16 мс
Другой континент	`delay 75ms rate 100mbit`	150,24 мс
Мобильный	`delay 30ms loss 1%`	60,22 мс
Плохой мобильный	`delay 30ms loss 3%`	60,25 мс
Край соты	`delay 50ms loss 5%`	100,42 мс

Четыре теста. Десять файлов по 8 КБ. Пятьдесят таких же. Один файл 3 МБ. И холодное соединение. HTTP/1.1 получает шесть параллельных соединений, HTTP/2 и HTTP/3 мультиплексируют потоки в одном — проверено счётчиком num_connects. Медиана из пяти прогонов, для крупного файла — из трёх, таймаут две минуты.

❯ Десять файлов: шесть окон перегрузки против одного

Сценарий	HTTP/1.1	HTTP/2	HTTP/3	Лучший	HTTP/3 к HTTP/2
Дата-центр, RTT 0	7 мс	9 мс	6	HTTP/3	-33%
Проводной, RTT 40 мс	170 мс	210 мс	146	HTTP/3	-30%
Другой континент, RTT 150 мс	615 мс	767 мс	519	HTTP/3	-32%
Мобильный, RTT 60 мс, потери 1%	255 мс	348 мс	214	HTTP/3	-39%
Плохой мобильный, RTT 60 мс, потери 3%	569 мс	368 мс	270	HTTP/3	-27%
Край соты, RTT 100 мс, потери 5%	846 мс	708 мс	466	HTTP/3	-34%

Десять файлов по 8 КБ. На каналах без потерь HTTP/2 отстаёт от HTTP/1.1

Первое, что бросается в глаза: на каналах без потерь HTTP/2 проигрывает HTTP/1.1. На проводном — 210 мс против 170, на межконтинентальном — 767 против 615. Ровно противоположно тому, что обещают слайды.

Объяснение простое, даже обидно простое. Браузер открывает шесть соединений, и десять файлов укладываются в два RTT. У каждого соединения своё окно перегрузки, все шесть проходят slow start параллельно — за тот же круг в сеть уходит вшестеро больше сегментов. А HTTP/2 кладёт всё в одно соединение и разгоняет одно-единственное окно. Мультиплексирование тут не отыгрывается: очереди из запросов и так нет.

HTTP/3 выигрывает у HTTP/2 стабильно — от 27 до 39 процентов. Я сначала списал это на рукопожатие, потом посчитал. На проводном канале отрыв 64 мс при экономии на рукопожатии 38, на межконтинентальном — 248 против 149. Рукопожатие объясняет от 41 до 60 процентов, остальное без объяснения. Скорее всего, начальное окно перегрузки у QUIC своё и разгоняется иначе — но чтобы утверждать это, нужна трассировка, а у меня её нет.

❯ Пятьдесят файлов: где мультиплексирование окупается

Сценарий	HTTP/1.1	HTTP/2	HTTP/3	Лушчий	HTTP/3 к HTTP/2
Дата-центр, RTT 0	14 мс	12 мс	15 мс	HTTP/2	+25%
Проводной, RTT 40 мс	461 мс	306 мс	227 мс	HTTP/3	-26%
Другой континент, RTT 150 мс	1,67 с	1,07 с	827 мс	HTTP/3	-23%
Мобильный, RTT 60 мс, потери 1%	805 мс	492 мс	355 мс	HTTP/3	-28%
Плохой мобильный, RTT 60 мс, потери 3%	1,12 с	1,16 мс	520 мс	HTTP/3	-55%
Край соты, RTT 100 мс, потери 5%	2,07 с	1,92 мс	1,12 с ⚠ 4/5	HTTP/3	-41%

Пятьдесят файлов по 8 КБ — здесь мультиплексирование наконец окупается

Картина переворачивается. Пятьдесят файлов на шести соединениях — это девять кругов, и HTTP/1.1 платит за каждый. На межконтинентальном канале 1,67 секунды против 827 миллисекунд у HTTP/3. Разница вдвое, и она видна невооружённым глазом.

И тут же главная оговорка. Посмотрите на первую строку: в дата-центре, где RTT практически ноль, все три протокола укладываются в 12–15 миллисекунд. Разница лежит в пределах шума. Мультиплексирование окупается только тогда, когда круговая задержка заметна. Нет задержки — нет выигрыша. Вот, собственно, и всё.

❯ Один поток на 3 МБ: упираемся в пропускную способность

Сценарий	HTTP/1.1	HTTP/2	HTTP/3	Лучший	HTTP/3 к HTTP/2
Дата-центр, RTT 0	5 мс	8 мс	22 мс	HTTP/1.1	+186%
Проводной, RTT 40 мс	631 мс	632 см	654 мс	HTTP/1.1	+4%
Другой континент, RTT 150 мс	1,62 с	1,62 с	2,10 с	HTTP/2	+30%
Мобильный, RTT 60 мс, потери 1%	4,59 с	1,22 с	6,66 с	HTTP/2	+446%
Плохой мобильный, RTT 60 мс, потери 3%	16,90 с	18,19 с	10,92 с	HTTP/3	-40%
Край соты, RTT 100 мс, потери 5%	32,10 с	40,31 с	19,42 с ⚠ 1/3	HTTP/3	-52%

Один файл 3 МБ, шкала логарифмическая. На проводном канале все три протокола показывают одно и то же

Строка «Проводной» — это квинтэссенция всей статьи. 631, 632 и 654 миллисекунды. Три протокола, разных на десять лет разработки, показывают одно и то же время. Потому что все трое упираются в пропускную способность. Узкое место лежит вне протокола.

Прикиньте порядок величин. При 100 Мбит/с и RTT 40 мс произведение полосы на задержку — около 500 КБ. Файл 3 МБ — это шесть таких окон, и заметная часть передачи уходит на разгон.

Строка «Дата-центр» интереснее. На идеальном локальном канале HTTP/1.1 отдаёт файл за 5 мс, HTTP/2 — за 8, HTTP/3 — за 22. Новые протоколы проигрывают старому вчетверо. Когда сеть перестаёт быть узким местом, им становится процессор: HTTP/2 тратит такты на фрейминг и сжатие заголовков HPACK, а у QUIC весь транспорт живёт в пространстве пользователя — каждая датаграмма проходит через системный вызов и шифрование, тогда как TCP-стек работает в ядре.

❯ Рукопожатие: экономия ровно в один RTT

Сценарий	HTTP/1.1	HTTP/2	HTTP/3	Лучший	HTTP/3 к HTTP/2
Дата-центр, RTT 0	1 мс	2 мс	2 мс	HTTP/1.1	-2%
Проводной, RTT 40 мс	122 мс	124 мс	86 мс	HTTP/3	-30%
Другой континент, RTT 150 мс	452 мс	452 мс	303 мс	HTTP/3	-33%
Мобильный, RTT 60 мс, потери 1%	182 мс	182 мс	123 мс	HTTP/3	-33%
Плохой мобильный, RTT 60 мс, потери 3%	182 мс	182 мс	125 мс ⚠ 3/5	HTTP/3	-32%
Край соты, RTT 100 мс, потери 5%	349 мс	303 мс	203 мс	HTTP/3	-33%

Гипотеза «QUIC экономит ровно один круг». Замеры ложатся на неё сами

Здесь HTTP/3 выигрывает предсказуемо: примерно на треть во всех сценариях с задержкой. TCP тратит круг на SYN и SYN-ACK, и только по установленному соединению идёт TLS 1.3, забирая ещё один. А у QUIC криптография едет прямо в первых пакетах транспорта — отдельного TLS-рукопожатия после установки соединения просто нет.

Арифметика сходится до миллисекунд. На межконтинентальном канале с RTT 150 мс: 452 мс у TCP против 303 у QUIC. Разница — 149 мс, ровно один круговой обмен.

Одна оговорка. В начале рукопожатия сервер не имеет права отправить на неподтверждённый адрес больше чем втрое от полученного объёма — RFC 9000 называет это anti-amplification limit. В этот лимит входит цепочка сертификатов. Если она объёмная, ответ не помещается, и рукопожатие съедает лишний круг. У меня сертификат локального центра сертификации маленький, поэтому экономия и легла точно в один RTT.

❯ Потери пакетов: откуда берётся разброс в разы

Девять прогонов файла 3 МБ подряд в одних и тех же условиях.

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

При потерях 1% худший прогон HTTP/1.1 хуже лучшего в 13,5 раза. У HTTP/2 — в 11,3. У HTTP/3 — только в 2,4. На чистом канале у всех троих разброс — единица.

Причина — в том, как TCP обнаруживает потерю. Если следом за потерянным сегментом пришли другие, отправитель видит дублирующие подтверждения и уходит в быструю повторную передачу: cubic срежет окно примерно на треть и поедет дальше. Именно на треть, а не вдвое — уполовинивание это поведение Reno, и разницу видно прямо в ядре:

$ cat /sys/module/tcp_cubic/parameters/beta 717

QUIC устроен иначе. Номера пакетов у него монотонно растут и не повторяются — повторная передача едет под новым номером. Исчезает та самая неоднозначность, из-за которой TCP не может понять, какому из двух одинаковых сегментов пришло подтверждение, и портит себе оценку RTT. Вместо таймаута повторной передачи работает probe timeout по RFC 9002.

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

❯ Пять процентов потерь: HTTP/3 встаёт намертво

Последний сценарий — RTT 100 мс и 5% потерь. Обычная жизнь на границе покрытия.

По медианам выходила красивая картинка: 32,1 секунды у HTTP/1.1, 40,3 у HTTP/2 и всего 19,4 у HTTP/3. Отличный финал для статьи. Потом я посмотрел, сколько прогонов вообще дошло до конца. У HTTP/3 — один из трёх.

Ни один прогон HTTP/1.1 и HTTP/2 не сорвался. Все обрывы у HTTP/3

За весь эксперимент таких набралось семь. И все семь — у HTTP/3. Отдельная серия с проверкой кода возврата показала CURLE_OPERATION_TIMEDOUT: не разрыв соединения и не ошибка QUIC, а обычный таймаут.

Дальше я снял трафик tshark'ом. И картина оказалась неожиданной. Зависание — это не медленная передача, а полная остановка:

run1  19,8 с  успех    пауз >300 мс: 0
run2 120,3 с  таймаут  одна пауза 108,4 с (встал на 11,6 с, отдав 1,77 МБ)
run4 120,2 с  таймаут  одна пауза 119,3 с (встал на 0,69 с, отдав 0,14 МБ)
run6  24,1 с  успех    пауз >300 мс: 0

Три зависания из шести устроены одинаково. Последний пакет перед тишиной — всегда от клиента, короткое подтверждение на 77 байт. После него сервер не присылает ничего, а клиент не отправляет ни одного зондирующего пакета, хотя RFC 9002 их предписывает. Обе стороны просто ждут друг друга — пока curl не закроет соединение по своему таймауту.

Точка срыва произвольная. Один раз — после 1,77 МБ. Два раза — после 0,15 МБ, на первой секунде. Версия про исчерпание окна на фиксированной границе отпала.

Назвать причину я не берусь. QUIC шифрует типы фреймов, и чтобы увидеть последний отправленный, нужен захват с ключами. Фиксирую то, что воспроизводится: связка curl 8.2.1-DEV с quiche 0.18.0 и Caddy на quic-go под потерями от 3% примерно в половине случаев встаёт намертво. Сборка клиента старая — на свежей стоит перепроверить.

❯ Три ловушки, в которые я попался

Все три раза ошибка выглядела как свойство протокола. И все три раза оказывалась свойством стенда.

MTU у loopback. Первый вариант стенда давал разброс в восемь раз между двумя запусками одной команды. Очередь netem была ни при чём — tc -s qdisc показывал dropped 0. Тогда я померил канал голым сокетом на Python, без всякого HTTP: чистый TCP выдал 34 МБ/с там, где curl еле выжимал 1 МБ/с. Тридцатикратный разрыв указывал на стенд. Причина — MTU интерфейса lo равен 65536, в сорок раз больше обычного Ethernet, и окно перегрузки, которое считается в сегментах, ведёт себя рвано. Лечится строчкой ip link set lo mtu 1500.

Медиана по уцелевшим прогонам. Те самые «19,4 секунды», посчитанные по одному успешному измерению из трёх. Формально не ложь: медиана успешных загрузок действительно такая. Просто читатель никогда бы не узнал, что каждая вторая попытка не заканчивается. Теперь генератор таблиц помечает такие клетки: 19,42 с ⚠ 1/3. Шесть символов — а смысл строки меняют.

Распределение потерь. Самую неприятную я нашёл, уже когда садился писать выводы. В захвате оказалось, что кадры QUIC на loopback доходят до 14 452 байт при MTU 1500: quic-go отдаёт ядру несколько пакетов одним системным вызовом. У TCP максимальный кадр — 2962 байта.

netem стоит до сегментации и роняет кадр целиком. Я решил, что это занижает HTTP/3, посчитал — оказалось, нет: доля потерянных пакетов совпадает, 124 против 125 из примерно 2500. Отличается распределение. Со склейкой потери приходят пачками — по два-одиннадцать подряд. Без склейки — поодиночке.

Я отключил склейку переменной QUIC_GO_DISABLE_GSO=true и перемерил всё заново.

Одна и та же доля потерь. Гладкие столбики — потери пачками, штрихованные — поодиночке

50 файлов	HTTP/1.1	HTTP/2	HTTP/3
Мобильный, потери 1%	805 → 756 мс	492 → 645 мс	355 → 715 мс
Плохой мобильный, 3%	1,1 → 1,1 с	1,2 → 1,0 с	520 → 854 мс
Край соты, 5%	2,1 → 1,7 с	1,9 → 3,9 с	1,1 → 2,5 с

При одной и той же доле потерь HTTP/3 вдвое медленнее, когда потери рассеяны. У HTTP/1.1 время почти не меняется. У HTTP/2 скачет без системы. Распределение бьёт в основном по QUIC — и это, в общем, логично: у него пятьдесят потоков восстанавливаются независимо, поэтому рассеянные потери задевают много потоков сразу, а пачка — один.

Возражение про процессор снимается контролем. Если бы дело было в лишних системных вызовах без склейки, это проявилось бы и на чистых каналах, а там ничего не изменилось — 461 против 455 мс, 306 против 308, 227 против 229.

Зависания HTTP/3, кстати, никуда не делись и во второй конфигурации. Сместились в другой сценарий, но остались. И по-прежнему только у HTTP/3.

❯ Что из этого следует

Ситуация	HTTP/2 против HTTP/1.1	HTTP/3 против HTTP/2
Сервер и клиент в одном дата-центре	ничего, иногда хуже	хуже
Один крупный файл, любой канал	ничего	ничего или хуже
Десяток мелких файлов	часто хуже	лучше на треть
Полсотни мелких файлов, заметный RTT	вдвое лучше	лучше на четверть
Мелкие файлы плюс потери	по-разному	зависит от распределения потерь
Установка соединения, заметный RTT	ничего	лучше на треть

Включать HTTP/2 и HTTP/3 стоит. Ни в одном реалистичном сценарии они не сделали заметно хуже — проигрыши вылезли только на loopback, где сеть вырождена. Но чуда не ждите там, где узкое место в другом. Если у вас один большой файл, медленная база или тяжёлый бэкенд — смена протокола не изменит ничего.

Больше всего выигрывают те, у кого много мелких ресурсов и далёкие пользователи. Если весь трафик приходит из соседнего дата-центра, эффект будет околонулевым.

HTTP/3 нужен как раз там, где есть потери: мобильный интернет, публичный Wi-Fi, дальние маршруты. На стабильном проводном канале его преимущество сводится к одному сэкономленному кругу на рукопожатии. И проверьте UDP-буфер: полстроки в sysctl отделяют работающий HTTP/3 от протокола, который у вас «почему-то медленный».

❯ Границы применимости

Замеры сделаны на эмулированной сети, и характер потерь у netem зависит от сегментации — совпадение с реальной сетью случайное. Клиент curl, а не браузер: нет разбора HTML, приоритизации, кеша и предзагрузки. Сервер один, реализации QUIC заметно отличаются. 0-RTT не проверял.

Всё это воспроизводится: конфиг Caddy на десять строк, шелл-скрипт и tc netem.

❯ Итог

Я шёл в эксперимент с ожиданием, что новые протоколы дают равномерный выигрыш — просто разного размера. Получилось не так.

Выигрыш оказался узким и адресным. HTTP/2 окупается ровно в одном сценарии — много мелких файлов при заметной задержке — и там действительно даёт вдвое. Во всех остальных он либо не меняет ничего, либо слегка проигрывает старому доброму HTTP/1.1 с его шестью соединениями. HTTP/3 добавляет сэкономленный круг на рукопожатии и более предсказуемое поведение под потерями, но под равномерными потерями сам оказывается вдвое медленнее, а при 5% в половине прогонов вставал намертво.

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

Отсюда единственный вывод, который я готов защищать: правдоподобный результат опаснее странного. Странный вы пойдёте проверять сами, а «19,4 секунды вместо 40» выглядят совершенно нормально — и проходят в публикацию, если не пересчитать прогоны из чистого занудства.

❯ Ссылки

RFC 9114 — HTTP/3
RFC 9000 — QUIC, в том числе anti-amplification limit
RFC 9002 — обнаружение потерь и управление перегрузкой в QUIC
RFC 9113 — HTTP/2 и причина, по которой HTTP/1.1 открывает несколько соединений
Документация quic-go по оптимизациям — размер UDP-буфера и переменная QUIC_GO_DISABLE_GSO
RIPE Labs: Navigating Network Measurements — почему сетевым измерениям нельзя верить по умолчанию

Может быть интересно:

Перейти ↩

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram‑канале ↩

Обновление элементов Справочника в 1С с асинхронным ответом

Mon, 14 Sep 2026 14:04:06 +0000

Аннотация

В этой статье рассмотрим получение Номенклатуры из базы данных SQL и последующую запись в систему 1С. После обработки сообщения системой 1С будет сформирован асинхронный ответ о статусе обработки и отправлен в систему источник.

Асинхронный ответ выгодно использовать, когда:

Нет необходимости оперативно обновлять информацию и получать статус об обновлении данных
Если есть риск недоступности системы приёмника (обслуживание или обновление базы 1С)
Требуется обновить большие объемы данных не вызывая повышенную нагрузку на сервера

Описание работы разрабатываемого решения:

Задание по расписанию (триггер) запускает обработку бизнес-процесса по получению записей из системы источника (MS SQL).
При выполнении бизнес-процесса происходит маппинг массива и отправка элемента Номенклатуры в 1С.
В обработчике 1С происходит создание/изменение Номенклатуры в Справочнике.
Формируется статус и помещается в регистр сведений "сшпОчередьИсходящихСообщений" с использованием документируемой функции сшпПоместитьВОчередьИсходящих.
Ответ попадает в Platform и маршрутизируется до MSSQL. При обработке статуса элементу в MSSQL всегда проставляется need_send = 0, чтобы успешные или ошибочные записи больше не попадали в обработку.

Настройки в Platform

1. Подготовительный этап:

Создаём тип данных habr_Номенклатура и импортируем в него структуру из Справочника “Номенклатура” из 1С. Назначение: Используется для обработки сообщения в обработчике 1С.

Создаём внешний тип данных habr_dbo_nomenklature и импортируем в него структуру таблицы “nomenklature” из базы MS SQL. Используем алиас (название), т.к. name зарезервированное слово. Назначение: Используется для получения Номенклатуры из Источника и обработки сообщения.

Создаём тип данных habr_Номенклатура_Ответ_1С, и заполняем его. Назначение: Используется для заполнения структуры ответа и маршрутизации.

2. Настройка обработчиков

Создаём обработчик habr_Номенклатура_Получение_MSSQL с типом “Обработчик MSSQL” для получения записей из системы источника (базы MSSQL).
- На вкладке Основное указываем направление “В Platform”.
- На вкладке Код указываем запрос:
```
SELECT TOP 100 uuid, sku, "name", units FROM nomenklature WHERE need_send = 1;
```
- На вкладке В Платформ указываем тип данных habr_dbo_nomenklature и указываем ему признак “Массив”, Операция - “Произвольный запрос”.

Создаём обработчик habr_Номенклатура_Обогощение_1С с типом “Обработчик 1С” для записи полученной номенклатуры в базу 1С.
- На вкладке Основное указываем направление “Из Platform”
- На вкладке Из Platform выбираем тип данных habr_Номенклатура
- На вкладке Код указываем следующее:

НачатьТранзакцию();
Попытка

    xdtoОбъект = сшпОбщегоНазначения.ПолучитьОбъектXDTO(Перечисления.сшпФорматыСообщений.JSON, ТелоСообщения());
    ИдентификаторMSSQL = Новый УникальныйИдентификатор(xdtoОбъект.UUID_MSSQL);
    
    Блокировка = Новый БлокировкаДанных;
    ЭлементБлокировки = Блокировка.Добавить("РегистрСведений.сшпБлокировкаОчереди");
    ЭлементБлокировки.УстановитьЗначение("Идентификатор", ИдентификаторMSSQL);
    
    Попытка
        Блокировка.Заблокировать();
    Исключение
        Пока ТранзакцияАктивна() Цикл
            ОтменитьТранзакцию();
        КонецЦикла;
        СостояниеСообщение = Перечисления.сшпСтатусыСообщений.ОжиданиеОбработки;
        Задержка = 30;
        Перейти ~Выход;
    КонецПопытки;

    //Поиск объекта
    спрСсылка = Справочники.Номенклатура.НайтиПоРеквизиту("UUID_MSSQL", ИдентификаторMSSQL);


    Если спрСсылка = Неопределено ИЛИ спрСсылка.Пустая() Тогда
            спрОбъект = Справочники.Номенклатура.СоздатьЭлемент();
    Иначе
            спрОбъект = спрСсылка.ПолучитьОбъект();
    КонецЕсли;
    
    спрОбъект.Наименование = xdtoОбъект.Наименование;
    спрОбъект.Артикул = xdtoОбъект.Артикул;
    спрОбъект.ЕдиницыИзмерения = xdtoОбъект.ЕдиницыИзмерения;
    спрОбъект.UUID_MSSQL = ИдентификаторMSSQL;
    спрОбъект.ДополнительныеСвойства.Вставить("СШПНеобрабатывать", Истина);
    спрОбъект.Записать();

    ОтветПоНоменклатуре = Новый Структура;
    ОтветПоНоменклатуре.Вставить("UUID_Source", ИдентификаторMSSQL);
    ОтветПоНоменклатуре.Вставить("updated_at", ТекущаяДатаСеанса());
    ОтветПоНоменклатуре.Вставить("status", "OK");
    СтруктОтв = сшпОбщегоНазначения.ПреобразоватьСтруктуруПоФормату(Перечисления.сшпФорматыСообщений.JSON, ОтветПоНоменклатуре);
    сшпПользовательскиеМетоды.ПоместитьВОчередьИсходящих("Номенклатура_ОбработкаОтвета",СтруктОтв);


    Пока ТранзакцияАктивна() Цикл
        ЗафиксироватьТранзакцию();
    КонецЦикла;

Исключение
    Пока ТранзакцияАктивна() Цикл
        ОтменитьТранзакцию();
    КонецЦикла;

    ОтветПоНоменклатуре = Новый Структура;
    ОтветПоНоменклатуре.Вставить("UUID_Source", ИдентификаторMSSQL);
    ОтветПоНоменклатуре.Вставить("updated_at", ТекущаяДатаСеанса());
    ОтветПоНоменклатуре.Вставить("status", "Error. " + ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
    СтруктОтв = сшпОбщегоНазначения.ПреобразоватьСтруктуруПоФормату(Перечисления.сшпФорматыСообщений.JSON, ОтветПоНоменклатуре);
    сшпПользовательскиеМетоды.ПоместитьВОчередьИсходящих("Номенклатура_ОбработкаОтвета",СтруктОтв);

КонецПопытки;
~Выход:

Создаём “прокси” обработчик habr_Номенклатура_ОбработкаОтвета_1C с типом “Обработчик 1С”, который будет получать сформированный ответ из 1С
- На вкладке Основное выбираем направление “В Platform” и указываем имя таблицы Номенклатура_ОбработкаОтвета. С этим типом объекта мы поместили ответ в регистр сведений очередь исходящих на стороне 1С.
- На вкладке В Platform выбираем тип данных habr_Номенклатура_Ответ_1С
- На вкладке Код указываем следующее:

РезультатОбработки.Body = ОбъектОбработки;

Создаём обработчик habr_Номенклатура_ОбновлениеСтатуса_MSSQL с типом “Обработчик MSSQL”, который будет производить обновление статуса в базе MSSQL.
- На вкладке Основное указываем направление “Из Платформ”
- На вкладке Из Platform указываем тип данных habr_ОбработкаОтвета_1С
- На вкладке Код указываем запрос по обновлению записи. Подстановка переменных происходит из типа данных. Например @ИмяПоляВТипеДанных.

UPDATE dbo.nomenklature
SET
need_send = 0,
updated_at = @updated_at,
status = @status
WHERE
uuid = @UUID_Source;

3. Настройка бизнес процессов

Создаём бизнес-процесс habr_Номенклатура_Обновление_БП, который производит получение и обновление номенклатуры В 1С.
- На вкладке Основное снимаем галочку “Запускать автоматически”
- На вкладке Переменные устанавливаем следующее:
  - Получаемый массив Номенклатуры
  - Итератор используется для обхода элементов массива
  - Общее количество элементов - определяет количество элементов в массиве и вычисляется единожды.
  - Номенклатура 1С - тип данных отправляемый в 1С.

Подробное описание настроек в бизнес-процессе:

Процесс будет обходит элементы массива, формируя сообщения для отправки в 1С.

1.Выбираем шаг “Источник” и заполняем его, для получения Номенклатуры из MSSQL.

2. Устанавливаем шаг “Алгоритм” в нём указываем следующее:

ОбщееКоличествоЭлем = ПолученнаяНоменклатура_MSSQL.Count;
Logger.Debug($"ОбщееКоличество записей к обработке: {ОбщееКоличествоЭлем}");

3. Устанавливаем шаг “Условие”, ведём от (+) к шагу маппинг. На соединительной линии указываем условие:

Итератор < ОбщееКоличествоЭлем

4. В шаге “Алгоритм” производим маппинг Элемента массива с типом данных для обработки в 1С. (Можно воспользоваться шагом установка переменных, кому как удобнее).

Номенклатура_1C.Наименование = ПолученнаяНоменклатура_MSSQL[Итератор].название;
Номенклатура_1C.Артикул = (int)ПолученнаяНоменклатура_MSSQL[Итератор].sku;
Номенклатура_1C.ЕдиницыИзмерения = ПолученнаяНоменклатура_MSSQL[Итератор].units;
Номенклатура_1C.UUID_MSSQL = ПолученнаяНоменклатура_MSSQL[Итератор].uuid;

Logger.Debug($"ЭлементНоменклатуры = {Номенклатура_1C}");

5. Выбираем шаг “Отправка получателю” и заполняем его

6. Выбираем шаг “Алгоритм” и к переменной Итератор добавляем единицу.

Итератор++;

Создаём бизнес-процесс habr_Номенклатура_ОбработкаОтвета_1С_БП , который производит запись ответа в MSSQL.
- На вкладке Основное указываем “Запускать автоматически”
- На вкладке Переменные в переменной обработки указываем тип данных ответа habr_Номенклатура_Ответ_1С (синоним habr_ОбработкаОтвета_1С).
- Заполняем получателя и выбираем обработчик по обновлению статуса.

4. Создание задания по расписанию (триггера)

Создаём триггер, устанавливаем ему время запуска и указываем схему обработки habr_Номенклатура_Обновление_БП, которую необходимо периодически запускать.

Результат работы:

Устанавливаем статус need_send = 1 в таблице Номенклатура в MSSQL.

В случае корректной обработки в базе MSSQL видим статус ОК.

Записи из MSSQL добавлены в справочник на стороне 1С:

В случае ошибки атрибут need_send становится равным нулю, повторная обработка ошибочных сообщений не происходит. В поле status описана ошибка, например: Деление на 0

В этом кейсе рассмотрена простая настройка для одного потока, если планируется обновление большого количества объектов, то можно подумать в сторону:

Формирования универсальной структуры ответа
Единого формата обработчиков по обновлению Статуса в СУБД
Универсальных бизнес-процессов по обработке данных

Используемое ПО

Microsoft SQL Server 2019 (MS SQL)
DATAREON Platform 3.2.1.1
Информационная база 1С (Платформа 1С 8.3.23.2157), в режиме совместимости 8.3.22

Файл скрипта базы MSSQL и выгрузка конфигурации Platform, доступны по ссылке.

Документация

Зарезервированные имена — документация Datareon Platform - использование зарезервированных системных слов используя алиасы.
Обработчики 1С — документация Datareon Platform - помещение в очередь исходящих.
Обработчики СУБД — документация Datareon Platform - работа с переменными в обработчиках с типом СУБД

SKILL.state в coding-агентах: меньше истории, но не всегда меньше работы

Rexarrior — Mon, 14 Sep 2026 14:00:08 +0000

О чём этот текст

Это рассказ о моём эксперименте: что захотелось попробовать, что получилось и где пришлось пересмотреть свои ожидания. Я не ставлю здесь задачу кого-то обучить или доказать, как правильно устраивать память агентов. Просто захотелось поделиться этим опытом — вместе с результатами, ошибками и вопросами, на которые у меня пока нет ответа.

С чего всё началось

Недавно мне попалась статья SKILL.state: Scalable Long-Horizon Agent Skills, и её идея меня зацепила: что, если агенту не нужна вся история работы и размышлений, чтобы выбрать следующее действие? Вместо неё можно хранить явное состояние выполнения и собирать очередной запрос вокруг него.

Раньше я работал с похожей архитектурой: смесью машины состояний и LLM workflow, где отдельные узлы — полноценные агенты со своим циклом работы, agent loop. Но каждый из них решал довольно узкий класс задач. Перенести тот же принцип на агента, который самостоятельно пишет код, мне тогда не приходило в голову. Поэтому захотелось попробовать идею «во плоти».

Итак, я решил перенести общую идею SKILL.state на задачи самостоятельной разработки программных проектов. В качестве основы взял два опенсорсных coding-агента — OpenCode и Codex: хотелось посмотреть, насколько результат зависит от устройства самого агента. Мне было интересно, как такая память поведёт себя внутри привычного рабочего цикла: агент получает спецификацию, создаёт файлы, запускает проверки, исправляет ошибки и решает, когда работа закончена. Сразу оговорюсь: это не повторение авторских экспериментов, а попытка применить их концепцию в другом окружении.

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

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

Что предложили авторы оригинальной статьи

SKILL.state предлагает организовать работу агента так, чтобы контекст не разрастался с каждым шагом. Авторы рассматривают длительные задачи, в которых агент рассуждает, вызывает инструменты и взаимодействует со средой — проще говоря, делает работу. Разработка ПО упоминается как одна из областей применения, но сама архитектура не привязана к coding-агентам. Постановка задачи в статье.

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

P неизменная постановка задачи
Σₙ текущее структурированное состояние
Oₙ последнее наблюдение среды

В ответ модель должна вернуть изменение состояния — patch — и следующее действие. Исполняющая часть агента, то есть runtime, проверяет и применяет этот patch, выполняет действие и возвращает наблюдение среды. На следующем шаге предыдущие рассуждения и старые ответы инструментов в запрос уже не попадают: если что-то из них пригодится позже, модель должна сама сохранить это в состоянии.

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

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

Экспериментальная часть оригинальной статьи охватывает несколько разных сред. В ней есть синтетический склад, симуляция репозитория с ветками, PR и статусами CI, терминальные задачи InterCode CTF и обслуживание клиентов в τ-Bench. Симуляция репозитория проверяет управление связанным состоянием, а CTF — поиск флагов через команды и проверку гипотез. Это смежные с разработкой сценарии, но всё-таки не то же самое, что самостоятельное создание приложения по спецификации. Описание бенчмарков.

У авторов в синтетическом эксперименте с управлением складом на горизонте 200 шагов получилось примерно 122 тысячи токенов у SKILL.state против 2,61 млн у ReAct (таблица 1). Разница впечатляет, но переносить её на агента, который пишет код, заранее было бы слишком смело. Захотелось посмотреть, сколько от этой экономии останется на наших задачах и сможет ли агент с такой памятью довести разработку до конца.

Как я проверял идею

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

В ядровой реализации задача и состояние сразу включены в запрос: модели не нужно отдельно читать файл памяти. История при этом никуда не исчезает из журналов — она нужна для разбора запусков, — но обратно модели в state-режимах не отправляется. Рабочая папка тоже сохраняется, так что созданные файлы агент может перечитать обычными инструментами. Если интересно посмотреть код, начать можно со сборщика состояния OpenCode или ядра состояния Codex.

Ранние пробы, в том числе с GLM-5.2 и Luna, остались в общем журнале. Для статьи я начал с отдельного сравнения на OpenCode и Codex, а затем продолжил эксперименты на Codex: добавил повторы, убрал глобальные скиллы и проверил расширенные лимиты памяти. В итоге получилось несколько серий. Ниже сначала опишу, что у них общего, а затем — чем они различаются.

Для эксперимента я взял пять небольших проектов:

CLI-менеджер задач с сохранением данных в JSON;
утилиту анализа CSV;
небольшой шаблонизатор;
HTTP key-value сервис;
планировщик зависимостей.

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

В сумме получается 40 проверок на пять проектов. Это важно не путать с 40 независимыми задачами: например, одна ошибка сохранения базы может потянуть за собой несколько проваленных проверок. Полный балл означает, что проект прошёл наши тесты. Ошибки за их пределами вполне могли остаться. Да и качество кода в широком смысле мы здесь не оцениваем: проверяем, делает ли программа то, что от неё требуется.

В основных сериях сравниваются четыре режима; в конце к ним добавился ещё один контроль — Paper2. V2/V3 и Paper2 — рабочие названия моих вариантов, они не имеют отношения к названиям версий оригинальной статьи:

Режим	Что модель видит из прошлой работы	Что предлагает за обращение
Native	Штатную историю агента	Штатные tool calls / Code Mode
Paper	Текущее Σ и последний результат O	Patch и одно действие
Paper2	Текущее Σ и одно O: действие, его аргументы, статус и результат	Patch и одно действие, как у Paper
V2	Текущее Σ и три структурированных наблюдения	Patch, необязательный comment и одно действие
V3	Текущее Σ и три наблюдения-батча	Patch, необязательный comment и последовательный массив действий

Детальное описание проведенных экспериментов

Подробнее об экспериментах и условиях запуска

Вот полный состав экспериментов, результаты которых вошли в статью. В каждой серии использовались все пять проектов; везде сравнивались четыре режима, кроме первого дополнительного круга V2/V3 и двух последних серий Paper2.

Серия	Агент и модели	Попыток на проект и режим	Запусков
Первое сравнение	OpenCode и Codex, Sol и Terra	1	80
Первые дополнительные повторы V2/V3	Codex, Sol и Terra	Ещё 2, только V2 и V3	40
Расширенная серия повторов	Codex, Sol	10	200
Без глобальных скиллов, прежние лимиты	Codex, Sol	5	100
Без глобальных скиллов, прежние лимиты	Codex, Astra	5	100
Без глобальных скиллов, лимиты до 2 МиБ	Codex, Astra	5	100
Без глобальных скиллов, лимиты до 2 МиБ	Codex, Sol	5	100
Paper2, без глобальных скиллов, лимиты до 2 МиБ	Codex, Sol и Astra	5, только Paper2	50
Paper2, без глобальных скиллов, малые лимиты и защита JSON	Codex, Sol и Astra	5, только Paper2	50
Итого			820

Каждая попытка решить один проект — отдельный запуск; всего в статье их 820. Например, пять повторов пяти проектов в четырёх режимах дают 100 запусков. Первые две строки таблицы — основная серия из 120 запусков: для Codex V2/V3 в ней по три попытки с учётом первого сравнения, для остальных сочетаний — по одной. Последующие серии добавляют ещё 700 запусков. Во всех них задачи остаются теми же: повторов много, но разных спецификаций по-прежнему пять. Отдельно учтены пять технически прерванных попыток первого запуска Paper2: они не входят ни в эти 820 итоговых исходов, ни в показанный расход. Ниже поясню, почему серию пришлось возобновить.

Исходники и настройки фиксировались перед сериями. Результаты дальше показаны по отдельности, чтобы было видно, при каких условиях они получены; общей средней по всем версиям здесь нет.

Режим Paper я задумывал как реализацию архитектуры статьи, но при встраивании в ядра агентов пришлось отступить от некоторых деталей. Поэтому буквальной копией авторского окружения он не стал. Чтобы сохранить штатные инструменты агентов, вместо JSON-блока с командой-строкой здесь используется вызов skill_step с типизированным действием. Схема состояния тоже своя, общая для всех пяти задач: например, в авторской CTF-схеме есть отдельное поле cmd_summary, которого у нас нет. В первых сериях на состояние отведено 32 KiB, на отдельный результат — 4 KiB. Позже я проверил вариант с расширенными лимитами — до него ещё дойдём, — но влияние каждого ограничения и самой схемы по отдельности пока не проверял. Это существенная оговорка: не каждую проблему нашей адаптации можно приписать самой идее SKILL.state. Первый аудит соответствия описывает реализацию и условия основной серии из 120 запусков. Я сохранил его как исторический документ, а поздние изменения лимитов, изоляции и сохранения состояния разобрал в дополнении к аудиту.

В первом сравнении и дополнительных повторах V2/V3 участвовали Sol и Terra; дальше — Sol и Astra. Во всех сериях на одну попытку решения проекта отводилось 15 минут. Внутри каждого сравнения модель и общие ресурсные ограничения оставались неизменными: у Codex был выбран medium reasoning, у OpenCode — temperature 0 и предел 80 шагов. Число обращений восстановлено по завершённым шагам OpenCode и записям расхода токенов Codex; отдельные сетевые повторы в этот счётчик не входят. При таких различиях настроек я сравниваю варианты внутри каждого агента, а не абсолютный расход OpenCode с расходом Codex. В последующих сериях Codex сохранились medium reasoning и окно k=3 у V2/V3; Paper по-прежнему получал только последнее наблюдение. Выводов о переносимости на другие семейства моделей эти опыты не дают.

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

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

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

Чтобы не оставлять эту оговорку просто оговоркой, для чистоты эксперимента я сделал ещё одну серию на Sol: временно убрал глобальные скиллы и инструкции, а после запусков вернул их на место. За время экспериментирования успела появиться Astra, поэтому бонусом прогнал те же задачи и на ней. Это две серии по 100 запусков из таблицы выше. Бинарник Codex, спецификации и оценщик сохранились; одновременно работало до пяти основных CLI-процессов. Во всех 200 сессиях проверка начальных сообщений уже не нашла маркеров каталога скиллов и глобального профиля. Это ещё не полная изоляция на уровне ОС, но конкретную примесь из прошлых запусков мы убрали.

У Astra случился технический перерыв после 35 запусков: защитная проверка остановила серию из-за повторного появления служебного кэша, загрузка которого была отключена. Разобравшись с загрузчиком, я поправил проверку и запустил оставшиеся 65 задач, не заменяя и не повторяя уже выполненные. Условия обеих серий и поправка к запуску сохранены отдельно. Новые результаты ниже тоже идут отдельными блоками: сравнивать их со старой Sol и приписывать всю разницу удалению скиллов было бы некорректно — менялись время, нагрузка и, конечно, сам ход решения при каждом запуске.

Следующие две серии — ещё по 100 запусков Astra и Sol — проверяют расширенные лимиты SKILL.state. Я поднял четыре лимита до 2 МиБ каждый: на полное состояние, принимаемые аргументы действия, их сохранённую копию и результат. Заодно исправил повторную обрезку JSON при сохранении истории. Обе модели использовали одну и ту же новую сборку; временное удаление скиллов, остальные настройки и параллельность сохранились. Native в этих сериях тоже запускался заново, чтобы у каждой было своё сравнение со штатным агентом. Подробности изменений и результаты разберу ниже.

Наконец, при повторном аудите возник вопрос к составу самого наблюдения O. Так появился Paper2: по 50 запусков с большими и малыми лимитами. В малой конфигурации я сохранил исправление JSON, поэтому это уже не возврат к старой сборке со всеми её особенностями. Эти серии сравниваю прежде всего между собой, а с Native и Paper — по ранее полученным результатам, без новых одновременных контролей.

Проверка реализации перед сравнением

Подробнее о найденных ошибках и исправлениях

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

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

Завершение без обязательного finish

В моей реализации Codex мог закончить работу обычным текстовым ответом, так и не вызвав обязательное действие finish. Это проявилось, например, в раннем запуске CLI-проекта на Sol/V2: код прошёл 8/8 проверок, но предусмотренного протоколом завершения в журнале не было. Баллы за работающий код у него заслуженные, а вот считать весь запуск полностью успешным нельзя: мы не знаем, сколько ещё обращений понадобилось бы модели, если бы ядро потребовало завершить работу правильно.

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

Успешный вызов инструмента — не обязательно успешная команда

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

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

Потерянное подтверждение apply_patch

Ещё одна проблема обнаружилась уже при первом диагностическом запуске Paper на Codex. Адаптер брал у apply_patch возврат для Code Mode — пустой объект {} — вместо текстового подтверждения изменения файлов. То есть файлы могли уже измениться, а модель не получала сообщения об этом. В журнале были видны повторные попытки создать те же файлы, но делать из этого выводы о SKILL.state было бы странно: обратную связь с инструментом терял наш собственный код.

Я поправил выбор результата: для инструментов, не относящихся к оболочке, теперь сохраняется текстовый вывод, а для команд оболочки — структурированные сведения о коде завершения и сессии процесса. Чтобы ошибка не вернулась, добавил регрессионный тест на реальных типах результатов инструментов. Эту диагностическую серию пришлось исключить целиком и начать сравнение Codex заново, включая Native. Исходный журнал остался для разбора ошибки, но даже удачные запуски из него в новую серию не попали.

Схема разрешала patch, который валидатор отвергал

В Paper была и менее заметная несогласованность: JSON Schema разрешала модели передавать null для обязательных полей верхнего уровня. При применении patch это означало удаление поля, и уже проверка полного состояния отвергала результат. Получалось, что модель могла добросовестно следовать предложенному формату и всё равно получать ошибку, а затем тратить обращения на исправление patch вместо самой задачи.

Я согласовал схему ответа и инструкции с тем, что принимает ядро. Обязательные контейнеры теперь нужно сохранять, но их содержимое по-прежнему можно очищать: массив заменить на [], а отдельную запись словаря files удалить через null. Сам принцип не изменился — модель предлагает patch, а runtime проверяет получившееся состояние до выполнения действия.

Неполный учёт входных токенов OpenCode

Наконец, пришлось разобраться в том, что именно означают счётчики токенов. Старые отчёты OpenCode складывали input + cache.read, хотя внутренний input уже не содержит ни чтения из кэша, ни записи в него. Мы теряли cache write, а вместе с ним могли неверно оценить и процент экономии, и соотношение вариантов. Поэтому для статьи полный вход восстановлен как input + cache.read + cache.write. У Codex устроено иначе: cached input уже входит в общий input, и прибавлять его повторно было бы ошибкой.

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

Так что ранние эксперименты были полезны: без них часть этих проблем легко могла остаться незамеченной. Но для основного сравнения текущих вариантов я использую отдельную серию из 120 запусков. В ней обычные таймауты, ошибки написанного кода и невалидные ответы модели остаются результатами эксперимента — они не заменяются удачными попытками. Подробности проверок реализации и правила исключения диагностических запусков вынесены отдельно. Описанные выше различия схем, инструментов и стартового контекста при этом никуда не делись; аудит исправил конкретные ошибки, но не сделал сравнение идеально изолированным.

Paper и Native: первое сравнение

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

Справа — число обращений к модели на ту же задачу. Шагом или циклом на этих рисунках я называю обращение, на которое зарегистрирован ответ основной модели, а не отдельное действие: V3 может выдать несколько действий сразу, да и обычный вызов shell может содержать несколько команд. Такой счётчик помогает понять, сколько раз агенту пришлось возвращаться к модели, и косвенно судить о времени работы. Конечно, оно зависит ещё от длины генерации, работы инструментов, ожиданий и нагрузки. В разделе повторов покажу время отдельно.

Paper против Native: input слева и обращения к модели справа, по каждой задаче

В большинстве этих запусков Paper израсходовал больше входных токенов, чем Native, хотя есть и обратные примеры. Эти результаты подсказали, что стоит внимательнее посмотреть на состав наблюдения. Расскажу, что попробовал изменить в протоколе.

V2: расширим память о совершённых действиях

В одном из ранних запусков Terra 74 раза повторила python3 -m py_compile main.py. Когда команда успешно завершалась без вывода, агент получал наблюдение, из которого нельзя было понять, что именно только что произошло. По одному журналу причину зацикливания не установить, но он подсказал, куда стоит посмотреть: хватает ли модели информации в нашем O?

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

Я заменил результат без контекста на запись примерно такого вида:

{
  "action": {"name": "bash", "input": {"command": "bun test"}},
  "comment": "Проверить поведение после изменения парсера",
  "status": "completed",
  "result": "12 tests passed"
}

По полям action, input, status и result видно, что агент сделал и что получил в ответ. А в comment модель объясняет, зачем ей это действие. Так между шагами сохраняется не только сама команда, но и её замысел. Важно лишь не путать комментарий с результатом: написать «проверить, что тесты проходят» — ещё не значит получить успешную проверку.

А вот следующий шаг уже меняет саму схему памяти: вместо одного наблюдения в следующий запрос я включил три последние записи — O[n−2], O[n−1], O[n]. Если сведения понадобятся и за пределами этого окна, модель должна сама перенести их в факты, решения или описание выполненной работы. Отдельное поле verification из ранней адаптации я при этом убрал, чтобы не заводить параллельный журнал проверок: недавние результаты и так видны в наблюдениях, а важные выводы можно сохранить в состоянии.

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

V2 против Native: input слева и обращения к модели справа, по каждой задаче

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

V3: несколько действий между обращениями к модели

К этому моменту стало хорошо заметно, что короткий контекст может потребовать от модели больше циклов для выполнения задачи: особенно наглядно это проявилось у Paper. Это не обязательное свойство любого state-агента — у V2 позднее получилось и меньше обращений, чем у Native, — но сама возможность потерять экономию на лишних возвращениях к модели меня беспокоила.

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

Одиночное действие превратилось в массив actions:

{
  "state_revision": 7,
  "state_patch": {"next_action": "Посмотреть результаты тестов"},
  "comment": "Создать известные файлы и запустить проверку",
  "actions": [
    {"name": "apply_patch", "input": {"patchText": "..."}},
    {"name": "bash", "input": {"command": "bun test"}}
  ]
}

Пример условный — у OpenCode и Codex различаются имена инструментов и их аргументы, — но общая механика такая: ядро проверяет структуру батча, состояние, имена действий и базовые типы аргументов, один раз применяет patch, а затем выполняет действия по очереди. При этом не все параметры проверяются заранее: часть проверок происходит уже внутри конкретного инструмента. Если действие завершается ошибкой, оставшиеся получают skipped; завершить работу через finish можно только отдельным вызовом, без других действий в батче.

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

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

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

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

V3 против Native: input и обращения к модели по каждой задаче

Сравнение с Native показывает результат всей модификации. Чтобы увидеть, что изменилось относительно V2, посмотрим на те же запуски, оставив на графике только эту пару:

V3 против V2: input и обращения к модели по каждой задаче основной попытки

На одних задачах V3 оказалась экономнее V2, на других — затратнее. Но здесь пока только по одной попытке. Повторы Codex заметно изменили первое впечатление; ниже покажу и первый круг из трёх попыток, и последующие десять повторов на Sol.

Повторы Codex

Первый круг: три попытки V2/V3

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

Модель	Попытка	V2: input	V2: обращения	V3: input	V3: обращения	V3 к V2: input
Sol	1	1,397 (40/40)	77	1,280 (40/40)	67	−8,4%
Sol	2	1,273 (40/40)	72	1,068 (39/40)	56	−16,1%
Sol	3	1,065 (40/40)	61	1,539 (40/40)	81	+44,5%
Terra	1	1,000 (39/40)	58	1,092 (39/40)	62	+9,2%
Terra	2	1,696 (40/40)	96	1,476 (39/40)	81	−12,9%
Terra	3	1,039 (39/40)	60	1,338 (39/40)	75	+28,8%

Это по-прежнему те же пять задач, выполненные по три раза. У Native, Paper и всех вариантов OpenCode в этой первоначальной серии остаётся по одной попытке.

И вот здесь первоначальное впечатление от V3 меняется. На Sol она снизила основной input в двух попытках из трёх, на Terra — в одной, но в сумме по всем трём попыткам потребовала больше входных токенов: на 4,0% и 4,6% соответственно. По проверкам тоже небольшое отставание: у Sol получилось 119/120 против 120/120 у V2, у Terra — 117/120 против 118/120. Этого мало для уверенного статистического сравнения качества, но достаточно, чтобы не объявлять V3 устойчивым улучшением по одному удачному запуску.

С числом циклов ожидание тоже оправдалось слабо: на Sol получилось 204 обращения у V3 против 210 у V2, то есть сокращение всего на 2,9%. На Terra сокращения вообще не было — 218 против 214. Контринтуитивно, по крайней мере для меня: возможность сделать больше действий за раз не обязательно означает меньше возвращений к модели за всю задачу.

Ещё десять повторов Sol: теперь все четыре варианта

Чтобы посмотреть на разброс внимательнее, я сделал ещё по десять полных повторов пяти задач на Codex/Sol для каждого режима — 200 новых сессий. Ни таймауты, ни неудачные решения успешными попытками не заменялись.

Режим	Input, млн	К Native	Обращения	Полный успех*	Таймауты
Native	19,488	—	632	49/50	0
Paper	32,319	+65,8%	2005	30/50	18
V2	9,795	−49,7%	556	48/50	0
V3	13,069	−32,9%	691	47/50	1

*Полный успех здесь — все внешние проверки плюс штатное завершение без таймаута. У Native проверяется turn.completed, у state — принятый finish.

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

Исходные оценки я сохранил. По прежнему оценщику полный успех составлял 46/50, 29/50, 46/50 и 47/50, а баллы проверок — 396/400, 385/400, 396/400 и 398/400, в том же порядке, что в таблице. После поправки баллы — 399/400, 386/400, 398/400 и 398/400. Обе версии оценок и все повторы сохранены вместе с объяснением исправления.

Десять повторов Codex/Sol: средний input, число обращений и фактическое время на задачу

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

Результат V2 меня вполне устраивает: почти вдвое меньше основного input, ни одного таймаута и почти столько же полностью успешных решений. Разницу 49/50 против 48/50 я не стал бы выдавать за установленное превосходство по качеству — для этого здесь слишком мало разных задач. Но как инженерный результат V2 выглядит интересно.

С V3 история оказалась ещё менее интуитивной, чем в первых трёх попытках. Основной input вырос на 33,4% относительно V2, а число обращений вместо ожидаемого сокращения увеличилось с 556 до 691 — на 24,3%. После поправки к оценщику обе версии оставили по 48 проектов, прошедших все проверки, но один V3-запуск не завершился в срок. То есть в этой серии батчинг не дал того выигрыша, ради которого я его добавлял. Правда, вместе с ним поменялось и окно наблюдений — их влияние ещё нужно разделить.

Paper отправляла короткие запросы, но делала это слишком часто: 2005 обращений против 632 у Native съели всю экономию. В 14 из 18 сессий с таймаутами код при этом прошёл все проверки. Особенно выделилась задача про HTTP-сервис — девять таймаутов из десяти запусков, восемь из них с рабочим кодом. Похоже, в этой версии агента модели было сложно понять, что пора остановиться: программа уже работает, а разработка всё продолжается.

Подробнее — в полном отчёте.

Sol без глобальных скиллов: V2 всё ещё мне нравится

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

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	6,710	—	295	25/25	0
Paper	12,191	+81,7%	842	8/25	17
V2	4,631	−31,0%	288	24/25	1
V3	5,250	−21,8%	309	24/25	1

Пять повторов Codex/Sol без глобальных скиллов: input, циклы и наблюдаемое время на задачу

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

V2 снова экономит — теперь 31% основного input относительно Native, при почти одинаковом числе обращений. Все 25 проектов прошли проверки, но одна сессия не успела закончиться, поэтому полного успеха здесь 24/25. Меня этот результат всё ещё устраивает, хотя выдавать его за улучшение без оговорок я бы не стал. V3 снова оказалась дороже V2, на 13,4%, и циклов сделала больше, а не меньше. Paper по-прежнему часто не доходит до завершения.

Изменившиеся проценты сами по себе не доказывают влияние скиллов: это другая серия, к тому же вдвое короче предыдущей. Исправленную проверку удаления я одинаково применил ко всем новым CLI-проектам обеих моделей; в этот раз она не изменила ни одного исходного балла. Отчёт Sol с проверками, повторами и исходными счётчиками.

Astra — сначала Native оказался лучше

А вот с Astra всё получилось совсем иначе. Лимиты памяти в state-режимах пока оставались прежними, и Native оказался заметно лучше всех моих вариантов: меньше входных токенов, меньше обращений и ни одного таймаута.

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	2,612	—	136	25/25	0
Paper	27,355	+947,2%	1845	0/25	25
V2	10,871	+316,1%	639	22/25	3
V3	9,627	+268,5%	548	22/25	3

Пять повторов Codex/Astra без глобальных скиллов: input, циклы и наблюдаемое время на задачу

В среднем Native понадобилось всего 5,44 обращения на проект; V2 — 25,56, V3 — 21,92. При этом отдельный запрос Native в среднем содержал даже больше входных токенов, чем запрос каждого state-режима: выигрыш дало небольшое число обращений. V3 здесь немного отыгралась относительно V2, но до Native обоим вариантам всё равно далеко.

Особенно обидно выглядит Paper: 24 из 25 проектов прошли все проверки, но ни одна сессия не завершилась в срок. Поэтому «Astra не смогла написать код» было бы неверным описанием происходящего. В разобранных сессиях модель часто уже написала работающий проект, а потом продолжала его перечитывать и проверять. Обрезка наблюдений в нашей реализации могла этому способствовать. И это оказалось достаточно заметным, чтобы не ограничиваться оговоркой, а сделать ещё один эксперимент. Отчёт Astra и разбор нескольких траекторий.

Кажется, я слишком старательно экономил контекст

Когда я полез в журналы Astra, обнаружилась довольно неприятная особенность нашей адаптации. Модель могла за один шаг написать 13 КБ кода, но в следующем наблюдении увидеть лишь короткую выдержку из собственного вызова — около 2 КиБ текста. Полный вызов из истории мы уже убрали, а в состоянии подробности написанного кода сами собой, конечно, не появлялись. Чтобы их восстановить, модель читала файл заново. И здесь её ждал следующий сюрприз: результат чтения обрезался до 4 КиБ.

Так агент рисковал застрять в чтении по кругу: написать файл, увидеть только начало, запросить другой фрагмент, вернуться к предыдущему. В одном из разобранных HTTP-проектов V2 сделала 87 обращений, 80 результатов оказались обрезаны, а последние 70 действий были чтением и осмотром файлов, без новых правок или запуска тестов. Это ещё не доказывает, что все лишние циклы вызвала именно обрезка, но повод проверить её явно был.

Я поднял сразу четыре лимита до 2 МиБ каждый: на полное состояние, принимаемые аргументы действия, их сохранённую копию и сохранённый результат. Раньше это были 32, 64, 3 и 4 КиБ соответственно. Заодно пришлось защитить JSON-запись перехода от повторной обрезки при сохранении истории: штатный механизм мог обрезать её как обычный текст, нарушив формат, и состояние уже не удавалось восстановить. Точнее, повреждённая запись пропускалась, и сборщик мог взять более раннее состояние вместо последнего. Первый аудит проверял, как собирается запрос, но это ещё не гарантировало сохранность состояния на всём пути через историю. Поэтому его отметку о передаче полного актуального Σ нужно читать с этой позднее обнаруженной оговоркой; она тоже зафиксирована в дополнении к аудиту. Сам протокол, comment, окно k=3 и правила исполнения действий не менялись.

Важно, что 2 МиБ здесь — потолок для каждого из перечисленных полей, а не обязательный размер запроса и не увеличение контекстного окна модели. В двух новых сериях самое большое сохранённое состояние оказалось меньше 4 КиБ, а результат действия — меньше 44 КиБ. Усечений на уровне SKILL.state больше не обнаружилось.

При этом в двух вызовах Astra/V2 вывод всё же оказался обрезан, но уже по другой причине: модель сама передала в exec_command параметр max_output_tokens: 2000. Оба случая относятся к одной сессии на HTTP-проекте. Вывод тестов каждый раз получился примерно на 2073 токена, и штатный инструмент Codex применил запрошенный лимит ещё до передачи результата в SKILL.state. Наш потолок в 2 МиБ этот меньший лимит не отменяет и уже потерянный текст не восстанавливает. Так что здесь мы убрали агрессивную обрезку со стороны нашей обёртки, но не отключили ограничения инструментов, в том числе заданные самой моделью.

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

Astra с расширенными лимитами: картина поменялась

Я снова запустил все четыре режима, по пять повторов пяти проектов. Native тоже прогнал заново, чтобы сравнивать результаты внутри одной серии. Скиллы на время запусков опять убрал; модель, reasoning, k и 15-минутный таймаут оставил прежними.

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	2,734	—	140	25/25	0
Paper	15,318	+460,3%	1027	16/25	9
V2	2,654	−2,9%	159	25/25	0
V3	2,340	−14,4%	141	25/25	0

Пять повторов Codex/Astra с лимитами 2 МиБ: input, циклы и наблюдаемое время на задачу

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

Вот теперь V2 практически сравнялась с Native по расходу, а V3 использовала на 14,4% меньше input при почти том же числе обращений — 141 против 140. У всех трёх вариантов полный успех 25/25. Если раньше у V2/V3 были десятки циклов на проект, то теперь в среднем получилось 6,36 и 5,64, рядом с 5,6 у Native. Для меня это хороший повод осторожнее относиться к мысли, что сильной модели на коротких задачах state непременно мешает: с другой настройкой памяти получилась уже другая картина.

Paper тоже стала чаще завершать работу, но девять таймаутов и расход в 5,6 раза выше Native никуда не спрячешь. Даже с дополнительным местом для памяти наша исходная адаптация пока заметно отстаёт. При этом всю разницу между сериями приписывать обрезке нельзя: помимо нескольких изменений реализации, на результат влияет и то, как именно модель решает задачу в каждом запуске. Полный отчёт Astra, включая фактические размеры наблюдений.

Sol с теми же лимитами: V2 экономнее, V3 чуть ближе

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

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	6,367	—	279	24/25	0
Paper	9,215	+44,7%	629	19/25	5
V2	4,077	−36,0%	235	23/25	0
V3	4,180	−34,4%	225	25/25	0

Пять повторов Codex/Sol с лимитами 2 МиБ: input, циклы и наблюдаемое время на задачу

V2 потратила на 36% меньше input, чем Native, V3 — на 34,4%. При этом V3 теперь дороже V2 всего на 2,5% и действительно сделала немного меньше циклов: 225 против 235. Правда, по времени в этой серии V2 всё равно быстрее — в среднем 5,28 минуты на проект против 5,93. Ещё одно напоминание, что число обращений полезно смотреть рядом со временем, но полностью заменять им время нельзя.

У V3 все 25 сессий прошли проверки и завершились, у V2 — 23, у Native — 24. Последнее число учитывает знакомую поправку к тесту удаления: я применил её ко всем 40 CLI-проектам двух новых серий, и она вернула один ошибочно снятый балл Sol/Native. По исходному оценщику у него было 23/25. Это не исправление проекта или перезапуск модели; обе версии оценок сохранены в отчёте.

Меня V2 по-прежнему устраивает, а V3 в этой конфигурации уже выглядит интереснее, чем в прошлых повторах Sol. Но превращать разницу в одну-две сессии на пяти знакомых задачах в вывод о превосходстве по качеству я бы не стал. Paper и здесь остаётся дороже Native и пять раз упирается в таймаут. Отчёт Sol с исходными и уточнёнными проверками.

Ещё один контроль: Paper2

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

Поэтому захотелось проверить ещё один, более близкий к этому прочтению вариант. Назвал его Paper2: всё оставил как у Paper, но в единственное последнее O добавил выполненное действие, его аргументы и статус. Без истории из трёх записей, без комментария и без других изменений V2. Простое переключение V2 на k=1 не дало бы такого сравнения: у неё отличаются и контракт ответа, и обновление состояния.

Я прогнал Paper2 на Sol и Astra: по пять повторов пяти проектов, с лимитами до 2 МиБ и без глобальных скиллов. Reasoning medium, 15 минут на задачу, до пяти CLI одновременно — как в предыдущих сериях. Ниже сравниваю с их Native и Paper, а не с новыми одновременными контролями: те запускались 8–9 сентября, Paper2 — 10 сентября. Протокол зафиксирован до прогонов.

Начну с Sol:

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	6,367	—	279	24/25	0
Paper	9,215	+44,7%	629	19/25	5
Paper2	4,602	−27,7%	302	23/25	2

Codex/Sol: Paper2 против прежних Native и Paper — input, циклы и время на задачу

Вот это уже гораздо ближе к тому, чего я ждал от исходной идеи. По сравнению с Paper расход упал на 50,1%, а число обращений — с 629 до 302. Относительно Native получилось на 27,7% меньше input, хотя циклов всё ещё чуть больше. Правда, экономия токенов не стала ускорением: среднее наблюдаемое время на задачу — 8,05 минуты против 6,32 у Native. Время здесь включает ожидания и таймауты, так что приписывать всю разницу устройству контекста тоже нельзя.

Полный успех у Sol — 23/25 после той же дополнительной проверки удаления задачи, что и в прошлых сериях. По исходному оценщику было 22/25: один корректный CLI снова потерял балл из-за формы JSON-ответа. Я проверил все десять новых CLI-проектов на копиях, не исправляя код и не перезапуская модель.

Теперь Astra:

Режим	Input, млн	К Native	Обращения	Полный успех	Таймауты
Native	2,734	—	140	25/25	0
Paper	15,318	+460,3%	1027	16/25	9
Paper2	4,395	+60,8%	284	23/25	2

Codex/Astra: Paper2 против прежних Native и Paper — input, циклы и время на задачу

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

У Astra улучшение относительно Paper ещё заметнее: на 71,3% меньше input, 284 обращения вместо 1027 и два таймаута вместо девяти. Но Native здесь всё ещё лучше — почти вдвое меньше циклов, меньше токенов и все 25 задач завершены. При этом сами проекты Paper2 прошли 200/200 проверок: в двух случаях код уже работал, а до принятого finish агент так и не дошёл. Поэтому балл проекта и полный успех я продолжаю показывать раздельно.

Для меня это важное уточнение к истории с Paper: чтобы получить заметно другой результат, не обязательно было добавлять три наблюдения или батчи. В этой серии хватило более содержательного последнего O. Но говорить, что мы доказали пользу каждого его поля, рано: имя действия, аргументы и статус добавились вместе, а контрольные серии проведены раньше. Отличие Native с Code Mode от state с Direct tools тоже никуда не делось. После этого на результаты первой адаптации я уже смотрю иначе.

И ещё техническая оговорка. Первый запуск остановила защита изоляции: обновление плагинов вернуло глобальные источники скиллов. Четыре готовых результата сохранили, пять прерванных попыток записали отдельно, а после восстановления изоляции запустили оставшиеся 46 сессий. В таблицах — 50 итоговых исходов; расход тех пяти прерванных попыток не включён, поэтому это не полный бюджет кампании. Четыре таймаута отдельных сессий, напротив, остались и в результатах, и в расходе. Проверки сохранённых контекстов не нашли маркеров глобальных скиллов, повреждённых переходов или обрезки input/result со стороны SKILL.state. После завершения глобальные источники восстановлены.

Отчёт Paper2 с исходными и уточнёнными оценками, данные для таблиц и графиков, разбор прерывания.

Paper2 с малыми лимитами

После этого захотелось сделать ещё одну проверку: а сохранится ли результат Paper2, если вернуть прежние ограничения? Состав O оставил тем же, но на состояние снова отвёл 32 КиБ, на принимаемые аргументы — 64 КиБ, на их сохранённую копию — 3 КиБ, на результат — 4 КиБ. Защиту JSON от повторной обрезки сохранил.

Получилось ещё 50 новых сессий: пять повторов пяти задач на Sol и Astra, без глобальных скиллов, с тем же reasoning medium, 15 минутами на задачу и параллельностью до пяти CLI. Ни одной попытки не заменял и не перезапускал. В таблицах ниже сравниваю только два варианта Paper2; малыми дальше называю эти четыре лимита.

У Sol результат ухудшился, хотя не настолько резко, как у Astra:

Лимиты Paper2	Input, млн	К большим лимитам	Обращения	Полный успех	Таймауты
До 2 МиБ на поле	4,602	—	302	23/25	2
Малые	6,956	+51,1%	463	18/25	5

Codex/Sol: Paper2 с большими и малыми лимитами — input, циклы и время на задачу

При малых лимитах код прошёл все проверки в 23 из 25 проектов, но пять из этих сессий не завершились в срок. Поэтому полных успехов осталось 18. Сумма проверок — 198/200. Дополнительную проверку удаления я снова применил ко всем десяти CLI-проектам обеих моделей; в этот раз она не изменила исходные оценки.

А вот Astra вернулась к знакомой картине: работающий код есть, завершения нет.

Лимиты Paper2	Input, млн	К большим лимитам	Обращения	Полный успех	Таймауты
До 2 МиБ на поле	4,395	—	284	23/25	2
Малые	31,728	+621,8%	2090	0/25	25

Codex/Astra: Paper2 с большими и малыми лимитами — input, циклы и время на задачу

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

Все 25 проектов Astra прошли тесты — 200/200 проверок, — но все 25 сессий упёрлись в таймаут. В журналах нет ни одной попытки вызвать finish: это не ситуация, когда модель пыталась завершить работу, а ядро отклоняло её ответ. По сравнению с большими лимитами вход вырос в 7,2 раза, число обращений — с 284 до 2090.

По сохранённым переходам у Astra 2002 результата действий были обрезаны лимитом SKILL.state, у Sol — 253. Повреждённых JSON-переходов аудит не нашёл. Само состояние, кстати, оставалось маленьким: максимум 928 байт у Astra и 3367 у Sol, гораздо меньше отведённых 32 КиБ. Это ещё не доказывает, что все лишние циклы вызвало усечение результатов, но явно не похоже на нехватку места под само Σ. Знать, какую команду только что выполнил, полезно; получить достаточный ответ на неё — отдельная задача.

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

Для меня итог этого контроля такой: более содержательное O заметно помогло Paper2 при больших лимитах, но само по себе не спасло при малых. Обсуждать только формулу памяти без того, что фактически доходит до модели, оказалось недостаточно. Дальше хочется разбирать эти ограничения по одному.

Отчёт малого Paper2, данные сравнения и аудит завершений и усечений.

Результаты

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

Сравнение

Начну со сводки Codex с расширенными лимитами: здесь у нас есть результаты всех пяти вариантов на Sol и Astra, по 25 сессий на каждое сочетание. В ячейках — вход в миллионах токенов и число полностью успешных сессий из 25. Как и выше, полный успех требует и прохождения проверок, и штатного завершения; расход включает неудачные запуски. Считаем пока основной агентный цикл.

Модель	Native	Paper	Paper2	V2	V3
Sol	6,367; 24/25	9,215; 19/25	4,602; 23/25	4,077; 23/25	4,180; 25/25
Astra	2,734; 25/25	15,318; 16/25	4,395; 23/25	2,654; 25/25	2,340; 25/25

Важная деталь: Native, Paper, V2 и V3 запускались 8–9 сентября, а Paper2 — 10 сентября. Настройки и задачи те же, но одновременного контроля для Paper2 не было. Таблица собирает эти результаты рядом для удобства; подробности каждой серии и сравнения с малыми лимитами остались выше.

Native оказался хорошей точкой отсчёта. В десяти повторах Sol он завершил с полным успехом 49 из 50 сессий, в следующих сериях — 25 из 25 и 24 из 25. На Astra в обеих сериях — 25 из 25. При прежних ограничениях памяти Astra в Native была ещё и заметно экономнее всех state-вариантов: на проект ей хватало в среднем 5,44 обращения. После расширения лимитов V2 и V3 смогли приблизиться к ней по числу циклов и потратить меньше входных токенов. Так что первое впечатление о безусловном преимуществе Native на этих коротких задачах пришлось пересмотреть.

Paper чаще других упирался в лишние циклы. Уже в первом сравнении Codex и Sol, и Terra довели до finish только по два проекта из пяти. В десяти повторах Sol получилось 30 полных успехов из 50, а в серии без глобальных скиллов — 8 из 25. На Astra с малыми лимитами не завершилась ни одна из 25 сессий, хотя 24 проекта прошли все проверки. Расширение лимитов заметно помогло обеим моделям, но расход Paper всё равно остался выше Native, и таймауты никуда не исчезли.

Paper2 заставил меня иначе посмотреть на эту историю. Одно наблюдение с действием, аргументами и статусом при больших лимитах дало по 23 полных успеха из 25 на обеих моделях. Относительно Paper вход уменьшился на 50,1% у Sol и на 71,3% у Astra. При этом Sol потратила на 27,7% меньше входа, чем Native, а Astra — на 60,8% больше. Даже у такого небольшого изменения результат зависит от модели. И всё это относится к большим лимитам: после их уменьшения у Sol осталось 18 полных успехов, у Astra — ни одного, хотя весь её код прошёл тесты. Вход вырос на 51,1% и в 7,2 раза соответственно. Защита JSON при этом сохранилась. Похоже, понимать, какое действие только что выполнил, полезно, но агенту ещё нужно получить достаточно информации о его результате.

V2 на Sol мне по-прежнему нравится больше всего по сочетанию расхода и качества. В десяти повторах она использовала на 49,7% меньше входа, чем Native, при 48 полных успехах из 50. Без глобальных скиллов экономия составила 31,0%, с расширенными лимитами — 36,0%. Условия менялись, направление сохранилось. Правда, в последней серии V2 завершила с полным успехом 23 сессии из 25, Native — 24, а V3 — все 25; разницу в одну-две сессии здесь ещё нужно проверять на новых задачах. На Astra при прежних лимитах V2 заметно проигрывала Native, зато с расширенными почти сравнялась по входу: на 2,9% меньше при тех же 25 полных успехах.

V3 дала самый неоднозначный результат. В первом круге из трёх попыток она в сумме оказалась дороже V2 и на Sol, и на Terra, а ожидаемого сокращения циклов почти не было. В следующих десяти повторах Sol вход вырос относительно V2 на 33,4%, число обращений — на 24,3%. После удаления глобальных скиллов V3 тоже оставалась дороже V2. С расширенными лимитами картина стала интереснее: на Sol V3 сделала 225 обращений против 235 у V2, потратила на 2,5% больше входа и завершила все 25 сессий с полным успехом. На Astra у неё уже лучший расход в этой сводке — на 14,4% меньше Native, при почти одинаковом числе обращений и тех же 25 полных успехах. Пока хочется разобраться, какую роль здесь сыграли сами батчи, а какую — более вместительное окно наблюдений.

Опыты с OpenCode тоже стоит держать в голове. На Sol V2 прошла все 40 проверок и потратила на 62,0% меньше входа, чем Native. На Terra каждый state-вариант использовал больше токенов и прошёл меньше проверок, чем штатный агент. В первоначальном Codex-сравнении V2 и V3 снизили вход на обеих моделях при том же суммарном балле. Но это были одиночные запуски, а Paper2 на OpenCode мы не проверяли. Считать, что результаты поздних серий Codex автоматически перенесутся на другое ядро, пока рано.

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

Общий график четырёх режимов: input относительно Native слева, обращения на задачу справа

Слева расход нормирован относительно Native: его серые столбцы стоят на уровне 1×, а шкала логарифмическая. Справа — число обращений на обычной линейной шкале. Штриховка и ! означают провал проверок, таймаут или отсутствие finish, в том числе у Native. Так видно, где низкий расход сопровождался неудачей. Прежний общий рисунок только с input также сохранён отдельно.

Для меня итог такой: структурированная память на этих задачах действительно может экономить вход. Но одной удачной формулы состояния оказалось недостаточно. Имеет значение, какие сведения получает модель после действия, сколько из них мы обрезаем и сколько лишних циклов из-за этого появляется. Особенно хорошо это видно по Paper2 и по развороту результатов Astra после расширения лимитов. Теперь хочется менять эти вещи по одной и проверять на новых задачах — пяти знакомых спецификаций для общих выводов всё-таки мало.

Токены — ещё не стоимость

Когда я смотрю на эти результаты, мне помогает держать перед глазами простое равенство:

накопленный input = число обращений × средний input на обращение

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

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

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

Есть ещё один расход, который не виден в основной таблице: у Codex работает отдельная модель, автоматически проверяющая разрешения на действия. Её вызовы идут в отдельной сессии, и их учёт я вынес в отдельный отчёт. Если добавить зарегистрированный вход этого рецензента, для Sol меняется даже направление сравнения: в первоначальном круге из трёх попыток основной цикл V3 использовал на 4,0% больше входа, чем V2, а вместе с рецензентом получилось на 8,4% меньше. Для Terra суммарный вход с рецензентом, наоборот, оказался на 16,9% выше у V3.

В последующих десяти повторах Sol добавление зарегистрированных вспомогательных вызовов уже не меняет направление вывода: V2 — 10,969 млн входных токенов, V3 — 14,057 млн, то есть V3 расходует на 28,2% больше. У Native получилось 20,131 млн, у Paper — 32,788 млн. Это другой набор запусков; его расход на вспомогательные вызовы учтён отдельно.

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

А что здесь зависит от модели и длины задачи?

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

Здесь можно позволить себе немного математики. Пусть B — постоянная часть запроса, h — средний объём, добавляемый в историю за шаг, а T — число обращений. Если история накапливается без сжатия, получаем простую прикидку:

контекст на шаге t ≈ B + h(t − 1)
суммарный input Native ≈ BT + hT(T − 1)/2

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

суммарный input state ≈ T(B + M)

Это та самая асимптотика из статьи: O(T²) против O(T), при ограниченном размере состояния и наблюдений. В этой упрощённой модели state начинает окупаться при T > 1 + 2M/h. Порог зависит от M и h: сначала нужно отбить накладные расходы. На короткой истории экономить ещё особенно нечего, а описание протокола и ведение состояния уже стоят токенов. Поэтому здесь такой подход скорее рискует навредить, чем автоматически дать выигрыш. Впрочем, Sol/V2 показывает, что и на наших небольших задачах экономия возможна при удачном соотношении накладных расходов и сохранённой истории.

Есть существенное «но»: число шагов у вариантов не обязано совпадать. Если агент в state-режиме теряет детали, заново читает файлы или не понимает, что уже пора заканчивать, сравнивать приходится не два выражения с одним T, а T_native и T_state. Более короткий запрос ничего не гарантирует, если таких запросов потребовалось в несколько раз больше. Да и реальный Native не обязан бесконечно накапливать историю: сжатие и усечение меняют объём передаваемого контекста, а кэширование влияет на стоимость, о которой говорили выше.

Первый результат Astra хорошо укладывался в эту картину. В Native наши экспериментальные задачки оказались для неё очень короткими: в среднем 5,44 обращения против 11,8 у Sol. История ещё не успела толком разрастись, а в state-вариантах уже возникли дополнительные циклы. С прежними лимитами штатный агент действительно оказался наголову эффективнее.

Но результаты с расширенными лимитами уже не укладываются в такое простое объяснение. Задачи не стали длиннее для Astra: Native по-прежнему уложился в среднем в 5,6 обращения. Зато V3 теперь понадобилось почти столько же, и она уже сэкономила input. Похоже, важно не только то, сколько шагов модели нужно для решения, но и то, сколько лишних шагов мы заставляем её делать выбранной схемой памяти. Пока это только гипотеза: влияние изменений мы не разделили, инструменты вызываются по-разному — через Code Mode у Native и напрямую в state-режимах, — да и с завершением работы варианты справляются неодинаково.

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

Сравнить Native с Paper, Paper2, V2, V3 или другим вариантом на задаче, длинной уже для самой Astra, нам ещё предстоит. Таких данных у нас просто нет. Обещать, что state на длинной задаче обязательно выиграет, тоже пока нельзя: нужно ещё удержать качество и не растянуть решение потерями памяти.

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

Что хочется проверить дальше

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

Из собственных вариантов я бы пока продолжил работу с V2: в нескольких сериях этот вариант дал интересный баланс расхода и качества. V3 при прежних лимитах на Sol ожидаемого улучшения не принесла, зато с расширенными уже немного сократила число циклов, почти не уступая V2 по input. А на Astra этот вариант оказался экономнее и V2, и Native при полном успехе во всех 25 сессиях. Это не делает V3 универсальным победителем, но и отбрасывать её после первых повторов было бы рано.

По пяти небольшим проектам, написанным с нуля на конкретных настройках, нельзя заключить ни что SKILL.state годится только для узкого класса задач, ни что мои дополнения универсально лучше. Зато появились более интересные вопросы. В какой момент структурированного состояния перестаёт хватать? Что делать с наблюдением, важность которого становится понятна лишь через несколько шагов? Сколько недавней истории нужно оставить, чтобы агент не забывал о начатом, и насколько ответ зависит от доступных ему инструментов?

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

Код, спецификации и журналы собраны в skill-state-research. Для тех, кто захочет разобраться глубже, есть полный отчёт основной серии, условия эксперимента и план научного продолжения. Мне по-прежнему хочется довести эту историю до полноценной научной статьи — теперь уже с более точными вопросами и экспериментами, которые позволят на них ответить.

Вывод

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

Claude Code читает не страницу, а её пересказ: прошёл путь одного запроса по документации Claude

sburyi — Mon, 14 Sep 2026 13:56:17 +0000

Совет оптимизировать сайт под Claude смешивает два инструмента Anthropic: Claude и агента Claude Code. Profound снял 24 135 ответов на одних запросах, и у двух инструментов разошёлся почти каждый показатель. Я прошёл по документации путь запроса в обоих инструментах. Для владельца сайта из разбора следуют три вещи: какие боты Anthropic заходят на сайт, что закрыть в robots.txt и как проверить заходы по access-логу.

Откуда данные: документация Anthropic и открытые исследования

Своих прогонов под эту статью я не делал, картина собрана по открытым источникам. Claude здесь и дальше означает приложение claude.ai и программный доступ к той же ИИ-модели через Messages API, Claude Code — агента, которого разработчик запускает в терминале для работы с кодом. Profound снимал приложение claude.ai, а параметры поиска и формат цитат взяты из документации Messages API: для приложения Anthropic их не описывает. Источников три группы: документация Anthropic (platform.claude.com, code.claude.com, support.claude.com), разбор Profound «Claude and Claude Code are distinct answer engines» от 24 августа 2026 года (answer engine — система, которая отвечает вместо выдачи ссылок) и два исследования серверных логов, Ahrefs и Saaslinks, о том, кто запрашивает у сайтов файл llms.txt.

Выборка Profound — 24 135 ответов на 1 724 запроса из 11 категорий, снятых с 13 по 23 июля 2026 года, веб-поиск включён у всех систем; отдельная подвыборка про программирование — 2 800 ответов на 200 запросов. Ещё компания разобрала топ-1000 страниц, которые агенты обеих систем посетили с 18 июля по 18 августа, и разложила их по категориям нейросетью GPT-4.1-mini, а не вручную. Страницы взяты с доменов, которые Profound отслеживает у себя (в оригинале internally tracked domains), и выборка, вероятно, смещена к SaaS и технологическим компаниям: переносить эти цифры на интернет-магазин или медицинский сайт без проверки я бы не стал.

Что происходит, когда Claude ищет через API: цитата с адресом и куском текста

В выборке Profound приложение claude.ai искало в вебе больше чем в 93% ответов. Это цифра одной выборки: другое исследование, со своим набором запросов и счётом по промптам, даёт для Claude 36,6%. По документации веб-поиска Messages API ИИ-модель сама решает, вызывать ли инструмент для конкретного вопроса. Владельцу сайта из параметров поиска важен один: разработчик приложения на API может сузить поиск списком разрешённых (allowed_domains) или запрещённых (blocked_domains) доменов, и тогда сайт вне списка такое приложение не найдёт, как бы хорошо он ни был написан.

Найденные страницы приходят отдельным блоком web_search_tool_result — списком с адресом и заголовком каждой. В тексте ответа Claude расставляет цитаты типа web_search_result_location, и каждая несёт адрес (url), заголовок (title), зашифрованный указатель на источник и кусок процитированного текста до 150 символов (cited_text). Поля url, title и cited_text в токенах не учитываются. Следующий фрагмент нужен тому, кто строит приложение на API: так со стороны кода выглядит разбор уже полученного ответа, без единого сетевого запроса.

def extract_cited_urls(response_content):
    """Уникальные цитаты web_search_result_location
    из response.content ответа Messages API."""
    seen = set()
    citations = []
    for block in response_content:
        for c in block.get("citations") or []:
            if c.get("type") != "web_search_result_location":
                continue
            url = c.get("url")
            if not url or url in seen:
                continue
            seen.add(url)
            citations.append({
                "url": url,
                "title": c.get("title", ""),
                "cited_text": c.get("cited_text", ""),
            })
    return citations

Функция проходит по блокам response.content, берёт из них цитаты веб-поиска и отбрасывает повторы одного адреса. Если страница есть в блоке результатов, но её url нет среди цитат, поиск её нашёл, а в текст ответа она не попала. У Messages API есть и второй инструмент, web fetch tool, который забирает содержимое страницы по адресу. По его документации он открывает только адреса, которые уже встречались в разговоре: в сообщении пользователя или в результатах прошлого поиска. Ссылку, которую ИИ-модель сочинила сама, он не откроет — так Anthropic защищается от утечки данных. JavaScript этот инструмент не выполняет, для страниц, которые собирает браузер, у Anthropic есть отдельный browser use tool.

На какие сайты приходятся цитаты Claude, посчитала OtterlyAI: 379 321 цитата по 16 406 доменам, июнь 2026 года, запросы из SaaS и tech. Сайты брендов и продуктов собрали 64,0% цитат, новости и медиа — 14,9%. На топ-10 доменов пришлось 9,5% всех цитат, на топ-500 — 59,9%, а 32,9% доменов процитированы ровно один раз.

Когда Claude Code открывает страницу, до основной ИИ-модели доходит пересказ

У Claude в API путь заканчивается цитатой с куском исходного текста, у Claude Code — ответом вспомогательной ИИ-модели.

Claude Code ищет редко: в той же выборке Profound веб-поиск сработал в 13% ответов. Поиск здесь один инструмент, WebSearch, и по справочнику инструментов Claude Code его разрешают или запрещают целиком, без правил для отдельных доменов.

Страницу Claude Code открывает инструментом WebFetch, и до основной ИИ-модели она, как правило, доходит уже переработанной. По справочнику, WebFetch получает адрес и промпт с описанием, что нужно извлечь, страницу по этому промпту читает вспомогательная ИИ-модель поменьше, и в большинстве случаев основная получает её ответ, а не исходную страницу. Длинные страницы перед обработкой обрезаются до фиксированного числа символов, а сама документация называет инструмент lossy by design: детали он теряет намеренно.

Исключение описано не у Anthropic, а в стороннем разборе кода Claude Code от января 2026 года. HTML там переводится в Markdown библиотекой Turndown, а пересказ пропускается при двух условиях сразу: домен входит в зашитый список примерно из 80 сайтов документации (Python Docs, MDN, React, Kubernetes, AWS), и страница отдаётся как text/markdown короче примерно 100 тысяч символов. Обычный сайт в этот список не входит, поэтому его страницу Claude Code получает пересказом, в каком бы формате она ни была. Anthropic списка не публикует, и он может смениться с любой версией.

Остальное в справочнике касается в основном отладки агента: кэш ответа на 15 минут, пятиминутный срок загрузки, переменные окружения. Для сайта важны две детали. Редирект на другой домен WebFetch сам не проходит: он возвращает исходный и новый адрес, и агент должен повторить запрос. А правилом WebFetch(domain:example.com) в списке permissions.deny файла settings.json разработчик может запретить агенту конкретный сайт, даже если robots.txt этого сайта открыт.

Разницу между Claude и Claude Code видно и по ответам

Выборка Profound, июль 2026: одни и те же 1 724 запроса, два разных набора чисел на выходе.

Разбор Profound показывает ту же разницу со стороны ответов. На одних и тех же 1 724 запросах Claude Code в среднем называет 6,6 бренда за ответ, Claude — 5,2, и совпадает у них лишь один бренд из пяти. Длина ответа тоже разная: в среднем 322 слова у Claude Code и 459 у Claude.

Сильнее всего различается форма ответа. По данным Profound, Claude Code вставляет списки в 94% ответов и таблицы в 54%. У Claude списки есть в 56% ответов, таблицы — в 11%. Причин такой разницы Profound не называет, в разборе приведены только доли.

Разные и страницы, на которые ходят агенты. В топ-1000 страниц, посещённых с 18 июля по 18 августа, почти три четверти визитов Claude Code пришлись на документацию. У Claude 60% визитов — это robots.txt, карта сайта (sitemap) и главные страницы.

Одна цифра в открытых источниках не сходится. Profound на июльской выборке получил поиск больше чем в 93% ответов Claude. Другое исследование, представленное на сессии Profound Zero Click и пересказанное Search Engine Land в июне 2026 года, даёт для Claude 36,6% промптов с поиском при примерно 90% у ChatGPT. Там же частота поиска разложена по типам запросов: 81% у вопросов о свежих событиях, 67% у рейтингов, 55% у запросов с привязкой к месту и 51% у сравнений. Profound считает долю ответов, второе исследование — долю промптов, выборки и периоды у них разные, поэтому к одному числу эти данные не сводятся. Сравнивать 13% у Claude Code корректно только с цифрой Profound: обе сняты на одной выборке.

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

На сайт заходят три разных бота Anthropic

Правило в robots.txt действует только на того бота, чьё имя в нём стоит.

У Anthropic три краулера с разными именами и задачами, и правило в robots.txt для одного из них не действует на двух других. По документации поддержки Anthropic, обновлённой 7 апреля 2026 года, ClaudeBot собирает контент для обучения ИИ-моделей, и его блокировка исключает сайт из будущих обучающих наборов. Claude-User забирает страницу, когда о ней спрашивает конкретный пользователь Claude, и его блокировка снижает видимость сайта в ответах на такие вопросы. Claude-SearchBot индексирует контент для качества поиска, и без него, по той же документации, может упасть точность цитирования.

Все три бота соблюдают robots.txt, включая Claude-User. По разбору Search Engine Journal это отличает Anthropic от OpenAI, у которой ChatGPT-User по её же документации может файл не соблюдать. Правила пишутся на каждого бота и на каждый поддомен отдельно. Кто хочет остаться в ответах Claude, но не отдавать тексты на обучение, закрывает только ClaudeBot:

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

Группы с Allow: / для Claude-User и Claude-SearchBot нужны, если в файле есть общее правило User-agent: с запретами: по стандарту robots.txt (RFC 9309) бот, для которого есть группа со своим именем, общую группу не читает. Если общего запрета нет, эти две группы можно не писать. Блокировать ботов по IP-адресу Anthropic не советует: они работают на мощностях публичных облачных провайдеров. Список адресов в bots.json компания публикует, но надёжнее различать ботов по user-agent — подписи, которой бот представляется серверу.

С user-agent инструмента WebFetch в Claude Code как раз ничего не ясно: какой подписью он ходит на внешние сайты, Anthropic не публикует. Это может быть тот же Claude-User или отдельная строка, а независимые каталоги ботов расходятся даже в строке Claude-User. Ответ для своего сайта даёт только собственный лог.

Боты Anthropic llms.txt почти не читают

Файл llms.txt лежит по адресу /llms.txt и коротко описывает сайт для ИИ-моделей: ссылки на главные страницы в формате, удобном для машинного чтения. У platform.claude.com и code.claude.com такой файл есть, со ссылкой на полную версию llms-full.txt, так что для собственной документации Anthropic этот формат держит.

На чужих сайтах его почти никто не запрашивает, в том числе боты Anthropic. Ahrefs проверил 137 210 доменов в мае 2026 года и нашёл валидный llms.txt примерно у 38 000: у 97% из них за месяц к файлу не было ни одного обращения. Краулеры обучения всех компаний вместе дали 5,3% запросов к llms.txt, а ClaudeBot — 0,8% запросов внутри этой категории. Claude-User набрал 2,5% всех запросов к файлу. Saaslinks разобрал логи одного сайта за две недели: ClaudeBot, Claude-SearchBot и Claude-User сделали 319, 96 и 8 запросов к /robots.txt и ни одного к /llms.txt.

Claude Code в исследовании Ahrefs назван среди примеров категории ИИ-агентов, и вся эта категория дала 10,5% запросов к llms.txt. По какой подписи Ahrefs опознавал агентов, в исследовании не раскрыто: сказано только, что все user-agent разложены на двенадцать категорий. Боты, от которых зависит ответ пользователю Claude в чате, файл почти не трогают. Если у проекта есть документация для разработчиков, llms.txt там уместен, Anthropic держит такой файл и у своей. Как способ попасть в ответ Claude на вопрос о бренде он по этим логам не работает.

Как посмотреть в своём логе, кто из ботов Anthropic к вам заходит

Какие боты Anthropic заходят на конкретный сайт, показывает только его собственный access-лог. У nginx стандартный формат журнала (combined log) содержит поле user-agent, и скрипт на Python считает по нему хиты трёх ботов и запрошенные пути. Официальной подписи WebFetch в Claude Code нет, поэтому все прочие user-agent со словом claude в любом регистре скрипт печатает отдельным списком: по нему видно, какие подписи с этим словом приходят на сайт.

from __future__ import annotations

import re
import sys
from collections import Counter

LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<path>\S+) \S+" '
    r'(?P<status>\d+) (?P<size>\S+) '
    r'"(?P<referer>[^"]*)" "(?P<agent>[^"]*)"'
)

BOTS = ("ClaudeBot", "Claude-User", "Claude-SearchBot")

def classify(user_agent: str) -> str | None:
    for name in BOTS:
        if name in user_agent:
            return name
    return None

def analyze(lines):
    hits: Counter[str] = Counter()
    paths_by_bot: dict[str, Counter[str]] = {}
    other_claude_agents: Counter[str] = Counter()
    for line in lines:
        match = LOG_PATTERN.match(line)
        if not match:
            continue
        agent = match.group("agent")
        bot = classify(agent)
        if bot:
            hits[bot] += 1
            paths_by_bot.setdefault(bot, Counter())[match.group("path")] += 1
        elif "claude" in agent.lower():
            other_claude_agents[agent] += 1
    return hits, paths_by_bot, other_claude_agents

def main() -> None:
    if len(sys.argv) != 2:
        sys.exit("Использование: python3 claude_log_stats.py access.log")
    with open(sys.argv[1], encoding="utf-8", errors="replace") as f:
        hits, paths_by_bot, other_claude_agents = analyze(f)
    print("Хиты по ботам Anthropic:")
    for bot, count in hits.most_common():
        print(f"  {bot}: {count}")
    print("\nПути по ботам:")
    for bot, paths in paths_by_bot.items():
        print(f"  {bot}: {dict(paths.most_common(5))}")
    if other_claude_agents:
        print("\nДругие user-agent с подстрокой claude:")
        for agent, count in other_claude_agents.most_common():
            print(f"  {agent}: {count}")

if __name__ == "__main__":
    main()

Файл читается построчно за один проход и не загружается в память целиком, так что большой лог скрипт тоже переварит. Функция classify ищет в user-agent имя одного из трёх ботов, analyze раскладывает строки на хиты, пути и прочие подписи с claude, а main без аргумента печатает подсказку и выходит с кодом 1. Строки, которые не разобрались по формату combined, пропускаются молча: если в логе nginx настроен свой формат, регулярное выражение придётся поправить под него.

Я проверил скрипт на шести синтетических строках, которые составил сам, это не трафик реального сайта. В них два захода ClaudeBot, по одному Claude-User и Claude-SearchBot, придуманный агент example-agent/0.1 (claude-test) и обычный браузер. Вывод прогона:

Хиты по ботам Anthropic:
  ClaudeBot: 2
  Claude-User: 1
  Claude-SearchBot: 1

Пути по ботам:
  ClaudeBot: {'/robots.txt': 1, '/blog/article-1': 1}
  Claude-User: {'/docs/pricing': 1}
  Claude-SearchBot: {'/pricing': 1}

Другие user-agent с подстрокой claude:
  example-agent/0.1 (claude-test): 1

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

Что по итогу разбора

Какой из двух инструментов важнее, решает аудитория сайта. Если вас выбирают покупатели, спрашивая чат, это Claude и его боты Claude-User и Claude-SearchBot. Если вашей документацией пользуются разработчики, добавляется Claude Code. Из документации и открытых исследований для владельца сайта следуют пять действий, первые два делаются за десять минут без разработчика.

Прописать robots.txt отдельно для ClaudeBot, Claude-User и Claude-SearchBot. Правило для одного бота на других не действует. Чтобы остаться в ответах Claude, но не отдавать тексты на обучение, достаточно закрыть только ClaudeBot.
Проверить, что важные страницы отдаются без JavaScript. Web fetch tool в Messages API не выполняет JavaScript, а WebFetch в Claude Code, по стороннему разбору кода, переводит в Markdown полученный HTML без выполнения скриптов. Если текст страницы собирает скрипт в браузере, оба инструмента его не увидят. Проверка простая: открыть страницу с отключённым JavaScript (в DevTools браузера это отдельная настройка). Что видно там, то видит и инструмент чтения.
Смотреть в собственный access-лог по user-agent. У трёх ботов Anthropic фиксированные подписи, их считает любой разбор лога по этому полю, а неизвестные подписи с claude стоит выводить отдельным списком. Скрипт на 60 строк здесь хватит, но запускать его на сервере обычно будет разработчик или администратор.
Не считать llms.txt способом попасть в ответы Claude. Боты, от которых зависят эти ответы, файл почти не запрашивают. У Saaslinks на логах одного сайта за две недели — ноль обращений от каждого из трёх, у Ahrefs 97% файлов на 38 000 доменов за месяц не получили ни одного обращения. Для документации, которую разработчики читают через Claude Code, llms.txt уместен.
Ставить главное в начало длинной страницы. WebFetch обрезает длинные страницы до обработки, а затем пересказывает их вспомогательной ИИ-моделью. Markdown-версия обычному сайту пересказа не отменит: по стороннему разбору кода быстрый путь без пересказа есть только у примерно 80 зашитых сайтов документации.

У разбора три ограничения. Цифры Profound сняты на доменах, которые компания отслеживает сама, вероятно в основном SaaS и tech, и для других ниш доли могут быть другими. Частота поиска у Claude расходится между источниками: больше 93% ответов у Profound и 36,6% промптов во втором исследовании, при разном счёте и разных выборках. User-agent, которым WebFetch в Claude Code ходит на внешние сайты, официально не описан, и узнать его можно только по своему логу.

Путь запроса в обоих инструментах описан в открытой документации почти целиком. В Messages API он заканчивается цитатой с адресом и куском исходного текста, у Claude Code — пересказом вспомогательной ИИ-модели, и формата цитат для него в документации Claude Code нет.

От поисковой строки к ИИ-агенту: зачем мы открыли Туту через MCP и что увидели на хакатоне

Mon, 14 Sep 2026 13:46:43 +0000

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

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

Привет! Меня зовут Арут Агабабян, я CTO Туту и один из организаторов нашего ИИ-хакатона. В Туту я отвечаю за технологическое развитие компании и много работаю с тем, как новые технологии можно превращать в реальные пользовательские сценарии. В этой статье расскажу, зачем мы открыли сервисы Туту для ИИ-агентов через MCP, что получилось у участников хакатона и какие выводы мы сделали про будущее агентных решений в travel-tech.

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

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

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

ИИ постепенно становится еще одним интерфейсом к travel-tech

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

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

Параллельно меняется и сам путь пользователя к покупке. В июне Forbes Technology Council описывал эту трансформацию через две технологии: GEO — Generative Engine Optimization, оптимизацию присутствия в ответах генеративных систем, — и MCP — Model Context Protocol, протокол подключения моделей к внешним данным и инструментам. В приведенном Forbes исследовании 64% маркетологов назвали снижение использования традиционного поиска одним из главных ожидаемых последствий распространения AI-поиска.

Для travel-tech эти два механизма решают разные задачи.

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

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

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

Что MCP меняет на практике

Model Context Protocol — открытый протокол для взаимодействия языковых моделей с внешними инструментами и источниками данных.

Если сильно упростить архитектуру, получается такая цепочка:

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

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

Сейчас через Tutu MCP агентам доступны пять основных направлений: самолеты, поезда, автобусы, электрички и отели. Для размещения можно использовать в том числе оценки и отзывы.

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

Для текущего этапа развития агентных интерфейсов human-in-the-loop — участие человека в критической точке сценария — выглядит вполне практичным компромиссом. Цена ошибки при рекомендации отеля и цена ошибки при оплате билета различаются.

Зачем после запуска MCP понадобился хакатон

Сделать API или MCP-сервер — только половина задачи. Вторая половина начинается с вопроса: что сторонние разработчики вообще будут строить, если дать им доступ к тревел-инструментам?

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

Поэтому с 19 по 21 августа мы провели всероссийский ИИ-хакатон. Задача была довольно широкой: разработать проект на основе Tutu MCP, который решает реальную проблему путешественника.

На участие пришла 301 заявка. На хакатон прошли 150 человек — 71 команда. До сдачи проектов дошли 42 команды, девять решений вышли в финал.

Мы специально оценивали не только факт использования ИИ. В критериях были понимание задачи, глубина функционала, UX/UI, документация, архитектура, качество кода, технологическая новизна и стабильность работы. Добавить LLM к форме поиска сравнительно легко. Нам было интереснее посмотреть, появляется ли за этим новый пользовательский сценарий.

Поисковая форма оказалась далеко не единственной точкой входа

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

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

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

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

Наконец, оказалось полезно строить поиск вокруг жесткого ограничения. Например: «У меня 20 тысяч рублей, три дня и нужно вернуться в Москву к понедельнику утром». Здесь задача начинается не с выбора конкретного направления, а с вычисления множества реально достижимых вариантов.

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

В агентной модели важен источник правды

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

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

Для пользователя эти слои могут выглядеть как один разговор. Внутри системы между ними должна оставаться четкая граница.

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

MCP здесь интересен не потому, что делает модель «умнее». Он дает ей стандартизированный способ обращаться к инструментам, способным ответить на вопрос сейчас.

Чем больше агент умеет делать, тем важнее безопасность

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

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

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

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

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

Это одна из причин, почему в текущем сценарии Туту финальная покупка остается за пользователем.

MCP пока не означает, что пользователи завтра перестанут открывать сайты

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

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

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

Поэтому для нас MCP пока скорее новый канал взаимодействия с продуктом, чем замена сайту или приложению.

Что мы вынесли из эксперимента

После запуска MCP и хакатона наше представление об агентном travel-tech стало немного конкретнее.

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

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

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

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

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

А что получили участники

Мы хотели, чтобы хакатон был полезен не только Туту.

Для участников это была возможность за несколько дней проверить собственную идею на реальном travel-tech-контексте, поработать с Tutu MCP и получить обратную связь от людей, которые каждый день делают продукты для путешествий.

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

Авторы лучших проектов получили призы, технику, мерч и сертификаты Туту на путешествия. Партнером хакатона стала Huawei, которая предоставила технику для призового фонда.

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

Поэтому участие в наших хакатонах — это не только три дня разработки и возможность забрать приз.

Это способ:

— получить доступ к реальной технологической инфраструктуре travel-tech-компании;

— проверить свою гипотезу на прикладной задаче;

— показать решение инженерам и продуктовым командам Туту;

— получить обратную связь от экспертов;

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

Ну и путешествия, конечно. Мы все-таки Туту :)

Планируем продолжать такие форматы. Поэтому если вам интересны ИИ, агентные системы и travel-tech, следите за нашими следующими хакатонами.

Что дальше

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

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

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

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

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

Как я учил планировщик класть широкие команды для Эльбруса, и почему LLM проиграла жадному алгоритму за 3 миллисекунды

Shmon — Mon, 14 Sep 2026 13:43:17 +0000

Все началось с того что я решил, что смогу оптимизировать компилятор Эльбрус с помощью ИИ
Вдохновлялся Эльбрусом 2: машина, которая в то время считала ПРО и космические задачи, 10 процессоров, десятки мегафлопс, когда это было реально много. Симметричный мультипроцессор с общей памятью, тегированная архитектура, аппаратная поддержка языков высокого уровня. В общем к проекту это вдохновение никак не повлияло.

Потом был Эльбрус-3 — уже с явным параллелизмом инструкций, прообраз VLIW. Потом тяжелые 90-е, потом Эльбрус 2000 / E2K. Ну про историю эльбруса вы уже слышали не раз.
Поэтому вернемся к моему проекту.

1. Что это за проект

Прототип к исследовательскому проекту «Планировщик инструкций для VLIW‑архитектур». Главный тезис:

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

Проще говоря, NEX CLI x Elbrus берет граф и модель e2k‑v6 и показывает: сколько насчитал жадный, сколько мог бы идеальный, и на какой операции и каком канале разница.

2. Зачем вообще трогать планирование под Эльбрус

Эльбрус — это VLIW. Там нет того, что прячет ваши косяки на x86: нет развитого OoО.

Что куда можно:
- Умножать можно только в каналах 0, 1, 3 и 4. Результат готов через 4 такта.
- Делить можно только в канале 5. Результат готов через 11 тактов, и следующее деление можно начать только через 2 такта.
- Загружать данные из памяти можно в каналах 0, 2, 3 и 5. Результат готов через 5 тактов.
- Записывать в память можно только в каналах 2 и 5.

Ошибся на один такт с делителем — встал весь пакет. Положил запись не туда — заклинил ,5, который нужен и делителю, и загрузкам. Компилятор lcc — единственный, кто может это разрулить статически.

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

python3 -m vliw run slotclash
# жадный: 23 такта, оптимум: 22 такта. -1 такт = -4%.
# Вопрос: где жадный зевнул монопольный ,5?

Сценарии так и называются — ловушки: slotclash, divpressure, memstream, unroll4, wide_ilp. У каждого — lesson в одну строчку. Например, ⁣memstream: 8 троек LOAD-ADD-STORE, узкое место — запись, потому что записей 8, а каналов под них 2.

3. Цифры не из воздуха. Но я им сам не до конца верю

Числа в e2k-v6-measured сняты с настоящего lcc-1.29.16 кросс‑сборкой под e2k-v6 тремя независимыми приемами. Это написано в шапке репа vliw/core/model.py:

1. Матрица портов — спрошена у ассемблера, а не угадана по листингу.
Для каждой пары (операция, канал) собирается крошечный .s. Если так нельзя аппаратно — ассемблер отвечает прямым отказом: 'muls' cannot be encoded in ALC2. Это ответ про кодировку широкой команды, про само железо, а не про то, что решил планировщик lcc. Автомат этого — tools/probe_matrix.py.

2. Латентность — цепочкой зависимых. x = x * b пять раз подряд. Следующая обязана ждать предыдущую, компилятор вынужден развести их ровно на latency. Разница номеров bundle читается напрямую. Так намеряны MUL 4, DIV 11, LOAD 5.

3. Занятие порта — потоком независимых. 8–16 штук с готовыми операндами. Шаг между выдачами = темп устройства. Так намеряны DIV раз в 2 такта, MUL раз в такт.

А теперь детектив.

Обожаю несмешно шутить

Первая версия модели была неверна. Был probe.c — 4 деления + 4 умножения. Все muls легли в ,0 подряд. Я прочитал это как «умножитель один, держит порт 8 тактов». А потом проверка ассемблером показала: умножение исполнимо на четырех каналах, а поток из 16 независимых умножений идет по одному в такт. Четырех операций просто не хватило, чтобы у жадного планировщика lcc появился повод их раскидать.

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

Все это прогонялось потом десятками ИИ‑агентов для перепроверки пар, каналов, сочетаний. Нашли ровно два запрета сочетаний в одной широкой команде: STORE,2 + LOAD,3 и STORE,5 + LOAD,0 — швы между кластерами ,0,1,2 и ,3,4,5. Сверялись с официальным «Руководством по эффективному программированию на платформе Эльбрус» 1.2 — но числа оттуда в модель НЕ подставляли: там Е4С/Е8С, а тулчейн целится в v6. Это сверка, а не источник.

И все равно — я не считаю цифры паспортом:

живого железа у меня не было, SSH Эльбруса — мне лень с ним возится.
из 19 классов latency измерена у 9. Остальное — ASSUMED=1, список открыт в ISA.md;
LOAD 5 против 3 (L1 hit, L2 11, L3 40, память ~100) из доки МЦСТ — расхождение поколений(Я перепроверял, и цифры сходились с документацией 24 года);
occupancy склеивает занятость устройства и слота. div8.c меряет устройство (раз в 2 такта), а в fma_kernel.s fdivd,5@t19 + aaurwd,5@t20 — слот свободен раньше. Модель пессимистична сознательно.

Поэтому давайте честно: это лучшая доступная аппроксимация, а не даташит.

И здесь — оффер, ради которого статья и пишется. Это не вам нужен мой проект. Это мне нужны вы.

Если у вас есть живой e2k-v6 — прогоните цепочки из examples/probes/ (mul_latency.c, div_latency.c, load_latency.c, store_burst.c...). Пришлите листинги lcc -O3 -fverbose-asm. Закроем 13 допущений, сверим LOAD 5 vs 3, померяем межкластер. Без вас эта таблица так и останется «замерами по поведению компилятора».

4. ИИ‑арка: как Qwen на 2 ГБ пытался стать оптимизатором

Изначальный план был наивный и красивый: научить LLM класть расписания напрямую. Граф на вход, строки id: такт=.. канал=.. на выход. Чем не планировщик?

База — Qwen2.5-3B-Instruct, QLoRA r16/alpha32, <2% обучаемых параметров. Адаптеры по ~120 МБ, три прогона, лежат открыто Shmonika/nex-vliw-lora — в git не влезли из‑за лимита 100 МБ. База в GGUF Q4_K_M — 2.1 ГБ, запускается на ноутбуке без GPU через llama.cpp.

Промпт — один и тот же код на обучение и на запуск (training/encode.py), иначе разъедется молча — уже проходили с EOS‑багом, когда модель без маркера конца не останавливалась и лила 24 лишних id:

vliw/core/     # чистый домен. Никаких print, никакого UI
vliw/cli.py    # Session, кэш, команды
vliw/ui/       # plain-рендер для терминала
vliw/tui/      # полноэкранный Textual
vliw/agent/    # разговорный агент поверх уже посчитанного
vliw/learned/  # LoRA-трек, опциональный
training/ tools/ examples/probes/ docs/

Датасет — 40 тысяч обученных данных: train_merged.jsonl — 39700 = dataset 20000 + extra 20000 - отсев. Пары граф -> оптимум через Oracle(budget=1.5с), только доказанные, размеры 6–14. Эвалы: eval 300, eval_wide 300 (4-24), eval_hard 300 (16-24, средний 20.3). Хотите — напишите мне, скину детали прогона, скрипты и промпты все открыты.

Что вышло по цифрам:

Скорость: baseline — миллисекунды, oracle на n=24 — 0.61с, 60 графов — 1.8с. Модель — 27–30с на граф, ~11 ток/с, на реале 178–395с, best-of-8 — 4 минуты на граф(после первого запроса скорость быстрее). Сервер держит 3.5 ГБ, без -c ограничения OOM‑киллер его убивал прямо посреди /learned.
Легкие выборки — пустые. Жадный уже 298/300 и 300/300 точно в оптимуме CP‑SAT. Выигрывать нечего. 477 секунд модели за тот же ответ, что эвристика дает мгновенно.
Прогон 0 без EOS — 26.7% валидных, прогон 1 с EOS — 97.7% на узком, 32.7% на широком. Все 11 провалов из 15 — STORE на чужом канале. В dataset не было ни одного STORE. Модель его никогда не видела.
Реал — 112-386 узлов против обучения на 4-24, словарь 37% UNKNOWN (предикаты, SIMD, AAU), 0/13 против случайного перебора за то же время.

То есть цифры сказали прямо: как бухгалтер модель медленная и хрупкая. Держать ее в ядре — значит платить 30 секунд за то, что алгоритм делает за 3 миллисекунды, и получать 17% законных на трудных графах.

Пришлось перейти на CAB (лучшее, что я случайно придумал).

5. CAB: забираем у модели бухгалтерию, оставляем чутье

Ладно, это очень смешно

CAB — “портфель законных расписаний из одного ответа модели”. Второй этап SEED стоит на нем, но суть — в первом.

Идея из docs/DIAG3.md: модель отлично чувствует порядок, но тонет в бухгалтерии — 315 незаконных каналов, 208 конфликтов, 26 неготовых операндов. При этом из 98 законных ответов 97 были точным оптимумом. Значит — забираем бухгалтерию целиком.

Что берем у модели:

берем	как	что выбрасываем
порядок	сортировка по ее `(такт,канал)` → `priority`	—
такты	как `defer_until` «не раньше»	—
каналы	не берем вообще	самая частая ошибка

Бухгалтерию ведет list_schedule из core/baseline.py — он по построению не выдаст раньше предков и не посадит двоих на канал. Расписание законно механизмом, а не удачей.

Дорогая здесь только генерация. Поэтому из одного ответа строим 5 кандидатов без лишних генераций: модель, модель+каналы (починка Куном), порядок, порядок+такты, жадный. Плюс те же 5 со второй генерации по грамматике GBNF. Побеждает min (makespan), при равенстве — ответ самой модели, чтобы не приписывать алгоритму чужое. Подпись в UI честная: CAB: <кандидат>.

Предсказание, записанное ДО замера, на slotclash с убитыми в ,0 каналами:

сырой — 22, но незаконно
жадный — 23
порядок — 23
порядок+такты — 22 = оптимум

Порядка мало, нужно еще «придержать» операцию у монопольного ,5. defer_until это возвращает.

Замер на трудном эвале, где у жадного наконец есть зазор (0/300 в оптимуме, разрыв 1.03):

жадный — 1.03, 0/300
модель + CAB — 0.82, 59/300 точно в оптимуме (62/300 после замера STORE=2)
вклад: порядок 25, модель 16, порядок+такты 13, модель+каналы 7. Итого 61/300 строго лучше жадного — 20% трудных графов.

Без CAB на тех же данных — 17% законных. С CAB — 100% по построению. Рост законных ничего не доказывает, доказывают 5 тактов на 30 и 60+ графов, отыгранные у доказанного оптимума.

SEED-1 (подсказка верхней границей в оракул) при этом мертв замером, а не мнением: даже идеальный оптимум экономит 5% узлов, потому что поиск идет снизу вверх и тратит все на провальные пробы. Платить 30с генерации за 5% от 30мс — бессмысленно. Оставили в коде, пригодится если поиск пойдет сверху вниз.

6. Где ИИ сейчас: не бухгалтер, а мини‑агент

И тут важный дисклеймер.

ИИ неэффективен только в моем сетапе. У меня нет мощностей гонять модели на сотни гигабайт — тысячегиговые монстры явно умнее моего Qwen на 2.5 ГБ. Суть не в том, что «ИИ бесполезен», а в том, что я откинул его на задний план.

Он в проекте есть. Он просто занимается фоновым:

поставляет порядок/такты для CAB,
помогает алгоритму как эвристика,
пересказывает код и панели человеческим языком поверх уже посчитанных ядром чисел,
перебирает детали в /doctor, /explain, /agent.

По сути я собрал агентного мини‑ИИ для Эльбруса на той же Qwen: один llama-server на unix‑socket, база — для чата, LoRA — для плана, офлайн‑фолбэк с детерминированным ответом, если весов нет. Ядро считает, модель формулирует… Живая заливка решетки токенами, trace для разбора, --raw/--pure для аудита.

И он ждет большое железо.

Если у вас или у меня появится ПК/сервер помощнее, больше ресурсов — туда можно встроить модель поумнее, которая, возможно, справится лучше всяких алгоритмов. Будет ли это прорывом — я не знаю.
Но проект это позволяет: реализуете Scheduler(kind="learned") через те же encode_prompt/decode_completion, кладете адаптер в training/checkpoints/, GGUF в vendor/models/ — и compare/explain/bench/CAB подхватят без правок ядра. Сделаете модель бухгалтером — отлично. Не выйдет — откатитесь к помощнику одной строкой флага /learned --cab.

Пропорция смешивания трудных графов (DIV 20% против единиц процентов в реальном lcc), словарь реала, обрезка контекста 4096 — все это отдельные решения, которые еще предстоит принять. Лучше принимать их вместе.

Финал:

[Проект оупенсорс] модульный монолит, а не комбайн

Я специально не делал микросервисы и плагины ради плагинов. Внутри — модульный монолит:

vliw/core/     # чистый домен. Никаких print, никакого UI
vliw/cli.py    # Session, кэш, команды
vliw/ui/       # plain-рендер для терминала
vliw/tui/      # полноэкранный Textual
vliw/agent/    # разговорный агент поверх уже посчитанного
vliw/learned/  # LoRA-трек, опциональный
training/ tools/ examples/probes/ docs/

Ядро не знает про интерфейс. Оба рендера читают один Session.results():

# vliw/cli.py:197
def results(self):
    # (scenario, profile, width) -> (baseline, oracle, metrics)

Хочешь свой планировщик — реализуешь один протокол:

# vliw/core/api.py — ЭТО ТОЧКА ПОДСТАНОВКИ МОДЕЛИ
class Scheduler(Protocol):
    name: str; kind: str; short: str
    def schedule(self, dag: DAG, model: MachineModel) -> SchedulingResult: ...

kind = "heuristic" — жадный, "exact" — оракул, "learned" — модель. Весь остальной код — валидация, метрики, /compare, /explain, визуализация — не меняется.

Хочешь свою машину — не правишь планировщики:

MachineModel(name="my-e2k", ops={...}, ports=[...])
PROFILES["my"] = my  # или get_profile("e2k-v6-measured").with_width(3)

pyproject.toml честный: dependencies=[]. Ядро работает на голом Python 3.10. tui=[rich,textual], learned=[torch,transformers,peft] — только extras. Команды стандартные: run, load, compare, doctor, bounds, path, analyze, all, scenarios, sweep, selfcheck.

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

Исходный код прототипа: https://github.com/smworklair/NEX‑CLI‑x-Elbrus
Веса LoRA: https://huggingface.co/Shmonika/nex‑vliw‑lora