使用 SaaS 产品保证业务连续性的好方法有哪些？
在我的学士论文中，我正在研究 SaaS 提供商如何安排某种业务连续性保证。
您可能知道“收缩包装”软件的源代码托管安排。当软件供应商遇到（财务）麻烦时，他们可以让客户访问源代码和所有适用的文档。这显然不适用于 SaaS，因为客户仅使用源代码是没有用的，并且客户可能无法承受由于 SaaS 提供商破产而导致几周无法登录 CRM 系统的后果。我目前正在研究不同的方法来解决这个问题。
您知道解决这个连续性问题的好的、实用的解决方案吗？或者已经提供好的解决方案的公司？
谢谢！
For my Bachelor Thesis I am researching how SaaS providers can arrange some sort of business continuity guarantee.
You probably know the Source Code Escrow arrangements for 'shrink-wrapped' software. They give customers access to the source code and all applicable documentation whenever the software supplier gets into (financial) trouble. This clearly does not work for SaaS, because customers have no use for just the source code, and customers probably can not afford not being able to login to their CRM system for a couple weeks because the SaaS provider went bankrupt. I am currently researching different methods to solve this problem.
Do you know good and practical solutions to solve this continuity problem? Or companies that already offer a good solution?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我认为你需要区分两种情况：
您提出的问题通常出现在考虑使用 SaaS 服务的公司的背景下。在这些情况下，谨慎的公司（作为其业务连续性计划的一部分）需要（a）确保供应商的财务可行性（有趣的是，大多数回答这个问题的人都认为这是主要风险），并且（b）确保供应商本身拥有适当的业务连续性计划，该计划将在发生所有重大风险时确保提供服务。 （例如，如果数据中心发生火灾，必须暂时关闭，是否有替代方案。是否处于热备状态？数据是否重复？可能会丢失多少数据？网络流量是否可以重新路由？等等.)
当然，客户还必须担心网络连接问题：供应商可能正在营业但无法联系到。以及（在跨境案例中）政治和监管风险。
事实上，SaaS 供应商的担忧与任何其他外包关键服务或产品的提供商并没有什么不同。 （如果您组装了定制法兰和定制索环来生产小部件，那么如果您的供应商出于任何原因无法向您提供法兰，您就会遇到麻烦。）
有趣的是，对于拥有几个大客户的 SaaS 供应商来说，财务状况是一个问题 。客户的生存能力和业务连续性。大型零售商的倒闭有时会导致其供应商的倒闭：供应商不仅背负巨额无担保债务，而且还缺少分销链的主要部分。
Jan Husdal 写了一篇有趣的关于供应链业务连续性问题的博客，尽管我认为他没有涵盖 SaaS 问题具体来说。
未来值得关注的一个指标可能是要求供应商按照公认的标准（例如 BS-25999）审核业务连续性计划。随着每家公司将认证要求推回其关键供应商，我们可能会看到业务连续性标准以 ISO-9000 标准的方式传播。
祝你的论文顺利。您选择了一个有趣的主题。您可能还想在 LinkedIn 上的灾难恢复日志群组中提出问题。这是我发现的关于业务连续性问题的唯一真正活跃的讨论区域。
I think you need to distinguish two cases:
The question you ask normally comes up in the context of a company considering using SaaS services. In these cases a prudent company (as part of its business continuity plan) needs to (a) assure itself of the financial viability of the supplier (interesting that most people answering this question see this as the main risk), and (b) assure itself that the supplier has an adequate business continuity plan which will assure services in the event of all major risks. (For example, if a data center has a fire and has to be shut down temporarily, is there an alternate. Is it on hot standby? Is data duplicated? How much data could be lost? Can network traffic be re-routed? etc.)
Of course, the customer also has to worry about network connectivity issues: the supplier may be in business but unreachable. And (in cross-border cases), political and regulatory risks.
The concerns for a SaaS supplier are in fact not that different from any other provider of outsourced critical services or products. (If you have assemble custom flanges and custom grommets to produce widgets, you will be in trouble if your supplier can't supply you with your flanges for whatever reason.)
Interestingly a concern for a SaaS supplier with a few large customers is the financial viability and business continuity of its customers. Failure of a major retailer sometimes results in the failure of its suppliers: not only are the suppliers left with large unsecured debts, they are left lacking a major part of their distribution chain.
Jan Husdal writes an interesting blog on issues of supply chain business continuity, although I don't think he has covered SaaS issues specifically.
One indicator to watch for the future may be the requirement for a supplier to have a business continuity plan audited to a recognized standard (e.g. BS-25999). It may be that we will see business continuity standards propagating in the way that ISO-9000 standards propagated as each company pushes back certification requirements to its critical suppliers.
Good luck with your thesis. You've chosen an interesting topic. You might also want to ask your question in the Disaster Recovery Journal group on LinkedIn. It's the only really active discussion area on Business Continuity Issues I've found.
在外包任何东西时，无论是开发、餐饮还是托管，服务可用性始终是需要考虑的问题（如果您经营一家工厂，而您的餐饮提供商破产了，导致您公司的餐厅没有员工，您会怎么做？）。
就软件而言，代码托管是确保最小中断的一个步骤（即使当然总是会出现一些中断）。
有时可以选择与备份托管提供商签订合同，将应用程序部署在冷备用上并定期进行数据库同步。
对于需要高正常运行时间的应用程序（我认为这里就是这种情况，因为您声明您甚至可以接受几天的停机时间），无论如何这是必要的。
毕竟，SAAS 提供商可能不会破产，但如果一架飞机在托管其服务器场的建筑物上坠毁，您的应用程序也会受到干扰（我曾为 SAAS 提供商工作过，并且我们在多个地点拥有自己的备份服务器场）为了确保服务的连续性，加上定期将代码转储发送到托管服务并发送到安全位置的存储以进行异地备份，客户没有理由不希望拥有自己的冷备份，或者至少有一个合同选项可以在由于当前合同持有人破产而导致服务中断的情况下接管托管合同）。
Service availability is always something to consider when outsourcing anything at all, be it development, catering, or hosting (what would you do if you run a factory and your catering provider goes bust, leaving your company restaurant with no staff?).
In the case of software, code escrow is a step to ensure minimum disruption (even if there will of course always be some disruption).
Having a contract with a backup hosting provider where the application is deployed on cold standby with regular database synchronisation can sometimes be an option.
For applications that require high uptime (which I assume is the case here as you state you can accept even a few days downtime) that's a necessity anyway.
After all, the SAAS provider might not go bankrupt but if an aircraft crashes on the building hosting their serverfarm your application is going to be disrupted too (I've worked for a SAAS provider, and we had our own backup server farms in several locations to ensure continuity of service, plus regular code dumps sent to an escrow service and sent off to storage in a secure location to have off-site backups, no reason why a customer shouldn't want to have their own cold backup as well, or at least a contract option to take over the hosting contract in case of disruption of service due to bankruptcy of the current contract holder).
作为一家小型 SaaS 提供商，我们经常被潜在客户问到这个问题。我们通过将我们的产品开源来解决这个问题。这可能不适合很多人，但对我们来说是最好的选择。
As a small SaaS provider, we are frequently asked this question by prospective clients. We addressed it by making our product open source. This may not be an option suitable to many but was the best for us.
我们做 SaaS，但我不确定管理层是否考虑过连续性。我认为最常见的情况是 SaaS 提供商根据合同限制其服务和责任，因此他们甚至不必考虑这一点。
作为一种可能的解决方案：公司可能会根据合同同意提供一定的工作量，以将数据迁移到客户选择的替代软件系统，以防其关闭运营。除此之外，几乎没有什么可期待的。
一个非常愚蠢的选择是：将数据库备份提供给将雇用顾问或从中获取零碎信息的客户。但这是一个紧急情况。
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.
我想你总是可以设计你的系统，以便在你的公司即将倒闭的情况下，你可以为客户提供足够的服务器端软件、配置文件和数据，以便他们可以托管他们自己的服务版本。本质上，向他们提供/出售您系统的映像，以便他们托管（内部或付费给其他人）足够长的时间以迁移到新系统。如果您在虚拟机内运行所有服务器端软件，这可能会（本质上）更容易为客户提供您的服务器。如果您的公司即将关闭，您甚至可以安排将虚拟机映像直接转移到第三方托管提供商（并预付足够的时间来履行客户当前合同的剩余部分）。
I suppose you could always design your system so that in case your company is about to go under, you could provide customers with enough server-side software, config files, and data that they could host their own version of your service. Essentially, give/sell them an image of your system for them to host (either internally or pay someone else to) long enough to move to a new system. If you run all your server-side software inside a virtual machine, this may make it easier to (in essence) give the customer your server. You may even be able to arrange for the VM image to be transferred directly to a third-party hosting provider (and pre-pay for enough time to fulfill the remainder of the customer's current contract) if your company is about to shut down.
作为 SaaS 的客户，我高度依赖发票、电子邮件和软件错误跟踪等服务。在回答这个问题之前，我没有多想：我可以随时退出合同，为什么他们不能？另一方面：我的数据需要受到保护。我已经询问了我的供应商（没想到很快会从 gmail 得到答复:-），同时采取了经常备份的措施。
可怕的是：我的提供商都没有在他们的服务条款中详细解释发生了什么。我应该在哪里期待此类信息？开发人员会将此类文本放置在哪里？
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?
关于这个问题，处理它的一种可能方法是认识到，虽然我与 X 公司就某个软件有业务往来，但驻留在该软件中的是我的数据。软件的数据存储。因此，我应该获得一份它的副本（XML 格式，或任何商定的格式）。这样，如果公司倒闭，我只需要最新的数据副本，并且可以将其带到其他地方。
我曾在 SaaS 行业工作过，知道很多公司都有不同的方式来保存用户数据，但他们也了解自己的竞争对手，并希望让公司能够轻松地将数据加载给他们。
With regards to this problem, a possible way to handle it is to realize that while I have business with company X for a piece of software, it's my data that resides in that software's data store. Ergo, I should be provided with a copy of it (in XML, or whatever format agreed upon). That way, if the company should go out of business, I simply need the latest copy of my data, and I can take it elsewhere.
Having worked in the SaaS industry, I know that a lot of companies have different ways of saving user data -- but they also are aware of their competitors and want to make it easy for companies to bring data to them to load.
好问题。在我工作的一家 SaaS 公司，我所在的团队开发了一套工具，供托管团队内部使用，以快速部署客户安装。部署客户是一个复杂的过程，涉及测试/生产站点，每个站点都有 7-10 台服务器。我们还制定了每晚备份客户数据的程序。
我想我们开发的供内部使用的工具可能已经产品化用于您所描述的目的，并且这些工具以及客户的数据可以让他们接管产品。该工具集足够灵活，允许客户将其数据重新部署到不同的服务器配置上。例如，在紧急情况下，他们可以将在 8 台服务器上运行的应用程序部署到 2 台服务器配置中，并且在设置好数据中心后，再次重新部署到性能更高的 8 台服务器配置。
Good question. At a SaaS company I worked for, I was on a team that developed a suite of tools for internal use by the hosting team to rapidly deploy a customer installation. Deploying a customer was a complicated procedure involving test/production sites with 7-10 servers each. We also had procedures in place to take nightly backups of customer data.
I suppose the tools we developed for internal use could have been productized for the purpose you describe, and these tools along with the customer's data could allow them to take over the product. The toolset was flexible enough to allow the customer to redeploy their data on a different server configuration. For example, in an emergency they could deploy an app that had been running on 8 servers into a 2 server configuration, and once they had their data center set up, redeploy again to the more performant 8 server configuration.