前回までで共通のCase／Stepモデルと3カラム画面ができました。ここからは、その上に載せた最初の課題です。基準となる実装として、Webサイト接続障害を選びました。
なぜ最初にこの課題を選んだか
題材にしたのは、CloudFront（＝Webサイトのデータを配信するサービス）を通したサイトが403（＝アクセスを拒否された状態）を返す、という接続障害です。個人開発でも遭遇しやすく、原因の候補が複数あって、順番に切り分ける価値がはっきりしているからです。
この課題は、確認観点を持っているかどうかで進み方がはっきり分かれます。慣れた人は上流から順にたどりますが、慣れていないと、思いついた場所をいきなり触ってしまいがちです。「とりあえずS3の設定を開いてみる」「なんとなくキャッシュを消してみる」といった、手当たり次第の動きになりやすい。最初の基準実装として、切り分けの型を示すのにちょうどよいと考えました。第1回で書いた「最初にどこを見るか」の差が、そのまま出る課題でもあります。
原因を「当てる」設計にはしたくなかった
設計で一番気をつけたのは、これを「原因当てクイズ」にしないことです。403の原因はこれ、と暗記させても、少し状況が変われば通用しません。前回までに書いた「操作を覚えるのではなく確認観点をたどる」を、ここで形にしたかったのです。
暗記型にすると、一見わかりやすい教材にはなります。でも、それは第2回で書いた「順調なときだけ使える地図」と同じで、想定と違う状況にぶつかった瞬間に崩れます。覚えるべきは答えではなく、答えにたどり着く順序のほうです。
そこで、答えを先に出すのではなく、上流から下流へ順に確認していく10ステップに組み直しました。もともとアプリにあった障害診断の知見を、最初から最後まで完走できる一本の流れへ再構成した形です。
- 事象確認（どんな条件で403になるか、HTTPステータスと再現性）
- DNS確認
- CloudFrontディストリビューションの確認
- オリジンの確認
- S3アクセス制御の確認
- キャッシュ・エラー応答の確認
- 原因判定
- 対応案の整理
- 証跡確認
- 完了
上流から順にたどる意味
最初の「事象確認」では、まず症状そのものを固定します。常に403なのか、特定のパスだけなのか、いつから起きているのか、誰から見ても同じか。ここを曖昧にしたまま下流へ進むと、あとで判断がぶれます。「たまに直る」のか「必ず403」なのかで、疑う場所はまったく変わるからです。
そこからDNS、CloudFront、オリジン、S3へと、通信の上流から下流に沿って観点を並べました。名前解決はできているのか。配信サービスの設定はどうか。配信元として指定した場所は正しいか。そして、保存先であるS3へのアクセス制御はどうなっているか。順番に見ていくと、どこまでが正常で、どこから怪しくなるかの境目が見えてきます。
S3のアクセス制御では、OAC（＝CloudFrontからだけS3へアクセスさせる仕組み）とバケットポリシーの関係が焦点になります。CloudFront経由のアクセスだけを許可する設定が崩れていると、ここで403になります。キャッシュの確認は、あえて後ろのほうに置きました。古い応答が残っているだけなのに、設定のほうを触ってしまう事故を避けたかったからです。原因でないところを先に触ると、かえって状況がこじれます。
こうして並べると、それぞれのステップが「原因の候補を一つずつ潰していく」役割を持ちます。原因を一発で当てるのではなく、切り分けの順序そのものを身につけてもらう、という設計です。上流が正常だと確認できていれば、そこは候補から外せる。消去法で範囲を狭めていく感覚を、ステップの並びで表しました。
危険な対応を、正解にしない
もう一つ強く意識したのが、安全な対応です。403を消したいだけなら、S3を直接公開してしまえば、とりあえず見えるようにはなります。実際、あせっているとこの手が頭をよぎります。でもそれは、非公開であるべきものを開けてしまう危険な対応です。障害を消す代わりに、もっと大きな問題を作りかねません。
だからこの課題では、そうした場当たり的で危険な対応を、正常な選択肢として置いていません。原因判定のあとの「対応案の整理」では、確認した事実にもとづいて、安全な方向の対応を検討させる形にしています。急いで穴を開けるのではなく、確認できた原因に対して、必要最小限の直し方を考える、という順序です。
そもそもこの課題を含めて、OpsMate Proの各ステップはAWSの実環境を触りません。すべての操作は、確認・判断・ダミー操作のいずれかです。設定変更のコマンドを実行する導線はなく、コマンドは表示とコピーまで。実際の変更は、正式な変更作業の手順に引き継ぐ前提にしています。各ステップにはこの性質（confirm／judge／dummyの区別）を持たせ、危険な操作をうっかり実行できないようにしました。切り分けの練習と、実際の変更を、はっきり分けているわけです。
証跡と完了条件をつなぐ
各ステップには、必須の証跡が最低一つと、正常か異常かの記録が必要です。DNSはどうだったか、CloudFrontの設定はどう見えたか。それを残しながら進むので、原因判定にたどり着くころには、判断の根拠が自然にそろっています。あとから「なぜそう判断したのか」を説明できる状態になる、ということでもあります。
原因判定のステップは、それまでの確認結果を突き合わせて、どこが怪しいかを絞る場所です。ここでも「たぶんこれ」で飛ばさず、確認した事実に紐づけて判断するようにしています。証跡確認と完了で、抜けがないかを最後にもう一度点検します。
作ってみて感じたこと
作りながら感じたのは、切り分けの順序を言葉にして固定するだけで、かなり印象が変わるということです。同じ403でも、「どこから見るか」が最初から示されているだけで、迷いはずいぶん減ります。自分で作っていて、「最初にこう並べてくれていたら、昔もっと楽だったな」と思う場面がありました。
一方で、10ステップに収めるために、実際の障害の細かい分岐はかなり削っています。現実にはもっと例外があるはずで、そこは今のデータでは表現しきれていません。基準となる型を作った、という段階だと思っています。分岐をどこまで増やすと親切で、どこから逆に迷わせるのか、その線引きはこれからの課題です。
次回は、性質のかなり違う課題として、IAMの権限追加を扱います。切り分けではなく、権限を設計・判断させる課題をどう組んだかを書きます。