こんにちは、インフラエンジニアのryuです。
現場に入ってしばらくすると、共有フォルダの奥にあるExcelファイルを開くよう言われることがあります。
シート名は「パラメータシート」。開いてみると、ホスト名、IPアドレス、タイムゾーン、ユーザー名、サービスの起動設定……と、値がただひたすら並んでいます。
正直に言うと、初めて見たとき、私はこれを「読むもの」だと思っていませんでした。構築の人が値を写すための、ただの転記元だと思っていたのです。
でも、このいちばん地味な表こそ、未経験のうちに読み方を覚えておくと得をする資料です。今日は、パラメータシートの正体と読み方を、できるだけ現場の感覚に近い形でお話しします。
そもそもパラメータシートって、何のための表なのでしょうか？¶
インフラの設計書には、大きく分けて2つの層があります。
ひとつは、システムの方針や骨格を決める基本設計書。もうひとつは、その方針を具体的な値に落とし込んだ詳細設計書です。パラメータシートは、この詳細設計書の中心にある表だと考えてください。
呼び方は会社によってばらばらで、詳細設計書、環境設計書、パラメータシートが実質同じものを指していることもよくあります。名前に惑わされず、中身が「値の一覧」かどうかで判断すると迷いません。
基本設計書との関係は、間取り図と家具の配置表¶
家を建てるときの話にたとえてみましょう。
基本設計書は間取り図です。「リビングは南向き」「寝室は2階」といった、暮らし方の方針が描かれています。
一方のパラメータシートは、家具の配置表です。「ソファは窓から80cm離す」「照明は3000Kの電球色」と、具体的な数字だけが書かれています。
配置表だけを見ても、なぜ80cmなのかは分かりません。でも間取り図と重ねると、「ここは通路になるから空けてあるんだな」と理由が見えてきます。
パラメータシートの値は、単独では意味を語りません。基本設計書の方針と重ねて読んだときに、はじめて「なぜこの値なのか」が分かります。
つまりパラメータシートは、基本設計で決めた方針を、誰が作業しても同じ結果になるように数値へ翻訳した表です。ここを押さえておくと、読み方がぐっと変わります。
手順書とは、役割がはっきり違う¶
以前、手順書をそのまま実行する前に確かめることという記事を書きました。手順書とパラメータシートは、よく一緒に渡されるので混同されがちです。
違いを表にするとこうなります。
| 資料 | 書いてあること | たとえるなら |
|---|---|---|
| 基本設計書 | 方針・構成・採用する方式 | 間取り図 |
| パラメータシート | 設定する値そのもの | 家具の配置表 |
| 手順書 | 値をどの順番で、どう設定するか | 引っ越し業者の作業手順 |
手順書は「どうやって」、パラメータシートは「何を」を担当しています。手順書の中に「パラメータシートのNo.12の値を設定する」と書かれていることも多く、2つはセットで動くものだと考えてください。
実際のパラメータシートを見てみよう¶
では、よくある形を見てみましょう。ここではLinuxサーバー1台ぶんの、ごく一部を抜き出したイメージです。
| No | 分類 | 項目 | 設定値 | 備考 |
|---|---|---|---|---|
| 1 | OS | ホスト名 | web01 |
命名規約に従う |
| 2 | OS | タイムゾーン | Asia/Tokyo |
|
| 3 | ネットワーク | IPアドレス | 192.168.10.11/24 |
サービスセグメント |
| 4 | ネットワーク | デフォルトゲートウェイ | 192.168.10.1 |
|
| 5 | 時刻同期 | 参照先 | ntp1.example.local |
社内NTP |
| 6 | SSH | PermitRootLogin | no |
セキュリティ方針による |
| 7 | SSH | PasswordAuthentication | no |
鍵認証のみ |
見た目は本当に地味ですよね。でも、この表には読み方のコツがいくつかあります。
列ごとに役割がある¶
まず注目してほしいのは、列の意味です。
No列は、手順書や試験項目書から参照されるための番号です。「No.6を確認」と言われたら、この行を指します。番号が振り直されると他の資料とのつながりが切れるので、勝手に並べ替えてはいけません。
分類列は、どの層の設定かを示しています。OS、ネットワーク、ミドルウェア、アプリケーションと、下から上へ積み上がる順番で並んでいることが多いです。この順番自体が、構築の順番のヒントになっています。
そして、いちばん大事なのが備考列です。
備考欄は「理由の入口」¶
多くの人は設定値の列だけを見ます。でも、設計の意図がにじみ出るのは備考欄のほうです。
たとえばNo.6の「セキュリティ方針による」。これは、基本設計書かセキュリティ方針の文書に、rootでの直接ログインを禁止する理由が書いてあるという合図です。
備考が空欄の行もあります。空欄は「理由がない」のではなく、「デフォルト値から変える理由がない」か「書き忘れ」のどちらかです。どちらなのかを先輩に聞けるようになると、表の読み方が一段深くなります。
値を見たら「なぜ？」を1つ添えてみる¶
ここからが、未経験のうちにやっておくと伸びる練習です。
パラメータシートの行を1つ選んで、その値がなぜそうなっているのかを、自分の言葉で1行書いてみてください。
たとえばこんな具合です。
No.2 タイムゾーン Asia/Tokyo
→ ログの時刻を日本時間でそろえ、障害時に他のサーバーと突き合わせやすくするため？
No.5 NTP参照先 社内NTP
→ インターネットへ直接出られないセグメントだから、社内の時刻サーバーを経由している？
No.7 PasswordAuthentication no
→ パスワード総当たり攻撃を避けるため、鍵認証だけに絞っている？
最後の「？」が大切です。正解かどうかは、この時点では分からなくてかまいません。
仮説を立ててから基本設計書や先輩に確かめると、答えがただの暗記ではなく、理由つきの知識として残ります。No.7の話であれば、鍵認証がうまくいかないときの調べ方をPermission denied (publickey) の原因を突き止める記事にまとめているので、あわせて読むとつながりが見えるはずです。
値の出どころは、たいてい3つのどれか¶
「なぜこの値？」と考えるとき、出どころはおおむね次の3つに分かれます。
| 出どころ | 例 | 確認先 |
|---|---|---|
| 要件・方針 | rootログイン禁止、ログ保存期間 | 基本設計書、セキュリティ方針 |
| 環境の都合 | IPアドレス、NTP参照先、DNSサーバー | ネットワーク設計書、構成図 |
| 製品の推奨・既定値 | カーネルパラメータ、ミドルウェアの初期値 | 公式ドキュメント |
1つ目の要件や方針について、日本の現場では、IPAが公開している非機能要求グレードを下敷きにして、可用性や性能、セキュリティなどの要求を整理することがあります。パラメータシートの値をさかのぼっていくと、こうした要求の一行にたどり着くことも珍しくありません。
3つ目の製品の既定値については、公式ドキュメントが答えを持っています。たとえば sshd_config の各項目の意味や既定値は、OpenSSHのマニュアルに書かれています。公式ドキュメントの探し方は、公式ドキュメントの読み方で詳しく書きました。
表と実機を突き合わせてみよう¶
パラメータシートは読むだけでなく、実機と見比べて初めて本領を発揮します。
構築が終わったあとの確認作業や、障害対応で「本当に設計どおりになっているか」を見るとき、手元のサーバーで値を取ってきて表と照らし合わせます。
先ほどの表に対応する確認コマンドは、たとえばこうなります。
# No.1 ホスト名
hostnamectl --static
# No.2 タイムゾーン
timedatectl show --property=Timezone
# No.3・No.4 IPアドレスとデフォルトゲートウェイ
ip -br addr show
ip route show default
# No.5 時刻同期の参照先（chronyの場合）
chronyc sources
# No.6・No.7 sshdが実際に読み込んでいる設定値
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
最後の sshd -T は、覚えておくと便利です。設定ファイルを目で読むのではなく、sshdが実際に解釈した結果を表示してくれます。
設定ファイルの中に同じ項目が2回書かれていたり、別ファイルから読み込まれていたりすると、ファイルを眺めるだけでは本当の値を見誤ります。パラメータシートと突き合わせるのは、ファイルの字面ではなく、動いているプロセスが使っている値のほうだと覚えておいてください。
ズレを見つけたら、どちらが正しいかを決めつけない¶
突き合わせをしていると、表と実機の値が違うことがあります。
ここで大事なのは、どちらかを勝手に直さないことです。
実機が間違っているとは限りません。障害対応で一時的に値を変え、そのまま表の更新が漏れているのかもしれません。逆に、誰かが設計にない変更を入れてしまったのかもしれません。
どちらのケースなのかは、変更履歴や作業記録を見ないと判断できません。ズレを見つけたら、行番号と実機の値をそのままメモして報告する。それが新人のうちにできる、いちばん価値のある動きです。
パラメータシートと実機のズレは、事故の種であると同時に、チームの運用の弱いところを教えてくれるサインでもあります。
ズレの報告を嫌がる現場はまずありません。むしろ、表が信用できる状態を保つことは、チーム全員を助けます。
表にも「版」がある¶
もうひとつ、見落としがちなのが版の情報です。
パラメータシートの表紙や最初のシートには、たいてい改版履歴があります。いつ、誰が、どの行を、なぜ変えたのか。ここを読まずに値だけを見ていると、古い版を開いたまま作業してしまう事故が起こります。
共有フォルダに「パラメータシート_最新.xlsx」と「パラメータシート_最新_修正版.xlsx」が並んでいる光景は、残念ながら珍しくありません。どちらが本物かを自分で判断せず、正本の置き場所を先輩に確認しておくと安心です。
改版履歴は、設計の歴史書でもあります。「2年前にNTPの参照先を変更」「昨年ログの保存期間を延長」と追っていくと、このシステムがどんなトラブルを経験してきたのかが、うっすら見えてきます。障害対応の振り返りがきっかけで値が変わった行は、たいてい備考欄にも何かしら書かれています。
新しい現場に入ったら、値の一覧より先に、改版履歴を上から眺めてみてください。そのシステムの性格が、意外なほどよく分かります。
自分でも小さなパラメータシートを作ってみる¶
最後に、学習中の方にすすめたい練習があります。
自宅の検証環境やクラウドの練習用サーバーを1台立てたら、その設定を自分用のパラメータシートにまとめてみるのです。
最初は10行ほどで十分です。ホスト名、IPアドレス、タイムゾーン、作成したユーザー、開けたポート、有効にしたサービス。これを表にして、備考欄に「なぜそうしたか」を1行ずつ書きます。
やってみると、意外なことに気づきます。「なんとなく」で決めた値が、思った以上に多いのです。
チュートリアルに書いてあったから、デフォルトのままだったから。そうした値は、備考欄に書く理由がすぐには出てきません。でも、それで正常です。理由が書けない行こそ、次に調べるべきテーマを教えてくれています。
その「なんとなく」に理由をつけようとした瞬間、ネットワークやLinuxの知識が必要になります。サブネットをどう切るか迷ったらサブネット計算の練習メニューが役に立つでしょうし、サーバーを立てるところから始めたい方はLinuxの基本コマンドから手を動かしてみてください。
作った表は、そのままポートフォリオの材料になる¶
自分で書いたパラメータシートは、学習記録としても使えます。
転職活動の面接で「検証環境で何をしましたか」と聞かれたとき、構成図とパラメータシートを見せられる未経験者は多くありません。値を並べただけでなく、備考に理由まで書いてあれば、それは立派な設計の練習の跡です。
InfraAcademyのLinuxロードマップでは、サーバーを実際に構築しながら学ぶ流れを用意しています。構築した環境をそのまま題材にして、自分用のパラメータシートを作ってみるのもおすすめです。ネットワークから固めたい方はネットワークロードマップもあわせて使ってみてください。
まとめ¶
パラメータシートは、設計書の中でいちばん地味に見える表です。でも、その地味さの奥には設計の判断がぎっしり詰まっています。
今日のポイントを振り返っておきます。
- パラメータシートは、基本設計の方針を具体的な値に翻訳した表
- 手順書が「どうやって」、パラメータシートは「何を」を担当する
- 値の理由は、要件・環境の都合・製品の既定値のどれかにたどり着く
- 突き合わせは、ファイルの字面ではなく実際に動いている値で行う
- ズレを見つけたら直さずに、行番号と実機の値を添えて報告する
値を見たら「なぜ？」を1つ添える。この小さな習慣が、転記係から設計が読めるインフラエンジニアへの一歩になります。
明日、パラメータシートを開いたら、まず備考欄から読んでみてください。きっと、昨日とは違う表に見えるはずです。
