外部云计算">服务水平协议专注于提供商的数据中心和网络基础架构的特征。尽管公司可以为其私有的平台即服务 (PaaS) 设置云计算 SLA，使 SLA 基于提供商公共的基础架构即服务 (IaaS)，但公司可能希望更多地掌控操作系统、服务器和网络基础架构，从而解决一些问题（比如频繁的服务中断）的根源。
通过调用附加到外部 SLA 的附加条款，公司可以将私有 PaaS 应用程序迁移到其内部数据中心。当公司解决问题之后，就可以将更加健全的 PaaS 应用程序返回到云中。
本文提供了一个内部化 SLA 的路线图，其中的场景提供了 SLA 变量、服务元素和用户控件，使用一条策略演示了如何最佳地管理 SLA。
内部化的 SLA 在 SLA 领域相对比较新颖。它们是外部 SLA（最古老的居民）与内部 SLA（不是很年轻的居民）相混合的产物。能够将它们用作有效工具主要是因为云计算基础架构的激增，系统和应用程序资源可能被多次复制并位于不同的位置。
外部 SLA 居民分散在外部云中，在客户、供应商、网络服务提供商和其他外部组织之间形成了复杂的关系。可伸缩性是云的最大优势之一。外部提供商能够控制操作系统、服务器和外部网络基础架构。
内部 SLA 居民主要是企业中的 IT 部门，他们发现通过外部网络传输数据的成本非常高。这些企业负责管理其内部数据中心内的操作系统、服务器和网络基础架构。
内部化的 SLA 结合了两家之长。在外部 SLA 上附加了一个附加条款。该附加条款允许云使用者将 PaaS 应用程序从外部云传输到公司的内部数据中心。应用程序到达之后，公司中待用的内部 SLA 将被重新激活。
云使用者（在本例中充当内部提供商）能够更多地掌控需要修复问题的操作系统、服务器和网络基础架构。云使用者在重新激活外部 SLA 后，将更加健全的 PaaS 应用程序返回给外部云。
理念就是这样的。让我们更详细地分析一下这个理念。
常见 SLA 特征
SLA 领地的所有居民都有一个共同特点。根据定义，SLA 是两方或更多方在服务质量、优先级和责任方面的期望。云服务客户委员会将云计算 SLA 视为 云使用者和提供者之间关于服务的书面期望。决策者在评估和对比来自云计算提供商的用户 SLA 时，该委员会为他们提供了有关期望的内容和应知道的事项的指南。
这些居民的一个特征是，从 SLA 的所有各方寻找输入，以便让 SLA 在服务的重大重组、精简和整合期间成功生效。SLA 应具备的另一个特征是，参照规范来操作云服务的底层 IT 基础架构。
场景 1：用于私有 PaaS 的内部 SLA
公司作为内部提供者，负责提供传统 IT 和内部云服务的内部数据中心。公司控制着支撑其私有 IaaS 的虚拟机的操作系统、服务和网络基础架构。所有 PaaS 应用程序都位于这些虚拟机之上。
公司与开发人员就私有 PaaS 的内部 SLA 进行协商。SLA 中包含 4 个阈值（稍后将解释）：
用户 资源 数据请求 响应时间
所有指定为 PaaS 上的共驻居民的 SaaS 用户都表明，他们可以顺利地访问 PaaS 应用程序，没有出现过服务中断。PaaS 平台的性能符合 SLA 中规定的保证的服务可用性水平。SaaS 最终用户的期望已得以满足。所有 PaaS 开发人员都很满意。
场景 2：用于云中的私有 PaaS 的外部 SLA
公司希望将它的私有 PaaS 放在提供商的公共 IaaS 之上，视图可根据开发、测试和运行 PaaS 应用程序的需要来扩充和精减云资源。公司数据中心内的操作系统、服务器和网络基础架构与外部提供商的数据中心类似。
迁移到云之前，公司作为云计算使用者，与外部提供商就其私有 PaaS 的外部 SLA 进行协商。作为协商的一部分，云使用者能够控制一个完整业务生命周期内存在的所有应用程序。外部提供商能够在最低限度上进行控制：
操作系统 服务器 网络基础架构
与分配给公司数据中心内的 PaaS 应用程序开发人员的控制权相比，这些控制权更有限。
外部提供商限制了与公司就用户、资源和数据请求阈值水平的控制。提供商允许 SaaS 最终用户访问云中的私有 PaaS 应用程序。
没有出现服务中断。所有 PaaS 开发人员都很满意。