システムの運用においてトラブルの対策を考える際、インパクトが大きいトラブルに対しては大きな労力を、そうではないトラブルに対しては小さな労力をかけるのが効率的です。
ここで、ホビーの売買サイトの運用を例に挙げて説明します。
例えば、エンドユーザーが直接触る画面において、金額計算を間違えてしまった場合、直接クレームに繋がってしまいます。
このようなインパクトの大きいトラブルの発生が想定される場合、予め念入りにテストしたり、本番リリース後にもテストを行ったりして、トラブル発生を防ぐために大きな労力をかける必要があります。
その結果として、実際にそのようなトラブルが起こる可能性は小さくなります。
逆に、管理者しか触らない画面において誤字がある、という程度のトラブルであれば、謝罪して修正してリリースすることで、大事にならずにトラブルを解消することができます。
このような軽微なトラブルについては前述のような念入りなテストを行ったり体制を用意する必要性は薄く、他のトラブルの対策に労力を割いた方が効率的になります。
しかし、トラブルのインパクトの大きさを過小評価してしまった場合、本来かけるべき労力をかけずに、高確率で大きなトラブルが発生してしまいます。
例えば、１日の売上記録を他システムへファイル連携するバッチ処理を想定します。
当該の他システムが開発中であり、その他システムではただファイルを受信しているだけであれば、ファイルの中身が誤っていたとしても後で時間をかけて検証して修正すれば、大きなトラブルになることはありません。
このトラブルで済むのであれば、開発者が作成したデータでテストで済ませ、リリース後も後で時間をかけて結果を検証する、という程度の労力でも通常は問題ありません。
しかし、開発中でファイル未取り込みだと思っていた当該の他システムが、実はファイル取り込みも行っている、しかも管理者がシステムテストのために処理結果を見ている、となった場合、システムテストのスケジュールに影響を与えてしまうというトラブルになってしまいます。
更に、取り込んだデータの修正も必要になるため、リカバリーにも時間がかかるという厄介なトラブルになってしまいます。
このレベルのトラブルになってしまうのであれば、本番データを想定したテストを事前に行い、リリース時も事前にファイルを出力し、出力結果に問題がある場合はファイル送信を差し止める、といった対応が必要になります。
前述のような少ない労力の対策では、本番で厄介なトラブルが発生する確率が高くなってしまいます。
このように、トラブルのインパクトの大きさを過小評価してしまうと、大きなトラブルに発展してしまう可能性が高まります。
それを防ぐために、トラブルのインパクトの大きさは予め有識者に確認しておく、確認できない場合は大きなトラブルが発生することを想定して労力をかける、ということが必要になります。
いかがでしたでしょうか。
今回は実務で発生したことを元にして、得られた教訓を記事として残しました。
実務から得られる教訓は貴重なものですので、これからも文章として残していきたいと思います。
コメント