릴리스를 놓치지 않고 실패한 번역 분류하기

다국어 릴리스에서 "실패"는 하나의 상태가 아닙니다.

모델 요청이 실패했을 수 있습니다. 번역은 준비되었지만 Contentful에 푸시할 수 없을 수 있습니다. 현지화된 항목은 업데이트되었지만 게시되지 않았을 수 있습니다. 이 세 가지를 모두 하나의 빨간 상태로 묶으면 대시보드는 더 단순해지지만 복구 작업은 더 어려워집니다.

실패한 단계부터 시작하세요

번역, 푸시, 게시는 서로 다른 의존성을 가진 별개의 작업입니다.

번역 실패는 제공업체 타임아웃, 잘못된 모델 응답, 또는 보호된 콘텐츠 검증에서 비롯될 수 있습니다. 푸시 실패는 권한, 필드 검증, 또는 Contentful 버전 충돌과 관련될 수 있습니다. 게시 실패는 항목 상태, 환경 설정, 또는 게시 모드를 반영할 수 있습니다.

첫 번째 분류 필터는 다음에 답해야 합니다. 어떤 단계에 주의가 필요한가?

이렇게 하면 담당 범위와 다음 단계가 즉시 좁혀집니다.

영향 범위를 보여주세요

실패한 요청에는 의사결정을 지원할 수 있을 만큼 충분한 식별 정보가 필요합니다.

• 항목 이름 및 ID
• 소스 및 대상 로캘
• 배치
• 실패한 단계
• 가장 최근 오류
• 시도 횟수 및 마지막 시도 시간
• 이후 단계가 시작된 적이 있는지 여부

이런 맥락이 없으면 운영자는 각 요청을 개별적으로 열고 릴리스를 수작업으로 재구성해야 합니다.

배치 보기는 부분 실패와 전체 실패도 구분해야 합니다. 50개 로캘 중 49개가 성공했다면, 팀은 하나의 요청을 복구하는 동안 완료된 작업으로 계속 진행할 수 있어야 합니다.

올바른 경계에서 재시도하세요

재시도는 실패한 단계를 재개해야 하며, 그 이전의 모든 성공한 단계를 반복하면 안 됩니다.

번역이 성공했고 푸시가 실패했다면, 검토된 번역을 보존하고 푸시를 재시도하세요. Contentful이 업데이트되었고 게시가 실패했다면, 현재 항목 상태를 기준으로 게시를 재시도하세요.

번역부터 다시 시작하면 다른 문구가 생성되고, 검토가 무효화되며, 비용이 증가하고, 원래 문제를 가릴 수 있습니다.

단계를 인식하는 재시도는 성공한 작업을 안정적으로 유지합니다.

일시적 실패와 영구적 실패를 분리하세요

일부 실패는 자동 재시도의 좋은 후보입니다.

• 제공업체 타임아웃
• 속도 제한
• 짧은 네트워크 중단
• 복구 가능한 버전 충돌

다른 경우에는 사람이 필요합니다.

• 잘못된 콘텐츠 구성
• 누락된 로캘 활성화
• 권한 거부
• 복구할 수 없는 보호된 구조
• 검토 후 변경된 대상 필드

재시도 정책은 제한적이어야 하며 가시적이어야 합니다. 자동 한도에 도달하면, 해당 요청은 마지막으로 유용한 오류를 그대로 유지한 채 사람의 큐로 넘어가야 합니다.

실패 목록을 가볍게 유지하세요

운영 화면은 이미 문제가 발생한 상황에서 사용됩니다. 모든 행에 대해 깊은 CMS 하이드레이션을 유발하거나, 페이지가 모니터링하는 워커보다 더 많은 부하를 만들 정도로 공격적으로 폴링해서는 안 됩니다.

먼저 안정적인 요청 메타데이터를 반환하세요. 운영자가 요청을 열었을 때만 전체 항목 세부 정보를 가져오세요.

빠른 필터링은 복구의 일부입니다.

핵심 요점

빨간 배지는 복구 시스템이 아닙니다.

실패를 단계별로 분리하고, 영향을 받은 범위를 보여주며, 실패한 작업만 재시도하세요. 명확한 한도 내에서 일시적 복구는 자동화하고, 그 외의 모든 경우에는 조치 가능한 오류를 보존하세요. 워크플로가 다음 결정을 분명하게 만들어 준다면 팀은 개별 실패를 감당할 수 있습니다.