健康检查
运维工程师重要的工作职责之一是度量系统，这个说法我深以为然。
如果无法定义一个系统重要行为的正确性，就无法优化和运维这个系统。为了更好的运维一个系统，运维工程师应当做以下工作：
1.定义。运维工程师需要去制作并维护质量模型。一个系统的质量模型可以定义为一个N维向量[x1,x2,x3,...,xN]，其中x为一个个的SLI（服务质量指标），可以是系统重要RPC接口的成功率，某个耗时等。质量模型可以看做是对一个系统服务质量的抽象，有了它，我们可以做进一步的工作：测量。
2.测量。运维工程师通过监控数据或其它方法获取系统原始数据，然后通过统计方法对原始数据进行加工，从而测量出质量模型中的各个指标的值。例如，我们的质量指标中有一项为页面响应耗时，原始数据是分钟级的耗时数据，我们如何准确得出今天该指标的质量情况？我曾经和同事讨论过这个问题，最直接的提议是算数平均；这种方法优点是简单，缺点显而易见，就是对服务质量的恶化不够敏感，如果系统质量出现问题，这种方法通常无法提前发现，正常的响应耗时会将异常的耗时掩盖掉。有些同事提出模仿奥运的打分机制，去掉几个最高值，去掉几个最低值，然后再平均，这个方法的缺点和直接平均是一样的，若研究对象的分布相对集中，而我们恰好要获取该对象一天当中最典型的响应时间时，这种统计方式是可取的，但是在度量系统质量的时候，我们需要提前发现异常，也就是说需要对异常的部分适当的给以高光，运维应该更加关注长尾指标。最终确定的测量方法是用每个小时中耗时最长的几个样本的平均值来代表该小时的响应时间，一天的响应时间则取当天响应时间最长的一个小时来代表。还是以响应时间为例，这个算法算出的值会比典型耗时大一些。但是作为服务质量指标，它可以提前发现系统中的隐患
3.诊断。有了测量结果这个基础，我们使健康检查成为可能，当然在这之前，我们还需要定义出一个健康的系统是什么样的，也就是健康的模型，也就是SLO(服务质量目标)。这个值的定义需要开发，产品，运维等几个团队共同制定，太松不能提前发现问题，太紧会增加成本。当这个值确定下来后就可以拿来诊断系统的健康状态了
4.迭代。一个成熟的模型需要根据实际情况进行迭代，优秀的东西都不是一蹴而就的