名証トラブルの原因に思う。 | ロマンチックなSEがIT業界を変える。

ロマンチックなSEがIT業界を変える。

アッツワークス株式会社 代表取締役 犬旅コンサルタントのブログです。
IT業界に入って25年。
システムエンジニア(SE)としての日々の活動記録。
キーワード は「右肩上がり」。
読者登録、大歓迎です。

IT業界で働くSEの皆様

先日発生した名証でのトラブル原因が判明しました。

運用を受託していた富士通中部システムズのオペレータが前営業日(二日)の業務終了後のバックアップ処理で、バックアップの「保存」を実行すべきところ、「退避」を実行。すぐに気づき、あわててキャンセル(強制終了)したが、この操作で本来、存在すべきデータベースの制御ファイルが存在しない状況となり、発生当日にシステムが起動しない事態を招いた、とこの記事には書かれています。

バックアップの際に、この制御ファイルをリネームする処理が入っていて、そのリネームが完了した際にキャンセルしたようです。さらにオペレータが操作ミスを起こした時点でシステムエンジニアに報告せず、また翌日に引き継ぐためのノートにも記録しなかったため、トラブル発生後に障害個所の特定などに時間を要する結果となったようです。
(別の記事では、SEに報告したが、その報告を聞いたSEが事実を勘違いし、報告不要と判断したため、オペレータは翌日に報告しなかったともあります。)

大きく2つ改善点があると考えました。
 (1)運用の自動化
 (2)ホウレンソウの徹底

(2)は意識の問題なので、もしかしたら、外注されているオペレータに対して意識付けするのは少し難しいかも知れませんね。どういう時に報告すればよいか基準を設けるのが難しいからです。

もし、SEが判断ミスをしたのなら、それはそれで反省する必要があります。なぜ判断ミスをしたのか検証が必要です。

しかし、やはり、システム開発や運用にはヒューマンエラーが発生することを前提として、技術力(というほどでもないですが)を活かすことはできなかったのかな、という点が疑問です。

定時バックアップのツールなんてたくさんありますよね、何故、それをオペレータ運用にしていたか疑問です。できるだけ人の手を介さない運用システムを作る、というのが鉄則ですよね、もちろんお客様予算とのトレードオフではありますが。

ふと思ったのですが、マシン室は常に18度程度に保たれているので、もしかしたら、その中に長時間いることにより、判断が鈍ったのかもしれませんね。1時間もいると、凍えてきますから。

いずれにしても、できるだけ自動化できるところはシステムに任せる、というのが設計思想として必要なんだろうな、と考えました。