総合トリアージ: 決済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=<getent 가 돌려준 IP>/SOURCE=<그 값이 적혀 있는 파일의 절대 경로>(プレースホルダーは順に、getentが返したIPと、その値が書かれているファイルの絶対パスです)- 9101のサービスのリッスンアドレスを確認し、
/root/triage/bind.txtに1行で書いてください。BIND=<리슨 주소:포트>の形式です(プレースホルダーはリッスンアドレスとポートです)。(例:BIND=127.0.0.1:9101) - アクセスできるほう(9102)に
/okをリクエストし、ステータスコードを/root/triage/http.txtに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=<원래 hosts 에 적혀 있던 잘못된 IP>/CAUSE_BIND=127.0.0.1/FIXED=yes(プレースホルダーは、もともとhostsに書かれていた誤ったIPです)
参考
- サービスを起動し直すときは、
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=<getent 가 돌려준 IP> / SOURCE=<그 값이 적혀 있는 파일의 절대 경로>(プレースホルダーは順に、getentが返したIPと、その値が書かれているファイルの絶対パスです)
getentが返すIPと、このサーバーの実際のIPを比べてください。その値がどこに書かれているかも探す必要があります。
バインドの問題の特定
9101のサービスのリッスンアドレスを確認し、/root/triage/bind.txtに1行で書いてください。BIND=<리슨 주소:포트>の形式です(プレースホルダーはリッスンアドレスとポートです)。(例: BIND=127.0.0.1:9101)
ssの出力のLocal Addressの列が答えです。2つのサービスのうち、どちらが問題なのかを見分けてください。
アプリケーション層の確認
アクセスできるほう(9102)に/okをリクエストし、ステータスコードを/root/triage/http.txtに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=<원래 hosts 에 적혀 있던 잘못된 IP> / CAUSE_BIND=127.0.0.1 / FIXED=yes(プレースホルダーは、もともとhostsに書かれていた誤ったIPです)
形式が決まっています。各値は、前のステップで実際に確認したものである必要があります。