Т-Такси | Система управления беспилотным флотом

1. Контекст

Т-Такси — концепт внутреннего инструмента для центра мониторинга беспилотных такси. Это рабочее место дежурного инженера: десктоп, тёмная тема, смены 24/7 и постоянный поток событий от машин.

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

Пользователи

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

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

Что считается успехом

• Для бизнеса — выше uptime флота, ниже стоимость обработки инцидента, больше машин на одного оператора (масштабируемость), безопаснее.
  • Операционные метрики: MTTA, MTTR, доля инцидентов, решённых удалённо, false positive rate алертов.
• Для пользователя — спокойная смена без пропущенных критичных событий: быстро понять, что происходит, что важно прямо сейчас и какое действие следующее.

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

2. Ограничения и скоуп

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

• триаж инцидентов — очередь, карта, приоритеты и фильтры;
• разрешение инцидента — карточка с контекстом машины, симптомами и действиями.

Что показало исследование

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

Перегруз сигналами

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

Один инженер — десятки машин

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

• Waymo — около 1:43
• Cruise — около 1:15–20
• Китайские операторы — около 1:3

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

Базовый паттерн Fleet Ops

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

Критичность и жизненный цикл

В управлении инцидентами важно сразу видеть приоритет и статус. Я использую P1–P4 и жизненный цикл:

1. новый
2. принят
3. в работе
4. отложен
5. разрешён

Заряд и доступность флота

Для электрофлота нужен двухуровневый показ SoC (state of charge): на уровне флота — общий донат или тепловая карта, на уровне машины — точный процент заряда и остаточный пробег. Это помогает понять не только проблему одной машины, но и состояние смены целиком.

4. Допущения

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

5. Сценарии смены

Главная работа пользователя

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

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

6. Приоритизация

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

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

7. Problem statements

Три проблемы, которые решает дизайн в этой итерации — по одной на приоритетную подработу.

1. Триаж. Дежурный инженер не справляется с триажом очереди за 60–90 секунд, потому что алерты приходят сырым потоком без дедупликации и без явных уровней критичности. Это приводит к пропущенным P1 и просрочкам SLA.
2. Резолюция. Инженер не успевает принять решение по инциденту за 2–3 минуты, потому что нужный контекст разнесён между телеметрией, системой алертов, историей инцидентов и чатом с командой. Это приводит к ложным вызовам бригад или к опозданию там, где нужна реальная помощь.
3. Параллельные события. Инженер теряет либо новый P1 (нужен ответ за 30 секунд), либо контекст текущего разбора, когда работа с одним инцидентом закрывает обзор очереди. Это удваивает время по разбираемому инциденту и создаёт риск пропустить критичное.

8. Решение

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

Объектная модель

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

Экран мониторинга

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

Инцидент вместо потока сигналов. Если сгруппировать сырые сигналы в инциденты, инженер быстрее разбирает очередь и реже теряет критичные события. Алерт остаётся событием от машины, а в очередь попадает инцидент: потеря связи, низкий заряд, код неисправности и повторные сигналы от одной машины сходятся в один объект с симптомами, приоритетом и статусом. В пик это сжимает очередь в 5–10× — инженер работает с одной проблемой, а не с двадцатью строками дублей.

Критичность видна везде одинаково. Если критичность не зависит от выделения строки, фильтров и прокрутки, инженер реже пропустит P1 во время параллельной работы. Уровень P1–P4 кодируется отдельным визуальным слоем: полоса в очереди не исчезает при выделении, сортировка идёт P1→P4, новый P1 пробивает активные фильтры, на карте инцидент получает кольцо критичности, а в карточке приоритет закреплён в шапке. Это один сквозной сигнал severity через очередь, карту и карточку — текущий фокус оператора не должен перекрывать safety-событие.

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

Мониторинг парка на карте

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

Наведите на области экрана или запустите пошаговый разбор.

Разобрать экран

Назад Далее

Наведите — обводка сразу, превью следом. Клик — пошаговый разбор. ← → двигают рамку между шагами · клик по экрану / Esc — выход

Карточка инцидента

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

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

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

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

Разобрать карточку

Назад Далее

Наведите — превью зоны. Клик по зоне или кнопке — пошаговый разбор. ← → шаги · Esc — выход

9. Trade-offs

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

Боковая панель vs модалка. Рассматривал модалку с overlay и боковую панель. Выбрал панель, потому что NOC — multi-tasking-контекст, а не линейный wizard: пока инженер разбирает один инцидент, может появиться новый P1. Теряю немного места под карточку. Это ок — видимость очереди и карты критичнее ширины карточки: пропущенный параллельный P1 дороже, чем тесная панель.

P1–P4 vs P1–P5. Рассматривал 5 уровней критичности (как у PagerDuty) и 4. Выбрал 4, потому что каждый уровень должен однозначно маппиться на класс реакции: P1 — немедленно / safety, P2 — срочно, P3 — можно отложить, P4 — информационный. Теряю гранулярность. Это ок — пятый уровень размывает границу между соседними и замедляет решение «что брать первым», а именно скорость этого решения и есть суть триажа.

Snooze как статус vs скрытый флаг. Рассматривал snooze как флаг (просто прячем строку) и как полноценный статус в жизненном цикле с полем snoozedUntil. Выбрал статус. Теряю — чуть более сложная модель данных. Это ок — флаг перекладывает задачу «не забыть» обратно на оператора, а статус с таймером возвращает инцидент в очередь сам. Плюс это стандартный паттерн Datadog / PagerDuty.

10. Как я бы мерил успех

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

Метрика Alert → Incident меряет сам механизм: сырые алерты никуда не делись, они по-прежнему приходят от машин на вход — я убрал их только из очереди как отдельные строки. Соотношение «сырые алерты → инциденты» показывает, насколько эффективно сжатие.

Эти метрики — ведущие индикаторы. Операционные метрики смены (MTTA, MTTR, доля инцидентов, решённых удалённо, false positive rate, fleet uptime) — то, во что они должны сконвертироваться, если гипотезы верны. Их мерил бы на пилоте как результирующий слой, не привязывая к одному конкретному решению.

11. Что дальше

Следующая итерация — про проверку на реальных сменах: интервью с операторами и разбор логов прошлых инцидентов (где теряется время, какие алерты дублируются, какие действия выбирают неправильно, как передают контекст между сменами). Это закрывает допущения из раздела 4 и даёт baseline для метрик из раздела 10.

Дальше можно углублять продукт:

• heatmap по заряду и доступности флота;
• полноценный экран передачи смены;
• временную эскалацию при потере связи;
• состояния empty / hover / active / error для всех контролов;
• отдельную поверхность для старшего смены.