思い込み

ITシステムのトラブル対応において、正しい原因の把握は極めて重要だ。見えている状況からそれらしいと思われる原因を推測しても、本当の原因ではないということが非常に多い。そして仮に原因が性能が特定されたとしても、必ずしも自明な解決策が最適だとは限らない。

たとえば、非常に単純な例ではあるけれど、分散データベース (KVSのようなもの) で書き込みの性能劣化が発生しているとする。

すぐに思いつくのはデータベースの性能が貧弱であるという原因である。システムを構築するときには性能評価は必ずするので、本来どれぐらいの性能が期待されるかというのはシステムの管理者であれば知っているべき情報だ。だがそれを満たしていないということが、直ちにデータベースの性能が悪いということにはならない。

よくある原因は、負荷の一極集中の問題である。つまり、性能評価時に確認されたパフォーマンスはあくまで理想的に負荷が分散されている状態でのものであるのに対し、実際のシステムではいろいろな理由により負荷が分散されずに非常に狭い範囲に集中した結果、システム上のある特定のポイントだけが高負荷になってそれ以上さばけなくなっているが、それ以外のところはスカスカで余裕のある状態である。

この場合に単純にデータベースのサーバ数を増やすことが問題の解決にならないのはお分かりいただけるだろう。いくらサーバを増やしたところで、負荷のかかっていないサーバの数が増えるだけである。サーバのスペックを増強する（もっと速いマシンに変える等）というのはある程度効果があるかも知れないが、サーバの置き換えは非常にコストがかかるし、何よりスカスカの状態のサーバまで増強してしまっても投資に見合う効果はない。ポイントは、性能劣化の原因が一極集中にあるということに如何にして気づくかというところにある。

しかし、原因っぽい事象に一度たどり着いてそれが根本原因だと思いこんでしまうと、その先に踏み込んで考えていくことは難しい。

この性能劣化の事例は一般的によくある問題なのでプロであればそこで思考停止してしまうことはまずないだろうけれど、ITのことを知らないビジネス側の人間がこの現象の報告を受けたとしたらどうだろうか。もちろんデータベースの裏側の技術的な詳細など理解しているわけではないから、データの分散の仕方やネットワーク設計によってパフォーマンスが変わることが理解できず、どんな利用方法であってもカタログ通りの性能が出て当たり前だと思うかも知れない。その結果、単純にデータベースの性能がスペック通りでないことに失望し、先に上げたような不完全な対策を推し進めるかも知れない。あるいはデータベース開発者やベンダーに責任を押し付けるかも知れない。そのビジネス側の担当者にいくらかITに関する知識があるときなどはむしろ厄介で、偏った知識や経験を元に自分で勝手に仮説を立て、その仮説への対応をエンジニアに押し付けてくることすらある。だがそれが往々にして的はずれであり、問題の解決に必ずしもつながらないということは上記の例からもわかるだろう。

一方で、ではプロはこういう過ちを侵さないかというと、決してそんなことはない。

我々もよくトラブルシューティングをしていて、製品がこう動いてほしいという期待からログを読み間違えたり、コードの意図を勘違いしてしまうことはある。監視システム上の断片的なグラフから立てた仮説がしっくり来るがゆえにそこに固執し、大事なログを見落として間違った結論に行き着いてしまうこともある。過去に経験したトラブル対応の記憶から抜け出せず、本質的な違いがあるにも関わらず以前と同じ対応方法でいいと誤解し、結果としてトラブルが拡大するといったこともある。

大事なのは、思い込みを捨てること、専門家の意見を仰いでそれにきちんと従うこと、そして結論を出す前に他の人とダブルチェックすること。これをするだけでトラブルへの対応は格段に向上する。

大したことない問題であればいざしらず、大きなトラブルであればあるほど、素人が専門家の意見を聞かずに（あるいは反発したりして）思い込みで勝手な判断をしてはいけない。それがこれまでの自分のテクニカルサポートとして経験した中で学んだ最も大切なことであるし、もっというとこれは実はどんなトラブル対応にも当てはまることだと思っている。

その上でサポートエンジニアとしてのスキル向上を考えるとすると、自分が以下に「専門家」の領域に近づいていくかということになるだろう。長くなったので今回はこの辺にして、続きは気が向いたらまた今度（前回も同じような締めだったけど）。