総合トリアージ: 決済API障害

目標

3つの欠陥が重なった障害を層ごとに絞り込んで原因を特定し、直し、決まった形式のポストモーテム報告書を残します。このコースで学んだすべてのツールを一度に使います。

なぜ重要なのか

実際の障害は、原因が1つとは限らないことが多いです。1つを直して「直らない」と方向を変えると、すでに直したものまで疑うことになります。そのため、各層を最後まで確認し、見つけたものをすべて書き留めておくほうが、結局は早く済みます。そして直したあとは、失敗を再現したそのコマンドで成功を確認して、初めて対処が完了します。

ステップ

bash /opt/fixtures/nt-triage/start-incident.shで障害状況を再現し、/opt/fixtures/nt-triage/incident.mdを読んでください。/root/triageディレクトリを作成してください。
自分のインターフェースのIPに3回pingした結果を/root/triage/l3.txtに保存してください。損失が0%である必要があります。
自分のインターフェースのIPの9101ポートと9102ポートをそれぞれ叩いてみて、結果を/root/triage/l4.txtに2行で書いてください。 9101=<open|refused|timeout> / 9102=<open|refused|timeout>
pay-api.labhub.localの名前解決の結果を確認し、/root/triage/name.txtに2行で書いてください。 RESOLVED=<IP returned by getent> / SOURCE=<absolute path of the file that holds that value>
9101のサービスのリッスンアドレスを確認し、/root/triage/bind.txtに1行で書いてください。BIND=<listen address:port>の形式です。(例: BIND=127.0.0.1:9101)
アクセスできるほう(9102)に/okをリクエストし、ステータスコードを/root/triage/http.txtにcode=<code>の1行で書いてください。
2つを直してください。
- /etc/hostsのpay-api.labhub.localのエントリを、このサーバーの実際のインターフェースのIPに直してください。
- 9101のサービスが0.0.0.0でリッスンするように、起動し直してください。(既存のプロセスは終了します) そして、curl -s http://pay-api.labhub.local:9101/okが成功することを確認し、その出力を/root/triage/fixed.txtに保存してください。
/root/triage/report.txtを次の6行で作成してください。 SYMPTOM=remote-timeout / LAYER1=name / LAYER2=bind / CAUSE_NAME=<wrong IP originally in hosts> / CAUSE_BIND=127.0.0.1 / FIXED=yes

参考

サービスを起動し直すときは、pkill -f 'server.py 9101'で先に片づけ、nohup python3 /opt/fixtures/nt-http/server.py 9101 0.0.0.0 &で立ち上げます。
名前解決の結果はgetent hostsで、実際のリッスンアドレスはss -ltnpで確認します。
よくある間違い1: ステップ3でループバックで試して、2つのポートがどちらもopenに見える場合です。必ずインターフェースのIPで行ってください。
よくある間違い2: ステップ7でhostsだけを直してバインドをそのままにすると、やはり失敗します。原因は2つです。

障害状況の再現

bash /opt/fixtures/nt-triage/start-incident.shで障害状況を再現し、/opt/fixtures/nt-triage/incident.mdを読んでください。/root/triageディレクトリを作成してください。

フィクスチャの起動スクリプトを実行すると、状況が作られます。報告書も一緒に読んでください。

L3の到達性の確認

自分のインターフェースのIPに3回pingした結果を/root/triage/l3.txtに保存してください。損失が0%である必要があります。

名前ではなくIPで確認すれば、名前の問題と混ざりません。自分のインターフェースのアドレスを使ってください。

ポートごとの結果の判定

自分のインターフェースのIPの9101ポートと9102ポートをそれぞれ叩いてみて、結果を/root/triage/l4.txtに2行で書いてください。 9101=<open|refused|timeout> / 9102=<open|refused|timeout>

2つのポートの結果が異なります。refusedとtimeoutとopenを、正確に区別して書いてください。

名前解決の問題の特定

pay-api.labhub.localの名前解決の結果を確認し、/root/triage/name.txtに2行で書いてください。 RESOLVED=<IP returned by getent> / SOURCE=<absolute path of the file that holds that value>

getentが返すIPと、このサーバーの実際のIPを比べてください。その値がどこに書かれているかも探す必要があります。

バインドの問題の特定

9101のサービスのリッスンアドレスを確認し、/root/triage/bind.txtに1行で書いてください。BIND=<listen address:port>の形式です。(例: BIND=127.0.0.1:9101)

ssの出力のLocal Addressの列が答えです。2つのサービスのうち、どちらが問題なのかを見分けてください。

アプリケーション層の確認

アクセスできるほう(9102)に/okをリクエストし、ステータスコードを/root/triage/http.txtにcode=<code>の1行で書いてください。

アクセスできるほうで先に確認し、サービス自体は正常であることを証明してください。

修正と検証

2つを直してください。

/etc/hostsのpay-api.labhub.localのエントリを、このサーバーの実際のインターフェースのIPに直してください。
9101のサービスが0.0.0.0でリッスンするように、起動し直してください。(既存のプロセスは終了します) そして、curl -s http://pay-api.labhub.local:9101/okが成功することを確認し、その出力を/root/triage/fixed.txtに保存してください。

2つとも直す必要があります。直したあとは、必ず外側のアドレスで再確認してください。

ポストモーテム報告書

/root/triage/report.txtを次の6行で作成してください。 SYMPTOM=remote-timeout / LAYER1=name / LAYER2=bind / CAUSE_NAME=<wrong IP originally in hosts> / CAUSE_BIND=127.0.0.1 / FIXED=yes

形式が決まっています。各値は、前のステップで実際に確認したものである必要があります。