不具合が報告されているハードやソフトを利用するシステムでトラブルが発生したら、その不具合が原因に違いないと考えるだろう。実際、不具合が原因であることが多い。だが一方で、不具合とは無関係の箇所に原因が潜んでいる場合もある。この場合、トラブル解決は往々にして難航する。
顧客企業のシステム運用を請け負うチームのリーダーだったラックの七沢樹さんが直面したトラブルがまさにこのケースだった。七沢さんはどのようにして原因を突き止めたのだろうか。
時間内に終わらず子会社の業務に支障
七沢さんたちのチームが運用を支援する顧客企業A社では、取引先であるB社の複数のサーバーからインターネット経由でデータを受け取り、データベース（DB）サーバーで統合してマスターデータを生成。その後、マスターデータをバッチ処理で加工してA社の子会社のサーバーに送信していた。子会社は加工したデータを受け取り、業務に利用していた。
2013年11月のある日の朝、このバッチ処理のシステムにトラブルが発生した。A社のIT担当者から「時間内にバッチ処理が終わりませんでした」と七沢さんに連絡があったのだ。子会社の業務部門から「データの到着が遅れ、業務に取りかかれなかった」と報告されたという。
トラブルが発生する前の週までは、特に問題なくバッチ処理が完了していた。システムの設定も変更していない。七沢さんはA社のIT担当者に「ネットワークなどのインフラと、アプリケーションの両方から原因を探りましょう」と提案した。
まず、バッチ処理の実行時の状況を把握するためにシステム運用管理ツールのログを調べた。すると、バッチ処理の開始時刻がいつもより遅かったことが分かった。バッチ処理に使用するマスターデータの生成に時間がかかっていたためで、バッチ処理そのものにかかった時間は、いつもとほぼ同じだった。
