私の学士論文では、SaaS プロバイダーが何らかのビジネス継続性を保証する方法を研究しています。
「シュリンク ラップ」ソフトウェアのソース コード エスクローの手配については、おそらくご存じでしょう。ソフトウェア サプライヤが (財務上の) トラブルに陥ったときはいつでも、顧客はソース コードと該当するすべてのドキュメントにアクセスできます。これは明らかに SaaS では機能しません。顧客はソース コードだけを使用することはできず、SaaS プロバイダーが倒産したために数週間 CRM システムにログインできないことを顧客はおそらく許せないからです。現在、この問題を解決するためのさまざまな方法を研究しています。
この連続性の問題を解決するための優れた実用的な解決策を知っていますか? それとも、すでに優れたソリューションを提供している企業ですか?
ありがとう！
次の 2 つのケースを区別する必要があると思います。
あなたが尋ねる質問は、通常、SaaS サービスの使用を検討している企業のコンテキストで出てきます。このような場合、慎重な企業は (事業継続計画の一環として) (a) サプライヤーの経済的な実行可能性を保証する必要があります (興味深いことに、この質問に回答するほとんどの人がこれを主なリスクと見なしています)。サプライヤは、すべての主要なリスクが発生した場合にサービスを保証する適切な事業継続計画を持っていること自体。(たとえば、データセンターで火災が発生し、一時的にシャットダウンする必要がある場合、代替手段はありますか? ホットスタンバイ状態ですか? データは重複していますか? どの程度のデータが失われる可能性がありますか? ネットワークトラフィックを再ルーティングできますか? など.)
もちろん、顧客はネットワーク接続の問題についても心配する必要があります。サプライヤは営業中ですが、連絡が取れない場合があります。そして（国境を越えた場合）、政治的および規制上のリスク。
実際、SaaS サプライヤーの懸念は、重要なサービスや製品をアウトソーシングする他のプロバイダーと大差ありません。(カスタム フランジとカスタム グロメットを組み立ててウィジェットを作成している場合、何らかの理由でサプライヤーがフランジを提供できない場合、問題が発生します。)
興味深いことに、少数の大口顧客を持つ SaaS サプライヤにとっての懸念事項は、顧客の経済的実行可能性と事業継続性です。大手小売業者の破綻は、そのサプライヤーの破綻につながる場合があります。サプライヤーは多額の無担保債務を抱えているだけでなく、流通チェーンの大部分が欠けたままになっています。
Jan Husdal は、サプライ チェーンのビジネス継続性の問題について興味深いブログを書いていますが、特に SaaS の問題を取り上げたとは思いません。
将来に向けて注目すべき指標の 1 つは、承認された基準 (BS-25999 など) に基づいて監査された事業継続計画をサプライヤーが持つ必要性かもしれません。各企業が重要なサプライヤーに認証要件を押し戻すにつれて、ISO-9000 規格が普及したのと同じように、ビジネス継続性規格が普及する可能性があります。
論文頑張ってください。興味深いトピックを選択しました。LinkedIn の Disaster Recovery Journal グループで質問することもできます。これは、私が見つけたビジネス継続性の問題に関する唯一の活発なディスカッション エリアです。
小規模な SaaS プロバイダーとして、見込み顧客からこの質問をよく聞かれます。製品をオープンソースにすることで、この問題に対処しました。これは多くの人にとって適切なオプションではないかもしれませんが、私たちにとっては最高でした.
会社が倒産しようとしている場合に備えて、十分な数のサーバー側ソフトウェア、構成ファイル、およびデータを顧客に提供して、顧客が独自のバージョンのサービスをホストできるように、いつでもシステムを設計できると思います。本質的には、新しいシステムに移行するのに十分な期間ホストする (内部的に、または他の誰かに支払う) ために、システムのイメージを提供/販売します。すべてのサーバー側ソフトウェアを仮想マシン内で実行すると、(本質的に) 顧客にサーバーを提供することが容易になる場合があります。会社が閉鎖されようとしている場合は、VM イメージをサードパーティのホスティング プロバイダーに直接転送するように手配することもできます (そして、顧客の現在の契約の残りを履行するのに十分な時間に対して前払いします)。
SaaS の顧客として、請求、電子メール、ソフトウェア バグ追跡などのサービスに大きく依存しています。この質問に答えるまで、私はあまり考えたことがありませんでした。私はいつでも契約を終了できますが、なぜ彼らはできないのでしょうか? 一方で、私のデータは保護する必要があります。私はサプライヤーに尋ねました (gmail からすぐに返事が来るとは思っていませんでした :-) その間、頻繁にバックアップするための措置を講じました。
怖い: 私のプロバイダーのどれも、サービス条件で実際に何が起こるかを詳細に説明していません。そのような情報はどこで期待できますか? 開発者はそのようなテキストをどこに配置しますか?
Well we do SaaS but I'm not sure management has though about continuity. I believe the most common state of affairs is that an SaaS provider limits his services and liabilities per contract so that they don't even have to think about it.
As a possible solution: company may agree per contract to provide some amount of effort to migrate the data to an alternative software system of customer choice in case it shut down its operation. Short of that, there is hardly anything to expect.
As a very bald option: give the database backup to the client who will employ consultants or make bits and pieces out of it. But it's rather an emergency case.
この問題に関して考えられる対処方法は、あるソフトウェアについてX社と取引を行っているが、そのソフトウェアのデータ ストアにあるのは私のデータであることを認識することです。そのため、そのコピーを提供する必要があります (XML または合意された形式で)。そうすれば、会社が廃業した場合でも、データの最新のコピーが必要になるだけで、それを別の場所に持ち出すことができます。
SaaS 業界で働いてきた私は、多くの企業がさまざまな方法でユーザー データを保存していることを知っていますが、競合他社のことも認識しており、企業がデータを簡単にロードできるようにしたいと考えています。
良い質問。私が働いていた SaaS 企業では、ホスティング チームが顧客のインストールを迅速に展開するために社内で使用する一連のツールを開発するチームに所属していました。顧客の展開は、それぞれ 7 ～ 10 台のサーバーを備えたテスト/運用サイトを含む複雑な手順でした。また、顧客データを夜間にバックアップするための手順も用意されていました。
社内で使用するために開発したツールは、あなたが説明した目的のために製品化された可能性があり、これらのツールと顧客のデータにより、製品を引き継ぐことができると思います. このツールセットは柔軟で、顧客はデータを別のサーバー構成に再展開できました。たとえば、緊急時に、8 台のサーバーで実行されていたアプリを 2 台のサーバー構成に展開し、データ センターをセットアップしたら、よりパフォーマンスの高い 8 台のサーバー構成に再度展開することができます。