大量的SLA在向这个世界作出承诺，只因为即使没有达到标准也几乎没有问责。

IT部门接受SLA指标后，由于未达到标准而受到的惩罚往往很轻微。由于应用响应缓慢而炒掉管理整个数据中心的员工并没有任何意义。企业可能会将应用外包给服务供应商，但设置并强制执行SLA指标的问题仍旧存在。

预先监控

大多数企业都有服务器、存储及网络设备，并由服务外包合作伙伴提供技术支持，每一类设备都有相应的服务级别要求。

发生负面事件时SLA是一种惩罚IT团队或者外包合作伙伴的方式吗？如果是这样，怎么能够为企业提供帮助呢？
例如，如果组织和外部服务供应商签订了SLA协议，其中可能包括了针对负面事件的财务惩罚。然而，如果无法访问服务导致组织无法完成业务交易，你将如何计算业务损失？让外部服务商支付接近SLA处罚的费用基本是不可能的。在财务惩罚几乎没有意义时，内部团队如何应对呢？

SLA应该确保服务级别是可实现的，应该包括过去、现状以及对将来的预期。

预先监控是SLA成功的关键。例如一个SLA指标决定了服务响应可接受的速度，规定每个小时的平均响应时间小于500ms是可接受的。

应用启动时，平均响应时间是300ms，低于SLA设置的阈值。然而，随着使用人数不断增加，系统的响应时间会缓慢增加：350ms、405ms，然后是470ms。如果只监控系统响应时间的均值，那么看起来系统参数仍旧在可接受的范围内。但如果在主动监控系统，那么在违反SLA之前你已经看到响应时间存在问题。

修复问题

跟踪趋势并在响应时间违反SLA之前采取行动。必须采取长期有效的措施，或者调整代码或者扩容硬件。

确定问题原因。系统响应慢是由于应用潜在的问题还是由于用户数增加？如果应用性能低下，要识别出根源—例如内存泄露—并编制系统修复计划。如果问题源于用户数增加，那么要对应用使用的硬件资源进行扩容。

随着工作负载的不断增加，服务供应商应该向企业建议保持服务级别需要做哪些工作，否则预先设定的服务级别是不切实际的。例如，如果用户数增加拖慢了应用，那么提高虚拟机的配置可能能够解决该问题，但需要支出更多的费用。如果IT预算不允许增加更多的硬件资源，那么就要在成本与服务级别之间进行权衡：例如IT支出更少，但服务级别要下降到响应时间为550ms，这是否可行？

内部SLA更复杂

就内部SLA进行谈判要更复杂。自有数据中心混合托管以及基于云服务的异构环境意味着“主”SLA需要参考IT部门与外部服务供应商之间的协议。附属SLA也要采用同样的方式。我们的目标是与供应商建立灵活的关系以避免宕机或者在性能或成本上的巨变，而不要考虑所谓的惩罚。

SLA应该是活生生的协议，而不是被遗忘的文档。定期回顾SLA以确保现有的指标仍旧符合初衷。企业必须定期重新审视SLA—三个月之前响应时间为500ms在今天看来可能太慢了，因为有其他竞争对手进入了这个市场。重新审视SLA，企业将会知道做哪些投资能够将目标响应时间下降为350ms或者400ms，而不仅仅是设置一个不合理的SLA而又没有强制的惩罚措施。

未达到SLA时只讨论惩罚措施。这时，双方的关系已经破裂了。有一个面向业务的B计划：谁来替代哪些对未达到SLA负有责任的人？你真的能够炒掉整个IT部门吗？应该将炒掉整个IT部门作为最后的选择。