連携が失敗したときの設計 — 4 つの作り方と、誰が気づくか
連携は必ず失敗します。失敗したときに何が起きるかを決めていないと、止まったまま誰も気づかない、という一番まずい形になります。
失敗の種類は 4 つ
種類が違えば、直す人も直し方も違います。まず切り分けます。
| 種類 | 症状 | どこを見るか |
|---|---|---|
| 呼び出し回数の上限 | 429 が返る。特定の時間帯だけ落ちる |
調査記録の「レート制限」欄 |
| 相手の仕様変更 | 昨日まで動いていた項目が消えた、旧版が止まった | 調査記録の「仕様変更の告知」欄 |
| 相手の障害 | 何も返らない、時々返る | 相手のステータスページと稼働状況 |
| データの食い違い | 通信は成功、中身が入らない | 項目の対応表（データ変換） |
上の 2 つは相手の設計で決まっていて、こちらでは変えられません。読む場所だけ決めておけば、当たったときに原因の特定で悩まずに済みます。
こちらの仕組みの作り方は 4 つ
エラーが返ったあと、こちらの仕組みが何をするか。作り方は 4 つです。
| 作り方 | 起きること | 向くところ |
|---|---|---|
| 何もしない | 止まったまま。誰も気づかない | どこにも向かない。これを選ばない |
| すぐ再試行する | 上限に当たっている場合は、さらに叩いて悪化する | 一時的な通信の揺れだけ |
| 待って再試行する | 時間の枠が戻れば通る | 上限・一時的な障害 |
| 待って再試行し、記録して知らせる | 通らなければ人に渡る | すべての種類。既定はこれ |
4 番目を既定にしてください。 再試行の回数と間隔、そして「何回失敗したら人に知らせるか」を決めておけば、止まったことに気づけます。
こう直す — 手順
| 順 | 手順 | こう判定する |
|---|---|---|
| 1 | 症状から種類を切り分ける（「失敗の種類は 4 つ」の表） | 429 なら上限、無応答なら障害、中身が空なら食い違い |
| 2 | 相手の側か自分の側かを確かめる | 相手のステータスページと外部からの観測を並べる（ステータスページ） |
| 3 | 直す人を決める | 上限・障害は待つ／設計を変える。仕様変更は作った人。食い違いは対応表を持つ人 |
| 4 | 同じ失敗で次も止まるかを見る | 止まるなら「こちらの仕組みの作り方は 4 つ」の 4 番目に変える |
| 5 | 気づく経路を 1 つ確保する | 通知先が個人のメールだけなら、担当が変わった日に切れる |
作った後に起きること全体（回数の壁・仕様変更・障害）は 連携を作った後に起きること、止まるか進むかの既定は 自動化が壊れた日に何が出るか に置きました。