今日はトラブルシューティングの中でも複合的な要素が重なり合って発生するトラブルって、問題の絞り込みが大変ですね、というご報告です。
いや、人によってはそうでもないのかな。個人的には結構シンドイです。
トラブル発生
例えば通信できなくなった、という時。
pingで通信できる稼働か確認して、IPレベルで通信が成立しているかどうか確認。
Request time out.通信出来てないな…、となると次の調査に移ります。
で、例えば通信出来ていない理由はスイッチ故障のせいじゃないか？となった場合にはスイッチを交換するわけなんですが、スイッチを交換しても通信できるところと通信できないところがある、はて？何で？となっちゃうわけですね。
で実際に通信できないノードを確認すると「Windows Firewallでブロック」あーなるほどな、となるわけですが、そこでちょっとした疑問が生まれます。
「今までなんで通信出来てたんですかね？」
そう…だよね。今まで通信できていたのが説明つかないなぁ、ってなってしまいます。
そうなると、スイッチが故障したことに起因して別のトラブルが発生したんだな、と片付けるしかないわけですが、その別のトラブルってなんですかね？ってちんぷんかんぷんになってしまうこともあります。
実態としては、スイッチ故障でWindows Firewallのプロファイルが今までプライベート（ネットワーク）だったものが「パブリック（ネットワーク）」に切り替わっちゃって、Windows Firewallでは「プライベートなら認識する通信がパブリックだとブロックされてしまう。」という動作をするもんだから話がややこしくなる、というわけです。
※あくまで例えば、の話です。
この事例だと…
この事例だと、
- スイッチが故障した、通信不良
- スイッチが故障して通信不良になると、Windows Firewallがパブリックプロファイルに切り替わる
という二つの原因によって「通信できない」というトラブルを引き起こすことになる、というわけです。
でも、「あぁ～、このスイッチが故障しているせいじゃん。」というトラブルを発見して対処してしまうと、「じゃ、スイッチ交換でこの件は終了ね。」ってなりがちです。
トラブルシューティングに苦労すればするほど、疲弊するほどに「ああ、もう早く終わらせたい…。」という気持ちが先行して、「よし、スイッチの故障だ、そうだ故障なんだ。」と話を完結したくなります。
でも、ここで、ちょっと冷静に。
「もしかして、他にも問題が潜んでいるかもしれない。」
と思えるかどうかが重要になりますね。
