基盤のテスト環境がない場合は誰がリスクを負うのか

今更ですが、ANAシステム障害の原因の発表を聞いたみなさんの反応まとめを読んで思ったことをつらつらと。

DBサーバー、アプリケーションサーバーを順次調べ、異常がないと判断。スイッチの不具合を疑った。「本番環境と同等の作りにしてあるテスト環境にスイッチを持ち込んでテストしたところ、不具合が再現した」（ANA広報）。
ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン

システム環境をどれだけ作るかは予算とのご相談になるわけですが、少なくとも本番環境と機能的には同等の環境をテスト環境で持つことには予算をどうやりくりしても頑張って確保しないとトラブル時にどうしようもないです。

とは言え、ロードバランサなどの機器はお高いので諦めざるを得ないことの方が多いですが。それでも最初から諦めずに環境の使用目的を明確にして費用を積まないと品質検証が本番にリリースする前に確認できない項目を抱えたままの神頼みになってしまうんですよ。これは顧客の担当者も一緒に心中するようなものですが。

想像するに要求されている可用性はOracleのRACを４台で組んでいることから相当高かった（９９．９９９９％くらい？）んだろうなと思うのですが数字は適当です。絶対落とすなくらいは言われていたのかどうか。もしかしたらメンテ時間以外はダメよ、だったのか。

これも想像ですが、本番環境と同等のテスト環境ですが、これ、普段はアプリのステージング環境だったのでしょう。ここで新機能をリリース前に業務視点でテストを目的でエージングしていたかもしれません。

ここで問題なのは、本番環境と同等の環境はあくまでも「アプリのための」であって今回話題になっているネットワークなどの基盤のテストのためのではないのではないか、ということです。もしかしたら、基盤のためのテスト環境があるかもしれませんが、ネットワークを含めて基盤のためのテスト環境なんてみたことあるかなぁ。

アプリの開発環境に同居した基盤の環境ならみたことある気がするのだけれど、基盤から見たらアプリのテスト環境は基盤担当にとって本番環境の扱いにされちゃうんだよねぇ。

で、本当にコスト的に切られちゃうのは基盤のテスト環境なのですよね。これを認められるのは本当に少ない。ネットワークなんてほぼ無理です。アプリで要件としてどうしても必要だから、で通らないと。

でもでも、基盤の人はここを、基盤のテスト環境をプロジェクトで持ってもらわないとダメです。それはプロジェクトの基盤としての要件を、機能検証、品質検証として確保するために必要なコストです。

認められないなら、そのリスクは顧客のリスクですよ、と言い続けることが必要です。でなければ、落ちてもごめんね。です。復旧手順は作っておかないといけないですが。

ところで、スイッチが中途半端に死なない事象って割と聞く気がするのですが、ネットワーク機器が落ち切らない場合のケースって障害対策の検討時に上がってこなかったのでしょうか。