障害対応演習
壊れた状態から始まる
このレッスンは、これまでと出発点が違います。始めた時点で、サーバーは既に壊れています。
何が壊れているかは書きません。実際の障害も、原因が書かれた状態では届かないからです。届くのは「サイトが見られない」という一言だけです。
切り分けの順番
慌てて設定ファイルを開くのは、いちばん遠回りです。外側から内側へ、順に絞り込みます。
- プロセスは動いているか —
systemctl status nginx - 動いていないなら、なぜ動けないのか —
journalctl -u nginx -n 30、nginx -t - 動いているなら、どう応答しているか —
curl -skI https://localhost/ - 応答がおかしいなら、なぜそう応答したのか — エラーログの末尾
この順に進めると、無関係な場所を触らずに済みます。逆から始めると、直っていないのに直したつもりになります。
ステータスコードが行き先を教えてくれる
返ってきた数字で、次に見る場所が決まります。
- 繋がらない — プロセスが動いていないか、待ち受けていない番号。
ss -tlnpを見る - 403 — ファイルはあるが読めない。権限を見る
- 404 — 探した場所にファイルが無い。
rootやaliasの指す先を見る - 500 番台 — nginx より奥で失敗している。エラーログを見る
エラーログの絶対パスがいちばん効きます。nginx が実際にどこを見に行ったかが書かれているので、設定の読み違いが一目で分かります。
直したら、直ったことを確かめる
1つ直すたびに curl を打ち直します。まとめて直すと、何が効いたのか分からなくなります。
そして、壊れている箇所は1つとは限りません。1つ直して 403 が 404 に変わったなら、それは前進です。次の原因が見えたということです。
記録を残す
復旧したら、何が起きて何をしたかを書き残します。
プレーンテキスト
1. nginx が起動していなかった。設定から秘密鍵の行が消えていたので書き戻した
2. トップページが 403 だった。index.html の権限が 000 だったので 644 に戻した同じことは必ずまた起きます。そのとき自分を助けるのは、記憶ではなくこの記録です。
手を動かす
壊れたサーバーを調べて、HTTPS で元どおり見られる状態まで戻します。原因と対処を記録に残してください。