相手が落ちているのか、自分だけか — 3 つの手掛かりで切り分ける
連携が止まった、という連絡が来たとき、最初に決めるのは相手か自分かです。ここを飛ばして設定を触り始めると、相手の障害だった場合に何も直らないまま時間が過ぎます。
手掛かりは 3 つ、順番に見る
| 順 | 手掛かり | 見る場所 | 読めること |
|---|---|---|---|
| 1 | 提供側の申告 | 相手のステータスページ・お知らせ | 相手が障害を認めているか |
| 2 | 外からの観測 | RenkeiMap の稼働状況 | 提供側の申告が無い時間帯に、外から見て応答があるか |
| 3 | 自分のログ | 自分の側の記録 | いつから・どのエラーコードで止まったか |
1 番目の読み方には癖があります。提供側の申告は形が 3 つに分かれ、どれかによって切り分けに使える度合いが変わります。
画面が動いていても、API は落ちていることがある
提供側のステータスページには、API を独立した項目として出すシステムと、出さないシステムがあります。出していない場合、画面を開いて「動いてますね」で終わらせると、API だけ落ちている状態を見逃します。
| 申告の形 | 切り分けに使えるか |
|---|---|
| API を独立した項目で出す | 使える。画面と API を別に読める |
| 専用ページはあるが製品全体で 1 つ | 部分的。その製品のどこが落ちているかは読めない |
| お知らせ・メールだけ | 機械的に監視できない。人が気づくまで分からない |
ステータスページには 2 つの落とし穴もあります。人が更新している（自動連動ではないと先に書いているシステムがある）ので、落ちてから表示までに時間差が出ます。そして別ドメインにあることが多く、本体サイトを探しただけでは「無い」ように見えます。
こう切り分ける — 手順
| 順 | 手順 | こう判定する |
|---|---|---|
| 1 | エラーコードを見る | 429 なら呼び出し回数の上限、401／403 なら認証、無応答なら障害の疑い |
| 2 | 提供側の申告を見る | 障害が出ていれば待つ。ただし表示は遅れうる |
| 3 | 外からの観測を見る | 申告が無くても外から無応答なら、相手側の疑いが強い |
| 4 | 自分のログの「いつから」を合わせる | 自分側の変更（設定・版上げ）と時刻が一致すれば自分の側 |
| 5 | 相手と分かったら記録を残す | 次に同じことが起きたときの判断が速くなる（何回目かが分かる） |
作った後に起きること全体（回数の壁・仕様変更・障害）は 連携を作った後に起きること、失敗したときの作り方は 連携が失敗したときの設計 に置きました。