本文へ移動

インフラ転職コンパス現場・技術・キャリアをつなぐ専門メディア

メニュー

EOSとEOLの違いとは?ネットワーク機器の保守期限と更改

EOSは販売・software提供など特定段階の終了、EOLは製品life cycle全体の終了を指す文脈で使われます。ただしvendorごとに用語とmilestoneが違うため、告知文書のLast Date of Support、security update、契約更新期限を型番単位で確認します。

この記事でわかること

  • EOS・EOLの用語差
  • vendor告知で確認する日付
  • 保守切れ前の更改計画
  • 型番・license・spareの棚卸し

設計構築チャンネル関連動画:EOSとEOLとは?違いを解説。知らないとは言えないNW業界の必須知識
けんと@設計構築チャンネル
けんと@設計構築チャンネル
EOSは販売終了日だけでなく、保守・修正提供・契約終了日を機種ごとに管理します。一つの表示だけで決めず、構成図上の次の観測点と照合するのがポイントです。

EOSとEOLは何が違う?

先に答えると、EOSは販売・software提供など特定段階の終了、EOLは製品life cycle全体の終了を指す文脈で使われます。ただしvendorごとに用語とmilestoneが違うため、告知文書のLast Date of Support、security update、契約更新期限を型番単位で確認します。

保守期限はどの資料で確認する?

仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。

仕組みと判断軸
項目 仕組み・役割 実務での判断
End of Sale 新規販売終了 追加購入・license入手可否
End of Software Maintenance bug fix/maintenance終了 対象releaseを確認
End of Security Support security update終了 脆弱性対応risk
Last Date of Support vendor support終了 更改完了を前倒し
構成・処理フロー
告知確認 → inventory照合 → risk評価 → budget/調達 → design/test → migration
                                          ↑ Last Date of Supportより前に完了

更改時期をどう逆算する?

更改時期をどう逆算する?では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。

実行手順と完了条件
STEP 実施内容 確認する結果
1 device inventoryを型番・serial・versionで整備 対象漏れを防ぐ
2 vendor EoX noticeと契約を照合 日付と対象PID
3 設計・調達・test・移行期間を逆算 support終了前に完了
4 延期時の代替controlを承認 spare、segmentation、monitoring
設定・確認例(対象機種・OS・versionで確認してください)
show inventory
show version
show license summary

# 台帳列例
PID / Serial / OS / Support Contract / EoS / Last Support / Owner
正常時の出力例・記録例
PID: C9XXX-XX
OS: 17.x
EoX Notice: vendor document ID
Last Date of Support: YYYY-MM-DD
Migration owner/status: Network Team / Design

更改できない場合のriskをどう下げる?

一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。

正常時と異常時の切り分け
症状・誤り 主な原因候補 次に確認すること
型番が曖昧 同series内の対象違い PIDとhardware revision
OSだけ確認 hardware/support契約を見落とす inventoryと契約
期限直前に着手 調達・互換性test不足 lead time込みで逆算
延命を放置 security/support risk 期限付き代替control

台帳へ何を記録する?

EOL情報は更新されるため、記事の固定日付よりvendorの最新noticeを正本にします。更改計画には『確認日、document ID、対象PID、契約回答』を残し、口頭情報だけで予算を決めません。

  • 対象機器・interface・VRF/VLAN
  • 取得日時・timezone・software version
  • 変更前後の同一command出力
  • 期待値・実測値・判定者
  • 異常時の停止条件とrollback結果

関連する仕組みを次に確認する

定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。

まとめ:用語よりvendor milestoneと自社の完了期限を管理する

用語よりvendor milestoneと自社の完了期限を管理することが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。

最近の記事
お知らせ