对于我的学士论文,我正在研究SaaS提供者如何安排某种业务连续性保证。
您可能知道“收缩包装”软件的源代码托管安排。每当软件供应商遇到(财务)麻烦时,它们就使客户可以访问源代码和所有适用的文档。这显然不适用于SaaS,因为客户仅使用源代码就没有用,而且由于SaaS提供商破产,客户可能无法承受数周无法登录其CRM系统的负担。我目前正在研究不同的方法来解决此问题。
您知道解决该连续性问题的好的实用方法吗?还是已经提供好的解决方案的公司?
谢谢!
最佳答案
我认为您需要区分两种情况:
您提出的问题通常是在考虑使用SaaS服务的公司中提出的。在这种情况下,审慎的公司(作为其业务连续性计划的一部分)需要(a)确保自身供应商的财务可行性(有趣的是,大多数回答此问题的人将其视为主要风险),以及(b)确保供应商本身有足够的业务连续性计划,以确保在发生所有重大风险时都能提供服务。 (例如,如果数据中心着火了,必须暂时关闭,是否存在备用设备?它是否处于热备用状态?数据是否重复?有多少数据可能丢失?网络流量是否可以重新路由?等)
当然,客户还必须担心网络连接问题:供应商可能在营业但无法到达。并且(在跨境情况下)political and regulatory risks。
实际上,SaaS供应商所关注的问题与外包关键服务或产品的任何其他提供商没有什么不同。 (如果组装了自定义的法兰和自定义的扣眼以生产小部件,那么如果供应商出于某种原因无法为您提供法兰,就会遇到麻烦。)
对于拥有少量大客户的SaaS供应商而言,有趣的是其客户的财务可行性和业务连续性。大型零售商的失败有时会导致其供应商的失败:不仅使供应商背负了巨额无抵押债务,而且供应商也缺乏其分销链的主要部分。
Jan Husdal写了一个有趣的blog on issues of supply chain business continuity,尽管我认为他没有专门讨论SaaS问题。
可以预见 future 的一项指标可能是要求供应商对业务连续性计划进行审核以采用公认的标准(例如BS-25999)。也许我们会看到业务连续性标准正在以ISO-9000标准传播的方式传播,因为每个公司都将认证要求推回了关键的供应商。
祝你好运。您选择了一个有趣的话题。您可能还想在Disaster Recovery Journal group on LinkedIn中问您的问题。这是我发现的有关业务连续性问题的唯一真正活跃的讨论区域。
关于cloud - 有什么好的方法可以保证SaaS产品的业务连续性?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2297785/