晚上在健身房跑完步回来，洗了个热水澡，闲着没事，翻了下《SRE：Google运维解密》这本书，由于有看完第二天基本全忘的本事，还是记录下读书笔记。今天只读了前面序言部分，简单mark下。
Q：什么是SRE？
A：SRE是指Site Reliability Engineer，即站点可靠性工程师。
Q：SRE的主要工作是什么？为什么需要SRE？
A：结合上条，SRE主要为了保证服务的可靠性。不同于软件工程师的专注于设计和构建系统，SRE专注于整个软件生命周期管理。随着一个软件的不断演进，规模逐渐扩大，对于保证可靠性的技术也要求越来越高（不光是google,国内的阿里、腾讯等互联网也是，都需要经历“由小变大”的阶段）所以需要将这部分技术能力抽离出来，一是能让职责划分更加清晰，各自能专注其领域。二是，剥离出来的SRE能更加通用化、全局化的“俯视”整个庞大的软件架构。
Q：SRE与传统运维工程师有什么区别？
A：简单理解的话，SRE做了大部分传统运维工程师的活儿，但也做了很多不属于传统运维工程师的活儿。
SRE应该是属于DevOps工作流中的传动轴，贯穿着整个DevOps工作流。软件从设计之初，就需要SRE的参与，以一种“检察官”的身份审视软件架构，优化可靠性、并发量等。在开发过程中，SRE同样会参与其中，此时的SRE更像是手术室中的“主刀助理”，为开发人员递上合适的工具，比如提供服务的负载均衡、消息队列、数据备份等中间件。
前言和序言的内容差不多就这么多，我看书不太走心，所以在读书过程中经常问自己问题，读书笔记也是以这种Q&A的方式展示。回答（理解）有误欢迎指正。
看完这书前面这一段，仔细一下，其实大部分的开发人员“血液”里多多少少是有一些SRE基因的。只是或许当前的系统较小，不需要更高的可靠性要求，又或者这些对服务性能优化、中间件的搭建工作由项目组其他人员承担了，但多多少少是听过、做过一点的。这应该也是开发人员更加需要读这本书的原因了，希望读完这本书的时候，我也能对可靠性有一个系统的认识。
