運び屋 (A carrier(forwarder) changed his career to an engineer)

Network / Cloud Native / Kubernetes / コンテナー / SRE / DevOps

GNS3で所属プロジェクト向けにネットワーク技術のトレーニングメニューを作ってみた(導入編)

先日、英語でのAWS合格体験記をMediumに書き、一安心して時間が空いてしまいました。 その間に、タイトルの通りに所属しているプロジェクト用のトレーニングメニューを検証/リリースしていました。 今回はその話を書こうと思います。実は私、AWS受験したり、コンテナ技術に興味がありますが、ネットワークがメインなのです。

ここで話すこと

  • なぜトレーニングメニューを考えたのか
  • なぜGNS3なのか
  • 現状と課題
  • 準備期間
  • 行った準備
  • 課題作成時のポイント
  • 今後の目標

ここで話さないこと

  • 案件の実際の構成や機器
  • GNS3のインストール方法などについて
  • GNS3以外の仮想環境について

なぜトレーニングメニューを考えたのか

理由は主に下記の3つです。

実機での操作には制約があり、自由に使える検証環境を持っていない為

ここでいう実機とは、サービスが乗っている機器の事であり、showコマンドでも機器に負荷を掛け過ぎるコマンドは打てませんし、 ノードやインターフェイスをDown/Upさせる事もサービス影響が出る、もしくは出る可能性がありますので、できません。

同一プロジェクトの運用チームから設計構築チームに7月に異動し、運用チームに明確な技術的ステップアップの道を作りたかった

運用メンバーとして案件で身に付けておきたい対応、対応できる様に求められている事はリスト化されております。 フローも基本的に明確に決まっていて、必要があれば更新しているので、対応を重ねていけばドンドン仕事ができる様になります。 ところが、実対応が発生するかどうかは良くも悪くも「運次第」という所があり、障害を引いていない人はシミュレーションで補う様になっています。 シミュレーションは出題者が障害対応の経験者が出すので、本番以上に厳しい目でチェックを受けられるのは良いのですが、 上記の通り実機操作が障害内容によっては、本番の様にはできません。 本人のやる気とは関係無しに対応経験値に差が出てしまうので、技術の理解を自身で深めていける、差を埋めていける環境を作りたいと考えました。

自身の個人目標の達成/評価制度の一環

自己紹介前回のAWS合格体験記でも触れましたが、私は元々IT業界をほぼ未経験で現職に就いており、 「一人称では仕事ができない」という状態でプロジェクトに参加しました。一年の間に現場の仕事を覚えて、色々と動いた結果「一人称で仕事ができる」という評価になりました。 次のステップとして、「メンバーの教育ができる事」などが職種を問わず、要件としてあります。分かりやすく達成する為に上記理由と併せて作成を始めました。

*自社の評価制度に関する事なので正確な文言はあえて使わず曖昧な表現にしてあります

なぜGNS3なのか

理由は主に下記の2つです。

昨年も前任者を中心にGNS3を使ってトレーニングメニューを作成/実施していた事

私は問題を解く側として誰よりも試行錯誤を繰り返しながらネットワーク技術の理解を深めました。 上手くいかない事を含めて、有識者に教わりながら課題を解決していく事が「楽しい」と思いました。

検証に必要なイメージを持っており、追加のリソース購入/構築が不要

複数のベンダー機器のイメージをプロジェクトで持っており、ある程度柔軟に条件の設定ができます。

現状

現状

  • 運用のメンバーは業務経験は様々。私の様に未経験者もいれば、私よりも年上で運用以外の経験も積んできた方もいます。
  • 取り扱う案件や構成は複数あり、全てのシミュレーションを端から端まで行うのは非現実
  • 緊急性、重要度、影響範囲、発生頻度、などから優先順位を付けてシミュレーションを行っている

準備期間

期間 やったこと
2019年7月 構築チームに異動。担当する構成の確認をしつつ、
GNS3のトレーニングメニューへの反映を模索
2019年8月 レベル1(導入編)を作成し、リリース。
レベル2.0(リーダーレベルへの昇格編)の作成開始
2019年9月前半 レベル2.0が作成/検証に時間を要する事、
深堀りできる要素が多い事が判明し、2つ(1.5を追加)に分ける事を決定
2019年9月後半 レベル1.5(ネットワーク構築編)を検証し、リリース。
レベル2.0は10月前半のリリースを目標に

事務的に準備したこと

  • 上長との実施内容/予定の合意
  • 問題の作成、実行環境の構築
  • チームリーダー陣への先行リリース/フィードバック
  • チームメンバーへの事前アナウンス

課題内容(大問名のみ。個別の問題、詳細は割愛)

<レベル1.0>

  • 1.Ciscoルータ - ホスト名の設定
  • 2.各RouterのインターフェースのIPアドレス設定、インターフェースの有効化 / 無効化、実対応への適用
  • 3.ping疎通確認(サイズ/回数/フラグメントなどのオプション設定)
  • 4.インターフェースのdescription設定 / インターフェイスの状態確認
  • 5.各種showコマンド集(ソフトウェア)
  • 6.各種showコマンド集(ハードウェア)
  • 7.Loopbackアドレス作成およびping疎通確認
    f:id:Yoshiki0705:20190924085744p:plain
    レベル1.0イメージ

<レベル1.5>

  • 1.acl設定(IP/Port単位/pingの遮断可否など)
  • 2.FHRP(First Hop Resolution Protocol)設定(VRRP/HSRP)
  • 3.eBGP設定(タイマー設定など)
  • 4.iBGP設定(OSPF/再配送/オプション設定などに)
  • 5.BGPポリシー分析および設定
    f:id:Yoshiki0705:20190924171056p:plain
    レベル1.5イメージ

<レベル2.0>予定

  • 1.LAG設定
  • 2.再配送設定(集約アドレス)
  • 3.経路情報確認
  • 4.各種テーブル確認
  • 5.VRFの設定

課題作成時のポイント

実務で役に立つ事に絞る

「資格でしか使わない」「IT昔話」はそこに興味がある特殊な人しか触れたくないと思うので、 「実際の案件で使っている技術」「2019年現在、汎用的に使える/覚えておきたい技術」にテーマと質問を絞りました。

選択したり、解いたら終わりの問題にしない

問題/課題が解決したログや根拠、背景となる技術への理解を確認する為の質問を投げ掛ける部分を作りました。 各大問の理解ができているか、深堀りして欲しいポイントをフィードバックしています。

強制参加にしない

前提として、昨年も強制参加ではありませんでした。ただし、やる/やらないの意思表明や理由が必要とされていました。 今回は、「レベルアップの条件」とする事で、必要/意思がある人が実施する様に設計しました。 「やらされている感」が出てしまうと、途端に人はやらなくなったり、自分がやらないだけならば良いのですが、 「頑張っている人の足を引っ張る/やる気を奪う」という行為に出る傾向があります。 ここは、特に重要な部分と考えています。今後の運用を注視していきます。

今後の目標

レベル2.0の作成/検証

レベル2.0の問題はまだ深堀りできていない為、問題の要件定義を実施中です。 要件定義ができたら自身で検証を行い、上長のチェックを経てリリースします。

マルチベンダー環境での設問

今回は手軽にスタートできる事を優先し、Cisco機器のみの環境設定としましたが、 他のベンダー機器を入れたり、メインにした構成も作ろうと企んでいます。

仮想環境での操作を前提としたシミュレーションメニューの作成

運用チームのシミュレーションではインターフェイスやBGPのshutdownなどの操作が実機ではできないので省略していますが、 仮想環境では問題無く試せるので、そうしたメニューの開発もサクサクできればと思います。

Contributor、Maintainerの育成

私がこうして去年の施策をヒントに定常的なメニュー作成を企画、実行しているわけですが、 これも属人的なものではなく、業務改善活動の一部としていきたいと思っています。

問題を作成する人、検証/査閲を行う人を育成し、業務フローに落とし込めればと考えています。 今後の業務自動化も視野に入れた、業務改善活動をもう一歩進めていきたい。

問題の詳細もニーズがあれば公開できるものだと思いますが、別途確認/調整が必要だと考えましたので、 今回は控えさせて頂きました。

では、また。

Bye now!!

Yoshiki Fujiwara