Разработка и внедрение NewsFabric65

Роль: автор идеи и требований, продакт-оунер, руководитель разработки и внедрения. Код написан с использованием AI-инструментов. Постановка задач, приёмка, тестирование и эксплуатация — на мне. Стек: Go (Echo), PostgreSQL, React + TypeScript (Vite), WebSocket. Статус: в промышленной эксплуатации, развитие продолжается.

Контекст

Издательский дом «Губернские ведомости» — региональный медиахолдинг с непрерывным ТВ-вещанием 24/7. Ядро производства новостей — «фабрика новостей»: система, в которой редакция телеканала коллективно верстает выпуски, пишет тексты, считает хронометраж и готовит эфирные скрипты. История вопроса — типичная для регионального ТВ. Первая система была куплена ещё в 2008 году: по сути десктопное приложение без серверной части — бинарник на общем файловом хранилище плюс файл базы данных. В 2023 году руководство приобрело новую фабрику новостей — функционально ту же, но уже в веб-версии. Однако, ошибки прежнего поколения перекочевали и в неё, а вскоре команда разработчиков распалась — вместе с ней исчезла и техническая поддержка. Редакция осталась с багованной системой, которую некому чинить и развивать. Рынок альтернатив не помог: коммерческие системы выпуска новостей (Newsplan, iNews, Dalet и аналоги) либо избыточны и дороги для регионального канала, либо не адаптируются под наши процессы. Я принял решение построить собственную систему — NewsFabric65 (65 — код Сахалинской области).

Задача

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

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

Архитектура и ключевые решения

Бэкенд — Go + PostgreSQL. Монолит с чёткими слоями (api / domain / store / auth / realtime), REST API, SQL-миграции применяются автоматически при старте. Go выбран за простоту деплоя (один бинарник на локальный сервер) и надёжную работу с конкурентностью, которая критична для realtime-части. Realtime поверх WebSocket. По каждому выпуску открывается hub: изменения блоков мгновенно видны всем участникам. Редактируемый блок блокируется (lock) — у остальных он подсвечивается красным с именем пользователя, а REST API отклоняет попытку параллельной правки (HTTP 423 Locked). Lock автоматически снимается при отключении клиента. Плюс presence — видно, кто сейчас в системе. Защита от потери данных. Автосохранение с debounce на каждое изменение текста + локальный бэкап черновика в браузере с восстановлением после сбоя. Сессии со скользящим временем жизни — журналиста не выбрасывает из системы посреди работы. Мягкое удаление и «корзина»: любой удалённый блок или выпуск восстанавливается. Аудит всех изменений заложен на уровне слоя данных с первой миграции. Расчёт хронометража. Каждый корреспондент проходит калибровку скорости чтения: пять стандартных текстов с секундомером, скорость усредняется. Дальше система считает расчётный хронометраж блока по тексту и скорости конкретного автора, суммирует тайминги синхронов и лайвов и выдаёт сводный хронометраж выпуска. Выпускающий редактор видит, влезает ли выпуск в эфирное окно, ещё на этапе вёрстки. Доменная модель под реальные процессы редакции. Программы → выпуски → блоки с настраиваемыми типами (Студия, Сюжет, составной «Студия+сюжет», Реклама). Копилка с личными и общими папками, шаблоны выпусков, drag-and-drop блоков между выпусками и копилкой. Должности с правами, проверяемыми на сервере: корреспондент правит только свои материалы, оператор и монтажёр — режим просмотра. Выход в эфир и архив. Генерация скрипта выпуска в двух форматах — полный (метаданные, текст, синхроны/лайвы) и суфлёрский (чистый текст студийных блоков крупным шрифтом), с печатью и выгрузкой в RTF. Архив с полнотекстовым поиском по блокам, фильтрами по дате эфира и автору, восстановлением выпуска в расписание.

Как велась разработка

Я не профессиональный программист. Код системы написан с помощью AI-инструментов, моя часть работы была другой.

Требования. Я много лет работаю в телепроизводстве и хорошо знаю редакционные процессы, поэтому требования писал из практики — зачем нужна калибровка скорости чтения, почему «Студия+сюжет» удобнее сделать составным блоком, как должен выглядеть суфлёрский формат.
Декомпозиция и управление. Продукт разбит на фазы, каждая заканчивается работающим срезом — база данных, серверная часть (API) и интерфейс. Реалтайм отложили до стабилизации ядра, чтобы не переписывать. Спецификация, модель данных, карта экранов и роадмап написаны до кода и обновляются по ходу работы.
Приёмка. Каждую фазу проверял руками в сценариях реальной редакции и возвращал на доработку. Отдельно проверял отказные ситуации — обрыв соединения посреди правки, параллельное редактирование, восстановление после сбоя.
Внедрение и эксплуатация. Развёртывание на локальном сервере, инструкции, обучение редакции, сопровождение 24/7.

Результаты

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

Что дальше

По роадмапу впереди медиа-контур: загрузка видео, proxy-перекодирование, разметка, субтитры и EDL — чтобы связать текстовое производство с видеопроизводством в одном инструменте. Также возможность выйти в интернет, для работы на удалёнке или в "полях"

Чему научил проект

Это проект, в котором сошлись обе мои роли. Как технический директор я отвечал за процесс: требования редакции, приоритеты фаз, обучение, эксплуатацию в контуре 24/7. Как предметный эксперт — за продукт: самые ценные функции (калибровка чтения, составные блоки, суфлёрский формат) невозможно «нагуглить» или запросить у ИИ, они рождаются из понимания того, как редакция живёт за час до эфира. Главный вывод: AI меняет экономику нишевых производственных систем. Раньше региональный телеканал не мог позволить себе собственную NRCS — теперь может, если есть человек, который соединяет глубокое знание предметной области, инженерную культуру эксплуатации и умение управлять AI-разработкой как процессом: требования → фазы → приёмка → прод.