利用服务级协议管理系统需求

S L A（Service Level Agreement，服务级协议）是一种正式定义关于系统可用性与系统性
能的特定需求问题的文档。只有经过终端用户与系统管理者之间的协商讨论之后，才有可能
达到需求上的一致性。 S L A的目标就是确保系统管理者与终端用户在数据库服务质量上的一
致性。其中详细地说明了对于系统失败的定义以及从这种失败中进行恢复所需要做的工作。
一个优秀的S L A也会指定性能与可用性之间的折衷关系以及为了实现系统高可用性与高性能
所花费的代价之间的关系。公司内部的 S L A同时也是公司与第三方硬件 /软件提供者之间建立
外部S L A的依据。

一般来说，S L A必须满足以下特点。
1. 完整性
一个优秀的S L A必须列出所有影响公司业务的关键因素。例如，为了保证公司的生存，
数据库系统的停工时间不能超过三个小时，这个问题就必须在 S L A中明确说明。如果公司的
数据库系统需要必须保证能够允许至少2 0 0个并行会话同时进行，也必须在S L A中说明。
2. 必须使用真实的数据
公司数据库系统的所有需求问题都必须用真实的数据进行量化。也就是说，在 S L A中必
须使用精确数据来描述每个用户需求问题。例如，如果公司的数据库系统需要跨地区使用一
个备用数据库，需要花费的开销为X；而由于使用了这个备用数据库，对于主数据库系统所带
来的性能压力为Y，那么这样两个问题就必须在 S L A中进行说明。当然，X与Y也可以不是真
实的开销数据，但必须是真实的百分比数据。这样，就可以帮助终端用户与系统管理人员在
系统高可用性问题上进行折衷处理。如果单纯地说明使用这个数据库所带来的性能减弱，并
不能非常有效地解决问题。因为有了适当的真实数据就可以增加自己的说服力，从而使得它
更为可信，而不是建立在模糊的假设之上。在这里， S L A又可以看做是一种合同协议。因此，
在S L A中不能简单地说“如果 A，那么将会B”，而应该更为清晰地指出“如果 A，那么将会
B；而如果C，那么将会D。而且，后一种方案的代价是前一种方案的两倍”。
3. 适应性
S L A必须具有动态可适应性，并且能够反映最新情况。许多公司在建立 S L A之后，就会
在几个月之后完全忘记其中的内容。造成这种问题的原因之一，就是 S L A的固定性，以致于
S L A不能适用于实际的情况。大多数情况下，在 S L A的创建过程中公司会考虑到当时的实际
情况，但是随着公司的不断发展壮大，这些情况也会作相应的改变，而不是静止不变的。因
此，必须对S L A作周期性的修改，以便能够适应公司具体情况的改变。特别是在网络时代，
用户对数据库访问的模式改变得非常迅速，更加应该保证 S L A的可扩充性以及兼容性。如果
根据公司的实际情况，要求每两个月就必须重新制定 S L A，那么公司也必须进行相应的 S L A
制定。例如，在电子商务的初期，公司中的所有顾客都只能算是“ G u e s t”，那么这时的S L A
就必须基于这样一个考虑来制定。随着电子商务的发展，那么就有一批顾客会经常使用公司
的数据库系统，那么公司就完全有必要重新修改自己的 S L A。可以说，某个公司的 S L A版本
越老，那么它与公司目前实际情况之间的差异就越大。在公司决定购买新的硬件或者软件时，
就必须根据S L A中的条款作出决策。这时，就非常有必要立刻更新 S L A。
4. 内容清晰
在S L A中所定义的条款必须非常精确与清晰。必须对其中的每个条款给予足够的解释，
使得不能对其中的任何条款产生二义性解释。例如，如果只是在 S L A中说明“要求采用高可
用性系统”，而不对其作任何解释，那么这种条款是没有意义的。而且，应该在条款中指出必
须保证的正常工作时间，同时列出对系统进行维护时间声明。如果同一个数据库需要为多个
应用程序服务，那么在 S L A中可以给出所有这些应用程序的累积需求，或者为每个应用程序
分别给出其可用性需求并为所有的应用程序产生一个综合的高级可用性需求表。此外，如果
能够以每天中的时间分段的方式给出系统可用性需求，那么对于公司的数据库系统可用性开
发是非常有意义的。表1 - 4提供了一个说明系统正常工作时间需求的文档示例。此外，还必须
说明系统的性能需求。例如，应该在文档中指出，如果系统中有 1 5 0个用户，那么小型的报表
可以在1 0分钟或者更短的时间内给出结果；但如果系统中的用户超过了 1 5 0个（例如在高峰
期），那么这种报表就需要3 0分钟才能给出结果。因此，必须在 S L A中列出高峰期性能与非高
峰期性能、关键应用程序性能与非关键应用程序性能。
根据上面的需求分析，操作管理部门就可以决定何时进行系统维护（例如备份与索引重
建）。同时，将所有运行在特定时间段上的应用程序进行罗列，有利于 D B A决定什么类型的部
分可访问性对于终端用户是合适的（也就是说，什么类型的表空间可以在某个时间内被脱机，
而什么类型的表空间又不能被脱机）。在数据库系统恢复的过程中，这些信息可以帮助 D B A决
定哪一个应用程序需要首先被恢复。如果数据仓库批处理工作没有必要立刻运行，那么就不
必首先执行数据仓库表的恢复动作；相反，可以将销售应用程序表优先恢复。
5. 经济可行性与技术可行性
一个有效的S L A必须考虑公司经济可行性与技术可行性的问题。在 S L A中所列出的任何
高可用性解决方案都不应该仅仅是在技术上可能的，而且必须考虑本公司的实际承受能力。
任何不能同时满足这两个要求的 S L A条款都是不可行的，因此也不适于实际的实现。
6. 可接受的平均时间
一个有效的S L A必须直接指定（或者利用附加文档指定）对于数据库系统可接受的 M T B F
时间或者M T T R时间。M T B F（失败之间的平均时间）是一个系统在失效之前平均的工作时间。
M T T R（Mean Time to Recover，平均恢复时间）是数据库系统在失败之后，进行系统恢
复所需要花费的时间。