运维考核

开宗明义，考核就是通过数据来描述工作目标的完成情况。这就是我对考核的认识。因此考核的内容不是工作过程，而是工作的结果。量化工作目标就是SLI的选择过程，而工作目标就是运维的目的和业务目标结合确定的。

运维的目的就是：

1、确保形成一条快速的，可预测，持续不断的计划内工作流，向业务部门交付工作价值。

2、同时降低计划外工作的影响和破坏，提供稳定的，可预期的，安全的IT服务。

这个只是对运维目的的认知描述。明确目的后，再根据目的来选择哪些指标可以衡量目的是否实现。第一条目的主要是持续交付和支撑类工作。对于持续交付来说有如下关键词：交付频率（以开发为主），交付时间（测试时间是否可控），成功率（回滚的原因也可能是业务功能问题），都无法作为运维的指标。支撑类工作还是以流程为主，这部分依托公司大环境情况吧。这里我只分享第二条目的的考核，而此条目的的工作目标就是：稳定，快速，安全。

在分析运维需要哪些指标可以比较准确的反映出业务目标时，可以依据以下两点：

l可量化。必须有信服的数据获取方式。

l能够直接的反映业务目标

基于工作目标，我认为的运维指标（SLI）如下：

l延迟：直接反应用户体验情况，也能反应某个服务的饱和度情况。通常服务的饱和度（cpu，内存，磁盘空间，磁盘IO，网络流量）超过一定阈值，都会造成延迟的增加。延迟数据有两种获取方式：a、用户端完成一个请求的时间；b、服务端处理完成请求的时间。理想情况下，方式a获取的信息是最准确的，但需要根据业务情况。如果客户端是APP就比较容易获取（比如APM），而如果是浏览器就做不到了（js可以获取部分接口的响应时间）。方式b是比较容易实现的，服务端可以轻易的获取到数据。

l错误率：服务端响应不正确的内容的速率。错误率的增加也意味着可用性的下降，必须将错误率（实时性指标）控制在一定范围，才能保障可用性（周期性指标）的达标。因此，此项指标是对可用性的一种保障。通常情况都是根据HTTP状态码（5xx）来判断响应是否错误。

l可用性：两个维度的数据

a)格式正确的请求处理成功的比例。此项主要是针对内部服务。此处强调格式正确，目的是屏蔽掉4xx请求。可用性计算方法：(2xx+3xx)/(2xx+3xx+5xx)。此项SLI需要注意的是，如果服务有限流措施，在触发限流限制时，会造成请求失败，尤其在被攻击时，会造成可用性大幅下降。

b)服务可用时间占总服务时间的百分比。此项主要是针对出口网络和出口的负载均衡。这个可用性是在架构设计时就已经明确了（说白了就是按目标可用性去设计的），因此是实际执行效果。数据获取方式就是：（时间周期-故障迁移时间）/时间周期。

l数据安全：数据篡改，外泄的探知能力和防范能力。审计和安全扫描能力。

确定SLI后，再为每个SLI指定一个目标值或范围值，就是SLO。在明确SLO时有两种情景：

a)从零开始，依据业务目标的期望值来确定SLO，按指定的SLO进行架构设计。

b)对现有业务制定SLO。需要按业务梳理系统架构，划分最小服务单元，掌握每个单元的各个指标情况，进行汇总。再依据公司的业务目标明确SLO。

为保证制定有效可执行的SLO，我会带着以下几点思路去落实：

l任何一个SLO都要考虑落地情况。因为没有那个SLO是运维能独立完成的。

l可以参考现有系统情况制定SLO。使SLO的效果略高于当前情况，留有一定的努力空间。

lSLO不是一成不变的，可以按计划提高SLO效果，而不是开始就制定一个实现不了的SLO。

l要考虑一些限制，比如DDoS，CC等多SLO的影响。

lSLO的拆分。细化到基本服务单元。

l业务的增长情况及所需资源。

和各部门一起确定各项指标的SLO后，就要考虑如何保障SLO的达标了。在落实SLO到工作中时，要考虑以下几点工作：

l监控系统：这个是SLI的数据来源。实时掌握各个SLO的余量，当余量不足时应避免对业务的操作。预警，在影响SLO之前提前处理。

l自动化能力：SLO保障的根本。

l流程制度：避免被打脸。比如一些临时的推广行为，会导致流量增加，如果没有准备，有可能会影响SLO。

l风险共享：对于有风险的工作，要确保参与人和决策人都了解风险。

l根据当前部门人员状况，分配各服务单元到人或组。并根据情况提出人员需求。