1，SLA
SLA是Service-Level Agreement的缩写，意思是服务等级协议，一般是协议双方做的彼此承诺，放在运维的领域，很重要的一个结果指标就是系统的SLA，这个是技术向业务做的一个承诺。
系统SLA的定制方法一般有两种，一种是通过时间维度进行测算，另外一种是通过用户请求状态进行测算。

• 时间维度测算
  公式：
  
  PS：如果年度SLA，则n=365

  这种计算方式比较常规，通用，但真正较真起来，还是比较麻烦的，麻烦的地方主要有以下几点：
  1），业务中断怎么判断，须知一个业务完全中断的场景并不多见，往往是出现部分业务受到影响。
  2），复杂组织场景下，如何做责任划分，比如A部门引发的问题，但B部门的容错性做的也不好，这种情况A，B的各自SLA是多少？
  3），时间分片并不是完全等价的，业务高峰时的一个小时要比业务低谷值钱的多，如果按照同样的时间去计算，其实是有失公允的。
  鉴于以上种种原因，在公司SLA实际计算中，计算公式会变得非常复杂，比较常见的一种就是根据业务进行时间换算，公式为：
  
  PS：如果年度SLA，则n=365

举例：
如果一天的业务量是一万单，业务时出现故障高峰，持续一个小时，影响1000单，那么时间业务影响时间换算为：1000 / 10000 * 24 = 2.4个小时，当天的SLA为 90%，而非95.8%
这种算法的优点是：
直观，计算简单，业务部门容易理解
缺点是：
这是个结果指标，改进指向不明确。

• 用户请求状态测算
  公式：
  
  举例：
  如果一个系统，用户一天请求量为10000，其中5XX的请求为1000，那么当天的SLA为90%
  优点：
  可以有针对性的改进，只要增加访问成功率即可
  缺点：
  业务不容易理解，在什么事请求成功上容易产生分歧

2，支撑SLA的运维指标
SLA一般我们定义为结果指标，也就是到最后一刻才知道是否正常，所以一般需要有一些过程指标进行跟踪，这里着重介绍一下运维侧指标，开发侧比较简单，不做详细介绍

• 一级指标
  一级指标直接承载SLA，指标好坏，会对SLA有直接影响
  1），故障次数，这个比较理解，就是有业务影响的异常次数
  2），故障的平均恢复时间，为了避免某几个故障处理时间过长，导致指标不能反映真实情况，一般会采用P90，P95的故障平均恢复时间
  3），N分钟内的异常恢复比例，N的取值和公司的技术能力和实际情况定，以故障为例，一般是30分钟能恢复就已经很不错了
• 二级指标
  二级指标间接承载SLA，指标好坏会对一级指标有直接影响
  1），用户报障比，有多少故障是用户发现的，而非监控系统发现的
  2），自动化变更占比，数字证明，自动化的变更质量要更好一些
  3），问题及时解决率，问题单尤其是故障产生的问题单解决效率
  4），事件及时解决率，事件单及时处理效率
  5），告警及时处理率，这个是把故障控制在萌芽中的很有效手段
  6），监控覆盖率，生产重要的应用和组件的监控覆盖程度

这些指标计算公式比较简单，这里不赘述。