以下のようなお悩みをお持ちではありませんか？
- 「実際にどんな作業をしているのか」
- 「機器を構築したあと、何をしているのか」
ネットワークエンジニアに興味がある方にとって、このあたりはイメージしづらいと感じることが多いと思います。
自分も最初は、機器の設定がネットワークエンジニアの仕事の大半だと思っていました。
ただ、実際の現場では構築のあとに「テスト」という工程があります。
このテストをどこまでやるかで、
本番環境での作業の成功確率・安定度は大きく変わります。
今回は、ネットワーク機器の構築が完了したあとに行うテストについて、
現場で実際にやっている内容をベースに整理します。
- どのくらいのレベル感で確認しているのか
- どこまで細かく見るのか
といった、現場の実態がイメージできるようにまとめています。
この記事は、現職でネットワークエンジニアとして業務を行っている私の経験をもとに書いています。
※勤め先の会社によって内容は多少異なる点がありますが、参考程度に読んでください。
＼プロのアドバイザーと無料相談ができる！／
ネットワーク機器のテストは3つに分かれる
現場で行うテストは、大きく分けると次の3つです。
- 単体テスト
- 結合テスト
- 障害テスト
名前はシンプルですが、それぞれ役割が違います。
どれか一つでも抜けると、本番で問題が出る可能性があります。
テストは仕様書ベースで進める
まず、前提をお話ししておくと
テストはその場の判断で進めるものではありません。
事前にテスト仕様書を作成し、それに沿って実施します。
仕様書には、主に次のような内容をまとめます。
- 実施するテスト内容
- 操作手順
- 想定結果
ドキュメントのフォーマットは会社、テスト仕様書の作成者によって異なりますが、
大まかには上記ような内容を網羅したドキュメントに従って作業を進めていきます。
想定結果を決めてから動かす
テストでは、「どうなれば想定通りか」を事前に決めておきます。
例えば、
- pingが通る
- ルーティングが切り替わる
- ログが出力される
といった状態です。
基本的には想定通りに動きますが、
障害テストなどでは当初に想定した結果とズレることもあります。
その場合は、
- showコマンドで状態確認
- ログの確認
- コンフィグの見直し
といった流れで切り分けていきます。
単体テスト：まずは機器単体の正常性を確認する
単体テストでは、機器そのものが正常に動いているかを確認します。
確認するポイントはシンプルで、
- 正常に起動するか
- ライセンスが適用されているか
- コンフィグが正しく投入されているか
といった基本的な内容です。
一見当たり前に見えますが、
ここでミスが出ることもあります。
例えば、
- コンフィグの一部が入っていない
- ライセンス未適用で機能が使えない
といったケースになります。
この段階で不備があると、
後工程に影響しますので機器の正常性を確認する上で「単体テスト」が重要になります。
そのため、作業内容は地味ですが、丁寧に確認しておく必要があります。
結合テスト：本番環境を疑似的に再現して確認する
単体で問題がなくても、
他の機器と接続した際、想定通りに通信が行えないといったがあります。
そのため、
実際の構成に近い形で機器を接続し、通信や機能が成立するかを確認していきます。
まずは疎通確認から入ります。
- pingが通るか
- どこまで通信できるか
基本的には想定した宛先に対してPingが全て通ることが前提です。
もし、Pingが通らない等の問題があれば、設定や経路に原因がある可能性が高いです。
通信が正常に行えているかを簡易的に確認するコマンド（手法）になります。
疎通確認が終わりましたら、必要に応じて機能試験も行います。（実施するケースは体感として多いです）
- NTP（時刻同期）
- SSHやTelnet（リモートログイン）
- SNMP / Syslog（監視・ログ）
- ルーティング（OSPF / BGP など）
ここは案件ごとに内容が変わるため、
要件に応じて確認ポイントを決めていきます。
障害テスト：意図的に通信障害を起こして復旧するか確認する
障害テストでは、実際に通信障害を発生させて機器の動作を確認します。
ここで本番環境に何か障害が起こった際に、
想定通りに通信が復旧するのかという近い挙動が見えてきます。
例えば、
- WAN側のケーブルを抜いて経路障害を発生させる
- EtherChannelの片系リンクをダウンさせる
- ポートをshutdownして物理障害を再現する
といった方法でテストを行います。
このときに重要なのは、
「通信が戻るか」だけを見るのではないという点です。
通信が復旧したあとに、
- ルーティングがどう変わったか
- インターフェースの状態はどうなっているか
- ログに何が出ているか
といった部分まで確認します。
どのコマンドでどこを見るのかを事前に決めておかないと、
正常に通信が復旧したのか判断できなくなる為です。
この準備も含めて、テストの一部になります。
正直な話：テストは地味な作業
ここまで読んでもらうと分かる通り、
テスト作業はそこまで派手ではありません。
- 正常系は想定通りに動くことが多い
- 作業としてはルーチン化しやすい
そのため、人によっては単調に感じることもあるかもしれません。
個人的な意見にはなりますが、
ネットワークエンジニアはこのような作業が多いので、向き不向きが分かれる仕事だと考えます。
細かい確認を積み重ねることが前提になります。
こういった作業が苦にならないかは判断の一つのポイントです。
もしこのあたりで、
「自分に合うのか分らない」と感じた場合
プロの転職アドバイザーに意見を聞いてみるのも判断する上でアリな選択肢です。
私はレバテックキャリアを用いて転職を成功させました。
私と同じようにネットワークエンジニアに興味がある方は、
一度以下のボタンから登録を進めてプロのアドバイザーに相談してみてください。
＼プロのアドバイザーと無料相談ができる！／
ネットワークエンジニアのキャリアに迷いがある人へ
ネットワークエンジニアといっても、
案件によって仕事内容は大きく変わります。
- 構築がメインの案件
- 運用・保守が中心の案件
関わるフェーズによって、求められるスキルも働き方も変わります。
そのため、
「思っていた仕事と違った」と感じるかどうかは、どの案件に入るかに左右される部分があります。
もし少しでも将来のキャリアに不安があるのであれば、
- 自分のスキルでどんな案件があるのか
- 自身の市場価値はどのくらいか
などを転職活動を通じて一度見ておくと、今後キャリアの判断がしやすくなります。
＼レバテックキャリアに1分で登録完了／
まとめ
ネットワーク機器のテストは、
単体・結合・障害の3つに分かれており、それぞれ役割があります。
どれも地味な作業ですが、
- 想定結果を決めてから実施する
- 想定とズレていないかを確認する
といった積み重ねが、本番作業の「質」に大きくつながります。
設定して終わりではなく、
その後の確認まで含めてがネットワークエンジニアの仕事です。
今回の内容で、
現場でどのくらいのレベル感で作業しているのかが、少しでも伝わればとうれしい限りです。
コメント