#はじめに
システムというものは、ある日突然おかしくなるものです。また、そういうものに限って担当者が退職していて引き継ぎも行われていないとか、古すぎてメーカーがサポートしてくれないとか、色々と困った状態になっていることが多いです。
こういった話は、Qiitaでよく見るイマドキのIT企業ではあまりないかもしれませんが、筆者が所属する製造業の業界ではよくあることのようです。
今回は、そんな「闇システム」をどうにか解析し、なんとかするための手順をまとめてみたいと思います。
#まずは相手を知る
よくわからないシステムを相手にしないといけないときは、まず環境を確認しましょう。確認すべき項目としては
システムを構成するコンピューターの仕様を確認する
まずは、サーバーなりクライアントなりが動いているコンピューターのCPUアーキテクチャ、OS等を確認しましょう。x86やx64とWindowsの組み合わせなら良いですが、それ以外の場合は身構える必要があります。
使用されているミドルウェアを確認する
OSとアーキテクチャが分かったら、次はミドルウェアに何が使用されているか確認しましょう。
ミドルウェアを確認する方法は色々とありますが、今回は実際に端末を操作できることを前提として考えてみます。
とりあえずnetstat
とりあえず、netstatで使用しているポートを確認してみましょう。
Well Known Portを勝手に使ってるようなお行儀の悪いソフトじゃなければ、何が動いてるかくらいはわかります。
できればパケットキャプチャ
あと、できればクライアントでWiresharkを動かして、通信内容を確認してもいいと思います。キャプチャ内容を見れば、アプリケーションの挙動がなんとなく分かるかもしれません。
もし、いろいろな理由でクライアントにWiresharkを忍ばせる事ができない場合は、ミラーポート機能のあるスイッチングハブを使用するのも一つの手ですが、こちらのほうが現実的に難しいかもしれません。
知ってそうな人に聞く
これは最終手段ですが、古参社員とか、少しでも導入時の事情を知ってそうな人に聞くのもありです。
障害の再現性を確認する
障害対応の基本中の基本ですが、起きた障害の再現性を確認する必要があります。
つまり、問題となっている障害が「時々起こる」のか「とある操作をしたときに起こる」のかを特定する必要があります。
対応可能な障害かどうかを判断する
再現性を確認して、問題の特定ができたら、最後にその障害が対応可能な障害かどうかを判断します。
例えば、データベースの障害が起こっていたとして、それが論理障害ならなんとかなるかもしれませんが、ディスクの不良セクタがちょうどDBのファイルが置いてあるところに発生している等、どうしようも無い場合も多々あります。
そういった場合は、上層部にそれらしい説明をする準備をせねばなりません。ここで一つおすすめな方法として、「できないことは無いけど高く付く」と説明する方法です。
先のデータベースの例を使うと、単に「ファイルが破損しているので復旧できません」と報告してしまうと、大抵の場合納得してくれません。酷いときには責任転嫁されて自分が悪いことになります。
ですが、「復旧することは可能ですが、業者に依頼する必要があります。今見積もり途中です」と返答すれば、とりあえず進捗がある事を強調することができます。
言い方の問題ですが、ただでさえ立場が弱い情シスで生き残るには、こういった手法も必要になってきます。
#おわりに
はじめは技術的な事を書くつもりだったのですが、そういったネタが全く思いつきませんでした。よく考えてみればそれもそのはずで、障害対応というのは結構経験則やカンに頼っている部分が大きく、特に闇システムに対しては、情報工学的なアプローチは全くと言って良いほど効果がありません。
RPGで相手の弱点属性を探るために、ひたすら魔法を当てまくる事がありますが、闇システムに対しても、そういった地道な作業が必要なのだと思います。
技術成分少なくてすみません・・・