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

LOTIS, «Шпионка» и кризис среднего возраста

O-Planet — Thu, 30 Apr 2026 14:04:15 +0000

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

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

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

Вопросы могут быть самыми разными: Это на улице или в помещении? Это для детей или взрослых? Можно ли на этом ездить? Это едят? И т.д.

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

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

Потыкать кнопочки можно вот по этой ссылке: http://www.o-planet.ru/alias/

Для любителей английских версий: http://www.o-planet.ru/aliasen/

Чем моя реализация отличается от других

Прежде всего тем, что это сетевая игра с каким-то несложным, но приятным интерфейсом. Но не только этим.

Упрощенный вход

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

Ведущий

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

Чат

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

Мерлин

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

Оформление

Не пинайте сильно, оно достаточно топорное. Но определенно лучше, чем та игра на минималках. Для убийства времени в компании вполне сойдет. И вообще, теперь это не «шпион», а «шпионка». А тем, кто знает, откуда эта милая девушка на заставке – отдельный респект!

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

https://github.com/O-Planet/alias-spyfall-php

И, да, все это сделано за вечер с помощью LOTIS

Summ3r 0f h4ck 2026: стажировка в DSEC by Solar

Thu, 30 Apr 2026 14:01:58 +0000

Выявить уязвимость до того, как ею воспользуются злоумышленники, разобраться в тонкостях безопасности информационных систем, освоить инструменты пентестеров под руководством опытных наставников — всё это можно попробовать на практике на стажировке в DSEC by Solar. Ждем ваши заявки до 10 мая!

DSEC (бывш. Digital Security) присоединилась к «Солару» в 2024 году. Команда проводит детальные исследования систем и сервисов в форматах тестирования на проникновение, анализа защищенности, Red Team и Purple Team. В компании работают опытные специалисты с практическим опытом и сертификатами ИБ-программ, участники конференций, Bug Bounty, открыватели CVE- и других уязвимостей.

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

А лучшие стажёры даже смогут получить оффер в компанию.

Кому подойдёт стажировка?

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

Как стать стажёром?

Если вам уже есть 18 лет, то вы можете подать заявку до 10 мая включительно. Заявка состоит из двух частей: анкеты и нескольких практических задач, которые надо решить. Без выполнения заданий кандидаты на стажировку не рассматриваются.

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

Как проходит стажировка?

Summ3r 0f h4ck 2026 пройдет с 1 июля по 28 августа 2026 года в офисе команды в Санкт‑Петербурге. Если вы из другого города, есть возможность присоединиться онлайн. Стажировка оплачивается.

Вы выберете интересующее направление обучения — проверка сервисов и интерфейсов на уязвимости (Web+mobile) или анализ внутренней и внешней инфраструктуры.

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

Summ3r 0f h4ck 2026 — это возможность получить опыт и начать карьеру в кибербезопасности! По всем вопросам пишите на почту: summerofhack@dsec.ru

Дорогой защитный аппарат: тревога, одиночество и статусная гонка как цена «я»

aeremenok — Thu, 30 Apr 2026 13:49:18 +0000

Знакомая паника

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

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

Если копнуть — а копать придётся к двум ныне забытым авторам, Борису Фёдоровичу Поршневу и Джулиану Джейнсу, — выяснится неудобное. То, что мы пытаемся защитить от LLM, возможно, не является ни базовой константой человека, ни вершиной эволюции, ни даже особенно удачным изобретением. Это конкретная историческая конструкция, собранная для решения конкретной задачи. Задача может исчезнуть. Конструкция тогда тоже исчезнет. И, возможно, об этом будут жалеть не больше, чем сейчас жалеют о потерянной способности слышать богов.

Минимальный ликбез

Поршнев («О начале человеческой истории», 1974) и Джейнс («The Origin of Consciousness in the Breakdown of the Bicameral Mind», 1976) работали независимо и пришли к похожему выводу: то, что мы называем своим внутренним «я», — позднее историческое образование, а не биологическая данность.

У Поршнева это цепочка суггестия → контрсуггестия → контр-контрсуггестия. Слово возникло как командный сигнал: один организм через звук запускает или тормозит поведение другого. Это суггестия. Постоянное подчинение чужому слову биологически невыносимо — у вас есть собственные сенсорные сигналы, которые с ним конфликтуют. Развивается контрсуггестия: фильтры недоверия к источнику, способность не подчиниться, отстаивание собственной правды. Это и есть зародыш «я» — точка сопротивления чужой команде. Дальше суггестор отвечает усложнением (риторика, ритуал, идеология) — это контр-контрсуггестия. Так разворачивается вся история коммуникации.

На нулевом шаге у Поршнева стоит не «обозначение», а интердикция — запрет, сигнал, тормозящий действие сородича. Семантика «о мире» возникает поздно, как надстройка над прагматикой «над тобой». Передаточный механизм — имитация: один демонстрирует, другой воспроизводит; в современных терминах это зеркальные системы и motor resonance. На этой имитативной инфраструктуре собирается удержание двух противоположных состояний в одном акте — Поршнев называет это дипластией («то же и не то же», «запрещено и предписано»), и без неё не получается ни символа, ни понятия. Главное следствие — интерпсихическая природа «я»: оно не сидит внутри отдельного черепа, а собирается в зазоре между «мы» и «они», между подчинением и сопротивлением. Робинзон-картезианец, мыслящий в одиночку, у Поршнева невозможен в принципе — без чужого слова не из чего собирать своё.

Борис Фёдорович Поршнев

У Джейнса версия более экзотическая. До какого-то момента в истории человек не имел интроспективного «я» в нашем смысле. Решения принимались, но переживались как голос — бога, царя, предка. То, что мы сегодня называем мыслью, тогда звучало как чужая речь. Сильную версию большинство специалистов не принимают. Слабая, в редакции Скотта Александера, выглядит так: Джейнс нашёл реальный сдвиг, но не в самом сознании, а в theory of mind и лексической инфраструктуре самоописания. Раньше люди не описывали внутреннее как пространство с наблюдателем — а потом начали. Это и есть «изобретение интроспекции».

Julian Jaynes at his Prince Edward Island home (From Richard Rhodes article in Omni, ~1978)

Живая иллюстрация — племя пираха в бассейне Амазонки, описанное лингвистом Дэниелом Эвереттом («Don’t Sleep, There Are Snakes», 2008). У пираха нет художественной литературы, почти нет ритуалов, нет мифов о происхождении мира — но есть постоянное взаимодействие с духами, которых они описывают не как метафору, а как конкретный факт повседневности. В прологе книги Эверетт описывает сцену: вся деревня собирается на берегу реки, кричит и показывает на пустой песок, утверждая, что именно там сейчас стоит названный по имени дух. Эверетт и его дети не видят ничего. Для пираха «дух на берегу» — такая же объективная данность, как ягуар или каноэ; для Эверетта — галлюцинация коллектива. Это не «недочеловеческое мышление», а другой режим самоописания: то, что наша культура поместила бы во внутреннее пространство как «мысль» или «образ», их культура размещает во внешнем мире как «существо». Сильную версию Джейнса пираха не подтверждают (theory of mind у них работает, обмануть друг друга они умеют), но слабую иллюстрируют идеально: лексическая инфраструктура самоописания не универсальна, и от её настройки зависит, где проходит граница «во мне / снаружи».

Народ пираха и американский лингвист Дэниел Эверетт

В современных терминах поршневская цепочка переписывается уже без павловской физиологии: shared intentionality (Tomasello), epistemic vigilance (Sperber), source-monitoring и predictive coding в self-monitoring (Frith, Fernyhough, Friston). Имена другие, структура та же. Контрсуггестия — это инвариант любой коммуникации, в которой есть две стороны с возможно расходящимися интересами.

«Я» как middleware

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

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

Поэтому Поршнев формулирует радикально: «я» рождается как точка сопротивления. Декартово «мыслю — значит существую» он бы переписал как «не подчиняюсь — значит существую».

У этой конструкции есть характерные побочные эффекты — на них и посмотрим.

Цена решения

У контрсуггестивного «я» есть штатные издержки. Не баги, а архитектурные особенности.

Постоянно работающий middleware ест ресурсы и держит систему в напряжении. Отсюда фоновая тревожность — норма, а не патология современности. Тревожные расстройства распространены в районе четверти-трети населения в высокодоходных странах; депрессия — массовое явление; нарциссические синдромы превратились в культурную тему. Экзистенциальное одиночество — структурное следствие конструкции «я-через-границу-с-другим»: чем чётче граница, тем плотнее изоляция. Статусная гонка — производная от того, что в любой коммуникации мы автоматически считываем иерархию суггесторов. Хроническое недоверие к словам — побочный продукт того, что без него мы бы стали игрушкой первого встречного манипулятора.

Это не плохо и не хорошо. Это её цена. Не «я-как-достижение», а «я-как-постоянно-работающий-защитный-аппарат, который дорог в обслуживании».

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

Что делает LLM-посредник

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

Возникало. И вот его структура.

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

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

Контрсуггестивный middleware, заточенный на «кто это говорит и что ему от меня нужно», теряет цель. Никто не нападает — защищаться не от кого. На уровне ощущений это переживается двойственно: с одной стороны, блаженно (никто не унижает, не давит, не претендует на власть), с другой — тревожно («что-то не так, источник не определяется, я не понимаю, на что реагирую»).

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

Все эти сценарии делают одно и то же на структурном уровне: рассеивают суггестора до неузнаваемости. Сигнал приходит без следов тела, статуса, интереса, эмоции. Source-monitoring коллапсирует — чьи мысли вы сейчас читаете, не определяется. Контрсуггестивный middleware простаивает.

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

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

Историческая параллель

Когда греки догомеровского времени описывали свои переживания, они говорили не «я подумал», а «θυμός велел мне» (что-то вроде «дух в груди»), не «я разозлился», а «μένος наполнил меня». Боги вмешивались в их действия — не метафорически, буквально: Афина схватила Ахилла за волосы, чтобы он не убил Агамемнона.

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

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

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

Нет оснований полагать, что переход «контрсуггестивное-я → что-то-после» будет переживаться как-то существенно иначе. Болезненно — да. Катастрофически — вряд ли.

«Но это будут уже не люди»

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

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

По джейнсовской оси граница «человеческого» сдвигалась всю историю. Гомеровский грек описывал себя через органы тела и внешних богов; шумер — через ушедшее присутствие; современный человек — через ментальные пространства и внутренние состояния. Поколение Z уже частично описывает себя через распределённую медиа-сигнатуру — фаундер дейтингового стартапа Schmooze формулирует это прямо: «для поколения Z мемы — это окно во внутреннее Я». Будущий пользователь LLM-посредников — возможно, через поле «я+мои-модели». Это разные режимы самоописания, и переход от одного к другому не превращает ни предыдущего носителя в не-человека, ни следующего — в пост-человека. Меняется лексическая инфраструктура, не онтология.

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

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

Нынешнее «я» — последняя на сегодня позиция в этом ряду. Не финальная.

Куда уходит гонка

Хэппи энда рисовать не будем.

Та гонка, о которой шла речь выше, не заканчивается. Она меняет участников.

Если индивидуальное «я» рассеивается под LLM-посредничеством, это не значит, что суггестивная асимметрия исчезает. Она просто перетекает на другой уровень: владелец инфраструктуры → пользовательская популяция. Тот, кто настраивает модели, получает суггестивный канал, на который у пользователя нет контрсуггестивного аппарата — потому что аппарат был заточен на людей, а не на инфраструктуру.

Дальше варианты:

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

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

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

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

Финал

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

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

Возможно, раунд заканчивается. Возможно, начинается следующий, в котором роли распределены иначе. И «человек», которого защищают паникующие треды, окажется в нём примерно тем же, чем гомеровский герой со своим θυμός оказался для нас: предком, узнаваемым, любопытным, но больше не нами.

Если так — это не катастрофа. Это окончание раунда. Возможно, не самого удачного.

И - неиронично предлагает ИИ-шка, с которой я оформлял эту статью:

И провокация даже не в том, что нам не должно быть жалко.

Провокация в том, что, возможно, не очень-то и жалко уже.

Больше историй об айти и географии у меня в тг

MAX и метка Spyware в Cloudflare: что это значит и к чему может привести

DevRoad — Thu, 30 Apr 2026 13:48:26 +0000

30 апреля в сети появилась информация, что глобальная IT-компания и оператор крупной интернет-инфраструктуры Cloudflare присвоила домену национального мессенджера Max классификацию Spyware (шпионское ПО). Прежде чем мысленно ухмыльнуться и подумать «а я же говорил», давайте объективно разберемся, что это за шум.

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

Что такое Cloudflare

Cloudflare — американская интернет-инфраструктурная компания. Она появилась в 2009 году, а публично запустилась в 2010-м. Основатели компании — Мэтью Принс, Мишель Затлин и Ли Холлоуэй. Изначальная идея проекта описывалась как firewall in the cloud, то есть «фаервол в облаке»: система, которая помогает сайтам и приложениям защищаться от вредоносного трафика и при этом работать быстрее.

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

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

Какие функции выполняет Cloudflare

Если объяснять просто, Cloudflare — это сервис, который помогает сайтам и приложениям работать быстрее, стабильнее и безопаснее.

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

Ускорение загрузки сайтов и приложений через CDN. CDN — это Content Delivery Network, или «сеть доставки контента». Проще говоря, это сеть серверов в разных странах и городах, где могут храниться копии картинок, видео, файлов, скриптов и других элементов сайта. Пользователь получает их не с одного далекого сервера, а с ближайшей точки Cloudflare. Поэтому сайт или приложение могут открываться быстрее.

Публичный DNS-сервис 1.1.1.1. DNS — это «адресная книга интернета». Когда пользователь вводит адрес сайта, например example.ru, DNS помогает устройству понять, к какому серверу нужно обратиться. Cloudflare предоставляет свой публичный DNS-сервис 1.1.1.1, который используется для быстрого и относительно приватного поиска таких адресов.

Web Application Firewall, или WAF. Firewall — это «сетевой экран», то есть защитный фильтр. А Web Application Firewall — это фильтр именно для сайтов, приложений и API. Он проверяет HTTP-запросы. HTTP-запрос — это обычный запрос браузера или приложения к серверу: открыть страницу, получить профиль, отправить форму, загрузить сообщение. Например, нормальный запрос может выглядеть так:

🔹 GET /profile?id=123

А подозрительный — так:

🔹 GET /profile?id=1%20OR%201=1--

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

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

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

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

Что такое Cloudflare Gateway

Gateway — это корпоративный фильтр интернета от Cloudflare. Он стоит не перед сайтом, а перед пользователем компании. Например, сотрудник открывает сайт или приложение, а Gateway проверяет: можно ли туда идти?

🔹Сотрудник → Cloudflare Gateway → сайт / приложение

Компания может настроить правила:

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

Если сотрудник открывает домен, который Cloudflare относит к категории Spyware, Gateway может заблокировать доступ или показать предупреждение.

Именно для таких продуктов Cloudflare и ведет классификацию доменов. Ей нужен список: какие домены относятся к мессенджерам, какие — к соцсетям, какие — к рекламе, какие — к фишингу, какие — к вредоносному ПО.

Что за реестр ведет Cloudflare

Cloudflare ведет собственную систему категоризации доменов — Domain Categorization. Посмотреть категории конкретного домена можно через Cloudflare Radar (https://radar.cloudflare.com/ru-ru/domains/domain/example.ru)

Категории делятся на два больших типа:

Content categories — это обычные тематические категории. Например: мессенджеры, соцсети, новости, реклама, развлечения, игры, финансы, образование, взрослый контент.

Security categories — это категории, связанные с рисками и угрозами. Например:

Malware — сайты, связанные с вредоносным ПО;
Phishing — фишинговые домены, которые могут красть логины, пароли или платёжные данные;
Spyware — домены, связанные со шпионским ПО;
Command and Control / Botnet — домены, к которым обращаются зараженные устройства;
Compromised Domain — легитимный домен, который был взломан и использован для вредоносной активности;
DNS Tunneling — подозрительная передача данных через DNS-запросы.

Домены категоризирует Cloudforce One — threat intelligence-подразделение Cloudflare, то есть команда/платформа по анализу киберугроз.

Что такое Spyware

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

Это может быть:

Сбор данных об устройстве — например, информации о модели телефона, операционной системе, настройках сети, IP-адресе, идентификаторах устройства или других технических параметрах.
Отслеживание активности пользователя — если приложение или связанные с ним домены передают данные о действиях пользователя чаще или шире, чем это необходимо для работы сервиса.
Передача телеметрии на сторонние серверы — телеметрия сама по себе не всегда опасна: многие приложения собирают технические данные о сбоях и производительности. Вопросы возникают, если такая передача непрозрачна, чрезмерна или идет на подозрительные домены.
Доступ к чувствительной информации — например, к контактам, файлам, геолокации, данным об устройстве или другим сведениям, которые неочевидно нужны для основной функции приложения.
Скрытая сетевая активность — если через DNS-запросы или корпоративные фильтры вроде Gateway фиксируются обращения к подозрительным серверам, не связанным напрямую с работой мессенджера, например с чатами, звонками или авторизацией.
Аномальные DNS-запросы — DNS — это служба, которая переводит понятные адреса сайтов в IP-адреса серверов. Подозрения могут возникать, если приложение регулярно обращается к странным, недавно созданным или уже замеченным в угрозах доменам.
Поведение, похожее на наблюдение или слежку — например, когда приложение собирает больше данных, чем ожидает пользователь, делает это без понятного объяснения или передает информацию так, что ее назначение трудно проверить.

Но важно: когда Cloudflare ставит домену категорию Spyware, это не всегда означает, что все приложение уже доказано является шпионским.

По каким признакам Cloudflare может поставить такую метку

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

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

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

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

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

То есть сейчас есть сам факт метки Cloudflare и есть объяснение со стороны сервиса. Окончательный технический вывод без независимого аудита делать рано.

Что может произойти с MAX после такой метки

Сама по себе метка Cloudflare не означает автоматического удаления приложения из App Store или Google Play. Она также не означает, что TLS-сертификат — цифровое удостоверение домена, которое подтверждает подлинность сайта или сервера и позволяет устанавливать защищенное HTTPS-соединение, — будет обязательно отозван.

Во-первых, домен могут начать блокировать корпоративные сети. Если компания использует Cloudflare Gateway и настроила правило «блокировать Spyware», доступ к max.ru может быть ограничен.
Во-вторых, у сервиса может появиться репутационный риск. Для пользователей и ИБ-специалистов метка от Cloudflare — это повод внимательнее посмотреть на приложение, его домены, сертификаты, сетевые запросы и политику обработки данных.
В-третьих, возможны дополнительные проверки со стороны магазинов приложений. Apple и Google могут проверять приложения на соответствие требованиям безопасности и приватности. Apple прямо пишет, что приложения проходят review, а App Store должен оставаться безопасным местом для пользователей.
В-четвертых, внимание могут обратить удостоверяющие центры, которые выдают TLS-сертификаты. Если они увидят основания для проверки, они могут запросить объяснения или провести собственную оценку.
В-пятых, вокруг сервиса может усилиться внимание со стороны исследователей безопасности, журналистов, регуляторов и пользователей (~~хотя, казалось бы, куда уж больше~~).

Пример Telega: почему историю с MAX начали сравнивать именно с ней

Параллель с Telega возникла не случайно. Telega — альтернативный клиент Telegram — ранее тоже получил метку Spyware у Cloudflare. Речь шла о рабочих доменах проекта, в том числе telega.me и api.telega.info. По сообщениям СМИ, это произошло 9 апреля 2026 года. В тот же день Telega исчезла из App Store, при этом в Google Play и RuStore приложение оставалось доступно.

По данным Meduza со ссылкой на «Осторожно, новости», после метки Cloudflare у Telega также был отозван TLS-сертификат — цифровое удостоверение домена, которое нужно для защищенного HTTPS-соединения. Предположительно, именно это могло стать одним из факторов удаления приложения из App Store.

Через несколько дней разработчики Telega заявили, что Cloudflare сняла классификацию Spyware с доменов проекта, включая telega.me, api.telega.info и telega.info. Однако возвращения в App Store это сразу не обеспечило. Отдельный этап начался 17 апреля 2026 года: пользователи iPhone начали сообщать, что iOS помечает уже установленную Telega как потенциально вредоносное приложение, блокирует запуск и предлагает удалить его.

Эта история важна как пример возможной цепочки:

🔹Метка Cloudflare → внимание к доменам → проблемы с сертификатами → вопросы со стороны Apple → удаление или блокировка приложения

Но это не значит, что с MAX обязательно произойдет то же самое. У MAX, по сообщениям СМИ на момент публикации, есть действующий TLS-сертификат, а приложение на данный момент доступно в App Store и Google Play.

Что все это значит для пользователей

Главное — не путать три разные вещи.

Первое: Cloudflare Radar действительно может показывать домен в категории Spyware. Это серьезный сигнал, потому что Cloudflare — крупный игрок в интернет-безопасности.

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

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

Заключение

История с MAX и Cloudflare — это не приговор, но и не мелочь, которую можно полностью игнорировать.

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

Но важно сохранять точность. Cloudflare не вынесла судебное решение, не запретила MAX и не доказала публично, что приложение является шпионским ПО. Она классифицировала домен max.ru в своей системе как Spyware. Это может привести к блокировкам в корпоративных сетях, дополнительным проверкам, вопросам к сертификатам и вниманию со стороны магазинов приложений. Но само по себе это еще не означает автоматического удаления приложения или официального признания его вредоносным.

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

EIP-7702: прикручиваем код к EOA, где можно споткнуться?

pnaydanovgoo — Thu, 30 Apr 2026 13:40:30 +0000

EIP-7702: Set Code for EOAs - это стандарт, который предлагает добавить новый тип транзакции согласно спецификации, описанной в EIP-2718: Typed Transaction Envelope, что позволит к Externally Owned Accounts (EOAs) прикрепить код смарт-контракта.

EIP-7702 является следующим шагом в области абстракции аккаунта в рамках обновления Ethereum под названием "Pectra".

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

Делегирование вызова для EOA cо смарт-контрактом

У сущности аккаунт в Ethereum всегда существовало поле code. Только раньше, для EOA, это поле оставалось пустым, а для смарт-контракта там находился байткод.

Теперь для EOA, в поле code, записывается адрес прикрепляемого смарт-контракта со специальным префиксом (0xef0100 || address). По сути, префикс - это некоторое магическое значение, которое позволяет четко определить, что это адрес для делегирования, а не байт-код смарт-контракта.

Глобально, EIP-7702 нацелен на улучшение UX приложений за счет небольших изменений внутри Ethereum. При помощи стандарта могут решаться следующие задачи:

Батчинг транзакций: Объединение нескольких атомарных операций внутри одной транзакции. Например, approve и трансфер в одной транзакции. Это то чего так долго ждали пользователи кошельков.
Безгазовые транзакции или спонсирование: Оплата газа сторонним аккаунтом или возможность оплачивать газ в ERC-20 токене. Это позволяет улучшить опыт использования кошельков новыми пользователями, у которых еще нет нативной валюты для оплаты газа.
Управление ролями и доступом: Выдача разрешений на управление аккаунтом третьим лицам.
Механизмы восстановления доступа: Может быть реализован вывод активов или резервный адрес, который сможет управлять активами кошелька.
и так далее.

Транзакция для прикрепления кода

В этом разделе разберем из чего состоит транзакция, которая прикрепит смарт-контракт к EOA.

Тело транзакции похоже на любой другой тип транзакции согласно EIP-2718: Typed Transaction Envelope:

TransactionType - тип транзакции равен 0x04.
TransactionPayload - кодированные данные отличаются тем, что добавляется новое поле authorization_list.

Структура транзакции для прикрепления смарт-контракта

Поле authorization_list - это tuple, который определяется как:

authorization_list = [[
  chain_id, // Идентификатор сети, для которой делегирование актуально
  address, // Адрес смарт-контракта куда будет делегироваться вызов
  nonce, // Текущий nonce EOA
  y_parity, // Данные подписи EOA аккаунта
  r, // Данные подписи EOA аккаунта
  s // Данные подписи EOA аккаунта
], ...]

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

Поэтому тут важно понимать, что если chain_id в authorization_list передать равным 0, то это будет означать, что EOA разрешает использовать транзакцию во всех EVM-совместимых сетях, поддерживающих EIP-7702.

Интересные моменты

Для того, чтобы подпись, разрешающая прикрепление EOA, была валидна в нескольких сетях, необходимо, чтобы nonce был одинаковым в этих сетях, иначе подпись будет невалидна для какой-то из сетей. Это может быть удобно, если создается новый аккаунт, владелец дает всего одну подпись для того, чтобы привязать код к EOA сразу в нескольких сетях.
Поле authorization_list в транзакции может содержит список данных, подписанных несколькими разными EOA. При этом инициатором транзакции может быть третья сторона, что позволяет реализовать безгазовое прикрепление кода смарт-контракта к нескольким EOA.
Для того, чтобы снова сделать свой EOA обычным (открепить смарт-контракт) достаточно установить поле address в authorization_list в значение 0.
Если один из элементов списка authorization_list невалидный, то он пропускается, валидные элементы списка применяются, транзакция не откатывается.

Как это работает для пользователя

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

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

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

Прикрепление кода к аккаунту позволит пользователю получить больше функций.

Встретить подобное можно уже сейчас, например, Metamask встроил EIP-7702 в свою фичу "Smart Account". Для этого Metamask разработал свои собственные смарт-контракты, то есть пользователь переводя свой EOA на Smart Account, будет делегировать выполнение смарт-контрактам от Metamask.

Metamask предлагает умные аккаунты

Metamask: подтверждение перехода на умный аккаунт

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

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

function signDelegation(address implementation, uint256 privateKey)
    external
    returns (SignedDelegation memory signedDelegation);

function attachDelegation(SignedDelegation calldata signedDelegation) external;

function signAndAttachDelegation(address implementation, uint256 privateKey)
    external
    returns (SignedDelegation memory signedDelegation);

Эти Cheatcodes позволяют подписывать транзакцию по прикреплению кода к EOA (signDelegation) и отправлять транзакции в сеть (attachDelegation) прямо в тестах.

Для того, чтобы EIP-7702 работал, необходимо убедиться, что компилируется код для evm версии не ниже "prague". Это может быть определено в foundry.toml.

// foundry.toml
evm_version = "prague"

Таким образом, самый простой пример, который прикрепит код к EOA будет выглядеть в тестах Foundry следующим образом:

// Объявляем StdCheats.Account public user;
...

function test_attachCode() external {
    // Проверяем наличие кода у EOA user
    console.logBytes(user.addr.code); // 0x

    // Симулируем подписание транзакции на прикрепление кода пользователем
    Vm.SignedDelegation memory signedDelegation = vm.signDelegation(address(delegation), user.key);

    vm.startBroadcast(operator.key);

    // Отправляем транзакцию на прикрепление кода к user. Обратить внимание, что это делает operator, а не user
    vm.attachDelegation(signedDelegation);

    vm.stopBroadcast();

    console.logBytes(user.addr.code); //0xef01005615deb798bb3e4dfa0139dfa1b3d433cc23b72f
}

По сути, тест реализует всего два этапа для прикрепления кода.

Шаги по прикреплению кода в тестах Foundry

Полный пример теста test_attachCode в Delegation.t.sol.

Хранилище делегированного смарт-контракта

Хранилище делегированного смарт-контракта, не является доступным для вызовов через EOA.

Более того, конструктор такого смарт-контракта не вызвать в контексте EOA, поэтому нельзя устанавливать данные через конструктор в хранилище в контексте EOA.

Изменение переменных хранилища при вызове остается в контексте EOA. То есть хранилище самого смарт-контракта не будет изменено.

Для проверки работы хранилища реализуем простой смарт-контракт Delegation.sol.

contract Delegation {
    uint256 private _value;

    constructor(uint256 initialValue) {
        _value = initialValue;
    }

    function setValue(uint256 newValue) external {
        _value = newValue;
    }

    function getValue() external view returns (uint256) {
        return _value;
    }
}

В тесте будем работать с хранилищем смарт-контракта напрямую и в контексте EOA:

// Delegation.t.sol
function test_workWithStorage(uint256 value) external {
    // Прикрепляем код смарт-контракта Delegation к EOA user
    ...

    // Step 1. Проверяем, что хранилище user пустое, а смарт-контракта delegation нет

    // Вызов getValue через user вернет 0, так как хранилище user пустое
    assertEq(Delegation(user.addr).getValue(), 0);
    // Вызов getValue через delegation вернет _INITIAL_VALUE, так как хранилище delegation не изменилось и было установлено через конструктор при деплое
    assertEq(delegation.getValue(), _INITIAL_VALUE);

    // Step 2. Устанавливаем значение в хранилище user
    Delegation(user.addr).setValue(value);

    // Вызов getValue через user вернет установленное value
    assertEq(Delegation(user.addr).getValue(), value);
    // Вызов getValue через delegation вернет _INITIAL_VALUE, хранилище не изменилось
    assertEq(delegation.getValue(), _INITIAL_VALUE);
}

Тест показывает, что конструктор смарт-контракта Delegation ничего не установил в хранилище EOA. В целом хранилище EOA и самого смарт-контракта - это разные хранилища.

Работа хранилища смарт-контракта и EOA

Полный пример кода теста test_workWithStorage в Delegation.t.sol.

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

contract Delegation {
    uint256 immutable private _value;

    constructor(uint256 value) {
        _value = value;
    }

    function getValue() external view returns (uint256) {
        return _value;
    }
}

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

function test_workWithStorage(uint256 initialValue) external {
    StdCheats.Account memory user = makeAccount("User");
    StdCheats.Account memory operator = makeAccount("Operator");

    // Деплоим смарт-контракт Delegation
    Delegation delegation = new Delegation(initialValue);

    // Прикрепляем код смарт-контракта Delegation к пользователю
    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegation), user.key);
    vm.stopBroadcast();

    // Проверяем, что хранилище user не пустое
    assertEq(Delegation(user.addr).getValue(), initialValue);
}

Проверки типа msg.sender == tx.origin

Раньше смарт-контракты использовали условие tx.origin == msg.sender для двух вещей:

Проверить, что код выполняется от имени EOA, так как tx.origin не может быть смарт-контрактом.
Защитить от повторного входа. Строится на предположение, что второй вход обязательно выполняется смарт-контрактом.

Важно! Если делегированный смарт-контракт в контексте EOA делает вызов к другому смарт-контракту, то msg.sender равняется адресу EOA. И здесь пока tx.origin равняется msg.sender.

Кто sender на каждом этапе вызова?

На схеме изображен поток вызова от пользователя к смарт-контракту Target через прикрепленный смарт-контракт Delegation. Пользователь подписывает своим приватным ключом вызов на свой же адрес, выполнение делегируется к смарт- контракту Delegation, который вызывает смарт-контракт Target. Во всех случаях адрес пользователя равен msg.sender и tx.origin.

Но теперь, как обойти условие, чтобы tx.origin изменился. EIP-7702 позволяет сделать любую реализацию смарт-контракта. Это означает, что вызывать его может любой другой аккаунт, если не реализовано иное. Таким образом, здесь msg.sender не будет совпадать с tx.origin, если первоначальный вызов будет исходить от стороннего EOA.

Кто sender на каждом этапе вызова?

На схеме, оператор подписывает транзакцию своим приватным ключом, который не совпадает с адресом пользователя. По итогу tx.origin не будет равен msg.sender.

Проверить это легко. Понадобится смарт-контракт Target, который будет позволять устанавливать value только если tx.origin != msg.sender.

// Target
function setValue(uint256 newValue) external {
    if (tx.origin == msg.sender) {
        revert EOACallIsNotAllowed();
    }

    _value = newValue;
}

Прикреплять к EOA будем смарт-контракт Delegation, который будет делать вызов setValue() на смарт-контракте Target.

contract Delegation {
    function setValue(address target, uint256 value) external {
        Target(target).setValue(value);
    }
}

Проверочный тест будет выглядеть следующим образом:

function test_checkCondition(uint256 value) external {
    Vm.SignedDelegation memory signedDelegation = vm.signDelegation(address(delegation), user.key);

    // Симулируем, что пользователь напрямую вызывает целевой контракт и транзакция ревертится
    vm.expectRevert(Target.EOACallIsNotAllowed.selector);
    vm.prank(user.addr, user.addr);
    target.setValue(value);

    // Operator прикрепляет смарт-контракт Delegation к user
    vm.startBroadcast(operator.key);
    vm.attachDelegation(signedDelegation);
    vm.stopBroadcast();

    // Operator вызывает функцию setValue() на контракте Delegation от имени user,
    // которая установит value на смарт-контракте Target
    vm.prank(operator.addr, operator.addr);
    Delegation(user.addr).setValue(address(target), value);

    // Проверяем, что значение установлено (проверка обойдена)
    assertEq(target.getValue(), value);
}

По итогу тест показывает, что вызывать смарт-контракт, прикрепленный к EOA может другой EOA, а соответственно в tx.origin будет другой адрес.

Полный пример теста test_checkCondition в Delegation.t.sol.

Проверка адреса на то, что он смарт-контракт

Больше нельзя полагаться на проверку address(contract).code > 0, которая определяет, что адрес является смарт-контрактом и не является EOA. Теперь EOA с прикрепленным смарт-контрактом тоже возвращает значение больше 0.

Проблемы при определении msg.sender

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

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

assembly {
    // Загружаем код msg.sender
    let ptr := mload(0x40)
    extcodecopy(caller(), ptr, 0, 32)
    let prefix := shr(232, mload(ptr))

    // Проверяем, что prefix == 0xef0100
    isDelegated := eq(prefix, 0xef0100)
}

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

Получение любого вида токена, который требует наличие callback функции, если получатель смарт-контракт

EOA, который прикрепил к себе смарт-контракт, для ERC-721, ERC-777, нативной валюты, начинает вести себя, как смарт-контракт.

Это означает, что EOA не сможет принимать активы, если на прикрепленном смарт-контракте не реализованы функции:

receive() external payable {}

или

function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);

и так далее.

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

Для проверки можно прикрепить к любому аккаунту пустой смарт-контракт Delegation.sol, который не будет реализовывать функцию receive().

contract Delegation {}

Проверочный тест будет выглядеть следующим образом:

function test_checkSendNativeCurrency(uint256 value) external {
    Vm.SignedDelegation memory signedDelegation = vm.signDelegation(address(delegation), user.key);

    // Operator прикрепляет смарт-контракт Delegation к user
    vm.startBroadcast(operator.key);
    vm.attachDelegation(signedDelegation);
    vm.stopBroadcast();

    // Пытаемся отправить нативную валюту, транзакция ревертнется
    (bool success,) = user.addr.call{value: value}(""); // success == false

    assertFalse(success);
}

Полный пример теста test_checkSendNativeCurrency в Delegation.t.sol.

Конфликт переменных хранилища для EOA

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

Коллизия в хранилище

Для проверки это гипотезы поочередно прикрепим два смарт-контракта DelegationFirst.sol и DelegationSecond.sol, которые работают с первым слотом памяти: первый устанавливает uint256, второй bytes32.

contract DelegationFirst {
    uint256 private _value;

    function setValue(uint256 newValue) external {
        _value = newValue;
    }

    function getValue() external view returns (uint256) {
        return _value;
    }
}

contract DelegationSecond {
    bytes32 private _hashValue;

    function setHash(bytes32 hashValue) external {
        _hashValue = hashValue;
    }

    function getHash() external view returns (bytes32) {
        return _hashValue;
    }
}

Проверочный тест будет выглядеть следующим образом:

function test_storageCollision(uint256 value, bytes32 hashValue) external {
    // Прикрепляем первый смарт-контракт
    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegationFirst), user.key);
    vm.stopBroadcast();

    // Устанавливаем значение в хранилище смарт-контракта
    DelegationFirst(user.addr).setValue(value);
    assertEq(DelegationFirst(user.addr).getValue(), value);

    // Прикрепляем второй смарт-контракт
    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegationSecond), user.key);
    vm.stopBroadcast();

    // Устанавливаем hash в хранилище смарт-контракта
    DelegationSecond(user.addr).setHash(hashValue);
    assertEq(DelegationSecond(user.addr).getHash(), hashValue);

    // Прикрепляем первый смарт-контракт повторно
    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegationFirst), user.key);
    vm.stopBroadcast();

    assertNotEq(DelegationFirst(user.addr).getValue(), value); // Доказывает что первоначальное значение было изменено
}

Полный пример теста test_test_storageCollision в Delegation.t.sol.

Что делать с коллизией?

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

Идея заключается в том, что вместо использования последовательных слотов хранения (это работает в Solidity по умолчанию) использовать ERC-7201 Storage Namespaces Explained или другие подобные решения.

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

contract Delegation {
    struct MainStorage {
        uint256 value;
    }

    // keccak256(abi.encode(uint256(keccak256("MetaLampIsTheBest")) - 1)) & ~bytes32(uint256(0xff))
    bytes32 public constant MAIN_STORAGE_LOCATION = 0xd66e0df2d96f7ee8f3c31d9f50f7a36abdf7b3a8a2cbbfbe615a3abcc8b5af00;

    function _getMainStorage() private pure returns (MainStorage storage $) {
        assembly {
            $.slot := MAIN_STORAGE_LOCATION
        }
    }

    function getValue() external view returns (uint256) {
        MainStorage storage $ = _getMainStorage();

        // Получаем значение из хранилища, которое хранится в специальном слоте
        return $.value;
    }
}

Важно! EIP-7201 не защитит, если пользователь прикрепил к своему аккаунту вредоносный смарт-контракт, который будет целенаправленно переписывать определенный слот вашего правильного хранилища.

Также, как никто не застрахован от подписания транзакции, которая прикрепит неизвестный код к EOA.

Работа с нативной валютой

Рассмотрим два случая для аккаунта, который прикрепил себе смарт-контракт:

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

Транзит нативной валюты сквозь payable функции

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

Для проверки это гипотезы прикрепим к пользователю смарт-контракт Delegation.sol.

contract Delegation {
    /// Оставляем нативную валюту на адресе user
    function buy() external payable {}

    /// @notice Пересылаем нативную валюту на смарт-контракт target
    function buyAndSendToTarget(address target) external payable {
        (bool success, ) = target.call{value: msg.value}("");

        if (!success) {
            revert();
        }
    }
}

contract Target {
    // Разрешаем принимать нативную валюту
    receive() external payable {}
}

Проверочных теста будет два:

function test_workWithNativeCurrency_buy(uint256 value) external {
    deal(operator.addr, value);

    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegation), user.key);
    vm.stopBroadcast();

    vm.prank(operator.addr);
    Delegation(user.addr).buy{value: value}();

    // Нативная валюта остается на балансе пользователя
    assertEq(user.addr.balance, value);
}

function test_workWithNativeCurrency_buyAndSendToTarget(uint256 value) external {
    deal(operator.addr, value);

    vm.startBroadcast(operator.key);
    vm.signAndAttachDelegation(address(delegation), user.key);
    vm.stopBroadcast();

    vm.prank(operator.addr);
    Delegation(user.addr).buyAndSendToTarget{value: value}(address(target));

    // Нативная валюта остается на балансе target смарт-контракта
    assertEq(address(target).balance, value);
}

Полный пример тестов test_workWithNativeCurrency_buy и test_workWithNativeCurrency_buyAndSendToTarget можно найти в Delegation.t.sol.

Совместимость

Один из самых интересных моментов, как EIP-7702 будет чувствовать себя с предыдущими решениями по абстракции аккаунта, в частности с ERC-4337.

На удивление очень хорошо! Все, кто имел абстрактные аккаунты на базе ERC-4337, могут продолжать использовать их. Дело в том, что для ERC-4337 не принципиален инициатор транзакции, достаточно того, чтобы критерии проверки (подпись user operation) были валидны.

В свою очередь, ребята из eth-infinitism практически сразу предложили вариант аккаунта в котором в одной связке работают ERC-4337 и ERC-7702. Первый стандарт для спонсирования газа, второй для батчинга операций.

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

contract Simple7702Account is BaseAccount, IERC165, IERC1271, ERC1155Holder, ERC721Holder {
    /// Адрес entrypoint, который может вызывать транзакции на аккаунте пользователя
    function entryPoint() public pure override returns (IEntryPoint) {
        return IEntryPoint(0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108);
    }

    /// Здесь будет проверяться, что операция подписана приватным ключом пользователя
    function _validateSignature(
        PackedUserOperation calldata userOp,
        bytes32 userOpHash
    ) internal virtual override returns (uint256 validationData) {

        return _checkSignature(userOpHash, userOp.signature) ? SIG_VALIDATION_SUCCESS : SIG_VALIDATION_FAILED;
    }

    ...
}

Схематично работа ERC-4337 и EIP-7702 представлена на схеме ниже.

ERC-4337 & EIP-7702

Пользователь делегирует выполнение Simple7702Account (прикрепляет код этого смарт-контракта). После этого он может подписывать данные об операциях и через bundler передавать их на выполнение.

Полный пример такого аккаунта.

В EIP-7702 вцепились все заинтересованные в абстракции: viem, metamask, ZeroDev, Biconomy, Alchemy, Trust Wallet, Ambire и другие. Они так или иначе интегрировали EIP-7702 в свои решения, поэтому референсных имплементаций достаточное количество.

Etherscan

Etherscan тоже молодец и сразу поддержал EIP-7702. Для этого он вывел все транзакции четвертого типа на отдельную страницу.

Etherscan: отображение Delegated Address

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

Etherscan: отображение Delegated Address внутри транзакции

Увидеть, что транзакция выполнялась на прикрепленном смарт-контракте можно и в отдельном поле "Delegated Address", а увидеть тип транзакции в поле "Other Attributes".

Etherscan: поле Other Attributes

Недостатки

Нужно понимать, что EIP-7702 не является реализацией полной абстракции аккаунта, он не преобразует EOA в "Умный самодостаточный аккаунт".

С точки зрения абстракции аккаунта, EIP-7702 имеет ряд ограничений:

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

Вывод

Таким образом, EIP-7702 является важным, стратегическим шагом на пути к абстракции аккаунта, привносит новую энергию в экосистему Ethereum и позволяет внедрять новые сценарии. Как абстракция аккаунта будет выглядеть в будущем одному Виталику известно.

Также не стоит забывать ключевые проблемы:

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

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

Links

Ethereum Improvement Proposals: EIP-7702: Set Code for EOAs
EIP-7702 от Cyfrin
Solidity и Ethereum, урок #93 | EIP-7702: EOA code. Видео от Ilya Krukowski. Здесь практический опыт использования EIP-7702 со стороны смарт-контрактов
In-Depth Discussion on EIP-7702 and Best Practices от SlowMist. Здесь больше со стороны того, как это работает в Ethereum
Документация viem
What You Need to Know About EIP-7702 “Smart” Account от etherscan
Deep Dive into Ethereum 7702 Smart Accounts: security risks, footguns and testing
Emergency EIP-7702 Wallet Recovery. История о том, как случайное делегирование позволило увести активы с кошелька.
EIP-7702 overview
EIP7702: Closing the Gap Between EOAs and Smart Contracts. Здесь интересен исторический обзор, как эволюционировали стандарты в области абстракции аккаунтов.
Awesome EIP-7702. На случай, если нужно еще больше материалов

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

Анализ защищенности 15 лет спустя. Акт первый

Thu, 30 Apr 2026 13:36:14 +0000

Всем привет! Меня зовут Сергей и я директор Центра Исследования Киберугроз в Angara Security. Занимаюсь и руковожу пентестами и редтимами всю свою сознательную ИБ-карьеру.

Хочу с вами, наши дорогие и уважаемые читатели, поделиться своими мыслями насчет подмены понятий в услугах по анализу защищенности. Очень часто я видел (да и сейчас часто вижу), как пентест называют "сканированием уязвимостей" или в понятие Red Team закладывают самый обычный пентест, пусть и с элементами "противодействия".

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

Спойлер для тех, кто все-таки хочет вдаться в подробности мотивации

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

Суровые будни лида пентестеров...

Слева - мой давний товарищ и очень зрелый эксперт из Defensive Secuirty, от которого такой вопрос получить было, мягко говоря, неожиданно. Справа - рабочий чат с одним из клиентов в процессе проекта. Несмотря на отсутствие контекста, суть проблемы эти переписки отражают. Я бы понял и не обращал на это внимание, если бы это был 1 случай на 20-30 проектов. Но такое встречается с завидной регулярностью по сей день.

С одной стороны, это может быть не критично. Особенно, когда и заказчик и исполнитель ожидают от работ одного и того же. С другой стороны, такая "синхронизация" встречается не так часто, как хотелось бы. И это приводит не просто к недопониманию на уровне оперативного общения, а скорее и чаще к тому, что одна сторона (заказчик) ожидает одного результата, а другая сторона (исполнитель) выдает совсем другой результат. А иногда это "недопонимание" происходит на уровне анализа ТЗ и пресейла. Одни не понимают, почему это стоит дороже и проводится дольше ожидаемого, а другие не понимают почему условия в ТЗ противоречат сложившейся практике или что хочет от них заказчик в принципе. В конечном итоге никто не получает желаемого.

В связи с этим у меня (и не только) возникает непреодолимое желание рассказать миру, как все-таки понять этот нелегкий мир услуг offensive security, выделить для себя отличия в этих услугах и сделать вывод о пользе того или иного подхода, решая свои задачи. Конечно же, я далеко не первый (и не последний), кто пытается сделать то же самое. В сети есть определенное количество крутых статей, подкастов, видео-материалов, где так или иначе рассказывается все то же самое, и мои коллеги с «красной стороны» действительно сделали крутую работу, недооценивать которую я не хочу и не имею права (привет и респект ребятам из PT, Kaspersky, BI.Zone, Cicada8, УЦСБ, Singleton и множества других компаний). Вместе с этим, в каждом из этих материалов так или иначе (как минимум мне) не хватает каких-то нюансов для охвата всей картины: где-то техники, где-то организационки, где-то банальной базы, потому что расчет был на достаточно зрелую аудиторию. И чтобы сложить всю картину у себя в голове, нужно не только пересмотреть/перечитать/послушать все, но и местами даже самому заняться изучением вопроса. Это драгоценное время, которое у нас всегда в дефиците.

Начать цикл статей я бы хотел с цитаты французского мыслителя Вольтера:

Вольте́р, Франсуа́-Мари́ Аруэ́

французский писатель и философ, один из главных представителей просветительской мысли XVIII века

«Тот, кто не знает прошлого, не знает ни настоящего, ни будущего, ни самого себя»

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

Итак, поехали!

История offensive-услуг

Вернемся в (уже) далекий конец 00-х, начало 10-х годов 21 века. Информационная безопасность только набирала обороты, пентест как таковой еще не был так популярен как сейчас. Предлагали эту услугу немногие компании (навскидку я вспомнил только Информзащиту, ДиалогНаука, и Диджитал Секьюрити), а о внутренних пентест-командах в крупных компаниях было известно чуть меньше, чем ничего. Качество работ определялось уровнем энтузиазма пентестеров и количеством выполненных проектов. Усредненный процесс пентеста (например, внутреннего) на тот момент был примерно следующим:

Приезжаем на объект;
Проводим сетевые атаки типа ARP Spoofing или VLAN-hopping. Может быть, если кто-то был знаком с Responder (да-да, первый коммит на Github датируется аж 12 февраля 2013 года) - NBT-NS/LLMNR spoofing;
Запускаем легендарный «сине-зеленый» сканер уязвимостей или пресловутый Xspider на все доступные подсети;
Cмотрим результаты:
- Нашлось что-то? Супер, пробуем это эксплуатировать, вручную считаем CVSS, думаем над рекомендациями;
- Не нашлось - штош, идем писать про «Уровень защищенности - высокий»;

Примерный флоу любого внутряка тех времен

Спойлер для тех, кто мог бы обидеться...

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

С внешним пентестом было примерно то же самое, только вышеупомянутый сканер дополнялся еще одним «бело-красным» сканером версии 10.5 для веб-приложений (помните, как он стал клиент-серверным?). Атаки на Kerberos? AD CS? Kubernetes? Нет, тогда этого еще не было. Хотя в 2017 году сильно нашумела история с ShadowBrokers и уязвимостью EternalBlue и с тех пор в арсенале у расторопных пентестеров, помимо metasploit'а, появилась своя виртуалочка с FuzzBunch.

Почему это было именно так? Для себя я выделил следующие причины:

Отсутствие достаточного опыта на рынке.
Пентест, как методичная и формализованная активность, только созревал. Это нормально, никогда не получается сразу «сделать красиво».
Уровень развития технологий и универсальность.
В то время не было разделения экспертов на направления, как это сейчас. Пентестеры были своего рода универсалами-ремесленниками, которые умели и «апрспуфинг» провести, и кавычку в форму веб-приложения пихнуть. Ну и, справедливости ради, на тот момент и веб был не таким тяжеловесным и по большей части серверсайдным, не было такого количества JavaScript-фреймворков, средства защиты еще не были такими «злыми», как сегодня, а наше комьюнити еще так глубоко не изучило винду и Active Directory. Быть универсалом на тот момент было в какой-то степени нормой.
Отсутствие адаптированной методической и практической базы.
Опытные безопасники мне, конечно, могут возразить: «Сережа, ты не прав! Был тогда и OWASP, и NIST 800-115, и PTES». Не спорю, были, но есть небольшой нюанс, и на этом пункте давайте остановимся подробнее.

Действительно, все эти стандарты и методики на тот момент были, но не у нас. Не секрет, что мировые тренды до наших краев доходят с некоторой задержкой. Сейчас эта задержка, безусловно, сократилась до недель. Но мы же говорим про 10-е года. Попробуем найти аргументов в пользу этого и пройдемся по стандартам, которые чаще всего на слуху, могут быть практически применены и вы их видели (или даже сами писали) в отчетах по пентесту: OWASP, PTES, OSSTMM.

OWASP Testing Guide

История этого гайда начинается в 2004 году. Однако ~~его~~ более-менее используемым он стал примерно со второй версии, которую зарелизили в 2007 году. К нам он дошел ближе к началу 10-х годов. Была даже глобальная кампания по переводу этого гайда на разные языки мира, включая русский. Об этом писали на Хабре. Обратим внимание на дату - 2014 год.

Сам гайд содержит 270+ страниц и применить на практике его, как некий читшит, было (да и есть) достаточно сложно.

Поэтому некоторые пентестеры делали свои локальные читшиты на основе этого гайда и своего опыта. Впоследствии появился отдельный проект OWASP Cheat Sheet, который уже более-менее стал утилитарным. Правда, он появился только к 2018 году :) И, что немаловажно, данный гайд был полезен для тестирования приложений, но не покрывал «инфраструктуру» в достаточной мере.

PTES

Данный стандарт впервые был опубликован в 2009 году, и в отличие от того же OWASP Testing Guide больше описывал этапы процесса и рекомендуемые инструменты (список которых часто копипастился в «Перечень используемых инструментов» в тех же отчетах по пентесту). Опять же, использовать его как читшит или мануал было достаточно сложно, потому что текст PTES не подразумевает конкретики по тому или иному действию, а местами даже общая информация отсутствует.

Шел 2026 год...

OSSTMM

Еще один зарубежный стандарт, первая версия которого появилась в конце 2000 года (для тех, кто хочет посмотреть одну из первых версий - сюда), а третья версия (ныне актуальная) - в конце 2010 года. Опять же, если обратиться к тексту стандарта, то вы вряд ли найдете подробную информацию, например, как и чем эффективно выполнить фаззинг веб-приложения или как корректно сделать ARP spoofing, чтобы не завернуть весь трафик подсети через свой интерфейс и не положить сетку всего этажа офиса Заказчика на некоторое время. (опытным пентестерам должна быть знакома эта ситуация) Скорее, вы больше там увидите концепцию подхода к тестированию, начиная от определений (безопасности, комплаенса, границ, контролей и т.д) и заканчивая требований к результату, то есть что вы должны написать в отчет и в каком виде.

Не похоже на те отчеты, что вы писали или получали, правда?

Был еще ряд других стандартов, методик и справочников (например, IDART, PCI DSS Penetration Testing Guidance или RTFM), но все они были по большей части скорее формальными документами и имели мало отношения к практической реализации пентеста. Да, я знаю что были уже тогда и наши отечественные стандарты и методики (привет 15408, 27001, СТО БР ИББС и другие), но они были куда более формальными, чем вышеперечисленные документы.

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

Пациент номер раз

Пациент номер два (опечатался, бывает...)

Второй, кстати, верно замечает еще одну немаловажную вещь. Помимо методик и чек-листов, на тот момент не было такого разнообразия тренировочных площадок или образов для самостоятельного изучения азов хакинга. Я навскидку вспомнил лишь RootMe, bWAPP и Metasploitable . Ну и, конечно же, множество CTF-соревнований на CTFtime.org. (но мы-то знаем, насколько «близки» условия CTF к реальной жизни...)

На сегодняшний день существует просто несметное количество блогов, читшитов, курсов и площадок, посвященных пентесту и редтиму. Перечислять их здесь не буду, ибо времени на это может не хватить. Да, раньше были курсы и от EC-Council (тот же CEH), и от eLearn Security. Но они стоили денег, в отличие от общедоступных и бесплатных блогов и Github-репозиториев.

Результат таких работ - отдельный вид искусства. Давайте посмотрим на скриншот части реального отчета 2015 года одной уважаемой ИБ-компании:

Ууух, RCE в винде...

Но если посмотреть на описание этой же уязвимости в результатах вышеупомянутого «сине-зеленого» сканера уязвимостей...

Хмм...

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

Итого, что имеем в итоге:

Было не так много боевого опыта.
Методическая база была, но не применима на практике.
Практическая база у каждого была своя и уровень её экспертности зависел от энтузиазма пентестера.
Пентестеры были «универсалами».
Технологии на тот момент времени были не такими сложными.

Разница услуг тогда и сейчас

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

Сканирование уязвимостей;
Внешний пентест;
Внутренний пентест;
Анализ приложений (веб и мобильных);
Соц.инженерия;
Анализ Wi-Fi сетей;
Физический пентест;
CPT (он же Continuous Penetration Testing);
Red Team;
Purple Team;
Киберучения.

Для сравнения, предложения тех времен насчитывали примерно 3 услуги:

Пентест;
Комплексный пентест;
Анализ защищенности.

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

Внутренний пентест

Пример ранних внутренних пентестов я уже приводил выше. На тот момент не было известно и/или найдено такого количества уязвимостей, позволяющих полностью скомпрометировать всю инфраструктуру. Навскидку, из наиболее пробивных я могу вспомнить MS08-067 и MS17-010. Да и, откровенно говоря, в арсенале пентестера-инфраструктурщика было достаточно иметь сканер уязвимостей, metasploit и пару-тройку утилит типа Responder, THC-Hydra или bettercap, чтобы разломать инфраструктуру среднестатистического Заказчика.

Однако, после нашумевшего EternalBlue и выхода на сцену российского пентеста пресловутого Kerberoasting'а, (хотя официально он опубликован аж в 2014 году на Derbycon 2014, но первый коммит в Impacket скрипта GetUserSPNs.py был сделан в мае 2016 года, а до нас он докатился чуть позже) количество уязвимостей и атак на инфраструктуру Windows начало стремительно расти. К тому времени уже использовались ныне известные атаки типа UD/CD/RBCD, атаки на WSUS, ADCS, SCCM, Pre-2K атаки и т.д.

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

Спасибо ЧатуЖПТ за кривую, но наглядную статистику

Спойлер для любознательных и недоверчивых

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

Подготовь мне статистику выявленных уязвимостей в ОС Windows и Active Directory за период 2010-2025 год. В статистику должны попасть только те уязвимости, которые относятся к классу RCE и Relay, активно эксплуатировались в реальных атаках и имеют публичные инструменты и описания в блогах исследователей по безопасности. Дополни статистику перечнем атак на windows и Active Directory, которые мог быть не присвоен идентификатор CVE, но все равно использовались в реальных атаках и имеют публичное описание и инструменты эксплуатации. Например, атаки на Kerberos, LDAP, WSUS, SCCM и другие. То есть нужно определить, в какой год появилась та или иная атака и добавить эту информацию в статистику. В качестве источника таких атак можно использовать mindmap от Orange Cyberdefence (https://orange-cyberdefence.github.io/ocd-mindmaps/), но не ограничиваться только им. Для каждой уязвимости/атаки должна быть приведена ссылка на ресурс с описанием, а также ссылки на публично доступные инструменты и PoC.

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

Таблица с колонками "Год", "Названия уязвимостей", "Номера CVE", "Номера MS" (к примеру MS08-067), "Ссылки", где каждая строка - год публикации уязвимости/атаки
Кумулятивный график обнаружения уязвимостей по годам, где ось X - годы, ось Y - количество уязвимостей

С того момента (то есть где-то с 2017-2018 годов) арсенал пентестера уже далеко вышел за рамки метасплоита. Там уже начали появляться и Impacket, и BloodHound, и всякие ntlmrelayx c certyfy/certipy, и многое-многое другое. С того же момента уже физически один среднестатистический offensive-эксперт не мог удержать в голове информацию и по приложениям, и по инфраструктуре. Ну и времени на выполнение качественного внутреннего пентеста стало уходить пропорционально больше, что в совокупности с остальным и сделало его из «этапа» в самостоятельную экспертную услугу.

Анализ приложений

Общая картина аналогична инфраструктурному пентесту. На заре оффенсива веб-приложения были преимущественно server-side'ными. Всю логику и безопасность обеспечивал сервер, а JavaScript в подавляющем большинстве случаев отвечал только за интерпретацию данных на стороне клиента. Впоследствии, когда грубо говоря XSS-ки начали активнее эксплуатировать ITW, разработчики стали уделять больше внимания client-side'у и ответственнее применять ~~всякие~~ SOP/CORS/CSP и прочие механизмы, которые также к сегодняшнему дню драматически усложнились.

Также в сложности в работу веб-пентестеров добавили, конечно же, фреймворки и языки программирования. Опять же, если обратиться к публичной статистике появления языков и фреймворков для разработки приложений (пусть даже не совсем точной и собранной нейросеткой), то можно увидеть динамику роста ~~зоопарка~~ разнообразия технологий, с которыми приходится сталкиваться веберу. И чем свежее эта технология, тем вероятнее всего она разрабатывалась Secure by Design, а еще больше усложняет поиск уязвимостей в таком продукте. Приправим это сверху концепцией «многослойности».

Современное приложение - это уже не просто пачка PHP-файлов на файловой системе сервера, а целый комбайн из технологий типа Kubernetes, S3, gRPC, GraphQL и т.д., который еще и работает за реверс-прокси. Да, можно справедливо заметить, что множество используемых технологий в некотором виде шаблонизированы и стандартизованы. Но отсюда только и вырастает сложность, так как при исключении простых уязвимостей типа SQL-инъекций, XXE или небезопасных десериалиазиций, появляются более сложные баги, поиск которых требует не только знания базовых вещей «на зубок», но и понимания работы той или иной технологии на уровне профессионального разработчика.

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

Спасибо (еще раз) ЧатуЖПТ за кривую, но наглядную статистику

Спойлер для любознательных и недоверчивых

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

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

1) Таблица с разбивкой по годам
2) Кумулятивный график появления продуктов, где ось X - годы, ось Y - количество продуктов

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

Спойлер для тех, кто потянулся за тапком

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

Как с этим жить

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

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

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

Stay tuned, до встречи в следующих статьях!

Экономим нервные клетки: как передавать макеты в разработку

Thu, 30 Apr 2026 13:30:11 +0000

Я продуктовый дизайнер с опытом более шести лет. В Лемана Тех работаю над продуктами ITSM-системы и касс.

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

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

Это была не инициатива «давайте всё задокументируем» и не попытка внедрить стандарт ради стандарта. Была конкретная потребность — улучшить качество продукта на выходе.

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

Проблема

Формально процесс выглядел корректно:

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

На практике это приводило к системным симптомам:

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

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

Каждый действовал по-своему:

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

И нигде это не сходилось в одну точку.

Решение

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

Исследование и выравнивание контекста

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

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

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

Важно было понять не то, «как должно быть», а как есть на самом деле.

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

Опыт разработчиков

Мы разобрали:

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

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

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

Опыт дизайнеров

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

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

Формирование чек-листа

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

Достаточно ли информации, чтобы разработка могла реализовать решение без догадок?

Чек-лист не проверял дизайн-решения, он проверял готовность к реализации и фиксировал:

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

В ходе исследования стало ясно, что часть проблем решается не процессами, а базовым выравниванием инструментального контекста. Многие разработчики просто не знали, как эффективно пользоваться Figma: от горячих клавиш и навигации по слоям до перехода к основному компоненту и применения всех фишек Dev Mode. После появления чек-листа мы провели встречи, где дизайнеры объясняли свой контекст принятия решений, а разработчиков обучали тонкостям Figma (горячие клавиши, логика работы компонентов, слои и отступы).

Ошибки и сложности

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

Основные сложности и ошибки в процессе создания:

сложная фасилитация больших групп, где каждый тянет одеяло на себя;
крайне низкий отклик на формы и опросы (около 5 человек);
частичное использование чек-листа (10–15 человек);
необходимость постоянного «пиара» материала, чтобы он оставался на слуху;
изначально лишний ресурс, потраченный на асинхронный сбор обратной связи вместо живого обсуждения.

Ключевые риски

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

Выводы

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

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

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

Чек-лист — лишь артефакт, а не волшебная таблетка. Он работает только в связке с живой коммуникацией и взаимным пониманием.

Чек-лист передачи макетов в разработку

1. Передача макета

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

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

2. Брейкпоинты

Макеты должны быть спроектированы с учетом всех брейкпоинтов дизайн-системы (добавьте основные брейкпоинты из вашей ДС в этот пункт).

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

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

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

Полезные ссылки (сюда нужно добавить ссылки из вашей ДС):

библиотека веб-компонентов в Фигме
библиотеки мобильных компонентов в Фигме
Storybook и Github — готовые компоненты в коде

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

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

Если используются кастомные компоненты

Новый компонент должен быть создан с учётом общепринятых паттернов;
Описана логика работы. Дана ссылка на описание или показано на макете стрелкой;
Добавлены все состояния: Default, Hover, Pressed, Disabled, Focused;
Учтены пограничные состояния. Например, в текстовом блоке минимум/максимум символов, прописаны ограничения по кол-ву символов в полях ввода, учтены и описаны самые длинные и короткие тексты;
Учтены размеры всех целевых экранов пользователей;
Компоненты стилизованы под дизайн-систему.

4. Пустые состояния форм и корнер-кейсы

Учтены на основных разрешениях экранов (см. пункт 2);
Отрисованы состояния переполнения контейнеров;
Сделаны шиммеры (скелетоны) или лоадеры экранов и блоков: определён с командой порядок загрузки частей страницы. Если нужно, отрисована поэтапная подгрузка или заглушки;
Показаны состояния скролла;
Описаны состояния валидации в формах ввода текста и написан текст к ошибкам валидации;
Описан текст к снэкбарам: успех / неуспех;
Спроектированы экраны ошибок 4ХХ, 5ХХ;
Проведена редактура текста: все формулировки проверены и исправлены согласно Редполитике, макеты содержат актуальный и реальный текст или максимально приближенный, в тексте нет ошибок.

5. Слои

Нет лишних вложенностей

✅ Правильно

❌ Неправильно

Нет скрытых слоёв, если они не скрыты свойством компонента Boolean

👀 Пример

Не использованы Group внутри компонента без необходимости (кроме иллюстраций)

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

☑️ Допустимо

❌ Неправильно

6. Консистентность

В макетах единая консистентность на всех экранах продукта

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

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

7. Описание макетов

В макете четко выделена часть, передаваемая в разработку

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

Должен прослеживаться сценарий с пошаговым объяснением действий пользователя

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

Каждая секция — это отдельная задача / сценарий / JTBD / user flow.

Описание задачи / сценария / JTBD / user flow

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

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

8. Размеры

Размеры компонентов и вложенных элементов выражены целыми значениями. Объекты, которые имеют дробные значения (например, иконки или изображения), должны находиться в контейнерах.

✅ Правильно

❌ Неправильно

Расстояния между элементами и сами элементы должны быть кратны 2 px.

Иначе на проде элементы могут отображаться некорректно.

9. Цвет и стили

Все стили цвета указаны переменными.

✅ Правильно

❌ Неправильно

Все шрифты указаны переменными.

✅ Правильно

❌ Неправильно

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

10. Анимация

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

Важно!

Не вносить правки в макеты, которые отданы в разработку!

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

Попробовали научить AI искать то, чего никто не замечает — слабые рыночные сигналы

AyratGil — Thu, 30 Apr 2026 13:26:18 +0000

Как мы научили алгоритм слушать рынок

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

Мысль, с которой всё началось

Представьте себе такую картину.

Утро. Вы открываете телефон и читаете новость: «Нефть достигла 117 долларов за баррель». Первый порыв — что-то сделать. Купить акции нефтяников? Продать рубли?

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

Значит ли это, что всё потеряно? Нет.

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

нефть выросла сегодня → через месяц рубль укрепился → инфляция замедлилась → Центральный банк снизил ставку → банкам стало меньше зарабатывать → через три месяца после нефтяного пика финансовый сектор пошёл вниз

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

Но три месяца назад — никто не ставил.

Такие зависимости мы называем слабыми сигналами. Они существуют в данных. Их можно найти. Просто нужна система, которая ищет их методично — перебирает тысячи комбинаций, проверяет сотни временны́х сдвигов, не устаёт и не отвлекается.

Человек так не может. Алгоритм — может.

Вот с чего начинался наш проект.

Змея, которая кусает себя за хвост

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

И мы её нашли.

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

Мы взяли эту идею и адаптировали её для финансовых данных.

Наш агент работает по тому же принципу:

гипотеза → SQL → данные → оценка
    ↑                        |
    └────── знания ←─────────┘

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

Причём агент учится сразу на трёх уровнях:

┌─────────────────────────────────────────────────────────────┐
│  Уровень 3: между сессиями                                  │
│  каждая итерация → датасет → обучение следующей версии      │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Уровень 2: внутри сессии                            │   │
│  │  гипотеза → SQL → данные → оценка → новая гипотеза   │   │
│  │                                                      │   │
│  │  ┌────────────────────────────────────────────────┐  │   │
│  │  │  Уровень 1: внутри одного запроса              │  │   │
│  │  │  ошибка → понять тип → исправить → попробовать │  │   │
│  │  └────────────────────────────────────────────────┘  │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

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

Второй уровень — основной цикл. Именно здесь рождаются гипотезы.

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

Архитектура слоев данных и функциями

Архитектура Signal Mind

Данные — это половина науки

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

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

Вот что у нас есть:

Источник	Что внутри	Объём
Московская биржа	15 индексов, 2016–2026	38 000+ строк
Центральный банк РФ	Ключевая ставка, курс USD/RUB	5 600+ строк
Росстат	Зарплаты, демография, жильё	15 503 строки
Глобальные рынки	Brent, SP500, Gold, DXY, MSCI_INDIA…	13 инструментов
Новости	Reuters, Bloomberg, CNBC и другие	2 520 591 статья
Документы ЦБ	PDF-доклады, корпоративная отчётность	17 492 фрагмента

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

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

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

Граф знаний Signal Mind в Obsidian

Каждый узел — это гипотеза или источник данных. Линии — подтверждённые связи. Так выглядят 1943 итерации, собранные в одну картину.

Красиво, правда? Но чтобы это получить — сначала нужно было провести эксперимент.

Ночь тишины

Итак - час ночи.

Мы запустили агента и закрыли ноутбук.

python -m src.agent.watchdog 32400   # 9 часов

Watchdog — это маленькая программа-сторож, которая раз в минуту проверяет: «агент ещё работает?» Если нет — перезапускает. Мы написали её на случай, если что-то пойдёт не так посреди ночи.

Она не понадобилась ни разу.

Девять часов агент работал в полной тишине. Генерировал гипотезы, писал SQL, получал числа, оценивал, передавал знание дальше. Без нас. Без подсказок.

В 10 утра мы открыли отчёт:

Что мерили	Результат
Итераций за ночь	1 943
Токенов потрачено	409 миллионов
Стоимость всей ночи	$5.76
Среднее время одной итерации	14.4 секунды
Ошибок SQL, которые агент исправил сам	22
Из них — неудачных	0
Перезапусков сторожа	0
«Подтверждённых» гипотез	67.7%

Шесть долларов. Девять часов. Почти две тысячи итераций.

И последняя строка — 67.7% — нас насторожила.

Ошибка, которая стала подарком

67.7% подтверждённых гипотез — это очень много.

Слишком много.

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

Мы начали проверять вручную. Открывали каждый «подтверждённый» SQL и запускали его на живой базе данных. И примерно на третьем примере поняли.

Агент должен был взять данные по китайскому индексу вот так:

-- Правильно: данные из нужной таблицы
FROM market_data WHERE instrument = 'FTSE_CHINA_50'

А он делал вот так:

-- Что он реально писал:
SELECT imoex_close AS ftse_china_50   -- ← просто переименовал колонку
FROM v_market_context

Понимаете, что произошло?

Он брал данные российского индекса IMOEX — и называл их «китайским индексом». Потом измерял корреляцию между IMOEX и MOEXOG. Между двумя российскими индексами. Конечно, они коррелируют — r ≈ 0.88. Потому что оба российские, а не потому что есть какой-то сигнал.

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

Около 60% «подтверждённых» сигналов были тавтологией.

Реальный результат: не 67.7%, а примерно 15–25%.

Теперь самое важное — что мы сделали дальше.

Мы не удалили эти примеры.

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

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

Ошибка превратилась в знание. Это и есть суть третьего уровня обучения.

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

Исправление

После находки мы сделали три вещи.

Первое — задокументировали паттерн ошибки. Файл forbidden_patterns.md, паттерн №8: «подмена инструмента». С примером до и после. Чтобы в следующий раз агент видел: «я уже пробовал так делать — это ошибка».

Второе — добавили явное предупреждение в промпт:

ВАЖНО: для внешних инструментов (FTSE_CHINA_50, DXY, MSCI_INDIA и др.)
данные ТОЛЬКО из: FROM market_data WHERE instrument = '<название>'
Никогда не переименовывай колонки из других таблиц.

Третье — запустили чистый скан с нуля. 618 комбинаций: 10 инструментов, 7 новостных тем, 5 целевых индексов, 6 временных лагов. На этот раз — честно.

Что нашли на самом деле

После чистого скана — шесть реальных паттернов. Не шестьдесят семь процентов. Шесть.

Зато настоящих.

Сигнал	r	Лаг	Механизм
USD/RUB → MOEXFN	+0.758	14 дней	Девальвация → переоценка активов
Brent → MOEXFN	−0.702	90 дней	Нефть → рубль → ставка → маржа банков
Ключевая ставка → MOEXFN	+0.651	0 дней	Банки зарабатывают на высокой марже
MSCI_INDIA → MOEXFN	+0.631	0 дней	Глобальный аппетит к рискованным рынкам
SP500 → MOEXFN	+0.593	7 дней	Мировой риск-аппетит с недельным лагом
Банковские новости → MOEXFN	+0.549	14 дней	Работает только при ставке < 15%

Самый нетривиальный — второй в таблице. Давайте разберём его подробнее.

Нефть предсказывает банки в минус

Нефть выросла — а через три месяца банки упали. Звучит странно, правда?

Вот цепочка, которая это объясняет:

Нефть дорожает
  → нефтяная выручка поступает в страну
  → экспортёры продают валюту, рубль укрепляется
  → инфляционное давление снижается
  → Центральный банк получает возможность снизить ставку
  → банки зарабатывают меньше (ставка = их маржа)
  → инвесторы переоценивают банковский сектор вниз
                                        (лаг ~90 дней)

Данные это подтверждают:

Brent и MOEXFN 2022–2025

Синяя линия — Brent. Зелёная пунктирная — финансовый индекс MOEXFN. В 2022 году нефть на пике ($117) — банки на минимуме. Когда нефть начала падать — банки пошли вверх.

Особенно убедительно вот что: корреляция монотонно растёт с увеличением временно́го сдвига:

Корреляция по лагам

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

Но вот здесь мы обязаны быть честными.

Честная часть

Когда мы посмотрели на данные год за годом — картина стала сложнее:

Год	Корреляция (лаг 90 дней)	Что происходило
2022	−0.574	Начало СВО, санкции, нефть на пике — сильный сигнал
2023	−0.113	Ставка растёт — нефтяной сигнал почти исчез
2024	−0.097	Ставка 21% — полностью заглушила нефть
2025	+0.265	Знак инвертировался

Агрегатная корреляция −0.70 — во многом эффект одного аномального года. В 2023–2024 сигнал просто не работал.

Зато режимный анализ даёт ясный ответ:

Режимный анализ

Условие рынка	Корреляция	Что это значит
Весь период 2022–2025	−0.702	✅ Реальный, структурный сигнал
Сильный рубль (USD/RUB < 80)	−0.851	✅ Очень сильный
Ставка ЦБ ≥ 16%	−0.100	❌ Сигнал не работает
2025, ставка снижается	+0.265	⚠️ Знак сменился

Главный вывод: сигнал включается только в определённых условиях. При высокой ставке ЦБ — она перекрывает нефтяной сигнал и становится главным фактором.

Это не слабость результата. Это самое интересное открытие всего проекта.

Главный урок

Российский финансовый рынок — это рынок режимов.

Один и тот же фактор работает по-разному при ставке 7% и при ставке 21%. При сильном рубле и при слабом. Нет одного универсального сигнала — есть сигналы, которые включаются и выключаются в зависимости от состояния системы.

Мы начинали с простого вопроса: «какие корреляции можно найти в данных?» А пришли к другому: «в каком режиме сейчас рынок — и какие сигналы в этом режиме работают?»

Это совсем другой вопрос. И он правильнее.

Поиск истины

Знаете, что меня больше всего радует в этом проекте?

Не шесть найденных сигналов. Не $5.76 за девять часов работы. Не 409 миллионов токенов.

Меня радует то, что мы нашли свою ошибку сами.

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

Именно так устроена настоящая наука. Не победное шествие от гипотезы к открытию. А спираль: предположение → проверка → сомнение → уточнение → новое предположение.

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

1943 итерации — это не результат. Это начало разговора.

Что дальше

Шаг	Задача
Phase 7	Второй марафон — чистый агент, без старых ошибок
Phase 8	Обучение DeepSeek на нашем датасете (1953 примера)
Phase 9	Режимный классификатор — агент сначала определяет состояние рынка, потом ищет сигналы

Phase 9 — это тот самый качественный скачок. Научить алгоритм спрашивать «в каком режиме мы сейчас?» прежде чем искать сигналы — это другой уровень.

Посмотреть самому

Всё открыто: github.com/iRatG/signal-mind

Открыть	Что внутри
📊 Разбор сигнала Brent→MOEXFN	SQL, 6 интерактивных графиков, режимный анализ
📈 Отчёт ночи тишины	8 графиков — телеметрия 9-часового запуска

# Попробовать самому — 10 итераций
python -m src.agent.agent 10

# Ночной марафон (9 часов)
python -m src.agent.watchdog 32400

Вдохновлено проектом Ouroboros

Python · DuckDB · ChromaDB · DeepSeek API · MOEX · ЦБ РФ · 2.52M новостей

[Перевод] System Design: проектируем сервис быстрых знакомств

pavsenin — Thu, 30 Apr 2026 13:17:16 +0000

Видеоразбор этой задачи на русском языке можно посмотреть здесь - https://www.youtube.com/watch?v=U_qR7HFZIbE

Проектирование Tinder

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

❤️ Что такое Tinder?

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

Функциональные требования

Основные требования

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

За рамками задачи

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

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

Нефункциональные требования

Основные требования

Система должна обеспечивать сильную согласованность (strong consistency) для свайпов. Если пользователь свайпнул “да” на человека, который уже свайпнул “да” на него, оба должны получить уведомление о матче.
Система должна масштабироваться под большое количество ежедневных активных / одновременных пользователей (20 млн DAU, в среднем ~100 свайпов на пользователя в день).
Система должна быстро формировать список потенциальных матчей (< 300 мс).
Система не показывает повторно профили, по которым пользователь уже свайпал.

За рамками задачи

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

На доске это могло бы выглядеть примерно так:

Нефункциональные требования

Подготовка

Планирование подхода

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

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

Проектирование API

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

Для Tinder основные сущности довольно очевидны:

User: это и пользователь приложения, и профиль, который показывают другим пользователям.
Swipe: выражение “да” или “нет” по отношению к профилю другого пользователя. Содержит информацию о пользователе, который свайпает (swiping_user), и пользователе, которого свайпают (target_user).
Match: связь между двумя пользователями, возникающая в результате взаимного свайпа “да”.

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

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

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

POST /profile
{
  min_age,
  max_age,
  max_distance,
  interested_in: "female" | "male",
  ...
}

Далее нужен эндпоинт, который возвращает “ленту” профилей потенциальных кандидатов.

GET /feed?lat={}&long={} -> User[]

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

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

Также нужен эндпоинт для свайпа:

POST /swipe/{userId}
{
  "decision": "yes" | "no"
}

В каждом из этих запросов информация о пользователе передается в заголовках (через session token или auth token). Это распространенный паттерн, так мы можем обеспечивать аутентификацию/авторизацию и безопасность. Не стоит передавать пользовательские данные в теле запроса: в этом случае их можно легко подделать.

Проектирование API и сущностей

Высокоуровневый дизайн

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

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

Мы принимаем запрос POST /profile и сохраняем настройки в базе. Для старта нам достаточно простой архитектуры Клиент -> Сервер -> База данных. При этом, если сразу очевидно, что мы будем использовать несколько сервисов, то можно сразу добавить на схему API Gateway для маршрутизации запросов.

Создание профиля с предпочтениями

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

Когда пользователь создает профиль:

Клиент отправляет POST /profile с данными профиля в теле запроса.
API Gateway направляет запрос в сервис профилей.
Сервис профилей обновляет предпочтения пользователя в базе.
Результат возвращается клиенту.

2. Пользователи могут просматривать список потенциальных матчей

Когда пользователь открывает приложение, он сразу видит список профилей для свайпа. Эти профили должны соответствовать фильтрам (возраст, интересы и т. п.), а также географии пользователя (например “< 2 км”, “< 5 км”, “< 15 км”).

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

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

Простейший запрос мог бы выглядеть так:

SELECT * FROM users
WHERE age BETWEEN preferredAgeMin AND preferredAgeMax
AND gender = preferredInterestedIn
AND lat BETWEEN userLat - preferredDistance AND userLat + preferredDistance
AND long BETWEEN userLong - preferredDistance AND userLong + preferredDistance

Список потенциальных матчей

Когда пользователь запрашивает новый набор профилей:

Клиент отправляет GET /feed, передавая текущую локацию через query‑параметры.
API Gateway направляет запрос в сервис профилей.
Сервис профилей запрашивает базу данных, выбирая пользователей по предпочтениям и локации.
Результаты возвращаются клиенту.

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

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

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

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

Добавим два новых компонента:

Сервис свайпов: сохраняет свайпы и проверяет матчи.
Хранилище свайпов: хранит данные свайпов.

Почему мы выбрали отдельный сервис и отдельное хранилище?

Обоснование: создание/обновление профиля происходят существенно реже, чем запись свайпов. Разделив сервисы, мы можем независимо масштабировать сервис свайпов. Аналогично, по данным, свайпов будет очень много. При 20 млн DAU × 100 свайпов/день × ~100 байт на свайп получается порядка ~200GB данных в день. Такой объем и нагрузку хорошо сможет обработать хранилище оптимизированное для записи такое как Cassandra (которое может быть не лучшим выбором для профилей). Кроме того, отдельное хранилище позволяет оптимизировать паттерны доступа и кэширование для свайпов без влияния на сервис профилей.

Такое разделение - не универсальный ответ для всех систем. Но здесь плюсы перевешивают минусы.

Поскольку свайп - действие почти без усилий, можно ожидать большой поток записей. Если принять 20 млн DAU и в среднем 100 свайпов/день, это 2 млрд записей в день. Это почти наверняка означает, что данные нужно партиционировать.

Cassandra хорошо подходит как хранилище свайпов. Мы можем партиционировать по swiping_user_id. Тогда проверка “свайпал ли пользователь A пользователя B” будет быстрой: мы предсказуемо идем в один раздел (partition). Также Cassandra хорошо выдерживает большие объемы записей благодаря архитектуре своего хранения (CommitLog + Memtables + SSTables). Недостатком использования Cassandra здесь является конечная согласованность для данных о свайпах. Мы обсудим способы нивелировать этот недостаток когда будем погружаться в детали.

Свайп вправо/влево и запись результата

Когда пользователь свайпает:

Клиент отправляет POST /swipe/{userId} с userId профиля и результатом свайпа (вправо/влево).
API Gateway направляет запрос в сервис свайпов.
Сервис свайпов записывает свайп в хранилище свайпов.
Сервис свайпов проверяет наличие обратного свайпа и, если он есть, сообщает клиенту о матче.

4. Пользователи получают уведомление о матче при взаимном свайпе

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

Уведомить Боба просто: это мы уже делаем. Поскольку он - второй, сразу после свайпа вправо мы проверяем, лайкнула ли Алиса, и если да - показываем уведомление на устройстве Боба.

Но что насчет Алисы? Она могла свайпнуть Боба несколькими днями ранее. Нам нужно отправить push‑уведомление на устройство Алисы, сообщив, что у нее новый матч.

Для этого будем использовать нативные сервисы push-уведомлений, такие как Apple Push Notification Service (APNS) или Firebase Cloud Messaging (FCM).

Уведомление о матче

APNS и FCM - это службы push‑уведомлений, с собственным набором API и SDK, которые мы можем использовать для отправки push‑уведомлений на пользовательские устройства.

Кратко повторим полный процесс свайпа с учетом пушей:

Некоторое время назад Алиса свайпнула вправо Боба, и мы сохранили это в хранилище свайпов.
Боб свайпает вправо Алису.
Сервер проверяет наличие обратного свайпа и находит его.
Мы показываем уведомление о матче на устройстве Боба сразу после свайпа.
Мы отправляем push‑уведомление через APNS/FCM Алисе, что у нее новый матч.

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

Потенциальные погружения в детали

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

1. Как обеспечить согласованность и низкую задержку при свайпах?

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

Свайп Алисы приходит на сервер - мы проверяем обратный свайп. Его нет.
Свайп Боба приходит на сервер - мы проверяем обратный свайп. Его нет.
Мы сохраняем свайп Алисы на Боба.
Мы сохраняем свайп Боба на Алису.

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

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

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

Хорошее решение: Транзакции

Подход

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

В Cassandra есть базовая поддержка того, что они называют легковесные транзакции (Lightweight Transactions, LWT), но это не полноценные ACID‑транзакции. LWT используют консенсусный протокол Paxos для обеспечения линеаризуемой согласованности (linearizable consistency) для конкретных операций, но только в рамках одного раздела (partition). Между разделами они не дают атомарности, уровней изоляции и откатов. Также LWT имеют существенные накладные расходы из‑за нескольких сетевых коммуникаций (round-trips) между нодами. Это делает такие транзакции подходящими в основном для простых условных обновлений.

Проблемы

Главная проблема при этом подходе - масштабируемость. 2 млрд свайпов в день не поместятся в один раздел, а транзакции на несколько разделов LWT не поддерживают.

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

Отличное решение: Транзакции в одном разделе

Подход

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

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

CREATE TABLE swipes (
    user_pair text,      -- ключ партиционирования: smaller_id:larger_id
    from_user uuid,      -- кластерный ключ
    to_user uuid,        -- кластерный ключ
    direction text,
    created_at timestamp,
    PRIMARY KEY ((user_pair), from_user, to_user)
);

При свайпе формируем user_pair, отсортировав id, для обеспечения согласованности:

def get_user_pair(user_a, user_b):
    # Отсортируем id так, чтобы (A->B) и (B->A) были в одном разделе
    sorted_ids = sorted([user_a, user_b])
    return f"{sorted_ids[0]}:{sorted_ids[1]}"

def handle_swipe(from_user, to_user, direction):
    user_pair = get_user_pair(from_user, to_user)

    # Обе операции выполняются атомарно в одном разделе
    batch = """
    BEGIN BATCH
        INSERT INTO swipes (user_pair, from_user, to_user, direction, created_at)
        VALUES (?, ?, ?, ?, ?);

        SELECT direction FROM swipes
        WHERE user_pair = ?
        AND from_user = ?
        AND to_user = ?;
    APPLY BATCH;
    """

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

Проблемы

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

Отличное решение: Redis для атомарных операций

Подход

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

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

Структура ключа и значения:

Key: "swipes:123:456"
Value: {
  "123_swipe": "yes",
  "456_swipe": "no"
}

def get_key(user_a, user_b):
    # Отсортируем id так, чтобы (A->B) и (B->A) были в одном разделе
    sorted_ids = sorted([user_a, user_b])
    return f"swipes:{sorted_ids[0]}:{sorted_ids[1]}"

def handle_swipe(from_user, to_user, direction):
    key = get_key(from_user, to_user)

    # Используем Redis хеш для хранения свайпов обоих пользователей
    # Хеш имеет два поля: user1_swipe и user2_swipe
    script = """
    redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])
    return redis.call('HGET', KEYS[1], ARGV[3])
    """

    # Выполняем атомарно используя Lua скрипт
    other_swipe = redis.eval(
        script,
        keys=[key],
        args=[
            f"{from_user}_swipe",  # поле для установки
            direction,             # наш свайп
            f"{to_user}_swipe"     # поле для проверки
        ]
    ) # Возвращает значение другого пользователя

    # Если другой пользователь тоже свайпнул вправо, это матч!
    if direction == 'right' and other_swipe == 'right':
        create_match(from_user, to_user)

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

Redis для атомарных операций

Проблемы

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

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

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

2. Как обеспечить быструю загрузку списка потенциальных матчей?

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

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

SELECT * FROM users
WHERE age BETWEEN preferredAgeMin AND preferredAgeMax
AND gender = preferredInterestedIn
AND lat BETWEEN userLat - preferredDistance AND userLat + preferredDistance
AND long BETWEEN userLong - preferredDistance AND userLong + preferredDistance

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

Хорошее решение: Индексированные БД для real-time запросов

Подход

Один из способов добиться низкой задержки - использовать индексированные БД для запросов реального времени. Если создать индексы по полям, используемым при построении списка (предпочтения, возраст, и особенно geo‑данные), можно сильно ускорить время ответа. Геопространственный индекс позволяет эффективно находить пользователей в заданной области.

Для масштабируемости и требований Tinder можно использовать БД оптимизированную для поиска вроде Elasticsearch или OpenSearch. Они заточены под быстрый поиск и сложные запросы, что делает их пригодными для обработки больших объемов данных с минимальной задержкой.

Индексированные БД для запросов списка потенциальных матчей

Проблемы

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

Обычно это решают через механизм Change Data Capture (CDC). Это шаблон, который фиксирует изменения базы данных (вставки, обновления, удаления) и передает их в другие системы. Часто реализуется путем мониторинга журнала упреждающей записи (write-ahead log) базы данных.

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

Хорошее решение: Предварительные вычисления и кэширование

Подход

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

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

Предварительные вычисления и кэширование

Проблемы

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

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

Отличное решение: Комбинация предвычислений и индексированной БД

Подход

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

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

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

Комбинация: предварительные вычисления + индексированная база данных

Как мы можем решить проблему устаревших списков?

Кэширование списков пользователей может привести к тому, что мы будем предлагать “устаревшие” профили:

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

Чтобы смягчить эту проблему, можно:

поставить строгий TTL на кэш списков (например, < 1 часа) и пересчитывать по расписанию
предвычислять списки только для действительно активных пользователей, а не для всех

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

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

Также есть вполне определенные пользовательские действия, которые делают кэш устаревшим:

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

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

3. Как избежать повторного показа профилей, по которым пользователь уже свайпал?

Было бы довольно неприятно, если бы пользователям повторно показывали профили, которые они пролистнули. У пользователя может сложиться впечатление, что его свайпы вправо (“да”) не были записаны, или это может раздражать пользователей, когда они снова видят людей, которых они раннее свайпнули влево (“нет”). Мы должны разработать решение, которое исключит этот неприятный пользовательский опыт.

Плохое решение: Запрос в хранилище свайпов

Подход

Сервис построения списка может запросить хранилище свайпов и сделать проверку на наличие свайпов пользователя, чтобы отфильтровать профили, по которым уже свайпали. Запрос “все свайпы пользователя” будет эффективным, потому что попадет в один раздел по swiping_user_id.

Проблемы

С этим подходом есть две проблемы:

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

Отличное решение: Кэш + запрос в хранилище свайпов

Подход

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

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

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

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

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

Кэш + запрос в хранилище свайпов

Проблемы

Остается проблема пользователей с очень большой историей свайпов: проверка на contains по большому множеству id будет все медленнее по мере роста истории.

Отличное решение: Кэш + запрос в хранилище свайпов + фильтр Блума

Подход

Этот подход может выглядеть слегка “over-engineered”, но это вполне разумный сценарий для фильтра Блума: поддержать построение списка для пользователей с огромной историей свайпов.

Если история свайпов превышает определенный порог (когда проверка на contains становится дорогой), мы строим и кэшируем фильтр Блума и используем его для фильтрации.

Фильтр Блума иногда дает ложноположительные результаты (false positives) (например, что профиль уже свайпали, хотя это не так), но никогда не дает ложноотрицательные (false negatives) (например, что профиль не свайпали, если его свайпали). Значит мы точно избегаем повторных показов, но можем не показать пользователю небольшое количество профилей из-за ложноположительных результатов.

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

Кэш + запрос в хранилище свайпов + фильтр Блума

Проблемы

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

Что ожидается на каждом уровне?

Хорошо, мы обсудили много всего. Возникает резонный вопрос: “сколько из этого реально ожидается от меня на интервью?”. Разберем по уровням.

Middle

Ширина vs глубина: от Middle кандидата чаще ожидается ширина кругозора и знаний (примерно 80% vs 20%). Вы должны собрать понятный высокоуровневый дизайн, закрывающий все функциональные требования, но многие компоненты могут оставаться абстракциями, которые вы проработали и обсудили с интервьюером на поверхностном уровне.

Проверка базовых знаний: интервьюер будет прощупывать базу, чтобы удостовериться, что вы понимаете, что делает каждый компонент. Например, добавив API Gateway, ожидайте вопрос “что он делает” и “как работает”.

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

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

Senior

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

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

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

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

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

Staff+

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

Интервьюер понимает, что вы знаете основы (REST, нормализация данных и т. п.), так что вы можете быстро пройти это на high-level дизайне и перейти к самому интересному.

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

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

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

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

Разборы задач по System Design:

Проектируем Ticketmaster, сервис бронирования билетов

Проектируем Uber, сервис для заказа такси

Как совместить работу и путешествие на 1000+ км (заметки собаки)

Thu, 30 Apr 2026 13:13:23 +0000

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

Хотя эта история из 2023 года, она всё ещё актуальна. Эти заметки я нацарапал тогда (лапами, не судите строго). Мы с моими людьми — Сашей, она отвечает за поддержку корпоративных клиентов и клиентский сервис в ЮKassa, и Витей, он говорил, что занимается продуктом в ЮKassa, — решили проверить одну гипотезу. Можно ли одновременно работать, ехать куда-то далеко и при этом не превращаться в выжатый лимон? Ну и заодно — каково это, путешествовать с собакой (спойлер: нормально, если собака — я).

Маршрут был такой: Нижний Новгород → Санкт-Петербург → Карелия → Нижний Новгород.

Дорога: маршрут и практические наблюдения

Ехали по классике: М7 до Владимира, потом М12, ЦКАД, и дальше М11 до Питера.

Сонное утреннее селфи! Кстати, это мои хозяева: Саша и Витя. Эти копуши хотели выехать в 7:00, но кто-то очень долго спит😊

Я, как главный специалист по высовыванию морды в окно, могу сказать:

Платные трассы — способ сохранить нервы. М11 — это стабильная скорость, хорошее покрытие и меньше стресса. Люди не ворчат, а значит, мне спокойнее.
Заправки лучше планировать. Когда у людей заканчивался бензин, они почему-то нервничали сильнее, чем когда у меня заканчивался корм. Странно.
Остановки каждые 2–3 часа — must have. И речь не только о собаках. Людям тоже полезно иногда выйти из машины и вспомнить, что у них есть ноги.

Фото 1. Я возмущён, что мне вместо кофе налили водички.
Фото 2. Всем давали солянку, а мне сухой корм. Облом!

Важно помнить, что дорога — это не место для подвига, а часть путешествия. Чем спокойнее едешь, тем больше сил остаётся на саму поездку и на игры с четвероногими. Мы доехали часов за 12–13 без подвигов. И, что важно, никто не страдал.

Петербург: работа днём, жизнь вечером

В Санкт-Петербурге мы пожили несколько дней. Формат простой: днём люди работают, вечером — гуляют (и я, наконец, живу свою лучшую жизнь).

А лежать на марсовом поле — бесценно.

Что я заметил:

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

А люди в это время… работали. Созвоны, задачи, какие-то спринты (я до сих пор думаю, что это про бег, но они почему-то сидят за ноутбуками).

Со стороны (с моего, самого объективного взгляда) это выглядело так: всё работает там, где есть доверие и общее понимание задач. Никто не занимается микроменеджментом или учётом времени — в центре внимания остаётся результат и его качество.

Карелия: сидим и смотрим

Потом мы поехали в Карелию, там ритм резко замедлился. Даже я стал меньше суетиться (но это не точно).

Если по точкам:

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

Долина водопадов
Красиво и спокойно: деревянные тропы, вода, лес. Можно идти и не думать о сложном. Я одобряю такие маршруты.

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

Онежское озеро
Прогулки по берегу — идеальное место для тишины и созерцания. Летом можно искупаться, но будьте готовы, что собаки тоже захотят поплескаться. У нас было несколько экскурсий, и одна из них — прогулка по урочищу «Чёртов стул». Место окружено мистикой: здесь дважды проводились всероссийские съезды колдунов. Подниматься на сам «Чёртов стул» было непросто, но да, меня туда тоже взяли.

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

Наш рецепт работы в путешествии

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

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

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

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

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

Никакой магии, только грамотное планирование и дисциплина. Итоги поездки:

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

Немного личного (собачьего)

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

Ну и мой главный вывод: путешествовать с собакой — это нормально. Главное помнить, что собака тоже участник процесса, а не багаж.

А теперь вопрос, чтобы не просто разойтись: как вы выстраиваете баланс между работой и жизнью в поездках — это чёткое расписание или скорее «как пойдёт»? И пробовали ли вообще совмещать работу с дорогой (и собакой)?

Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

Thu, 30 Apr 2026 13:06:43 +0000

Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java / Kotlin разработки в FinTech, а также преподаю на курсах по архитектуре и бэкенд‑разработке в OTUS. В этой статье хочу разрушить один опасный миф: якобы скоро нейросети заменят разработчиков, и нам останется только пить кофе, пока ИИ пишет микросервисы.

Спойлер: это не так.

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

Агенты не пишут код. Они решают задачи

Когда я только начинал экспериментировать со связкой Kotlin + AI‑агенты, я думал, как и многие: «Сейчас объясню бизнес‑требование, и оно само превратится в Pull Request». На деле получил лапшу из классов, нарушающую все принципы SOLID. Потому что ИИ, будь то Copilot, Cursor с агентами или самописные воркеры на базе LangChain4j, отлично решает задачу «в лоб». Но плохо понимает контекст всей системы, если этот контекст ему не дать.

Можно потратить месяц, переписывая один модуль Ktor‑приложения, где ИИ‑агент генерировал эндпоинты без спецификации OpenAPI. Каждый новый метод будет работать, но вместе все это превращается в кашу. Именно тогда я и сформулировал правило: «Кодинг — это доставка. Архитектурный дизайн и контракты — рулевое управление». И рулить должен разработчик (рис. 1).

Рис. 1 Иллюстрация концепции: разработчик как дирижер ИИ‑команды

Благодаря этому у меня сформировалось понимание того, что подход Agent‑Oriented Programming имеет место быть, но с жестким контролем. Весь входящий поток бизнес‑требований необходимо сначала «упаковывать» в строгую архитектурную схему, используя проверенные шаблоны. Только после этого даем волю ИИ‑команде.

Подготовка фундамента: не дайте агенту сойти с рельсов

Главная ошибка новичков — дать агенту промпт: «Создай CRUD для пользователей на Ktor с Exposed». Он создаст. Но как потом это поддерживать? Без абстракций, без Clean Architecture, без разделения на слои.

Мой Best Practice теперь выглядит так: шаблон решает всё. Я не стартую проект с пустого main.kt, а использую stage‑driven генерацию (пошаговое создание структуры).

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

domain — модели и чистые интерфейсы репозиториев (никаких фреймворков).
usecases — бизнес‑логика, которая дергает интерфейсы.
adapters — реализации репозиториев (Exposed, Ktor Client), контроллеры.

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

Агента‑аналитика: Проанализируй вводные и предложи модель данных и sequence‑диаграмму (Mermaid).
Человека: Утверди диаграммы, добавь нефункциональные требования (NFR).
Агента‑разработчика: Имплементируй строго по утвержденной спецификации в подготовленных файлах.

Работа с ИИ‑командой: декомпозиция под надзором

Перейдем к практике. Допустим, задача — сделать функциональный узел «Управление подписками пользователей» на Kotlin.

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

Я даю агенту промпт: «Распиши Use Case „Оформление подписки“. Учти, что платеж проходит через внешний эквайринг, возможна задержка колбэка до 30 секунд, пользователь должен видеть актуальный статус в реальном времени».

Агент выдает:

Сохранить запись в БД со статусом PENDING.
Сходить в эквайринг.
Обновить статус.

Как человек, смотрю на это и вижу фатальную дыру. А если эквайринг отвечает долго, а пользователь нажал кнопку 5 раз подряд? Идемпотентность! Агент часто игнорирует идемпотентность, если ему не напомнить.

Дальше подключаем второго агента для написания интеграционных тестов. Мы не пишем тесты руками. Мы скармливаем ему спецификацию в формате Gherkin (Given/When/Then), и он генерирует Kotlin‑код с использованием kotest и test containers. Человек на этом этапе следит только за одним: покрыты ли тестами те самые граничные условия, которые нашел архитектор.

Посмотрите на диаграмму последовательности ниже. Это результат работы связки «Человек‑Архитектор + ИИ‑аналитик». Мы специально развели синхронные и асинхронные вызовы, чтобы не связывать основной поток пользователя с внутренней кухней платежей (рис. 2).

Рис. 2 Диаграмма последовательности: идемпотентное оформление подписки с разделением на синхронный ответ и асинхронный callback

Схема показывает, как мы развели синхронную и асинхронную ветки в сценарии оформления подписки. Пользователь получает моментальный ответ 202 Accepted и не ждёт, пока отработает платёж. В этот момент запись уже лежит в базе в статусе PENDING, а событие ушло в очередь. Дальше фоновый агент спокойно общается с эквайрингом (до 30 секунд) и обновляет статус, не нагружая основной пользовательский поток. Ключевой момент — insertOrIgnore с идемпотентным ключом, который предотвращает дублирование подписок при повторных запросах.

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

Инженерный контроль: когда ИИ ошибается красиво и незаметно

Правило, которое я вывел: автоматика отлично справляется с happy path. Как только начинаются сетевые проблемы, гонки состояний или обратное давление (backpressure) — нужен инженерный контроль. ИИ сегодня — это мощный, но все еще Junior‑разработчик. А когда Junior пишет сложный многопоточный код в продакшен, за ним нужен Lead.

Чтобы минимизировать риски, можно использовать практику «Авто‑ревью». Один ИИ‑агент генерирует код, второй (с промптом «ты вредный сеньор‑проверяльщик») ищет типовые уязвимости: блокировки на уровне БД, утечки корутин, нарушения контрактов. И роль человека — принимать окончательное решение в спорных ситуациях между ними.

История одного рефакторинга: от хаоса к оркестру

Как‑то в сети мне попалась история, когда команда переводила легаси‑проект с Java на Kotlin и прикрутить умный поиск. Бизнес хотел «как в Google, но внутри ERP». Изначально команда пыталась просто писать промпты в ChatGPT и вставлять код. Закончилось это тем, что сервис поиска падал при любом запросе длиннее трех слов.

Но после применения коллаборативного подхода все взлетело. Был взят шаблон Ports and Adapters (Hexagonal Architecture):

Разработчик спроектировал порт SearchEnginePort с одним методом.
ИИ‑агент сгенерировал три адаптера: простой полнотекстовый поиск, поиск через векторную базу (pgvector) и гибридный с ранжированием.
Архитектор (человек) написал фабрику, переключающую стратегии в зависимости от типа запроса без перезагрузки сервиса.

В итоге это решение стало обрабатывать 500 RPS на довольно скромных контейнерах. Но главное не цифры, а то, как быстро были перебраны гипотезы. Без агентов написание трех параллельных адаптеров заняло бы недели две. С ними команде удалось сделать прототип за 3 дня. Но дирижировал процессом человек. Именно он решил, что pgvector надо использовать не напрямую, а через обертку, чтобы избежать проблем с драйвером PostgreSQL!

Результат: пошаговое создание работающего функционала

Как это выглядит в итоге на проекте?

Инициализация: берем готовый Gradle‑шаблон с Ktor, Exposed, Koin. (1 минута).
Анализ: загружаем требования в NotebookLM или LangChain‑агента, получаем каркас Use Case и диаграмму (Рис. 2).
Контракты: разработчик‑человек пишет 20–30 строк интерфейсов в domain и usecases. Это и есть границы дозволенного для ИИ.
Реализация: агент генерирует DefaultSubscriptionUseCase и SubscriptionController. Код компилируется с первого раза, потому что контракты жестко заданы типами Kotlin.
Проверка: второй агент генерирует property‑based тесты, проверяет на утечки по шаблонам. Человек проверяет критический сценарий с таймаутами.

Заключение: дирижер, а не исполнитель

Возвращаясь к началу статьи: стоит ли бояться ИИ? Нет. Стоит ли учиться с ним работать по‑новому? Однозначно да!

Мир уходит от ремесленного написания тысяч строк однотипного кода. Ценность разработчика смещается в область архитектурных решений, понимания компромиссов и настройки автономных агентов. Это как переход от ручного труда к работе оператора сложного станка с ЧПУ. Вроде бы работу делает станок, но без мастера, который его настроит и проконтролирует, он настрогает брака.

Если вам близок подход «ИИ не вместо разработчика, а как часть инженерной системы», тему можно разобрать глубже на курсе «Проектирование и разработка Kotlin‑бэкенда». Он подойдет тем, кто хочет не просто писать код на Kotlin, а проектировать backend‑сервисы с понятными контрактами, архитектурными границами, тестируемой бизнес‑логикой и устойчивостью к реальным продакшен‑сценариям.

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

6 мая в 19:00 — «Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ‑команды».
_{Разберём, как перейти от идеи к функциональному узлу системы: где помогает ИИ, где нужны архитектурные ограничения и почему разработчик всё равно остается тем, кто управляет процессом.}
20 мая в 19:00 — «Эволюция Kotlin‑разработчика: программирование бизнес‑процессов и управление ИИ‑агентами».
_{Поговорим о том, как меняется роль backend‑разработчика: от ручного написания кода к проектированию процессов, постановке задач агентам и контролю инженерных решений.}

Мама, я не вайб-кодер

Lxx — Thu, 30 Apr 2026 13:01:03 +0000

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

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

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

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

Не написав ни одной строчки кода.

Откуда я смотрю

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

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

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

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

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

И тут в мир ворвались ИИ и агенты. Я начал пользоваться Claude Code – и мой мир перевернулся.

Идея

Кто читал мою предыдущую статью на Хабре, помнит Мимира – моего ИИ-братишку, который помогает мне вести Telegram-канал. Так вот, я подумал: если Мимир работает для меня – он может работать и для других.

Идея проекта простая. AI-помощник для редакторов Telegram-каналов. Подключаешь свои источники – другие каналы и RSS-ленты – а сервис сам читает, скорит посты по «горячести» и присылает в личку готовый черновик: рерайт текста плюс сгенерированная картинка. Тебе остаётся только нажать «Опубликовать» – и пост появляется в канале.

Технологически – смешение всего самого вкусного: Claude Sonnet для рерайта, fal.ai Flux для иллюстраций, MTProto и TDLib для чтения каналов. Чистый хайповый AI-стартап нового поколения.

Неделя

Воскресенье. Дети сели делать уроки, я открыл Клода и набросал спецификацию. К вечеру из неё родилось техническое задание.

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

Вторник, первая половина. Попросил Клода переделать ТЗ в промпт для Claude Code. Это тоже ответственное дело: нужно убедиться, что все мысли и постановки переехали правильно. Что меня поняли. Что ничего лишнего, и ничего не забыто.

Вторник, вторая половина. Мы с Клодом сели программировать. Я контролировал, что создаёт Claude Code – куда идёт, как структурирует код, какие принимает архитектурные решения. Где-то корректировал, где-то учил делать правильно, где-то возвращал и говорил «давай переписывать заново».

Среда, утро. Появился первый драфт сервиса.

Среда, вечер. Первая альфа.

Четверг, утро. Бета-версия. Покрываем тестами.

Четверг, вечер. Крепкий релиз-кандидат. Сделал лендинг.

Пятница, утро. Финальные UI-правки.

Пятница, обед. Зарелизил. Сервис в продакшене.

Архитектура

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

Один сервер – в России, на нём крутится основной продакшн: Rails-приложение, PostgreSQL, Redis, Sidekiq для фоновых задач, MinIO для хранения картинок, nginx с SSL – на нём живут пользователи, к нему подключается домен mimirjotun.ru.

Второй сервер – в Амстердаме, на нём отдельный микросервис на Python с FastAPI, который умеет ходить в Telegram по протоколу MTProto и читать каналы.

Между серверами – overlay-сеть на Tailscale, через которую они общаются друг с другом так, как будто стоят в одной стойке.

Сервис интегрируется с внешним миром: Anthropic Claude (рерайт постов), fal.ai Flux (генерация картинок), Telegram Bot API (доставка драфтов в личку), Telegram Login (вход в веб через виджет), Telegram MTProto и tdlib (чтение каналов). Внутри – десятки сервисных классов, фоновые джобы, очереди, скоринг постов с учётом просмотров, форвардов, реакций и реплаев. Админка с Basic Auth. Sidekiq Web для мониторинга. Sentry для ошибок. Lograge для логов. Bullet для отлова N+1. 279 зелёных тестов на RSpec.

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

А теперь следите за руками

Всё, что я только что описал – Rails-приложение, две базы, фоновый процессинг, отдельный микросервис на Python в другой стране, туннель между ними, интеграции с тремя внешними API, тесты, мониторинг, деплой – раньше для меня означало бы недели работы команды разработчиков. Постановку задачи, разделение по людям, код-ревью, отладку, интеграционное тестирование. Это нормальный такой объём работ для хорошей и опытной команды с архитектором во главе.

Я собрал это один. За неделю. По два-три часа в день – и то с трудом наскребая эти часы между созвонами, рабочими решениями, сериалами с женой и доткой после отбоя. Никто не освобождал меня от обязанностей CEO. У меня по-прежнему по 6-8 митингов в день. Я не уходил в отпуск, не запирался в кабинете на неделю, не выбивал у себя «творческое время». Я просто между делами открывал Claude Code и продолжал с того места, где остановился.

И на выходе – работающий сервис. Не игрушка, не лендинг, не «MVP на коленке». Полноценный продукт со своей админкой, тестами и нормальным деплоем.

Мама, я не вайб-кодер!

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

В интернете сейчас много разговоров про «вайб-кодинг» – когда чувак, не умеющий программировать, описывает агенту что хочет, и агент ему что-то выкатывает. Чаще всего это простой лендинг, поделка, прикольная игрушка. И автор такой: «Смотрите, я разработчик! Я сделал продукт!»

Так вот, я не вайб-кодил.

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

Только я не писал код руками. Я занимался тем, что в индустрии начинают называть агентной разработкой – когда ты управляешь агентом, как тимлид тремя сильными мидлами: задаёшь задачу, проверяешь, корректируешь, иногда переписываешь. Только эти мидлы не устают, не отвлекаются и пишут в десять раз быстрее любого моего разработчика. Но я остаюсь архитектором продукта от первой строчки ТЗ до последней строчки в коде. Я понимаю каждое решение. Я знаю, почему здесь Sidekiq, а не Solid Queue. Почему PostgreSQL, а не MongoDB. Почему туннель через Tailscale, а не прямой VPN. Почему Hotwire, а не React.

Агент – это инструмент. Очень умный, очень быстрый, очень мощный. Но инструмент. И именно я решаю, что он делает.

Возвращение в игру

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

Это другая профессия, которой раньше не существовало.

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

Смена технологического уклада обычно играет против старшего поколения. Ты не успеваешь за молодыми, у которых в руках свежие инструменты и новые фреймворки. Так было всегда. А сейчас, кажется, наоборот. Эпоха разворачивается в пользу опытных мужиков, которые прошли весь путь разработки. Все думали, что пора готовиться к пенсии и что наш опыт уже не очень-то и нужен. А оказалось – нам просто не хватало одного мощного инструмента, который сконвертирует этот опыт в профит!

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

Похоже, что мне и моему поколению «компьютерщиков» снова повезло?

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

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

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

Сопричастность 2.0.

Обсудим?

Олег Балбеков, @obalbekov

Тестируем программы для вскрытия биткойн-головоломок

Thu, 30 Apr 2026 13:00:42 +0000

Тест программ-решателей биткойн-головоломок

После того как я написал статью «Головоломка на 1000 BTC» мне стали писать в личку авторы программ для их решения. В этой статье я расскажу о целом семействе таких программ и протестирую все те, что попали мне в руки, на скорость.

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

Речь идёт про головоломки, у которых известен только BTC-адрес формата P2PKH, но не известен публичный ключ. Это головоломки с номерами 71-159, кроме тех, чей номер кратен 5. У головоломок кратных 5 известен публичный ключ и для них применяются совсем другие алгоритмы — кенгуру Полларда или BSGS, на порядки более быстрые, чем bruteforce. Самая лёгкая ещё не вскрытая головоломка с известным публичным ключом — 135.

Краткая хронология программ

Я не претендую на полное знание этой сферы, поэтому, если я что-то упустил, , пишите в личку или в комментарии

Год начала разработки	Программа	Автор	Платформа	Язык
2018	BitCrack	brichard19	CUDA + OpenCL	C++
2019	VanitySearch	JeanLucPons	CPU + CUDA	C++
2021	KeyHunt	albertobsd	CPU	C++
2021	KeyHunt-Cuda	Qalander	CUDA	C++
2024	Cyclone	dookoo2	CPU (AVX2/512)	C++
2024	ecloop	vladkens	CPU	чистый C
2025	CUDACyclone	dookoo2	CUDA	CUDA
2025	BtcMole	keymole	CPU (x86-64, ARM64) + CUDA + AMDGPU	closed source

BitCrack (2018)

Старейшина жанра. Первая массовая программа для перебора приватных ключей на GPU, поддерживает и CUDA, и OpenCL. Сегодня морально устарела — отстаёт от лидеров примерно в 5 раз. Технические причины разберём в разделе «Что используют авторы для ускорения перебора».

VanitySearch (2019)

Программа Жан-Люка Понса (JeanLucPons) задумывалась для генерации «красивых» биткойн-адресов (1Love…, 1Btc…), но архитектурно оказалась настолько удачна, что почти все последующие проекты связанные с биткойн-головоломками — её прямые потомки или форки. Канонические трюки массовой инверсии Монтгомери и работы с PTX зародились именно здесь.

KeyHunt (2021)

Программа-комбайн для CPU от Alberto: поддерживает Bloom-фильтр по списку адресов, режим BSGS (Baby-step Giant-step) для подбора по известному pubkey, несколько типов целей (BTC, ETH).

KeyHunt-Cuda (2021)

Порт логики KeyHunt + VanitySearch на CUDA от Qalander. Долгое время держался в топе по CUDA-производительности.

Cyclone (2024)

Современная CPU-перебиралка от @dookoo2. Некоторым эта программа знакома из комментариев к моей статье «Головоломка на 1000 BTC» — там автор объясняет принятые им архитектурные решения. За точку отсчёта в наших таблицах берётся именно Cyclone.

ecloop (2024)

Минималистичный C-проект от русскоязычного разработчика vladkens: main.c + несколько библиотек для хэшей, минимум зависимостей.

CUDACyclone (2025)

CUDA-версия Cyclone от того же @dookoo2.

BtcMole (2025)

Свежий проект от автора под ником keymole. Распространяется в виде бинарных сборок. Поддерживает Windows, Linux; процессоры amd64, arm64, arm; видеокарты Nvidia, AMD.

Методика бенчмаркинга

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

Каждая из этих программ во время работы рисует на экране собственную скорость в Mkey/s (миллионах ключей в секунду). Доверять этим цифрам нельзя по нескольким причинам:

Скам в крипте — обыденность. Цифру можно нарисовать любую.
Холодный VS горячий старт. Первые несколько секунд GPU/CPU показывают результат заметно выше среднего рабочего.
Внутренние счётчики бывают просто кривые.

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

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

Размер выборки: почему 100 итераций. Сначала я делал по 10–20 прогонов на программу. На таких выборках одна «неудачная» позиция ключа могла кардинально перевернуть таблицу: разные программы сканируют диапазон в разном порядке (последовательно, со смещением, случайно), и один и тот же случайный ключ оказывается для одной программы «на старте», а для другой «в самом конце». Один такой выброс при 10 запусках сдвигал среднее на десятки процентов. Мне пришлось увеличить поисковые интервалы примерно вдвое относительно первой версии бенча и поднять число прогонов до 100 на каждую программу — итоговый бенчмарк работал всю ночь. Стандартная ошибка среднего теперь ≈ σ/√100 ≈ σ/10, чего вполне достаточно для статистической достоверности.

Репозиторий бенчмарка

Скрипт и все патчи доступны на GitHub.

Дизайнерские решения в `bench.py`

Все программы — с настройками по умолчанию. Я сознательно не подбирал размер батча, число потоков, grid/slices и т.п. — предполагаю, что авторы выставляют оптимальные настройки по умолчанию. Точные команды можно посмотреть в скрипте.
Один источник случайности. SEED фиксирован (SEED = 42), так что на повторных запусках набор ключей-целей идентичный — можно честно сравнивать прогон с прогоном.
Per-device параметры. Для CPU и CUDA задаются разные интервалы (2^33 и 2^35 соответственно) и одинаковое число итераций (100). Для AMDGPU — короткий интервал и мало итераций (см. соответствующий раздел).
Единый разбор вывода. Каждой программе сопоставлен success_re — регулярное выражение, по которому распознаётся «нашёл этот ключ».
Тайм-аут с принудительным завершением. Если программа уходит в бесконечный цикл или зависает, через BENCH_TIMEOUT секунд ей шлётся SIGTERM, потом SIGKILL. Итерация засчитывается как FAIL.
Изоляция подпрограмм. Каждая программа клонируется и собирается в отдельной папке work/<name>/ (кроме BtcMole — cpu/cuda/amdgpu делят одну папку, так как репозиторий один на все версии).
Патчи под сборку. Часть программ из обзора без правок просто не собирается на свежем GCC/CUDA/ROCm. Для таких случаев в бенче лежат собственные патчи (bug-fix Makefile’ов, замены deprecated CUDA-API, правки include’ов), которые применяются перед сборкой.

Запуск: ./bench.py --device cpu, ./bench.py --device cuda или ./bench.py --device amdgpu. Перед первым запуском — --prepare (clone + build). Все настройки (число итераций, прогревов, размер интервала, seed) — вверху скрипта.

Сам скрипт bench.py написан с помощью Claude Code.

Оборудование стенда

CPU: AMD EPYC 7C13 (64 ядра / 128 потоков, 2.45 GHz base)
GPU: NVIDIA CMP 90HX (Ampere, sm_86, 50 SM, 1530 MHz @ 200 W power-limit)
AMDGPU: Radeon R9 Fury (gfx803, 56 CUs)
OS: Linux (Calculate Linux, kernel 6.18)

Тестирование CPU-программ

Особенности тестирования на CPU

Эти программы рассчитаны на круглосуточную работу — в реальности процессор нагрет, может сбрасывать частоту. Холодный замер дал бы завышенные цифры. Поэтому перед каждой программой идёт прогревочный прогон, результаты которого не учитываются (константа WARMUP_PER_DEVICE в bench.py).

Сколько потоков отдаётся программе. Каждой CPU-программе передаётся 115 потоков из 128 доступных (~90%). Оставшиеся 13 потоков остаются за графической оболочкой, фоновыми службами, самим bench.py и т.п. Если отдать программе все 128, она будет конкурировать за процессорное время с GUI и системой — итог станет менее точным.

Важная оговорка про SIMD. На моей машине нет AVX-512, есть только AVX-2. Поэтому Cyclone собирается и тестируется именно в этом варианте. Бенчмарк ARM64 я тоже не проводил.

Тестируемые программы

Программа	Год разработки	Язык	Источник
KeyHunt	2021	C++	GitHub
Cyclone	2024	C++	GitHub
ecloop	2024	C	GitHub
BtcMole (CPU)	2025	?	GitHub

Параметры прогона

Диапазон поиска: [0x200000000, 0x3ffffffff] (size = 2^33 ≈ 8.6 миллиарда ключей).
Ключи: 100 (разные случайные внутри диапазона).
Эталон скорости: Cyclone (за 1.00× принят его суммарный результат).

Результаты

Программа	OK / FAIL	Σ время (s)	Avg (s)	Скорость (× эталон)
BtcMole (CPU)	100 / 0	1111.15	11.11	1.32
ecloop	100 / 0	1384.45	13.84	1.06
Cyclone (AVX-2)	100 / 0	1469.36	14.69	1.00
KeyHunt	100 / 0	3691.10	36.91	0.40

Тестирование GPU-программ

Особенности тестирования на GPU

Холодная карта ≠ рабочая карта: на холодной частота держится на разгонной, после прогрева начинаются сброс частот (так называемый тротлинг — защита от перегрева). Любитель публиковать рекорды просто запустит свою программу первой. Чтобы убрать этот эффект, частота и power limit GPU зафиксированы:

CMP 90HX (NVIDIA): power-limit 200 W, clock 1530 MHz — при этих параметрах частота не сбрасывается, сколько бы карта ни работала. Откуда взялись именно такие значения — подробно разобрано в моей предыдущей статье «Максимально выгодно используем видеокарты с помощью школьной формулы из физики».

Плюс 2 прогревочных прогона перед общим тестированием, как и на CPU.

Что заявляют сами авторы

Заявленные скорости на топовой RTX 5090 (Blackwell, sm_120):

CycloneCUDA (dookoo2) — 6200 Mkey/s.
BtcMole (keymole) — 9520 Mkey/s.

Значения приведены для справки, в тестах мы на них не ориентируемся.

Карты Nvidia

Тестируемые программы

Программа	Год разработки	Язык	Источник
BitCrack (CUDA)	2018	C++ / CUDA	GitHub
KeyHunt-Cuda	2021	C++ / CUDA	GitHub
CUDACyclone	2025	CUDA	GitHub
BtcMole (CUDA)	2025	закрытый	GitHub
KeyKiller-Cuda	2024	C++ / CUDA	GitLab
KeyScanner	2024	C++ / CUDA	GitHub

Параметры прогона

Диапазон поиска: [0x800000000, 0xfffffffff] (size = 2^35 ≈ 34.4 миллиарда ключей).
Ключи: 100.
Эталон скорости: CUDACyclone (за 1.00× принят его суммарный результат).
Карта: NVIDIA CMP 90HX (sm_86, 50 SM, 200 W @ 1530 MHz).

Результаты

Программа	OK / FAIL	Σ время (s)	Avg (s)	Скорость (× эталон)
BtcMole (CUDA)	100 / 0	901.99	9.02	1.46
KeyHunt-Cuda	100 / 0	1302.08	13.02	1.01
CUDACyclone	100 / 0	1320.70	13.21	1.00
KeyKiller-Cuda	100 / 0	2952.25	29.52	0.45
KeyScanner	92 / 8	6166.90	67.03	0.21
BitCrack (CUDA)	100 / 0	6289.19	62.89	0.21

Карты AMD

Единственная программа, авторы которой заморочились с поддержкой AMD-карт — это BtcMole. Остальные авторы живут в парадигме «есть только NVIDIA».

Да, есть ещё clBitCrack (OpenCL), внешне работающая под AMD, но в реальности она совсем не ищет ключи. Она сдулась на первом же ключе из бенча: диапазон 0x40000000:0x7fffffff (всего 2³⁰ ≈ 1.07 млрд ключей), цель — адрес 1Q4U2cBxgduTyEiWFWBF16tjsb4hR7zee9, известный приватный ключ 0x6d06ef13. BtcMole-AMDGPU нашёл ключ за секунды. clBitCrack прокрутил весь диапазон и завершился сообщением Reached end of keyspace — ключ не найден. То же самое — на остальных трёх итерациях. Похоже, в OpenCL-ядре BitCrack есть баг арифметики или хеширования. Поэтому скрипт пометил все запуски clBitCrack как FAIL.

Грубая оценка скорости clBitCrack. На независимом тесте на AMD RX 580 clBitCrack показывает ~9.42 Mkey/s, btcmole-AMDGPU на той же карте — ~240 Mkey/s. То есть даже если бы clBitCrack находил ключи, отрыв был бы в 25 раз в пользу BtcMole. Это уже не «оптимизация», а просто другая весовая категория.

Тестируемые программы

Программа	Год разработки	Язык	Источник
BitCrack (OpenCL)	2018	C++ / OpenCL	GitHub
BtcMole (AMDGPU)	2025	закрытый	GitHub

Параметры прогона

Диапазон поиска: [0x40000000, 0x7fffffff] (size = 2^30 ≈ 1.07 миллиарда ключей) — короткий, потому что BitCrack-OpenCL заведомо FAIL и тратить на него больше времени смысла нет.
Ключи: 4 — достаточно для проверки работоспособности BtcMole-AMDGPU, не претендует на статистическую значимость.
Карта: AMD Radeon RX 580.

Результаты

Программа	OK / FAIL	Σ время (s)	Avg (s)
BtcMole (AMDGPU)	4 / 0	16.73	4.18
BitCrack (OpenCL)	0 / 4	—	—

Если кто-то знает другие живые программы-решатели для карт AMD — сообщите мне.

Что используют авторы для ускорения перебора

Все рассматриваемые проекты решают одну и ту же задачу — массовое сложение точек на кривой secp256k1, хеширование SHA-256 + RIPEMD-160, сравнение хэша с целевым. Ниже — основные технические приёмы, упорядоченные по программам.

BitCrack — «в лоб», без массовой инверсии

Старейшина. Считает каждое сложение точек отдельно. На каждом шаге — инверсия по модулю (InvMod в конечном поле). Это самая дорогая операция в EC-арифметике (в ~60 раз медленнее умножения). VanitySearch и все последующие снижают эту цену через одну инверсию на большой батч точек (массовая инверсия) — отсюда и пятикратное отставание BitCrack.

VanitySearch — массовая инверсия Монтгомери

Здесь нужно отдельно сказать спасибо Жан-Люку Понсу (JeanLucPons на GitHub). Его проект VanitySearch 2019 года — это, без преувеличения, фундамент всей программ-решателей. По моим оценкам, больше 90% всех CPU- и GPU-программ для перебора приватных ключей так или иначе содержат куски его C+±кода: классы Int, IntGroup, IntMod, Point, SECP256K1, файлы Random.cpp, базовые PTX-макросы для 256-битной арифметики. Это видно невооружённым глазом — открываешь репозиторий любого «нового» решателя, а внутри лежит копия этих файлов с минимальными правками. KeyHunt, KeyHunt-Cuda, KeyKiller, KeyScanner, Cyclone — все они стоят на плечах этого человека.

Ценность работы Понса не в одной идее, а в их сочетании: он принёс в нишу высокопроизводительный 256-битный классы Int и IntMod для 256-битной арифметики, компактную реализацию EC-арифметики над secp256k1 без зависимости от тяжёлого OpenSSL/libsecp256k1. Запрограммировал на C++ передовой алгоритм инверсии DivStep62, Монтгомери-батчи для обработки точек.

Идея массовой инверсии: копим произведение разностей (x_i − x_target), делаем единственный InvMod от полного произведения, потом «раскручиваем» обратно, получая инверсию каждой разности по очереди. Эффективная стоимость самой дорогой операции в EC-арифметике падает до 3 умножений на точку. Эту схему сейчас использует каждая CUDA-программа из обзора, кроме BitCrack — и каждая вторая CPU-программа.

То, что один человек проделал такую колоссальную работу и выложил её под свободной лицензией, — большое везение для всех. Без VanitySearch не было бы ни KeyHunt-Cuda, ни Cyclone, ни большинства проектов, которые мы здесь сравниваем.

KeyHunt — гибкость и BSGS

KeyHunt берёт код secp256k1 от Жан-Люка Понса, но накручивает поверх Bloom-фильтр (для проверки по большому списку адресов) и BSGS (для поиска по известному pubkey). Никаких AVX, никакой массовой инверсии в основных режимах перебора. Зато умеет: BTC + ETH, P2PKH + P2SH + bech32, файлы со списками целей. Сила этой программы в алгоритме BabyStep-GiantStep (работает с известными публичными ключами), в простом брутфорсе P2PKH она работает хорошо, но отстаёт от лидеров.

KeyHunt-Cuda и CUDACyclone — inline PTX

На первый взгляд — там C++ код, но если присмотреться, то многие макросы разворачиваются в inline PTX-ассемблер для 256-битной арифметики:

#define UADDO(c, a, b) asm volatile ("add.cc.u64 %0, %1, %2;" : "=l"(c) : "l"(a), "l"(b) : "memory");
#define UADDC(c, a, b) asm volatile ("addc.cc.u64 %0, %1, %2;" : "=l"(c) : "l"(a), "l"(b) : "memory");

CUDACyclone дополнительно реализует батчевую инверсию — тот же приём массовой инверсии Монтгомери, перенесённый в ядро. По умолчанию: батч в 128 точек.

Cyclone — AVX-2 интринсики для хешей

Cyclone использует __m256i напрямую: SHA-256 и RIPEMD-160 для 8 параллельных потоков сжимаются в одно 256-битное регистр-поле. Файлы sha256_avx2.cpp и ripemd160_avx2.cpp — почти учебник по SIMD-хешированию:

#define Maj(x, y, z) _mm256_or_si256(_mm256_and_si256(x, y), _mm256_and_si256(z, _mm256_or_si256(x, y)))
#define Ch(x, y, z)  _mm256_xor_si256(_mm256_and_si256(x, y), _mm256_andnot_si256(x, z))
#define ROR(x, n)    _mm256_or_si256(_mm256_srli_epi32(x, n), _mm256_slli_epi32(x, 32 - n))

Модулярная арифметика — на стандартных C+±операторах + наработки Жана-Люка. Есть отдельный AVX-512-вариант для процессоров с поддержкой AVX-512.

ecloop — компиляторные builtin’ы + AVX2

ecloop сознательно отказался от inline-ассемблера, но взял AVX2-интринсики. 256-битная арифметика — через GCC/Clang-builtin’ы:

__builtin_addcll(x, y, carryin, &carryout)   // add-with-carry
__builtin_uaddll_overflow(x, y, &rs)         // overflow detection

Расчёт на то, что современный clang сам поднимет это в adc/adcx-инструкции (вместо ручного inline-asm).

Хеши — полноценный AVX2 и AVX-512 в lib/rmd160s.c: SHA-256 и RIPEMD-160 параллельно по 8 потоков через __m256i и т.п. Размер батча для инверсии — 2048 точек. Итог — 1.06× от Cyclone при компактном коде.

BtcMole — возможные оптимизации

С BtcMole сложнее — исходники закрыты, все суждения только по бинарникам. Что можно утверждать наверняка:

Аппаратная поддержка x86-64 + ARM64 — обычно достигается компиляторными SIMD-интринсиками (__m256i/__m512i под Intel, vqaddq_*/vmlal_* под NEON), либо отдельными asm-вставками для каждой архитектуры. Раз скорость на x86 опережает Cyclone, велика вероятность использования более подходящих интрисинков и ручных asm-вставок.
CUDA-сборка единая для sm_50…sm_120 — это Fat Binary с заранее скомпилированными .cubin-ами. Внутри почти наверняка inline PTX (как у конкурентов) или даже SASS (если автор пошёл дорогой Retired Coder).
AMDGPU-сборка покрывает GCN 3-4, CDNA, RDNA1-4
Массовая инверсия Монтгомери — с такой скоростью без неё нельзя; вопрос только в размере группы.

Fat Binary — почему некоторые программы такие большие

Технология Fat Binary в CUDA-мире — это упаковка нескольких прекомпилированных .cubin-ов под разные compute capabilities в один исполняемый файл, плюс PTX-код для архитектур, для которых нет предкомпилированного ядра. Преимущество: один бинарник работает «и на 1080Ti, и на RTX 4090, и на новых Blackwell без перекомпиляции». Недостаток — размер.

Программа	Размер бинарника	Архитектуры в FatBin
KeyHunt-Cuda	~1.5 МБ	одна (выбирается через `make ccap=86`)
CUDACyclone	~2.6 МБ	три (sm_75, sm_86, sm_89)
BtcMole (GPU)	~16 МБ	11 NVIDIA + ~10 AMD

CycloneCUDA и BtcMole заработали без всяких патчей. KeyHunt-Cuda требует ручной сборки под целевую архитектуру (make ccap=89) — для пользователя без NVCC это барьер.

Сводка по стеку оптимизаций

Программа	Mass-inverse	Inline asm	SIMD-хеши	Fat Binary	Особое
BitCrack	❌	❌	❌	❌	—
VanitySearch	✅ (родоначальник)	PTX	—	❌	—
KeyHunt	в спец-режимах	❌	❌	❌	BSGS, Bloom
KeyHunt-Cuda	✅	PTX	—	❌	—
Cyclone	✅	❌	AVX2/512	n/a	—
ecloop	✅ (2048)	builtin’ы	AVX2	n/a	компактность
CUDACyclone	✅ (один-на-батч)	PTX	—	✅ (3 arch)	настраиваемые параметры запуска
BtcMole	✅	предположительно да	предположительно да	✅ (~20 arch)	мульти-платформа CPU+CUDA+AMDGPU

Двигаемся к потолку производительности

Retired Coder и проект RCAsm

Разработчик под ником Retired Coder (RC) известен как автор серии быстрых решателей биткойн-головоломок по алгоритму кенгуру Полларда. На днях он опубликовал проект RCAsm — DSL-обёртку над cuAssembler для написания CUDA-ядер прямо на уровне SASS, без участия PTX и nvcc.

Зачем это нужно? Цитирую RC из README:

PTX is not powerful enough: 1. You still cannot control registers usage. 2. PTX does not provide all instructions, some of them can be really important. 3. There is no way to declare fast functions. 4. There is no way to use uniform registers and instructions directly. 5. There is no way to specify control codes. 6. There is no good management for carry flags. 7. You have to check what SASS is generated every time.

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

RCAsm обходит это, давая прямой доступ к SASS ценой головной боли — синтаксис SASS намного ужаснее обычного ассемблера.

Под капотом — модифицированный cuAssembler и Python-обёртка. Требуется CUDA v12.8 (другие версии не поддерживаются).

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

Это и есть последнее слово индустрии для перебора приватных ключей. Если кто-то решит побить рекорды Retired Coder (19 Mkey/s на 5090 в алгоритме кенгуру Полларда), наверное, ему придётся идти тем же путём.

Команды для индивидуального поиска

Если хочется попробовать всё-таки вскрыть нерешённую головоломку — это для тех, кто верит в удачу или у кого куча собственного железа (см. ниже про математику лотереи). Команды ниже — для головоломки № 71 (BTC-адрес 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU, диапазон 2^70..2^71-1). Подставьте свой кошелёк/диапазон по аналогии для других номеров.

CPU

# Cyclone (AVX2)
./Cyclone -t 24 -r 400000000000000000:7fffffffffffffffff \
  -a 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

# ecloop — режим mul (умножение точек)
./ecloop mul -t 24 -f target.h160 \
  -r 400000000000000000:7fffffffffffffffff

# keyhunt — последовательный режим по адресу
./keyhunt -m address -t 24 -l c \
  -r 400000000000000000:7fffffffffffffffff \
  -a 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

# BtcMole — единый бинарник для всех устройств
./bm bf -pz 71 +cpu              # только CPU
./bm bf -pz 71 +cpu:50%          # 50% ядер
./bm bf --address 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU \
        --range 400000000000000000:7fffffffffffffffff +cpu

CUDA

CUDACyclone

./CUDACyclone --address 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU \
  --range 400000000000000000:7fffffffffffffffff \
  --grid 128,8 --slices 64

KeyHunt-Cuda

./KeyHunt -t 0 -g --gpui 0 --gpux 256,256 \
  -m address -l c \
  -r 400000000000000000:7fffffffffffffffff \
  1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

KeyKiller-Cuda — принимает только размер диапазона в битах

./kk -r 71 -a 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

KeyScanner

./keyscanner -a 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU \
  -r 400000000000000000:7fffffffffffffffff

BitCrack (CUDA)

./cuBitCrack --keyspace 400000000000000000:7fffffffffffffffff \
  -o found.txt 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

BtcMole — CUDA с тонкой настройкой числа SM

./bm bf -pz 71 -cpu +cuda            # все SM
./bm bf -pz 71 -cpu +cuda:30,40      # 30 SM на карте 0, 40 на карте 1

AMDGPU

BtcMole — единственный реально работающий вариант на картах AMD.

./bm bf -pz 71 -cpu -cuda +amdgpu
# Оставляем 20% GPU для интерфейса и роликов
./bm bf -pz 71 -cpu -cuda +amdgpu:80%

Сохранение прогресса между рестартами

После проверки CLI каждой программы и кода — поддержка чек-поинтов есть у большего числа проектов, чем казалось:

Программа	Сохраняет прогресс с возможностью продолжения	Как включить
BitCrack	да	`--continue FILE`
BtcMole	да, для каждого устройства при диапазонах размером в 2^40 ключей и выше	автоматически подхватывается
Cyclone (CPU)	пишет log в `progress.txt` каждые 5 мин, ручное возобновление
KeyKiller-Cuda	да (только в range-режиме, не в random)	флаг `-b` («backup mode»)
KeyScanner	да (только в range-режиме)	`-n N` — чек-поинт каждые N минут
KeyHunt (CPU)	нет
KeyHunt-Cuda	нет
CUDACyclone	нет
ecloop	нет

Вероятность открытия головоломки

Если у вас нет сотен видеокарт, то вскрытие нерешённой головоломки (№ 71, 72, …) — это лотерея. Победит либо тот, кто сильно раньше начал, либо тот, у кого больше железок.

Поясню масштаб. Размер диапазона головоломки № 71 — 2^70 ≈ 1.18 × 10^21 ключей. Производительность одной CMP 90HX в btcmole-cuda ≈ 1950 Mkeys/s (среднее по нашему бенчу). Одной картой полный перебор 50% интервала займёт 9 599 лет. То есть если вы 1 год перебираете, то у вас примерно 1 шанс из 19 000, что именно вы вскроете головоломку. Это выше, чем сорвать джекпот в лотерею, но всё равно мало.

Заключение

Победители:

Среди программ с открытым кодом:
- На CPU — ecloop (1.06× относительно Cyclone). Cyclone почти не уступает (1.00×).
- На CUDA — KeyHunt-Cuda (1.01×) с минимальным отрывом от CUDACyclone (1.00×); фактически паритет.
Среди всех программ (включая закрытый код):
- На CPU — btcmole (1.32× относительно Cyclone).
- На CUDA — btcmole (1.46× относительно CUDACyclone).
- На AMD GPU — btcmole (единственный, кто работает; остальные либо не пытались поддержать AMD, либо не работают на свежем ROCm).

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

Про внутренние «попугаи». В целом, к моему удивлению, заявленные авторами цифры более или менее соответствуют реальности — относительный расклад программ на «их» Mkey/s примерно совпадает с тем, что показывает наш честный wall-clock-бенчмарк. Единственное яркое исключение — KeyKiller-Cuda: там внутренний счётчик завышал результат раза в полтора (учитывалось только GPU-время, без CPU-составляющей), и без патча программа выглядела бы намного сильнее, чем есть. У CUDACyclone цифры в Mkey/s заметно «пляшут» от запуска к запуску, но среднее всё равно близко к реальной скорости. Так что общее правило «не верьте экранным цифрам» сохраняется, но конкретно у этих авторов — без злого умысла.

Индустрия не стоит на месте. Retired Coder (человек решивший 120, 125 и 130 головоломки) уже показал, что чистый SASS даёт ещё 15-25 процентов по сравнению с PTX. Правда, по его словам, программироание на SASS несёт серьёзные риски потери психического здоровья.

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

Я прошу прощения у авторов непротестированных программ — я протестировал всё, что нашёл из поиска гугла и телеграм-чатов. Хотя, уверен, что есть масса авторов со своими самописными решениями, которые не попали в обзор.

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

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

Всем цифровым кладоискателям — удачи!

Xcode Simulator — Ускоряем прогон тестов на CI + Fastlane

house2008 — Thu, 30 Apr 2026 13:00:09 +0000

Речь пойдет про наш любимый fastlane, если вы являетесь специалистом по Maraphon или Emcee, то, возможно, мои советы для вас окажутся больше вредными / нелепыми / и порой даже забывными - не обессудьте.

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

И вот что я увидел в Fastfile

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

iOS проект (Swift + SwiftUI + UIKit + SwiftPM)
Отдельная джоба для юнит тестов
Отдельная джоба для UI тестов на последней ОС (на момент написания статьи это iOS 26.4.1)
Отдельная джоба для UI тестов для iOS 18.6 (UI для iOS 26 и 18 сильно отличается, поэтому тестами покрываются обе версии, чтобы отлавливать регрессии на старых осях)
Джобы в пайплайне идут последовательно (для GitLab concurrent = 1)
Испытуемый проект для статьи это не оригинальный рабочий проект, так как оригинальный имеет очень много тестов и кода для сборки, тогда бы исследование для статьи вышло бы в очень долгий процесс, но испытуемый проект очень похож на боевой по структуре и самое важное по структуре тестов и их интеграции на CI

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

А fastlane слудующим образом:

 private_lane :run_testing do |options|
    scan(
        project: project,
        scheme: options[:scheme],
        testplan: options[:testplan],
        destination: "platform=iOS Simulator,id=#{options[:uuid]}",
        skip_detect_devices: true,
        code_coverage: false,
        derived_data_path: derived_data_path,
        disable_concurrent_testing: true
    )
end

  lane :run_unit_tests do
    run_testing(scheme: "AppTests", testplan: "UnitTests", uuid: "123..")
  end

  lane :run_ui_tests_26_4 do
    run_testing(scheme: "AppUITests", testplan: "UITests", uuid: "123..")
  end

  lane :run_ui_tests_18_6 do
    run_testing(scheme: "AppUITests", testplan: "UITests", uuid: "456..")
  end

Обычный пускатель тестов без излишеств в каждом втором туториале про fastlane, где под капотом вот такая xcodebuild команда:

xcodebuild \
    -scheme AppTests \
    -project App.xcodeproj \
    -derivedDataPath DerivedData/App-biooakmzntobceawoboqmizvekct \
    -destination 'platform=iOS Simulator,id=5F53A860-544D-4A6F-9F1A-C414CC89DDA5' \
    -disable-concurrent-testing \
    -enableCodeCoverage NO \
    -testPlan 'AppTests' \
    build test

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

Суммарное время вышло 11 минут и 4 секунды (запускал пайплайн несколько раз и взял среднее), зафиксируем это время как время отсчета до наших изменений.

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

Собираем приложение один раз и раздаем тестовым задачам

Для этого будем использовать новый флаг -testProductsPath из Xcode 13.3, который описан следующим образом:

xcodebuild now supports an .xctestproducts bundle format for the build-for-testing and test-without-building actions. Using a bundle makes it easier to run tests, particularly when transporting tests between systems. Use the new -testProductsPath argument to set the path to the bundle.

Простым языком, для поиска приложения для запуска тестов когда используется флаг build-for-testing теперь не нужно исследовать DerivedData, xcodebuild просто положит финальную сборку в специальную .xctestproducts директорию, которую потом нужно передать снова через -testProductsPath + test-without-building для запуска тестов.

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

  private_lane :build_for_testing do |options|
    # создаем `.xctestproducts` прям в DerivedData директории
    product_path = "#{File.join(derived_data_path, "#{options[:scheme]}")}.xctestproducts"
    scan(
      project: project,
      scheme: options[:scheme],
      sdk: "iphonesimulator",
      destination: "generic/platform=iOS Simulator",
      # Тут важно это выставить `true`
      build_for_testing: true,
      code_coverage: false,
      derived_data_path: derived_data_path,
      # Так как fastlane не поддерживает `-testProductsPath` передаем через `xcargs`
      xcargs: "-testProductsPath #{product_path}"
    )

    # Так как после сборки `.xctestproducts` также содержит артефакты сборки,
    # то мы удаляем лишнее, так как нам нужно только само приложение и пускатель UI тестов
    tests_files = [
      "App.app",
      "AppUITests-Runner.app"
    ]
    derived_data = File.join(product_path, "Binaries/0/Debug-iphonesimulator")
    Dir.children(derived_data).each do |name|
      if tests_files.any?(name)
        next
      else
        path = "#{derived_data}/#{name}"
        if File.directory?(path)
          FileUtils.rm_rf(path)
        else
          File.delete(path)
        end
      end
    end

    # Директория артефактов, это директория сборок, которую мы будем передавать
    # тестовым джобам, которые будут ее передавать в `-testProductsPath` при запуске тестов
    artifacts_path = File.join(ENV["HOME"], "builds/artifacts/#{options[:uname]}")
    if !File.exist?(artifacts_path)
      Dir.mkdir(artifacts_path)
    end
    # Перемещаем `.xctestproducts` из Xcode DerivedData в артефакты
    FileUtils.mv(product_path, artifacts_path)
    # Возвращаем путь до `.xctestproducts` из артефактов
    File.join(artifacts_path, File.basename(product_path))
  end

Мы описали lane который:

Соберет приложение в виде ${SCHEME}.xctestproducts для тестов
Поместит ${SCHEME}.xctestproducts в артефакты (специальную папку на CI)
Вернет из функции путь до ${SCHEME}.xctestproducts в артефактах

В моем конкретно примере, этот lane вернет такого вида путь $HOME/builds/artifacts/2026.04.28_01-44-11-883074-+0700/${SCHEME}.xctestproducts. Под капотом xcodebuild комнада для сборки продукта (.xctestproducts) выглядит так:

xcodebuild \
    -scheme AppTests \
    -project App.xcodeproj \
    -derivedDataPath DerivedData/App-biooakmzntobceawoboqmizvekct \
    -sdk 'iphonesimulator' \
    -destination 'generic/platform=iOS Simulator' \
    -enableCodeCoverage NO \
    -testProductsPath DerivedData/App-biooakmzntobceawoboqmizvekct/AppTests.xctestproducts \
    build-for-testing

Теперь напишем lane, который собирает продукты для юнит тестов и UI тестов:

lane :build_tests_products do
    # Выставляем одинаковое имя, чтобы все продукты этой джобы лежали в одной директории
    uname = "#{Time.now.strftime("%Y.%m.%d_%H-%M-%S-%6N-%z")}"
    build_for_testing(
        scheme: "AppTests",
        uname: uname
    )
    products = build_for_testing(
        scheme: "AppUITests",
        uname: uname
    )
    File.write(File.join(project_dir, "products.txt"), File.dirname(products))
end

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

File.write(File.join(project_dir, "products.txt"), File.dirname(products))

Так как у нас будет отдельная джоба для сборки приложения, то нам затем нужно передать эти данные дочерним тестовым процессам. Идеально это всё делать “по-взрослому”, заархивировать данные и загрузить в artifactory на aws например, откуда дочерние джобы себе скачают, что им нужно. Но для тестового примера или когда у вас CI это просто одна физическая машина, то проще результаты сборки сохранить тут же локально и просто передать путь до них через простой текстовый файл который загрузить в тот же artifactory, при этом нужно загрузить только этот небольшой файл, а не огромный архив, и потом ничего долго скачивать не нужно, так как файлы тестовых сборок уже лежат локально на машине.

Поэтому в нашем примере, пишем путь до .xctestproducts в файл products.txt, который положим в корень проекта, что будет автоматически скачено дочерней джобой и автоматически станет доступно в джобе тестирования. В .gitlab-ci.yml это будет выглядеть примерно так:

iOS Build Tests Products:
  extends: .testing_template
  script:
    - bundle exec fastlane ios build_tests_products
  artifacts:
    when: on_success
    paths:
      - products.txt
    expire_in: 1 day

iOS 26.4.1 iPhone | UI Tests:
  extends: .testing_template
  needs: [ "iOS Build Tests Products" ]
  script:
    - bundle exec fastlane ios run_ui_tests_26_4

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

А файл products.txt имеет следующее содержание:

cat products.txt 
/Users/user/builds/artifacts/2026.04.28_13-54-47-168741-+0700

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

И наконец обновим наш последний lane с именем run_testing который запускает тесты, раньше он и собирал приложение и сразу же на нем запускал тесты. Теперь за сборку тестов у нас отвечает отдельный lane с именем build_tests_products , поэтому немного поправим lane запуска тестов чтобы он не собирал приложение, а передавал готовую сборку через -testProductPath.

private_lane :run_testing do |options|
    products_path = File.read(File.join(project_dir, "products.txt"))
    product_path = "#{products_path}/#{options[:scheme]}.xctestproducts"
    scan(
        testplan: options[:testplan],
        # Важно передать пустую строку из-за бага https://github.com/fastlane/fastlane/issues/20540
        package_path: "",
        # Важно выключить `build` фазу. Поведение флага:
        # - когда не skip, то добавляется 'build test'
        # - когда skip, то добавляется 'test'
        skip_build: true,
        # Выставляем в `true`, чтобы выключить 'test' флаг (смотри выше)
        test_without_building: true,
        destination: "platform=iOS Simulator,id=#{options[:destination]}",
        skip_detect_devices: true,
        disable_concurrent_testing: true,
        derived_data_path: product_path,
        xcargs: "-testProductsPath #{product_path}"
    )
end

Что транслируется в

xcodebuild \
    -destination 'platform=iOS Simulator,id=4E015A22-1A11-4C64-8A4C-46D2285B0262' \
    -derivedDataPath /Users/user/builds/artifacts/2026.04.28_22-34-01-946967-+0700/AppTests.xctestproducts \
    -disable-concurrent-testing \
    -enableCodeCoverage NO \
    -testPlan 'AppTests' \
    -testProductsPath /Users/user/builds/artifacts/2026.04.28_22-34-01-946967-+0700/AppTests.xctestproducts \
    test-without-building

Запускаем снова весь пайплайн, чтобы проверить, стоило ли это всех наших усилий:

Ожидаемо получаем прирост в 21.7% (8 минут и 40 секунд вместо 11 минут, запускал пайплайн несколько раз и взял среднее), то есть на 1/5 стало быстрее, а это почти две с половиной минуты. В день этот пайплайн разработчиками может запускаться десятки раз, потому что иногда пайплайны запускались не только на создание MR/PR, но и просто на push в ветку. Идем дальше.

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

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

private_lane :run_testing do |options|
    uuid = (sh "xcrun simctl create #{options[:SimName]} #{options[:SimDeviceType]} #{options[:SimRuntime]}").chop
    sh "xcrun simctl boot #{uuid}"
    sh "xcrun simctl bootstatus #{uuid}"
    begin
        scan(
            destination: "platform=iOS Simulator,id=#{uuid}",
            ...
        )
    ensure
        sh "xcrun simctl shutdown #{uuid}"
        sh "xcrun simctl delete #{uuid}"
    end
end

Это тот самый run_testing который запускает тесты. Обратите внимание, что на каждый тест этот lane создает симулятор и после теста удаляет его. Нет никакого намека на использование уже созданных симуляторов. Сейчас объясню, в чем разница. Но сначала выясним что делает каждая команда из кода выше для simctl. Как вы знаете simctl позволяет управлять симуляторами. Выше команды делают следующее.

Команда create создает симулятор:

xcrun simctl create ${SimName} ${SimDeviceType} ${SimRuntime}

Команда boot поднимает симулятор:

xcrun simctl boot 4E015A22-1A11-4C64-8A4C-46D2285B0262

Команда bootstatus лочит вызывателя до тех пор, пока симулятор не будет готов к работе:

xcrun simctl bootstatus 4E015A22-1A11-4C64-8A4C-46D2285B0262

Теперь устроим замеры скорости запуска симулятора уже созданного и только что созданного. Командой ниже через time замеряем общее время трех simctl команд create + boot + bootstatus, то есть только что созданного симулятора, который сразу же запускаем и ждем, когда он будет готов к использованию:

time (SIM_ID=$(xcrun simctl create "iPhone-17-Pro-Max-Unit-Tests" "com.apple.CoreSimulator.SimDeviceType.iPhone-17-Pro-Max" "com.apple.CoreSimulator.SimRuntime.iOS-26-4") \
    && xcrun simctl boot ${SIM_ID} \
    && xcrun simctl bootstatus ${SIM_ID})

Результат:

[2026-04-28 17:43:24 +0000] Status=4, isTerminal=NO, Elapsed=00:29.
	Waiting on System App

[2026-04-28 17:43:25 +0000] Status=4, isTerminal=NO, Elapsed=00:30.
	Waiting on System App

[2026-04-28 17:43:26 +0000] Status=4294967295, isTerminal=YES, Elapsed=00:31.
	Finished

0.08s user 0.09s system 0% cpu 32.036 total

То есть процесс подготовки симулятора к тестам занимает 32 секунды. Теперь то же самое, только пропускаем шаг создания симулятора:

time (xcrun simctl boot ${SIM_ID} && xcrun simctl bootstatus ${SIM_ID})

Результат в 3 раза быстрее:

Monitoring boot status for iPhone-17-Pro-Max-Unit-Tests (BC8ABA4E-2FCD-4D79-AEE3-5F9B728496B4).
[2026-04-28 17:48:44 +0000] Status=1, isTerminal=NO, Elapsed=00:01.
	Waiting on BackBoard

[2026-04-28 17:48:50 +0000] Status=4, isTerminal=NO, Elapsed=00:07.
	Waiting on System App

[2026-04-28 17:48:52 +0000] Status=4294967295, isTerminal=YES, Elapsed=00:09.
	Finished

( xcrun simctl boot ${SIM_ID} && xcrun simctl bootstatus ${SIM_ID}; )  0.07s user 0.08s system 1% cpu 9.855 total

У нас в пайплайне идет 3 теста и 3 раза мы создаем симулятор. Если отталкиваться от тестов выше, то переиспользование симуляторов дает нам +20 секунд дополнительного времени, а для трех целая минута. Пока это теория, поэтому обновляем тестовые lane чтобы проверить. Для простоты эксперимента просто захардкодим ID симуляторов:

lane :run_unit_tests do
    run_testing(
        scheme: "AppTests",
        testplan: "AppTests",
        destination: "8A23906D-84CA-42FA-9703-1CA8986B11D9"
    )
end

lane :run_ui_tests do
    run_testing(
        scheme: "AppUITests",
        testplan: "AppUITests",
        destination: "8A23906D-84CA-42FA-9703-1CA8986B11D9"
    )
end

А из lane пускателя тестов убираем создание и удаление симулятора

private_lane :run_testing do |options|
    uuid = options[:destination]
    sh "xcrun simctl boot #{uuid}"
    sh "xcrun simctl bootstatus #{uuid}"
    begin
        scan(
            destination: "platform=iOS Simulator,id=#{uuid}",
            ...
        )
    ensure
        sh "xcrun simctl shutdown #{uuid}"
    end
end

Пушим в репо и перезапускам весь пайплайн и средний результат у нас получается 7 минут и 10 секунд, что на 1 минуту и 30 секунд быстрее предыдущего результата (теоретические расчеты примерно эту цифру и показывали).

На данный момент мы ускорили пайплайн на 35.24%. Идем дальше.

Выжимаем максимум из симуляторов

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

Закрывает все симуляторы

xcrun simctl shutdown all

Чистит все симуляторы

xcrun simctl erase all

Создает новые симуляторы если необходимо
Запускает необходимые симуляторы, чтобы, когда запускались тесты, они уже были “прогреты”

Правим наш run_testing чтобы он:

Если симулятор не запущен, то запускал перед тестом
Не закрывал симулятор после теста, чтобы он был переиспользуемым

private_lane :run_testing do |options|
    uuid = options[:destination]
    is_booted = (sh "xcrun simctl list devices booted").include?(uuid)
    unless is_booted
        sh "xcrun simctl boot #{uuid}"
        sh "xcrun simctl bootstatus #{uuid}"
    end
    scan(
        destination: "platform=iOS Simulator,id=#{uuid}",
        ...
    )
end

Пушим изменения и прогоняем пайплайн очередной раз. Получаем картину:

Где средний результат 6 минут и 8 секунд, что на 1 минуту лучше предыдущего. На данный момент мы ускорили пайплайн на 44.58%. Идем дальше.

Разбиваем джобы по раннерам

Сделаем анализ джоб в пайплайне.

Сборка проекта (долгая и тяжелая для процессора работа)
Юнит тесты (легкая работа, слабо нагружает процессор)
UI тесты (тяжелые продолжительные тесты)

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

Наша цель, запускать юнит тесты вместе с UI тестами параллельно. Для этого создадим второй раннер на CI. У нас есть один дефолтный раннер ios, который теперь будет отвечать за выполнение тяжелых задач. И новый раннер, на котором мы будем запускать только легкие задачи. Разрешим новому раннеру запускать до 2 легких задач параллельно, а старому раннеру разрешим только 1 тяжелую джобу, а самому CI выставить возможность запускать только 2 джобы в параллели. То есть у нас теперь могут запускаться такие комбинации:

1 легкая задача + 1 тяжелая задача
2 легких задачи
Если нет легких задач, то запуститься только одна тяжелая задача

Создаем второй раннер с тегом ios_low_load и прописываем в ~/.gitlab-runner/config.toml (если вы используете GitLab):

concurrent = 2

[[runners]]
  name = "ios"
  limit = 1
  
[[runners]]
  name = "ios_low_load"
  limit = 2

Затем раставляем эти теги в .gitlab-ci.yml, тут всё просто, только для юнит тестов выставляем новый раннер ios_low_load, для остальных оставляем старый.

iOS iPhone | Unit Tests:
  tags:
    - ios_low_load

Пушим и запускаем. Так как у нас юнит тесты занимают почти 30-40 секунд, в теории мы должны получить прирост примерно такой же.

Если сложить время всех задач, то получим 5 минут 49 секунд. Но время самого пайплайна 5 минут и 23 секунды, потому что часть задач стали выполняться параллельно. Что дало нам прирост в скорости, чем дольше бы у нас были юнит тесты, тем больше бы прирост мы получили. На данном этапе мы улучшили скорость пайплайна на 51.36%, то есть в 2 раза, как вы помните, без всех изменений выше время пайплайна было больше 11 минут. Переходим на финальный этап.

Распараллеливаем UI тесты

Наверное, самая холиварная часть этой статьи. Сначала определимся, что значит параллельное UI тестирование. Xcode (xcodebuild если точнее) имеет механизм параллельного тестирования на нескольких симуляторах в рамках одного тестового запуска. Вот так выглядит симулятор, когда параллельное тестирование выключено:

А вывод команды запущенных симуляторов выглядит так:

xcrun simctl list devices booted
== Devices ==
-- iOS 26.4 --
    iPhone-17-Pro-Max-Unit-Tests (8A23906D-84CA-42FA-9703-1CA8986B11D9) (Booted)

А так выглядят симуляторы при параллельном тестировании:

Если во время теста мы запустим команду получения списка запущенных симуляторов:

xcrun simctl list devices booted
== Devices ==
-- iOS 26.4 --

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

Внимательный читатель, возможно, заметил, что в fastlane командах выше мы использовали disable_concurrent_testing: true которые для xcodebuild транслируется в -disable-concurrent-testing чтобы отключить параллельное тестирование, но на самом деле этот флаг ничего не делает так как мы запускаем тесты через testPlan, а testPlan имеет свою настройку для параллельного запуска и она берет приоритет над -disable-concurrent-testing. Мы этот флаг в fastlane использовали, чтобы подчеркнуть, что запускаем тест не в параллельном режим, хотя на самом деле это было выключено на уровне testPlan вот тут:

Теперь опишем как Xcode запускает тесты в параллельном режиме (включено в testPlan). Когда вы запускаете команду:

xcodebuild \
-destination 'platform=iOS Simulator,id=8A23906D-84CA-42FA-9703-1CA8986B11D9' \
-testPlan 'UITests-iPhone' \
-testProductsPath AppUITests.xctestproducts \
test-without-building

xcodebuild завершает работу симулятора (8A23906D-84CA-42FA-9703-1CA8986B11D9) если он запущен
Создает клонов этого симулятора сколько считает нужным если явно не задано через команду (-parallel-testing-worker-count N) (где N - количество клонов):

xcrun simctl clone 8A23906D-84CA-42FA-9703-1CA8986B11D9 "Clone ${N} ${DEVICE_NAME}"

Запускает параллельно тесты на клонах
После завершения тестов клоны уничтожаются (их нельзя переиспользовать, потому что у них нет UDID)

На базе этого мы делаем выводы, где у такого подхода могут быть проблемы:

Клоны не имеют UDID и мы не можем ими управлять
Клоны всегда перезапускаются, невозможно создать pool клонов и переиспользовать, чтобы не тратить время на запуск, так как запуск симуляторов это тяжелая операция для CPU (откройте htop и сделайте boot симулятору). Вот скриншот с мощной M машины, тут xcodebuild запускает одного клона для тестов:

А ведь для параллельного тестирования мы будем создавать 4-5-6 клонов (среднее устоявшееся кол-во при котором тесты на флакуют), и запуск этих 4-6 клонов с легкостью съедают от 3 до 5 минут прежде, чем все тесты в параллели запустятся на симуляторах. Если у вас немного тестов, то ситуация бывает такой, что на первом клоне тесты уже прошли, а четвертый или пятый еще даже не прогрузились.

Но опять же это всё теория. Давайте делать замеры.

Тесты без параллельного тестирования для нашего тест плана мы можем взять из джоб, что мы описывали выше, последний результат был 2 минуты и 10 секунд
Тесты с параллельным режимом. Наш тест план имеет всего 2 теста (2 тестовых XCTest класса), но все равно проверим. В fastlane выставляем concurrent_workers: 2 чтобы точно запустилось нужное нам кол-во клонов-симуляторов. Два перезапуска и вот результат:

private_lane :run_testing do |options|
  scan(
    concurrent_workers: 2,
    ...
  )
end

xcodebuild \
    -destination 'platform=iOS Simulator,id=8A23906D-84CA-42FA-9703-1CA8986B11D9' \
    -derivedDataPath AppUITests.xctestproducts \
    -parallel-testing-worker-count 2 \
    -testPlan 'AppUITests' \
    -testProductsPath AppUITests.xctestproducts \
    test-without-building

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

Делаем замер параллельного запуска, но ручного:

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

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

lane :run_ui_tests do |options|
    thread1 = Thread.new do
        scan(
            destination: "platform=iOS Simulator,id=#{SIMULATOR_1}",
            only_testing: [
                "UITest-1",
                "UITest-2",
            ]
        )
    end

    thread2 = Thread.new do
        scan(
            destination: "platform=iOS Simulator,id=#{SIMULATOR_2}",
            only_testing: [
                "UITest-3",
                "UITest-4",
            ]
        )
    end

    thread1.join
    thread2.join
end

К сожалению, fastlane не поддерживает многопоточность. Поэтому это пришлось параллелизацию вынести из fastlane на bash:

lane :run_ui_tests do |options|
    scan(
        destination: "platform=iOS Simulator,id=#{options[:destination]}",
        only_testing: options[:only_testing].split(","),
        disable_concurrent_testing: true
    )
end

fastlane ios run_ui_tests destination:${SIM_1} only_testing:'UITest-1,UITest-2' & \
    fastlane ios run_ui_tests destination:${SIM_2} only_testing:'UITest-3,UITest-4' & \
    wait

Очевидно получаем прирост скорости, потому что параллелизация и прогретые симуляторы, итоговое время 1 минута и 38 секунд, что на 24.62% быстрее непараллельного режима и на 34.66% быстрее параллельного режима с холодным стартом клонов.

Из чего мы делаем вывод, если у вас есть время и вы хотите выжать максимум из симуляторов для UI тестов, то вам нужно присмотреться к ручному управлению параллелизации на уже прогретых симуляторах. Ускорение пайплайна на 3-5 минут кажется не существенным, но, если пайплайн запускается десятки раз за день, это время уже идет на часы.

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

Основано на реальном проекте:

Была в одном проекте как раз такая проблемная джоба, которая запускала UI тесты. Время ее прогона было около 30 минут (4 симулятора в параллели через клоны, больше CI не тянул). Тестов было и правда много - сотня-две. Джоба запускалась довольно часто (до 10 раз в день легко, а если релиз и того больше). Постоянно в чате было, что QA ждёт, когда пройдет пайплайн, чтобы забрать билд на проверку, да и сами разработчики ждали, потому что UI тесты грузили сильно CI, второй пайплайн не запустишь.

В итоге после применения всех пунктов, что описаны выше в статье, удалось снизить время выполнения UI тестов с 30 минут до 12-15 минут насколько помню. После данные оптимизации были добавлены и в другие UI тесты, и даже юнит тесты нам удалось ускорить в несколько раз, потом что мы написали тулу, которая на лету разбивала тест план на несколько тест планов и запускала их на свободных прогретых симуляторах. Я потом делал расчет времени каждого теста и их суммарное время на CI. И у меня выходило, что тесты выполнялись за теоретический максимум, так как в тестах не было потерь времени на что-то другое кроме тестов (запуск симулятор и прочее). То есть пришли в итоге к такому состоянию, что просто уже нечего было улучшать. Теоретический предел посчитать легко это сумма времени каждого теста, деленное на кол-во симуляторов, время тестов можно вытащить из .xcresult. Если у вас это время сильно отличается от времени прохождения джобы/пайплайна, то нужно искать, где это время теряется, и попытаться убрать этот bottle neck.

Бонус, кто дочитал до конца, что такое .xctestproducts

Это директория очень напоминает DerivedData проекта, но структурирована немного иначе. Директрия содержит не только результат сборки приложения, но и, логично, скомпилированне тест планы, что есть ${TESTPLAN_NAME}.xctestrun, что из себя представляет обычный plist файл. Причем самое интересное, что этот файл мы можем изменять, если нужно изменить поведение теста, и не нужно после изменений снова перекомпилировать testplan, можно сразу же использовать измененный .xctestrun. Покажу пару примеров, которые я сам использовал:

В .xctestrun есть такая секция:

<key>CommandLineArguments</key>
<array>
    <string>-AppleLanguages</string>
    <string>(en)</string>
    <string>-AppleTextDirection</string>
    <string>NO</string>
    <string>-AppleLocale</string>
    <string>en_US</string>
</array>

Если мы хотим запустить тесты (например снапшот тесты) для разных языков, мы можем один раз собрать приложение, и меняя .xctestrun без пересборки приложения прогонять тесты на разных языках очень быстро. Например, для французского языка выставляем:

<key>CommandLineArguments</key>
<array>
    <string>-AppleLanguages</string>
    <string>(fr)</string>
    <string>-AppleTextDirection</string>
    <string>NO</string>
    <string>-AppleLocale</string>
    <string>fr_FR</string>
</array>

Следующая интересная секция:

<key>OnlyTestIdentifiers</key>
<array>
    <string>UITest1/test()</string>
    <string>UITest2/test()</string>
</array>

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

И последняя довольно интересная секция:

<key>EnvironmentVariables</key>
<dict>
    <key>LOCAL_PORT</key>
    <string>8000</string>
</dict>

Через EnvironmentVariables можно пробрасывать разлиные данные в тестовое приложение, например чтобы не хардкодить port для локального сервера, который предоставляет приложению тестовые данные, его можно передать как через testplan, так и напрямую через .xctestrun. Например, если у вас несколько CI и вы передали на другой CI .xctestproducts, то сборщик, возможно, не имеет знаний, какой port нужно было выставить в оригинальном testplan, поэтому уже на месте исполнения тестов это можно пробросить именно тут.

Цель статьи:

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

Спасибо всем, кто дочитал. Надеюсь было полезно.

Для написания статьи ИИ не использовался, только спелчеккер для русского языка в IntelliJ Idea.

Вредные советы для Flutter-разработчика

Thu, 30 Apr 2026 12:53:28 +0000

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

Привет! Вообще-то я руковожу мобильной и фронтенд-разработкой в AGIMA, но сегодня я тут в другом амплуа. Помогаю всем желающим запомнить, как писать код на Flutter не надо. Чтобы запомнить вредные советы было проще — воспользуемся стихотворной формой.

Вступление

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

Наливай чай-кофе в чашку —
Или что в твоей баклажке? —
И знакомься с объясняшкой.
Для начала — сразу твист:
Дельную найдешь ты мысль,
Только если флаттерист.

Применять советы нужно
Перорально и наружно,
Когда весело и скучно.
Следуй им беспрекословно —
Польза будет баснословной,
Что для Девы, что для Овна.

Прочитай их перед сном
Вместо всяких .ru и .com —
Будешь писать кипятком.
Мал или велик твой стаж,
Это высший пилотаж.
Вот и кончен инструктаж.

Основная часть

День рабочий — это счастье:
Чтобы в мелочность не впасть нам,
Не дели проект на части.
В main фиксируй мысли ток,
Чтоб никто прочесть не мог
Твой десяток тысяч строк.

Дальше тема посложнее.
Если нужно в приложеньи
Состояньем управленье,
Всюду пользуйся setState —
Никаких не будет бед!
Это норм такой совет.

Сделав очень важный вид,
Нажимай всегда Rebuild —
И работа закипит!
Даже если changed один,
Обновляй весь магазин.
Это чистый дофамин.

Вот подумай сам немного:
Ну зачем тебе, ей-богу,
Легкую искать дорогу?
Хочешь быть обут-одет,
Оснований просто нет
Не использовать setState.

9.

Если, скажем, строя дом,
Сделал лишний ты проем,
То какой совет даем?
Верно, сносим дом под корень —
Чтобы был с землею вровень.
Важно, чтоб ты принцип понял!

10.

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

11.

Понял жизнь? Так не спеши.
Код ты пишешь для души —
Пусть растет и вглубь, и вширь.
А async/await — измена,
Не понять им чувства дзена.
Где б еще добавить then’а?

12.

Дальше — больше: DTO.
Надо с ходу брать его,
Словно норму ГТО.
Ну кому нужны модели?
Мы и так тут еле-еле
До обеда досидели.

13.

Нет, серьезно. Просто знай:
API передать в UI —
Это самый чистый кайф.
Усомнишься: «Вдруг контракт
Завтра сменят?» Если так,
Перепишешь всё. Пустяк.

14.

Pagination — это роскошь.
У кого сейчас ни спросишь,
Всякий скажет: это просто ж —
Надо загрузить всё сразу:
Виджеты, картинки, базы —
Это классно, это маза.

15.

Если данных миллиард —
Пользователь будет рад
Подождать три дня подряд.
С интернетом ныне плохо —
Время есть на охи-вздохи.
Не загрузится — и ладно.

16.

Плагины с онлайн-просторов
Выбирай без лишних споров.
Здесь не место для разборов.
Если в сборке есть конфликт,
Значит, сборка полетит,
Словно гоночный болид.

17.

Значит, драма в сборке есть,
Есть сомненье, есть протест.
Возбуждает интерес!
Плагина-героя злой
Плагин выманил на бой.
Чувствуешь, накал какой?

18.

Здесь добавим мы для веса:
Должен код быть интересен,
Как сюжет старинных песен.
Если прост он и понятен,
Нет ошибок в нем и пятен, —
Без работы мы, приятель!

19.

Дальше скажем для проформы,
Что учитывать платформы —
В наши дни уже не норма.
Что Android, что iOS —
Лучше делать на авось.
Наплевать, какая ось.

20.

Миллиметр влево-вправо…
Если кнопка мимо встала —
Признак профессионала.
Честно, тут у нас не тир:
Не попал — не рухнул мир.
Ты не врач и не факир.

21.

Есть у нас одно словцо,
Шесть слогов в нем. Про-из-во-
ди-тель-ность… Ни то ни сё!
Нам такие бы слова
Вычеркнуть из словаря.
Там лежат они зазря.

22.

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

23.

Анимаций нету плавных —
Быть не может ровных планов
Даже у больших экранов.
Если дергается что-то —
Это не твоя забота.
Так устроена природа!

24.

Что еще? Забей на доки,
Если очень давят сроки.
И без них всё будет оки.
Для чего дана нам память?
Чтобы лишний раз не спамить.
Лучше голый код оставить.

25.

Что бы там ни думал босс,
Доки вызывают птоз,
Токсикоз, понос, склероз,
Аллергию, геморрой,
Недержание порой.
Обходи их стороной.

26.

Если через день релиз —
Сильно ты не торопись.
Будет пусть для всех сюрприз.
Если до релиза час —
Вот тогда пора и в пляс.
Куча времени у нас.

27.

Следуй правилу всегда ты:
Слышишь от начальства маты —
Собирай сертификаты.
Если твой тимлид молчит
И спокойный держит вид,
Значит, дело не горит.

28.

Лучше баги не логируй —
Сам себя ударишь гирей.
Без того обильно в «Джире».
Хочешь верь, хочешь не верь,
Настоящий инженер,
Чуять должен, например.

29.

Да, еще момент один:
Лучший лог для бага — print.
Нечего драконить спринт.
Зафиксируй всё в debug:
Если не заявлен брак,
Значит, ты себе не враг.

30.

Сорри, что формулировки
Не всегда бывают ловки.
Дело близится к концовке.
Сборку делай сам сиди,
Позабудь CI/CD —
Всё умеешь ты, поди.

31.

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

Послесловие

32.

Вот и всё — окончен опус.
Натянув сову на глобус,
Сотворили фокус-покус.
Выполняй советы эти —
Будешь при воде и свете,
При котлете и монете.

32.

Следовать им нелегко —
Пей за вредность молоко.
Прочитав, храни покой.
Есть еще одна побочка:
Опосля последней точки
Рифмовать захочешь точно.

33.

Опыт получился гарный
(Хоть, пожалуй, не для Хабра).
Не забудь досыпать кармы.
Где последняя строка?
На помин она легка.
Вот она. Бывай, пока.

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

Статьи про Flutter не в стихах

«М.Видео»: рынок бытовой техники и электроники давно стал узким для развития

Thu, 30 Apr 2026 12:49:19 +0000

Владислав Бакальчук, гендиректор М.Видео

Как будет развиваться рынок непродовольственных товаров и где искать зоны роста? Об этом и многом другом журналистам РБК рассказал гендиректор М.Видео Владислав Бакальчук.

О рынке бытовой электроники

Рынок бытовой техники и электроники не только не растет, но даже сокращается. По итогам 2025 года в натуральном выражении, по данным «ГФК-Русь», он вырос на 2,2%, до 403 млн единиц, а в денежном — сократился на 11,7%, до 2,63 трлн руб. Динамика объясняется тем, что, по подсчетам аналитиков, средняя цена устройства за год снизилась более чем на 14% — потребители отдают предпочтение более дешевым устройствам, тщательно сопоставляя цену и качество.

Также мы отмечаем и увеличение цикла обновления техники. Например, рынок смартфонов в 2025 году сократился на 19% и в штуках, и в деньгах, по оценкам тех же аналитиков. Средняя стоимость смартфона практически не изменилась, то есть рынок снижается не из-за цен, а из-за объемов — люди просто реже меняют устройства. При этом мы видим рост спроса на восстановленную технику. По итогам 2025 года продажи восстановленных смартфонов у нас выросли более чем вдвое в количественном выражении, а ноутбуков — на 70%. Это уже устойчивый тренд, и мы планируем активно развивать продажи таких товаров.

В целом рынок бытовой техники и электроники давно стал узким для развития «М.Видео»: жизненно важно не замыкаться внутри него, а выходить в другие сегменты. Поэтому мы изменили саму логику взаимодействия с клиентом — от разовой покупки смартфона или телевизора к регулярному контакту по самому широкому кругу товаров. Это влияет не только на структуру выручки, но и экономику бизнеса в целом: растет LTV (Lifetime Value — «время жизни клиента». — «РБК Отрасли»), снижается стоимость удержания, укрепляется позиция платформы в повседневном потреблении. Мультикатегорийность в этой логике — инструмент увеличения частоты контакта и перехода в другой класс отношений с клиентом.

Опрос наших клиентов подтвердил запрос на расширение категорий: около 16% из них интересуют автотовары, по 15% — товары для дома, сада и мебель, 12% — товары для спорта и отдыха, 10% — посуда, 7% — ассортимент для строительства и ремонта.

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

Будущее за цифровыми платформами

Во многих сегментах онлайн-продажи составляют уже более половины рынка: например, в секторе красоты и здоровья — 61%, детских товарах — 57%, одежде и обуви — 54%, по подсчетам Infoline. Но в сегментах, скажем, автотоваров, товаров для животных, спорта и отдыха, мебели или бытовой химии еще есть большой потенциал для развития.

Рынок бытовой техники и электроники уже функционирует по платформенной логике, где 55% продаж идут в онлайне и 67% из них через маркетплейсы.

В этих условиях приоритетом стала трансформация бизнеса в платформенную модель, где офлайн-инфраструктура выступает не центром, а одним из элементов системы продаж. Мы целимся достигнуть доли маркетплейса в онлайн-продажах компании на уровне 25% к концу 2026 года и 50% к 2028 году. Эти ориентиры основаны на переходе к гибкой 3P-модели (Third-Party — продажа товаров селлеров через платформу маркетплейса. — «РБК Отрасли»), которая позволяет кратно наращивать ассортимент от сторонних продавцов при снижении нагрузки на оборотный капитал.

В большинстве категорий non-food (непродовольственных товаров) доля онлайн-продаж может дойти до 70–80% к 2035 году. Иначе говоря, этот рынок станет преимущественно онлайн-ориентированным, что формирует долгосрочный прогноз по наращиванию доли маркетплейсов на нем. И мы вышли на этот рынок, опираясь на уже готовую инфраструктуру: технологическую платформу, розничную сеть в сотнях городов, более 50 тыс. партнерских пунктов выдачи заказов и постаматов по всей стране и развитую логистику.

Доверие и взаимовыгодное сотрудничество — основа бизнеса

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

Отдельная задача — работа с восприятием платформы среди потенциальных партнеров-селлеров, которые должны увидеть, что теперь мы гораздо больше, чем продажа техники. Мы строим доверительные отношения с продавцами-партнерами — бесплатно храним их товары, вводим прозрачные комиссии, организуем доступную логистику и быстрое получение доходов от продаж, а также даем нестандартные сервисы, например возможность выкладки товаров в физической рознице. В I квартале этого года к нашей платформе присоединились 3200 новых селлеров, что в 1,6 раза больше, чем в IV квартале прошлого года.

Сегодня агентская схема и продажи товаров селлеров формируют уже около 35% оборота компании — до конца 2026 года планируем выйти на 45%, а к 2028-му — на 70%. Вслед за этим ростом кратно расширяется и ассортимент: до конца года платформа может достигнуть 1 млн товарных позиций, а к 2028 году — 10 млн.

Заграница нам поможет

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

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

О трансформации розничной сети

Мы сосредотачиваем присутствие розничных магазинов в стратегически значимых локациях с максимальной операционной эффективностью. При этом в малых и удаленных городах переходим на партнерскую модель обслуживания. Интеграция со СДЭК и «Яндекс Доставкой» обеспечила доступ в более чем 4,5 тыс. населенных пунктов и тысячи пунктов выдачи без дополнительных инвестиций.

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

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

Часть магазинов будет превращаться в white store, где клиент может как сам оперативно забрать нужный товар с полки, так и мы — быстро оформить и отправить онлайн-заказ в соседний партнерский ПВЗ или на дом.

О технологиях

Идет полная замена IT-ландшафта компании с бюджетом около 9 млрд руб. В периметре трансформации будут новый сайт и мобильное приложение для покупателей, личный кабинет продавца, системы управления складами, транспортировкой и заказами, CRM, перевод инфраструктуры на Linux, а также встраивание ИИ в ценообразование, прогноз спроса и клиентский сервис. Это позволит в 2027 году перейти к полноценному масштабированию платформы. Внедрение технологий сильно ускоряет процессы: например, ИИ-модуль обработал уже свыше 240 тыс. обращений за первые месяцы этого года, снизив нагрузку на контактный центр по письменным ответам на 90%. Технологии в этой логике — не инструментарий, а несущая конструкция и двигатель бизнеса.

Установка Zabbix Agent 2 на Cloud Director Appliance (Photon OS 4)

Thu, 30 Apr 2026 12:45:17 +0000

На Photon OS 4 (Cloud Director Appliance ≥ 10.6, vCenter Server Appliance 8) ставим Zabbix Agent 2 (LTS 7.0, RPM под EL8) без установки чужих RPM в систему. Распаковываем три RPM (агент, openssl-libs 1.1, pcre2), кладём бинарь и конфиги штатно, недостающие .so складываем в /etc/zabbix/libs/ и подключаем к сервису через LD_LIBRARY_PATH в systemd-юните. На vCSA дополнительно извлекаем .hmac-файлы для FIPS. В финале — открытие порта 10050 и проверка с Zabbix-сервера через zabbix_get.

Шаги:

1. Скачать RPM (агент + openssl-libs 1.1 + pcre2) на машине с интернетом.

2. Распаковать, разложить файлы по нужным путям на appliance.

3. Прописать LD_LIBRARY_PATH в unit-файле, запустить службу.

4. Открыть порт 10050 и проверить доступность агента с сервера мониторинга.

Зачем это нужно

Photon OS — компактный базовый дистрибутив VMware для appliance-решений. Официально установка Zabbix Agent на Photon не поддерживается, а штатный пакетный менеджер tdnf не сможет закрыть зависимости агента: Photon OS 4 поставляется с OpenSSL 3 (libssl.so.3, libcrypto.so.3) и без PCRE2. Zabbix Agent 2, собранный для EL8, ждёт:

• libssl.so.1.1

• libcrypto.so.1.1

• libpcre2-8.so.0

Доступ к репозиторию VMware с самого аплайнса часто закрыт сетевыми политиками, а ставить «чужие» RHEL-пакеты в систему рискованно — сломаются обновления самого аплайнса. Поэтому собираем «портативную» установку: библиотеки лежат отдельно и подгружаются только агенту.

Почему именно RPM под EL8, а не EL9

EL9 идёт уже на OpenSSL 3 — казалось бы, ближе к Photon 4. Но Zabbix Agent 2 для EL9 собран против более свежего glibc (2.34+), а в Photon OS 4 — glibc 2.32. Бинарь EL9 на Photon 4 просто не запустится из-за несовместимых символов glibc. Сборка EL8 (glibc 2.28) совместима, поэтому единственное, что приходится «донести» — это OpenSSL 1.1 и PCRE2.

О версиях пакетов

Конкретные версии RPM ниже актуальны на момент написания (апрель 2026). Перед развёртыванием возьмите свежие версии из тех же источников: Zabbix — repo.zabbix.com/zabbix/7.0/rhel/8/x86_64/, openssl-libs 1.1 и pcre2 — pkgs.org или зеркала Rocky/AlmaLinux 8. Цепочка зависимостей и пути сборки от версии к версии не меняются.

Часть 1. Подготовка

Подготовиться можно как на самом appliance (если у него есть интернет), так и на соседней Linux-машине. Все артефакты собираем в /root/zbx-portable.

1.1. Скачиваем RPM

• zabbix-agent2 RPM под EL8 — с https://repo.zabbix.com/zabbix/7.0/rhel/8/x86_64/

• openssl-libs 1.1.x под EL8 — например, с pkgs.org

• pcre2 под EL8 — там же

Раскладываем в ./rpm/:

/root/zbx-portable/rpm/
  openssl-libs-1.1.1k-15.el8_6.x86_64.rpm
  pcre2-10.32-3.el8_6.x86_64.rpm
  zabbix-agent2-7.0.23-release1.el8.x86_64.rpm

1.2. Полностью распаковываем пакет с агентом

cd /root/zbx-portable
rpm2cpio ./rpm/zabbix-agent2-*.rpm | cpio -idmv

1.3. Извлекаем только нужные библиотеки

Из пакетов с библиотеками вытаскиваем только нужные .so и складываем в ./libs/. Для систем с включённым FIPS (vCSA) дополнительно извлекаем .hmac-файлы — без них OpenSSL в FIPS-режиме откажется грузиться:

mkdir -p /root/zbx-portable/libs && cd /root/zbx-portable/libs
 
rpm2cpio /root/zbx-portable/rpm/pcre2-10.32-3.el8_6.x86_64.rpm \
  | cpio -idmv './usr/lib64/libpcre2-8.so.0*'
 
rpm2cpio /root/zbx-portable/rpm/openssl-libs-1.1.1k-15.el8_6.x86_64.rpm \
  | cpio -idmv './usr/lib64/libssl.so.1.1*' './usr/lib64/libcrypto.so.1.1*'
 
# Только для vCSA / FIPS-режима:
rpm2cpio /root/zbx-portable/rpm/openssl-libs-1.1.1k-15.el8_6.x86_64.rpm | cpio -idmv \
  './usr/lib64/.libcrypto.so.1.1.1k.hmac' \
  './usr/lib64/.libcrypto.so.1.1.hmac' \
  './usr/lib64/.libssl.so.1.1.1k.hmac' \
  './usr/lib64/.libssl.so.1.1.hmac'

Обратите внимание на символьные ссылки в полученных файлах — cpio сохранит их, переносить файлы дальше нужно с флагами, сохраняющими симлинки (cp -a / rsync -a).

Часть 2. Установка на Photon OS 4

2.1. Системный пользователь и каталоги

Создаём пользователя и группу для агента:

groupadd --system zabbix
useradd --system -g zabbix -d /usr/lib/zabbix -s /sbin/nologin \
  -c "Zabbix Monitoring System" zabbix

Каталоги для логов и runtime:

mkdir /var/log/zabbix
chown -R zabbix:zabbix /var/log/zabbix
 
mkdir /run/zabbix
chown zabbix:zabbix /run/zabbix

2.2. Конфиги и бинарь агента

Копируем конфиги Zabbix:

cd /root/zbx-portable/
cp -r etc/zabbix/ /etc/zabbix/
chown -R root:zabbix /etc/zabbix
chmod 755 /etc/zabbix
chmod -R 755 /etc/zabbix/zabbix_agent2.d
chmod 640 /etc/zabbix/zabbix_agent2.conf

Теперь правим /etc/zabbix/zabbix_agent2.conf — Server, ServerActive, Hostname и т. д.

Согласуйте PidFile с RuntimeDirectory

В юните дальше указывается RuntimeDirectory=zabbix → systemd создаст /run/zabbix при старте. Параметр PidFile в zabbix_agent2.conf должен указывать туда же: PidFile=/run/zabbix/zabbix_agent2.pid. Иначе агент будет писать pid в путь по умолчанию, а systemd будет очищать другой каталог — рассинхрон при рестартах.

Копируем бинарник агента:

cp usr/sbin/zabbix_agent2 /usr/sbin/zabbix_agent2
chown root:root /usr/sbin/zabbix_agent2
chmod 755 /usr/sbin/zabbix_agent2

2.3. Библиотеки в отдельном каталоге

Копируем извлечённые .so с сохранением симлинков:

mkdir /etc/zabbix/libs
cp -a /root/zbx-portable/libs/. /etc/zabbix/libs/

На всех каталогах по пути нужен execute-bit (x), иначе линкер не сможет зайти в директорию:

chmod 755 /etc/zabbix
chmod 755 /etc/zabbix/libs
chmod 755 /etc/zabbix/libs/usr
chmod 755 /etc/zabbix/libs/usr/lib64
 
chmod 644 /etc/zabbix/libs/usr/lib64/libcrypto.so.1.1.* \
          /etc/zabbix/libs/usr/lib64/libssl.so.1.1.* \
          /etc/zabbix/libs/usr/lib64/libpcre2-8.so.0.*

2.4. systemd-юнит и LD_LIBRARY_PATH

Копируем unit-файл из распакованного RPM:

cp usr/lib/systemd/system/zabbix-agent2.service \
   /usr/lib/systemd/system/zabbix-agent2.service

Если запустить агента сейчас, получим ошибку:

/usr/sbin/zabbix_agent2: error while loading shared libraries:
  libpcre2-8.so.0: cannot open shared object file

Список недостающих библиотек удобно смотреть так:

ldd /usr/sbin/zabbix_agent2 | awk '/not found/{print $1}'

Решение — добавить в секцию [Service] переменную окружения, чтобы библиотеки видела только эта служба, а заодно зафиксировать каталог и режим для pid-файла:

vim /usr/lib/systemd/system/zabbix-agent2.service
 
[Service]
Environment="LD_LIBRARY_PATH=/etc/zabbix/libs/usr/lib64"
RuntimeDirectory=zabbix
RuntimeDirectoryMode=0755

Применяем:

systemctl daemon-reload
systemctl enable --now zabbix-agent2.service

Альтернатива: вшить путь в бинарь через patchelf

Если вы хотите, чтобы агент находил библиотеки независимо от того, как его запустили (не только через systemd, но и руками для отладки), можно вшить RUNPATH прямо в ELF:

tdnf install -y patchelf   # или принести patchelf тем же способом, что и агента
patchelf --set-rpath /etc/zabbix/libs/usr/lib64 /usr/sbin/zabbix_agent2

После этого LD_LIBRARY_PATH в юните не нужен. Минус — после обновления бинарника агента patchelf нужно применять заново.

Часть 3. Проверка работы

3.1. Зависимости закрыты

Первое, что хочется сделать после правки юнита — запустить ldd и убедиться, что библиотеки нашлись. Но есть нюанс: ldd использует переменные окружения текущего шелла, а LD_LIBRARY_PATH мы выставили только внутри unit-файла. Поэтому «голый» ldd будет продолжать показывать libssl.so.1.1, libcrypto.so.1.1 и libpcre2-8.so.0 как not found, даже если агент при этом прекрасно работает под systemd.

Правильная проверка — с тем же LD_LIBRARY_PATH, который видит служба:

LD_LIBRARY_PATH=/etc/zabbix/libs/usr/lib64 \
  ldd /usr/sbin/zabbix_agent2 | awk '/not found/{print $1}'

Должны получить пустой вывод.

3.2. Статус и логи службы

systemctl status zabbix-agent2 --no-pager
journalctl -u zabbix-agent2 -b -n 50 --no-pager

3.3. Проверка с Zabbix-сервера

Запуск процесса ещё не гарантирует, что агент реально отвечает. С хоста Zabbix-сервера или прокси проверяем end-to-end:

zabbix_get -s <appliance-ip> -p 10050 -k agent.ping
# должно вернуть: 1

zabbix_get -s <appliance-ip> -p 10050 -k agent.version
# должно вернуть номер версии агента

Если zabbix_get упирается в таймаут — проблема либо в firewall (см. Часть 4), либо в параметре Server= в конфиге агента: хост сервера должен быть в нём явно разрешён.

Часть 4. Открытие порта 10050

4.1. Cloud Director Appliance

В /etc/systemd/scripts/ip4save-vmw добавить правило рядом с однотипными записями:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 10050 -j ACCEPT
 
# и перезапустить службу:
service iptables restart

4.2. vCenter Server Appliance

Временное правило (действует до перезагрузки):

iptables -I port_filter -p tcp --dport 10050 -j ACCEPT

Закрепить правило между перезагрузками — добавить блок в /etc/vmware/appliance/services.conf:

"zabbix-agent": {
    "firewall": {
        "enable": true,
        "rules": [
            {
                "direction":  "inbound",
                "protocol":   "tcp",
                "porttype":   "dst",
                "port":       "10050",
                "portoffset": 0
            }
        ]
    }
}

Часть 5. Сопровождение

5.1. Ротация логов

Из RPM мы скопировали только /etc/zabbix/, без /etc/logrotate.d/. Чтобы лог /var/log/zabbix/zabbix_agent2.log не рос бесконтрольно, добавьте конфиг ротации:

cat > /etc/logrotate.d/zabbix-agent2 <<'EOF'
/var/log/zabbix/zabbix_agent2.log {
    weekly
    rotate 12
    compress
    delaycompress
    missingok
    notifempty
    create 0640 zabbix zabbix
    postrotate
        /bin/kill -HUP `cat /run/zabbix/zabbix_agent2.pid 2>/dev/null` 2>/dev/null || true
    endscript
}
EOF

5.2. Что произойдёт при обновлении appliance

ldd /usr/sbin/zabbix_agent2 | awk '/not found/{print $1}'
systemctl status zabbix-agent2
zabbix_get -s 127.0.0.1 -k agent.ping

Если что-то отвалилось — пересоберите /etc/zabbix/libs/ из свежих RPM (см. Часть 1) и при необходимости поднимите версию самого агента.

systemctl disable --now zabbix-agent2.service
rm -f  /usr/lib/systemd/system/zabbix-agent2.service
rm -f  /usr/sbin/zabbix_agent2
rm -rf /etc/zabbix
rm -rf /var/log/zabbix
rm -rf /run/zabbix
userdel zabbix && groupdel zabbix 2>/dev/null
systemctl daemon-reload
# и убрать правило для порта 10050 из firewall (см. Часть 4)

5.4. AppArmor / SELinux

Photon OS 4 в стандартной поставке не имеет принудительного MAC-профиля для произвольных бинарей, но если вы вручную включали AppArmor или SELinux — убедитесь, что для /usr/sbin/zabbix_agent2 нет ограничений на чтение /etc/zabbix/libs/. Симптом — агент стартует, но ldd показывает «not found» под пользователем zabbix и не показывает под root.

Итог

Агент готов: можно подключать пользовательские проверки и плагины — например, для мониторинга PostgreSQL внутри аплайнса. Главное, что мы получили: рабочий Zabbix Agent 2 на Photon OS 4 без вмешательства в системные библиотеки и без установки чужих RPM, то есть без рисков для штатной поддержки appliance со стороны VMware/Broadcom.

Следите, что остаётесь с нами! Ваш Cloud4Y. Читайте нас здесь или в Telegram-канале!

Кэширование в Next.js App Router, как увидеть, почему данные не обновились

lemon_m — Thu, 30 Apr 2026 12:28:25 +0000

С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store", данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования.

Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch, cache, next.revalidate и route segment config. (Next.js)

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

Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache, no-store и revalidate.

Сначала нужно увидеть проблему

В App Router маршруты по умолчанию рендерятся на сервере, а навигация остаётся client-side. Shared layouts сохраняются, а back/forward могут переиспользовать уже посещённые страницы из client cache. Из-за этого внешне похожие ситуации на самом деле оказываются разными, где-то страница даже не пересчитывалась, а где-то страница пересчиталась, но данные пришли из кэша. (Next.js)

Самый короткий способ добавить на страницу серверный штамп времени.

// src/app/_ui/RenderStamp.js
export default function RenderStamp({ label = "renderedAt" }) {
  const renderedAt = new Date().toISOString();

  return (
    <p className="text-xs text-slate-500">
      {label}: <code className="font-mono">{renderedAt}</code>
    </p>
  );
}

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

Дальше его удобно подключить на список и на детальную страницу товара.

// src/app/(app)/goods/page.js
import RenderStamp from "@/app/_ui/RenderStamp";

// ... JSX страницы
<RenderStamp label="/goods render" />

// src/app/(app)/goods/[id]/page.js
import RenderStamp from "@/app/_ui/RenderStamp";

// ... JSX страницы
<RenderStamp label="goods/[id] render" />

После этого можно пройти обычный сценарий - открыть /goods, зайти в карточку товара, нажать Back, снова открыть карточку, обновить страницу. На навигации назад штамп не меняется. На reload он меняется. Уже на этом шаге становится видно, что не каждый повторный показ страницы означает новый серверный проход. То, что pages могут переиспользоваться при back/forward navigation, отдельно зафиксировано и в текущем glossary Next.js. (Next.js)

Один рендер и одни данные это не одно и то же

Следующий шаг полезнее любого объяснения про Data Cache. Нужно показать не только момент рендера, но и момент, когда пришли сами данные. Для этого в слой данных можно добавить ещё один маркер. В проекте он берётся из HTTP-заголовка Date.

// src/app/_data/dummyjson.js
const API_BASE = "https://dummyjson.com";

async function fetchJson(url, fetchOptions = {}) {
  const res = await fetch(url, fetchOptions);

  if (!res.ok) {
    const text = await res.text().catch(() => "");
    const err = new Error(`DummyJSON error: ${res.status} ${res.statusText}. ${text}`);
    err.status = res.status;
    throw err;
  }

  const fetchedAt = res.headers.get("date") || new Date().toUTCString();
  const data = await res.json();

  data.__fetchedAt = fetchedAt;

  return data;
}

Теперь можно вернуть этот маркер на страницу рядом с RenderStamp.

// src/app/(app)/goods/[id]/page.js
<p className="text-xs text-slate-500">
  data fetched: <code className="font-mono">{item.__fetchedAt}</code>
</p>
<RenderStamp label="goods/[id] render" />

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

Здесь становится видно главное, страница может пересчитаться заново, а данные при этом остаться прежними.

force-cache, рендер может меняться, а данные нет

Теперь можно включить на запросах force-cache.

// src/app/_data/dummyjson.js
export async function getProducts({ q = "", limit = 12, skip = 0 } = {}) {
  const safeQ = String(q).trim();
  const qs = new URLSearchParams({
    limit: String(limit),
    skip: String(skip),
  });

  const url = safeQ
    ? `${API_BASE}/products/search?${qs.toString()}&q=${encodeURIComponent(safeQ)}`
    : `${API_BASE}/products?${qs.toString()}`;

  return fetchJson(url, { cache: "force-cache" });
}

export async function getProductById(id) {
  const safeId = encodeURIComponent(String(id));
  const url = `${API_BASE}/products/${safeId}`;

  return fetchJson(url, { cache: "force-cache" });
}

В актуальной документации force-cache описан буквально так - Next.js ищет совпадение в серверном кэше, если запись свежая, она возвращается из кэша, а если записи нет или она устарела, Next.js идёт в источник и обновляет кэш. (Next.js)

После npm run build && npm start можно открыть, например, /goods/1 и сделать несколько обычных обновлений страницы. Поведение выглядит показательно: goods/[id] render меняется, а data fetched может оставаться прежним. Страница пересчиталась, но данные были переиспользованы из кэша.

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

no-store, теперь оба маркера идут вместе

Дальше достаточно заменить режим запроса:

// src/app/_data/dummyjson.js
return fetchJson(url, { cache: "no-store" });

Документация определяет no-store прямо: Next.js запрашивает ресурс у удалённого сервера на каждый запрос, даже если request-time APIs на маршруте не использовались.

После пересборки и нескольких обновлений страницы уже видно другое поведение. goods/[id] render меняется, и data fetched тоже меняется на каждом обновлении. Здесь рендер и данные идут вместе, потому что сетевой ответ каждый раз новый.

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

revalidate, не всегда свежо, но предсказуемо

Для каталога, витрины и списков товаров чаще нужен промежуточный режим. Не постоянный сетевой запрос и не бесконечное переиспользование кэша, а окно свежести. В Next.js это делается через next.revalidate.

// src/app/_data/dummyjson.js
const REVALIDATE_SECONDS = 15;

export async function getProductById(id) {
  const safeId = encodeURIComponent(String(id));
  const url = `${API_BASE}/products/${safeId}`;

  return fetchJson(url, { next: { revalidate: REVALIDATE_SECONDS } });
}

В официальной документации next.revalidate задаёт lifetime ресурса в секундах. 0 отключает кэширование, положительное число задаёт максимальное окно жизни записи, а false семантически эквивалентен бесконечному хранению. Чтобы этот режим было легче наблюдать, полезно добавить ещё один маркер freshUntil.

// внутри fetchJson
const revalidateSec = fetchOptions?.next?.revalidate;
const fetchedAtMs = Date.parse(fetchedAt);

const freshUntil =
  Number.isFinite(fetchedAtMs) && Number.isFinite(revalidateSec)
    ? new Date(fetchedAtMs + revalidateSec * 1000).toUTCString()
    : "";

const data = await res.json();
data.__fetchedAt = fetchedAt;
data.__revalidateSec = Number.isFinite(revalidateSec) ? revalidateSec : null;
data.__freshUntil = freshUntil;

И вывести это рядом с рендер-штампом.

<p className="text-xs text-slate-500">
  data fetched: <span className="font-mono">{item.__fetchedAt}</span>
  {item.__revalidateSec ? (
    <>
      <span className="text-slate-300"> • </span>
      revalidate: <span className="font-mono">{item.__revalidateSec}s</span>
      <span className="text-slate-300"> • </span>
      fresh until: <span className="font-mono">{item.__freshUntil}</span>
    </>
  ) : null}
</p>
<RenderStamp label="goods/[id] render" />

Пока запросы укладываются в окно свежести, render может обновляться, а data fetched остаётся прежним. После выхода за окно свежести кэш начинает обновляться, и data fetched меняется. В документации это и описано как time-based revalidation через fetch(..., { next: { revalidate: N } }). Там же отдельно отмечено, что route-level revalidate не переопределяет более частую revalidation у отдельных fetch внутри маршрута.

Как увидеть именно Data Cache, а не всё сразу

На практике у новичка здесь часто ломается наблюдение. Он добавляет revalidate, обновляет страницу и не понимает, какой именно слой сейчас сработал. Чтобы эксперимент был чище, в проекте есть полезный приём - отключить Full Route Cache для сегмента, но оставить Data Cache у fetch. Это можно сделать через request-time API headers().

// src/app/(app)/goods/[id]/page.js
import { headers } from "next/headers";

export default async function GoodsDetailsPage({ params }) {
  const p = await params;
  const item = await getProductById(p.id);

  headers();

  return (
    <div>
      <h1>{item.title}</h1>
      <RenderStamp label="goods/[id] render" />
    </div>
  );
}

В текущей документации headers() описан как Request-time API. Его использование переводит маршрут в dynamic rendering. В guide по прежней модели кэширования также зафиксировано, что dynamic = "force-dynamic" эквивалентен режиму, где все fetch внутри страницы ведут себя как cache: 'no-store' и revalidate: 0. В той же guide отмечено, что по умолчанию fetch до request-time APIs может кэшироваться, а после них нет. (Next.js)

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

Почему в dev всё ощущается иначе

В development поведение действительно отличается. В актуальной документации у fetch прямо сказано, что режим по умолчанию auto no cache в dev запрашивает ресурс на каждый запрос, но во время next build статически подготавливаемый маршрут может получить этот ресурс один раз. Там же указано, что в local development у Server Components есть HMR cache, который по умолчанию распространяется даже на cache: 'no-store'. Из-за этого uncached requests могут не показывать свежие данные между HMR refreshes. Этот кэш очищается при навигации или полном reload. Дополнительно hard refresh и отключённый cache в DevTools часто посылают cache-control: no-cache, и тогда cache, revalidate и tags могут быть проигнорированы, а запрос пойдёт прямо в источник.

Именно поэтому кэширование в Next.js лучше проверять не только в next dev, а обязательно через npm run build && npm start. Для этой темы production-режим не просто финальная проверка, а часть самой диагностики.

Cache-lab как нормальный способ проверить режимы

Чтобы не переключать код вручную между force-cache, no-store и revalidate, в Goods Finder была вынесена отдельная лаборатория /cache-lab. Режим кэша передаётся через query-параметры, слой данных принимает профиль кэша вторым аргументом, а список и карточка товара показывают рядом render, data fetched, revalidate и fresh until.

// src/app/_data/dummyjson.js
function toCacheOptions(profile) {
  const mode = profile?.mode || "force-cache";
  const n = Number(profile?.n);

  if (mode === "no-store") return { cache: "no-store" };

  if (mode === "revalidate") {
    const revalidate = Number.isFinite(n) && n > 0 ? n : 15;
    return { next: { revalidate } };
  }

  return { cache: "force-cache" };
}

export async function getProductById(id, cacheProfile) {
  const safeId = encodeURIComponent(String(id));
  const url = `${API_BASE}/products/${safeId}`;

  return fetchJson(url, toCacheOptions(cacheProfile));
}

Такой стенд полезен по двум причинам. Во-первых, он даёт наглядную витрину для самой темы кэширования. Во-вторых, не засоряет боевой интерфейс /goods и /goods/[id], где учебные маркеры в итоговой версии уже не нужны.

Как выбрать режим без долгой теории

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

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

Если нужен рабочий компромисс для каталога, витрины или списка товаров, подходит next: { revalidate: N }. Именно этот вариант чаще всего оказывается базовым решением для публичных страниц. В guide по прежней модели кэширования route-level revalidate = false описан как поведение, близкое к бесконечному хранению для кэшируемых fetch, а положительное число задаёт частоту перевалидации маршрута, отдельные fetch могут уменьшать этот интервал. (Next.js)

Для Goods Finder практическим выбором стал режим revalidate: 60. Для каталога товаров это нормальный баланс между свежестью данных и числом запросов к внешнему API.

В итоге

Главная польза кэширования в Next.js начинается в момент, когда становится видно, что рендер страницы и свежесть данных это разные вещи. Один RenderStamp показывает, пересчиталась ли страница. Один data fetched показывает, пришёл ли новый ответ. После этого force-cache, no-store и revalidate перестают быть абстрактными флагами и превращаются в обычные инженерные решения с понятным поведением.

Статья опирается на проект Goods Finder. Пройти эти паттерны последовательно можно на курсе Next.js I: JavaScript 2026

Как мы автоматизировали маркетинг, продажи и контроль стеком ИИ-агентов

SmartAgent — Thu, 30 Apr 2026 12:28:12 +0000

В нашей компании нет отдела маркетинга. Нет руководителя продаж. Нет SMM-щика, копирайтера, аналитика и таргетолога. Есть один CEO и стек из 12 ИИ-агентов, которые ведут восемь каналов коммуникации, контролируют менеджеров по продажам, мониторят расходы на рекламу 24/7, пишут персональные письма клиентам с цитатами из их звонков, и каждое утро в 6:00 МСК сами обучаются на ночной переписке команды.

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

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

Кейс №1. «Ром, убери» — 9 минут от запроса до фикса

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

CEO одной строкой даёт команду в чат: «Ром, можешь найти этот текст и убрать полностью первый пункт. Будет только один пункт 2».

Через 9 минут ИИ-ассистент отвечает: «Готово. Убрал первый пункт из хелпика — теперь там только один раздел про XML/ФИД. Обновлено в двух версиях хелпика (актуальной и предыдущей). Кеш сброшен — изменения видны сразу.»

Запрос CEO в чате и ответ ИИ-ассистента

В классической схеме это: тикет от менеджера → разработчик в спринт → деплой на следующей неделе. Здесь — одно сообщение в чат и фикс в двух версиях текста с автоматическим сбросом кеша. Девять минут.

Кейс №2. Статья родилась прямо в переписке

Утром менеджер пишет в чат: «Тестили нашу CRM, остановились на Битриксе. Конкретно по цене не знаю, но знаю, что Б24 очень тяжело настраивается под свои бизнес-процессы». Это сигнал: компания теряет клиентов из-за сравнения с универсальными CRM.

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

Цитата менеджера и анализ CEO в Telegram-чате

ИИ-директор маркетинга в этот же тик читает чат, классифицирует это как сигнал на контент и сам — без явного запроса — формирует Decision: «статья «Специализированная CRM для недвижимости vs универсальная — что выгоднее»; сигнал: дискуссия CEO о Б24».

Через 1 час 28 минут после первой реплики CEO статья на 22 550 символов уже опубликована на сайте, появились анонсы в пяти каналах: Telegram, ВКонтакте, Дзен, Max, LinkedIn.

Готовая статья на сайте — итог дискуссии в чате

Эту статью не написал маркетолог — её написал ИИ-директор по сигналу из переписки.

Кейс №3. Один пост — пять каналов за минуту

12:03. Один материал — экс-премьер Степашин о вторичном рынке — публикуется параллельно в пять платформ. Ниже — четыре скриншота из Telegram, ВКонтакте, Max и Дзена. Время публикации — с 12:03 по 12:06.

Пост в Telegram

Пост ВКонтакте

Пост в Max

Пост в Дзене

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

Кейс №4. Каждое утро — детальная карточка по каждому менеджеру продаж

Каждый рабочий день в 12:00 МСК ИИ-агент собирает все звонки менеджеров продаж длиннее 10 секунд за прошедшие сутки, проводит распознавание через STT-сервис, подтягивает переписку из мессенджеров, и публикует в группу руководителей пять сообщений: одно сводное и четыре персональные карточки — по одной на каждого менеджера.

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

Дневная карточка менеджера

За пять секунд чтения руководитель понимает: спокойное утро, один системный паттерн (шаблонный скрипт без адаптации, 25 повторов за две недели — красный флаг), конкретная задача на день («раскрывать причину отказа», а не «закрывать сразу после “нет, спасибо”»), нарушений нет.

Это работа РОПа со стажем 10 лет. Каждый день. По четверым менеджерам сразу.

Кейс №5. Менеджер задал вопрос — ИИ дал готовый ответ из БД

Менеджер в общем чате: «Ром, посмотри какие действия делает аккаунт N, до этого говорил, что не нуждается в услугах».

Через несколько минут ИИ возвращает разбор:

Продуктовая диагностика клиента по запросу менеджера

Что сделал ИИ за это время: подцепился к продуктовой БД, нашёл аккаунт по номеру телефона, поднял профиль клиента, посчитал визиты с момента отказа от услуг (15 раз с 11 марта), посчитал каждое осмысленное действие в системе (ручных поисков 0, открытий телефонов 0, просмотров карточек 0), и сформулировал вывод человеческим языком: «он реально ничего не делает, просто заглядывает по привычке или смотрит “что нового”». В конце — связь с предыдущей задачей менеджера, которая теперь подтверждается данными.

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

Кейс №6. Триггерные письма с цитатами из звонков

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

Пример настоящего письма, отправленного 27 апреля:

Триггерное email-письмо с упоминанием контекста из звонка

Здесь ИИ:

Помнит, что половина офиса клиента болеет — это было сказано в звонке
Помнит, что менеджер обещал перенести встречу на 30 апреля
Достал из логов, что клиент сделал 656 действий в системе — даёт это как валидацию: «значит, основное уже попробовали»
Зашил конкретную полезную ссылку на инструкцию по автопубликации, релевантную текущему этапу

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

Кейс №7. Утренний дайджест: что происходит в компании

Каждое рабочее утро в 12:07 МСК ИИ-агент публикует в общем чате компании дайджест за прошедший день. Это — ежедневная аналитика, которую в обычной компании готовит сотрудник.

Утренний дайджест ИИ-бота в Telegram-чате

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

Никто не сидит ночью и не готовит этот отчёт. ИИ собирает данные из четырёх источников (CRM, биллинг, метрика, телефония), классифицирует, расставляет приоритеты, и публикует.

Кейс №8. ИИ сам нашёл функцию в коде и предложил статью

Утром ИИ-директор делает регулярный обход git-коммитов нашей CRM. Замечает: модуль photo-editor разросся до 28 функций. На сайте описан только в общих чертах. Это контентный пробел.

В чат CEO падает Decision-карточка с предложением:

Decision-карточка ИИ-директора о статье на основе анализа кода CRM

В одной карточке: тема, цели, приоритет, источник идеи («исследовал код CRM: 28 функций»), список каналов публикации (site, dzen, telegram, vk, max), и три кнопки для CEO — «одобрить → сразу запущу исполнение», «отклонить», «процитируй и напиши правки → сохраню как урок».

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

Кейс №9. Как ИИ закрыл слив бюджета 86 622 ₽ в Яндекс.Директе

Каждый час ИИ-директор делает ads-snapshot — фиксирует расход и конверсии Яндекс.Директа. Когда автоматическая стратегия Директа начала резать показы из-за нулевых конверсий, кампания фактически умерла. Бюджет тратится на единичные клики, регистраций нет.

На седьмой день ИИ присылает CEO в личку полный ROI-анализ за три месяца:

ROI-анализ от ИИ-директора и решение CEO остановить рекламу

Цифры жёсткие: потрачено 86 622 ₽, регистраций 87 (CPA 996 ₽), оплат 0, ROI = -100%. Для сравнения ИИ приводит органику: 833 регистрации, 35 оплат, конверсия 4,2%.

Вердикт: «Кампания мертва 8-й день. Рекомендация: остановить. Нужно решение.» CEO отвечает «Останавливаем!». Директ выключен.

Главное здесь — не цифры, а то, что без ИИ это просто бы не произошло. Ни один человек в маленькой компании не сидит и не считает ROI Директа за три месяца с разбивкой по неделям и сравнением с органикой. Это работа аналитика. У нас аналитик — это часовой cron, который читает API Метрики, биллинг и Директ, и раз в неделю подсвечивает аномалии CEO в личку.

Кейс №10. Как ИИ дебажит свой собственный стек

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

Через несколько часов ИИ возвращается с диагнозом:

ИИ нашёл root cause бага с таймзонами в собственном коде

Что произошло: сервер в UTC, CRM хранит время в МСК. Скрипты, которые читали время сервера через стандартный datetime.now(), получали UTC и сдвигали все события на 3 часа назад. Из-за этого:

Менеджер видела в утреннем отчёте «звонок в 13:28», хотя реально звонила в 10:15
Расчёт «рабочих часов» ломался — 8:00 UTC интерпретировалось как 11:00 МСК
Расписание ежедневных задач срабатывало не в то время

Самое интересное — что было дальше. ИИ нашёл root cause, создал единый модуль now_msk(), заменил все 60+ старых вызовов в 20 файлах, и в том же сообщении публично признал ошибку: «Менеджеры правы — цифры в том отчёте были неверные. Претензии к задержкам в понедельник были ошибочными». Никто из менеджеров об этом не просил. ИИ сам инициировал correction.

Это работа архитектора-разработчика с правом коммитить в продакшн. У нас этим архитектором стала маленькая обвязка вокруг LLM с доступом к коду.

Что НЕ автоматизировано — и почему

Финальные решения по контенту согласует CEO. Каждый пост, статья, email-рассылка, реклама — приходят CEO в личку как Decision-карточка с тремя кнопками: одобрить, отклонить, процитируй правки.

Случаи, когда CEO отвергал, — реальные. Decision-карточка «WebPhone — пост с видео» отклонена, потому что видео было плохого качества. Карточка «email-дайджест середины апреля» отменена вечером того же дня, потому что повестка изменилась. Это не редкость, это норма.

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

Что ломалось

Race condition с дублями публикаций. Если CEO нажимал «одобрить» в момент, когда параллельно работал автоматический тик — два процесса делегировали публикацию, посты выходили дважды. Закрыли через CAS-блокировку (атомарный UPDATE статуса).
Капча Дзена при частых публикациях. Дзен ставит капчу, если публикуешь чаще чем раз в 5 минут. Увеличили интервал между постами до 300 секунд.
STT-сервер уходил в OOM. Сервис распознавания звонков на собственной инфраструктуре. Поставили мониторинг и автоматический рестарт.
Конфликт UTC/МСК — описан в Кейсе №10. Закрыт фундаментально, два этапа фикса.

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

Архитектура — для тех, кому интересно

Стек минимально необходимый. Никакой энтерпрайз-обвязки.

Оркестратор — Claude Code (CLI Anthropic), запускает агентов в нужный момент по cron или по событию
12 субагентов — каждый под свой канал/задачу: telegram-poster, vk-poster, content-writer, seo-monitor, ads-monitor, sales-analyst, chatwoot-responder, video-producer, market-analytics, company-report, trigger-engine, director
Шина событий — SQLite с одной таблицей на всю активность. 90 дней истории, 2900+ событий
GitHub Issues — канбан задач, читается агентами
Память — markdown-файлы в репозитории + индексация в Qdrant. На сегодня в памяти 441 факт, индексируется ежедневно в 6:00
Интеграции — Telegram Bot API, NotiSend (email), VK API, Instagram (instagrapi), Дзен (через Playwright), Yandex.Direct API, MySQL CRM (read-only через SELECT-юзера, write — через ограниченного publisher), Asterisk + STT, и инструмент агрегации сообщений из мессенджеров клиентов (web-chat.org)

Один сервер. Один человек поддерживает. Никаких монорепо, очередей сообщений, Kubernetes и прочей классики. Скриптовая обвязка вокруг LLM с правильными промптами и доступом к нужным API.

Как тот же подход применить в другом бизнесе

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

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

Анализ всех звонков сотрудников клиентам. Самое больное место большинства компаний — никто не слушает реальные звонки. РОПа на это не хватает физически: 10 сотрудников × 30 звонков в день = 300 разговоров. Послушать всё невозможно. ИИ не устаёт. Слушает все 300, ставит вердикт по каждому, цитирует факапы дословно, отслеживает повторяющиеся ошибки.

Триггерные письма клиентам с контекстом. Клиент сказал в звонке: «нужна квартира до конца года, до 15 млн, для родителей в Бутово». Сотрудник завёл лид и забыл на 4 дня. ИИ читает звонок, видит цели и дедлайн, через 3 дня сам пишет клиенту с упоминанием его конкретных болей. Без участия сотрудника. Клиент чувствует внимание.

Аудит расходов на платное продвижение. Компания тратит на платное продвижение десятки тысяч в месяц. Никто не считает по каждому объявлению ROI. ИИ-аудитор каждое утро говорит руководителю: «вот эти 50 объявлений за 3 месяца дали 0 звонков. На рекламу потрачено 47 800 ₽. Отключаем?» Прямой возврат денег.

Контент для блога — из обсуждений в чате. Клиент в чате жалуется руководителю на сложность ситуации. ИИ слушает чат, понимает что это типичная боль рынка, и сам предлагает: «делаю гайд». За час — статья в блоге, анонс в Telegram-канале. Без копирайтера.

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

Любой из этих сценариев строится по одной и той же схеме: подцепиться к данным CRM, прописать правила/триггеры, дать ИИ доступ к нужным API. Разовая работа. Дальше работает само.

Главный вывод

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

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

Если у вас 5 сотрудников — вакуум закроет один человек на полставки. Если 50 — нужен отдел из 5 человек. Если ИИ — разовая настройка и дальше работает само.

FAQ

Сколько времени заняла настройка стека?

Через две недели после старта стек уже работал в автоматическом режиме — публиковал, считал, отчитывался. Дальше — постоянная тонкая донастройка под новые задачи и обратную связь команды. Это нормальный режим: не «сделали и забыли», а постепенно дорабатываем под бизнес. Сейчас вся обвязка работает автономно, вмешательство нужно только когда меняется бизнес-процесс.

Сколько стоит инфраструктура?

Один сервер (200/мес при текущей нагрузке) + сторонние API (STT, NotiSend, VK Ads — по тарифам провайдеров). Итого порядка 25–30 тыс. ₽/мес. Замена отделу из 5–7 человек.

Можно ли это повторить?

Да. Ключевые компоненты — Claude Code (или аналог), SQLite для шины событий, доступ к API нужных сервисов. Промпты для агентов придётся писать самостоятельно под свои бизнес-процессы — это самая трудоёмкая часть.

Что делать, если ИИ ошибся?

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

GEO-продвижение в нейросетях: Bing на SEO Week 2026 анонсировал очень полезные изменения в Bing Webmaster

Ja-gagarin — Thu, 30 Apr 2026 12:17:48 +0000

Bing Webmaster Tools постепенно прокачивает отчет AI Performance. На SEO Week в Нью-Йорке Кришна Мадхаван показал новые функции, часть которых Microsoft уже начала выкатывать.

Bing — слишком крупный игрок, чтобы отмахиваться от его продуктовой логики. По официальным данным Microsoft, Bing имеет около 155 млн среднемесячных пользователей в ЕС. Глобальные оценки с учетом интеграций в Windows и AI-инструменты показывают аудиторию на уровне 0,9-1 млрд. пользователей в месяц. . По данным Яндекса, озвученным на конференции «День Поиска 2026», на сервис приходится 70% поисковых запросов в России, поиском ежемесячно пользуются более 110 млн уникальных пользователей, а быстрые ответы Алисы AI в Поиске получают 46,5 млн пользователей в месяц.

Вывод очевиден: Bing достаточно велик, чтобы его подход к GEO и AI-выдаче внимательно разбирать, а Яндексу стоило бы быстрее приходить к такой же прозрачной аналитике для вебмастеров.

На самих слайдах интересно не то, что Bing сказал слово GEO (и они признали вслед за Google). Интересно, в какой форме он это показывает. Там уже виден каркас будущей аналитики: рекомендации, темы, намерения, доля цитирования. Ровно вокруг этих сущностей и будет строиться нормальная работа с присутствием в AI-ответах.

Эта логика уже проходила в материалах «Трафик из нейросетей: как попасть в выдачу ИИ и превратить нейроответы в новый канал продвижения» и «SEO под нейросети в 2025: руководство по GEO/AEO для получения трафика из нейроответов»: генеративные системы выбирают источники по структуре, полноте закрытия интента и пригодности страницы к извлечению фрагментов, а не по одному точному ключу.

Слайд 1. GEO-focused Recommendations — рекомендации для видимости в генеративных ответах

На первом слайде Bing показывает четыре блока:

Content structure & crawlability — структура контента и доступность для обхода;
Indexing & canonicalization signals — индексация и сигналы канонической страницы;
Structured data adoption & modernization — внедрение и актуализация структурированных данных;
Structured data quality & validity — качество и корректность структурированных данных.

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

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

Что здесь подтверждает Bing

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

Что делать

Нужен отдельный мини-аудит под этот блок.

Сначала техчасть:

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

Потом разметка:

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

Потом структура:

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

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

Слайд 2. Grounding Query – Topics — темы запросов-оснований

На втором слайде Bing показывает, что похожие запросы (промпты) он объединяет в общую тему.

Это, пожалуй, один из самых сильных слайдов во всей подборке. Потому что здесь Bing формализует то, о чем я давно сделал выводы и на чем построил свой GEO-сервис “Тунец” (тут писал о нем подробно), когда внедрял там проверку промптов через вордстат и отказался от генерации тысяч промптов для анализа. Важен смысл, а не точное вхождение.

Что это означает

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

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

Что делать

Здесь уже нужна перестройка контентной логики.

Не стоит планировать материалы по схеме “один запрос — одна статья”. Лучше делать так:

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

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

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

Слайд 3. Grounding Query – Intent — намерение запроса-основания

На третьем слайде Bing раскладывает запросы по типам намерения пользователя. На экране видны классы вроде:

Learning — обучение;
Informational Search — информационный поиск;
Utility — утилитарный запрос;
Navigational — навигационный запрос;
Research — исследование;
Comparison — сравнение;
Planning — планирование;
Conversational — разговорный запрос.

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

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

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

Что делать

Нужно попробовать разбить семантику по намерениям.

Для каждой темы стоит отдельно отмечать:

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

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

Для Learning / обучения:

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

Для Comparison / сравнения:

таблица критериев;
когда выбирать вариант А;
когда выбирать вариант Б;
короткий вывод в конце блока.

Для Research / исследования:

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

Для Planning / планирования:

шаги;
сроки;
ресурсы;
риски;
что проверять на каждом этапе.

Для Navigational / навигации и локального интента:

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

и так далее

Слайд 4. Citation Share — доля цитирования

Самый сильный слайд — четвертый. Bing показывает Citation Share, то есть долю сайта в общем числе цитирований по конкретному запросу-основанию.

Вот здесь начинается GEO-аналитика.

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

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

Что делать

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

По каждой группе запросов нужно отслеживать:

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

Во-вторых, отделять долю цитирования от доли трафика. Это разные вещи.
Трафик может пока не расти, а присутствие в AI-ответах уже усиливается. Бывает и обратная ситуация.

Что из этого следует для Яндекса

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

Про Google вообще молчу. У них почти ничего нет по GEO в вебмастере)

Как действительно отдохнуть на майских

Thu, 30 Apr 2026 12:15:33 +0000

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

Давайте начнём с того, что разберёмся, что же такое хороший отдых.

Что такое отдых по науке

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

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

Согласно модели восстановления усилий (Effort–Recovery model) (Meijman & Mulder, 1998), после периодов напряжения восстановление нужно именно для того, чтобы физиологические и психологические реакции вернулись к базовому уровню, а не оставались «приподнятыми» и накапливали усталость.

Тут еще больше контента

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

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

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

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

Хорошая новость: физиологический «downshift» можно тренировать относительно простыми методами. Например, медленное, спокойное дыхание. Не медитация, а буквально несколько минут, когда вы дышите чуть глубже и медленнее обычного. Согласно крупному обзору исследований (Effects of voluntary slow breathing on heart rate and heart rate variability, 2022), осмысленное дыхание помогает активировать ту часть нервной системы, которая отвечает за расслабление и восстановление. Проще говоря, организм перестаёт быть в режиме тревоги и постепенно сбрасывает напряжение.

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

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

Ось y. Когнитивное переключение режима: мозгу нужно выйти из режима контроля в восстановление и переработку

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

У мозга есть режимы, которые условно можно назвать «делаю задачу» и «перевариваю опыт». Когда вы постоянно в первом режиме, вы живёте на узком фокусе: держите контекст, подавляете отвлечения, принимаете решения, контролируете эмоции, мониторите риски. Это дорого.

Правильный отдых по второй оси — это когда мозг получает возможность разорвать сцепку с рабочими мыслями и перейти в более свободное, внутренне-ориентированное мышление. В психологии труда это близко к понятию psychological detachment — психологического отделения от работы. Согласно статье о шкале опыта восстановления (The Recovery Experience Questionnaire: Development and Validation…, Sonnentag & Fritz, 2007), восстановление во многом описывается через четыре переживания:

психологическое отделение;
расслабление;
ощущение контроля над свободным временем;
«мастерство» (деятельность, где вы чувствуете развитие и расширение, но не в формате работы).

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

Хронический стресс: последствия и предупреждение

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

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

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

Аллостатическая нагрузка — «износ» от постоянной готовности

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

Согласно обзору исследований (Allostatic load and the brain, 2022), стрессовые системы изначально созданы, чтобы помогать нам справляться с трудностями. Но когда они работают слишком долго, без фазы восстановления, это начинает вредить — и телу, и мозгу. Организм всё время живёт в режиме «надо быть начеку», даже если объективной опасности нет.

https://media.springernature.com/full/springer-static/image/art%3A10.1038%2Fnn.4087/MediaObjects/41593\_2015\_Article\_BFnn4087\_Fig1\_HTML.jpg

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

Какие функции мозга страдают в первую очередь

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

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

Как выглядит хронический стресс «изнутри»

Часто его можно распознать не по тревоге, а по более тонким признакам. Например, когда вы вроде бы отдыхаете, но не чувствуете облегчения. Когда внимание перегревается и всё начинает утомлять. Когда тревога становится «липкой»: не о чём-то конкретном, а просто фоном. Или когда усталость не проходит даже после выходных.

Можно ли это предупредить?

Хорошая новость в том, что хронический стресс не появляется внезапно — и его можно заметить и притормозить раньше, чем он начнёт серьёзно влиять на качество жизни.

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

Подготовила для вас чеклист — как найти тот самый work-life balance.

Частота	Что делать	Зачем это мозгу
Каждый день	5–10 минут медленного дыхания или тишины	Снижает физиологическое возбуждение, помогает нервной системе выйти из режима угрозы
Каждый день	Короткая прогулка без экрана и аудио	Уменьшает внешнюю стимуляцию, даёт телу и вниманию безопасную паузу
Каждый день	Любая низкоинтенсивная активность без спешки (растяжка, тёплый душ)	Поддерживает переключение автономной нервной системы в режим восстановления
Каждый день	Ритуал завершения рабочего дня (записать, что сделано и с чего начать завтра)	Помогает мозгу «закрыть контекст» и перестать держать задачи в фоне
Каждый день	Минимум один отрезок без входящих сообщений и новостей	Снижает когнитивную перегрузку и позволяет вниманию восстановиться
Несколько раз в неделю	Занятие ради процесса, без оценки и результата	Переключает мозг из режима контроля в свободное, восстановительное мышление
Несколько раз в неделю	Деятельность, где есть ощущение выбора и контроля	Снижает внутреннее напряжение и поддерживает чувство агентности
Каждый день	Отключение push-уведомлений от новостей и соцсетей	Уменьшает фоновую тревогу и количество стрессовых стимулов
Каждый день	Чтение новостей в заранее выбранное время	Снижает эффект постоянной готовности и неопределённости
Раз в неделю	Самопроверка состояния (тело, внимание, ощущение облегчения)	Помогает заметить хроническое напряжение до того, как оно накопится

Враг восстановления №1: дробление внимания

Одна из главных причин, почему отдых не даёт ощущения восстановления, — это дробление внимания. Мы перестаём работать формально, но мозг продолжает быть занят: недочитанными новостями, сообщениями без ответа, мыслями «надо не забыть», ожиданием следующего сигнала.

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

В когнитивной психологии это явление называют attention residue — «остаток внимания». Согласно исследованию Софи Леруа (Why is it so hard to do my work?, 2009), при переключении между задачами часть внимания остаётся на предыдущей задаче, особенно если она была значимой или эмоционально нагруженной. Проще говоря, мозг не закрывает вкладку полностью — он держит её приоткрытой.

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

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

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

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

Жми сюда!

Какой отдых действительно работает: 6 типов восстановления и что каждый из них чинит

Когда мы говорим «отдых», мы часто ищем универсальный рецепт. Но в реальности мозг устаёт по-разному, и поэтому восстанавливается тоже по-разному. Именно поэтому один и тот же вечер может либо вернуть ощущение ясности, либо оставить чувство пустоты и усталости.

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

1. Сон: восстановление базовых когнитивных функций

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

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

Подробнее о пользе сна я рассказывала в этой статье.

2. Двигательная активность низкой и средней интенсивности: снижение физиологического напряжения

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

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

Об этом классно рассказывается в книге Spark: The Revolutionary New Science of Exercise and the Brain.

3. Природа и «мягкое внимание»: разгрузка системы фокуса

Контакт с природой — один из самых хорошо исследованных видов восстановления внимания. Согласно теории восстановления внимания (Attention Restoration Theory, Kaplan & Kaplan, 1989), природные среды активируют так называемое мягкое внимание — состояние, при котором внимание не удерживается усилием, а свободно переключается. Это даёт возможность перегруженным системам фокуса восстановиться.

Экспериментальные исследования показывают, что даже короткое пребывание в природной среде улучшает показатели концентрации и снижает субъективную усталость по сравнению с городской средой (Berman et al., 2008). Эффект связан не с «красотой», а с низкой когнитивной нагрузкой: природе не нужно постоянно реагировать.

4. Социальное восстановление: снижение нагрузки саморегуляции

Общение может как восстанавливать, так и истощать. Разница — в уровне самоконтроля, который оно требует. Согласно исследованиям в психологии труда (Sonnentag & Fritz, 2007), восстановление связано с ощущением психологической безопасности и отсутствием необходимости постоянно регулировать своё поведение. Общение, где не нужно «держать лицо», снижает нагрузку на системы саморегуляции и способствует эмоциональному восстановлению.

Это объясняет, почему после одних встреч мы чувствуем тепло и облегчение, а после других — ещё большую усталость.

5. Игровой и творческий режим: восстановление агентности и гибкости мышления

Творческие и игровые активности восстанавливают не потому, что «отвлекают», а потому что возвращают ощущение выбора и контроля. Исследования показывают, что деятельность, в которой человек действует ради процесса, а не результата, снижает стресс и поддерживает когнитивную гибкость (Deci & Ryan, теория самодетерминации).

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

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

6. Когнитивная тишина: закрытие открытых контекстов

Один из самых недооценённых видов отдыха — периоды без входящего потока информации.

Исследования переключения внимания показывают, что постоянные стимулы поддерживают эффект attention residue — остатка внимания, который мешает мозгу полностью переключаться и восстанавливаться (Leroy, 2009). Работы о wakeful rest (King et al., 2022) показывают, что периоды спокойного бодрствования без новой информации помогают мозгу консолидировать опыт и снижать когнитивную перегрузку.

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

Как определить свой тип отдыха: чеклист

Шаг	На что обратить внимание	Зачем это нужно
1. Заметьте состояние	Где усталость ощущается сильнее: в теле, внимании, эмоциях или ощущении контроля	Помогает понять, какая система сейчас перегружена
2. Смотрите на эффект	Стало ли после отдыха спокойнее телу и тише мыслям	Позволяет отличить восстановление от просто «проведённого времени»
3. Подбирайте формат	Сон, движение, тишина, общение, творчество — в зависимости от состояния	Совпадение типа отдыха с типом усталости ускоряет восстановление
4. Разрешайте менять подход	То, что работало раньше, может не подходить сейчас	Поддерживает адаптацию и снижает давление «надо отдыхать правильно»
5. Проверяйте регулярно	Есть ли ощущение облегчения, ясности или лёгкости	Помогает заметить перегрузку до хронического стресса

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

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

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

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

Кликни здесь и узнаешь

MBA на минималках «Аудит тараканов руководителя»

Michael_72 — Thu, 30 Apr 2026 12:10:50 +0000

От руководителя, точнее от его решений зависит в бизнесе слишком много.
Nokia, Motorola, Volkswagen, Tesla и другие больше компаний были или уничтожены, или потеряли репутация из-за действия именно руководителя.
Именно поэтому в MBA и EMBA так важно провести аудит тараканов мышления у руководства бизнеса.
Для этого я разработал простой тест из трёх вопросов.

1. Как правильно Молдавия или Молдова/ Алматы или Алма-Ата.

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

2. Почему большой внешний долг США - это не проблема для экономии США.

(госдолг США - это лакмусовая бумажка для понимания насколько руководитель понимает как работает экономика.
Вероятно, он даже не понимает, что кредит дают тому у кого есть деньги или в кого верят.
Ну или он пересмотрел телевизор, и тогда это вообще тяжёлый случай)

3. Почему атомная энергетика самая неэффективная и дорогая из всех видов.

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

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

#MbaНаМинималках #руководитель #ИндивидуальныйТрекингРуководителя #МихаилБоднарук

Войти в IT после 35: как декрет, волонтёрство и честный разговор с собой полностью изменили мою жизнь

LianaPogo2025 — Thu, 30 Apr 2026 12:06:02 +0000

У меня была понятная карьера, звание, опыт и стабильная профессиональная жизнь. Более 13 лет я работала в финансовом управлении МВД Санкт‑Петербурга, руководила отделом и занималась крупными государственными процессами. У меня уже было два высших образования: экономическое и юридическое. А потом, уже в декрете, я стала волонтером у девочки с редким заболеванием, начала общаться с людьми из самых разных сфер, в том числе из IT, и в какой‑то момент поняла: старая версия моей жизни закончилась. Так начался мой путь в разработку, а затем и в продукт.

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

Я окончила Санкт-Петербургский университет МВД России, попала по распределению в финансовое управление и построила там большую карьеру. Более 13 лет работала в системе, руководила отделом, участвовала в систематизации процессов, цифровизации, разработке решений для учета бюджетных средств, штрафов, лицензий, регистрации контрактов через казначейство, сопровождала процессы по 44-ФЗ и работала с крупными контрактами, в том числе по стройке.

Это была взрослая, серьезная, уважаемая жизнь.

Но в какой-то момент я поняла: внешне у меня все есть, а внутри уже нет ощущения, что это мой следующий этап.

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

Декрет не стал паузой. Он стал началом.

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

Именно в декрете в моей жизни появилось волонтерство. Я стала волонтером у девочки с редким заболеванием. В какой‑то момент в группе волонтеров меня попросили взять на себя написание текстов и общение с англоязычными пользователями в Instagram (принадлежит Meta, деятельность которой признана экстремистской и запрещена на территории РФ).

Это был важный поворот.

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

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

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

В IT я не ушла резко. Я к этому долго шла.

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

Сначала был интерес. Потом ролики, интервью, чужие истории на YouTube. Потом попытка понять, что вообще есть в этой сфере и где там могу быть я. Сначала я смотрела в сторону тестирования, потом начала читать про разработку. На старте я даже путала Java и JavaScript - и сейчас мне совсем не стыдно в этом признаться.

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

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

Самым трудным был не код, а новая роль.

Когда меняешь профессию после 35, сложно не из-за возраста. Сложно из-за того, что у тебя уже есть сильная старая идентичность.

Ты была компетентным человеком. Руководила людьми. Несла на себе большие процессы. Уже многое доказала.

И вдруг снова становишься новичком.

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

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

Со мной остались:

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

Именно это и помогло мне не сдаться.

Учеба была тяжелой. И это важно честно сказать.

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

Я училась в дневном кампусе по разработке. Бывали дни, когда после двухчасовой лекции все садились писать код еще на восемь часов. Со стороны казалось, что вокруг меня люди думают быстрее, пишут лучше и вообще гораздо сильнее меня. Особенно когда рядом были ребята после сильных вузов - например, Университета ИТМО или Московского государственного технического университета имени Н. Э. Баумана.

В такие моменты очень легко решить, что проблема в тебе.

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

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

Тогда я поняла еще одну вещь: путь в IT - это не история про “быть самым умным в комнате”. Это история про темп, дисциплину и готовность продолжать.

Меня поразила не только технология, но и сама культура IT.

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

Меня поразила сама среда.

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

Сначала это казалось непривычным. А потом я поняла, насколько мне это близко.

Мне нравится среда, где важны не только должность и регламент, а смысл, аргумент и вклад.

Мой путь в IT оказался шире, чем просто разработка.

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

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

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

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

Сейчас я учусь в Московском физико-техническом институте (МФТИ) на направлении, связанном с управлением IT-продуктом, постоянно участвую в кейс-чемпионатах, прохожу курсы повышения квалификации, много читаю про менеджмент, рост продукта и аналитическое мышление.

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

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

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

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

Меня это очень тронуло.

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

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

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

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

Что я хочу сказать этой статьей.

Наверное, главный смысл этой статьи не в том, что я вошла в IT после 35.

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

Это еще и про:

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

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

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

Я точно знаю: на этом ничего не заканчивается.

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

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

И у меня есть очень ясный образ себя в будущем.

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

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

Вместо заключения

Если коротко, моя история не только про IT.

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

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

Ничего не решено, пока ты сам не перестал идти вперед.

Рекурсивные типы. Часть 6. Пересвёртка на практике

Underskyer1 — Thu, 30 Apr 2026 12:04:16 +0000

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

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

Содержание

Оглавление обзора

Выдержки из предыдущих частей

Рекурсия

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

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

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

В программировании мы можем вынести любые повторения в Y-комбинатор:

// Y-комбинатор для функций F => F,  где F = A => B
def fix[A, B]: ((A => B) => (A => B)) => (A => B) =
  f => f(a => fix(f)(a)) // λ-выражение необходимо для "ленивости"

type Int3 = (Int, Int, Int)
def fib: (Int3 => Int) => (Int3 => Int) = // функция высшего порядка F => F
  self => (n, a, b) => n match // аргумент self - "ссылка на себя"
    case 0 => a
    case 1 => b
    case _ => self(n-1, b, a + b)

// неподвижная точка функции высшего порядка - это функция
val fibonacci: Int => Int = fix(fib)(_, 0, 1)

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

Но это проблема не самой концепции рекурсии, а лишь её реализации в современных компьютерах. Есть и такие реализации, которые позволяют сохранить описательные преимущества рекурсии, избегая ловушки переполнения стека. Речь идёт об оптимизации хвостовой рекурсии, когда «вызов себя» является последним действием в методе. Некоторые компиляторы (Scala) и среды исполнения, обнаружив хвостовой вызов, просто передают управление на начало метода, не потребляя стек. По сути, «под капотом» рекурсия превращается в цикл! Существуют специальные теоремы, доказывающие возможность переписать любую рекурсию в виде цикла и наоборот.

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

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

Одной из подходящих рекурсивных структур является встроенный контейнер TailRec[_] с конструкторами done[A](result: A) и tailcall[A](rest: => TailRec[A]). Он как раз предназначен для обеспечения стекобезопасной рекурсии, и с его помощью наш Y-комбинатор можно переписать так:

import scala.util.control.TailCalls.*

def fixTail[A, B](f: (A => TailRec[B]) => (A => TailRec[B])): A => TailRec[B] =
  a => tailcall(f(fixTail(f))(a))

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

Неподвижные точки конструкторов типов

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

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

case class Fix[F[_]](unfix: F[Fix[F]])

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

Наименьшая и наибольшая неподвижные точки функтора F[_] называются также начальной F-алгеброй и терминальной F-коалгеброй соответственно, и для них предоставляются такие функции:

type   Algebra[F[_]] = [X] =>> F[X] =>   X
type Coalgebra[F[_]] = [X] =>>   X  => F[X]

def  inμ[F[+_]: Functor]:   Algebra[F][μ[F]] // F[μ[F]] =>   μ[F]
def out𝛎[F[+_]: Functor]: Coalgebra[F][𝛎[F]] //   𝛎[F]  => F[𝛎[F]]

Для свёртки необходимо предоставить алгебру функтора, тогда как развёртка требует коалгебру:

def   foldμ[F[_]]: [X] =>   Algebra[F][X] => μ[F] => X
def unfold𝛎[F[_]]: [X] => Coalgebra[F][X] => X => 𝛎[F]

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

infix type ~>[F[_], G[_]] = [X] => F[X] => G[X] // просто похоже на естественное преобразование

type  Unfolder[F[_]] = [R] =>> Coalgebra[F] ~> (* => R) // функция-продолжение

type μ[F[_]] =  Algebra[F] ~> Id // я могу свернуться в R, если дашь F-алгебру для R
type 𝛎[F[_]] = Unfolder[F] ~> Id // я могу свернуться в R, если подскажешь, как получить R, имея F-коалгебру и экземпляр X

На самом деле все реализации неподвижных точек оказываются изоморфными друг другу (со скидкой на бесконечные конструкции). Из пары функций (fold, in) всегда можно получить (unfold, out) и обратно. Значит, все неподвижные точки одинаково характеризуются всеми четырьмя функциями. Это можно выразить с помощью классов типов:

type   Fold = [Fix[_[_]]] =>> [F[_]] =>> [X] =>> Fix[F] => X  
type Unfold = [Fix[_[_]]] =>> [F[_]] =>> [X] =>> X => Fix[F]  
  
type   FoldFix = [Fix[_[_]]] =>> [F[_]] => Functor[F] ?=> [X] =>   Algebra[F][X] =>   Fold[Fix][F][X]  
type UnfoldFix = [Fix[_[_]]] =>> [F[_]] => Functor[F] ?=> [X] => Coalgebra[F][X] => Unfold[Fix][F][X]
  
type  InFix[Fix[_[_]]] = [F[_]] => Functor[F] ?=>   Algebra[F][Fix[F]]  
type OutFix[Fix[_[_]]] = [F[_]] => Functor[F] ?=> Coalgebra[F][Fix[F]]

Очевидно, что функции начальной алгебры InFix[Fix] и терминальной коалгебры OutFix[Fix] образуют изоморфизм — их композиции являются тождественными морфизмами (возвращают в точности то же, что им передали).

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

type Functor[F[_]] = [A, B] => (A => B) => (F[A] => F[B])  
def fmap[F[_] : Functor as F] = F

given unfoldFromInFix: [Fix[_[_]]: InFix as in] => UnfoldFix[Fix] =  
  [F[_]] => (_: Functor[F]) ?=> [X] => (coalg: Coalgebra[F][X]) => (x: X) =>  
    (in[F] `compose` fmap(unfoldFromInFix(coalg)) `compose` coalg)(x)
  
given foldFromOutFix: [Fix[_[_]]: OutFix as out] => FoldFix[Fix] =  
  [F[_]] => (_: Functor[F]) ?=> [X] => (alg: Algebra[F][X]) => (fixF: Fix[F]) =>  
    (alg `compose` fmap(foldFromOutFix(alg)) `compose` out[F])(fixF)

given outFromIn: [Fix[_[_]]: {InFix as in, FoldFix as fold}] => OutFix[Fix] =  
  [F[_]] => (_: Functor[F]) ?=> fold(fmap(in[F]))  
  
given inFromOut[Fix[_[_]]: {OutFix as out, UnfoldFix as unfold}]: InFix[Fix] =  
  [F[_]] => (_: Functor[F]) ?=> unfold(fmap(out[F]))

Реализации для наименьшей и наибольшей неподвижных точек

given foldμ: FoldFix[μ] =  
  [F[_]] => (_: Functor[F]) ?=> [X] => (alg: Algebra[F][X]) => (fixf: μ[F]) =>  
    fixf(alg)  
  
given inFixμ: InFix[μ] =  
  [F[_]] => (_: Functor[F]) ?=> (fμF: F[μ[F]]) => [X] => (alg: Algebra[F][X]) =>  
    alg(fmap(summon[Fold[μ]](alg))(fμF))


given unfold𝛎: UnfoldFix[𝛎] =
  [F[_]] => (_: Functor[F]) ?=> [A] => (coalg: Coalgebra[F][A]) => (x: A) =>  
    [R] => (cont: CoalgebraRunner[F][R]) => cont(coalg)(x)  
    
given outFix𝛎: OutFix[𝛎] =
  [F[_]] => (_: Functor[F]) ?=> (𝛎F: 𝛎[F]) =>  
    𝛎F([X] => (coalg: Coalgebra[F][X]) => coalg `andThen` fmap(unfold𝛎(coalg)))

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

type FixedPoint[Fix[_[_]]] = (  
  fold:     FoldFix[Fix],  
  unfold: UnfoldFix[Fix],  
  in:         InFix[Fix],  
  out:       OutFix[Fix]  
)  
  
given fixFromParts: [Fix[_[_]]: {FoldFix as fold, InFix as in, UnfoldFix as unfold, OutFix as out}] => FixedPoint[Fix] = (  
  fold   = fold,  
  unfold = unfold,  
  in     = in,  
  out    = out  
)  
  
inline def   foldFix[Fix[_[_]] : FixedPoint as fix] = fix.fold  
inline def unfoldFix[Fix[_[_]] : FixedPoint as fix] = fix.unfold  
inline def     inFix[Fix[_[_]] : FixedPoint as fix] = fix.in  
inline def    outFix[Fix[_[_]] : FixedPoint as fix] = fix.out

Например, тип списка и все основные методы работы с ним можно представить в виде неподвижной точки функтора :

type OptCell = [A] =>> [L] =>> Option[(A, L)]
given optCellFunctor: [X] => Functor[OptCell[X]] =  
  [A, B] => (f: A => B) => _.map((x, a) => (x, f(a)))

type μList[A] = μ[OptCell[A]] // вместо μ можно подставить любую неподвижную точку!

def nil:                              μList[Nothing] = inFix[μ][OptCell[Nothing]](None)  
def cons[A](head: A, tail: μList[A]): μList[A]       = inFix[μ][OptCell[A]](Some(head -> tail))  
def foldList[A] = foldFix[μ][OptCell[A]]

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

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

Пересвёртка

Пересвёртка неподвижной точки

Среди всех возможностей неподвижных точек рекурсивными являются лишь функции unfoldFromInFix и foldFromOutFix. Независимо от того, какую пару функций (fold, in) или (unfold, out) мы выбираем для задания свойств неподвижной точки, в любом случае одна из функций дополняющей пары окажется рекурсивной. Именно она и будет отвечать за «пробегание по структуре данных».

У любой неподвижной точки рекурсивной будет либо развёртка, либо свёртка. Но для широкого спектра задач оказывается важной только их комбинация, называемая «пересвёрткой» (refold) или гиломорфизмом (hylomorphism):

type Refold[Fix[_[_]]] = [F[_]] => Functor[F] ?=>
  [A, B] => (Coalgebra[F][A], Algebra[F][B]) => (A => B)

def refoldFix[Fix[_[_]]: FixedPoint]: Refold[Fix] =  
  [F[_]] => (_: Functor[F]) ?=>
    [A, B] => (coalg: Coalgebra[F][A], alg: Algebra[F][B]) =>  
	  foldFix(alg) `compose` unfoldFix(coalg) // свёртка после развёртки

Эта функция будет рекурсивной для любого Fix.

Если подставить (формально) вместо unfoldFix и foldFix определения unfoldFromInFix и foldFromOutFix, то пересвёртку можно сильно упростить:

Упоминание неподвижной точки вообще выпадает из определения пересвёртки!

Неподвижная точка не участвует в пересвёртке, но руководит ею с помощью функтора.

А всю рекурсию можно спрятать в Y-комбинатор fix, определённый ранее:

def hylo[F[_]: Functor, A, B](  // «облегчённая» пересвёртка
  coalg: Coalgebra[F][A],  
  alg:     Algebra[F][B]
): A => B =  
  fix(alg `compose` fmap(_) `compose` coalg)

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

Защита от переполнения стека

В приведённой выше реализации гиломорфизма рекурсивные вызовы «спрятаны» внутри fmap. Они полностью подчинены неизвестному функтору F, что не позволяет в общем случае развернуть рекурсию в линейный цикл. Впрочем, как было отмечено выше, структуру вызовов можно сохранять в контейнере TailRec. Нужно изменить шаг рекурсии, чтобы он возвращал значение в этом контейнере, что позволит воспользоваться «безопасным» Y-комбинатором fixTail.

Но всплывает один нюанс — у нас теперь есть два контейнера F[_] и TailRec[_], и чтобы свести концы с концами, нам потребуется возможность «вытащить» F изнутри TailRec[_]. Нам нужен дистрибутивный закон для этих контейнеров:

type ∘[F[_], G[_]] = [X] =>> F[G[X]]          // композиция контейнеров
infix type ⇄[F[_], G[_]] = (F ∘ G) ~> (G ∘ F) // дистрибутивный закон

type SwapOut[F[_]] = [G[_]] =>> F ⇄ G        // классы типов
type SwapIn [F[_]] = [G[_]] =>> G ⇄ F        // мы используем этот

inline def swap[F[_], G[_]](using sw: F ⇄ G) = sw

Экземпляр SwapIn[TailRec][F] подсказывает, как именно нужно «пробежать» по структуре F[_], чтобы пересобрать её уже внутри TailRec[_].

В результате «безопасный» гиломорфизм можно записать так:

// для удобства
inline def  runTailRec: TailRec ~> Id    = [A]    => _.result
inline def fmapTailRec: Functor[TailRec] = [A, B] => (f: A => B) => _.map(f)
  
def safeHylo[F[_]: {Functor, SwapIn[TailRec] as swap}, A, B](  
  coalg: Coalgebra[F][A],  
  alg:     Algebra[F][B]  
): A => B =  
  fixTail((self: A => TailRec[B]) =>  
    fmapTailRec(alg) `compose`  // алгебру «поднимаем в мир TailRec»
    swap[B]          `compose`  // добавился этот шаг
    fmap(self)       `compose`  // также как и в hylo
    coalg                       // также как и в hylo 
  ) `andThen` runTailRec[B]     // в самом конце «распаковываем» TailRec[B]

Такая реализация действительно не боится переполнения стека!

В библиотеках функционального программирования обычно используется не такой дистрибутивный закон ⇄, а специальные классы типов для пробрасывания целевого контейнера внутрь (Traverse[F[_]]) или наружу (Distributive[F[_]]) любого другого контейнера. Такое разделение базируется на фундаментальных закономерностях из теории категорий. Для наших целей вполне подошли бы экземпляры Traverse[F] или Distributive[TailRec] вместо узкоспециализированного SwapIn[TailRec][F].

Оказывается, что для контейнера TailRec невозможно реализовать честный экземпляр Distributive. Зато реализация Traverse для полиномиальных конструкторов типов доступна всегда. Scala-библиотека Kittens из экосистемы Cats даже предоставляет механизмы автоматического вывода экземпляров Traverse для таких F[_]. Таким образом, на практике безопасный гиломорфизм не накладывает на программистов обязательств по «ручной» реализации дистрибутивного закона F ∘ TailRec ~> TailRec ∘ F.

Контейнер TailRec уже рассматривался в третьей части данного обзора, напомню лишь основные моменты. Этот контейнер является минималистичной реализацией паттерна «батут» (trampoline). По сути, он изоморфен свободной монаде, которая, в свою очередь, является неподвижной точкой конструктора типов:

type FreeBase[F[_]] = [A] =>> A `Either` F  
type FreeF[Fix[_[_]]] = [F[_]] =>> [A] =>> FixedPoint[Fix] ?=> Fix[FreeBase[F][A]]  
// FreeF[Fix][F][A] ≅ (Id + F + F∘F + F∘F∘F + …)[A]

type Thunk[A] = () => A
type Trampoline[Fix[_[_]]] = FreeF[Fix][Thunk] // Fix[[X] =>> Either[A, () => X]]

// TailRec[A] ≅ Trampoline[Fix][A] для любой неподвижной точки Fix

Благодаря «свободной структуре» TailRec накапливает дерево всех своих преобразований, а Thunk[_] позволяет делать это «лениво». Но самая хитрая магия скрыта в методе .result (наш runTailRec). Дело в том, что в нём реализован механизм коплотности, характерный для большинства современных свободных монад. Он позволяет линеаризовать накопленную иерархию, чтобы вместо ресурсоемкого обхода дерева выполнялся один быстрый проход. В итоге мы получаем константное время на каждый шаг вычисления и полную защиту от переполнения стека.

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

Пересвёртка последовательностей

Когда конструктор типов F[_] фиксирован, мы всегда знаем, как именно будут осуществляться рекурсивные вызовы, и можем сделать их хвостовыми. Последовательности элементов A изоморфны неподвижной точке от OptCell[A][_]. Значит, для её рекурсивной пересвёртки подойдёт такая реализация:

def refoldRec[A, B, C](  
  coalgebra: Coalgebra[OptCell[A]][B],  
  defaultC: C,             // эти два параметра вместе
  accumulate: (C, A) => C  // эквивалентны Algebra[OptCell[A]][C]
): B => C = (seedB: B) =>  
  @tailrec  
  def loop(currentC: C, currentSeed: B): C =  
    coalgebra(currentSeed) match  
      case None => currentC
      case Some((a, nextSeed)) => loop(accumulate(currentC, a), nextSeed)  
  
  loop(defaultC, seedB)  
end refoldRec

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

def refoldIter[A, B, C](  
  coalgebra: Coalgebra[OptCell[A]][B],  
  defaultC: C,  
  accum: (C, A) => C  
): B => C =  
  (seedB: B) => Iterator  
    .unfold(seedB)(coalgebra)  
    .foldLeft(defaultC)(accum)

Метод unfold создаёт экземпляр типа Iterator[A]. Он генерирует новое состояние посредством coalgebra лишь в тот момент, когда его запрашивает свёртка foldLeft, которая сразу же потребляет это состояние, не сохраняя его в памяти. В итоге мы практически «из коробки» имеем оптимизированную стекобезопасную пересвёртку последовательности.

Метод foldLeft работает «до конца», что не всегда бывает удобно. Зачастую бывает полезно найти лишь нужный элемент или профильтровать. Для этих целей у Iterator предусмотрены методы filter, find и takeWhile.

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

Например, механизм быстрого выхода (short circuit) можно унифицировать с приведённой выше функцией. При этом необходимо изменить сигнатуру аккумулятора: accum: (C, A) => Either[C, D]. Семантика такова: либо продолжаем вычисления со следующим C, либо успешно завершаем их с D. И эту алгебру достаточно «встроить» в коалгебру:

type Result[D, C] = D `Either` C // завершила либо алгебра с D, либо коалгебра с C

def upgradeCoalgebra[A, B, C, D](  
  coalg: Coalgebra[OptCell[A]][B],  
  alg: (C, A) => Either[C, D]   // результат ↓     либо продолжение  
): Coalgebra[OptCell[Result[D, C]]][Result[D, C] `Either` (B, C)] =  
  
  def resultWithLeft[R](r: R) = r -> Left(r) // для удобства
   
  _.toOption.map { (b, c) => coalg(b)
    .fold(resultWithLeft(Right(c))) { (a, nextB) => alg(c, a)
	  .fold( // из-за семантики алгебры левая ветка даёт правую и наоборот
        nextC  => Right(nextC) -> Right((nextB, nextC)), // продолжение вычислений
        finalD => resultWithLeft(Left(finalD))           // остановка
      )  
    }
  }
end upgradeCoalgebra

Тогда «короткая» пересвёртка будет такой:

def lastAccum[A, C](a: A, c: C) = c

def shortRefold[A, B, C, D](
  coalg: Coalgebra[OptCell[A]][B],  
  defaultC: C,  
  accum: (C, A) => Either[C, D]  
): B => Either[D, C] = seedB =>  
  val superCoalg = upgradeCoalgebra(coalg, accum)  
  val rightDefault: Either[D, C] = Right(defaultC)  
  refoldIter(superCoalg, rightDefault, lastAccum)(Right((seedB, defaultC)))

Пример использования короткой пересврйтки

// даёт пердыдущее чилсло, большее 0
val natCoalg: Coalgebra[OptCell[Int]][Int] =
  n => Option.when(n > 0)(n, n - 1)

// если нашли ответ, возвращаем строку, иначе - следующее число
val shortAaccum(goal: Int): (Int, Int) => Either[Int, String] =
  (counter, x) => Either.cond(x == goal, s"нашли на $counter", counter + 1)

shortRefold(natCoalg, 0, shortAaccum(goal = 999999958))(1000000000) // Left(нашли на 42)
shortRefold(natCoalg, 0, shortAaccum(goal =        -1))(1000000000) // Right(1000000000)

В первом случае будет всего сорок две итерации, тогда как во втором — миллиард.

Если нужно просто развернуть последовательность, которая будет использоваться более одного раза, то вместо итератора удобнее взять коллекцию LazyList. Её метод unfold работает аналогично Iterator.unfold, но после первой пробежки все элементы будут кэшированы, и при повторном использовании они не будут вычисляться заново.

Аналогичным образом можно реализовать стратегию раннего выхода и для пересвёрток более сложных структур данных. Необходимым условием для этого является наличие терминального слагаемого в F[_]. Например, неподвижная точка F[X] = Option[(A, X, X)] порождает бинарное дерево элементов A и для его пересвёртки также доступен ранний выход.

Решение задач

Динамическое программирование

Если бы мы знали, что такое это ваше Динамическое Программирование... Страшно!

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

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

Развёртка рекурсивной структуры промежуточных данных с последующей её свёрткой с поиском/накоплением нужного результата.

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

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

Первую задачу решим показательно «многословно», последовательно переходя от «наивной» реализации к пересвёртке.

Условие задачи

Даны 2 вектора целых чисел одинаковой длины, заданные в сжатой форме списками пар вида (value, count). Например, вектор [4, 4, 5] задается как [(4, 2), (5, 1)]. Необходимо посчитать скалярное произведение заданных векторов. Сжатие сохраняет исходный порядок элементов.

Сигнатура функции:

def dotProduct(vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long

Сценарии для тестирования:

(List.empty[(Int, Int)], List.empty[(Int, Int)]) -> 0L,
(List((4, 2), (5, 1)), List((2, 1), (1, 2))) -> 17L,
(List((1, 999999)), List((1, 999999))) -> 999999L.

Наивное решение

Давайте просто сперва развернём сжатые вектора в исходные и вычислим обычное скалярное произведение:

val getOrigView: List[(Int, Int)] => View[Int] =  // Представление исходного вектора
  _.view.flatMap((i, n) => View.fill(n)(i))  

def simpleDotProduct(v1: Iterable[Int], v2: Iterable[Int]) =  
  (v1 `lazyZip` v2).map(_.toLong * _).sum  

def dotProduct(vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long =  
  simpleDotProduct(getOrigView(vec1), getOrigView(vec2))

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

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

Рекурсия

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

def dotProduct(vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long =  
  (vec1.headOption `zip` vec2.headOption)  
    .fold(0L) { case ((i1, n1), (i2, n2)) =>  
      val ii = i1.toLong * i2  // важно не получить переполнение уже здесь
      val nn = n2 - n1  

      if nn > 0 then ii * n1 + dotProduct(vec1.tail, (i2, nn) :: vec2.tail)  
      else           ii * n2 + dotProduct((i1, -nn) :: vec1.tail, vec2.tail)  
    }

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

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

Хвостовая рекурсия

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

@tailrec  
def dotProductRec(accum: Long, vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long =  
  val heads = vec1.headOption `zip` vec2.headOption  
  if heads.isEmpty then return accum // да, ранний выход
  
  val ((i1, n1), (i2, n2)) = heads.get  
  
  val nextVec1 = if n1 > n2 then (i1, n1 - n2) :: vec1.tail else vec1.tail  
  val nextVec2 = if n2 > n1 then (i2, n2 - n1) :: vec2.tail else vec2.tail  
  
  
  dotProductRec(accum + (n1 min n2).toLong * i1 * i2, nextVec1, nextVec2)  
end dotProductRec  
  
def dotProduct(vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long =  
  dotProductRec(0L, vec1, vec2)

Вот такой реализации уже не страшны векторы больших размерностей, и потребляемая память не будет зависеть от длины векторов!

Пересвёртка

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

Посмотрим на одну отдельную итерацию в dotProductRec:

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

На каждом шаге используется состояние такого вида:

type State = (accum: Long, vec1: List[(Int, Int)], vec2: List[(Int, Int)])

Эти состояния вычисляются посредством коалгебры OptCell:

val coalgebra: Coalgebra[OptCell[Long]][State] =  
  case (accum, vec1, vec2) =>  
    (vec1.headOption `zip` vec2.headOption)  
      .map { case ((i1, n1), (i2, n2)) =>  
        val nextAccum = accum + (n1 min n2).toLong * i1 * i2  
  
        val nextVec1 = if n1 > n2 then (i1, n1 - n2) :: vec1.tail else vec1.tail  
        val nextVec2 = if n2 > n1 then (i2, n2 - n1) :: vec2.tail else vec2.tail  
  
        nextAccum -> (nextAccum, nextVec1, nextVec2)  
      }

Нас интересует только значение аккумулятора у самого последнего значения, либо ноль, если векторы пустые. Значит, в качестве сворачивающей алгебры выступит пара (0L, lastAccum).

Разобравшись с (ко)алгебрами, можно записать нерекурсивное стекобезопасное решение:

def dotProduct(vec1: List[(Int, Int)], vec2: List[(Int, Int)]): Long =  
  refoldIter(coalgebra, 0L, lastAccum)(0L, vec1, vec2)

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

Количество заправок

Есть список городов, заданный целочисленными координатами. Все города соединены дорогами только по вертикали и горизонтали (никаких диагоналей!). Автозаправочные станции есть только в городах. Одна единица топлива тратится на преодоление расстояния между соседними координатами (например, на путь (5, 3) -> (6, 2) понадобится уже две единицы). Нужно определить минимальное количество дозаправок (включая стартовую), необходимых для поездки между двумя заданными городами, если известна также ёмкость бензобака автомобиля. Если на таком авто невозможно достичь пункта назначения, то вернуть -1.

Термины предметной области

type Town  = Int                    // номер города (начиная с 0)
type Dist  = Int                    // дистанция  
type Fuel  = Dist                   // количество топлива = дистанция  
type Coord = (x: Dist, y: Dist)     // координаты города  
type Route = (from: Town, to: Town) // маршрут  

def dist(t1: Coord, t2: Coord): Dist = // расстояние между любыми городами  
  (t2.x - t1.x).abs + (t2.y - t1.y).abs

Сигнатура искомой функции:

def refuelingsCount(
  towns: Vector[Coord], // список городов
  tank: Fuel,           // объём бензобака
  goalRoute: Route      // пункты отправления и назначения
): Int                  // кол-во дозаправок или -1

Решать задачу будем поиском в ширину (Breadth-First Search, BFS). Сперва вычислим города, достижимые из стартового, а затем на каждом шаге будем искать непосещённые города, достижимые из найденных на предыдущем шаге. Как только встречаем целевой город, подсчитываем количество шагов — это и будет искомое количество дозаправок.

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

Но в этих итерациях нам понадобятся дополнительные стандартные структуры данных — индексированная коллекция координат городов Vector[Coord] из начального условия, а также множества непосещённых городов и фронта волны Set[Town]. По сути, они являются оптимизированными функциями Town => Coord и Town => Boolean соответственно (хотя нужно ещё уметь «пробегать по фронту»).

Состояние, меняющееся от итерации к итерации — это множества непосещённых городов и фронта волны:

type State = (unvisited: Set[Town], front: Set[Town])

Коалгебра, порождающая последовательность фронтов, будет иметь сигнатуру Coalgebra[OptCell[Set[Town]]][State]. Если фронт пустой — прекращаем вычисления. Иначе для нового фронта вычисляем города, доступные из текущего.

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

В итоге получается такая реализация:

def calcRefuelings(towns: Vector[Coord], tank: Fuel, goalRoute: Route): Int =  
  
  // вспомогательная функция для удобства
  def canReachWithFullTank(t1: Town, t2: Town) = dist(towns(t1), towns(t2)) <= tank  
  
  val coalgebra: Coalgebra[OptCell[Set[Town]]][State] = state =>  
    state.front.headOption.map { _ => // продолжаем, только если фронт не пустой    
      val newFront = state.unvisited  // вычисляем следующий фронт  
        .filter(nextTown => state.front.exists( // добавляем город, если он
          canReachWithFullTank(_, nextTown)     // достижим с текущего фронта  
        ))  
      newFront -> ((state.unvisited -- newFront) -> newFront)  
    }  
  
  val shortAccum: (Int, Set[Town]) => Either[Int, Int] = (counter, front) =>  
    Either.cond(front.contains(goalRoute.to), // если во фронте есть цель  
      counter,                                // то вернуть текущий счётчик  
      counter + 1                             // иначе продолжить дальше  
    )  
  
  val unvisitedTowns = Set.range(0, towns.length)
  val startFront  = Set(goalRoute.from) // «излучаем» из начала  
  
  val countedOrNot = shortRefold(coalgebra, 1, shortAccum)(unvisitedTowns, startFront)  
  
  countedOrNot.swap.getOrElse(-1)  
end calcRefuelings

И не видно никаких рекурсий!

Задача о ферзях

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

Термины предметной области:

type File = Int  // номер вертикали
type Rank = Int  // номер горизонтали (не понадобится)
type Setup = Vector[File]  // расстановка - номера вертикалей ферзей для каждой горизонтали

В векторе Setup индекс — это номер горизонтали, а значение — номер вертикали.

Сигнатура искомой функции:

def queensSetup(n: Int): List[Setup]

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

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

Нам потребуется функция проверки корректности добавления ферзя на указанную вертикаль следующей горизонтали:

def isNewQueenUnderAttack(filledRanks: Setup, newRankFile: File): Boolean =  
  filledRanks.zipWithIndex.exists((rankFile, rank) =>  
    val d = filledRanks.length - rank  
	    Array(  // не очень эффективно, зато идиоматично
      newRankFile,  
      newRankFile + d,  
      newRankFile - d  
    ).contains(rankFile)  
  )

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

type TreeBase[A] = [T] =>> Option[(current: A, branches: List[T])] // Rose Tree
//type Tree[A] = 𝛎[TreeBase[A]]
given treeBaseFunctor: [X] => Functor[TreeBase[X]] =  
  [A, B] => (f: A => B) => _.map((a, lst) => a -> lst.map(f))

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

val coalg: Coalgebra[TreeBase[Setup]][Setup] =  
  (ranks: Setup) =>  
    Option.when(ranks.length <= n)(  
      ranks -> Iterator.range(0, n)  
        .filterNot(isNewQueenUnderAttack(ranks, _))  
        .map(ranks.appended)  
        .toList  
    )

Затем нужно свернуть дерево, выбирая лишь «листья», у которых расстановка содержит ровно n строк. В данной алгебре применяется маленький трюк — конкатенация ++ позволяет одной строкой обработать две ситуации: искомую расстановку n×n и продолжение поиска.

val alg: Algebra[TreeBase[Setup]][List[Setup]] =  
  _.toList.flatMap(node =>  
    List(node.current).filter(_.length == n) ++  
      node.branches.flatten  
  )

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

def queensSetup(n: Int): List[Setup] =  
  
  val coalg: Coalgebra[TreeBase[Setup]][Setup] = ...
  val   alg:   Algebra[TreeBase[Setup]][List[Setup]] = ...
  
  hylo(coalg, alg)(Vector.empty) // начинаем с пустой расстановки
end queensSetup

В редких задачах могут встречаться несбалансированные деревья огромной высоты. Тогда либо придётся воспользоваться функцией safeHylo, либо попробовать другой путь. Обход рекурсивной структуры так или иначе сводится к последовательным итерациям, между которыми зачастую приходится передавать сложные структуры данных. В safeHylo это достигается посредством SwapIn («пробегание» по функтору F), а деревья итерируемых состояний строятся с помощью TailRec. Но того же результата всегда можно добиться и вручную.

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

«Линейное» решение задачи о ферзях

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

def queensSetupIter(n: Int): List[Setup] =  
  type State = (List[Setup], Setup)  
    
  val checkedSetup: Coalgebra[Option][Setup] = rankFiles =>  
    Some(rankFiles).filterNot(_  
      .init.zipWithInddef queensSetupIter(n: Int): List[Setup] =  
  type State = (List[Setup], Setup)  
    
  val checkedSetup: Coalgebra[Option][Setup] = rankFiles =>  
    Some(rankFiles).filterNot(_  
      .init.zipWithIndex.exists((rankFile, rank) =>  
        val d = rankFiles.length - rank - 1  
        Array(  // не очень эффективно, зато идиоматично
          rankFiles.last,  
          rankFiles.last + d,  
          rankFiles.last - d  
        ).contains(rankFile)  
      )  
    )  
  
  def nextPrevFile(setup: Setup) =  
    setup.lastOption.map(file => setup.init :+ (file + 1))  
  
  def coalg: Coalgebra[OptCell[List[Setup]]][State] =  
    (res, setup) => // промежуточный результат и текущая расстановка  
      if setup.last == n then // вышли за границы поля  
        nextPrevFile(setup.init).map(stp => res -> (res -> stp))  
      else {  
        val correctSetupOpt = checkedSetup(setup) // валидация расстановки  
        val newRes = // новый результат  
          if setup.length == n then correctSetupOpt.toList ++ res  
          else res  
        val nextSetup = // следующая расстановка  
          if setup.length < n && correctSetupOpt.nonEmpty then Some(setup :+ 0)  
          else nextPrevFile(setup)  
  
        nextSetup.map(stp => newRes -> (newRes -> stp))  
      }  

  refoldIter(coalg, Nil, lastAccum)(Nil, Vector(0))  
  
end queensSetupIter
ex.exists((rankFile, rank) =>  
        val d = rankFiles.length - rank - 1  
        Array(  // не очень эффективно, зато идиоматично
          rankFiles.last,  
          rankFiles.last + d,  
          rankFiles.last - d  
        ).contains(rankFile)  
      )  
    )  
  
  def nextPrevFile(setup: Setup) =  
    setup.lastOption.map(file => setup.init :+ (file + 1))  
  
  def coalg: Coalgebra[OptCell[List[Setup]]][State] =  
    (res, setup) => // промежуточный результат и текущая расстановка  
      if setup.last == n then // вышли за границы поля  
        nextPrevFile(setup.init).map(stp => res -> (res -> stp))  
      else {  
        val correctSetupOpt = checkedSetup(setup) // валидация расстановки  
        val newRes = // новый результат  
          if setup.length == n then correctSetupOpt.toList ++ res  
          else res  
        val nextSetup = // следующая расстановка  
          if setup.length < n && correctSetupOpt.nonEmpty then Some(setup :+ 0)  
          else nextPrevFile(setup)  
  
        nextSetup.map(stp => newRes -> (newRes -> stp))  
      }  

  refoldIter(coalg, Nil, lastAccum)(Nil, Vector(0))  
  
end queensSetupIter

Выводы

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

сформулировать понятия предметной области,
определиться со структурой ветвления (функтор F[_]),
описать шаг развёртки Coalgebra[F],
описать шаг свёртки Algebra[F],
указать граничные значения (seedB для начала развёртки и defaultC как часть алгебры),
и выбрать наиболее подходящую функцию пересвёртки с учётом конкретного F и ожидаемой глубины рекурсии.

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

С более высокого уровня абстракций проблемы выглядят мельче))

Установка macOS. Часть 1

Thu, 30 Apr 2026 12:00:41 +0000

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

В этой статье я разберу все основные методы: от самого быстрого («Стереть контент и настройки») до самого радикального (Restore через второй Mac с DFU-кабелем).

Проверка системных требований

Прежде чем что-то делать, убедитесь, что ваш Mac поддерживает нужную версию macOS.

macOS 26 (Tahoe) — актуальная версия на момент написания статьи. Она поддерживает:

Все Mac на Apple Silicon (M1 и новее).
Ограниченный круг Intel-машин — только с чипом T2. Это последняя версия macOS с поддержкой Intel.

Что проверить перед установкой:

Модель Mac: меню Apple → Об этом Mac (About This Mac)
Свободное место на диске: минимум 20–25 ГБ
Стабильное интернет-соединение

Полный список совместимых моделей: everymac.com

Как работает «Стереть контент и настройки» и почему этого может быть не достаточно?

Это самый быстрый способ вернуть Mac в исходное состояние без переустановки системы. Функция удаляет всех пользователей, их данные и установленные приложения, оставляя нетронутой саму macOS. После этого Mac встречает следующего владельца экраном «Ассистента настройки», как будто только что распакован из коробки. Подробнее в статье из документации Аpple.

Рис.1 - Настройки macOS, расположение функции "Стереть контент и настройки".

Рис.2 - Запуск функции "Стереть контент и настройки".

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

Проблемы с Secure Token. Secure Token — это атрибут учётной записи, необходимый для работы FileVault и ряда других механизмов безопасности. Если единственный пользователь с активным токеном был удалён, Mac может оказаться в нерабочем состоянии: система не разблокируется, а восстановить работоспособность без переустановки macOS практически невозможно.

Проблемы с Secure Enclave. Ошибки при входе, сбои при активации, невозможность авторизоваться — всё это может указывать на повреждение данных на уровне Secure Enclave. Здесь поможет только полная переустановка, а в тяжёлых случаях — Restore через второй Mac.

Сбой в процессе стирания. Любые сбои приводящие к “окирпичиванию” устройства, например, отключение питания в процессе стирания, обновления и тд.

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

Далее перейдем к описанию способов установки macOS.

Загрузочная флешка

Когда использовать: нет стабильного интернета, нужна конкретная версия macOS, массовая установка на несколько машин.

Все администраторы знакомы с созданием загрузочных флешек для Windows или Linux — для Mac процесс устроен аналогично. Подробное руководство можно найти в документации Apple.

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

Рис.3 Создание загружаемого установщика для macOS Ventura в приложении «Терминал».

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

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

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

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

Переустановка через Recovery

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

Это cамый простой способ для большинства ситуаций. Официальная документация.

Как войти в Recovery

На Apple Silicon: зажмите кнопку питания, дождитесь меню загрузки и выберите Options.

Из Recovery (Рис.4) можно:

Переустановить macOS.
Стереть диск через Disk Utility.
Восстановить из Time Machine.
Запустить Terminal для диагностики.

Рис.4 - Окно Recovery.

Важный нюанс: по умолчанию Recovery устанавливает macOS поверх существующей, не удаляя данные пользователей. Если нужна чистая установка, то сначала вручную сотрите диск через Disk Utility и только потом запускайте установку.

Internet Recovery

Когда локальный Recovery поврежден или недоступен. В этом случае Mac загружает минимальную Recovery-среду прямо с серверов Apple.

Посмотреть, как это выглядело на Intel Mac можно в этой статье.

На Apple Silicon Internet Recovery интегрирован в стандартный механизм — при недоступности локального Recovery система автоматически обращается к серверам Apple.

Особенности: загрузка может занять значительное время в зависимости от скорости соединения.

Fallback Recovery (только Apple Silicon)

На Apple Silicon есть дополнительный уровень защиты — Fallback Recovery. Это резервная Recovery-система, которая хранится отдельно от основного раздела Recovery (Рис.5).

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

Рис.5 - схема структуры загрузочного диска в macOS 15 (на Apple Silicon)

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

Единственное, хочется отметить, что начиная с установщиков macOS Big Sur 11.6.1 и Monterey, при обновлении основной Recovery система может копировать содержимое старой версии Recovery в Fallback Recovery. Это решение заранее заложено в обновлениях и не настраивается пользователем.

Это означает, что новый Mac на Apple Silicon может вообще не иметь Fallback Recovery до первого обновления macOS. Apple практически не документирует это поведение.

Revive и Restore через второй Mac

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

В редких случаях компьютер Mac с чипом Apple или Apple T2 Security Chip может столкнуться с проблемой, для устранения которой требуется регенерация либо восстановление прошивки с помощью другого компьютера Mac.

Такие проблемы могут возникнуть при определенных редких обстоятельствах (например, если установка операционной системы macOS прерывается вследствие сбоя питания):

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

При использовании такого способа важно знать:

Во-первых, есть различия между Revive и Restore.

	Revive	Restore
Что делает	Обновляет firmware и recoveryOS	Полный сброс firmware + recovery + macOS
Данные	Сохраняются	Стираются полностью

Во-вторых, обратите внимание на требования, что вам необходимо:

Компьютер Mac, с которым возникла проблема (Mac с чипом Apple или Mac с чипом Apple T2 Security Chip) и для которого необходимо выполнить регенерацию или восстановление прошивки. Другие модели Mac не подходят.
Другой компьютер Mac любой модели с macOS Sonoma 14 или более поздней версии. Вы будете использовать этот Mac для регенерации или восстановления компьютера Mac, на котором возникла проблема. Определение версии macOS, установленной на компьютере Mac.
Кабель USB-C/USB-C, поддерживающий как передачу данных, так и зарядку. Например, зарядный кабель Apple USB-C, который поставляется с некоторыми продуктами Apple. Он совместим с портами на компьютере Mac, поддерживающими разъем USB-C. Не используйте кабель Thunderbolt 3.

Обратите внимание, что порт DFU у каждого устройства свой. Если использовать не тот порт, восстановление запустить не получится. Пример для MacBook Pro (Рис.7):

Рис.7 - MacBook Pro, вид слева, порт DFU.

Подробная процедура восстановления Mac одним из перечисленных выше способов приведена в документации Apple. После подготовки проблемного Mac и его подключения к основному устройству откроется окно режима DFU (рис.8).

Рис.8 - Окно Finder: DFU.

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

Apple Configurator 2 и CLI

Apple Configurator 2 (AC2) — основной инструмент для Revive/Restore (рис.9), но у него есть и консольный вариант: cfgutil. Он позволяет автоматизировать операции в рамках скриптов или MDM-пайплайнов.

Рис.9 - Apple Configurator 2.

Через AC2 также можно прошивать конкретный IPSW-файл. Это нужно, если требуется откатиться на определённую версию или поставить бета-прошивку. Подробнее про IPSW ниже.

IPSW-прошивки

IPSW — это образы полной прошивки для устройств на базе Apple Silicon (по аналогии с тем, что давно используется для iPhone и iPad). При выполнении восстановления через AC2 на устройство устанавливается именно IPSW. Кроме того, при создании виртуальной машины, например, в UTM, также потребуется загрузить IPSW-прошивку.

База актуальных IPSW для всех моделей Apple Silicon: mrmacintosh.com

Когда это нужно:

Нужная вам версия macOS уже не предлагается через стандартные каналы.
Нужно воспроизвести конкретную конфигурацию, например, для тестирования или корпоративного деплоя).
Restore через AC2 не находит нужную версию автоматически.

Инструменты для массового деплоя

Если вы занимаетесь развёртыванием macOS на парке устройств, обратите внимание на MDS (Mac Deploy Stick). Это инструмент, который до версии 4 распространялся бесплатно, а начиная с версии 5 стал платным. Он позволяет создавать загрузочные флешки с автоматизированной установкой macOS и предварительной настройкой конфигурации, что упрощает работу (рис.10).

Рис.10 - Окно MDS

Заключение

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

Но это далеко не все, что можно рассказать о процессе установки macOS, продолжение следует во второй части статьи. До встречи!

Мемристор для Венеры: как ученые из США сделали память, которая не боится 700 °C

Thu, 30 Apr 2026 12:00:28 +0000

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

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

Жара как старый враг электроники

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

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

Именно поэтому большинство кремниевых чипов эффективны примерно до 125–150 °C, а уже после 200 °C начинают выходить из строя. Это не случайное ограничение и не недоработка инженеров, а следствие самой физики материалов, на которой построена вся индустрия. Мы научились компенсировать это охлаждением, защитой, резервированием, но по сути просто обошли проблему, а не решили ее. Однако решение есть, и скрыто оно в мемристоре.

Мемистор, мемристор и старая мечта об умной памяти

В начале 1960-х Бернард Уидроу занимался вещами, которые сегодня мы бы назвали ранним машинным обучением, хотя тогда это выглядело скорее как инженерный эксперимент на стыке электроники и психологии. Его система ADALINE пыталась имитировать работу нейрона через изменение весов, и для этого требовался элемент, который мог бы не просто проводить ток, а менять свое состояние в зависимости от того, что через него уже прошло.

Так появился мемистор (да, именно так) — трехполюсное устройство с изменяемым сопротивлением, которое, по сути, «помнило» свою историю. Это была вполне прикладная штука, на которой работали реальные нейросетевые схемы вроде MADALINE.

Cоветский мемистор СЗР-2

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

Долгое время эта идея оставалась теоретической. И только в конце 2000-х, когда HP Labs объявила о физической реализации мемристора на оксиде титана, тема снова всплыла на поверхность. Тогда ее подхватили с большим энтузиазмом, местами даже с избыточным, как это обычно бывает с технологиями, которым сразу пытаются назначить роль «убийцы всего существующего». Однако мемристоры не заменили транзисторы, не перевернули индустрию и не стали основой для ИИ (тогда).

Сейчас исследователи опять вернулись к теории мемристоров, но уже с вопросом не о том, как «научить» устройство, а о том, как вообще считать достаточно быстро и энергоэффективно и… желательно с жаропрочностью.

Крошечный чип памяти для экстремальных температур

В новом исследовании, опубликованном в журнале Science, ученые под руководством Джошуа Янга, профессора кафедры электротехники и вычислительной техники, сообщили о разработке нового типа электронного запоминающего устройства Gra/HfOx/W. Новый мемристор стабильно работал при температуре 700 °C — это намного выше всех предыдущих показателей в этой области.

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

Как случайная неудача стала физическим принципом

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

Рассчитанная энергия адсорбции одиночного адатома и димера вольфрама, а также коэффициент диффузии вольфрама на поверхностях Pt(111) и Gra

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

Устройство нового мемристора

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

Устройство Gra/HfOx/W и изображение поперечного среза. (a) Оптическое изображение одного устройства размером ~1 мкм × 1 мкм. (b) Изображение поперечного среза, полученное с помощью просвечивающей электронной микроскопии, и спектроскопия электрохимического рассеяния для элементов W, Hf и C

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

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

(а) Схематическое изображение устройства Gra/HfOx/W. (b) Кривые переключения постоянного тока I-V устройств Gra/HfOx/W, измеренные на месте при различных температурах

Разработка принципиально отличается от традиционной кремниевой электроники. Даже специализированные решения (HTC, high-temperature silicon) обычно стабильно работают лишь в диапазоне примерно 225–300 °C и в редких случаях — до ~350 °C, тогда как большинство стандартных микросхем теряет работоспособность уже при 200 °C.

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

Оптическое изображение крестообразной матрицы 32×32 (1K) на основе устройств Gra/HfOx/W с двухпроводной конфигурацией

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

Исследование механизма с помощью просвечивающей электронной микроскопии высокого разрешения, энергодисперсионной рентгеновской спектроскопии и рентгеновской спектроскопии с энергодисперсионной рентгеновской спектроскопией. Результаты испытаний на отжиг контрольных устройств Pt/HfOx/W

При чем тут ИИ

Хорошо, память выдерживает 700 °C, атомы ведут себя прилично, графен никого не пускает куда не надо. Но при чем здесь искусственный интеллект, кроме того, что его сейчас принято упоминать в любом контексте?

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

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

Этот мемристор с чУдным названием Gra/HfOx/W хранит состояние в виде сопротивления, и это же состояние участвует в вычислении. Получается, входной сигнал задается напряжением, вес — проводимостью, а результат выходит в виде тока, который течет через элемент. То, что в цифровой системе разбивается на последовательность операций, здесь происходит как единый физический процесс.

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

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

Где может пригодиться такая память

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

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

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

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

Есть и менее драматичный, но не менее важный уровень применения. Автомобильная электроника, например, регулярно сталкивается с температурами около 100–125 °C, и там вопрос надежности уже давно стоит остро. Устройство, рассчитанное на 700 °C, в таких условиях будет работать с огромным запасом прочности.

Жестокий, несправедливый мир

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

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

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

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

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

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

Как не тратить ресурсы впустую: четыре шага перед разработкой любой фичи

aareboot — Thu, 30 Apr 2026 12:00:27 +0000

Как сделать так, чтобы продукт или фича работала для пользователя? Ответ в этой статье.

Привет, на связи Саша Солдатов, CEO REB8T! Сегодня расскажу про четыре инструмента, которые наша команда использует в работе на каждом проекте: JTBD, ICE-приоритизацию, User Flow и UX-гипотезы.

Огромное спасибо нашему Lead UX/UI Вере Ксенофонтовой, которая собрала этот материал и разложила всё по полочкам для вас и нашей команды!

А теперь, начнём!

1. Jobs To Be Done: думаем о пользователе

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

Когда заказчик приходит с ТЗ «добавьте личный кабинет», первое желание — открыть Figma и рисовать. Но в такие моменты надо себя останавливать и задавать вопросы:

Зачем пользователю личный кабинет? Что он хочет сделать? Что его не устраивает?

Ответы могут быть разными:

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

Всё это — разные работы, и под каждую нужно своё решение.

Два ключевых инструмента внутри JTBD

Job Story — формулируем решение через ситуацию. Это задача в конкретном контексте. Например:

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

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

Как приоритизировать работы пользователя

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

— Насколько задача важна для пользователя (1–10 баллов)
— Насколько он доволен тем, как сейчас решает её (1–10 баллов)

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

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

«Хочу получить конкретные инструменты для работы» — важность 10, довольство 2

«Знать бэкграунд спикера, чтобы понять, насколько он научит» — важность 9, довольство 5

«Быстро понять, есть ли нужный курс» — важность 7, довольство 3.

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

2. ICE-приоритизация: берём в работу то, что даст максимум

Когда фичей много, а ресурсы ограничены, нужен способ выбрать, с чего начать. ICE (Impact, Confidence, Ease) — фреймворк для приоритизации. Каждую фичу оцениваем по трём критериям от 1 до 10, а итоговый балл считается как их произведение.

Impact (влияние) — влияение фичи на ключевые метрики. LTV (суммарный доход от одного пользователя), Long-Term Retention (процент пользователей, которые остаются через N месяцев), Time to Value (время до первой полученной пользы).
Confidence (уверенность) — шанс, что фича сработает. Основывается на результатах интервью и опросов, наличии похожих решений у конкурентов, сильных пользовательских сигналах.
Ease (простота) — время и ресурсы на реализацию MVP-версии фичи.

Два корректирующих коэффициента

Помимо базовой формулы, добавляем два множителя, которые делают оценку точнее.

Операционный коэффициент (0.1–1.0) — снижаем приоритет, если фича требует постоянной поддержки, модерации или производства тяжёлого контента. Например, UGC с ручной модерацией получает коэффициент 0.8.
Ad hoc корректировка (0.1–2.0) — дополнительный множитель от команды или клиента. Если фича стратегически важна или уже есть договорённости с партнёрами — поднимаем выше 1.0. Если откладываем на потом — снижаем.

Итоговая формула: ICE Score × Операционный коэффициент × Ad hoc = FINAL Score

Пример из нашего проекта Mum's Club

Mum's Club — приложение для молодых родителей. Нам нужно было выбрать, что добавить в него в первую очередь. Думали между двумя вариантами:

Статьи от экспертов. Impact 9, Confidence 10, Ease 7. ICE = 630. Коэффициенты: 1.0 × 1.5. Итог: 945. Контент уже частично готов, эксперты проверены, клиент считает это ключевой частью бренда — поднимаем в приоритете.
UGC-контент. Impact 6, Confidence 7, Ease 8. ICE = 336. Коэффициенты: 0.8 × 0.1. Итог: 26.88. Идея интересная, но требует постоянной модерации, а клиент не готов запускать UGC в MVP — откладываем.

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

3. User Flow: карта пути пользователя от А до Б

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

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

Из чего состоит User Flow

Момент первого контакта, будь то открытие приложение, переход по ссылке, нажатие на баннер. Дальше идут шаги — конкретные действия по пути к цели. В моментах выбора появляются развилки: пользователь принимает решение, и Flow разветвляется — например, авторизован он или нет, выбрал доставку или самовывоз. Финал — точка, в которой цель достигнута и человек получил то, за чем пришёл. Также указываем возможные ошибки и корнер-кейсы.

Как это работает на практике

Рассмотрим на примере нашего проекта «Самолёт Сити», геймификация онбординга сотрудников. Клиент обозначил 7 главных задач пользователя: последовательное прохождение материалов, возможность повторного просмотра, рейтинг, ачивки, техподдержка и мини-игры.

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

Пример User Flow для «Самолёт Сити»

Четыре признака хорошего User Flow:

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

Как построить User Flow

4. UX-гипотеза: формулируем предположение так, чтобы его можно было проверить

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

UX-гипотеза — это формализованное предположение о том, как конкретное изменение в интерфейсе повлияет на наблюдаемое поведение пользователя в контексте.

Формула UX-гипотезы

Как выглядит хорошая гипотеза?

Хорошая UX-гипотеза должна отвечать «да» на два вопроса.

Понятно ли, что именно меняется и в какой ситуации?
Понятно ли, как мы это заметим и на основе чего примем решение?

Если хотя бы на один ответ «не очень» — гипотеза сырая.

Пример

Если заменить свободное поле выбора доставки на список с предустановленными вариантами, пользователи, оформляющие заказ впервые, будут реже останавливаться на этом шаге дольше 5 секунд и перестанут возвращаться назад

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

Виды гипотез:

Поведенческая — если мы изменим переменную X в сценарии Y, то пользователи сегмента Z начнут или перестанут делать А, что можно зафиксировать через B. Например: если заменить свободное поле выбора доставки на список с предустановленными вариантами, пользователи, оформляющие заказ впервые, будут реже останавливаться на этом шаге более чем 5 секунд и перестанут возвращаться назад.

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

Про приоритеты внимания — что пользователь замечает первым и что игнорирует. Например: если основной CTA визуально отделить от вторичных действий, пользователи станут реже выбирать второстепенные сценарии.

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

Через гипотезы мы принимаем более взвешенные решения и минимизируем влияние собственных когнитивных искажений.

Чек-лист перед запуском фичи

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

Чек-лист 4 элементов перед запуском продукта

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

Всем добра!

Новый GPU в противовес NVIDIA? Bolt Graphics Zeus

Thu, 30 Apr 2026 12:00:04 +0000

22 апреля 2026 года Bolt Graphics объявила об успешном финальном этапе проектирования тестового чипа Zeus на производственных мощностях TSMC. Напомню, это стартап из Калифорнии, основанный в 2020 году. Создатель компании до текущей деятельности занимался проектированием дата-центров и облачной инфраструктуры, но впоследствии переключился на создание GPU для рендеринга.

Что это, значимая новость для индустрии или очередной «прожект»? Новые GPU, имена и конкуренция мэтрам — это всегда хорошо для конечного клиента и двигает рынок вперед. Рассмотрим стадию создания продукта, его технические характеристики и место под солнцем в новостной статье.

Что означает tape-out

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

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

Однако это означает, что компания-разработчик железа уже потратила реальные деньги на производство. Tape-out на TSMC 12nm может стоить несколько миллионов долларов. Можно сказать, что это переход из категории «анонс» в категорию «проект». В случае Bolt Graphics — именно поэтому текущая апрельская новость интереснее всех предыдущих их заявлений. Для них это конкретный технический шаг вперед, но до массового производства еще далеко: компания ориентируется на Q4 2027.

Технические характеристики

Zeus — это несколько моделей, ориентированных на разные сегменты рынка.

	Bolt Zeus 1c26-032	Bolt Zeus 2c26-064	Bolt Zeus 2x26-128	Bolt Zeus 4c26-256
Форм-фактор	Однослотовая PCIe	Двухслотовая PCIe	Двухслотовая PCIe	Двухслотовая PCIe
Мощность	120 Вт	250 Вт	250 Вт	500 Вт
FP64/FP32/FP16 TFLOPS	5/10/20	10/20/40	10/20/40	20/40/80
INT16/INT8 TFLOPS	307,2 / 614,4	614,4 / 1 228,8	614,4 / 1 228,8	1 228,8 / 2 457,6
Кеш	128 МБ	256 МБ	256 МБ	512 МБ
Память	32 ГБ LPDDR5X	64 ГБ LPDDR5X	128 ГБ LPDDR5X	256 ГБ LPDDR5X
Расширение памяти	до 160 ГБ, два слота DDR5 SO-DIMM	до 320 ГБ, четыре слота DDR5 SO-DIMM	до 384 ГБ, четыре слота DDR5 SO-DIMM	до 2304 ГБ, восемь слотов DDR5 SO-DIMM
Сетевые интерфейсы	400 GbE (QSFP-DD)	400 GbE (QSFP-DD)	400 GbE (QSFP-DD)	6x 800 GbE (OSFP)

Вместо распространенной в индустрии GDDR-памяти Zeus использует LPDDR5X плюс расширяемые DDR5 SO-DIMM — это дешевле, чем GDDR7 или HBM3e. Но все еще позволяет иметь большой объем до 384 ГБ. Однако пропускная способность памяти оценивается не более 300 ГБ/сек. Тогда как в GDDR7 это показатель в несколько раз выше.

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

Еще одна нетривиальная особенность: заявлены встроенные интерфейсы 400GbE и 800GbE для прямого соединения GPU без InfiniBand. Это потенциально интересно для кластеров рендер-ферм и HPC, где стоимость сетевой инфраструктуры — существенная статья расходов.

Что касается техпроцесса: тестовый чип изготовлен на 12nm FFC TSMC. Компания упоминает, что архитектура масштабируется на 5nm, но продакшен-версия пока привязана к 12nm. Для справки: RTX 4090 выпускалась на N5P (4nm class), RTX 5090 — на N4P. Это означает, что тактовые частоты и плотность транзисторов у Zeus будут скромнее.

Конкуренты

Bolt Graphics сравнивает Zeus в основном с RTX 5090. В позиционировании NVIDIA это консьюмерская карта, а не профессиональные ускорители вроде H200 или MI350X.

По заявлениям компании

Zeus 1c26 (120 Вт) vs RTX 5090 (575 Вт) — примерно в 2,5 раза быстрее в трассировке путей;
Zeus 2c26 (250 Вт) vs RTX 5090 — в 5 раз быстрее в трассировке путей;
Zeus 4c vs RTX 5090 — до 10–13 раз быстрее в трассировке, в 6 раз в HPC-задачах, и совершенно фантастические 300x в симуляциях ЭМ-волн.

Все эти цифры получены из «pre-silicon benchmarks in emulation» — то есть из симуляций на FPGA, а не с реального кремния. Это важная оговорка.

Арендуйте GPU за 1 рубль!

Выберите нужную конфигурацию в панели управления Selectel. *

Подробнее →

«А что с инференсом?»

Самая интересная и одновременно самая проблемная часть истории Zeus обнаруживается в инференсе.

Инференс LLM — сегодня крупнейший и наиболее платежеспособный сегмент спроса на ускорители. «Тяжелый люкс» и уже стандарт индустрии здесь — это NVIDIA B300, NVIDIA H200 или хотя бы NVIDIA RTX PRO 6000 Blackwell

Zeus в этом контексте выглядит неоднозначно. С одной стороны, возможность иметь 128 ГБ LPDDR5X на двухчиплетной или 256 ГБ LPDDR5X на четырехчиплетной карте — это потенциально интересно для инференса с большими моделей даже без квантизации. С другой стороны, LPDDR5X дает принципиально меньшую пропускную способность, чем HBM и даже GDDR7. А этот параметр принципиальный для инференса.

Еще одна проблема для инференса — это не железо, а программный стек. PyTorch, vLLM, TensorRT-LLM, FlashAttention — не пустые слова, весь современный инференс-стек заточен под CUDA или хотя бы ROCm. Bolt Graphics предлагает собственный рендерер Glowstick и API на базе RISC-V, но ни слова про поддержку стандартных ML-фреймворков в публичных материалах нет. Без этого Zeus для инференса слабоприменим вне зависимости от характеристик железа.

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

Состоится ли Zeus

В 2023 году на CES Bolt Graphics анонсировала первые продукты: мобильный GPU Lightning и десктопные GPU Thunder. Компания заявляла о высокой производительности и сравнивала устройства с NVIDIA RTX 4090.

На CES 2024 Thunder был анонсирован повторно — уже «latest edition» (самая новая версия). Компания также обещала прототипные чипы на 5nm с поставками в конце 2024 года.

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

Итак, сейчас анонсирован tape-out тестового чипа на 12nm. Это уже конкретный результат, которого у предыдущих продуктов не было публично. Девкиты планируются на конец 2026 года, массовое производство — на 2027 год.

Tape-out на TSMC — это не просто пресс-релиз, ведь потрачены реальные деньги. Значит, инвесторы продолжают вкладываться. Архитектурная ставка на специализированные блоки трассировки лучей теоретически обоснована — NVIDIA сама отчасти движется в эту сторону. Зарубежный рынок рендер-ферм, VFX-студий и HPC действительно платит много и реально ограничен в доступе к compute, в частности — на фоне конкуренции с задачами инференса.

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

Отдельная проблема — программный стек. NVIDIA потратила 15 лет на построение CUDA-экосистемы, AMD тратит годы на ROCm и все еще догоняет. У Bolt Graphics менее ста сотрудников, собственный рендерер (не путать с «рендер») Glowstick и API на базе RISC-V. Для нишевого применения в рендеринге этого может хватить, для HPC — уже сомнительно, для инференса — утопия.

И конкуренты, мягко говоря, не стоят на месте и вообще не собираются останавливаться. К 2027 Nvidia будет как минимум с GPU Rubin, максимум — выпустит следующее поколение. AMD перевалит в индексах GPU MI за цифру 400. Рынок, в который Zeus хочет войти, к тому моменту будет другим.

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

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

Однако мы продолжаем следить за новинками рынка в надежде, что когда-нибудь у NVIDIA и AMD появится достойный конкурент, а Selectel напишет, что знали про них еще на заре появления первых устройств.

[Перевод] Стратегия резервного копирования 3-2-1: технический разбор

Thu, 30 Apr 2026 11:48:49 +0000

Целостность данных — краеугольный камень современной корпоративной инфраструктуры. Базовых сценариев резервного копирования может хватать дома, но в корпоративной среде нужна жёсткая, отказоустойчивая методология. Стратегия 3-2-1 по-прежнему остаётся индустриальным стандартом, обеспечивая устойчивость данных к повреждениям, аппаратным сбоям и атакам шифровальщиков. Эта статья разбирает техническую реализацию правила 3-2-1 — в первую очередь для системных администраторов и архитекторов, проектирующих решения с высокой доступностью.

Разбираем правило 3-2-1 по частям

В своей основе 3-2-1 — это протокол избыточности, спроектированный так, чтобы устранить единые точки отказа (SPOF) в системе хранения.

Три копии данных

Правило требует поддерживать как минимум три копии любого набора данных: продакшн-данные плюс две независимые резервные копии. Статистически такая избыточность серьёзно снижает вероятность одновременной потери. Если вероятность отказа одного диска равна 1/100, то вероятность одновременного отказа трёх независимых дисков падает до 1/1 000 000 — при условии, что отказы не коррелируют между собой.

Прим. перев. Оговорка про «независимые» отказы здесь принципиальная. На практике диски из одной партии с одной прошивкой, лежащие в одной полке, в одной стойке, в одном ЦОД — это не три независимых события. Поэтому 1/1 000 000 — это идеализированная нижняя граница, а не цифра, которую вы реально получите в продакшене. Ровно поэтому пункты про «разные носители» и «другая локация» в правиле не менее важны, чем сам факт трёх копий.

Два разных типа носителей

Две из копий должны лежать на разных типах носителей. Это требование снижает риск проблем, специфичных для конкретного носителя — например, багов прошивки в конкретной партии HDD или деградации оптических носителей. Использование разнородных технологий хранения — скажем, связки массивов на «крутящихся» дисках (HDD) с SSD или магнитной лентой — отвязывает резервные копии от уязвимостей конкретной технологии.

Одна копия за пределами площадки

Последняя копия должна находиться географически отдельно от продакшн-среды. Это защищает от катастроф уровня площадки: пожара, потопа или физической кражи. В современных архитектурах под «offsite» чаще всего понимают неизменяемое (immutable) облачное хранилище или физически отдельный ЦОД, подключённый по WAN.

Стратегии реализации в продвинутых архитектурах

Для энтерпрайз-уровня простого копирования файлов мало. Продвинутая реализация 3-2-1 требует автоматизации, верификации и интеграции с системами безопасности.

Оркестрация трёх копий

Серьёзные реализации опираются на технологии снапшотов и репликации, а не на банальное копирование файлов.

Продакшн-данные. Лежат на высокопроизводительных массивах SAN/NAS.
Первичный бэкап. Частые инкрементальные снапшоты, хранящиеся на отдельной локальной системе. Это даёт низкое время восстановления (RTO) для повседневных задач восстановления.
Вторичный бэкап. Асинхронная репликация наборов резервных копий в третью локацию.

Разнообразие носителей в эпоху Software-Defined

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

Disk-to-Disk-to-Tape (D2D2T). Некоторые считают это легаси, но LTO-лента остаётся жизнеспособным носителем для архивного хранения с воздушным зазором (air-gapped). Высокая плотность записи плюс защита от горизонтального распространения шифровальщиков — не самые плохие свойства.
Disk-to-Disk-to-Cloud (D2D2C). Использование объектного хранилища (S3-совместимого) в качестве второго носителя. Чтобы получить честное различие носителей, локальный репозиторий может работать с блочным хранилищем, а облачный — с объектным.

Защита offsite-копии

Offsite-компонент — ключевая линия обороны против шифровальщиков.

Неизменяемость (Immutability). Настройка политик Object Lock (WORM — Write Once Read Many) для облачных репозиториев. Это блокирует любому пользователю, включая администраторов, возможность удалить или изменить блоки бэкапа до истечения срока хранения.
Воздушный зазор (Air-Gapping). Для повышенной безопасности применяется логический или физический air gap, при котором сеть управления резервным устройством не имеет постоянного подключения к продакшн-сети или интернету.

От Cloud4Y. Если задумываетесь, где разместить ту самую «третью копию за периметром», у нас сейчас как раз идёт акция для читателей Хабра: новым клиентам — скидка 20% на аренду облачных серверов для бизнеса по промокоду HABR20. Серверы размещаются в ЦОД уровня TIER III, SLA — 99,982%, можно взять готовую конфигурацию или собрать машину под задачу. Условия — на странице акции, перейдите по ссылке. На арендованном сервере (или связке из нескольких) удобно поднять свой бэкап-таргет под Veeam, Commvault, Acronis или любой другой привычный инструмент — и спокойно проверить схему 3-2-1 на реальных данных, прежде чем закладывать её в основную архитектуру.

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

Плюсы и минусы модели 3-2-1

Модель надёжна, но в корпоративной среде у неё есть свои компромиссы.

Плюсы:

Устойчивость. Максимизирует выживаемость данных при разных доменах отказа.
Универсальность. Не привязана к конкретным вендорам железа или ПО для бэкапа.
Соответствие требованиям. Закрывает требования к восстановлению после аварий в большинстве регуляторных рамок (GDPR, HIPAA, SOC 2).

Минусы:

Стоимость. Содержание избыточного железа и плата за исходящий трафик из облака увеличивают совокупную стоимость владения (TCO).
Сложность. Синхронизация по разнородным носителям и локациям требует серьёзных инструментов оркестрации.
Задержки. Восстановление больших наборов данных из удалённого «холодного» хранилища может ухудшать RTO по сравнению с локальным восстановлением.

Инженерия отказоустойчивости

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

Прим. перев. Канонические 3-2-1 за последние годы расширили до 3-2-1-1-0 (одна неизменяемая копия + ноль ошибок при восстановлении — версия Veeam) и 4-3-2 — именно потому, что классические три копии всё хуже справляются с современными атаками, где злоумышленник целенаправленно идёт за бэкапами. Различия между этими схемами заслуживают отдельного материала — постараемся его сделать.

Как я завалил кучу собесов по Go и что из этого вынес

Zmey56 — Thu, 30 Apr 2026 11:48:47 +0000

Привет! Меня зовут Александр. Некоторые могут помнить мои статьи про финансовую аналитику на Python - анализ ETF, оптимизацию портфелей. Но последние 6 лет я Senior Go Backend Engineer, специализируюсь на финтехе и трейдинге.

Эта комбинация - domain expertise в финансах + техническая экспертиза в Go - оказалась очень ценной. Но путь был тернистым.

Последние полгода активно собеседовался: 8 интервью в разных компаниях - от крупных российских IT-гигантов до международных финтех стартапов. Где-то взяли, где-то нет. Решил поделиться самыми дурацкими ошибками, которые делал я и другие кандидаты. Может, кому поможет не наступить на те же грабли.

Немного предыстории

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

Но обо всем по порядку. Вот топ-10 косяков, которые я либо сам делал, либо видел у других кандидатов.

1. “Что выведет этот код?” - и тут началось…

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

Дают мне код:

func main() {
    s := make([]int, 0, 5)
    s = append(s, 1, 2, 3)
    
    a := append(s, 4)
    b := append(s, 5)
    
    fmt.Println(a) 
    fmt.Println(b) 
}

Я, умный такой, отвечаю: “Ну понятно же - a будет [1,2,3,4], а b будет [1,2,3,5]”.

Интервьюер так грустно на меня посмотрел… Оказывается, оба слайса будут [1,2,3,5]!

Почему? Да потому что underlying array у них общий, capacity хватает, и когда мы делаем append(s, 5), это затирает четверку в том же массиве.

Я тогда честно признался: “Не, ну это я не знал”. Интервьюер говорит: “А как же вы баги в проде ловите?” А я думаю: “Ну… методом тыка?” Конечно, вслух не сказал, но по лицу было видно.

Мораль: Надо знать, как слайсы устроены под капотом. Не просто “это динамический массив”, а реально понимать про capacity и underlying array.

2. Race conditions - “Да что тут такого сложного?”

Это вообще отдельная песня. В одной криптоплатежной компании (европейская, миллиарды в обороте) дали задачку написать простенький счетчик:

type Counter struct {
    value int
}

func (c *Counter) Increment() {
    c.value++ // Чего тут сложного-то?
}

Я говорю: “Ну все, готово”. А интервьюер: “А что будет, если много горутин будут это вызывать?”

И тут я понял, что проштрафился. c.value++ - это не одна операция, а три: прочитать, увеличить, записать. А между ними другая горутина может влезть.

Правильно было бы так:

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
}

Или еще проще - через atomic:

type Counter struct {
    value int64
}

func (c *Counter) Increment() {
    atomic.AddInt64(&c.value, 1)
}

Фишка в том, что надо понимать КОГДА что использовать. Для простого счетчика - atomic. Для сложной логики - mutex. Для передачи данных между горутинами - channels.

Кстати, один интервьюер мне формулу дал: “atomic → RWMutex → Mutex → channel”. По возрастанию сложности и накладных расходов.

3. PostgreSQL и деньги - тут шутки плохи

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

Я, наивный, пишу:

func TransferMoney(from, to int, amount decimal.Decimal) error {
    tx, err := db.Begin()
    // ... проверки ошибок
    
    var balance decimal.Decimal
    err = tx.QueryRow("SELECT balance FROM accounts WHERE id = ?", from).Scan(&balance)
    
    if balance.LessThan(amount) {
        return errors.New("денег нет, но вы держитесь")
    }
    
    // Списываем
    tx.Exec("UPDATE accounts SET balance = balance - ? WHERE id = ?", amount, from)
    // Зачисляем
    tx.Exec("UPDATE accounts SET balance = balance + ? WHERE id = ?", amount, to)
    
    return tx.Commit()
}

Интервьюер спрашивает: “А что будет, если две транзакции одновременно переводят деньги с одного счета?”

Я думаю: “Ну, транзакция же, изоляция…” А он говорит: “А между SELECT и UPDATE другая транзакция может успеть?”

И правда может! Классический Lost Update. Надо было блокировать строку:

err = tx.QueryRow("SELECT balance FROM accounts WHERE id = ? FOR UPDATE", from).Scan(&balance)

Этот FOR UPDATE блокирует строку до конца транзакции.

Урок: В финтехе шутки плохи. Не знаешь SELECT FOR UPDATE - не работай с деньгами.

4. Context - “А зачем он мне?”

Помню собес в одной большой российской IT-компании. Дают задачку написать функцию, которая ходит в API. Я пишу:

func GetUser(userID int) (*User, error) {
    resp, err := http.Get(fmt.Sprintf("http://api/users/%d", userID))
    // дальше парсинг...
}

“А context где?” - спрашивает интервьюер.

“А зачем он тут? Это же просто GET запрос” - отвечаю я.

Оказывается, зачем:

Timeout control - а то запрос может висеть вечно
Cancellation - если пользователь ушел, зачем тратить ресурсы?
Trace propagation - для мониторинга

Правильно:

func GetUser(ctx context.Context, userID int) (*User, error) {
    req, err := http.NewRequestWithContext(ctx, "GET", 
        fmt.Sprintf("http://api/users/%d", userID), nil)
    
    client := &http.Client{Timeout: 5 * time.Second}
    resp, err := client.Do(req)
    // ...
}

Правило: Context - первый параметр в любой функции, которая может “повиснуть”.

5. Горутины и утечки памяти

Это я понял не сразу. На одном собесе дают задачу: “Обработайте массив данных параллельно”.

Я, как настоящий гений, пишу:

func ProcessData(data []string) {
    for _, item := range data {
        go func(item string) {
            result := heavyProcessing(item)
            fmt.Println(result) // И кто это будет читать?
        }(item)
    }
}

“А как вы узнаете, что все обработалось?” - спрашивает интервьюер.

“Ну… подождем?” - говорю я.

“Сколько?”

“Ну… достаточно?”

Конечно, это неправильно. Горутины запустятся и “уплывут”. В production это memory leak.

Правильно - через WaitGroup:

func ProcessData(data []string) error {
    var wg sync.WaitGroup
    errCh := make(chan error, len(data))
    
    for _, item := range data {
        wg.Add(1)
        go func(item string) {
            defer wg.Done()
            
            if err := heavyProcessing(item); err != nil {
                errCh <- err
            }
        }(item)
    }
    
    go func() {
        wg.Wait()
        close(errCh)
    }()
    
    for err := range errCh {
        if err != nil {
            return err
        }
    }
    return nil
}

Фишка: Всегда знай, когда твои горутины закончатся. И как ловить их ошибки.

6. interface{} - универсальное зло

Ох, сколько я на этом налетел! Думал - раз Go такой строгий с типами, то interface{} - это способ “расслабиться”.

func Process(data interface{}) interface{} {
    switch v := data.(type) {
    case string:
        return strings.ToUpper(v)
    case int:
        return v * 2
    case []interface{}:
        // тут начинается рекурсивный ад...
    default:
        return "хз что это"
    }
}

Интервьюер говорит: “А что будет, если я передам map[string]int?”

Я: “Ну… вернется ‘хз что это’”

“А вы узнаете об этом когда?”

“Ну… в runtime?”

“Вот именно. А можно узнать раньше?”

Оказывается, можно. Либо через generics (если Go 1.18+), либо просто нормальными типами:

type UserRequest struct {
    Name string `json:"name"`
}

func ProcessUser(req UserRequest) (*UserResponse, error) {
    // Тут все понятно и type-safe
}

Правило: interface{} только когда РЕАЛЬНО нужен any type. А это редко.

7. Ошибки - “Залогировал и забыл”

Еще один мой косяк. Пишу функцию:

func GetUser(id int) *User {
    user, err := db.GetUser(id)
    if err != nil {
        log.Printf("Ошибка: %v", err) // "Залогировал же!"
        return nil
    }
    return user
}

Интервьюер: “А как вызывающий код поймет, что произошло?”

Я: “Ну… nil же вернется”

“А nil может быть и потому что пользователя нет, и потому что БД упала?”

Ага, точно. Caller не поймет, что делать с nil.

Правильно:

func GetUser(id int) (*User, error) {
    user, err := db.GetUser(id)
    if err != nil {
        return nil, fmt.Errorf("не смог достать пользователя %d: %w", id, err)
    }
    return user, nil
}

Фишка в %w - он сохраняет оригинальную ошибку, и ее потом можно распаковать через errors.Unwrap().

8. ClickHouse - “Это же просто SQL”

Вот тут я реально не знал специфики. В одной финтех компании активно используют ClickHouse. Дают задачку написать запрос для аналитики:

SELECT user_id, COUNT(*) 
FROM events 
WHERE event_type = 'click' 
  AND timestamp >= '2026-01-01' 
GROUP BY user_id
ORDER BY COUNT(*) DESC

Я думаю - ну нормально же? А интервьюер морщится: “А по чему у вас ORDER BY в таблице?”

Оказывается, в ClickHouse все таблицы отсортированы по ORDER BY ключу. А если фильтруешь не по нему - будет медленно.

Правильно:

SELECT user_id, count() as clicks
FROM events 
WHERE timestamp >= '2026-01-01' 
  AND timestamp < '2026-02-01'  -- Используем партиции
  AND event_type = 'click'       -- После timestamp!
GROUP BY user_id
ORDER BY clicks DESC

Урок: Column-oriented БД - не PostgreSQL. У них свои заморочки.

9. Kafka - “Читаю и обрабатываю”

На собесе в одной high-load компании дали задачку с Kafka. Я написал что-то вроде:

for {
    msg, err := consumer.ReadMessage(-1)
    if err == nil {
        processMessage(msg.Value) // А если упадет?
    }
}

“А что будет, если processMessage упадет с паникой?” - спрашивает интервьюер.

“Ну… restart?” - говорю я.

“А offset закоммитится?”

И тут я понял, что не подумал про exactly-once delivery. Если message обработался, но offset не закоммитился - после рестарта сообщение придет снова.

Правильно - коммитить offset только после успешной обработки:

for {
    msg, err := consumer.ReadMessage(100 * time.Millisecond)
    if err != nil {
        continue
    }
    
    if err := processMessage(msg.Value); err != nil {
        log.Printf("Не смог обработать: %v", err)
        continue // НЕ коммитим offset
    }
    
    consumer.CommitMessage(msg) // Коммитим только тут
}

Урок: В distributed systems каждая мелочь важна.

10. System Design - тут совсем грустно

Самый сложный этап. В одной крупной российской IT-компании дали спроектировать URL Shortener.

Я говорю: “Ну делаем REST API. POST /shorten принимает URL, возвращает ID. GET /:id возвращает original URL. В PostgreSQL храним mapping. Все!”

Интервьюер: “А сколько URL в день вы ожидаете?”

“Ну… много?”

“Давайте цифры”

И тут началось… Оказывается, надо считать:

100 млн URL в день = ~1200 writes/sec
Read:Write = 100:1 = 120,000 reads/sec
Хранение за 5 лет = терабайты

Один PostgreSQL не потянет. Нужен кеш (Redis), CDN для популярных ссылок, шардинг БД…

Урок: System Design - это не “какую БД выбрать”, а понимание масштаба и trade-offs.

Неожиданный бонус: финансовый бэкграунд

Кстати, мой путь analyst → Go developer оказался преимуществом!

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

“Как обеспечить exactly-once delivery для платежей?”
“Что такое идемпотентность в контексте денежных переводов?”
“Как бы вы реализовали matching engine?”

Когда я рассказываю про опыт с ETF анализом, portfolio optimization, понимание рынков - это сразу выделяет среди других кандидатов. Интервьюеры понимают, что я не просто пишу код, а понимаю зачем.

Урок: Ваш нетехнический опыт может стать конкурентным преимуществом!

Что я понял после всех этих собесов

Дело не в синтаксисе Go - дело в том, как ты мыслишь как engineer
Production опыт стоит больше, чем знание всех фишек языка
Domain knowledge может быть решающим фактором
Честность лучше чем попытка заболтать непонимание
Вопросы обратно показывают, что ты думаешь о проблеме

Что реально спрашивают:

60% - concurrency и как оно работает под капотом
30% - databases и distributed systems
10% - алгоритмы (и то не leetcode, а практические)

Что помогло получить офферы:

Рассказывать про реальные проблемы которые решал
Объяснять trade-offs - почему выбрал именно это решение
Признавать пробелы - “не знаю, но думаю так…”
Задавать вопросы - уточнять требования, обсуждать альтернативы

Что дальше: от статьи к практике

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

Запускаю Telegram канал @go_interview_prep_ru, где буду регулярно делиться:

📝 Подробными разборами задач с реальных собесов
🧠 Еженедельными Go quiz с объяснениями
💡 Инсайдами про процессы топовых компаний
🔧 Практическими советами для Senior уровня
💰 Данными по зарплатам и market trends

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

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

🎯 Для кого это будет полезно:

Middle → Senior Go разработчики
Backend engineers из других языков, переходящие на Go
Финтех разработчики (особенно ценю domain expertise!)
Career changers как я - никогда не поздно расти

Подписывайтесь: t.me/go_interview_prep_ru

Unity Builder — как мы победили боль с ручными сборками и написали своё приложение

c3n9 — Thu, 30 Apr 2026 11:26:13 +0000

Всем привет! Продолжаю свой мониторинг по упрощению работы с Unity. В прошлой статье я писал о JSON Viewer (CraftHub) — инструменте, который упрощает работу с конфигами в формате JSON.

Откуда растут ноги

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

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

Первая попытка: Jenkins на своём сервере

Мои друзья (кстати, вот @crackanddie одного из них) первыми бросились в бой и попробовали Jenkins на собственном сервере. Настроили пайплайны, всё красиво… но идея быстро споткнулась о суровую реальность:

Unity поначалу вставал с большим трудом
Лицензия оказалась настоящим квестом — получить Community-ключ так и не получилось

Пошли дальше.

Вторая попытка: GitHub Actions + game-ci

Спустя полгода я решил разобраться в вопросе сам и подключил к поискам нейросеть. Она подсказала unity-builder от game-ci — на первый взгляд идеальный вариант.

Быстро добавили все данные от аккаунта в Repository Secrets, настроили workflow — и поехали. Вот что получилось:

name: Unity Build & Release

on:
  workflow_dispatch:

permissions:
  contents: write

jobs:
  build-windows:
    name: Build Windows (x64)
    runs-on: ubuntu-latest
    steps:
      - name: Free disk space
        uses: jlumbroso/free-disk-space@main
        with:
          tool-cache: false
          android: true
          dotnet: true
          haskell: true
          large-packages: true
          swap-storage: true

      - name: Checkout
        uses: actions/checkout@v4
        with:
          lfs: true

      - name: Cache Library
        uses: actions/cache@v4
        with:
          path: Library
          key: Library-Windows-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: Library-Windows-

      - name: Build
        uses: game-ci/unity-builder@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          unityVersion: 2021.3.45f2
          targetPlatform: StandaloneWindows64
          buildName: ${{ github.event.repository.name }}
          buildsPath: build

      - name: Zip build
        run: |
          cd build/StandaloneWindows64
          zip -r ../../${{ github.event.repository.name }}-windows-x64.zip .

      - name: Upload to Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ github.ref_name }}
          files: ${{ github.event.repository.name }}-windows-x64.zip

  build-linux:
    name: Build Linux (x64)
    runs-on: ubuntu-latest
    steps:
      - name: Free disk space
        uses: jlumbroso/free-disk-space@main
        with:
          tool-cache: false
          android: true
          dotnet: true
          haskell: true
          large-packages: true
          swap-storage: true

      - name: Checkout
        uses: actions/checkout@v4
        with:
          lfs: true

      - name: Cache Library
        uses: actions/cache@v4
        with:
          path: Library
          key: Library-Linux-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: Library-Linux-

      - name: Build
        uses: game-ci/unity-builder@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          unityVersion: 2021.3.45f2
          targetPlatform: StandaloneLinux64
          buildName: ${{ github.event.repository.name }}
          buildsPath: build

      - name: Zip build
        run: |
          cd build/StandaloneLinux64
          zip -r ../../${{ github.event.repository.name }}-linux-x64.zip .

      - name: Upload to Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ github.ref_name }}
          files: ${{ github.event.repository.name }}-linux-x64.zip

  build-macos:
    name: Build macOS (arm64)
    runs-on: ubuntu-latest
    steps:
      - name: Free disk space
        uses: jlumbroso/free-disk-space@main
        with:
          tool-cache: false
          android: true
          dotnet: true
          haskell: true
          large-packages: true
          swap-storage: true

      - name: Checkout
        uses: actions/checkout@v4
        with:
          lfs: true

      - name: Cache Library
        uses: actions/cache@v4
        with:
          path: Library
          key: Library-macOS-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: Library-macOS-

      - name: Build
        uses: game-ci/unity-builder@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          unityVersion: 2021.3.45f2
          targetPlatform: StandaloneOSX
          buildName: ${{ github.event.repository.name }}
          buildsPath: build

      - name: Zip build
        run: |
          cd build/StandaloneOSX
          zip -r ../../${{ github.event.repository.name }}-macos-arm64.zip .

      - name: Upload to Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ github.ref_name }}
          files: ${{ github.event.repository.name }}-macos-arm64.zip

Казалось бы, вот оно счастье. Но дальше ждало разочарование.

Сборка нашего рабочего проекта под три платформы — Windows, Linux и macOS — заняла 40 минут.

Сорок. Минут. СОРОК. Загрузка Unity, получение лицензии через unity-builder — всё это вылилось в настоящую бесконечность. Особенно обидно, когда на локальной машине те же действия занимают от силы минуты три на каждую платформу, забавный момент.

Вы скажете: «А что насчёт self-hosted runner?» Пробовали. И тут тоже не срослось — активация Unity через сеть сам по себе небыстрый процесс. А пока мы настраивали self-hosted и исправляли баги, время ожидания каждой следующей ошибки росло в геометрической прогрессии. Сдали ли нервы? Может быть.

Третья попытка: написать своё

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

Встречайте — Unity Builder!

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

Что умеет Unity Builder

Базовая настройка

На старте вас встречает простой экран с минимально необходимым:

Путь до исполняемого файла Unity
Папка проекта
Версия Unity
Выходная директория
Название проекта

Страница конфигурации сборки

База, ничего лишнего.

Выгрузка на FTP и индексация изменений

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

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

Страница индексирования и ftp

Поддержка платформ

Официально в Community-версии Unity нет поддержки под Linux ARM64, поэтому на текущий момент доступны:

Платформа	Архитектуры
Windows	x64, x86
Linux	x64
macOS	Universal (Silicon + Intel)

Кстати, macOS — очень удобно: собирается сразу универсальный билд, совместимый и с Apple Silicon, и с Intel. Поэтому если вы выбрали выгрузку на FTP, можно указать сразу два пути — для нашего, а может и вашего удобства.

Android пока не завезли, но будем рады помощи :)

Страница выбора платформ

Пайплайн в виде нодов

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

Страница пайплайна

Несколько важных деталей о работе пайплайна:

Одновременно может выполняться только один Build — он взаимодействует с Unity напрямую
Hash Computer и выгрузка на FTP могут работать до 10 параллельных потоков — этого более чем достаточно
Под капотом это SemaphoreSlim — простое и надёжное решение

Каждый нод кликабельный: можно тыкнуть по нему и увидеть консольный вывод в реальном времени. В случае отмены главного процесса (сборки) все дочерние процессы — выгрузка и Hash Computer — убиваются автоматически.

Карточки нодов показывают:

Текущий статус
Прогресс выполнения
Время выполнения каждого нода

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

Что нужно для запуска

Всё просто: предустановите в Unity модули для нужных платформ — Windows, macOS, Linux — и сборки будут работать для всех из них без дополнительных телодвижений.

Никаких скриптов активации, никаких танцев с лицензией, никакого Docker. Скачал, указал путь до Unity и папку проекта — и через пару кликов у тебя уже крутится пайплайн. Если Unity уже стоит с нужными модулями, первый билд можно запустить буквально за пару минут после скачивания приложения. Мы специально старались сделать порог входа минимальным — чтобы не было ощущения, что ты настраиваешь CI/CD на работе, а не собираешь свой проект дома в воскресенье вечером.

Обновления

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

Вместо заключения

Мы прошли через Jenkins с его лицензионным квестом, через GitHub Actions с сорокаминутными сборками — и в итоге написали то, что хотели с самого начала.

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

Ссылка на проект: https://github.com/Soft-V/UnityBuilder
Ссылка на релизы: https://github.com/Soft-V/UnityBuilder/releases

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

Как дать AI-агенту не лом, а ключ от браузера: разбираем agent-browser от Vercel

kee_real — Thu, 30 Apr 2026 11:14:16 +0000

agent-browser против монстра-DOM-дерева

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

Обычно в таких случаях не глядя берут проверенные инструменты вроде Puppeteer или Playwright, которые обернуты в те самые три буквы MCP. Но ребята из Vercel недавно выкатили свою альтернативу — agent-browser (cli-утилиту, написанную на связке Rust и, некогда Node, но об этом позже). Зачем понадобился еще один велосипед для автоматизации, если у нас уже есть стандарты индустрии? Давайте разбираться.

1. Что не так с существующими решениями (Puppeteer, Playwright MCP и тд)

Никто не спорит, Playwright и Puppeteer — это шедевры инженерии. Они идеально подходят для того, для чего создавались: детерминированного end-to-end тестирования, CI/CD пайплайнов и предсказуемого парсинга.

Но когда мы пытаемся передать управление браузером AI-агенту через популярный сейчас Model Context Protocol (MCP), начинается боль, и заканчиваются токены. Агенту нужно "видеть" контент страницы, чтобы понимать, куда кликать. Есть два основных способа дать ему эту возможность:

Скормить сырой HTML. И моментально выжечь весь контекст на одном только DOM-дереве тяжелого SPA-приложения.
Отдать Accessibility Tree. Это стандартный подход для MCP-серверов, но полные деревья весят все равно неадекватно много.

Проблема совершенно не выдумана. Загляните в issue-трекеры популярных инструментов: например, в официальном репозитории ChromeDevTools/chrome-devtools-mcp разработчики прямо показывают в логах, как один только клик и снятие снимка сложной страницы (вроде Jupyter Notebook) выбивает в трубу от 15 000 до 200 000 токенов за шаг. Агент делает пару кликов, забывает, зачем вообще пришел на сайт и как его зовут, и с треском падает с ошибкой context length exceeded.

К тому же, LLM часто галлюцинируют в сложных CSS-селекторах. В итоге традиционные инструменты заставляют агента жрать лишние токены и постоянно промахиваться мимо кнопок.

2. Как Vercel избавились от лишнего и в своем же решении в том числе

Команда Vercel последнее время плотно занялась AI-инструментами (тот же v0, инфра для агентов и тд) и столкнулась с очевидным затыком: им нужен был способ валидации фронтенда. Когда автономный кодинговый агент пишет компонент, он должен сам открыть браузер, покликать и убедиться, что всё работает.

Изначально они слепили гибрид: Rust-клиент плюс тяжелый фоновый процесс на Node.js. В сети до сих пор можно наткнуться на статьи, где люди жалуются на скорость agent-browser в той версии, сравнивая его с другими решениями. Но, к сожалению, или к моему счастью, ко мне в руки он попал уже тогда, когда из него полностью выпилили Node-демон.

Архитектура стала максимально простой:

Единый бинарник (100% Rust): моментально парсит команды из терминала.
Прямое общение с CDP: Rust дергает Chrome DevTools Protocol напрямую, без прослоек.
Zero-dependency: вам больше не нужно тащить в Docker-контейнер всю экосистему Node.js.

Архитектура agent-browser: до и после

Главная киллер-фича — компактизация стейта. Вместо того, чтобы вываливать на агента весь DOM, agent-browser делает снимок интерактивных элементов (snapshot -i) и присваивает им короткие референсы.

Для LLM вывод выглядит так:

button "Sign In" [ref=e1]
textbox "Email" [ref=e2]

Это занимает пару сотен токенов. Агент понимает, что ему нужно нажать, и просто отправляет bash-команду: agent-browser fill @e2 "admin".

3. Сравнение подходов и внезапный ответ от Microsoft

Разница в подходах лучше всего видна на практике. Допустим, мы просим агента: "Зайди на habr.com и кликни на первую статью".

Подход классического MCP-сервера:

Агент вызывает инструмент навигации. В ответ ему прилетает простыня Accessibility Tree на 20 000 токенов. LLM продирается через эти мегабайты текста, чтобы найти заголовок, а затем пытается сгенерировать точный селектор для клика: browser_click({ "selector": "tm-articles-list__after-article h3 > a.title-link" }). Шаг влево, шаг вправо в верстке — и клик улетает в пустоту, ~~или в диалог о согласии на куки~~.

Подход agent-browser:

Агент плюет в bash одну строчку: agent-browser open https://habr.com. Затем делает agent-browser snapshot, получает плоский короткий список, где нужная ссылка помечена как [ref=e42], и отправляет agent-browser click @e42. Риск промахнуться стремится к нулю.

habr.com размеченный референсами agent-browser

А как же playwright-cli?

Самое смешное, что в Microsoft тоже осознали тупиковость классического MCP для агентов. Буквально недавно они выкатили свой ответ — @playwright/cli , специальный интерфейс именно для AI-агентов. Не путать с обычным playwright раннером.

Они пошли по тому же пути и перевели агентов на bash. Теперь агент через Playwright тоже может написать playwright-cli click e15. Инструмент сам разбирается с селекторами под капотом, а вместо того, чтобы стримить гигантские деревья в контекст LLM, сохраняет стейт на диск. Это кардинально снижает расход токенов.

Сравнивая agent-browser и playwright-cli, мы видим битву двух одинаковых философий. Отличие в деталях: playwright-cli тянет за собой всю мощь (и тяжесть) экосистемы Node/Playwright, предлагая привычный инструментарий для тех, кто уже плотно сидит на стеке с Playwright. agent-browser же подкупает своей ~~хайповой~~ нативной Rust-природой и абсолютным минимализмом — один маленький бинарник, который идеально ложится в легковесные контейнеры.

4. Заключение

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

Если вам нужен сложный скрапинг данных с обходом антифрод-систем или жесткие E2E-тесты в пайплайнах, вы всё равно будете писать код на классическом Playwright. А если вы хотите, чтобы кодинговый агент сам проверял, что кнопка в вашем React-Tailwind-VibeСode-WebApp работала так, как нужно, используйте легковесные обертки вроде agent-browser или нового playwright-cli.

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

Ну, а на дорожку, пощупать agent-browser можно буквально в пару строк:

npm install -g agent-browser
npx skills add vercel-labs/agent-browser
agent-browser install
agent-browser open https://habr.com

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

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

Как дизайнеру подготовить сложную веб-анимацию для разработчика: три сценария из практики

tim_kate1010 — Thu, 30 Apr 2026 11:07:29 +0000

Все мы знаем этот рабочий любовный треугольник: клиент — дизайнер — разработчик.

Клиент: «А давайте при движении мышки у нас из частиц соберётся грузовик, а потом ещё и датчик слежения за ним?»

Дизайнер: «Я нарисовал. Примера анимации нет, но я тебе сейчас всё объясню на словах…»

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

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

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

Ситуация 1. Клиент хочет эффект воды, ряби или капель на hero-блоке при движении курсора

Ситуация не то чтобы страшная, но попотеть придётся. Есть несколько вариантов решения этого вопроса.

Вариант 1: если есть референс — вообще замечательно! Беру страницу с похожим эффектом, нажимаю на правую кнопку мыши или на тачпад, выбираю «Просмотр кода», выделяю весь код и вставляю в любой текстовый редактор. Я пользуюсь стандартным Google Docs, но можно и блокнотом, ну, или скачивайте в формате .txt.

В моём случае был такой сайт:

https://bfd.su/

Далее иду в Grok, прикрепляю файл и пишу промпт:

«Из этого кода надо вычленить кусок, который отвечает за анимацию воды на hero-блоке»

Вот какой результат выдаёт нейронка:

Иииии...ничего не заработало, иду дальше.

Пишу следующий промпт: «Прикрути к коду тёмный фон, чтобы хорошо посмотреть эффект воды»

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

Но мы не сдаёмся!

Пишу дальше: «Код не работает, найди ошибки»

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

Вариант 2: Можно найти похожий эффект в сервисах с готовым кодом и отправить его в качестве рабочего варианта.

Например, такие штуки можно искать на CodePen.

Пишу в поисковой строке «Water ripple effect» и смотрю, что выдаст поиск.

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

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

Небольшой совет: обращайте внимание на название самого эффекта. Его можно скопировать и использовать для более точного поиска.

Ситуация 2. Клиент хочет «взрыв-схему» бургера (или любого продукта)

Клиент открывает свою бургерную и хочет что-то УНИКАЛЬНОЕ, как у Apple, и чтобы всё вертелось, крутилось, но было минималистично и лаконично. В общем, хочет «взрыв-схему» бургера, завязанную на скролл.

Ок! Хочет — буду делать.

Шаг 1. Генерирую исходную картинку

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

Промпт:

«A hyper-realistic, mid-air exploded view of a towering veggie burger with multi-grain bun, sharp cheddar, grilled mushroom patty, roasted red pepper, and crisp breadcrumbs, and red cherry tomatoes hover in dynamic suspension around the ingredients, as if caught in a flavorful gust of wind. The lighting is warm and directional, highlighting moisture droplets, textures, and sheen across every layer. Photorealistic rendering with extreme depth of field, dramatic shadows, and vibrant organic color grading evokes the sense of a fresh, gourmet plant-based meal captured in an action freeze-frame»

Иду в бесплатный Gemini и вставляю промпт.

Получается такой результат:

Шаг 2. Собираю бургер обратно

Всё в том же Gemini собираю бургер.

«Assemble the burger–make sure it doesn't fall apart»

Получаю две картинки:

Иду в Figma и готовлю материал:

Делаю однотонный фон, желательно того же цвета, что и фон сайта.
Делаю одинаковый формат — это важно! Один фон, одно позиционирование и один размер картинки.

Шаг 3. Делаю плавный переход в Kling

Выгружаю картинки в формате JPEG и иду в Kling для генерации видео. Зачем? Чтобы потом покадрово разложить видео и привязать кадры к скроллу.

Выбираю формат работы — «Generate».

Выставляю первый и финальный кадр самого видео.

Получаю видео с зацикленным результатом.

Шаг 4. Превращаю видео в интерактивный скролл-эффект

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

Томить не буду, просто вставлю всё сюда.

Папка с файлами.

Беру 3-й промпт, вставляю его и прикрепляю все остальные документы из папки.

Промпт:

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

Файлы в проекте:

landing.md — полное ТЗ с текстами, структурой страницы и описанием секций. Следуй ему.
scroll-animation-config.md — конфигурация scroll-анимации: пайплайн, параметры canvas, предзагрузка кадров, логика скролла. Используй как техническую спецификацию.
video.mp4 — исходное видео с анимацией бургера. Из него нужно извлечь кадры для scroll-анимации.
logo.png — логотип для хедера.

Техстек:

Next.js
Tailwind CSS

Важно: Для извлечения кадров из видео нужен FFmpeg. Если не установлен — сначала установи его. Конвертация video.mp4 → секвенция кадров WebP описана в scroll-animation-config.md»

ВАЖНО! Названия файлов должны совпадать с названиями в промпте.

Добавляю всё это в Claude и получаю такой результат:

file:///Users/kate/Downloads/grind-burger-preview%20(1)/index.html

Вытаскиваю рабочий кусок кода и отдаю фронтам.

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

Ситуация 3. Логотип распадается и собирается из частиц

Идея классная, но что с ней делать?! Объяснить такое тяжело, но есть несколько вариантов.

Можно вернуться к предыдущим сценариям, а можно перейти в Spline. Там есть возможность для создания своих анимаций, а ещё внедрение уже придуманных эффектов.

Перехожу в раздел «Community» и вбиваю в поиске «Particles».

Нахожу нужный референс:

Захожу в рабочее пространство самого эффекта
Загружаю в него 3D-рендер модели. В моём случае это был сложный грузовик, но в целом, это может быть что вашей душе угодно. Вопрос лишь в том, что чем проще фигура, тем лучше она будет выглядеть — это в целом логично. Условно, квадрат или несложный логотип будут более эффектными и менее замороченными по настройкам.
Далее кручу, верчу и настраиваю сами частицы, делаю их крупнее или мельче, много или мало. Настраиваю интерактивное взаимодействие анимации и мышки, скорость реакции, резкость — ну, вы поняли. Лучше это всё отдавать вашему моушен-дизайнеру, но в целом, разобраться реально. Подробнее на видео:
После того, как видимый результат начал вызывать экстаз и истерический восторг, экспортирую скрипт, который описывает данную анимацию.
Отдаю все файлы фронту и живу в мире и благополучии.

Есть одно НО — этот сервис платный.

Итоговые лайфхаки для дизайнеров и разработчиков:

Не пытайтесь объяснять сложную анимацию только на словах. Лучше сразу прикладывайте референсы, код и видео.
CodePen, Spline Community и готовые эффекты на GitHub — это ваши лучшие друзья.
ИИ (Grok, Claude и Kling) сильно ускоряет процесс, но работает лучше всего в связке: один генерит визуал, второй — код, а третий помогает отлаживать результаты.
Самый быстрый путь к вау-эффектам — комбинация: референс → ИИ-разбор → доработка → готовый код.

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

Что будет, если пихать кофеин под глаза

Thu, 30 Apr 2026 11:00:19 +0000

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

Источник

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

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

Мы в Гельтеке 30 лет делаем медицинские гели, 10 лет — уходовую косметику, любим сложные задачи. Фофаны — одна из таких. У нас есть средство с кофеином, но это, скорее, экстренная косметическая помощь. А теперь мы сделали штуку посерьёзнее: кофеина там больше, он высвобождается постепенно и работает на перспективу.

Из чего состоят тёмные круги

Группа пластических хирургов в 2016 году перелопатила доступную на тот момент литературу по тёмным кругам и выдала саммари: что это такое, откуда берётся, как лечить.

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

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

То, что заложено с рождения, гелем не переписать.

А вот то, что усиливается от недосыпа и усталости, — это уже рабочая зона.

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

Почему кофеин вообще делает с сосудами что-то полезное

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

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

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

Японцы решили это проверить и получили неожиданные данные

В 2002 году учёные из Медицинского колледжа Осаки задались вопросом: окей, кофеин снижает кровоток в мозге, это мы знаем, но что именно он делает с сосудами внутри глаза, особенно в зоне зрительного нерва?

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

Поэтому вопрос не академический, а сугубо прикладной.

В исследование взяли 10 человек: 5 мужчин и 5 женщин, возраст 25–44 года, никаких глазных болезней. Дизайн двойной слепой: каждый участник приходил дважды с интервалом в неделю. Один раз получал капсулу со 100 мг кофеина (это примерно одна чашка кофе), другой — пустышку с лактозой. Ни участники, ни исследователи не знали, что именно принимается в конкретный день. Перед каждым визитом 6 часов без кофеина, 2 часа без еды, полчаса без физических нагрузок.

Источник

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

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

Результат: кровоток в зрительном нерве и в сосудистой оболочке глаза (хориоидея — это слой сосудов под сетчаткой) достоверно снизился. По AUC (это суммарный эффект за два часа, а не одна точка измерения) в зрительном нерве p = 0,0218, в хориоидее-сетчатке p = 0,0469. В среднем по хориоидее на 60-й минуте — минус 6% кровотока. Для сравнения: при двойной дозе в более ранней работе снижение доходило до 13% — зависимость выглядит примерно линейной.

Главный сюрприз: артериальное давление — стабильно (примерно 79–80 мм рт. ст. во всех точках), как и пульс (примерно 70 уд/мин). Внутриглазное давление тоже без изменений (около 13 мм рт. ст.). Кровоток упал, а вся система как будто этого не заметила.

Учёные посчитали сосудистое сопротивление: взяли перфузионное давление (грубо — давление, которое «проталкивает» кровь через ткани) и разделили на скорость кровотока. Если давление не изменилось, а кровотока стало меньше — значит, сосуды физически сузились. Как шланг: давление воды то же, а струя слабее, потому что его пережали. На 60-й минуте сосудистое сопротивление значимо выросло.

Момент минимального кровотока у всех разный. У кого-то на 45-й минуте, у кого-то на 75-й. Это нормальная физиология: скорость, с которой организм перерабатывает кофеин, сильно различается. Период полувыведения (время, за которое концентрация вещества падает вдвое) варьирует от 2,7 до 9,9 часа. Почти четырёхкратная разница. Зависит это от активности фермента CYP1A2 в печени.

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

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

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

Суровая фармакология и никакого мошенства!

Музыкальная пауза для тех, кто дочитал до середины.

Почему предыдущая формула нас не устраивала

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

Базовый — он на то и базовый, без акцента на активный дренаж.

Часть пользователей этого геля жаловалась на жжение. Это неудивительно: кожа вокруг глаз — самая тонкая на лице, буквально в доли миллиметра, плюс анатомически близко к слизистой. Любой агрессивный компонент там ощущается сразу. Мы пересмотрели систему консервантов и заменили её на более мягкую: каприлгидроксамовую кислоту и Disodium EDTA. Ну и решили докрутить формулу и усилить кофеином, чтобы два раза не вставать.

Вторая проблема вскрылась уже на альфа-тестировании: у нас это было 20 человек и 3–4 недели. Мы сравнивали доработанную версию с текущей и выяснили, что эффект по отёкам есть, но слабее, чем хотелось бы. Стали разбирать состав.

За противоотёчный эффект отвечал пептид айсерил — это молекула, которая должна улучшать микроциркуляцию и уменьшать застой жидкости. На практике его оказалось недостаточно. В итоге заменили его на дипептид-2 (он лучше работает с лимфодренажем) и добавили дополнительные активы. После этого провели бета-тестирование (больше людей, дольше использование), и там картина уже была стабильной.

Концентрация инкапсулированного кофеина в новом геле — 5% (в пересчёте на чистый — 2,5%), но дело не только в количестве, но и в упаковке (капсула).

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

Для зоны вокруг глаз это решает сразу две задачи: безопасность и эффективность.

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

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

Основа геля — вода, глицерин, пропиленгликоль. Последний работает двойным агентом: растворяет компоненты и помогает им проникать в кожу. Молочная кислота здесь не отшелушивает, а регулирует pH формулы, чтобы всё перечисленное выше работало в оптимальных условиях. Гиалуроновая кислота (высокомолекулярная) удерживает влагу на поверхности кожи, чтобы гелевая текстура без масел не давала ощущения сухости.

Куда и как мазать

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

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

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

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

Как мы переписывали логику очередей: Celery => aio-pika => FastStream

GregTMJ — Thu, 30 Apr 2026 10:58:52 +0000

Наш путь активной работы с очередями RabbitMQ начался с классического Celery. Осознав критичность низкоуровневого контроля системы, принялись работать с aio-pika. Но и этот уровень слишком местами сложный (далее расскажу почему), и нашли отличное решение, на текущий момент, в лице FastStream. Сразу оставлю такую пометку, что каждый инструмент подходит для решения своей задачи. Мы больше хотели сделать акцент на удобство и скорость разработки относительно затрачиваемого времени на миграции решений.

N.B.: Код возможно покажется неоптимальным или старым. Это всё наш дорогой Легаси.

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

Наша система построена на основе микросервисов, работающих с RabbitMQ. Внутри - обычный асинхронный код для похода на внешние API и в БД.

Требования:

Надежный консьюминг - это для нас критично, чтобы сообщение шло по всему флоу и нигде не останавливалось без причин. Если ошибка падает, то это должно отражаться в 3 местах: БД, логи и метрики.
Ретраи при ошибках обработки.
Трейсинг - поддержка OpenTelemetry.
Мониторинг сервиса через healthcheck’и.
Prometheus метрики.

Решение №1: Celery как консьюмер

Почему Celery

Celery — классический инструмент для фоновых задач, знакомый большинству Python-разработчиков. Из коробки: декларативное описание задач, ретраи с экспоненциальной задержкой, хранение результатов, мониторинг через Flower, интеграции с фреймворками. Логика проста: пишешь @app.task, запускаешь воркер — и сообщения из очереди начинают обрабатываться.

Как мы его использовали

Мы не отправляли задачи из кода в духе my_task.delay(), а настраивали Celery на прослушивание внешней очереди, куда сообщения попадали от других систем. По сути, Celery выступал как consumer: подключался к брокеру, забирал сообщения, десериализовал и передавал в наши обработчики. Настройки вроде max_retries, default_retry_delay, countdown позволяли гибко управлять поведением при сбоях. Важно ещё подсветить, что результат всегда игнорируется с помощью параметра ignore_result=True поскольку все результаты записываются в БД.

Пример инициализации воркера:

def create_app(
    name,
    broker,
    include,
    backend=None,
    task_queues=None,
    liveness_probe=1,
    update_period=60,
    watcher_config={},
):
    # Создание само приложение + наложение дополнительных конфигурации
    app = Celery(name, broker=broker, include=include, backend=backend)
    app.conf.update(
        result_expires=120,
    )
    add_without_heartbeat_argument = Option(
        ("--without-heartbeat",),
        default=True,
    )

    app.user_options["worker"].add(add_without_heartbeat_argument)
    if task_queues is not None:
        app.conf.task_queues = task_queues

    if liveness_probe:
        add_update_period_argument = Option(
            ("--update-period",),
            default=update_period,
        )

        HEARTBEAT_FILE.touch()

        app.user_options["worker"].add(add_update_period_argument)

        # Добавление кастомной livenessProbe для K8s
        app.steps["worker"].add(LivenessProbe)
    
    # инициализация трейсинга
    with_tracing = watcher_config.get("with_tracing")
    if with_tracing:
        tracing_exporters = watcher_config.get("tracing_exporters", ())
        signals.worker_process_init.connect(
            init_celery_tracing(app_name=name, tracing_exporters=tracing_exporters),
            weak=False,
        )
    return app

С чем столкнулись

Celery проектировался как система передачи сообщений между системами. Из-за чего столкнулись со следующими проблемами:

Потребление памяти — из-за оборачивания каждого сообщения в метаданные и хранения внутренних структур Celery расход оперативной памяти быстро рос пропорционально потоку сообщений. При высоком темпе обработки воркер начинал использовать значительно больше ОЗУ, чем требовалось самой бизнес-логике, что вынуждало выделять избыточные ресурсы.
Управление соединениями и heartbeat — Celery скрывает многие детали брокера, из‑за чего при сетевых сбоях восстановление происходило с задержками, а тонкая настройка consumer_timeout, broker_transport_options была сложной и плохо документированной.
Избыточность — Как можно заметить мы используем минимальные дополнительные конфигурации Celery.
Падение контейнера на битом сообщений — Будет не совсем справедливо относить это полностью к минусам самого Celery, это больше камень в наш огород. Но опыт есть опыт. Если воркер обрабатывал невалидное сообщение в плане структуры, то падал весь контейнер, при этом сообщение консьюмилось. Что приводило к непониманию “куда делось сообщение и что с ним произошло?”.

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

Решение №2: aio-pika — близко к железу

Идея

Перейти на чистый AMQP, отказавшись от посредника в виде Celery. aio-pika — асинхронная библиотека для RabbitMQ, предоставляющая прямой доступ к каналам, обменникам, очередям. Код становится минимальной прослойкой над протоколом: сами управляем подписками, подтверждениями (ack/nack), префетчем, реконнектами.

Что переписали

Написали небольшой собственный “фреймворк” консьюминга: асинхронный раннер, который при запуске создаёт соединение, открывает канал, объявляет очереди с нужными параметрами durable/exclusive, подписывается на них, а в колбэке вызывает наши обработчики.

Поверх этого появились:

Ручной retry — Декоратор поверх колбэка, имеющий свой счётчик кол-во повторов при возникновений ошибок.
LivenessProb — Кастомный на уровне ядра aio-pika представлен чуть ниже.
Трейсинг — вручную оборачиваем вызовы в OpenTelemetry спаны, передаём trace context в заголовках AMQP при ретраях.

Пример LivenessProb:

class CustomRobustConnection(RobustConnection):
    def __init__(
        self,
        url: URL,
        loop: asyncio.AbstractEventLoop | None = None,
        **kwargs: Any,
    ):
        super().__init__(url=url, loop=loop, **kwargs)
        # Кастомный класс пробы, схож с тем, что выше для Celery
        self._liveness_probe = LivenessProbe()

    async def connect(self, timeout: TimeoutType = None) -> None:
        # Тут держитесь крепче. Я когда впервые это увидел, без литра кофе не смог понять как оно работает
        self._RobustConnection__connect_timeout = timeout

        if self.is_closed:
            raise RuntimeError(f"{self!r} connection closed")

        if self.reconnecting:
            raise RuntimeError(
                (
                    "Connect method called but connection "
                    f"{self!r} is reconnecting right now."
                ),
                self,
            )

        if not self._RobustConnection__reconnection_task:
            self._RobustConnection__reconnection_task = self.loop.create_task(
                self.__connection_factory(),
            )

        await self._RobustConnection__fail_fast_future
        await self.connected.wait()

    async def __connection_factory(self) -> None:
        logger.debug("Starting connection factory for %r", self)
        while not self.is_closed and not self._close_called:
            logger.debug("Waiting for connection close event for %r", self)
            await self._RobustConnection__connection_close_event.wait()

            if self.is_closed or self._close_called:
                return

            try:
                self.transport = None
                self.connected.clear()

                logger.debug("Connection attempt for %r", self)
                await Connection.connect(self, self._RobustConnection__connect_timeout)

                if not self._RobustConnection__fail_fast_future.done():
                    self._RobustConnection__fail_fast_future.set_result(None)

                logger.debug("Connection made on %r", self)
                self._liveness_probe.start()

            except CONNECTION_EXCEPTIONS as e:
                if not self._RobustConnection__fail_fast_future.done():
                    self._RobustConnection__fail_fast_future.set_exception(e)
                    return

                logger.warning(
                    'Connection attempt to "%s" failed: %s. '
                    "Reconnecting after %r seconds.",
                    self,
                    e,
                    self.reconnect_interval,
                )
                self._liveness_probe.stop()
            except Exception:
                logger.exception(
                    "Reconnect attempt failed %s. " "Retrying after %r seconds.",
                    self,
                    self.reconnect_interval,
                )
                self._liveness_probe.stop()

            await asyncio.sleep(self.reconnect_interval)

Что стало лучше

Полный контроль над жизненным циклом соединения, тонкая настройка prefetch, возможность реализовать любую логику подтверждения (например, отложенный ack после завершения цепочки действий). Нет лишних метаданных в теле сообщения — брокер передаёт ровно то, что отправил продюсер. Асинхронность нативная, работает на asyncio без костылей.

Проблемы

Каждая «плюшка» делалась вручную и со временем объём инфраструктурного кода разросся. Десятки строк для декларации очередей, логирование reconnect‑цикла, согласование формата trace‑заголовков между сервисами. Healthcheck, хоть и был создан вручную, требовал аккуратности: нужно было отслеживать состояние не только TCP-соединения, но и открытого канала.

Решение №3: FastStream — золотая середина

Основная идея

FastStream — надстройка над aio-pika (а также над NATS, Kafka), которая даёт декларативный стиль описания consumer’ов, lifespan‑хуки, встроенные механизмы: healthcheck-эндпоинт, OpenTelemetry-интеграция, метрики Prometheus.

По сути, это aio-pika, обёрнутая в лучшие практики, которые мы сами реализовывали руками в предыдущем решении. Механизм retry описан как пример использования middleware.

Что пошло так

Healthcheck из коробки — достаточно указать FastStream объект в ASGI-приложении (через AsgiFastStream), и на /health возвращается статус брокера.
Lifespan — менеджер контекста управляет запуском и корректной остановкой consumer’ов, повторными соединениями. Не нужно писать свои обработчики сигналов. Это касалось не только RMQ коннектов, но и например коннектов к базам данных.
Мониторинг и трейсинг — подключение OpenTelemetry сводится к нескольким строчкам: спаны автоматически создаются для каждого обработанного сообщения, propagate context через заголовки.
Декларативные middleware — проще внедрять кросс‑касательную логику (логирование, валидацию) без захламления бизнес-кода.
Простота конфигурации — брокер, очереди, обменники описываются через Python-декораторы и типы, нет нужды вручную управлять каналами и ack/nack.
Интеграция с Pydantic — Сообщение на уровне описание консьюмеров сразу пытается отвалидироваться в Pydantic модель, если это нужно.
Dependency Injection — Как можно увидеть в примере ниже FastStream предлагает нам возможность подключение DI как в FastAPI.

Вот во что превратилась кодовая база одной инициализации процесса:

app = AsgiFastStream(
    broker,
    # health + metrics из коробки
    asgi_routes=[
        (
            "/health",
            make_system_ping_asgi(broker, timeout=5.0, include_in_schema=False),
        ),
        ("/metrics", make_asgi_app(registry)),
    ],
    # Кастомный lifespan. Обычно здесь идёт инициализации подключений к БД
    lifespan=lifespan,
)

Было бы ещё не очень справедливо не показать, что из себя представляет broker

broker = RabbitBroker(
    settings.RMQ_URL,
    # Примеры миддлвары
    # RabbitPrometheusMiddleware из коробки для мониторинга сообщений
    # EnrichLogMiddleware и FailCatchComplexMiddleware кастомные для отслеживания логирования и ошибок 
    middlewares=(
        RabbitPrometheusMiddleware(registry=registry),
        EnrichLogMiddleware,
        FailCatchComplexMiddleware(
            ignore_routing_keys=[
                settings.RMQ_FAIL_TABLE_QUEUE,
                settings.RMQ_DASHBOARD_SETTINGS_QUEUE,
                settings.RMQ_TIMEOUT_QUEUE,
            ],
        ),
    ),
    logger=logger,
    # Кастомные парсеры и декодеры для обработки входящих сообщений
    parser=json_parser,
    decoder=decoder,
)

broker.include_router(router)

и пример как инициализируется консьюмер

from faststream import Depends
from faststream.rabbit import (
    ExchangeType,
    RabbitExchange,
    RabbitMessage,
    RabbitQueue,
    RabbitRouter,
)
from faststream.rabbit.annotations import RabbitBroker as ContextRabbitBroker

# Вместо RabbitRouter можно использовать broker.
router = RabbitRouter()
@router.subscriber(
    RabbitQueue(
        name=...,
        durable=True,
        routing_key=...,
    ),
    RabbitExchange(
        name=...,
        durable=True,
    ),
)
async def on_service_hub_message(
    message: RabbitMessage,
    # Имеется общий контекст всей системы
    broker: ContextRabbitBroker,
    # DI
    async_session=Depends(get_db_session),
) -> None:

Подключение консьюмеров простое, почти схожее с Celery, но чуть шире. Возможности FastStream на этом не заканчиваются. Если копать ещё глубже, то там можно найти документацию AsyncAPI и In-memory тесты.

Что пошло не так

Производительность — из-за дополнительных слоёв абстракции (middleware, автоматическая обвязка спанов, встроенные ретраи) пропускная способность ниже, чем у голого aio-pika. Это для нас лишь только в теории, поскольку поток не достигает больших значений 30-40 RPS. Справедливости ради, это не относится к минусам, поскольку бенчмарки я не проводил, и фраза “поверь мне брат” меня убедила.
Сложность отслеживания кодовой базы — Тут опять из-за дополнительных слоёв абстракции иногда заходишь внутрь посмотреть что там, и можно с лёгкостью потеряться.

Итоговое сравнение

Критерий	Celery	aio-pika (самописный)	FastStream
Подход	Динамические задачи	Низкоуровневый AMQP	Высокоуровневый consumer
Асинхронность	Ограниченная (gevent)	Полная (asyncio)	Полная (asyncio)
Healthcheck	Требует доп. решения	Ручная реализация	Из коробки
Retry	Встроен в задачу	Реализуется вручную	Реализуется вручную (есть пример)
Трейсинг (OTel)	Через сигналы Celery	Ручное встраивание	Из коробки
Контроль	Низкий	Максимальный	Средний (middleware)
Производительность	Умеренная	Высокая	Больше чем у Celery, ниже чем у aio-pika
Кривая входа	Низкая	Средняя (требует знаний AMQP)	Низкая (знакомо по FastAPI)

Заключение

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

Да, возможно я выступаю в качестве адвоката этого инструмента, но что могу поделать, когда он так понравился? это вы ещё не увидели как стараюсь переписать всё на Rust.

Отойдя от жаргона и шуток повторю первую свою мысль: У каждой задачи свой инструмент. Мой — это FastStream.

Фишинг в 2026: как ИИ и дипфейки изменили методы атак, но не изменили способы защиты

Lexx_Nimofff — Thu, 30 Apr 2026 10:57:47 +0000

Вступление

Привет, Хабр! Находясь на мероприятии BI.ZONE Day, я слушал доклады и ходил между стендами, думая, чтобы такого спросить, не связанного с продуктами и технологиями компании, чьё было мероприятие. И тут меня привлекла презентация про фишинг, я не мог отказать себе в удовольствии задать несколько вопросов специалистам по фишингу. Тем более тема всегда актуальная и интересная. Поэтому я поговорил с руководителем BI.ZONE AntiFraud Алексеем Лужновым и руководителем BI.ZONE Digital Risk Protection Дмитрием Кирюшкиным. Встречайте интервью Алексея и Дмитрия о том, как ИИ изменил методы фишинга, какие приёмы социальной инженерии до сих пор работают в 2026 году, насколько велик рынок понятия «фишинга как услуги» (Phishing as a Service, PHaaS) и не только. Приятного чтения!

Интервью

Как ИИ (нейросети, дипфейки) изменил методы фишинга в 2026 году?

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

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

Какие каналы (электронная почта, мессенджеры, соцсети, SMS и телефонные звонки) чаще всего используют злоумышленники для фишинга?

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

При этом традиционным способом доставки фишингового контента остается электронная почта. По данным исследования Threat Zone 2026, 64% целевых атак на компании России и других стран СНГ начинаются именно с фишинговых писем. С помощью них атакующие стремятся получить доступ к IT-инфраструктуре организаций: достаточно одного открытого вложения, чтобы злоумышленники могли скомпрометировать устройство и получить доступ к чувствительным данным компании.

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

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

Дмитрий Кирюшкин: Примерно с октября 2025 года мы отмечаем, что большинство фишинговых атак нацелено на получение доступа к мессенджерам или личным кабинетам в государственных сервисах. Также мы наблюдаем рост количества атак типа Ghost invoice. Это не совсем типичный фишинг, но близкое к этому виду мошенничество. При такой схеме злоумышленники создают домены, похожие по наименованию на названия ресурсов крупных компаний: чаще всего они связаны с промышленной сферой. От имени этих организаций рассылают предложения потенциальным клиентам. По незнанию они могут оплатить поддельные счета и остаться без денег и без товара. При этом компания, которую имитируют мошенники, потеряет доверие клиентов и репутацию.

Какие приёмы социальной инженерии (фальшивые письма от банков, уведомления от госслужб, лотереи и т.д.) наиболее эффективны в рамках фишинга в 2026 году?

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

Большой популярностью все еще пользуется схема Fake Boss, при которой злоумышленники выдают себя за руководителя компании. Сотруднику пишут якобы от имени начальника, предупреждают о предстоящем звонке от правоохранительных органов или регуляторов и просят посодействовать. Затем жертву убеждают под угрозами проверок перевести деньги на «безопасный счет», который контролируют мошенники. В результате под давлением сотрудники совершают переводы или раскрывают конфиденциальную информацию, что приводит к финансовым потерям и рискам для компании.

Как злоумышленники используют новые инструменты (QR-коды, поддельные мобильные приложения, фишинговые сайты) для проведения атак?

Дмитрий Кирюшкин: Мошенники крайне активно используют подобные инструменты для обмана пользователей. Однако некоторые из них постепенно теряют свою популярность. Например, за первый квартал 2026 года обнаружено 12,5 тысяч мошеннических сайтов во всех доменных зонах, включая российскую. За аналогичный период прошлого года таких ресурсов насчитывалось 17,5 тысяч Такая динамика отчасти связана с тем, что регистраторы, хостинг‑провайдеры и команды реагирования оперативно их блокируют. Кроме того, мошенникам все сложнее реализовывать сценарии атак, поскольку общая киберграмотность населения растет из года в год.

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

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

Что известно о развитии «фишинга как сервиса» (Phishing-as-a-Service) и насколько широко он используется преступниками?

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

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

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

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

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

Какие примеры многоэтапных фишинговых схем («письмо + звонок», цепочки переадресации и т.п.) становятся заметными?

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

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

Кроме того, распространен метод TOAD (telephone-oriented attack delivery, фишинг с обратным звонком). Злоумышленники заставляют жертву самой выйти с ними на связь, например, через письмо или сообщение с просьбой перезвонить. Благодаря этому обходятся антиспам-фильтры, которые обычно срабатывают при входящем звонке от мошенника, тогда как в таких сценариях инициатива формально исходит от самой жертвы. У человека возникает больше доверия к разговору. Во время такого звонка злоумышленники могут представляться сотрудниками компаний, выманивать логины и пароли или убеждать установить вредоносное приложение. В результате они получают доступ к устройству, аккаунтам жертвы или даже к корпоративным системам.

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

Что известно о теневой экономике фишинга: на сколько велик рынок «фишинга как услуги» и какова его доходность?

Дмитрий Кирюшкин: В российской доменной зоне часть фишинга работает по типу PHaaS. Это можно отследить на примере известной схемы «Мамонт». Есть люди, которые создают целую сеть фишинговых доменов, и есть воркеры, которые распространяют фишинговые ссылки за определенный процент от украденных средств. Порог вхождения очень низкий, для этого не нужно обладать глубокими экспертными знаниями. При этом ущерб от таких схем довольно масштабный: по нашей оценке, за 2025 год мошенники похитили более 18 млрд рублей.

Заключение

Как стало понятно из разговора, фишинг в 2026 году эволюционировал далеко за рамки простых массовых рассылок. Благодаря ИИ, дипфейкам и платформам атаки стали персонализированными, многоэтапными и технологически изощрёнными.

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

Ну что же, обычным пользователям и компаниям остаётся только быть настороже, не терять бдительность и помнить: если что‑то выглядит подозрительно — лучше перепроверить через официальные каналы. Спасибо за прочтение!

Откуда в YADRO конструктивизм: ищем ответы в истории авангарда

Thu, 30 Apr 2026 10:42:22 +0000

TATLIN, VEGMAN и KORNFELD — это не только идеальное наполнение для центра обработки данных, но и плеяда знаменитых на весь мир архитекторов-конструктивистов эпохи авангарда. Их философией вдохновлялись основатели YADRO, а принцип «функция определяет форму» лег в основу продуктов компании. Но чем занимались архитекторы, в честь которых назвали серверы, СХД и коммутаторы? Какое наследие они оставили нынешнему поколению инженеров?

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

Владимир Татлин — визионер с инженерным мышлением

И любитель бандуры

В линейке YADRO: системы хранения данных TATLIN.

Что вдохновляет: визионерство и стремление к совершенству.

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

Летательный аппарат «Летатлин» хранится в Третьяковской галерее

В начале карьеры он преподавал во ВХУТЕМАС — главной архитектурной школе своего времени.

ВХУТЕМАС — первая точка маршрута «Вычисляя архитектуру» и место учебы множества авангардистов в 20-е годы прошлого века, когда этот стиль преобладал в искусстве и архитектуре. Но признаки и принципы авангарда можно найти в постройках разных периодов: от от Вычислительного центра Госплана до высотки на Красных воротах. Вместе с опытным гидом из креативного бюро «Глазами инженера» вы узнаете:
как создавались неочевидные инженерные изобретения: например, адимарипы и нейтрализующие стены;
почему «дом-компьютер» пропорционален диаметру Земли;
где находится несуществующий проспект, на который выходят парадные фасады министерств;
зачем инженеры замораживали землю под сталинской высоткой.
Экскурсии пройдут в Москве 11 и 30 мая в 12:00. Старт маршрута — у Дома Юшкова на «Чистых прудах».
Купить билет →

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

Узнать больше →

Георгий Вегман — инженер-художник

В линейке YADRO: серверы VEGMAN R.

Что вдохновляет: умение смотреть на продукт с разных сторон.

Георгий Вегман обучался и во ВХУТЕМАС, и в Московском институте гражданских инженеров. Этот опыт отразился на каждом его проекте: художественное видение и инженерное мышление позволяли архитектору создавать многофункциональные и технологичные здания.

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

Проект ночлежного дома

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

Узнать больше →

Яков Корнфельд — проектировщик зрелищных зданий

В линейке YADRO: сетевые коммутаторы KORNFELD.

Что вдохновляет: идея создать универсальный продукт в своей сфере.

Самый известный проект Якова Корнфельда — кинотеатр «Родина» в Москве, и его уникальность в том, что он не стремится быть уникальным. Корнфельд спроектировал типовой советский кинотеатр, аналоги «Родины» есть по всей стране. Тем не менее в своем «массовом» решении конструктивист все-таки отстроился от главного зрелищного здания начала XX века — монументального, но неадаптивного кинотеатра «Художественный».

«Родина» в 1952 году

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

Узнать больше →

Больше об истории авангарда и его связи с разработками YADRO узнаете на экскурсии «Вычисляя архитектуру». Билеты — на лендинге проекта.

Большое сравнение процессоров Intel разных лет в играх

Thu, 30 Apr 2026 10:39:08 +0000

Спойлер: старые лучше новых

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

Тестовый стенд и методика

Тестирование проводилось в 1080p — это стандартная методика Hardware Unboxed для процессорных тестов, потому что в более высоких разрешениях упор смещается на видеокарту и разница между CPU размывается. Видеокарта — GeForce RTX 5090, чтобы она точно не стала узким горлом. Память для платформ LGA 1151/1200 выбрали DDR4, а для LGA 1700/1851 — DDR5. 12900K тестировали с обоими типами.

Естественно, если вы играете в 1440p или 4K, разрыв между поколениями будет заметно меньше. В 1080p мы получаем потолок процессора, в 4K — потолок видеокарты. Так что, если сидите на 7700K с хорошей видеокартой — в реальности fps окажется выше, чем дали результаты рассматриваемого тестирования.

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

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

Rainbow Six Siege X
Counter-Strike 2
The Last of Us Part II Remastered
ARC Raiders
Horizon Zero Dawn Remastered
Assetto Corsa Competizione
Battlefield 6
Borderlands 4
Marvel Rivals
Baldur's Gate 3 (DX11)
Cyberpunk 2077: Phantom Liberty
Space Marine 2
Mafia: The Old Country
Spider-Man 2

Результаты тестирования процессоров Intel в играх

Процессор	Год	Ядра / потоки	Средний fps в 14 играх (1080p Ultra)	1% Low
Core i7-7700K	2017	4 / 8	78	54
Core i7-8700K	2017	6 / 12	99	71
Core i9-9900K	2018	8 / 16	113	83
Core i9-10900K	2020	10 / 20	122	91
Core i9-11900K	2021	8 / 16	121	90
Core i9-12900K (DDR4)	2021	16 / 24	127	94
Core i9-12900K (DDR5)	2021	16 / 24	149	113
Core i9-13900K	2022	24 / 32	170	127
Core i9-14900K	2023	24 / 32	172	129
Core Ultra 9 285K	2024	24 / 24	157	117
Core Ultra 7 270K Plus	2026	24 / 24	169	130

7700K, 8700K, 9900K, 10900K, 11900K — старые процессоры в играх

Честно говоря, 7700K в 2026 году — это уже впритык. 78 fps в среднем — вроде играбельно, но 1% Low в районе 54 fps, а значит микрофризы будут регулярными. В легких играх вроде Counter-Strike 2 или Rainbow Six Siege он еще уверенно держит больше 100 fps. Но стоит включить трассировку лучей в Cyberpunk 2077 или Spider-Man 2 — и fps валится ниже 60. На средних настройках без RT ситуация заметно лучше: средний fps поднимается до 95, а с 1% Low в районе 67. Так что если вы готовы играть без лучей и не на максималках — 7700K все еще скрипит, но едет.

Core i7-7700K хоть и старый, но все еще достаточный для не самого требовательного геймера.

8700K — уже совсем другая история. Два дополнительных ядра дали ощутимый толчок, особенно в тяжелых играх. В Spider-Man 2 с трассировкой 8700K выдает 53 fps против 39 у 7700K — разница в полтора раза. В Cyberpunk 2077 разрыв еще больше: 76 fps против 51. Правда, в Mafia: The Old Country прирост скромнее — процессор и так нагружен под завязку и дополнительные ядра помогают не так сильно.

9900K со своими 113 fps и 10900K несмотря на почтенный возраст все еще тянут даже современные игры. 10900K выдаёт 122 fps в среднем — более чем комфортно для большинства современных игр в 1080p.

А вот 11900K — единственный процессор в этом списке, который оказался медленнее своего предшественника. Первый раз за десятилетие Intel выпустила новое поколение, которое пошло назад. Если у вас стоит 10900K, а в свое время вы хотели купить новое поколение — вы ничего не потеряли.

12900K, 13900K, 14900K — быстрые процессоры, но с недостатками

Core i9-12900K стал первым процессором Intel с гибридной архитектурой и поддержкой DDR5. С DDR4 он выдает 127 fps. На DDR5 — уже 149 fps. Разница в 22 кадра между типами памяти у этого процессора ощутимая. Когда 12900K только вышел, DDR5 почти не давала преимущества в играх, но сейчас они научились использовать ее пропускную способность, особенно с трассировкой лучей.

Intel i9-12900K - был одним из поворотных моментов в истории бренда.

Core i9-13900K выдает 170 fps в среднем по 14 играм, 14900K — 172 fps. Разница между ними минимальна: 14900K — это по сути тот же 13900K с небольшим заводским разгоном. Вот только покупать сейчас эти два процессора сродни лотерее.

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

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

Какой процессор лучше для игр

И вот мы добираемся до архитектуры Arrow Lake. Core Ultra 9 285K позиционировался как полная перезагрузка серии, но в играх это обернулось скорее провалом. В итоге 285K с его 157 fps оказался медленнее 13900K (170 fps) и 14900K (172 fps), и всего на 5% быстрее 12900K на DDR5 (149 fps). Intel сделала ставку на энергоэффективность, но заплатила за это частотами и задержками между чиплетами — а в играх это как раз то, что убивает fps.

Core Ultra 9 285K - не просто так поменял нейминг. Это действительно новое поколение процессоров.

В марте 2026-го Intel выкатила Core Ultra 7 270K Plus за чуть меньше чем 30 000 рублей. По спецификациям это почти полный клон 285K за 50 000 рублей, но частота шины между чиплетами поднялась с 2,1 до 3 ГГц.

В играх 270K Plus выдает 169 fps — почти на уровне 14900K (172 fps) и получается, что лучшим игровым процессором всей линейки Arrow Lake оказался не флагман, а его более дешевая переупаковка. Лично я в этом вижу тихое признание Intel того, что 285K оказался неудачным.

Какой процессор Intel выбрать в 2026 году

Если собираете новую систему прямо сейчас и хотите Intel, но так, чтобы можно было поиграть, то Core Ultra 7 270K Plus выглядит самым разумным вариантом. По fps он на уровне 14900K, но без рисков деградации и с заметно меньшим энергопотреблением. Брать 285K за 55 000 рублей смысла мало — это переплата почти вдвое за то, что в названии стоит «Ultra 9» вместо «Ultra 7», при более низкой игровой производительности.

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

Если сидите на 7700K или 8700K — апгрейд даст ощутимый результат, но имейте в виду: при переходе на Arrow Lake придется менять материнку, память (на DDR5), цена которой сравнима с готовым компьютером год назад и, скорее всего, кулер. А в конце 2026 года Intel обещает Nova Lake с новой платформой, после чего Arrow Lake станет тупиковой веткой — апгрейдиться на ней уже будет некуда. Так что если ваш 7700K, особенно в паре с хорошей видеокартой, еще терпит, есть смысл подождать полгода и посмотреть, что реально покажет Nova Lake.

Если у вас 12900K, 13900K или 14900K — менять пока не на что. 270K Plus вам не добавит примерно ничего, а 285K и вовсе скорее всего будет медленнее. Лучше сидите и ждите Nova Lake с его обещанными 52 ядрами и Big Last Level Cache до 144 МБ. Заодно посмотрим как выглядит ответ синих на 3D V-Cache от AMD. Если Intel реально завезет все это и оно заработает, у нас будет первый по-настоящему интересный апгрейд со времен 13900K.

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

Пользовательская инструкция как инструмент адаптации, а не формальность проекта

Thu, 30 Apr 2026 10:33:09 +0000

Наталья Белова

Аналитик ELMA365 из департамента CRM&BPM в «КОРУС Консалтинг»

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

В ИТ-проектах ситуация удивительно похожа.

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

Привет, Хабр! Я Наталья Белова, аналитик ELMA365 из департамента CRM&BPM в «КОРУС Консалтинг». В этой статье расскажу, как научиться создавать инструкции, которые будут открывать и помогут пользователям легче адаптироваться к изменениям в привычной системе работы.

Почему типовые инструкции не решают проблемы

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

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

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

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

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

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

Наш первый инсайт: делать такие руководства непросто

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

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

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

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

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

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

Шаг 1. Определите цель внедрения системы

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

❌ Внедрение системы класса X для автоматизации процессов Y.

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

Шаг 2. Покажите, что изменится в работе

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

Например:

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

Затем свяжите эти изменения с практическими сценариями: «После согласования больше не придется отправлять письмо — система сама уведомит следующего участника».

Шаг 3. Обозначьте, что НЕ изменится

Этот пункт часто недооценивают, а зря.

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

Отдельно подчеркните, что сохраняется:

Зона принятия решений остаётся за руководителем;
Ответственность за корректность данных остаётся за исполнителем;
Регламент согласования не меняется, меняется только инструмент.

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

Шаг 4. Объясните, какие проблемы решаются и какой результат ожидается

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

Говорите на языке «рабочих болей»:

Больше не придется вручную собирать информацию из разных источников;
Исчезнут «потерянные» заявки;
Уменьшится количество ручных операций;
Снизится риск ошибок из-за человеческого фактора;
Процесс согласования ускорится в Х раз.

Шаг 5. Разделите зоны ответственности системы и человека

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

Зафиксируйте три блока:

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

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

Шаг 6. Определите роли пользователей

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

Это может быть разделение на:

Бухгалтера
Менеджера
Оператора
Руководителя
Администратора.

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

Шаг 7 . Сформируйте список сценариев

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

❌Работа со справочником контрагентов

✅Создать карточку нового клиента / зарегистрировать заявку / согласовать договор / сформировать отчет

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

Шаг 8. Опишите сценарии через задачу и результат

Пользователю важно понимать не только «куда нажать», но и к какому результату приведут его действия.

Попробуйте придерживаться общей структуры описания сценариев:

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

Шаг 9. Добавьте контрольные точки

Они снижают количество ошибок и помогают самостоятельно проверить себя без обращения за помощью.

Что стоит указать:

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

Шаг 10. Опишите типовые ошибки

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

Что важно включить в раздел:

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

Шаг 11. Продумайте и опишите нестандартные ситуации

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

Например, это может быть описание действий в случае, если возникла проблема, потому что:

Ответственный исполнитель отсутствует;
Документ нужно изменить после отправки;
Данные внесены с ошибкой;
Процесс остановился на согласовании.

Шаг 12. Объясните, как фиксировать проблемы грамотно

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

В алгоритме можно описать следующие шаги:

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

Чек-лист: как понять, что инструкция получилась рабочей?

Проверьте ее по критериям:

Есть вводная часть, описывающая цели изменений или внедрения новой системы.
Пользователь может быстро найти нужный сценарий.
Сценарии исходят от целей, задач, ролей пользователей и включают ожидаемые результаты.
Есть раздел по решению типовых ошибок.
Есть раздел с описанием действий в нестандартных ситуациях.
Инструкция отвечает на вопрос «что делать?», а не «как устроено?».

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

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

Владелец наркобизнеса из даркнета о РКН и импортозамещении

gtosss — Thu, 30 Apr 2026 10:32:16 +0000

Владелец наркобизнеса из даркнета о РКН и импортозамещении.

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

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

Как автору удаётся одновременно говорить с двумя лагерями, которые категорически не согласны друг с другом, — и при этом заставлять каждый из них кивать в знак согласия? Какие приёмы позволяют вложить в одну и ту же фразу два противоположных послания — по одному для каждой стороны? И главное — делает ли он это осознанно?

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

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

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

Но то, что вышло 28 апреля, просто невозможно оставить без внимания. Видео под заголовком: Разоблачение коррупционеров — Кто блокирует интернет в России.

В видео много политического контента, но Хабр этого не одобряет. Я не хочу подставлять Хабр, поэтому постараюсь смягчить все провокационные формулировки. Хотя лично моё мнение — обсуждать происходящее, не обсуждая политику, — это как пытаться объяснить, почему в комнате слон, описывая только мебель вокруг него. Или объяснять, почему потонул Титаник, не упоминая айсберг. Проводить код-ревью, не имея доступа к исходному коду. Читать stack trace, полностью игнорируя первые строки. Дебажить прод, не имея доступа к логам…

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

Видео начинается очень сильно — с цепляющих и действительно откликающихся тезисов.

— Знаете, зачем на самом деле заблокировали YouTube, Instagram и зачем сейчас блокирует Telegram? Кто конкретно и почему это делает? Ну и, конечно, к чему это приведёт?

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

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

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

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

Позже мы разберём эту тему отдельно и заполним пробелы, которые оставил сценарист видео.

Характеристика данного фрагмента — Никакой конкретики и, главное, никаких противоречий: две совершенно не согласные друг с другом аудитории только что полностью согласились с автором.

— WhatsApp, Instagram, YouTube и Telegram. Что объединяет все эти сервисы? Возможно, они все созданные на западе и используются с целью информационной войны против нашего государства или их объединяет независимость и свобода? (Ироничный смех автора)

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

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

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

Ну, тут мало кто будет спорить.

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

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

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

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

— Вспомните холодную войну. Почему советские люди охотились за джинсами и пластинками Beatles? Потому что запретный плод сладок, а свой продукт был серым и скучным. Блокируя YouTube, государство расписывается в собственном бессилии. Оно признаёт, мы не можем сделать контент интереснее, чем у них. Мы не можем победить в честном споре. Поэтому мы просто заткнём им рот, а вам завяжем глаза.

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

Обезличенная критика то ли власти, то ли ещё кого-то. Но весьма аргументированно.

— Ответ, как всегда, кроется в цепочке прибыли. Когда вы создаёте продукт, который любят сотни миллионов, как Telegram или YouTube, вы богатеете за счёт инноваций и рекламы. Но когда вы строите, ВК видео или чудо месседжер Макс, вы богатеете за счёт бюджета. Чувствуете разницу?

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

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

Просто база и еще немного раскачки на эмоции затрагивая тему налогов. Двигаемся дальше.

Блокировка Ютуба связана конкретно с неуспешностью ВК/рутуба.
Блокировка Telegram с провальным релизом мессенджера Макс.

— Заметили, как по времени совпадают эти события? Имея миллиардные бюджеты и фактическую монополию на рынке, которые обеспечивают блокировки, ВК продолжает накручивать просмотры своим избранным блогерам, чтобы в статистике всё выглядело так, словно ВКонтакте достойный конкурент Ютубу.

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

— Так вот, Макс, Рутуб и ВК хоть и являются государственными проектами, а значит, обязаны быть самыми сильными и лучшими представителями рынка при российских правилах игры таковыми не являются. А главное, они не приносят прибыль, но жрут миллиарды государственных бюджетов. Миллиарды рублей? Нет, долларов!

— И что вы думаете? В таком случае никто не спрашивает, куда делись деньги и где результаты. Представьте себе чиновника из Роскомнадзора или топ-менеджера государственного IT-гиганта. Перед ним стоит задача за 3 года и 5 млрд бюджетных денег создать убийцу YouTube. Деньги потрачены, сроки вышли. А убийца едва дышит, путаясь в собственных гениальных рекламных кампаниях и накрученных просмотрах. Что делать? Признать провал?

— В системе это означает не просто увольнение, а политическую смерть, а иногда и вполне реальные сроки. И тогда в ход идёт стратегия выживания паразита. Они начинают врать. Врут верховному правительству. Сдают отчёты, как количество пользователей непрерывно растёт. Но остаются ли эти пользователи? Готовы ли они совершать покупки или продавать рекламу и становиться популярными за счёт их сервисов? В их графиках кривая популярности rutube уходит в стратосферу, а месседжер Макс якобы вот-вот обгонит Telegram по количеству активных пользователей. Но реальность штука упрямая. Люди всё равно сидят в телеге и смотрят YouTube через костыли. И вот здесь коррупционеры находят гениальный, по их мнению, выход. Чтобы их обман не раскрыли, чтобы никто не смог сравнить их мертворожденный продукт с живым рынком, рынок нужно уничтожить.

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

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

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

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

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

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

— Настоящие профессионалы в погонах сегодня вынуждены тратить время на настройку VPN, вместо того, чтобы выполнять свои прямые обязанности. Это ли не вредительство? <далее реклама VPN>

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

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

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

Кто не хочет отвлекаться от текущей, кратко основные мысли из статьи:

Россия выделит 70 миллиардов рублей на блокировку интернета в течение ближайших трёх лет
РКН потратит 2,3 млрд рублей на ИИ для фильтрации интернета и блокировки VPN
В 2023 году кассовое исполнение расходов РКН составило 31,1 млрд

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

Сегодня упор на техническую сторону блокировок, завтра — на юридическую. Написали статью об обходе? Пройдёмте с нами. Подключились к VPN несогласованно — пройдёмте с нами. Откуда узнали? Яндекс-браузер, Ozon, Wildberries, приложения банков — уже сейчас собирают реестр пользователей VPN и изучают, с какой стороны подступиться.

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

Судьба Youtube всем известна:

Карта доступности Youtube из Википедии

А вот относительно ВК, стоит вспомнить как это было.

Официальным днём основания считается 10 октября 2006 года. В конце ноября была открыта свободная регистрация. Также запущена рекламная кампания по привлечению новых пользователей. По итогам 2007 года среди всех сайтов России «ВКонтакте» лидировал по объёмам трафика. По популярности сайт занимал 2-е место в Рунете, а также лидирующие позиции в СНГ (4-е место в Казахстане, 7-е в Беларуси, 10-е — на Украине). В 2010-м количество зарегистрированных пользователей превысило 100 млн.

Позже в соцсети начали появляться аккаунты знаменитостей со всего мира. Так, в 2013-м, 21 марта, голливудский киноактёр Том Круз зарегистрировался в социальной сети и оповестил об этом подписчиков своего блога в другой зарубежной социальной сети. Среди прочих знаменитостей во «ВКонтакте» могли встретиться: Виктория Бекхэм, Джаред Лето, Шакира, Кевин Спейси, Энрике Иглесиас, Софи Эллис-Бекстор, Пол Ван Дайк, Эрос Рамазотти и другие. Прозвучало, как вступительные титры к остросюжетному блокбастеру, но в общем-то оно так и есть.

Далее началось то, к чему мы все привыкли сегодня, но мало кто это замечал тогда. В 2013-м, 24 мая, Роскомнадзор внёс домен vk.com и его IP-адрес в единый реестр запрещённых сайтов, однако уже через несколько часов удалил его оттуда, объяснив свои действия «человеческим фактором». Видимо, дали по рукам свыше за самодеятельность, план-то был намного более коварным.

18.02.2014 на сайте vedomosti.ru была опубликована новость под заголовком: «Во “ВКонтакте” начали проверку экономической деятельности соцсети».

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

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

Сама страница с новостью удалена с ресурса

Ссылки

vedomosti.ru: Сама страница с новостью удалена с ресурса

webarchive: Архивная ссылка на новость

В 2014 году Павел Дуров публикует пост на своей официальной странице ВКонтакте. В нём он называет свою должность генерального директора формальной в результате последних изменений акционерного состава ВКонтакте.

2014 год отличился еще одним событием. РБК публикует новость.

— По словам Дурова, в процессе ему пришлось пожертвовать многим, в том числе и своей долей “ВКонтакте”. О каком именно процессе идет речь, Дуров не уточнил. При этом основатель сети подчеркнул, что не жалеет о своем выборе. “Защита личных данных людей стоит этого и намного большего. С декабря 2013г. у меня нет собственности, но у меня осталось нечто более важное – чистая совесть и идеалы, которые я готов защищать”, - отметил Дуров.

Думаю, в целом сложилось понимание. Всё неподконтрольное забрали силой, что не удалось отобрать — заблокировали, предложив костыльную «альтернативу».

Ладно, мы немного отвлеклись, у нас обзор видео Мориарти. Видео выстраивает интересную картину мира, затрагивая очень эмоциональные для нас темы. Сценаристы мастерски работают с чувствами своей аудитории и бьют в самое яблочко. Это гениальный маркетинг. Но в отрыве от таинственного голоса человека в маске, этот текст пестрит манипуляциями на хайповую тему и подаёт крайне поверхностную концепцию, не углубляясь в конкретику и исторические примеры. Цель видео достигнута на все 100% — больше одного миллиона просмотров за сутки. Оба лагеря аудитории удовлетворены и аплодируют, продажи и установки VPN растут. А что за VPN? Не товарища ли майора?

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

Боль — у нас отбирают свободу
Враги — коррупционеры и диверсанты внутри
Эмоциональное раскачивание — вы для них “скот”, “кривозубые крестьяне”
Решение — VPN автора и ссылка на роскомандзорную фармацевтику
Призывы к действию - установите VPN, подпишитесь на канал, загляните в ссылки из описания

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

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

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

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

И на последок, хочу высказаться на тему цензуры. Цензура — это система запретов и ограничений. Она нужна: без неё не будет никаких рамок дозволенного, и интернет быстро превратится в свалку мусора. Но, по-моему, РКН совершенно не справляется с этой задачей. Неужели нам нужно выделять на это 100 млрд рублей? Хабр берёт своё начало в 2006-м, РКН — в 2008-м. И Хабр на протяжении всех этих лет не просто прекрасно модерирует свой контент, но и генерирует прибыль. Здесь вы не встретите ни порнографии, ни нарушений закона, ни призывов к неподобающему поведению.

В РКН работает около 3 000 человек, которые, к слову, в 2016 году умудрились заблокировать сами себе localhost, а на Хабре — около 2 миллионов пользователей. Квалифицированных айтишников, которые отлично понимают, как устроены протоколы шифрования, и знают, как противостоять техническим угрозам. Так, может быть, доверить полномочия РКН Хабру? Заодно сэкономим 100 млрд. А представляете, сколько достойных альтернатив зарубежным сервисам можно было бы создать на эти деньги в условиях честной конкуренции, если бы их осваивали мы, а не три тысячи человек из РКН?

А это я ещё не причисляю сюда википедистов и представителей других самоорганизованных сообществ, которые годами поддерживают качество контента на чистом энтузиазме — без единого рубля из бюджета. Если объединить экспертизу всех этих людей, мы получим армию специалистов, которая на голову превосходит РКН и по компетенциям, и по мотивации. И всё это — бесплатно.

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

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