ども。
スマホが壊れ3日間ほど不自由していた担当ちゅんです。

とある出先部署に設置している屋外無線LANの調子が悪くなり、先日から調査を行っておりました。北国の厳しい冬を乗り越え、しかもその間は何の障害もなく元気に動いていたのに、比較的天候が穏やかな5月にすこぶる調子が悪いとは一体何事でしょうか。

現場からは「ネットがつながらず仕事にならない」という悲痛の叫びが。我々としても現地にも足を運び、原因の特定作業を急ぎました。
ようやく、不具合が発生している箇所を特定。どうやら子局側には特に問題がなく、無線が途切れるタイミングで、親局側のAPから5GHzの電波が発射されなくなっているようです。APのログを取得し確認してみると、そこには次のような記述が残されておりました。

Radar was found on station.
DFS start, use JAP table
br0: port 2(peer1) entering disabled state

最初にこれを見つけた時には「すごく珍しいものを見た！」という気分になりました。実は5GHz帯の無線の屋外利用では、同じ周波数を利用する気象レーダーなどの電波を感知した際には速やかにチャンネル変更することが義務付けられています。
上記ログからはその時の動きを読み取ることができ、レーダーを見つけたので停波した様子が記録されています。ちなみに、DFS（Dynamic Frequency Selection）というのがレーダーの検知機能です。

ならば、「原因はコレだったんだ」「無線機は正常だったんだ」と結論付けたくなるところなのですが、今回はそうもいかないようです。
なぜなら、このログをもう少し読み進めていくと、

DFS start, use JAP table
autoch_select: Auto Channel select ch=136
DFS start, use JAP table
autoch_select: Auto Channel select ch=104
DFS start, use JAP table

こんなログが延々と繰り返されているのです。これでは通信などまともにできるわけがありません。このDFS、調べてみるとどうやらレーダーとチャンネルがバッティングした場合、そのチャンネルは30分間利用できなくなり、さらに別なチャンネルに移動する前にはレーダー波の有無を1分間スキャンしなければならないと。これも義務。
結果として、これが動いている間は通信が途切れてしまい、今回の案件が発生していると思われます。

業者さんとも連絡を取り合いながら、本件は「おそらく機器の故障ではないか」ということで代替機と交換する方法で検討を始めました。しかし、本当にレーダー波との周波数バッティングであれば、一体何が起きているのか。空から降ってくる謎の電波、少し不気味ですね。

何の電波が降ってきているのでしょうかね・・・

（投稿者：ちゅん）

ども。
イベントの後片付けをするたびに歳を重ねていることを実感する担当ちゅんです。

先般、とある重要なシステムで障害が発生しました。このシステムは出先部署に置かれている端末と本庁舎に置かれているスイッチとで通信することで情報がやり取りされるもの。大人の事情で詳しくは書けませんが、物理的に建物が分かれているために、ネットワーク的にはルータ同士がVPNで接続されています。本来、入口から入ってきた情報は出口から出て来なければならないのですが、どこかで詰まってしまったらしく、今回は出口から出てこなかったという状況です。

すぐに関係する保守業者さんも交えて原因の調査が始まりました。今回は「システムの構築保守業者」「システムの開発ベンダー」「ネットワークの構築保守業者」と3社が関係する案件。それに加えて我々「役場の情シス担当」が呼ばれました。この時点でかなり嫌な予感がしたのですが、やはり。

「システム的には正常でした」「機器の故障は無いようです」とすぐさま中間報告が上がり、結果として「回線の問題ではないでしょうか」と。今回の件だけではなく、どうも回線（ネットワーク）というのは悪者にされがちです。それは、おそらく通信というものが「直接目に見えない」からだと思います。しかし、こういう言い方をしてはなんですが、ろくに調査もしないで「システムは問題ない」「機械は壊れていない」となぜ言い切れるのか疑問です。ネットワークを再度見直した結果、それでも現象が収まらなかったときにはじめて「ネットワークではないようなので、もしかしたらシステム（機器）かも」と。こんなケースになることが多いです。

悔しかったのであの端末、その機械、このスイッチに思いつく限りの「仕掛け」をしました。常時通信を監視し、入口から出口までの経路のどこで障害が起きているのかを突き止めるためです。すると、当初「ここが原因では？」と言われていた経路は限りなく「白」という結果に。まだ油断はできませんが、この調査結果からは「機器の故障」もあり得るのではないかと。ここまでやって、ようやくシステム側と同じ土俵で話ができるというのが現状です。そもそも、我々だってネットワークに絶対の自信があるわけではありませんし、むしろ疑われても反論ができません。でも、「不思議なことが起きたら、きっとそれはネットワークのせい」という決めつけは、時に問題解決の大きな障害になると思います。「にわか」が言っても説得力に欠けますがね。

ここまでやらないとマトモに取り合ってもらえないのが悲しいです

（投稿者：ちゅん）

ども。
今週末行われる「熊石あわびの里フェスティバル」ではステージイベントの司会者をする予定の担当ちゅんです。

先日、某所に外勤した際に「申し訳ないけどこの端末とそのプリンタを接続してもらえないかい」と声をかけられました。こういう「あ、いいところに！」的な頼まれ方はありがたいことであり、我々は「御用聞き」と呼んだりもします。別な案件のついでに済ませられるので、こういう「ついで仕事」は助かります。

早速パソコンの電源を入れます。その端末は業務用PCではなく、特定の事業目的に利用している端末で、スタンドアロン運用しておりました。なので、TCP/IPではなくUSBでの接続を試みます。
が、端末を起動させてみて驚きました。液晶画面には無数の横線が走り、赤や緑の帯がびっしり。なんと、私たちが起動させたタイミング（もしくは以前からか？）で液晶パネルが壊れるというミラクルが発生。原課の職員も「あれ？どうして？」という反応です。不幸中の幸いか、自分の目で故障を確認できましたので端末はそのまま職場に持ち帰り「緊急オペ」となりました。

オペといっても液晶パネルの交換などもはや朝飯前。すでに役割を終えて廃棄を待っているノートPCからパネルを取り外し、対象のPCのパネルと交換するだけ。昔はノートPCのモニタによって型番がシビアで合う・合わないがあったのですが、最近のモニタはほぼ何でも使える印象です。今回も対象機は「N」でしたが、交換機は「F」。メーカーが違ってもパネルは共通で「S」が使われていて、ケーブルの規格や筐体のネジ穴など問題なく交換できました。

小一時間で作業は終了。今回パネルを交換した端末は若干複雑な構造をしており、PCの筐体をばらしてキーボードを外さないとパネルが外れないという面倒さはありましたが、この程度はどうってことない保守作業です。ただ、やはり作業をしている最中は「自治体の情報担当者としてこれはやりすぎではないか」という思いが何度も頭をよぎります。これは答えが出ない永遠の課題かもしれません。

作業中の風景。一見ネジが乱雑に感じられますが、ちゃんと考えておいてあります。

（投稿者：ちゅん）

ども。
紺色の作業服がどう見ても業者さんと言われる担当ちゅんです。

それも無理はありません。先週末、某所でかなり大規模な「フロアの配置換え」が行われ、臨席おーるど氏とともに配線作業に追われました。その作業の様子は、誰がどう見ても役場職員ではなく、業者さんです。
入念に現調し、図面を起こし、部材を発注と大型連休前からこつこつ準備を進めていて、ついに本番。その現場はOAフロアではないのでLANケーブルの敷設はどうしても露出配線となります。しかし、単純に露出させるのではなく、いかに隠ぺいし綺麗に工事するかが勝負。綺麗に配線することは見た目がいいだけの自己満足ではなく、耐障害性や可用性といった面でも非常に重要なことです。

さて、こうした現場作業では8割方が事前の準備で終わると言っても過言ではありません。レジェンドである元上司92氏の教えでは「事前に頭の中で工事が終わっていなければならない」と。まさにそのとおりであり、何回も事前にシミュレーションをし、私の頭の中では工事は終わっていた・・・のですが。

思った通りにいかないのもまた、現場。あらかじめ想定はしていましたが、いざ配置換えが始まると「このデスクはこっちではなくそっちに」「端末の位置はやっぱりあっちに」などなど、事前の打ち合わせとは異なる事態が次々と発生。そのたびに右往左往し、時には手戻りしながらの作業。心の中では「当日変更は勘弁してください・・・」とつぶやきつつ、現場判断で導き出された理想的な配置を実現すべく汗をかきました。

一心不乱に配線作業を続け、ようやく作業を終えた頃にはすっかり真夜中になってしまいました。しかし、案の定、翌開庁日には「この端末が通信できない」「プリンタが使えない」などの問題も。確認してみると、通常はしないようなミスを連発していました。体力的に限界で、意識も若干もうろうとする中での仕事でしたので致し方がないとはいえ、まだまだ修行が足りません。こういうところは「にわか」であってはいけないと肝に銘じます。

「誰がどう見ても役場職員ではない」の図

（投稿者：ちゅん）

ども。
「連休明けに」としていた案件に追われている担当ちゅんです。

先日、某施設から「Webカメラが動かなくなっている」と連絡を受けました。その施設では公式ホームページ上に2台のライブカメラと1台の静止画カメラの映像を公開しているのですが、確認してみると確かにライブカメラが2台とも通信できなくなっていました。

現地に向かい、まずは状況確認。今回、カメラが2台とも不調になったということで、原因は「HUBかルータだろう」と想定。カメラから延びているLANケーブルが接続されているHUBにノートPCを接続し、ブラウザにIPアドレスを打ち込んでみます。すると、不調だった2台のうち1台のカメラからは映像が送られてきました。どうやらカメラそのものは正常に動いているけど、それがインターネットに出ていけないようです。

その後、色々と調べているうちに、どうやらルータに設定していたダイナミックDNS（変動するグローバルIPをホスト名に紐づけするサービス）のIPアドレスが更新されていないということが判明。ルータのスイッチを入り切りしてしばらく様子を見ていると、無事にIPアドレスが更新されたのかカメラの映像がホームページに表示されるようになりました。よかった。

ですが、残り1台はそれでもダメです。カメラまでの経路にあるネットワーク機器にPINGを打ってみますが全く反応がありません。「もしかしてカメラが盗難にでもあったのでは！？」と急いで確認に向かうと、カメラと機材一式は無事。ひとまず最悪の事態は免れました。

こちらはこちらで何かが起きているようです。調べていくと、なんと通信機器まで電気が来ていないようです。ここで記憶を呼び起こし、「確かこのカメラの電気は近くのあの建物の・・・その分電盤の・・・」と思い出しながら辿っていくと、最後に「切」になっているブレーカー3つに行き当たりました。「これだ・・・」とりあえず全てを「入」にしてみると、PINGが通りはじめカメラの映像もホームページに送られました。その後、一つずつ「切」にしてみて、ようやくカメラ用電源を取っていたブレーカーを特定。
どうやら、冬期間に施設を閉鎖する際に「切」にしていたブレーカーを「入」にしていなかったことが原因のようです。

この「仕様」については、我が社がいつも頼りにしている「設定書類【虎の巻】（通称：古文書）」には書き込まれていませんでした。カメラを設置した当初は記憶にあったはずですが、やはり人間は忘れる生き物です。今回判明した「仕様」については、留意点としてしっかりと古文書に追記し、現場を後にしました。最近は難解なトラブルが多くて疲れます。

この3つのブレーカーのうち、1つが当たりでした。

（投稿者：ちゅん）