自動化が失敗しました: 再試行する前に確認すべきこと

自動化がエラーと表示され、誰かが「再試行」を押すことを提案します。その前に、もっと具体的な質問に答えるべきです。何がまだ完了していないのか？ アクション自体が不足しているのか、その確認が不足しているのか、あるいは後続のステップが不足しているのか。フロー全体を繰り返すことは、これらの状況のうちの一つには役立ちますが、他の状況を悪化させる可能性があります。

創業者や小規模チームにとって、統合を構築した人物が不在であっても調査を続行できる必要があります。このガイドでは、確認済みの事柄と不明な事柄を区別するためのタイムラインとシートを提供します。この例は架空のものであり、Frihetのインシデントを記述したり、実際のサービス、顧客、認証情報を使用したりするものではありません。

画面のエラーと作業の状態

タイムアウトは、待機が時間内に応答なしで終了したことを示します。それだけでは、宛先が何かを保存したかどうかを知ることはできません。AWSはこの問題を説明しています。そこでは、リクエスト元が確認を受け取っていなくても、リソースが作成された可能性があるリクエストについて触れています。この不確実性を解決するには、影響とその発生源を特定する必要があります。

効果が確認済み、効果がないことが確認済み、不明の3つの状態で作業します。「私の画面に表示されない」は、フィルター、別のアカウント、遅延したインデックス、またはまだアクティブな実行の可能性があるため、3番目の状態に属します。また、誰がいつ状態を確認したかも記録してください。観察にはコンテキストがあり、永遠の有効性はありません。

決定を変えるタイムライン

内部タスクを作成し、その参照を追跡シートに記録するフローを仮定します。以下のすべては仮説です。時間は同じシミュレートされた時計を使用します。実際の調査では、各タイムスタンプのタイムゾーンと出所を保持してください。

次のステップは、文書化された手順に従って追跡を回復することです。「タスクの作成」から再開すると、すでに解決済みのものに再度触れることになります。もし最後の行が「シートに表示されない」とだけ書かれていた場合でも、そこに書き込む前に遅延、フィルター、またはアクティブなプロセスを排除する必要があるでしょう。

オペレーション参照は安定していますが、試行識別子は実行ごとに変わります。受信したイベントと作成されたタスクも異なるIDを持ちます。同じ作業の2つの試行と2つの正当な作業を混同しないように、それらの関係を保持してください。

他の人が続けられるシートを保存する

まず、既存の記録を保持し、そのフローに想定されている一時停止メカニズムを使用して新しい書き込みを抑制します。一時停止は実行されたものを元に戻したり、進行中のリクエストを停止させたりする保証はありません。他の誰も行動しないと仮定する前に、キューと保留中の再試行を確認してください。

このシートを適切なアクセス権を持つ内部記録にコピーしてください。共有ドキュメントに秘密や個人情報を貼り付けないように、証拠への参照を使用してください。各修正は、以前の観察を削除せずに日付とともに追記する必要があります。

インシデント: [内部参照]
望ましいオペレーション: [単一の具体的な結果]
プロバイダー / アカウント / 環境: [宛先のコンテキスト]
オペレーション / イベント / 試行: [IDと関係]
フローのバージョン: [実行されたバージョン]
最後に確認されたステップ: [証拠とタイムゾーン付き時刻]
実行結果の状態: [存在を確認済み / 存在しないことを確認済み / 不明]
宛先の証拠: [参照、クエリ、可視性の制限]
まだアクティブな作業: [リクエスト、キュー、保留中の再試行]
再試行の仕様: [ドキュメント、適用範囲、有効期間]
不足しているデータ: [決定に必要な証拠]
次のアクション: [照会または限定された復旧]
責任者 / 次回レビュー: [担当者と日付]
後続の結果: [新しい証拠、以前のものを上書きしない]

「実行結果が存在しないことを確認済み」とするには、検索結果が空だったという以上の証拠が必要です。例えば、処理先の記録から実行前に拒否されたことが分かり、ほかの試行が結果を生んだ可能性も除外できている場合です。その状態を正当化できない場合は、「不明」を維持してください。

べき等性キーには限界がある

具体的なリクエスト、アカウント、環境に関するプロバイダーの契約を確認してください。書き込みを保護するキーは、後続の通知や他のサービスを自動的に保護するものではありません。また、すでにキーなしで送信されたリクエストに遡って追加することもできません。シートは「べき等性がある」とだけ書くのではなく、適用されるドキュメントへのリンクを含むべきです。

Stripeにおいて、べき等なリクエスト — API v1は、500エラーを含む最初の実行の保存された結果を再利用します。Stripeはパラメータを比較し、作成から24時間以上経過したキーを削除することがあります。削除されたキーを再利用すると、別のリクエストが開始されます。Stripeのエラーガイドは、500の後に起こりうる影響について警告しています。キーを変更したり、期限切れを待ったりしても、不確実なアクションを繰り返すのが安全であることを証明するものではありません。

上記の期間はStripeのものです。他の宛先については、独自の期間、重複と見なされるID、および同時リクエストの処理方法を記録してください。リカバリにパラメータの変更が必要な場合は、以前の効果のレビューを含め、新しい決定として扱ってください。

証拠に基づいて、段階的に決定する

以下の表は、提案された運用基準であり、プロバイダーの普遍的なポリシーではありません。データの変更許可から調査を分離してください。

取り消し不能な書き込みや影響の大きい書き込みは、提案されたリカバリについて人間のレビューが必要です。キーも緑色のボタンも、プロセス全体に対して「ちょうど一度」の保証を提供するものではありません。

誰が再試行するかも確認する

自動化ツール、APIクライアント、およびプロバイダーがそれぞれ独自の再試行を持つ場合があります。Stripeのウェブフックでは、手動での再送信は自動再試行をキャンセルしません。さらに、イベントが重複したり、順序が入れ替わって到着したりする可能性があります。イベントを再送信することは、APIの書き込みをべき等的に繰り返すこととは異なり、異なるメカニズムです。

シートを閉じる前に、宛先の現在の状態、保留中のステップ、およびその後到着する可能性のある試行を確認してください。次の実行を誰が監視するかを定義します。シートを閉じることが作業を解決することではありません。不明な結果が残っている場合は、担当者とレビュー日を設定してインシデントを開いたままにしてください。

その後、不要な作業の削減、自動化、委任の順序（英語）の基準に従って、フローが自動化され続ける価値があるかをレビューできます。Frihetを接続する場合は、対応するインターフェースを見つけるために、開発者向けドキュメントと連携カタログを参照してください。このシートをフローと一緒に保管してください。次に担当する人が、チャットから再構築することなく、最後に確認された状態を見つけられるようにするためです。

技術的な情報源は2026年9月14日に参照されました。シート、決定、およびDEMO参照は、教育目的の提案であり、実際のサービスに変更を実行するための指示ではありません。