リリースを失わずに失敗した翻訳をトリアージする

多言語リリースにおいて、「失敗」は単一の状態ではありません。

モデルへのリクエストが失敗した可能性があります。翻訳は準備できていても Contentful にプッシュできない場合があります。ローカライズされたエントリは更新済みでも公開されていないことがあります。この3つをすべて1つの赤いステータスにまとめると、ダッシュボードは単純になりますが、復旧作業は難しくなります。

まず失敗したフェーズから始める

翻訳、プッシュ、公開は、それぞれ依存関係の異なる別個の操作です。

翻訳の失敗は、プロバイダーのタイムアウト、無効なモデル応答、または保護されたコンテンツの検証に起因することがあります。プッシュの失敗には、権限、フィールド検証、または Contentful のバージョン競合が関係する場合があります。公開の失敗は、エントリの状態、環境設定、または公開モードを反映している可能性があります。

最初のトリアージフィルターが答えるべきなのは、どのフェーズに対応が必要か、ということです。

それにより、担当者と次のアクションがすぐに絞り込まれます。

影響範囲を示す

失敗したリクエストには、判断を支えるのに十分な識別情報が必要です。

• エントリ名と ID
• ソースロケールとターゲットロケール
• バッチ
• 失敗したフェーズ
• 最新のエラー
• 試行回数と最後の試行時刻
• 後続フェーズが開始されたことがあるかどうか

この文脈がなければ、オペレーターは各リクエストを個別に開いて、手作業でリリースを再構築することになります。

バッチビューでは、部分的な失敗と完全な失敗も区別できるべきです。50ロケール中49が成功したなら、チームは1件のリクエストを復旧しながら、完了した作業を前に進められるべきです。

適切な境界から再試行する

再試行は、失敗したフェーズから再開すべきであり、その前に成功したすべてのフェーズを繰り返すべきではありません。

翻訳が成功してプッシュに失敗した場合は、レビュー済みの翻訳を保持してプッシュを再試行します。Contentful が更新されて公開に失敗した場合は、現在のエントリ状態に対して公開を再試行します。

翻訳からやり直すと、異なるコピーが生成され、レビューが無効になり、コストが増え、元の問題が見えにくくなる可能性があります。

フェーズを認識した再試行は、成功した作業を安定したまま保ちます。

一時的な失敗と恒久的な失敗を分ける

一部の失敗は自動再試行の有力な候補です。

• プロバイダーのタイムアウト
• レート制限
• 短時間のネットワーク中断
• 回復可能なバージョン競合

一方で、人の対応が必要なものもあります。

• 無効なコンテンツ設定
• ロケール有効化の不足
• 権限拒否
• 復元できない保護された構造
• レビュー後に変更されたターゲットフィールド

再試行ポリシーは、上限があり、可視化されているべきです。自動上限に達した後は、そのリクエストは最後に有用だったエラー情報を保ったまま、人間のキューに入るべきです。

失敗リストを軽量に保つ

運用画面は、すでに何かがうまくいっていないときに使われます。各行ごとに CMS の詳細データを深く hydration したり、ページが監視対象のワーカー以上の負荷を生むほど積極的にポーリングしたりするべきではありません。

まず安定したリクエストメタデータを返します。完全なエントリ詳細は、オペレーターがそのリクエストを開いたときにのみ取得します。

高速なフィルタリングは復旧の一部です。

要点

赤いバッジは復旧システムではありません。

フェーズごとに失敗を分離し、影響範囲を示し、失敗した操作だけを再試行します。一時的な復旧は明確な上限の中で自動化し、それ以外については実行可能なエラーを保持します。ワークフローが次の判断を明確にするなら、チームは個別の失敗に耐えられます。