障害対応演習

壊れた状態から始まる

このレッスンは、これまでと出発点が違います。始めた時点で、サーバーは既に壊れています。

何が壊れているかは書きません。実際の障害も、原因が書かれた状態では届かないからです。届くのは「サイトが見られない」という一言だけです。

切り分けの順番

慌てて設定ファイルを開くのは、いちばん遠回りです。外側から内側へ、順に絞り込みます。

1. プロセスは動いているか — systemctl status nginx
2. 動いていないなら、なぜ動けないのか — journalctl -u nginx -n 30、nginx -t
3. 動いているなら、どう応答しているか — curl -skI https://localhost/
4. 応答がおかしいなら、なぜそう応答したのか — エラーログの末尾

この順に進めると、無関係な場所を触らずに済みます。逆から始めると、直っていないのに直したつもりになります。

ステータスコードが行き先を教えてくれる

返ってきた数字で、次に見る場所が決まります。

• 繋がらない — プロセスが動いていないか、待ち受けていない番号。ss -tlnp を見る
• 403 — ファイルはあるが読めない。権限を見る
• 404 — 探した場所にファイルが無い。root や alias の指す先を見る
• 500 番台 — nginx より奥で失敗している。エラーログを見る

エラーログの絶対パスがいちばん効きます。nginx が実際にどこを見に行ったかが書かれているので、設定の読み違いが一目で分かります。

直したら、直ったことを確かめる

1つ直すたびに curl を打ち直します。まとめて直すと、何が効いたのか分からなくなります。

そして、壊れている箇所は1つとは限りません。1つ直して 403 が 404 に変わったなら、それは前進です。次の原因が見えたということです。

記録を残す

復旧したら、何が起きて何をしたかを書き残します。

同じことは必ずまた起きます。そのとき自分を助けるのは、記憶ではなくこの記録です。

手を動かす

壊れたサーバーを調べて、HTTPS で元どおり見られる状態まで戻します。原因と対処を記録に残してください。