第一篇 - SRE闲谈

经常会有人说运维是苦力活，很多的运维在大家眼中成了一个不值钱的角色，但是随着sre的兴起，K8S的流行，以及devops的茁壮成长，系统运维/运维开发/云运维/大数据运维/中间件运维/应用运维等详细的岗位划分也逐渐出现，而SRE工程师也成为了一个火热的名词。

经常会有人问什么是SRE？SRE的名词最开始出现于google，全称为Site Reliability Engineering，翻译过来就是：站点可靠性工程师。

而SRE最明确的职责就是确保站点的稳定，这需要他对站点所涉及的系统、组件非常熟悉（大型网站的系统和组件依赖以及网站的发展史会在后面的文章给大家介绍），同时需要开发、维护很多工具和系统支撑其完成这项工作，比如devops系统，监控系统，日志系统，资源管理系统等。总的来说，SRE是一个综合素质很高的全能手，需要懂服务器、操作系统、网络、中间件……具备基础编程能力、架构能力、问题分析能力、抗压能力以及性能调优能力……

从这些面描述我们发现，SRE是覆盖了devops的？没错，在我看来SRE的工作本身就是Develop+Operate的结合，是DevOps的践行者，他们与传统的运维工程师不同的是是使用更加自动化和高效手段来实现，这种高效来源于自动化工具、监控工具的支撑。

结合我们国内公司的现状来分析，SRE的主要工作职责看是通过工程能力解决在日常运维中的稳定性、效率甚至是成本和用户体验等一系列问题，这里面最直观的就是开发能力&架构能力，没错，就是全才！

那么SRE的效果如何评价？SRE本身的存在就是为了解决产品迭代变更、用户量的倍增等引起的风险，在这方面google提出了SLI-->SLO-->SLA的机制。

SLI——服务质量指标，如：延时、吞吐量、错误率、可用性等

SLO——服务质量目标，服务的某个SLI的目标值，或者目标范围。比如：SLI<=目标值

SLA——服务质量协议（Agreement），服务（SRE）和用户（开发、产品）之间的一个明确的、或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。或者可以转化为先行的KPI，比如系统可用性99.99%等

而最后能够实现考核我们成果的唯一标准就是SLA！这是一个漫长而痛苦的过程，这是一个从99%到99.99%，最后到99.9999%需要经历漫长沉淀的过程，那么为了SLA我们需要做些什么？后面的文章带你慢慢了解。

详细内容建议大家阅读《Google SRE》