こんにちは、インフラエンジニアのryuです。
自分で立てたサーバーにブラウザからアクセスしたら、画面が真っ白のまま返ってこない。ターミナルには見慣れないエラーが1行。さて、どこから手をつけよう。
そこで手が止まってしまった経験は、ないでしょうか。
インフラエンジニアの仕事は、実は「新しく作る」時間より「動かない何かを直す」時間のほうが長かったりします。そしてこの直す力、いわゆる切り分け（トラブルシューティング）こそ、参考書を読むだけではなかなか身につかない、いちばん差がつくスキルなのですね。
今回は、未経験の方に向けて、障害の切り分けとは何かをかみ砕いて説明し、そのうえで独学でもこの力を鍛えていく具体的な方法をお話しします。コマンドを覚える段階を一通り終えて、「次は何を伸ばせばいいんだろう」と感じている人にこそ読んでほしい内容です。
なぜ未経験のうちは「切り分け」で固まってしまうのか？¶
まずは、つまずく理由をはっきりさせておきましょう。原因が分かれば、練習の方向も決まります。
未経験のうちに障害対応で固まってしまうのには、だいたい共通したパターンがあります。
ひとつめは、目の前の「症状」しか見えていないことです。「画面が表示されない」という結果だけを見て、その裏で何と何がつながって初めて画面が出るのか、という道筋がイメージできていない。だから、どこを疑えばいいのかの当たりがつかないのですね。
ふたつめは、あせって一度にいくつも設定を変えてしまうことです。ファイルを直し、サービスを再起動し、ついでに別の値も変えて……とやってしまうと、仮に直っても「何が効いたのか」が分からなくなります。逆に悪化したときも、元に戻せません。
みっつめは、エラーメッセージやログを「怖いもの」として読み飛ばしてしまうこと。実際には、ログは犯人がこぼしていった手がかりの宝庫です。読み方さえ分かれば、切り分けの半分は終わっていることも珍しくありません。
この3つは、どれも知識量の問題というより「進め方」の問題です。だからこそ、正しい型を知れば、未経験でも着実に上達していきます。
言いかえると、切り分けが苦手なのは頭の良し悪しではなく、単に「手順を習っていないから」なのですね。料理でいえば、包丁の握り方や下ごしらえの順番を知らないだけの状態です。順番さえ覚えれば、あとは場数がついてきます。ここから先で、その順番をひとつずつ見ていきましょう。
そもそも「切り分け」とは何をすることなのか？¶
切り分けという言葉を、もう少しかみ砕いてみましょう。
たとえるなら、引っ越しの荷物の中から、なくした鍵を探す作業に似ています。部屋じゅうの段ボールを一度に開けてぜんぶひっくり返しても、鍵はなかなか見つかりません。
かしこいやり方は、まず「玄関で使ったのだから、玄関まわりの箱に入っているはず」と範囲をしぼり、その箱だけを開けて確かめることです。違えば次の箱へ。こうして怪しい範囲を半分ずつ潰していけば、少ない手数でたどり着けます。
インフラの切り分けもまったく同じで、「怪しい範囲を段階的にしぼり込み、原因のある一点まで追い込んでいく」作業を指します。やみくもに全部を触るのではなく、確かめて、範囲を狭めて、また確かめる。この繰り返しです。
ここで頼りになるのが、ネットワークの世界でおなじみのOSI参照モデルという考え方です。通信を物理的なケーブルから始まる7つの層に分けて捉えるもので、切り分けのときは「どの層まで正常に届いているか」を下から順に確かめる地図として使えます。
層ごとに「何が正常なら、その下は正常とみなせるか」を整理すると、こう見えてきます。
| 見るところ | 確かめること | よく使う道具 |
|---|---|---|
| 物理・接続 | ケーブルやNIC、機器の電源は生きているか | ランプ、ip link |
| IP到達性 | 相手のIPアドレスまで届くか | ping |
| 経路 | どこまで進んでどこで止まるか | traceroute |
| 名前解決 | ドメイン名がIPに変換できるか | nslookup、dig |
| サービス | 目的のポートでアプリが応答するか | curl、ss |
この地図があるだけで、「まずpingが通るか見て、通るなら物理とIPは正常。次は名前解決かサービスを疑おう」と、考えの道筋が一本につながります。もしpingそのものを触ったことがなければ、pingコマンドの使い方から先に手を動かしておくと、この先の話がぐっと腹落ちします。
切り分けの「型」：3つのステップで原因に近づく¶
考え方が分かったら、次は実際の手順です。ベテランが無意識にやっていることを、あえて3つのステップに分けてみます。
ステップ1：症状を「言葉」にして再現条件をつかむ¶
いきなり設定ファイルを開くのは、ぐっとこらえてください。まず、起きていることを正確な言葉にします。
「サイトが見られない」では、あいまいすぎます。「自分のPCのブラウザからは真っ白だが、サーバーにログインしてcurl localhostすると正常なHTMLが返る」まで具体化できると、それだけで疑う範囲が半分に減ります。この例なら、アプリ自体は動いていて、外から中への通り道が怪しい、と当たりがつきますよね。
いつから、誰から見て、どの操作をしたときに起きるのか。この再現条件をつかむことが、切り分けの出発点です。
とくに効くのが、「最後に正常だったのはいつか」という問いです。昨日までは動いていたのに今朝から見えない、というなら、その間に加わった変更こそが最有力の容疑者になります。設定を触った、更新をかけた、証明書の期限が切れた——時間軸で挟み込むだけで、疑う範囲が一気に狭まるのですね。
ステップ2：仮説を1つ立て、1つだけ試す¶
次に、症状から「たぶんここだろう」という仮説を1つ立てます。そして、その仮説を確かめる操作を1回に1つだけ行います。
Googleが公開しているSRE本でも、トラブルシューティングは「システムがどう動くべきかを知り、データを集め、仮説を立て、それを検証する」ことだと説明されています。勘で当てるのではなく、仮説を立てて一つずつ潰す。この地道さが、実は最短ルートなのですね。
たとえばネットワークが怪しいなら、次のように下の層から順に確かめていきます。
# 相手のIPアドレスまで届くか（物理・IPの確認）
ping -c 4 192.0.2.10
# 経路のどこで止まっているか
traceroute 192.0.2.10
# ドメイン名がIPに変換できているか
nslookup example.com
# 目的のポート(80/443)でアプリが応答するか
curl -I http://192.0.2.10/
大事なのは、1つ試したら結果をメモしてから次に進むことです。変えた設定を元に戻せるようにしておけば、迷路に入り込んでも必ず引き返せます。
ステップ3：レイヤーで「上か下か」を判断する¶
pingが通ったなら、物理とIPの層は正常だと分かります。ならば原因はその上、名前解決かアプリ側にある。逆にpingが通らないなら、原因はその下、経路か物理側にある。
このように、ある層が正常だと確認できたら、そこを境に「上を疑うか、下を疑うか」を決めていきます。真ん中から始めて上下に振り分けるこのやり方は、ネットワーク機器の設計で知られるシスコの解説でも、効率のよい切り分け手法として紹介されています。
経路の途中でパケットがどう運ばれるのか、その全体像が曖昧なままだと、この判断はどうしても鈍ります。仕組みそのものに不安が残る人は、ルーティングとは何かやNAT（アドレス変換）の仕組み、ARPの役割をあわせて押さえておくと、切り分けの精度が一段上がります。
具体例で追いかけてみよう：Webサイトが見えないとき¶
型だけを聞いても、なかなか実感がわかないですよね。ひとつ、よくある場面を最初から最後まで追いかけてみましょう。
状況はこうです。自分で立てたWebサーバーに、ブラウザからアクセスしても真っ白のまま。「サーバーが壊れたのかな」と不安になる場面です。
ここで前のめりにサーバーの設定を書き換えないのが、上達する人の第一歩です。まず症状を言葉にします。「自分のPCのブラウザからは表示されない」。これだけです。ならば、確かめる順番はこうなります。
はじめに、サーバー自身の中では動いているのかを見ます。サーバーにログインしてcurl localhostを打ち、正常なHTMLが返ってくれば、アプリそのものは生きていると分かります。これで「アプリの故障」という大きな箱を、ひとつ閉じられました。
次に、自分のPCからサーバーのIPアドレスまで届くかをpingで確かめます。応答があれば、物理とIPの層は正常。原因はもっと上、名前解決かポートのあたりだと絞れます。応答がなければ、原因は下、経路やファイアウォールにあると分かります。
こうして「中は動く・IPは届く・でも見えない」とそろえば、残る容疑者はぐっと減ります。ドメイン名で見えないだけならDNSを、特定のポートだけ弾かれているならファイアウォールの設定を疑う、というふうに、最後の一点まで一本道でたどり着けるのですね。
大切なのは、途中のcurl localhostが成功した時点で、疑う範囲の半分を切り落とせている、という感覚です。名前解決の流れそのものに不安があるなら、DNSの仕組みを先に押さえておくと、この容疑者の絞り込みがスムーズになります。
独学でも「切り分け力」は鍛えられる¶
ここまで読んで、「型は分かったけれど、現場の障害なんて経験できないから練習できないのでは」と思ったかもしれません。
でも大丈夫です。切り分けは、自分の学習環境の中でも十分に鍛えられます。おすすめの練習を3つ紹介します。
ひとつめは、わざと壊して、直す練習です。自宅の仮想マシンやクラウドの検証環境で、設定ファイルを1か所だけ書き換えたり、サービスを止めたりしてから、「さっき何を変えたか」を思い出さずに原因を探ってみる。答えを自分が握っているぶん、切り分けの筋道を安全に何度でも試せます。
ふたつめは、ログを読む習慣をつけることです。エラーが出たら、まず/var/log/配下やアプリのログを開き、時刻とメッセージを追う。最初は意味が分からなくても、「このエラーが出たとき、実際は何が原因だったか」をセットで覚えていくと、ログが会話のように読めてきます。Linuxでの具体的な追い方はLinuxのトラブルシューティング手順にまとめてあるので、手順の見本として使ってみてください。
みっつめは、直したあとに「なぜそれで直ったのか」を一言でメモすることです。原因と対策を言葉にして残すと、次に似た症状に出会ったとき、記憶の引き出しから型を取り出せるようになります。障害対応が上手な人は、例外なくこの「振り返り」を積み重ねています。
もうひとつ、余裕が出てきたら試してほしいのが、他人が書いた障害報告を読むことです。世の中の企業やサービスは、大きな障害が起きたあとに「何が原因で、どう気づき、どう直したか」をまとめた記録を公開していることがあります。これを読むと、経験豊富なエンジニアがどんな順番で疑い、どこで手がかりをつかんだのかを、追体験できます。自分が現場でまだ出会えない規模の障害でも、思考の道筋だけは先に借りられるわけですね。
こうした練習に共通しているのは、「答えを知っている状態で、あえて筋道をたどり直す」という点です。本番の障害はいつ来るか分かりませんが、切り分けの型は、こうして安全な場所で何度も素振りしておけます。素振りの回数だけ、いざというときの落ち着きが変わってきます。
そして、こうした練習をひとりで続けるのは、思った以上に根気がいります。InfraAcademyでは、ネットワークやLinuxの仕組みを図解で学びながら手を動かせる教材を用意していて、切り分けの土台になる「システムがどう動くべきか」を体系立てて身につけられます。独学の順番に迷ったら、まずはネットワークの学習ロードマップから始めてみてください。基礎コマンドが不安な人はLinuxコマンド入門やインフラ学習の全体像もあわせてどうぞ。
まとめ¶
最後に、今日の要点を振り返っておきましょう。
障害の切り分けとは、怪しい範囲を段階的にしぼり込み、原因の一点まで追い込む作業でした。引っ越しで鍵を探すときのように、当たりをつけて半分ずつ潰していくのがコツです。
その進め方は、症状を言葉にして再現条件をつかみ、仮説を1つずつ検証し、層の上下で原因を振り分ける、という3ステップに整理できます。あせって一度に複数を変えないこと、そしてログという手がかりを恐れないことが、遠回りを防ぎます。
この力は、現場に出る前でも、わざと壊して直す・ログを読む・振り返りを残す、という練習で着実に伸ばせます。コマンドを覚える段階の次に来る、少し骨のあるステップですが、ここを越えると「動かないもの」がぐっと怖くなくなります。
そしてこの切り分けの型は、ネットワークにもサーバーにもクラウドにも、そのまま応用が効きます。対象が変わっても、症状を言葉にして、仮説を一つずつ試し、範囲をしぼり込む、という骨組みは同じだからです。一度身につければ、長く使える一生モノの武器になります。
一つずつ確かめていけば、真っ白な画面の向こう側も、必ず読み解けるようになります。焦らず、手を動かしていきましょう。
