勝手にパッチが当たっていく

いつも拝読させて頂いております。
さてクラウド上のパッチ適用についてですが、例えば、Paas上にアプリを構築し運用していた場合、Paas業者が勝手にパッチを適用したおかげでアプリが不安定になるなんて事が起こる可能性はないでしょうか・・私が担当する金融機関ではそのリスクを鑑み、基本はパッチを適用しないのですが・・

イチロウさんありがとうございます。可能性でいえばPaaSでも勝手にパッチがあたればアプリに支障がでることはありえるとおもいます。ただ、アプリがPaaSのインターフェースを深読みして作っていないとか、タイミングセンシティブに作っていない、そしてPaaSベンダーがインターフェースには影響を与えないかバグフィックスのみでパッチを当てる。この限りにおいてはその可能性は極めて小さくなると言えると思います。とはいえごりごり作りこむアプリもありますよね。PaaSでそういうアプリを作れるか、作っていいかという議論もあるでしょう。

一方、セキュリティーの課題が大きい場合はパッチでのアプリの支障の可能性以上に、当てないとリスクが大きくなることもあるでしょう。

このあたりまた整理して書いてみたいと思います。なかなか難しいテーマではありますが。適切な質問ありがとうございます。

自動のパッチ適用のあり方を見直すPaaSベンダーもあるようですね。SaaSのようにアプリも含めて全てベンダーで運用できる場合と異なり、PaaSを提供する上ではこの話題は避けて通れないのかもしれません。より影響があるのがユーザー企業自身が運営するプライベート･クラウドではないでしょうか。クラウド上の全てのシステムを塩漬けするわけにも行きませんので、パッチ適用ポリシーに応じた複数のクラウド環境を準備する必要がありそうです。パッチ適用による不具合への対応や影響度を確認するテスト費用にだけ目が行きがちですが、パッチを適用しなかったために生じるコスト、例えばトラブル対応の人件費、ビジネスの直接の損失、信用失墜などと比較・評価した上で、ポリシーを決定することが重要では無いかと考えています。

パッチを提供するベンダーから、リグレッション・テストの結果を公開してもらうというのはありえない話でしょうか。

ベンダーとしては、しかるべきリグレッション・テストを行って品質を確認した上でパッチを出荷していますので、本来であればお客様の方で実施すべき確認テストは限られているはずです。しかし、そのリグレッション・テストの結果が公開されていないため、お客様としては自分の信じるテストをすべて実施しなければ安心できません。そして、たいていの場合、テストの工数が莫大になるので、リスクに目をつぶってパッチを適用しない道を選択されているように思われるからです。

ミッチーさん、コメントありがとうございます。SaaSでなくPaaSだと問題はまさにそうですね。またOSまで提供しているか、それより上位の抽象度の高いインターフェースを提供しているかにより、影響度も違うでしょう。抽象度が高ければ影響は少ないと期待されます。

プライベートクラウドで、ご指摘のポリシー別にプールを作るのも一つの方法かもしれませんね。ミッションクリティカルを扱うなら。理想的には同じポリシーがコストとして嬉しいですが。

D.Sさん、コメントありがとうございます。いろいろ考えさせられます。

昔、メインフレームの開発にいましたが、リグレッションテストのツールがあって、アーキテクチャーブックの仕様でケースが作られていて、一晩で流していました。

ただオープンの時代になって、仕様がややぼけてきたせいか、さらに組み合わせや状態が指数関数的に増えてきて、そういった一晩でできるツールは作れない、すべてのテストケースは作れないなと思ったことがありました。またベンダーがケースを出してもローレベルのインターフェースのテストだったりして、アプリへの影響はわからないかもしれません。

アプリの視点で、基本的な機能のテストの自動化や、逆にPaaSなどである抽象度の高いインターフェースでのテストなどが、テストをするという前提では可能性のある方法かもしれませんね。