落ち着いた情報収集が障害対応の要

ある異世界のお話です

来場者数の記録更新を目論む大臣から最新技術をふんだんに盛り込んでいるけど一般にもその技術が判りやすくて安定したネットワークを構築するという矛盾だらけの要件の仕事が一段落した勇者が居ました。基本的なパフォーマンス試験も良好で、障害切り替え試験も無事に終えて、予定よりは遅れてはいますがなんとかサービスの正式開始には間に合いそうです。

その時、普段は無口な僧侶が「CRCエラーが多い」とつぶやきます。暗号のようなそのつぶやきを解析すると、ある要所の機器のprimaryポートのframe CRC errorのカウンターの値がまだ本格的なトラフィックが乗っていないのに多い気がします。早速勇者は使役獣を召喚して現地に派遣し収容ポートの変更を行いました。割り当てされていないポートが余っていたのが幸いでした。

しかし、エラーカウンターの上昇傾向は変わりません。ポートの光トランシーバを交換したいところですが構築に全て使い切ってしまい予備がありません。そこで、疲れて眠りこけている錬金術師を叩き起こして急遽予備品を作らせました。サービス開始期限が迫っている時点では痛い時間の消費です。

なんとかサービス開始予定直前に予備品が錬成され交換作業を行いました。ところがカウンターの上昇傾向は変わらず。勇者は思わず天を仰ぎました。その時聖女が神のお告げを伝えます「広い視野を持ちなさい」

勇者に閃きが降りてきます。「エラーカウンターが上がっているポートではなく対向のポートの光トランシーバーの交換だ」無事カウンターの上昇は解消しギリギリサービスの正式開始時刻に間に合ったのでした。メデタシメデタシ。

よりスマートな解決方法は無かったのか？

まず、エラー数の上昇に気付いたモニターチームが偉い。どうしてもこの手のドタバタした構築では監視系の実装の優先度が上がらず苦労するものです。そして、収容替えを行えるポート数があったのも良い。ちゃんと設計時に予備として明確に割り当てされていたのであればもっと良い。

障害切り分け用の部材を確保していなかったのは痛いですねぇ。これでかなり時間をロスしています。

しかし、根本的問題は障害を発見した直後の情報収集です。障害そのものにあまりに集中しすぎて周辺の情報収集を怠ったのではないでしょうか。ベンダーの障害レポートの指定項目は多く、一見障害に関係無さそうな情報が数多く求められます。それも、障害の内容を観る事もなく様式的にあれやこれや要求してくる事が多いでしょう。うんざりした気分に毎回なりますが、このようなテンプレートに沿った情報収集はとても大事なのです。

勇者は、対策を行う前に該当ポートの他の情報。送信レーザ出力、受信レーザーレベル等を確認すべきでした。当然対向側のポート情報の収集も必要です。そして、それら全体を眺めて異常値がないかの確認をしていればより早く障害の解決に至ったと思います。

さらにスマートに

回線開通時の確認作業に問題があるように思います。回線が接続されリンクがあがりデータが流れた。それだけで開通作業は終了としてしまったのではないでしょうか。

開通したあとに各種パラメータを確認し、想定の値の範囲に収まっているか確認するまでを回線開通のタスクとして明確に定義してればその時点で機器の不良に気が付けた可能性が高いと思います。