こんにちは、インフラエンジニアのryuです。
入門書を1冊、最後まで読み終えたことはあるでしょうか。
ls や cd が指に馴染んで、vi で設定ファイルも編集できるようになる。仮想マシンにWebサーバーを入れて、ブラウザに「It works!」が表示された日のことは、たぶんよく覚えているはずです。
ところが、そのあとで求人票を開くと急に足が止まります。冗長構成の設計・運用経験、障害の一次対応、監視設計。書いてある日本語は読めるのに、自分が何をできる人間なのかを説明できない。
この、入門と実務のあいだにある踊り場を、私は勝手に中級の壁と呼んでいます。
学習が止まりやすいのは、実はここです。基礎が足りないのではなく、次に何を積めばいいのかが見えなくなる。今日は、その壁の正体と、越えるための具体的な視点をお話しします。
なぜ入門書を終えても「できる気がしない」のか¶
先に言っておくと、これはあなたの理解力が足りないという話ではありません。入門書と現場では、そもそも問われているものが違うのです。
入門は「部品」、現場は「つながり」¶
料理でたとえてみます。入門書で学ぶのは、包丁の握り方、火加減、玉ねぎの切り方といった、いわば部品の技術です。
いっぽうで現場が求めるのは「2時間後に、6人分のコース料理を、冷めない順番で出すこと」。使う包丁は同じなのに、問われているのは段取りと全体像に変わっています。
インフラもまったく同じです。入門で覚えるのはコマンド・設定ファイル・用語といった部品。現場で問われるのは、その部品が何とつながっていて、どこが切れると何が止まるか、という関係のほうです。
言葉にすると、こんな違いになります。
| 入門書で学ぶこと | 現場で問われること |
|---|---|
| Webサーバーをインストールする | そのサーバーが落ちたとき、誰が最初に気づくか |
| ポートを開ける | なぜそのポートだけを開け、他を閉じるのか |
| 設定ファイルを書き換える | 再起動しても、その設定が生き残るか |
| コマンドの意味を覚える | 出力のどの行を見て、次に何をするか |
右側の列に、暗記でたどり着けるものが1つもないことに気づいたでしょうか。ここが壁の正体です。
「動いた」と「わかった」は別もの¶
もうひとつ、つまずきの原因になりやすいのが写経です。
手順書のとおりにコマンドを打つと、たしかに動きます。でも「なぜそのコマンドが必要だったのか」を聞かれると答えられない。私も駆け出しのころ、構築手順書のとおりに作業して、あとから先輩に「この行、なんで要るんだと思う?」と聞かれて固まったことがあります。
動かせることと、説明できることのあいだには、思っているより深い溝がある。
この溝は、新しい入門書をもう1冊読んでも埋まりません。同じ深さの水を、もう一杯足しているだけだからです。
しかも厄介なことに、写経は成功体験として残ります。動いた画面を見ているので、できるようになった気がしてしまう。そのまま次の教材へ進むと、いつまでも足元が固まらないまま冊数だけが増えていきます。
自分がどちらの状態にいるかを確かめる方法は、ひとつだけあります。手順書を閉じて、同じものをもう一度作ってみることです。ここで手が止まったなら、それは覚えていなかったのではなく、まだ理解に変わっていなかっただけ。落ち込む場面ではなく、伸ばす場所が見つかった場面です。
必要なのは、いま持っている知識に別の問いを当てて、深さを変えることです。その問いを4つに整理してみます。
中級の壁を越える4つの視点¶
現場で「一人前になった」と見なされる瞬間を思い返すと、だいたい次の4つのどれかを自分でやり始めたときでした。
| 視点 | 入門のとき | 中級で足す問い |
|---|---|---|
| つながり | 1台の中を触る | この通信は、どこを通って戻ってくるか |
| 継続性 | 動いた時点で完了 | 明日の朝も、再起動しても動いているか |
| 障害前提 | 壊れないように作る | 壊れたとき、何分で戻せるか |
| 引き継ぎ | 自分が動かせればいい | 他の人が同じものを作れるか |
ひとつずつ、具体的に見ていきます。
視点1:1台の中から、複数台のあいだへ¶
入門の課題は、ほとんどが1台で完結します。同じマシンにWebサーバーもデータベースも入れて、localhost でつなぐ。これだと、ネットワークの出番がありません。
そこで、同じ構成をあえて2台に割ってみます。Webサーバーは1台目、データベースは2台目。それだけで、急に考えることが増えます。
相手のIPアドレスは何か。そのポートは開いているか。名前で呼ぶならDNSは誰が引くのか。片方から片方へ、パケットはどの経路をたどるのか。
ここでようやく、ルーティングとは?やDNSとは?で読んだ話が、自分の手元の出来事になります。知識が現場の感覚に変わるのは、たいてい台数が増えた瞬間です。
つながりを確かめるコマンドも、この段階で身体に入れておくと後が楽になります。
# 相手のポートが開いているか(Webサーバーからデータベースへ)
$ ss -lntp # 自分側で待ち受けているポートを確認
$ nc -zv 192.168.10.20 3306 # 相手のポートに届くか
$ ip route # そもそもどの経路で出ていくのか
$ dig db.example.local +short # 名前が引けているか
このうち1つでも「何を見ているのか説明できない」ものがあれば、そこがあなたの伸びしろです。
台数が増えると、切り分けの考え方も自然と身につきます。画面が表示されないとき、原因はWebサーバーなのか、データベースなのか、そのあいだの経路なのか。1台構成だと全部が同じ場所にあるので、この問いが生まれません。
宅配便に置きかえると分かりやすいと思います。荷物が届かないとき、原因は差出人なのか、配送業者なのか、受取先の住所が間違っているのか。区間を分けて考えられる人は、原因にたどり着くのが早いです。インフラの切り分けも、やっていることはこれとほとんど同じです。
視点2:「動いた」から「動き続ける」へ¶
構築が終わってブラウザに画面が出ると、つい完了にしたくなります。けれど現場では、そこはまだ半分です。
試しに、作ったサーバーを一度再起動してみてください。同じ画面が出るでしょうか。
手動で起動しただけのサービスは、再起動すると消えます。systemctl enable を忘れていた、ログが溢れてディスクを埋めた、証明書の期限が切れた。動き続けることを邪魔する要因は、構築とは別のところにあります。
# 再起動後も自動で上がるか
$ systemctl is-enabled nginx
$ systemctl enable --now nginx
# ログが溜まり続けていないか
$ journalctl --disk-usage
$ df -h /var
中級への一歩は、構築が終わった直後に再起動してみることです。地味ですが、これだけで気づけることが本当に多いです。
そして落ちたとき、原因はたいていログに残っています。読み方に自信がなければ、未経験インフラエンジニアのためのログの読み方入門を先に押さえておくと、この視点はぐっと使いやすくなります。
視点3:「壊れないように」から「壊れる前提」へ¶
初心者のうちは、壊さないことが目標になりがちです。私もそうでした。
でも現場の設計思想は逆で、いつか壊れる前提で組みます。ディスクは壊れるし、電源は落ちるし、人間は間違ったコマンドを打ちます。だから問われるのは「壊れないか」ではなく「壊れたとき、何分で戻せるか」になります。
この視点を練習するのは簡単です。自分で作った環境を、自分で壊してみればいい。
設定ファイルをわざと壊して起動しなくしてみる。データベースのデータを消してから、バックアップで戻してみる。ネットワークを切って、アプリがどんなエラーを出すか眺めてみる。
自宅の仮想マシンなら、何度壊しても誰にも迷惑がかかりません。環境の作り方は自宅で作るインフラ学習ラボにまとめてあるので、まだ手元に壊せる環境がない人はそこから始めるといいと思います。
バックアップは取った時点では半分しか終わっていない。戻せて、はじめて完了する。
戻す手順を一度も試したことがないバックアップは、正直に言うと存在しないのと大差ありません。ここを実際にやったことがある人は、未経験でもかなり強いです。
面接でも、この経験は効きます。「何を作りましたか」と聞かれて構成を説明できる人はたくさんいますが、「壊れたときにどうしましたか」まで話せる人はぐっと減るからです。現場が本当に知りたいのは、うまくいったときの話より、うまくいかなかったときの動き方のほうだったりします。
視点4:自分だけが動かせる、から人に渡せる形へ¶
最後の視点は、少し性質が違います。技術というより、仕事の作法に近い話です。
現場のインフラエンジニアは、自分が作ったものをいつか誰かに引き継ぎます。だから「自分の頭の中にしかない手順」は、そのままでは価値になりません。
やることは3つだけです。作業した内容を手順として書き残す。設定ファイルの差分を残す。同じ環境をもう一度作り直せるか試す。
同じ構築を2回目にやってみると、自分の手順書の穴が一気に見えます。「ここでrootに切り替えていた」「ここでファイアウォールを開けていた」。書き漏らした行こそが、あなたが無意識でやっている作業です。
学習の記録がそのまま人に渡せる形になれば、それはポートフォリオとしても効いてきます。転職活動のためだけでなく、自分の理解を確かめる意味でも効率がいいやり方です。
いつもの構築を「中級の課題」に変えてみよう¶
視点の話が続いたので、ここで具体的な課題に落としてみます。
入門でよくある「1台にWebサーバーとデータベースを入れる」構成を、そのまま素材にします。作り直す必要はありません。問いを足すだけです。
同じ構成に、4つの問いを足す¶
やることを一覧にすると、こうなります。
| 元の課題 | 足す条件 | 身につく感覚 |
|---|---|---|
| 1台にまとめて構築 | Webとデータベースを別ホストに分ける | 通信経路と名前解決 |
| 起動したら完了 | 再起動しても自動で上がるようにする | 永続化とサービス管理 |
| 正常系だけ確認 | わざと片方を止めて挙動を見る | 障害時の見え方 |
| 手元で動けばよし | 手順書を書き、もう一度作り直す | 再現性と引き継ぎ |
4つ全部をいきなりやる必要はありません。1つ足すだけでも、同じ構築がまったく違う勉強になります。
自分に投げてみる7つの質問¶
構築が終わったあと、自分にこう聞いてみてください。答えに詰まった項目が、次に読むべき場所です。
1. この通信は、どのIPからどのポートへ出ていく?
2. サーバーを再起動しても、同じ状態に戻る?
3. サービスが落ちたら、どのログに何が出る?
4. データを消してしまったら、どこから戻す?
5. この設定を変えると、他のどこに影響する?
6. 同じ環境を、明日もう一度ゼロから作れる?
7. この作業を後輩に頼むとしたら、何を渡す?
7つとも答えられたら、その構成についてはもう中級の入り口に立っています。答えられない質問があっても落ち込む必要はなくて、むしろ次に何を勉強するかが1行で決まったということです。
どこまで行けば「中級」なの?¶
そうは言っても、自分がどのあたりにいるのかは分かりにくいものです。目安として使いやすいのが、資格の出題範囲です。
教材を買い足す前に、いまの環境を深掘りする¶
その前にひとつだけ、遠回りになりやすいパターンをお伝えしておきます。壁にぶつかったときに、新しい技術へ横に逃げてしまうことです。
Linuxが分からないままコンテナに手を出し、コンテナが分からないままクラウドの資格に移る。どれも将来必要になる技術なので、勉強していること自体は間違いではありません。ただ、深さが足りないという問題は、幅を広げても解決しないのです。
穴を掘るのに例えるなら、同じ場所を掘り続けないと水は出ません。浅い穴をいくつ並べても、途中で力尽きてしまいます。
だから、迷ったら新しい教材ではなく、いま手元にある環境に問いを1つ足すほうを選んでみてください。そのほうが確実に深く掘れます。
たとえばLinuxの認定試験であるLinuCは、レベル1が1台のLinuxサーバーを操作・運用できること、レベル2が仮想環境を含むシステムの設計・構築、そして高可用性やトラブルシューティングまでを扱う、という形で段階が分かれています。
つまり、この記事で挙げた4つの視点は、レベル1とレベル2のあいだにある差そのものなのです。資格を受けるかどうかは別として、出題範囲を眺めるだけでも「現場が中級に何を期待しているか」の地図として役に立ちます。
もう少し先を覗いてみたい人には、Googleが公開しているSREの書籍が無料で読めるのでおすすめです。壊れる前提で運用する考え方が、どういう言葉で語られているのかが分かります。
そして、こうした順番を自分で組み立てるのが難しいと感じるなら、体系立てられた教材に頼るのも立派な選択です。InfraAcademyでは、Linuxを1台の操作から実務で使う形まで積み上げるLinuxロードマップと、通信の流れを手を動かしながら追うネットワークロードマップを用意しています。独学で散らばってしまった知識を、つながった状態に組み直すのに使ってみてください。
まだ全体像そのものが曖昧だという人は、先にインフラエンジニアのロードマップやLinuxコマンドの基礎に戻ってから、この記事の4つの視点を足すのがきれいな順番だと思います。
まとめ¶
中級の壁は、知識の量ではなく問いの種類が変わることで生まれます。
越えるための視点は4つでした。1台の中から複数台のあいだへ。動いたから動き続けるへ。壊れないようにから壊れる前提へ。そして、自分だけが動かせるから人に渡せる形へ。
新しい教材を買い足す前に、いま作れる構成にこの問いを1つ足してみてください。同じ環境が、まったく違う顔を見せてくれるはずです。
入門書を1冊終えたということは、部品はもう手元にあるということです。あとはつなげるだけ。焦らず、1つずつ足していきましょう。



