はじめに
本番環境などでやらかしてしまった人Advent Calendar2025の7日目です！
昨年も参加させていただきまして、自分の愚かさを世に放出してみました。
昨年の記事はこちら👇
今回も私の失敗談を自戒の念を込めて書き下ろします。
中規模拠点のネットワークリプレイスで起きた話です。
皆さんにとっても何か学びを得られる機会になるといいな。
- 私について
普段は自称ネットワークエンジニアとして大胆に働いています。
ネットワークに関する軽微な変更であれば自分で手を動かすこともありますが、
一定規模以上では社内外のメンバーと協力し、PM的な立場で案件を進めることも多いです。
今回のお話はどちらかというと案件をマネジメントする立場で起きたやらかしのおはなしです。
背景
数週間前、私はある拠点のネットワークのリプレイスを完了していた。
リプレイス内容は、回線の増強と主要ネットワーク機器の入れ替え。
海外メーカーから国産メーカーへの変更があり、変更後はマルチベンダー環境にもなるなど、少し複雑な設計だったが、やりきった達成感を覚えていた。
何が起きたか
契機
ある日メンバーから別拠点の経路情報の差分について報告を受けた。
「リプレイス前にはあった経路がリプレイス後に無くなっていますよ」
ネットワークエンジニアのみなさん、いや、全人類が恐れるこの言葉。
「あるはずの経路がない」
「あるはずのものがない」
さあ、みなさんも恐々としてきましたね？
その経路情報は、とある管理設定の動作に関わりそうな情報だった。
調査を進めていくと、うん、他拠点の時刻同期がとれていない…
Clock is unsynchronized,に行きついた。
ミスの特定
さらに調査を進めると、経路広報が出来ていないうえ、管理アドレスの設定も抜けてしまっていた。管理用の仮想アドレスの設定とそのアドレスの広報、という二つの漏れが今回のミスの根っこであった。
同期がとれている場合はClock is synchronized,みたいになります
ちなみに...
時刻同期がとれていないと、どういう懸念が出るだろうか？
ネットワークスペシャリスト試験や情報処理安全確保支援士の試験にも出てきそうなので、是非考えてほしい。
私が思いつくのは以下の通り。
-
ログのタイムスタンプがずれ、トラブルシュートが破滅的に難しくなる
→ 監視ツールと併走している環境では特に致命的 -
監視・管理系の自動制御のトリガーにズレが出る
→ 閾値超過の判断が遅れたり、逆に誤作動したり -
経路制御の更新タイミングに影響する
→ 学習した経路の更新時が意図しない経過時間になる
同期が外れても最初はズレていないのでClockだけ見ても気付きにくいが、
これがほんとにじわじわズレていくのである。
なぜ起きてしまったか
リプレイス前には存在していた設定が、リプレイス後には無くなっていた。
原因を考えよう。
1. レビュー不足
原因を振り返ると、設計を踏襲しつつも一部で構成変更があるという状況に、レビュー体制がうまく適応できていなかったことが大きかったように思う。ミスが入り込む余地があった。
-
Configが真実という意識の弱さ
設計書・パラメータシート・設定ファイル（Config）の三点はきちんと作り込んでいた。設計書やパラメータシートには項目として明記してあり、そこを読んだ段階では「書いてあるし大丈夫だろう」と思い込める。一方で、設計意図が実際に反映されるべき Config ファイルは、読み解く負荷も高いし、「あるはず」と都合の良い解釈をしてしまった。結果として、「設計上は正しいが、Configに落ちていない」というギャップを見逃した。 -
信頼という名の思い込み
また、提供された設定ファイル（Config）のレビューをしたつもりになっていた点も反省点である。実際には、既存構成と新構成の差分、他拠点との依存関係まで含めた統合レビューが不十分で、前提として踏襲すべき設定が、そのまま次の世代へ渡されていない箇所があったのだから。
2. テスト項目不足
もうひとつの大きな要因は、テスト項目の不足が挙げられる。対象機器はネットワーク装置ではあるが、同時に他拠点から参照されるサーバとしての役割も持っていた。
-
繋がっていればOKというゴール設定の甘さ
普段は通信系のテストに重点が置かれがちだが、今回はその「サーバとして動作しているか」という視点が抜け落ちていた。実際、今回の設定漏れは 実通信には影響しないため、従来のテスト項目だけでは検知できない。「問題が起きない＝成功」ではなく、依存されているサービスが正常に動いているかを積極的に確認する必要があったことを痛感した。サーバ視点のテストを設計段階で組み込めていなかったことが、発見の遅れにつながったのだ。
今回の設定漏れは、以上のふたつが組み合わさって起きたものでした。
どちらも工程としてはありがちなポイントで、だからこそ、次に繰り返さないために何を変えるかが重要だと感じています。
おわりに
今後に向けて活かしたい教訓を列挙します。
明日の自分の行動を変えるヒントになりますように🙏
- 他者が作成したConfigでも最終責任は受け取る側（自分）
- だからこそ、安心せずに自分の目で確認することが大切で、Configを読み解くのが億劫にならないように研鑽し続ける
- レビュー体制は「完璧なものが出来上がっている」という前提にせず、自分の目でみる
- もちろん100%自責ではなくチームの仲間の力を借りることも必要
- サーバ機能・管理機能を持つ機器のリプレイスでは、その機器が他から同参照されているのか、正常時の動作の棚卸しが不可欠
失敗は、闇に葬らず、共有した方がみんなの役に立ちます。
私はそう信じて、今回も自分の失態を白日の下に晒しています。
最後まで読んでいただきありがとうございます。
来年もよろしくお願いします。（？）
宣伝🎉
Podcastをやっています！聞いてください！
ネットワークスペシャリストなどネットワークの勉強を頑張るみなさんに送る番組
情報処理安全確保支援士などセキュリティの勉強を頑張るみなさんに送る番組
Youtubeチャンネル「まさるの勉強部屋」のまさる（@masaru_benkyou）と、ネットワークエンジニアとして働くかとこ（@katokonigiry）が、ネットワークやセキュリティに関する問題をお互いに出題し合って雑談する番組です。「ちょっとした息抜きに聞けるのに勉強にもなっちゃうラジオ」をコンセプトにお送りしています🐵📻🐰
Youtubeでも更新しています！動画で見たい方や感想やコメントを送りたい方は、ぜひYoutubeも覗きに来てください！
以上、ここまで読んでいただきましてありがとうございました。感謝。