バッチ処理の開始チェックは大事、ということか

みずほ銀行さんのシステム障害という悲しい事件が騒がれています。

みずほ銀行は15日未明、バッチ処理が予定時間までに終了しなかった。原因について同行は「東京都内の特定支店の特定口座への振り込みが想定以上の件数に上った」と説明しており、その段階でシステムが動かなくなった可能性がある。18日夜の会見で西堀利頭取は「一部の口座では、データ容量の上限設定が適切な数値になっていなかった」と人為ミスの可能性に言及している。

テクノロジー : 日経電子版

・・・ちょっと何いってるかわかりません、というカンジだし、記事へのブックマークコメントが興味深いので、考えたことをメモしておきます。(特定の会社の話題に関するチラ裏なので、続きは折りたたんでみる)

開発方法論は無関係のハズ

ウォーターフォールで開発してるからこうなった、というネタにマジレスすると、それは無関係でしょう。

たしかに、派生開発したシステムに対して、既存システムの性能目標値を盲目的に適用すれば、意味のある性能検証ができなくて、今回のようなケースが起こる可能性はあります。しかし、目標値を適切に設定して性能テストを実施していれば、避けられる問題です。開発方法論に原因を求めるのは、おそらく筋違いです。

"人為ミス"が何を指すか不明だが、業務のミスではないハズ

記事にある"人為ミス"という単語は、頭取の方が口にした言葉なのでしょうか。気になります。

人為ミスと聞いて、自分は業務上の運用ミスを想像しました。しかし、システムに投入するデータ容量の上限設定は、人の運用に頼ってカバーする領域ではありません。データ容量上限の設定方法がどのようなものであっても、異常値に対して機械によるエラー処理があるべきですし、当然あるはずです(実際どうかは知らないので想像で書いてますが)。

システムが必要とする機構を備えていなかった、あるいは、備えていたが正しく機能しなかったために起きたミスを、人為ミスと呼ぶでしょうか。開発工程にミスがあったことを政治的理由で認められない場合を除いて、呼ばないでしょう。

要件定義、設計、実装およびそれらのレビューも人間の行為だから"人為ミス"であるというなら、まだ分かりますが、それはそれで言葉の選択が悪いと思います。

性能目標値定義のミスでもないハズ

次の記事にある表「大手銀行のシステム別、主要担当ベンダーの一覧」を見ると、みずほ銀行の勘定系システムを担当されたのは、F社さんのようです。

F社さんといえば、「非機能要求グレード」を策定した非機能要求グレード検討会に名を連ねるITベンダーの1つです。

「非機能要求グレード」の目的は、リンク先に書かれています。要は、発注者と受注者が非機能要求に関して認識合わせをすることを支援するためのものです。「非機能要求グレード」に定められた項目は、ユーザ/ベンダー間で調整されることが望ましいものです。そして、実際に要求として定義された項目は、もちろん開発工程の中で検証されます。

「非機能要求グレード」は、複数の文書で構成されています。その1つ「システム基盤の非機能要求に関する樹系図」から、非機能要求の大項目である「性能・拡張性」以下で、バッチについて言及している項目を抜粋してみましょう。

性能・拡張性

├業務処理量
│  │
│  ├ 通常時の業務量
│  │  └ B.1.1.5 バッチ処理件数
│  │
│  └ 業務量増大度
│     └ B.1.2.5 バッチ処理件数増大率

├性能目標値
   │
   └ バッチスループット
      └ B.2.4.2 ピーク時処理余裕率

いうまでもなく、F社さんは、バッチ処理性能を要求として定義する必要性を把握されています。そもそも、勘定系のプロに対して、指摘するのも失礼というレベルの話です。

最初に上の記事を読んだ時、データ容量上限の要件定義でミスをしたのかと思いました。しかし、開発を担当した会社が非機能要求分野のエキスパートならば、知らなかった/やらなかった、ということはありえません。また、決済システムの社会的重要性を考えると、検証していないなどということは考えがたいです。

もし、あるとすれば、

  • 適切に実施できなかった
  • 他社に委託していて査収が不十分だった

などでしょうか。しかし、こんな重要なシステムで、そんなテキトーなことは、それこそしないと思うのですが…(想像で書いてます)

少なくとも、バッチ処理の開始条件チェックに問題があったとはいえるかも

「通常はバッチ処理に入る前に(データが処理可能な量を超えるなら)気づいて対処できるはず」という指摘があり、なるほどと思いました。

上の記事だけでは何が問題だったのかよく分かりませんが、これだけは確かといえそうです。たとえ性能テストがいい加減でも、上限値の設定を誤っても、バッチ処理の直前でせき止めて対処できれば、システムのダウンは避けられるであろうからです。

これもまた、ミッションクリティカルなシステムなら、本来は作り込まれているべきですし、充分に検証がなされているべきでしょう。しかし、現実に機能しなかったということです。

できれば、もう少し詳細が明らかにされますように

というわけで、金融に限らず、ミッションクリティカルなシステムの品質向上、障害防止のために、なるべく多くのことが公表されることを願っています。

こと金融システムなので、セキュリティの問題で色々むずかしいでしょうけれども・・・期待できませんが、希望しています。