スポンサーリンク
6月24日にモバイルSUICAのチャージができないなど一部機能が使えない障害が発生して、多くのユーザに影響が出た。
どうしてこういうことが減らないのか考えてみる。
IT業界に関するニュースのまとめはこちら。
24日午前0時半からモバイルSUICAの残高チャージ、グリーン券購入ができない障害が発生した。復旧は13時間後の午後1時だった。
一時は駅の窓口でもクレジットカードを使えない状況になった。
日経によれば、屋内の電源工事の際に計画と異なるブレーカを切ってしまい、モバイルSUICAを制御するサーバの電源を切ってしまったためだった。
なぜ誤ったブレーカを切ったかといえば、操作手順書に誤りがあったためだった。
手順書が間違っているのだからそれを信じて作業する作業員に何の落ち度もない。
モバイルSUICA 障害 JR東日本 230624 出典:日経
ソフトウェアの不具合が減らないのは、ソフトウェアに問題がないことを証明する方法がないからだ。結局テストを行って、その範囲では問題がない、と証明するしかない。
このためテストの範囲外、例えば条件を変えるような場合に未テストのパターンがあればそこで問題となって現れる。
近年ではテストの自動化、テストファーストなどいろいろな取り組みがあるが、ソースコードに問題がない証明をする方法がないのでその点は何も変わっていない。
一方でインフラ工事は、組み合わせたものの結節点に弱点があることが多い。
組み合わせたパーツ、例えばサーバ、OS、ミドルウェアそれぞれはテストされているが、くっつけた状態でのテストはインフラ提供者の責任で行う必要がある。
ここでも上と同じく、条件に漏れがあれば、そのパターンで問題が発生する可能性がある。
そのうえで、インフラの場合は何らかの操作を行う際に手順書をそろえることが多い。
手順書はシステムそれぞれでカスタマイズされることが多く、同様の操作が他のシステムにもあるとは限らない。
カスタマイズされるので新規のミスが入り込む余地が多くあり、手順書を十分テストしなかったとしたら、そこには潜在的な問題が多くありそうだ。
網羅的に問題の検出する仕組みを検討する必要があるが当面は難しい。手順にまつわる問題はまだまだ続きそうだ。
PR
