Генерация новостей из RSS: сквозной процесс
Сквозной процесс — это когда владен каждый шаг: расписание, нормализация, дедуп, скоринг, генерация, медиа, категории WP, публикация, архив.
Разрыв в любом звене даёт либо дубли и мусор, либо тишину. Проектируйте систему так, чтобы можно было ответить, какой элемент ленты породил какой URL и какая версия шаблона была применена.
Опорная схема
На каждом шаге нужны идемпотентные ретраи и алерты.
Между шагами — чёткие контракты данных: если нормализация отдала пустой заголовок, дальше генерация не должна стартовать; если медиа не загрузилось, политика решает — черновик или отложенная публикация.
Расписание
Разносите запросы, соблюдайте лимиты источников.
Частота fetch должна соответствовать характеру ленты: wire — чаще, фоновые блоги — реже. Ночные окна используйте для тяжёлых бэкфиллов, а не для боя с rate limit.
Аудит
Храните неизменяемые копии элементов ленты и выходов модели.
Срок хранения согласуйте с комплаенсом; экспорт в холодное хранилище дешевле бесконечного роста БД.
Наблюдаемость и дежурства
Алерты на тишину ленты, рост очереди, провалы публикации. Ротация дежурных с runbook — иначе инциденты заканчиваются «отключили конвейер до понедельника».
Еженедельный обзор: топ ошибок, посты с ручным вмешательством, аномалии токенов. Тренды важнее разовых пиков.
Стоимость и ёмкость
Считайте стоимость на успешный пост: токены, медиа, человеко-часы сопровождения. При росте объёма сначала оптимизируйте шаблоны и отбор элементов, а не только тариф провайдера.
Планируйте запас по квотам API и CMS на пики новостей — иначе лаг станет заметнее качества.
Идемпотентность подробно
Используйте детерминированные ID черновиков из ID элемента и версии шаблона. Повторная публикация должна либо no-op, либо явно версионироваться — никогда молча перезаписывать без аудита. Клиенты WordPress должны быть транзакционны: черновик, медиа, вложение, публикация — каждый шаг с безопасным ретраем без дублирования постов.
Храните ключи идемпотентности на границе внешних API — тогда ретраи безопасны даже если воркеры не идеально exactly-once.
Модель данных для аудита
Предпочитайте append-only логи решений генерации изменяемым строкам, которые «просто обновили». Неизменяемость делает споры разрешимыми. Если дорого — тируйте в объектное хранилище с политиками жизненного цикла вместо удаления истории.
Каждый опубликованный URL должен ссылаться на bundle ID со всеми входами: байты элемента ленты, выход модели, ручные правки.
Человек в контуре, когда нужен
Проектируйте очереди ревью без блокировки всего конвейера: рискованные темы — в ревью; низкий риск — в поток. Добавьте SLA-таймеры — элементы не должут гнить днями в очереди-свалке.
Меряйте пропускную способность и ошибки ревьюеров; им тоже нужны перерывы и ротация.
Миграции и бэкфиллы
Бэкфилл старой истории RSS может взорвать стоимость и дубли URL. Если бэкфилл неизбежен — волнами, с дедупом против уже опубликованных URL и явными правилами каноникала. Сначала режим «только черновик».
Внутренне коммуницируйте бэкфилл: саппорт и продажи должны понимать, почему вдруг появились старые истории.
Сквозные приёмочные тесты
Перед крупными релизами — полный прогон в staging: fetch → generate → publish → проверка структурированных данных → проверка sitemap. Автоматизируйте что можно; для остального — чеклист с человеческой подписью.
Сохраняйте подписанные отчёты тестов — аудиторам нравятся артефакты.
Финальный мастер-чеклист для печати
Генерация новостей из RSS — цепь; рвётся слабое звено. Распечатайте статью, пройдите цепь по порядку и отметьте риски: расписание, нормализация, дедуп, генерация, медиа, SEO-поля, публикация, архив, мониторинг, контроль затрат, управление. У каждого блока — владелец и тест. Иначе у вас демо, которое ждёт плохой новостной день, чтобы стать инцидентом. Стройте систему.
Приложение: матрица устранения неполадок по полям
Используйте таблицу как карту первой реакции; при совпадении симптома углубляйтесь в логи.
| Симптом | Вероятная причина | С чего проверить |
|---|---|---|
| Посты есть, метаданные неверны | Маппинг полей или дефолты при слиянии на ретрае | Custom fields WP; путь ретрая; теги версии шаблона |
| Дубли то появляются, то нет | Гонки воркеров или разные ключи дедупа по локалям | Сериализация по кластеру источника; блокировки; сравнение ключей |
| Рост стоимости в тихие дни | Буря ретраев, случайный бэкфилл, сбой cron | Число ретраев на элемент; расписание задач; токены по имени job |
| В ленте нормальный HTML, у вас «каша» | Кодировка / двойное кодирование в парсере | Образец в hex; тесты с нелатиницей и сущностями |
Приложение: минимальный набор документации (в репозитории)
Держите: схему архитектуры; политику хранения; список лент с владельцами; changelog шаблонов; runbook дежурного; шаги аварийного восстановления; журнал инцидентов с уроками. Документация — не бюрократия: так переживают смены людей и аудиты.
Если документации короче этой статьи — реальность, скорее всего, не описана.
Приложение: заметка о длине для читателя
Текст длинный специально: RSS-конвейеры ломаются на краевых случаях, а те всплывают на объёме. Используйте распечатку как рабочую тетрадь — свои заметки, allowlist IP, идентификаторы API (в общих копиях — с редактированием), телефоны эскалации. Нужно единое место доверия, когда продакшен ломается в худший момент — и руководство как раз смотрит.
Приложение: таблица ёмкости (заполнять ежеквартально)
Оцените пик элементов в час, которые конвейер прогоняет end-to-end при текущих воркерах, лимитах моделей и пропускной CMS. Сравните с историческими пиками. Если запас головы меньше двадцати процентов — расширяйтесь до предсказуемого всплеска новостей, а не после переполнения очередей.
| Строка | Текущая оценка | Исторический пик | Запас % | Владелец |
|---|---|---|---|---|
| Пик элементов/час (сквозняком) | — | — | — | — |
| Параллелизм воркеров / задач | — | — | — | — |
| Квота модели (RPM/TPM) | — | — | — | — |
| Пропускная способность CMS | — | — | — | — |
Прикладывайте таблицу к обзорам ёмкости: цифры убеждают финансы сильнее «ощущений».