对于我的学士论文,我正在研究 SaaS 提供商如何安排某种业务连续性保证。
您可能知道“收缩包装”软件的源代码托管安排。每当软件供应商遇到(财务)麻烦时,它们都可以让客户访问源代码和所有适用的文档。这显然不适用于 SaaS,因为客户无法仅使用源代码,而且客户可能无法承受由于 SaaS 提供商破产而在几周内无法登录其 CRM 系统的情况。我目前正在研究解决这个问题的不同方法。
你知道解决这个连续性问题的好方法吗?还是已经提供了良好解决方案的公司?
谢谢!
我认为您需要区分两种情况:
您提出的问题通常出现在考虑使用 SaaS 服务的公司的背景下。在这些情况下,一家谨慎的公司(作为其业务连续性计划的一部分)需要 (a) 确保供应商的财务可行性(有趣的是,大多数回答此问题的人都认为这是主要风险),以及 (b) 确保供应商本身具有充分的业务连续性计划,该计划将确保在发生所有重大风险时提供服务。(例如,如果数据中心发生火灾,必须暂时关闭,是否有备用方案。是否处于热备状态?数据是否重复?可能会丢失多少数据?网络流量是否可以重新路由?等.)
当然,客户也必须担心网络连接问题:供应商可能正在营业但无法联系到。以及(在跨境案例中)政治和监管风险。
事实上,SaaS 供应商的担忧与任何其他外包关键服务或产品的供应商没有太大区别。(如果您组装了定制法兰和定制索环来生产小部件,那么如果您的供应商出于某种原因无法为您提供法兰,您将遇到麻烦。)
有趣的是,对于拥有少数大客户的 SaaS 供应商来说,其客户的财务可行性和业务连续性是一个问题。大型零售商的倒闭有时会导致其供应商的倒闭:供应商不仅背负了大量无担保债务,而且还缺少分销链的主要部分。
Jan Husdal 写了一篇关于供应链业务连续性问题的有趣博客,尽管我认为他没有专门讨论 SaaS 问题。
未来需要关注的一个指标可能是要求供应商根据公认标准(例如 BS-25999)对业务连续性计划进行审核。随着每家公司将认证要求推回其关键供应商,我们可能会看到业务连续性标准以 ISO-9000 标准的传播方式传播。
祝你的论文好运。你选择了一个有趣的话题。您可能还想在 LinkedIn 的灾难恢复日志组中提问。这是我发现的关于业务连续性问题的唯一真正活跃的讨论区。
在外包任何东西时,无论是开发、餐饮还是托管,服务可用性总是要考虑的(如果你经营一家工厂,你的餐饮供应商倒闭了,你的公司餐厅没有员工,你会怎么做?)。
在软件的情况下,代码托管是确保最小中断的一个步骤(即使当然总是会有一些中断)。
有时可以选择与备份托管提供商签订合同,将应用程序部署在冷备用状态并定期进行数据库同步。对于需要高正常运行时间的应用程序(我假设这里就是这种情况,因为您声明您甚至可以接受几天的停机时间)无论如何这都是必要的。毕竟,SAAS 提供商可能不会破产,但是如果一架飞机在托管他们的服务器场的建筑物上坠毁,您的应用程序也会被中断(我曾为一家 SAAS 提供商工作,我们在几个地方都有自己的备份服务器场为了确保服务的连续性,加上定期将代码转储发送到托管服务并发送到安全位置的存储以进行异地备份,客户没有理由不想拥有自己的冷备份,
作为一家小型 SaaS 提供商,我们经常被潜在客户问到这个问题。我们通过使我们的产品开源来解决这个问题。这可能不是适合许多人的选择,但对我们来说是最好的。
As a customer of SaaS I highly depend on services such as invoicing, e-mail, and software bug tracking. Until answering this question I hadn't given it much thought: I can quit the contract anytime, why can't they? On the other hand: my data needs to be secured. I have asked my suppliers (not expecting an answer soon from gmail :-) and in the mean time taken measures to frequently back-up.
Scary: none of my providers actually explain what happens in detail in their terms of service. Where should I expect such information? Where would a developer place such text?
好问题。在我工作的一家 SaaS 公司,我所在的团队开发了一套工具供托管团队内部使用,以快速部署客户安装。部署客户是一个复杂的过程,涉及测试/生产站点,每个站点有 7-10 台服务器。我们还制定了每晚备份客户数据的程序。
我想我们为内部使用而开发的工具可能已经为您描述的目的进行了产品化,并且这些工具连同客户的数据可以让他们接管产品。该工具集足够灵活,允许客户在不同的服务器配置上重新部署他们的数据。例如,在紧急情况下,他们可以将在 8 台服务器上运行的应用程序部署到 2 台服务器配置中,一旦他们设置好数据中心,就可以再次重新部署到性能更高的 8 台服务器配置中。
关于这个问题,一种可能的处理方法是意识到,虽然我与X公司有业务合作,但它是我的数据,驻留在该软件的数据存储中。因此,我应该得到一份它的副本(以 XML 格式,或任何商定的格式)。这样,如果公司倒闭了,我只需要我的数据的最新副本,我就可以把它带到别处。
在 SaaS 行业工作过,我知道很多公司都有不同的保存用户数据的方法——但他们也知道他们的竞争对手,并希望让公司能够轻松地将数据提供给他们进行加载。
好吧,我们做 SaaS,但我不确定管理层是否有连续性。我认为最常见的情况是 SaaS 提供商限制了他的服务和每份合同的责任,因此他们甚至不必考虑它。
作为一种可能的解决方案:公司可能会根据合同同意提供一些努力,以将数据迁移到客户选择的替代软件系统,以防它关闭其运营。除此之外,几乎没有什么可期待的。
作为一个非常大胆的选择:将数据库备份提供给将聘请顾问或对其进行零碎制作的客户。但这是一个紧急情况。
我想您总是可以设计您的系统,以便在您的公司即将倒闭的情况下,您可以为客户提供足够的服务器端软件、配置文件和数据,以便他们可以托管他们自己的服务版本。从本质上讲,给/卖给他们您的系统映像,让他们托管(内部或支付给其他人)足够长的时间以迁移到新系统。如果您在虚拟机中运行所有服务器端软件,这可能会更容易(本质上)为客户提供您的服务器。如果您的公司即将关闭,您甚至可以安排将 VM 映像直接转移到第三方托管服务提供商(并预付足够的时间来履行客户当前合同的剩余部分)。