catch-img

無知の知~トラブル再現検証に参加してみて~

はじめに

パートナーブログをお読みいただいている皆様、はじめまして。筆者は、ネットワンパートナーズ株式会社で、セールスエンジニアとして業務に携わっている2年目メンバーの一人です。本記事では、駆け出しの筆者が日々の技術業務の一環として取り組んだ実機研修の内容と学びについて、技術課題に留まらずご紹介したいと思います。本稿は、”Beyond Blog” 記事の第5弾です。

実機検証とは?

実機検証は、名のとおり、実際に機器に設定を投入し、ネットワークを構成して動作確認を行うものです。そこには2つの側面があり、1つは機器の動作が想定どおりであるかを確認し、問題があれば解決策を探るもの(事前検証)、もう1つは運用で発生した事象を検証環境で再現し、トリガーと証拠を捉えるもの(再現検証)です。どちらも運用環境とまったく同じ機器構成で行えれば理想ですが、現実はそうもいきません。そのため実機検証では、コアのスイッチやファイアウォールなど着目すべき重要部分を最小構成で構築するテクニックが必要になります。

検証内容​

今回の課題は、次の事象(不具合)を捉えて、その証拠となるログを収集することです。

「L2SWと接続しているC9300X-12YにてRcv-Errが大量に発生する。当該接続インターフェイスをshut/no shutするとRcv-Errの増加が止まり、事象が解消する。Rcv-Errが発生する際、SymbolErr framesのカウントも同様に増加する。」

検証手法は、図1および図2のネットワーク構成において、Ping PC(左端; 172.24.16.101)からWS-C2960CX(右端 ;172.24.0.11)に連続してPingを実行中に、WS-C29600CXの電源OFF/ONを50回程度繰り返すことで、事象が再現するかを試みました。

当初、図1の構成で現象の再現を試みましたが、再現に至りませんでした。そこで先輩からの助言を受け、運用環境との差分を整理することにしました。​差分を洗い出したうえで、「再現性に影響がありそうなもの」から優先順位を付け、​一つずつ検証しながら差分を埋めていきました。​その結果、図2の構成で現象を再現することができました。​図1と図2の違いは、C9300X-12Yが単体構成であるかスタック構成であるかという点です。​今回の検証では、なぜこの違いによって現象再現の有無が変わったのかについては深掘りをしていません。ただし、現象が再現まで闇雲に試験を続けるのではなく、「影響のありそうな差分から優先的に潰していく」というアプローチの重要性を学びました。

図1 検証環境1

図2 検証環境2

検証で確認する不具合​

本事象は、メーカの開発チームで既知の不具合として挙げられているものです。一見、同じ事象が観察されていても、本当に当該不具合によるものなのかは、再現検証を行わなければ判断できません。不具合の概要は、次のとおりです。

① 何に不具合があったのか​
スイッチの1 Gbps 光インターフェース(GbE)におけるリンク初期化および再リンクアップ時のデータ転送処理に関連する問題でした。これは、特定の条件下において、インターフェースの物理層回りの処理が正常に完了しないことがあり、その結果、インターフェースのリンク状態はリンクアップしていると認識されるものの、通信の安定性やパケット転送に影響が出る可能性があるというものです。​

② 不具合の発生トリガーは何か​
スイッチの再起動(電源ONリスタートを含む)で、GbEが再リンクアップするタイミングがトリガーであり、作業後の(再)起動や停電復旧時に発生します。安定稼働中に発生するものではありません。​

③ 不具合をどのように改修したのか​

GbEのリンク初期化及び再リンクアップ時に実行する内部処理のコードが修正されました。​

④ 改修の有効性をどのように確認したのか​

メーカの開発チームによる検証などで、事象が再発せず、安定して通信ができることが確認されました。

難しかったところ1(準備~検証開始)​

実際にやってみて痛感したのは、「検証そのものよりも、そこに至るまでの環境作りが一番の山場だった」ということです。準備から検証開始までにぶつかった難所を振り返ります。​

1.機器の準備と接続​
まずは、機器を揃えるところからスタートしました。初めて借りる機器もあり、やや手こずりましたが、先輩に頼りながらなんとか揃えることができました。つぎに、設計図通りにケーブルを接続していくのですが、これにも大変神経を使いました。「SFPをどこに挿すのか」「光ケーブルの扱い方がわからない」といった初歩的な作業にも苦戦しました。ここでの「1本のケーブルの挿し間違い」が、後の数時間を奪うことにつながりかねないので、慎重に作業を行いました。​

2.設定コマンド投入​
機器の接続が終わったら、次は設定コマンドの投入(コンフィグファイルの流し込み)です。基本、事象が発生している機器での設定コマンドと同じものを投入します。設定コマンドは、一つひとつは簡潔なコマンドでも、数が増えれば話は別で、ペースト漏れはないか、設定の矛盾はないかなど、コンソール画面と睨めっこしながらコマンド投入の完全性を担保する作業は、かなりの集中力を要しました。また、今では当たり前のように行えている作業の「時短術」も、この実機検証で身に付けることができました。​

3.疎通確認とトラブルシューティング​
「よし、準備完了!」と意気揚々と Ping を打つものの、無情にも返ってくるのはタイムアウトの文字でした。ここからが本当の戦いです。「リンクはUPしているか?」「漏れている設定はないか?」「ケーブルは正しく挿してあるか?」など、どこに原因があるのかを切り分けるために、物理部分のチェックやshow コマンドを駆使しました(原因は前項の2つで、詳細は後述)。通信が通った瞬間の「安堵」と「感嘆」は、エンジニアならではの感動かもしれません。

難しかったところ2(検証開始~片付け)​

検証環境を無事に構成できたら、いよいよ検証開始で、ここからが本番です。検証開始から片付けまでの、自身のポイントを振り返ります。​

1.検証はひたすら集中​
検証作業は、自分にとって数時間にわたる一瞬も気が抜けない「全集中」の連続でした。showコマンドの出力結果を画面に張り付いて監視し続けながら、いつ起こるかわからない事象を待っている間の緊張には相当なものがあります。集中力が途切れて目を離した瞬間に限って事象が起きる「検証の魔物」との戦いであると言われる所以です。​

2.再現時のログ採取​
検証のハイライトは、狙っていた不具合の事象が再現された瞬間です。しかし、喜んでいる暇はありません。「再現した!でもログを取り忘れた…」これだけは絶対に許されないミスです。喜ぶ気持ちを抑え、予め決めた手順どおりに漏れなくログを採取します。取得ログのポイントは2つで、機器に事象が発生した証拠である「show コマンドの出力」と、そのときに通信していた「パケットキャプチャの保存」です。ログを確実に取得できているかどうかは、自身の作業に全て依存するので、まさにプレッシャーとの戦いでした。​

​3.機器を正しく返却​
無事、全ての検証項目が終わって、ようやく撤収です。ここで「終わったー!」と適当に片付けるのは禁物です。検証機は共用または借用物なので、単に機器を返却するだけでなく、「機器の初期化」「付属品(ケーブルやSFP)の欠品チェック」などを確実に行い、次に使う人の使用に支障がない状態に戻すことが求められます。重い機器を抱えて棚に戻しながら、「来た時よりも美しく」の精神で臨みました。

学んだこと​

検証作業で実際に手を動かし、「泥臭い」トラブルを乗り越えたからこそ見えてきた「3つの大きな学び」をまとめます。​

1.見落としがちな物理層​
物理層の確認の重要性を痛感しました。 SFPの差し込みの甘さや光ケーブルの挿し間違いは、コマンド設定による論理的な対応で解決できません。「物理層は正しく動作している」という確信が持てて、初めて次のステップに進めるものだと学びました。​

2.正しく設定を入れる​
どれだけ物理層が完璧でも、IPアドレスなどの論理設定に一つでもミスがあれば、通信は一切通りません。今回の検証でも、つながらない原因を突き詰めたら単純なIPアドレスの設定ミスだった、という「基本の怖さ」を学びました。一気に設定を流し込むのではなく、一つのインターフェースごとに「正しく入っているか」など、段階的に進めることが、結果として一番の近道なのだと実感しました。​

3.「現象の再現」は「検証の成功」と別物である​
前にも書きましたが、裏付けになる機器のログやパケットキャプチャがなければ、その成功を主張することはできません(「幻」と同じです)。検証現場では現象が再現した瞬間に「やった!」とガッツポーズしたくなります。しかし、再現検証で求められているものは、客観的に事象を説明し、それをメーカに申告して不具合修正に結び付ける「仕事の成功」です。検証作業で得たものを漏れなく次の作業につなげられるように、気を抜くことなく作業を行う大切さを学びました。​

4.エンジニアの品格​
最後の「機器の返却」にこそ、エンジニアとしての矜持が示されます。機器は会社の資産であり、破損させることなく返却し、付属品のチェックを徹底することは当然ですが、設定の初期化を徹底しておくことは、次にその機器を使う仲間への敬意でもあります。また、こうした所作の欠如は、お客様先での作業では信頼に直結します。最後まできっちり完了してこそ「仕事が終わった」と言えることを学びました。

おわりに​

検証作業、特に不具合検証は、「いつ再現するのか、いや、再現しないかもしれない」​という先の見えない作業でもあり、心身ともに疲弊するのは確かです。​しかし、ゼロから環境を構築し、Pingが通って準備が完了した瞬間の「快感」や、自らの手で問題を一つひとつ潰していく過程で得られる「手応え」は、参考書を読んでいるだけでは絶対に味わえません。​

今回の検証作業で得た、「環境準備」と「確実なログ採取」という経験は、これからどんなに複雑なネットワークを扱う際にも、重要な自分の武器の一つになると確信しています。そして、「検証は、準備に始まり、片付けに終わる。」この言葉を胸に、業務と向き合いたいと思います。最後までお読みいただき、ありがとうございました。

佐々野 市之助
佐々野 市之助
ご不明な点はお気軽に
お問い合わせください
ソリューション・カタログは
こちら

新着記事一覧

製品/ソリューションカタログはこちら
nopとは?

サイト内検索

記事カテゴリ一覧

目的から探す

人気記事