はじめに
2022年頃、Juniper SRX320の保守を復活させようとして、かなり苦労したことがあります。
当時は、
- ルータが古い
- ファームウェアが更新できない
- 保守も切れている
- 調達元や構築元との関係も薄れている
- 予備機はあるが、そのまま使える状態ではない
という状況でした。
当時の自分は、
保守期限を年間スケジュールに登録して、更新漏れを防ごう
という結論にしました。
ただ、4年ほど経った今振り返ると、それだけでは足りなかったと思います。
この記事では、当時の経験をもとに、
ネットワーク機器を「動かす」だけではなく、「保守できる状態で維持する」ためには何を管理すべきか
を整理します。
きっかけは、既存ルータの不調
当時利用していたルータに不調がありました。
調査を依頼したところ、100Mbpsを超える通信で制限がかかるような状況になっていました。
そこでファームウェア更新を検討したのですが、問題がありました。
その機器を構築した会社とは、すでに10年以上コンタクトがありません。
さらにメーカー保守も切れていたため、正規ルートでファームウェアを入手できませんでした。
インターネット上を探せば、それらしいファームウェアが見つかることもあります。
ただし、ネットワークの中核機器に、出所の分からないファームウェアを適用するのはリスクがあります。
そこで、以前調達していたJuniper SRX320を使えないか検討しました。
SRX320はあった。しかし、使える状態ではなかった
SRX320は2017年頃に調達していた機器でした。
ただし、当時サーバールームの実務を担当していたパートナーから、保守契約の情報が十分に引き継がれていませんでした。
結果として、
- 保守契約は停止
- ファームウェアは古い
- 管理GUIも古いWeb技術に依存
- 正規にアップデートするには保守復活が必要
という状態でした。
ここで気付いたのが、
「機器が存在する」ことと「その機器を運用できる」ことは別
という点です。
予備機がラックや倉庫に置いてあっても、
- ファームウェアが古い
- ライセンスが切れている
- 設定が最新ではない
- 保守がない
- 管理方法が分からない
のであれば、障害時の代替機としては不十分です。
保守復活のハードル
過去の調達資料を探したところ、購入元や保守に関する情報が見つかりました。
そこで調達元経由で保守復活を依頼しました。
Juniper側にも確認したところ、保守を復活するためには、機器のInspection、つまり製品検査が必要とのことでした。
当時確認した条件では、
- Inspection費用は1台あたり約10万円
- 合格後に保守契約を再開可能
- 保守費用は別途
- 商流は複数社を経由
という状況でした。
さらに、最初の問い合わせから見積もりが出るまでにもかなり時間がかかりました。
機器が完全に故障してからこの確認を始めていたら、かなり厳しかったと思います。
問題は「保守切れ」だけではなかった
当時は単純に、
保守契約の更新を忘れた
という問題だと思っていました。
今考えると、実際には複数の問題が重なっていました。
1. 契約情報の属人化
保守契約が誰の管理なのか明確ではありませんでした。
担当者やパートナーが変わると、そのまま情報が失われる構造になっていました。
2. 機器情報と契約情報が分離していた
資産として機器が存在していても、
- どこから購入したか
- 誰が保守しているか
- 契約番号
- 契約期限
- 問い合わせ先
がひとまとまりになっていませんでした。
3. ファームウェア入手経路を考えていなかった
ネットワーク機器では、メーカーサイトから自由に最新版を取得できるとは限りません。
保守契約が、実質的にソフトウェア更新権でもあるケースがあります。
4. 予備機が「未検証」だった
予備機として保有していても、実際に切り替えられる状態か確認していませんでした。
今ならどう設計するか
現在なら、ネットワーク機器を単なる資産台帳ではなく、
運用可能性まで含めた構成管理台帳
として管理します。
最低限、以下のような項目を持たせます。
| 分類 | 項目 |
|---|---|
| 基本情報 | メーカー |
| 基本情報 | 製品名 |
| 基本情報 | 型番 |
| 基本情報 | シリアル番号 |
| 基本情報 | 設置場所 |
| 基本情報 | 管理IP |
| 導入情報 | 導入年月日 |
| 導入情報 | 購入元 |
| 導入情報 | 構築会社 |
| 保守情報 | 保守会社 |
| 保守情報 | 契約番号 |
| 保守情報 | 保守開始日 |
| 保守情報 | 保守終了日 |
| ライフサイクル | EOL |
| ライフサイクル | EOS |
| ソフトウェア | ファームウェアバージョン |
| バックアップ | 設定ファイル保存場所 |
| 運用 | 問い合わせ先 |
| 運用 | 管理担当者 |
| 更新 | 後継機候補 |
| 更新 | 更新予定時期 |
保守期限だけではなく、EOL/EOSも見る
保守契約が有効でも、製品自体がライフサイクル終了に近いことがあります。
逆に、機器が正常に動いていても、
- ファームウェア更新停止
- 脆弱性修正終了
- 部品交換不可
- 技術サポート終了
となる可能性があります。
そのため、
保守終了日だけでなく、メーカーのライフサイクル情報も管理対象
にします。
「壊れていないから使える」は危険
ネットワーク機器は長期間稼働します。
5年、7年、10年と使われることもあります。
そして、長期間安定して動いている機器ほど、更新が後回しになります。
しかし、
動いている
ことと、
安全に運用し続けられる
ことは同じではありません。
個人的には、以下の状態になった時点で更新検討対象にした方がよいと思います。
- 保守終了が近い
- EOSが近い
- セキュリティアップデートが終了する
- ファームウェア取得条件が厳しくなる
- 代替機の調達が難しい
- 設定変更できる担当者がいない
予備機も定期的に確認する
予備機を保有している場合、最低でも定期的に以下を確認します。
・起動できるか
・最新設定を投入できるか
・ファームウェアは適切か
・必要なライセンスは有効か
・管理者アカウントにログインできるか
・実際に切り替え可能か
つまり、
予備機を持つ
ではなく、
切り替え可能な予備環境を維持する
という考え方です。
保守期限は自動通知する
当時は、年間カレンダーに保守期限を登録する運用にしました。
今なら、もう少し自動化します。
例えば、ExcelやSharePoint Listなどで資産台帳を管理し、
- 180日前
- 90日前
- 30日前
に通知する仕組みを作ります。
Power AutomateでもGASでも実現できます。
例えば、以下のようなイメージです。
資産台帳
↓
毎日定期実行
↓
保守終了日をチェック
↓
180日前 / 90日前 / 30日前
↓
担当者へ通知
こうしておけば、
人が覚えていることを前提にしない運用
にできます。
CSVやJSONで出せる形にしておく
さらに、資産情報をCSVやJSONとして扱えるようにしておくと便利です。
例えばJSONなら、以下のようなイメージです。
{
"vendor": "Juniper",
"model": "SRX320",
"serial_number": "XXXXXXXX",
"firmware_version": "xx.x",
"support_end_date": "2027-03-31",
"eos_date": "2028-03-31",
"config_backup": "\\\\server\\network\\srx320.conf",
"support_vendor": "XXX",
"replacement_plan": "2027年度"
}
こうしておけば、
- PowerShell
- Python
- Power Automate
- GAS
- BIツール
などとも連携しやすくなります。
さらに現在であれば、AIに資産一覧を渡して、
・1年以内に保守切れする機器を抽出
・EOSが近い機器を抽出
・設定バックアップが未登録の機器を抽出
・問い合わせ先が不明な機器を抽出
といったチェックを行うこともできます。
インフラ管理では「情報の保守」も必要
この経験から一番大きく感じたのは、
ハードウェアだけを保守しても足りない
ということです。
必要なのは、
- 機器
- 設定
- ファームウェア
- 契約
- ベンダー
- 問い合わせ先
- ライフサイクル
- 更新計画
をまとめて管理することです。
特に担当変更が多い環境では、
誰かが知っている
状態をできるだけ減らす必要があります。
まとめ
4年前、Juniper SRX320の保守復活でかなり苦労しました。
当時は、
保守期限をカレンダーで管理する
という結論でした。
今なら、もう少し広く考えます。
管理したいもの
・機器情報
・保守契約
・EOL / EOS
・ファームウェア
・設定バックアップ
・問い合わせ先
・代替機
・更新予定
さらに、
台帳化
↓
定期チェック
↓
期限前通知
↓
更新判断
まで仕組みにします。
インフラは正常に動いている間、問題が見えにくいものです。
だからこそ、
「今動いているか」ではなく、「壊れたときに復旧できる状態か」
まで含めて設計する必要があります。
当時の自分に一言で伝えるなら、
保守期限だけではなく、「その機器を将来も扱える状態か」を管理しよう。
ということになると思います。