uptime

运维工程师一定很熟悉 uptime 这个命令，如果用服务器的 uptime 时长来衡量我们运维的效果，你觉得是否合适？很多的应用场景，服务器从来没有发生过宕机，但是服务的响应速度很慢，那这样的运维是不满足用户要求的，那你说这是运维的锅还是开发的锅？

如果运维仅仅盯着 uptime 是远远不够的，因此传统运维需要向 SRE 转型。

SRE是什么

SRE 的全称是 「Site Reliability Engineering」，最早在 2003 年由 Google 的工程师 Benjamin Treynor 提出。与传统的运维工程师相同的是，Benjamin Treynor 的团队也是负责生产系统的运维工作，不同的是，他们更关注服务的可靠性和服务的质量。

从 SRE 的角度来看，我们更应该关注的是我们运维的服务是 可靠 「Reliable」的，也就是要保证我们的 SLA 水平「Service Level Agreement」。比如说系统可用性是 99.99%，响应延迟低于 200 毫秒等等。

四条法则

• 关注延时。关注交易链路上各个环节的请求，确保延时都在满意的范围内。例如实时查询接口最好在500毫秒内返回结果，报表类的复杂业务最好也不要让用户一直看着转圈圈。
• 关注流量。不光关注底层技术上的流量，也要适当关注业务层面的流量，诸如每日总访问量、最高峰访问量等等。
• 关注监控。基础的运维需要能够监控到系统错误，例如HTTP的500错误，或者Java应用中的Error报错。进阶的运维则更需要关注业务错误，如果系统报大量的404，我们同样需要判断是否有异常访问或者存储上是否有问题。
• 关注容量。系统容量考量的是我们对于突发问题的预见性，如果系统高可用架构设计了两个节点，则每个节点的日常流量不应超过总流量的1/2，如果高可用架构设计了三个节点，则每个节点的日常流量不应超过系统容量的60%。

SRE 更加强调从设计之初就考虑未来可能的故障问题，并鼓励用自动化的手段来代替人的操作，其本质是利用软件工程的思维和方法解决复杂的运维问题。

「认真」是最难能可贵的品质。