Сортировка неудачных переводов без срыва релиза

В многоязычном релизе «сбой» — это не одно состояние.

Запрос к модели мог завершиться неудачей. Перевод может быть готов, но его невозможно отправить в Contentful. Локализованная запись может быть обновлена, но не опубликована. Если объединить все три случая под одним красным статусом, панель управления станет проще, а восстановление — сложнее.

Начинайте со сбойного этапа

Перевод, отправка и публикация — это отдельные операции с разными зависимостями.

Сбой перевода может быть вызван тайм-аутом провайдера, недопустимым ответом модели или валидацией защищенного контента. Сбой отправки может быть связан с правами доступа, валидацией полей или конфликтом версий в Contentful. Сбой публикации может отражать состояние записи, конфигурацию окружения или режим публикации.

Первый фильтр при разборе должен отвечать на вопрос: какой этап требует внимания?

Это сразу сужает круг ответственных и следующие шаги.

Показывайте масштаб влияния

Неудавшемуся запросу нужно достаточно идентифицирующих данных, чтобы поддержать принятие решения:

• имя записи и ID
• исходная и целевая локаль
• пакет
• этап сбоя
• последняя ошибка
• количество попыток и время последней попытки
• запускались ли вообще последующие этапы

Без этого контекста операторам приходится открывать каждый запрос по отдельности и вручную восстанавливать картину релиза.

Представление по пакету также должно различать частичный сбой и полный сбой. Если 49 из 50 локалей выполнены успешно, команда должна иметь возможность двигаться дальше с завершенной работой, параллельно восстанавливая один запрос.

Повторяйте с правильной границы

Повторная попытка должна возобновлять сбойный этап, а не повторять все успешные этапы до него.

Если перевод выполнен успешно, а отправка завершилась сбоем, сохраните проверенный перевод и повторите отправку. Если Contentful был обновлен, а публикация завершилась сбоем, повторите публикацию с учетом текущего состояния записи.

Перезапуск с этапа перевода может привести к другому тексту, аннулировать ревью, увеличить стоимость и скрыть исходную проблему.

Повторные попытки с учетом этапов сохраняют стабильность успешно выполненной работы.

Разделяйте временные и постоянные сбои

Некоторые сбои хорошо подходят для автоматического повтора:

• тайм-ауты провайдера
• ограничения по частоте запросов
• кратковременные сетевые сбои
• устранимые конфликты версий

Другие требуют участия человека:

• недопустимая конфигурация контента
• отсутствие включения локали
• отказ в доступе
• защищенная структура, которую невозможно восстановить
• целевое поле изменилось после ревью

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

Делайте список сбоев легковесным

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

Сначала возвращайте стабильные метаданные запроса. Полные сведения о записи загружайте только тогда, когда оператор открывает запрос.

Быстрая фильтрация — часть восстановления.

Главное

Красный индикатор — это не система восстановления.

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