Представлен открытый проект Game Optimizer, который оптимизирует работу CPU под игры в Windows (распределяет потоки и кэш, чтобы разделить нагрузку).
На примере Overwatch у тестеров получилось увеличить FPS вдвое с 210 до 450 кадров. Утилита грамотно распределяет ресурсы, как работает:
Снижает нагрузку на ваш ПК, которую создают фоновые приложения и утилизируют ресурсы CPU, в которых нуждается игра. Особенно актуально, если у процессора есть кэш нескольких уровней (L1, L2, L3).
CPU Game Optimizer создаёт маски для игр, которые разделяют ресурсы.
Маски можно создавать самому или использовать пресеты.
Как внедрить ИИ в оптовые продажи: практические сценарии
⏰ Вебинар 15 сентября в 11:00
Приглашаем на вебинар, на котором эксперты департамента e-commerce «КОРУС Консалтинг» разберут практические сценарии внедрения ИИ в оптовые продажи — что стоит оптимизировать в первую очередь, что потребуется для запуска и как измерять результат.
⚡️Почему это важно сейчас
71% российских компаний уже используют, тестируют и внедряют ИИ. Но в торговых и производственных компаниях не всегда понятно, какие сценарии применимы на практике и с чего стоит начать. Быстрый и ощутимый эффект чаще всего дают задачи с большим объемом рутинной работы: разбор входящих заявок, подготовка коммерческих предложений, ответы клиентам по статусам заказов. Для их автоматизации не всегда нужен масштабный проект — понятная отдача видна уже на первых этапах.
👉 В программе вебинара
Какие задачи в оптовых продажах уже имеет смысл отдавать ИИ: семь практических сценариев для отдела продаж и личного кабинета клиента
Как выбрать первый сценарий для своей компании: по каким критериям оценить потенциальный эффект, сложность запуска и необходимость интеграций
Что потребуется технически: какие решения работают с корпоративными документами и данными, а где нужен доступ к учётным системам
Ответы на вопросы и разбор ситуации в ваших компаниях в прямом эфире
🎁 Бонус при регистрации
Всем зарегистрированным отправим подборку кейсов для вдохновения «Как российские компании внедряют ИИ в оптовые продажи и закупки», которая поможет сориентироваться в том, что уже происходит на рынке, найти идеи для собственных проектов и посмотреть, как другие компании подходят к внедрению ИИ на практике.
Исследуем soft skills для инженеров и тимлидов в эпоху AI
Когда-то мы выпускали подкаст про soft skills для SRE — обсуждали, как инженерам прокачивать не только технические, но и человеческие навыки. Тема оказалась настолько живой, что мы решили пойти дальше и разобраться шире: как soft skills инженеров и тимлидов меняются с приходом AI-инструментов в повседневную работу.
Какие навыки становятся важнее, а какие теряют актуальность? Как меняется коммуникация в командах? Где заканчивается зона ответственности человека и начинается зона ответственности модели?
Мы хотим собрать реальную картину от вас, а не строить гипотезы в вакууме. Если вам близка тема — заполните опрос, это займёт несколько минут.
А если хотите освежить контекст, смотрите выпуск подкаста В SREду на кухне про soft skills для инженера, с которого всё началось:
Как частное облако помогло Okko выдержать наплыв зрителей в периоды крупных чемпионатов
🏭 Что за компания Okko — один из крупнейших российских онлайн-кинотеатров. Фильмы, сериалы и в особенности спортивные события привлекают миллионы пользователей. Сервису было критически важно поддерживать бесперебойную работу платформы даже в периоды максимальной нагрузки.
⚡ Задача Okko располагал собственной инфраструктурой в Москве и Санкт-Петербурге, необходимо было связать все воедино, обеспечить резервной площадкой и убедиться, что платформа будет работать стабильно даже при взрывном росте аудитории.
☁️ Что сделали Используя платформу Cloud.ru Evolution Stack развернули частное облако на 294 хостах, реализовали новую сетевую архитектуру и георезервирование. В качестве резервной площадки выступило публичное облако Cloud.ru. Единство кодовой базы публичного и частного облака обеспечило бесшовное масштабирование и стабильную работу онлайн-кинотеатра при высоких нагрузках.
🦾 Что получили в итоге Скорость SDN-компонентов достигла 240 Гбит/с, обеспечены необходимые показатели пропускной способности сети и количества одновременно поддерживаемых пользователей. Собственная инфраструктура кинотеатра показала свою устойчивость в период Олимпийских игр. А во время финала Лиги чемпионов нагрузку подхватило публичное облако, что обеспечило доступ к трансляции для 4,5 млн зрителей. Инфраструктура готова к еще большему масштабированию без изменения архитектуры.
Телематика и топливо: как данные о стиле вождения влияют на экономию
Ситуация с топливом не радует, а когда узнаёшь, что часть залитого в бак, сгорает из-за стиля вождения, по-другому смотришь на необходимость телематики.
В перерасходе можно винить поломки или плохую дорогу, но важным фактором остается манера вождения. Резкий разгон, торможение в последний момент, скорость выше оптимальной – каждое действие разово и само по себе не так страшно. Но вместе они дают устойчивый перерасход, который списывают на маршрут, погоду или возраст техники. Сейчас, когда цены на топливо растут, а доступность ГСМ на маршрутах нестабильна, это уже вопрос рентабельности каждого рейса. На парке в 50 машин плюс 10–15% к расходу превращаются в сотни тысяч рублей в год – просто за то, что никто не смотрел на стиль вождения.
А наша любимая телематика это видит. Технология Eco Driving фиксирует резкие ускорения и торможения, превышения скорости, работу двигателя на повышенных оборотах. Каждое событие – метка на треке со временем, местом и именем водителя. По итогам смены или недели можно составить рейтинг и увидеть, кто пережигает топливо. Данные сами по себе, конечно, ничего не меняют. Дальше начинается самое интересное: что с ними делать. Штрафовать и премировать? При нынешнем рынке кадров терять водителей никто не хочет.
И момент, который обычно упускают: стиль вождения влияет не только на расход. Есть кейс с 89 КАМАЗами в нефтегазовом секторе: после внедрения телематики и контроля режима работы двигателя межсервисный интервал вырос в 2,5 раза. Меньше агрессии за рулём = меньше износ = реже и дешевле ТО. Экономия на обслуживании оказалась сопоставима с экономией на топливе.
В первую очередь, говорю для тех, чья работа связана с грузоперевозками, потому что работаю в основном с тяжелой и спецтехникой. Но вот недавно поставили систему телематики с Eco Driving на легковые машины. Захотелось поделиться одним из первых результатов месяца тестирования: одна и та же машина трижды подряд прошла один замкнутый круг 30,3 км: спокойно, резко и снова спокойно. Одна дорога, один час, один водитель – различается только манера:
спокойно: 6,90 л/100 км, 27 минут;
резко: 13,75 л/100 км, 24 минуты;
спокойно: 6,99 л/100 км, 30 минут.
Резкий круг сжег вдвое больше топлива и выиграл три минуты. Для масштаба: у машины, которая ежедневно ездит по одним и тем же маршрутам, расход от проезда к проезду гуляет на 5–8%. Разница вдвое – это куда больше обычного разброса. Погоды, светофоров или времени суток уже недостаточно, чтобы объяснить.
круг 1 - спокойная езда, круг 2 - резкая, круг 3 - спокойная
Ближе к обычной жизни другой замер: две городские поездки подряд по одной дороге (совпадение треков 94%) дали +24% топлива – без всякого показательного «резкого» режима.
Честная оговорка: это один маршрут, одна машина, один водитель. Каждый случай – индивидуальный. Переносить «экономия N%» на весь парк нельзя – для этого нужны повторы на других машинах и в городе. Но порядок цифр на контрасте виден уже сейчас.
*Как считалось: расход – интеграл мгновенного расхода из CAN-шины машины (SPN 183): прибор его измеряет, а не моделирует. Совпадение маршрутов – сравнение треков по клеткам 200×200 м (на кругах 92–95%), старты расходятся не более чем на 30 м, диапазон высот один. Источник – посекундная телеметрия Galileosky из системы мониторинга, времена UTC+5.
Готовлю подробный разбор о работе Eco Driving. Интересно узнать, кто-нибудь сталкивался в работе с контролем стиля вождения?
Почему мои оценки сроков всегда ошибались в одну сторону
Долго не мог понять один паттерн. Задачу оцениваю в три дня - выходит пять. Оцениваю в неделю - выходит две. Причём не случайно, а стабильно в одну сторону. Всегда дольше, никогда быстрее.
Потом разобрался. Дело не в том что я плохо оцениваю конкретную задачу. Дело в том что я оцениваю задачу в вакууме - без учёта всего остального что происходит параллельно.
Я оцениваю сколько времени займёт написать спеку. Не оцениваю что в этот же день придут три срочных вопроса, встреча затянется на час и коллега попросит помочь с презентацией.
Это называется ошибка планирования. Мозг фокусируется на сценарии где всё идёт по плану. Реальность всегда добавляет помехи которые в оценку не попали.
Два способа которые реально помогли.
Первый: умножать свою оценку на полтора. Не красиво, не научно, но работает. Если честно думаю что займёт два дня - закладываю три. Почти всегда попадаю.
Второй: оценивать не время на задачу, а дату когда задача будет готова. Это заставляет думать о реальном календаре - встречах, других задачах, выходных - а не об абстрактных часах работы.
Ни один из этих способов не устраняет причину ошибки. Просто компенсирует её достаточно надёжно чтобы перестать постоянно срывать дедлайны.
Как вы решаете проблему с оценкой сроков - нашли что-то что работает лучше?
15 бесплатных уроков для тех, кто работает с искусственным интеллектом
Искусственный интеллект уже меняет подход к разработке: LLM помогают писать код, искать информацию, автоматизировать процессы и создавать новых цифровых помощников. Но при переходе от экспериментов к реальным задачам появляются вопросы: какую модель выбрать, где достаточно промпта, когда нужен RAG или дообучение, как контролировать качество ответов и встроить ИИ в рабочие процессы.
Разобраться в современных ИИ‑инструментах — это первый шаг к тому, чтобы использовать их как полноценный инженерный инструмент: запускать локальные модели, создавать ИИ‑агентов, работать с ML‑пайплайнами и понимать ограничения технологий.
Собралиоткрытые уроки от преподавателей‑практиков, которые помогут разобраться в ключевых направлениях искусственного интеллекта — от больших языковых моделей и ИИ‑агентов до машинного обучения и внедрения ИИ в реальные задачи.
LLM и генеративный ИИ
3 сентября, 20:00. «Локальные LLM модели для разработки». Записаться
8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться
23 сентября, 18:00. «Structured Outputs: как заставить LLM всегда возвращать то, что вам нужно». Записаться
ИИ‑агенты и искусственный интеллект в разработке
14 сентября, 20:00. «ИИ‑агенты против Junior‑разработчиков: кто кого заменит к концу 2026 года». Записаться
17 сентября, 20:00. «Обзор ИИ‑технологий для разработчиков. От идей до рабочих решений». Записаться
1 октября, 20:00. «Продуктивность разработчика и Agent Skills». Записаться
ML и работа с данными
7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться
9 сентября, 18:00. «Оптимизируем построение модели через Pipeline». Записаться
10 сентября, 18:00. «Подготовка данных в Pandas». Записаться
16 сентября, 18:00. «Задача классификации от 0 до 9». Записаться
23 сентября, 18:00. «Дерево решений — простой и интерпретируемый ML‑алгоритм». Записаться
Практическое применение ИИ
7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться
8 сентября, 20:00. «ИИ против бага: как разобрать инцидент в Python‑проекте от логов до исправления». Записаться
21 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться
22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться
Это удивительная книга. По сути, это сборник наставлений, написанный одним старым самураем для других, молодых. Каждое наставление – отдельная, короткая, законченная глава. Касается и вполне приземлённых вопросов, и глубоко философских, вроде отношения к жизни, выбора пути, концепции служения, подходов к обучению, управления людьми и т.д.
Написана простым языком (или переводчики хорошо постарались). Читать можно с любого места, в произвольном порядке. Просто открываете на любой странице и получаете совет, который может помочь. Или хотя бы увидеть проблему с иной стороны.
Меня в этой книге подкупает глубина проработки. Подумайте сами. Сейчас технологии меняются каждый месяц, оказывая влияние, в т.ч., на управление, как область знаний. И на управление людьми, и на управление своей жизнью. Скорость перемен в одних областях (технологии, коммуникации) создаёт специфичное отношение к другим областям – тем, что традиционно считались не особо подверженными переменам. Например, определение личных целей, выбор пути, жизненная философия, концепция самообучения и саморазвития.
Специфичность отношения выражается в том, что любые старые книги и рекомендуемые в них методы кажутся устаревшими, неподходящими к современным реалиям. Попробуйте объяснить подростку или молодому человеку, что на все его вопросы о том, как жить надо, уже есть ответы в книгах Стивена Кови, Сенеки, Достоевского и Цунэтомо. Покрутит пальцем у виска и продолжит смотреть рилсы. Не только для развлечения – человек ищет там ответы на фундаментальные вопросы, сознательно или подсознательно.
Если найдутся авторы, вроде упомянутого уже Райана Холидея, переупаковавшие старые книги в новые, технологичные форматы, то пальцем у виска уже никто крутить не будет, и автора ждёт успех. Потому что мысли и знания на вечные темы, написанные в прошлых веках, не устарели. Более того: ничего особо нового в 20-21 веках и придумано не было. Почему?
Возвращаюсь к упомянутой уже глубине проработки. В те времена жизнь не менялась веками. И были люди, которые могли потратить на размышления и наблюдения половину жизни. Сейчас никто так не может – работать надо. А тот же Цунэтомо мог аккумулировать опыт лет за 500, и этот опыт был воспроизводим – контекст не менялся. Автор мог наблюдать, что в этом мире работает, а что нет, на протяжении жизни нескольких поколений. Поразмышлять об этом часа по 4 в день на протяжении 10-20 лет. Писать книгу лет 10, не переживая о гонорарах и роялти (их всё равно не будет 😊).
Как вам глубина проработки темы? Сейчас хоть один автор так может?
Самая опасная кнопка в КИИ — у человека за соседним столом
В новом исследовании «СёрчИнформ» ста судебных дел за последние годы по статье 274.1 УК РФ — «Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации» обнаружилась интересная закономерность.
95% нарушителей — сами сотрудники пострадавших организаций. 14%среди них — руководители подразделений. Но есть и хорошая новость, ИТ‑ и ИБ‑специалистов среди них всего 5%, а топ менеджмента и подавно 1%. Почти на уровне погрешности.
Внешних нарушителей — всего 5%. Но это не потому, что их мало. Просто раскрываемость компьютерных преступлений в России не превышает 21%. Большинство внешних атак остаются безнаказанными.
Что интересно, 67% проанализированных дел — не взлом и не уничтожение серверов, а внесение недостоверных данныхв таких сферах, как связь и телеком 47%, здравоохранение 25% и финансовый сектор 10%.
Причина — большое число сотрудников с легитимным доступом к системам и низкая цифровая грамотность.
Больше доступа — выше цена ошибки.
Когда администратор просто изменил не тот атрибут, или скрипт сломал членство в службе каталога — каталог жив, пользователи заходят, но доступы уже сломаны.
Для LDAP‑инфраструктуры это головная боль: система считает изменение легитимным (права‑то были!), а вы даже не знаете, что именно вернуть назад.
Классический бэкап здесь не выход. Откатывать всё из‑за одной сломанной группы — как стрелять из пушки по воробьям. Нужен другой подход:
Сравнить текущее состояние каталога с резервной копией.
Найти точечные расхождения.
Восстановить только изменённые объекты, не трогая остальное.
Защищать нужно не только доступность каталога, но и целостность данных. Потому что легитимный доступ ≠ безопасное изменение. И это справедливо не только для КИИ.
Представлен открытый проект Phone Farm iOS - TikTok-ферма на устройствах с iOS. Подключаем iPhone к Mac, регистрируем в панели и управляем прямо из браузера: можно смотреть экран в реальном времени, тапать, свайпать и запускать автоматизацию TikTok. Встроенный планировщик публикует посты и слайд-шоу по расписанию, а очередь и история запусков хранятся в PostgreSQL. Проект работает без джейлбрейка и полностью локально.
Incident Management: почему компании живут от аварии до аварии
Системы без аварий не существует. Это не пессимизм — это физика распределённых систем. Вопрос не в том, случится ли инцидент, а в том, будет ли команда к нему готова и станет ли система после него лучше или просто вернётся в исходное состояние до следующего раза.
В новом выпуске «В SREду на кухне» вместе с Максимом Бурцевым, руководителем отдела мониторинга в e-commerce, разобрали, что отличает команду, которая учится на авариях, от той, что просто их переживает.
Что на повестке
Почему большинство инцидентов случаются сразу после релиза — и при чём тут овертаймы и дежурства. Как работать с Root Cause вместо того, чтобы латать одни и те же дыры по кругу. Кто должен управлять инцидентом в моменте и какие три вопроса нужно задать сразу после аварии. Сколько на самом деле стоит инцидент — и стоит ли рассказывать об этом пользователям. Отдельно — про AI: добавит ли вайб-кодинг новых аварий и может ли AI помочь ими управлять. В Авито уже попробовали — рассказали, что получилось.
Основная мысль проста. ИИ может успешно справляться с некоторыми формами умозаключений - например, с дедукцией и индукцией, но пока не способен полноценно использовать третий тип: абдукцию.
«Хотя ИИ способен сжимать и обобщать данные с помощью индукции и доказывать теоремы посредством дедукции, он пока не может воспроизвести тот интуитивный скачок, который совершил Альберт Эйнштейн при формулировании основных положений общей теории относительности. Этот процесс опирался не на манипулирование символами, а на мысленное моделирование физических явлений».
Как фильтровать результат оконных функций в ClickHouse
Когда пишешь SQL-запрос с оконками, часто необходимо сделать фильтрацию по данным, которые они возвращают, например, получить первую строку в каждой группе через ROW_NUMBER(). Для этого приходится оборачивать запрос в подзапрос и уже на уровне внешнего запроса фильтровать данные. Ну, либо использовать CTE.
В ClickHouse можно проще.
Недавно наткнулся на фичу, которая позволяет сделать такую фильтрацию вообще без использования подзапросов или CTE. Это предложение QUALIFY.
Оно работает по аналогии с WHERE, но с одним важным отличием. WHERE отрабатывает до вычисления оконных функций, поэтому оно просто их «не видит», а QUALIFY — после.
Поэтому раньше приходилось писать так:
SELECT *
FROM (
SELECT
id,
category,
ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
FROM my_table
)
WHERE rn = 1;
А с использованием QUALIFY запрос становится короче:
SELECT
id,
category,
ROW_NUMBER() OVER(PARTITION BY category ORDER BY created_at DESC) as rn
FROM my_table
QUALIFY rn = 1;
Несколько нюансов:
В QUALIFY можно фильтровать данные прямо по алиасу из SELECT и не дублировать весь код оконной функции.
Оконную функцию можно написать прямо внутри QUALIFY. Выводить её в итоговый SELECT не обязательно. Фильтрация всё равно сработает «под капотом».
Если в запросе нет ни одной оконки, QUALIFY выдаст ошибку. Для обычной фильтрации всё так же используем WHERE.
UPD UPD: Теперь все должно быть пучком, за подробностями сюда
UPD: Важная поправка по справочнику физики и справочнику схемотехники. Codex конкретно меня подставил, и вместо реального справочника фактически выдал макет справочника, который надо допиливать и наполнять содержанием.
Лимиты у меня к сожалению уже выжраны недельные, но планирую этот факап исправить на этой или следующей неделе (у кодекса если что сбросятся 7 сентября лимиты).
По математике все относительно нормально, сам материал на месте и интерактив рабочий, но в комментах замечали что сами формулировки могут быть корявыми, так что имейте ввиду.
3 STEM-справочника никому не надо? Все в ru/eng вариантах. Доступны на Github Pages.
Писались через GPT Sol Ultra, на плане Pro 5x. Все книжки отдельно проходили аудит на то, работают ли интерактивные штуки и нет ли фактологического вранья. Во всех трех случаях агенты находили кучу косяков, и исправляли их.
Собирал в первую очередь как справочник интересующихся меня тем. Я сейчас в основном угораю по высшей математике, но справочники по физике и схемотехнике могут пригодится мне на работе, так что за компанию сделал и по ним.
При составлений тем/карточек по высшей матеше я ориентировался на эту книгу (я ее сейчас читаю, рекомендую, очень интересно и доступно поясняют) - Конспект лекции по высшей математике - Д.Т. Письменный.
Рефакторинг 22 000 строк C++: Как победить класс-монстр в Vulkan-движке [Анонс стрима]
Привет, Хабр!
Меня зовут Shagu, и последние несколько месяцев я в одиночку пишу Shuttle Engine — экспериментальный 3D-рендерер и редактор сцен на C++20 и Vulkan 1.3/1.4. Проект ориентирован на современные графические технологии: GPU-driven pipeline (Indexed Indirect Drawing, Compute-пассы для подготовки геометрии), Bindless Descriptors, Buffer Device Address (BDA) и PBR/IBL освещение.
Но, как это часто бывает в инди-разработке, за быстрым прогрессом и красивой картинкой скрывается технический долг.
История одной боли: Эволюция монолита
Изначально весь проект начинался как прототип, и вся инициализация Vulkan, окон и отрисовки находилась… в одной гигантской функции main(). Когда масштабы стали критическими, я перенес этот код в класс Application.
Но теперь и Application превратился в классический «Класс-Бог» (God Class). В одном месте у меня намешано всё:
Инициализация устройств и очередей Vulkan;
Создание Swapchain и управление кадрами;
Запись барьеров (pipelineBarrier2) прямо внутри кадра рендеринга;
Редакторский интерфейс ImGui и логика загрузки ассетов.
Добавление любого нового пасса рендеринга (например, теней или SSAO) превращается в ручное дописывание сотен строк кода в этот монолит и риск сломать синхронизацию Vulkan. Пора это исправить.
Что будем делать на стриме?
В эту пятницу, 5 сентября в 19:00 по МСК (UTC+3), я проведу свой первый LIVE-стрим, который будет полностью посвящен фундаментальному архитектурному рефакторингу Shuttle Engine.
Мы превратим класс Application в легкий и понятный оркестратор (Mediator), разбив его на три независимых модуля:
Application Module (PAL): Полностью изолируем работу с ОС (Win32/SDL), событиями ввода и созданием нативных окон.
Engine Module (Vulkan Runtime): Перенесем туда всю работу с графическим API, VMA, RenderGraph и сценой.
UI Module (RmlUi + ImGui): Выделим интерфейс в отдельный слой.
Этот рефакторинг — критически важный шаг, который подготовит фундамент для следующих тем: асинхронного многопоточного рендеринга и перехода на полноценную архитектуру RenderGraph.
Если вам интересны низкоуровневая графика, Vulkan, C++ и проектирование сложных систем реального времени — подключайтесь к трансляции. Это будет живой, нерепетированный процесс написания кода, обсуждения архитектурных компромиссов и поиска решений.
P.S. Проект разрабатывается независимо. Если вы хотите поддержать создание Shuttle Engine и помочь автору в обустройстве новой рабочей базы в это непростое время, вы можете сделать это на моей странице поддержки: https://boosty.to/shagunov. Любой вклад очень помогает продолжать работу над движком!
Еще одна интересная форма тупости у нейросеток (сначала Claude Sonnet 5, потом Claude Opus 5): оно не понимает, что если устройство (нетривиальное, то есть у которого есть внутреннее состояние) выдало глюк на тесте в первую секунду работы, то бесполезно минимизировать количество глюков, которое оно выдаст в следующий час. Оно уже глючное, нужно исправлять первый глюк. Прогресс - это не “было 100 глюков в час, стало 80”, а “был глюк на первой секунде теста, а теперь глюк появился только на второй”.
Дал нейросетке задание: исправить ошибку в сгенерированном ею модуле на языке описания аппаратуры SystemVerilog. Модуль погружен в тестовое окружение которое проверяет работу модуля против его модели (тоже написанной на SystemVerilog). На вход и модуля и модели подаются одни и те же входные транзакции (stimuli), после чего у них сверяется ответы. Ответы могут приходить в несколько разное время, но это не имеет значения, потому что перед проверкой они складируются в очередях. Как и исходные транзакции до отправления, чтобы не сравнивать детали латентности handshake-ов.
И у модуля, и у его модели имеется внутреннее состояние, поэтому ответ на первую и сотую транзакции может быть разный, даже если входящие транзакции идентичны. Из этого должно быть и коню понятно, что после того как ошибка произошла, дальше все идет вразнос - потому что отныне состояние у модуля и модели разное.
И вот оно провело ночь гоняя симуляции и минимизируя счетчик глюков. Ну первую ночь я бы простил. Я сказал “мерило прогресса - не счетчик глюков, а что первый глюк возникает позже”. Но оно потом это забыло и снова провело ночь минимизируя счетчик глюков.
Это из той же оперы как “если ты услышал что часы на башне пробили 13 раз, то скорее всего неверным является не только 13-й удар колокола, но и 12 предыдущих”. Или если у тебя syntax error в коде на Си в строке 100, то зачем проводить всю ночь пытаясь минимизировать количество syntax errors в последующих строках?
Для тех рекламных агентств кому интересны заморочки с оптимизацией процесса размещения рекламы в интернете для того, чтобы официально не платить рекламный сбор.
Развиваем тему, когда между РД и РА услуговый договор, а между РА и РР агентский, где РА выступает в качестве агента, а принципалом выступает РР - агентство официально не будет платить рекламный сбор. Рекламный сбор в данной классической цепочке (РД-РА-РР) с договором перевертышем (РА-РР) заплатит только РР - самое главное эту схему правильно оформить в ОРД, чтобы ЕРИР начислило сбор только РР.
Данную возможность официально подтвердило ЕРИР (дословно):
По договору оказания услуг РА является исполнителем, но в данном случае сбор на него начисляться не будет. Так как доход, который РА получает от РД, не остается у агентства, а полностью транслируется в сторону РР. Далее РР оплачивает агентскую комиссию агентству, а сумма рекламного бюджета будет отражена в отчете посредника РА-РР. Таким образом, РР будет оплачивать сумму сбора со своего дохода (стоимость рекламного бюджета).
Например: между РД и РА заключен договор оказания услуг на 100 руб., которые РА транслирует в сторону РР, и сбор с РА не взымается. В этой же цепочке между РА и РР заключен посреднический (агентский) договор на 120 руб., из которых сумма рекламного бюджета составляет 100 руб., а 20 рублей - комиссия. В пункте акта (при разаллокации акта) указывается сумма 100 руб., и с нее взимается сбор 3%
Так вот, в принципе, тему перевертыша можно расширить на любое количество посредников в рекламной цепочке.
Например, более сложная цепочка: РД-РА1-РА2-РР
Сорри, рисовать не умею, но, надеюсь, идея понятна)
Договор РД-РА1 услуговый на рекламный бюджет в размере 1000 рублей, который долетит по цепочке до РР.
Как это произойдет?
Договор РА1-РА2 агентский на 1200 рублей, где РА1 является агентом для принципала РА2. По данному договору РА1 перечисляет на счет РА2 те же самые 1000 рублей (рекламный бюджет), которые РА1 получило от РД. А потом РА2 перечисляет вознаграждение на счет РА1 в размере 200 рублей за то, что подкатило рекламный контракт для них. Для этого в акте ОРД должно быть указан договор РД-РА1 в специальном поле. В итоге договор РА1-РА2 типичный перевертыш, когда рекламный бюджет 1000 рублей поступает от агента (РА1) к принципалу (РА2)
Далее еще интересней)
Договор РА2-РР также агентский на 1300 рублей, где РР является для принципалом, а РА2 - агентом, который действует в интересах РР. По данному договору РА2 перечисляет на счет РР те же самые 1000 рублей (рекламный бюджет), которые РА2 получило от РА1. А потом РР перечисляет вознаграждение на счет РА2 в размере 300 рублей за то, что подкатило рекламный контракт для них. Для этого в акте ОРД должно быть указан договор РА1-РА2 в специальном поле. В итоге договор РА2-РР также типичный перевертыш, когда рекламный бюджет 1000 рублей поступает от агента (РА2) к принципалу (РР)
В итоге по данной цепочке РД-РА1-РА2-РР рекламный сбор должен (по идее ЕРИР) заплатить только РР, а для РА1 и РА2 рекламный сбор не должен быть начислен
А рекламный бюджет сквозняком пролетит по всей рекламной цепочке и окажется у РР в размере 1000 рублей, т.е. в том размере как его отправлял РД в начале цепочки.
Чтобы агентствам не платить рекламный сбор нужно постараться все правильно оформить в бухгалтерских документах и самое главное в своих ОРД
