情シスが社内ネットワークの可視化に取り組んだら意外なものが見えてきた話

小型のパケットキャプチャ装置を売っています、黒ブラといいます。

普段お客様に対して、社内ネットワークの可視化をすると色々分かることがありますよ、というお話をするのですが、具体的に何がどう分かって、どう改善するのかというようなことが短い商談では伝えきれないことがよくあるので、僕の原体験となったある出来事について書き残しておこうと思います。

僕は新卒で商社に入り、情報システム部門に配属されました。
最初に覚えた仕事はPCのキッティングをはじめとするヘルプデスクでしたが、当時新システムの導入が大炎上しており、入社2年目からそのシステム開発のお手伝いに駆り出されました。
ヘルプデスクとSQL開発の2足のわらじで僕の情シスキャリアはスタートします。

システムのリリースが一段落した後、僕はあるサブシステムの運用を任されます。
どういう運用業務かというと、そのシステムがたまに止まるので、データベースの止まる原因となったセッションをKillしたり、再起動したりというような仕事です。
システムが止まると、関連する業務も止まってしまいますので、止めないよう監視しなくてはなりません。月末月初は特に負荷がかかるので、原則休まないようにと釘を刺されていました。

ここで、このシステムのビジネス的な背景についてご説明すると、商社というのは基本的に「売ってください、買ってください」の構造です。
ある商品をお客様に対して、「買ってください」と販売するのも仕事ですが、競争力のある商品を「扱わせてください」と仕入れ先にお願いするのも重要な仕事です。
複数ある仕入れ先は「うちの商品を代理店に扱わせてやってる」という態度で来るわけで、この仕入れ先に対して売上の報告をする業務というのがあります。

当然、そういう報告に際して、例えば、エンド顧客のセグメントごとの売上推移をレポートせよ、であるとか仕入れ元の作った商品区分ごとに売上を集計せよ、であるとか、まあ様々なリクエストが仕入れ担当者に降ってくるわけですね。

で、そういうリクエストに対して、売上や在庫のデータベースからデータを引っ張って加工する業務というのがありまして、ユーザーにはあるシステムを使ってもらっていました。
このシステムは疑似SQLと言いますか、GUI上で簡単にSQLを組み立てることが出来るというもので、副問い合わせなどのような、複数のSQLを入れ子にして組み合わせることはできないですが、自由度の高い問い合わせが出来ることを売りにしたシステムでした。

本筋に戻ります。
このシステムが時たま止まる、というのが引継ぎを受けた当時の説明で、原因は重いSQLが流れているからだということでした。
ただし、そのSQLは誰が流したのかは分からないという問題がありました。

システム上にログが出ないのか？と思った方がいらっしゃるかもしれません。
悪いことにこのシステムはデータベースへのリクエストが成功しデータを返すときにログに記録する仕様でした。
データを誰が引いたのか（誰が持っているのか）を記録に残す機能ということですね。
つまり重すぎて情シスが切ったセッションについては一切のログが残らないという問題があったのです。

この時に流れるSQLは集計操作のミスのようで、新人が慣れない業務で引き起こしている問題だと情シスは認識していました。そのため新人へのシステム教育でこのシステムを使用するときの注意点として、かなり力を入れて教育をしていたのですが、その努力も空しく、月末月初になるとたびたび発生するのです。

ある時、僕は得意のパケットキャプチャを使ってこの問題を追いかけることを思いつきました。
データベースへのリクエストを全てパケットキャプチャに取り、そのTCPペイロードをダンプして無理やりテキストファイルに書き出し、それを疑似的なログとして扱うシステム（と言えるかどうかわからないくらい原始的なシロモノ）を作ったのです。
16進ダンプを何も考えずにそのままASCII変換しており、変換できないデータも当然混在しますので、まあまあの荒技です。
どうせ管理者（僕）しか見ないからいいよね、という闇のシステムです。

現行業務で使用しているシステムですので、本体に手を入れるわけにはいかなかったという事情もあり、既存のシステムに影響を与えないように作られています。
この疑似ロギングの仕組みは幸いなことにうまく機能し、問題となる重いSQLが実際にはどのようなリクエストだったか、そして誰が流していたかが明らかになりました。

このSQLを流していたのは当時仕入れ部門のベテランのアシスタント、そして他に在庫管理チームからも重いSQLがリクエストされていました。こちらもベテラン選手です。

SQLの全文を見ればどのような目的でそのリクエストをしようとしたのかが大体予想できます。
驚くべきことに、このベテラン選手達はおそらく「Group by」の概念を誤解しており、正しい集計操作を行っていないと推測されました。
（GUI上も、少し間違いやすい操作であったことは確かです）
仕入れ先への報告で数字の間違いがあっては一大事ですので、僕は顔色を変えてこのベテラン選手たちに電話を掛けました。

ヒアリングしてみたところ、自分の出したリクエストが返ってこないことはベテラン選手側も認識しており、これは重いシステムのせいだろうと不満に思っていたようです。

そこで、僕はこの人々の立場にも配慮して、個別に再教育を行いました。
現場の上司等にも根回しをしたうえで「いまさら聞けない○○」的な教育プログラムを作り、実施した結果、月末月初のシステム停止をほとんどなくすことができたのです。

これらを通じて月末月初のシステム停止、業務停止のリスクを軽減させることが出来、さらに重いシステムに不満を持っていた各部門の有力者からの情シスに対するマイナス印象をプラスに転じることが出来たと思っています。（特に誰からもお褒めの言葉は頂きませんでしたが。。）

可視化というのはキレイなグラフで表せることばかりではありません。
取れなかった情報を何とか取れるようにする、物事に対する解像度を上げるといった取り組みも含まれると考えています。
この件を通して、データを取り、それを読み解き、適切なフォローをする事で、きちんと改善効果が表れることを学びました。
これは僕が入社3年目の出来事ですが、忘れがたく記憶に残っています。

まとめると
以下のようになると思います。

・いつ起こるかわからない問題には定常的な観測が必要
・可視化すると予想と違う原因が判明することはよくある
・既存のシステムを変えずに何かをやりたいときに低レイヤの解析技術を応用するとうまくいくことがある
・データに基づいた分析は話し合いの時にエビデンスとして機能する
・状況を知れば「配慮」ができるようになる

情シスの機能は大きく2つあり、「チェック」と「サポート」に分けられます。ネットワークの可視化というのはこれらの攻守に同時に効かせることが出来る一手であり、忙しい情シスの負荷を減らし、エンドユーザーの信頼を獲得するための強力な武器になると信じて、日々開発と営業に邁進しております。