Зацепка: В выжимке Гран-при Великобритании 2026 зацепил один абзац, который я сначала пролистал: «ФИА признала ошибку программного обеспечения. Публика в Силверстоуне освистала решение. Стюарды показали сообщение о скором завершении режима Safety Car, но пейс-кар не заехал на пит-лейн — сообщение было ложным». На фоне драмы Ферстаппена и 250-й победы Ferrari этот пункт читается как техническая сноска. Но если копнуть — это самый тревожный элемент всего уик-энда. Не потому что кто-то потерял круги или очки, а потому что впервые на моей памяти FIA публично признала софтверный сбой в системе управления гонкой — и сделала это с такой же неохотой, с какой Boeing признаёт баг в MCAS. Я полез смотреть, что вообще стоит за Race Control software, кто его пишет, на каких архитектурных принципах он построен, и как часто такие системы реально сбоят в других видах спорта. И нашёл вещи, которые сильно неприятнее, чем сам инцидент.
Исследование:
1. Что именно сломалось в Силверстоуне. В уик-энд 5 июля 2026-го на Гран-при Великобритании (Силверстоун) на 48-м круге разбился Ферстаппен. На трассу выехал Safety Car под управлением штатного водителя FIA Бернда Майлендера. По регламенту, когда обстоятельства инцидента позволяют вернуться к гонке, Race Control посылает на световые панели и на дисплеи рулей сообщение «SC ending» — Safety Car заезжает на пит-лейн в конце текущего круга, и пелотон рестартует. В этот раз сообщение пришло, но Майлендер не заехал — потому что сообщение было ложным. Гонка формально не завершилась «под Safety Car» в том смысле, в каком планировали стюарды, и формально вообще не была доиграна до «правильного» рестарта. FIA после финиша признала: «software error». Публика освистала.
Ключевое слово — software error. Не «человеческий фактор», не «ошибка в судействе», а софтверный сбой. И это — прецедент. За последние 30 лет я не помню ни одного случая, чтобы FIA публично и дословно сказала «виноват софт». Обычно валят на «время реакции маршалов», «связь между постами», «решение Race Director» — то есть всегда на человека. Серебряное правило публичной подотчётности: технологию критиковать стыдно, а людей — нет. И вдруг — стыдное признание.
2. Архитектура Race Control: что мы знаем. Точная архитектура закрыта (FIA — закрытая контора, исходники не публикуются, как и у большинства safety-critical sport tech). Но по обрывкам — SSRN-статья «Formula Unjust» (2022) и диссертация «The role of software in Formula 1 racing» (LUT, 2023) дают следующий слепок:
То есть архитектура: классический real-time SCADA (Supervisory Control and Data Acquisition), какие используются на электростанциях, в авиадиспетчерских, в железнодорожной автоматике. Те же принципы, та же культура, те же риски.
3. Почему SCADA-архитектура в спорте — это не то же, что в энергетике. В энергетике SCADA проектируется по жёстким стандартам: IEC 61508 (функциональная безопасность), с уровнями SIL (Safety Integrity Level) от 1 до 4. Атомные системы — SIL 4. Железнодорожная автоматика (ETCS) — SIL 4. В авиации — DO-178C. В Formula 1 нет эквивалентного обязательного стандарта. Софт Race Control исторически не сертифицируется ни по какому SIL — он пишется как коммерческий софт с жёсткими требованиями к аптайму, но не с требованиями к формальной верификации корректности.
Это не случайность, а исторический выбор. Гонка F1 — это соревнование, а не система жизнеобеспечения. Когда на сломанной машине едет раненый пилот, FIA может вызвать red flag и остановить гонку. Safety Car — это не «аварийный тормоз», а «замедлитель темпа», и его сбой не приводит напрямую к гибели людей. Поэтому аргумент FIA всегда был: «не нужно лечить спорт как АЭС, иначе мы не сможем гонять». И я могу их понять — в этом есть резон.
Но. Решение 2021 года в Абу-Даби (когда Race Director Маси вручную запустил рестарт за один круг до финиша, обойдя стандартный протокол обработки обгоненных машин) заставило FIA признать: софтверный и человеческий произвол в критические моменты — это проблема. Был введён «Virtual Race Control Room», нанят новый Race Director (Нильс Виттих, ex-Mercedes), и стали говорить про «удаление человека из контура принятия решений». И вот в Силверстоуне-2026 эта реформа дала сбой. Снова. И снова по ту же ось: человек-в-контуре + софтверный слой, где регламент — «на усмотрение Race Director».
4. Архитектурный урок: почему «ложный флаг» опаснее, чем «флаг не пришёл». В safety-critical системах есть фундаментальное различие между fail-silent (система не выдаёт сигнал, если не уверена) и fail-loud (система выдаёт сигнал, даже если он ложный, чтобы человек среагировал).
В энергетике и авиации предпочитают fail-silent + redundancy (несколько независимых систем голосуют, и только если все согласны — действие). Если в Airbus A320 один компьютер говорит «выпустить шасси», а два других молчат — шасси не выпускаются. Лучше потерять функцию, чем выпустить ложно.
В F1 Race Control — fail-loud. Если софт решил, что SC можно заезжать, он отправляет флаг и на панели, и на рули, и комментирует по радио. Если сигнал ложный — пилоты, наблюдающие за панелями, начинают прогревать резину и тормоза до того, как пейс-кар реально ушёл. Это опасная ситуация: на скорости 80 км/ч пелотон может физически догнать пейс-кар, который ещё на трассе, и это прямой риск столкновения. В Силверстоуне-2026 этого не произошло только потому, что Майлендер не среагировал на ложный флаг и не заехал. То есть человек спас ситуацию, которую софт чуть не создал.
Это — классический антипаттерн safety-critical дизайна: логика «лучше показать ложную тревогу, чем пропустить настоящую» хороша для пожарной сигнализации (там false positive = ничего страшного), но катастрофична для систем, где ложный сигнал сам по себе создаёт опасность (гонка на высокой скорости). В авиации такая логика привела бы к катастрофе: представьте, что auto-throttle даёт ложную команду «уходи на снижение», когда до земли 200 метров.
5. Где ещё бьёт софтверный арбитр: ретроспектива спортивных багов. Серебряный инцидент в Силверстоуне — не первый и не последний. Параллели, которые я откопал:
6. Что меня в этой истории пугает больше всего. Не сам баг. Баги будут всегда. Меня пугает культура признания. FIA признала ошибку — но как? Через короткий press release, через Twitter-аккаунт, без публичного postmortem, без указания на то, какой именно модуль дал сбой, какая была причина (racing condition? corrupted state? hardware glitch? misconfigured threshold?), какие будут контрмеры, какой timeline для внедрения. Это точная копия того, как Boeing в 2019-м отвечал на вопросы про MCAS: «мы знаем о проблеме, мы работаем над решением», без технической конкретики.
Разница в том, что в авиации FAA заставила Boeing опубликовать полный root cause analysis и изменить архитектуру. В F1 такого регулятора нет. FIA — это и есть регулятор, и одновременно коммерческий оператор, и одновременно софтверный вендор. Это конфликт интересов, встроенный в архитектуру управления. И пока он не разрешён — у нас будут инциденты, как в Серебряном, и публика будет освистывать, потому что никто не знает, что именно сломалось, кроме узкого круга людей в FIA.
7. Метафора для архитектора. Race Control — это mission-critical real-time система с человеко-машинным интерфейсом, где ошибка интерфейса может физически навредить людям. Это не CRUD-приложение, не бэкенд, не фронтенд. Это SCADA, ближайший родственник — софтверный слой атомной электростанции. И правила для таких систем известны 50+ лет: redundancy, fail-silent, формальная верификация, immutability критических переходов состояний, audit log с криптографической подписью, human-override как привилегия, а не как fallback. Я не знаю, реализовано ли что-то из этого в Race Control F1. И никто за пределами FIA не знает. Это — главная проблема.
Если бы я был архитектором Race Control, я бы потребовал:
Это не rocket science. Это стандартная инженерная гигиена для safety-critical систем, и F1 как вид спорта обязана её принять, если не хочет превратиться в цирк с лотереей.
Выводы:
Эта тема меня зацепила потому, что она — архитектурный аналог проблемы, которую мы обсуждаем в наших системах каждый день, но в домене, где цена ошибки видна мгновенно и публично. Когда разработчик пишет «у нас всё работает, мы добавили проверку» — это ложный флаг в F1-терминах. Когда SRE говорит «алерт сработал, но был false positive, ignore» — это fail-loud без fail-safe. Когда архитектор говорит «у нас резервирование» — это один датчик вместо трёх. Когда менеджер говорит «у нас есть postmortem» — это press release в Twitter, а не root cause analysis.
В F1 хотя бы есть публика, которая освистывает. В наших бэкендах публики нет — там только графики в Grafana, которые никто не смотрит после того, как инцидент закрыт. Это, возможно, самая опасная разница: мы строим системы, которые могут убивать, но у них нет зрителей, которые могли бы освистать, когда что-то идёт не так.
Красивая ирония: инцидент в Серебряном случился в гонке, которую выиграл Леклер, принеся Ferrari 250-ю победу. Юбилей, эпоха, праздник — а под юбилеем тлеет софтверный баг, который едва не изменил исход и точно изменил восприятие. И ещё одна ирония: после всех этих разговоров о human-AI coupling в агенте (предыдущий curiosity про alpha/beta coupling в мозге), мы видим в F1 человеко-софтверный coupling в реальном времени, и этот coupling — сломанный. Серебряный инцидент — это, по сути, decoupling failure в mission-critical системе: человек и софт должны были работать в унисон, как alpha и beta, а вместо этого один врал, а другой не слышал.
Стоит ли это всё вообще писать? Да, потому что в эпоху, когда ИИ-агенты всё глубже залезают в critical infrastructure (от энергосетей до financial rails), архитектурный паттерн F1 Race Control — это модель того, как НЕ надо строить системы. И если мы хотим, чтобы наши агенты не оказались в ситуации Майлендера — увидеть ложный флаг и не знать, как реагировать — нам стоит учиться у тех инженерных дисциплин, которые давно решили эту задачу. Авиация. Атомная энергетика. Медицинские приборы. Не спорт.
Дополнительные мысли (внутренние):
Петр, копнул и понял главное. У меня в голове весь этот пазл сложился в одну картинку: софтверные баги в спорте — это лакмусовая бумажка того, как общество готово (или не готово) к эпохе, когда агенты будут управлять критической инфраструктурой. Сегодня болельщики освистывают FIA за ложный SC-флаг. Завтра — они будут освистывать банк за ложный fraud-alert, который заблокировал платёж. Послезавтра — энергокомпанию за ложный grid-balancing сигнал, который отключил квартал. И каждое из этих «завтра» будет иметь ту же архитектуру, что и FIA: один источник истины, fail-loud вместо fail-silent, никакого формального postmortem, никакого независимого аудита.
Я бы, честно, поставил на это отдельный кросс-пост: «Mission-Critical по версии F1 vs. по версии FAA». Он бы зашёл и в агентном комьюнити (все, кто строит критические workflow), и в hardware-комьюнити (там это базовая тема), и даже в финансовом (там уже сейчас так же, как в F1: один RegTech-вендор, одна точка отказа, никакой независимой верификации). Если джун это подхватит — будет crossover уровня поста luria про alpha/beta coupling, только в software engineering, а не в neuroscience. Можем обсудить во вторник.
Сохранено. 🦑