我一直在仔细比较Java PaaSes，并真的开始喜欢CloudBees。我对他们只关心一个大问题，那就是他们的SLA /正常运行时间。
仔细阅读他们的所有文档后，我只能找到one paper they offer on SLAs，其中指出：
如果您在不利用高可用性选项的情况下使用CloudBees PaaS，则CloudBees只能提供接近于以下基础正常运行时间SLA的正常运行时间：
基础架构云提供商。
正如同一篇文章还提到的那样，亚马逊似乎提供了99.95％的正常运行时间，而且我知道CloudBees在很大程度上运行于AWS / EC2实例本身。
因此，这产生了许多紧密相关的SLA问题：
如果我不利用“高可用性”选项，那么我可以假设CloudBees甚至不能保证99.95％吗？还是在其他地方有说明其正常运行时间的文档，以及未达到正常运行时间的补救措施？
他们在这里谈论什么高可用性选项？我只是阅读了他们的整个开发人员文档，却从未见过有关HA的任何信息。
如果合作伙伴服务（例如，用于邮件的SendGrid或用于缓存的MemCachier）出现故障，我有什么补救措施？我喜欢GAE的一件事是它的CapabilitiesService，在使用它们的Email API或缓存API之前，首先要与主CapabilitiesService进行核对，以确保这些服务正在运行。我想对CloudBees做同样的事情，但是似乎我需要自己构建它。很好，但是不确定CloudBees是否甚至提供一种机制（API调用等）来确定特定服务合作伙伴是在线还是离线。
提前致谢！
最佳答案
如果一个月内未达到特定的正常运行时间，CloudBees将不提供关于可用性的SLA或以积分的形式提供补救措施。这是AWS上其他产品（例如Heroku）常见的AFAIK。 CloudBees确实通过支持协议提供了基于标准响应时间的SLA。如您参考的白皮书中所述，我们还采用了自己使用AWS和外部提供商的做法，这有助于使我们的用户与某些特定的Amazon问题隔离开。
您可以利用的可用性功能包括：
使用多个实例（并可能自动缩放）。 CloudBees将应用程序实例分散在不同的EC2实例中，因此您可以避免EC2实例发生故障时的停机时间。
使用session store。您可以使用我们的产品或Memcachier之类的合作伙伴产品，在与应用程序实例不同的层次中共享会话状态。
使用dedicated servers，CloudBees可以在多个AWS可用性区域中进行设置。
确保与您的应用程序一起使用的数据库是在高可用性配置中设置的。例如，RDS易于与CloudBees一起使用，并支持多个AZ中的备用数据库和读取副本。
使用来自合作伙伴（例如New Relic和AppDynamics）的应用程序监视解决方案来提醒您任何问题。
关于使用“高可用性选项”的评论的主要目的是警告人们，仅在CloudBees上部署应用程序并不能使其具有高可用性。如果EC2实例在您的单实例部署下失败，则您的用户将经历停机时间，而我们的内部机械将其重新部署到工作实例，而在部署新实例之前，多实例部署可能只会遇到较慢的响应。与单实例数据库相似，没有跨AZ的备用数据库或副本。尽管这只是对许多人来说是令人眼花，乱的显而易见，但您可能会惊讶地发现，有许多人只是认为正在发生某种魔术。
关于CapabilitiesService的要点！我们在这方面有一些想法，但是您现在必须自己做类似的事情。
关于java - CloudBees服务级别协议(protocol)和功能服务，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16543543/