信頼できる実行

自動化は、同じものを2回送信するまで誰も気にかけません

しかし実際に起きれば、全員が気づきます。このページの4つの仕組みが存在するのは、この種のソフトウェアの失敗が常に同じ4つの失敗であり、注意深さではなく設計によってすべて回避できるからです。

公開前にシミュレーション

無効化されたワークフローに実在のレコードを通し、何が起きるはずだったかを正確に読み取れます。通った経路、各ステップでのすべての値、すべてのメッセージの文言、各外部システムに送信されるはずだったリクエストまで。

外部には何も出ていきません。メールは送信されず、請求書は発行されず、課金は試行されず、行は書き込まれません。外部呼び出しは、送信されるはずだったペイロードとともに「意図」として記録されるため、誰かの問題になる前にマッピングが正しいか確認できます。

シミュレーションは、自動化の導入をためらわせるあの問い、すなわち「実際に何が起きるのか？」に答えるための手段です。

シミュレーション · 注文 88,214送信なし

1住所の検証一致しました。6つのフィールドが書かれていたはずです。
?条件1,000 złを超える注文？いいえ — 289,00 zł。短い経路が選択されました。
3請求書請求システムに POST する予定でした。ペイロード全体が表示されています。
!ここで捕捉VAT税率が誤ったフィールドからマッピングされていました。経理担当者の受信箱ではなく、シミュレーションの中で発見されました。

送信：なし請求：なし

各実行は、開始時に入ったバージョンを進みます

ワークフローへの変更の公開は、すでにその中にいる実行には影響しません。各実行は開始時のバージョンに固定され、どれだけ時間がかかっても、その間にどれだけ書き換えても、そのバージョンで完了します。

そのため、1万人が途中にいる最中でもワークフローを再構成でき、全員が約束されたフローを完了できます。代替案 — 入口で下流の経路全体を実体化する設計 — こそ、多くのツールで稼働中のオートメーションの編集が危険に感じられる理由です。ここでは、それが特別なことではありません。

公開した瞬間から、新しい実行は新しいバージョンを取得します。実行がどのバージョンにいるかは実行自体に記録されるため、3月の挙動についての疑問にも9月に答えがあります。

稼働中の編集v4 → v5

1導入前実行中の2,918件、すべてv4上。2日間の待機中のものもあります。
2v5を公開11:402つのステップを入れ替え、1つのメッセージを書き直しました。
3導入後その2,918件はv4で完了します。11:40以降に開始されるすべてはv5で実行されます。
§誰も半分はあるワークフロー、半分は別のワークフローを受け取りません。

すべての実行にバージョンを記録旧バージョンを保持

二重送信できないリトライ

ステップは入力の純粋な関数であり、その効果は、次のステップへの実行自体の進行とともにコミットされます。メッセージは送られたのに実行がそれを知らない、という窓は存在しません。

これが仕組みのすべてであり、約束ではなく構造的な性質です。ステップの途中でワーカーが死んだ場合 — デプロイ、クラッシュ、消失したマシン — 実行は元の場所にそのまま残ります。別のワーカーが引き継ぎ、ステップを再実行します。効果と進行が一体としてコミットされるため、両方か、どちらでもないかのどちらかです。

冪等キーをサポートするシステムへの外向き呼び出しには、実行とステップから導出されたキーが付与され、相手側も再送を認識できます。

送信中にワーカーが死亡復旧

1ステップ5を開始09:14:06出荷通知を送信します。
✕ワーカーが死亡09:14:07デプロイ。何もコミットされていませんでした。
2引き継ぎ09:14:31別のワーカーが、実行がまだステップ5にあることを発見します。
✓1回だけ送信09:14:32お客様には2通ではなく1通のメールが届きました。

効果は進行とともにコミット実行とステップごとの冪等キー

人が読むために書かれたログ

すべての実行、すべてのステップ、選択された分岐とそれを決めた値。ステップごとの所要時間。各外部呼び出しのリクエストとレスポンス（認証情報はマスク済み）。実行が使用していたバージョン。実行が待機している場所とその期限。

14日に注文された注文書がどうなったかと聞かれたとき、答えがあり、それを見つけるのにかかるのは1分です。3つのシステムのログを突き合わせる午後の作業ではありません。

失敗した実行は一箇所に集められ、原因ごとにグループ化されるため、「一晩で41件の失敗」は、41件の個別調査ではなく、「あるサプライヤが9分間 503 を返していた」という1つの結論に収まります。

一晩で、グループ化41件の失敗

11つの原因サプライヤAPIが 02:41 から 02:50 まで 503 を返していました。
2何が起きたか41件すべてが再試行され、39件は2回目の試行で成功しました。
3残ったもの2件が停止し、人の対応を待っています。どちらも、失敗した行とともに一覧に表示されます。
§41件ではなく調査は1件。あとは2件のレコードについての判断だけです。

認証情報はマスク済みバージョンは記録済み

私たちが主張しないこと

マーケティングページにアップタイムの数値を掲載することはありません。測定期間と「稼働」の定義を伴わない数値は、飾りにすぎないからです。契約上必要な場合は、お問い合わせください。実際にコミットできる範囲についてご相談いたします。

また、他人のAPIを信頼できるものにすることはできません。プロバイダがダウンしている場合、それに依存するワークフローは待機し、再試行し、最終的に明確な理由とともに停止します。私たちが約束できるのは、障害が可視化されること、何も破損しないこと、そして再開時にメッセージが二重に送信されないことです。

待機について: 2日間待機している実行は、キューに積まれたジョブではなく、その実行に設定された wake_at です。そのため、ワークフローが10万件の実行を3週間の待機中に保持していても一切のコストがかからず、現在待機中の実行数について考慮する必要がないのです。