エンジニアとしてどのように年齢を重ねていくことが望ましいのか?

問題を解析する能力を磨こう

»

 ここでいう問題とは、システム構築時に発生する諸々の障害を意味しています。

 システム構築の現場で予期せぬトラブルに出くわすことがよくあります。そのような局面で重要となるのは、目の前で発生している障害の原因を、正確に迅速に突き止めることです。

 システムトラブルは発生しないに越したことはないのですが、若いうちに様々な局面で問題解析能力を磨いておくと、将来、大変役に立ちます。

■まずは問題を正しく切り分ける

 システムのトラブルといっても様々なケースがあります。

 例えば、自らが開発したソフトウェアを組み合わせて構築したシステムである場合や、商用製品など自らが開発をしていないソフトウェアを組合わせて構築したシステムの場合などがあります。また、システムはソフトウェアのみで動作することはできませんので、サーバ、ストレージ、ネットワーク機器など様々なハードウェアと組み合わせて機能するものです。そのため、トラブルが発生した場合に厄介なのが、一体どこで障害が発生しているのかが判り辛いケースです。

 このような場合に重要になるのは、問題の切り分け能力です。問題の切り分けとは、障害の原因が、ハードウェアにあるのか、ソフトウェアにあるのか、論理的な判断により障害の原因箇所を少しずつ狭めていき、最終的な原因特定まで導き出すことです。

 これには経験と知識が必要ですが、意識して訓練することは可能でしょう。障害の事象を見ただけで、誰もがすぐに原因の特定ができるようなケースもありますが、多くの場合は、すぐに原因の特定には至らず、いくつかの調査を経て、原因の特定につながるのではないでしょうか。

 障害の原因を調査するうえでのアプローチ方法としては、システム全体をいくつかの意味のある単位に分類し、分類した単位(コンポーネント)ごとに障害の事象と照らし合せて、障害の原因となる可能性の有無を論理的に立証することをお勧めします。また、ソフトウェアに限らず、サーバ、ネットワーク関連のハードウェアも同様に、分類した単位ごとに当該箇所が障害原因となり得るかを検証することが非常に大切です。

 こうした論理的な立証のための調査や検証には、地道な活動を要しますが、障害原因になり得ることを証明する検証をするのか、障害原因になり得ないことを証明する検証をするのか、どちらが検証し易いかといった視点が重要になります。システムトラブルは原因の特定に時間が掛かるケースもありますが、このように1つ1つ確実に障害原因となり得る範囲を狭めていけば、最終的には原因を特定できる可能性は高まるでしょう。

■最近、ダンプ解析をしている人が減少している

 これは15年ほど前のことになりますが、メインフレーム・システムの構築現場で育ったわたしにとって、UNIX環境での開発者たちがアプリケーションの障害発生時にダンプ解析(*)をあまりしていないことに非常に驚いた経験があります。

 わたしが見てきた範囲に限りますが、業務システムを開発している技術者の中で、コアダンプの解析を正確にできる人材は少なかったように感じました。しかし、ダンプの解析を正確にできなければ、深い問題に直面した時、障害原因の特定はできないように思えます。

 ダンプ解析をするには、それなりの知識が必要であり、解析作業にも時間を要しますが、ダンプ解析をすると障害原因の特定の可能性は確実に上がります。なぜなら、障害が発生した時のメモリーの状態がそのまま残っているため、表面的には見え辛いことがダンプ解析をすることで明らかになるからです。皆さんも、ダンプ解析ができる先輩SEが周りにいたら、積極的にその技術を習っておくことをお勧めします。

 システムトラブルに対する対処として、上手に問題の切り分けをし、障害原因の特定をすることと、障害原因が局所化した場合は、より深い調査能力を有することが重要です。日々の仕事の中でも問題解析の意識を持つことによって、このような技術を向上させることができると思います。 

(*)ダンプ解析:プログラムが占有するメモリーの情報を16進形式で出力したもの

Comment(0)

コメント

コメントを投稿する