无法验证SLA性能数据。客户依赖于提供商来度量SLA，而不是依赖于客观工具来自动获取SLA性能数据。这是一个错误;自动化工具将为SLA性能提供更准确的表示，并减少分歧。
SLA定义。提供者经常编辑建议的SLA定义，以便更容易地满足SLA。例如，事件响应时间是一种SLA，旨在确保提供者的人员在最少的分钟数(例如，10分钟)内处理事件。但是，有些提供商通过对其事件队列中收到的任何电子邮件进行自动回复，100%地满足了SLA。客户应该仔细定义sla，以便它们表示和度量服务水平的意图，而不仅仅是定义的术语的语言。
还没有实现的sla。一些供应商在市场领先的sla面前畏缩不前，因为之前在客户环境中没有实现过sla，而一些客户认为这种定位是合理的。相反，客户应该关注他们的业务需要的sla，而不管过去是否实现了这样的sla，并在一定程度上根据提供者提议如何满足这些新服务级别来选择提供者。
SLA异常的过程。一旦SLA就位，一些提供者将努力创建异常，以确保提供者永远不会错过SLA。客户需要强大的SLA治理，以避免诸如为了重置时钟而更改事件优先级级别、在供应商等待澄清时调用“保持时间”或任何与第三方参与有关的借口。
为了开发考虑到应用程序开发和维护(ADM)复杂性的sla战略集，客户应该记住什么?
Kirz:客户需要记住，ADM服务是在一个持续的道路上，远离人员的增加，并向基于结果的解决方案(或管理的服务)前进。因此，需要转向与服务交付模型保持一致的服务水平度量组合。这可能意味着重新定义指标和调整优先级。客户应该为此做好准备，并推动与服务提供商的对话，这样他们就可以满足内部利益相关者日益增长的需求。
首先，可以而且应该应用于人员扩充工作的sla。任何由供应商控制的人员扩充都可以而且应该有一个SLA(例如，机载资源的时间或人员更替)。
其次，用于维护的sla与用于开发的sla非常不同。每个工作区域都应该有自己的sla集、风险金额和信用点池。
第三，sla必须随着时间不断改进。客户要么不包含确保sla持续改进的条款，要么允许提供商指定仅允许逐年进行微小改进的统计方法。相反，客户应该包括确保sla每年都会改进的语言。
IT领导应该考虑哪些有效的ADM sla ?
Kirz:在人员扩充中，以度量为中心的sla关注于人员的入职、减员、生产力和编码质量，这些sla往往会工作得很好。对于托管服务，我们希望看到与预期结果一致的度量标准——例如，票证解决时间框架、批处理效率、应用程序可用性和客户满意度。更重要的是，客户应该认识到，大多数交易都有管理服务和员工增加组件，所以一个全面的度量组合是关键。
在应用程序开发中——除了标准sla之外——客户还应该考虑包括管理变更管理遵从性、功能规范遵从性的sla，以及在发布前多远解决所有缺陷。
在应用程序维护中，除了标准sla之外，客户还应该考虑包括管理根本原因分析的速度、综合事务时间和重新打开票证的数量的sla。
“如何为更具战略性的应用程序外包构建更好的sla”这篇文章最初由首席信息官 。