《SRE生存指南—系统中断响应与正常运营时间最大化》一书其作者为美国人Nat Welch，他在谷歌做过四年SRE。之后，他在各种规模的公司工作过，并一直致力于提高网站的可靠性，以帮助开发人员构建可靠的系统。翻译者是冯文辉，他是知名软件设计公司ThoughtWorks的咨询顾问。
业内评价，此书是SRE工程师、DevOps工程师、运维工程师和系统管理员不可或缺的参考资料；软件架构师、软件工程师、用户体验设计师也能从本书中获取关于SRE的相关知识。
看了这本书之后，我觉得书中有一些不错的文字（段落），我也赶赶时髦，叫他们金句吧。下面我就把这些金句写出来，与各位朋友分享。
1、SRE是一个令人兴奋的领域。为了定义这个领域，我们可以从它的全称“站点可靠性工程Site Reliability Engineering”中学到很多东西。
- Site：一个网站。
- Reliability：被定义为“值得信赖的质量或一贯可靠的质量”。
- Engineering：被定义为“熟练地运用技巧以达到某种目的的行动”。
2、事故是指一些重要的事情发生，它迫使你改变正常的行为。例如，一杯咖啡洒在你身上，你需要去更换衣服；在通勤的路上发生了意外，使你不得不更换路线；你可能会摔断胳膊，不得不在接下来的三个月里打着石膏。所有这些事故都要求你立马做出应对，甚至往往使你的计划发生长期的改变。
3、事故响应通常包括以下几个动作：
- 关注，注意到有些东西不对劲。
- 交流，告诉别人哪些东西不对劲。
- 恢复，纠正不对劲的东西。
4、如果工程师知道他们每天早上三点肯定会被叫醒，那么可能会很快就离职了，或者只是把手机警报停掉，而不做任何响应。
5、测试和发布流程通常在项目早期建立，然后被逐步遗忘。
6、在大型组织中，你也可能会发现自己被限定在一个专门的角色上。你可能感觉测试不是你的责任。但请记住，不仅“灭火”是你的工作，“防火”也是你的工作。
7、另一个经常被忽略的领域是数据恢复测试：
- 有常规的数据备份吗？
- 对数据备份的过程有常规的测试吗？
- 对备份的数据有验证吗？
8、追求完美的发布不再是目标，相反，我们只想要一个好的发布，这样就可以继续迭代和完善产品了。
9、SRE的目标是将50%的时间用于编写代码，30%的时间用于与人打交道，20%的时间用于应对紧急情况。
10、如果我们不需要人类来完成任务，那么就编写代码，这样人类就不需要参与其中了。
11、软件的第一个实现将采用尽可能短的路线，重点在于交付而不是长期的可维护性。之后花时间把一个粗糙的产品打造成更稳定和持久的东西是很重要的工作。
12、SRE存在一种风险，就是SRE工程师有可能成为只负责配置管理或只负责事故响应的人员或团队。腾出时间进行软件开发可以帮助你的团队避免这种命运。软件开发在金字塔中的地位很高，作为一个团队，你不应该忘记它的重要性。
13、用户体验位于Mikey金字塔的顶部，不是因为它不重要（或最重要），而是因为它需要其它层次才能发挥作用。
14、站会形式多种多样，可以是聊天、电子邮件，或现场举行，无论什么形式，能达到效果就行。
15、重新造轮子是指人们只想使用由其组织中的人员编写的软件，并且缺乏对那些不在那里工作的软件开发人员构建的任何东西的信任。这非常危险，因为它可能会导致你编写的软件数量超出组织能够维护的范围。中肯的建议是，你应该构建的软件是你的核心竞争力，你应该让其他人构建你的非核心区域的代码。
备注：下图是作者在本书中引用的Mikey金字塔。
本文为东方瑞通祝文彬老师原创，祝老师为北京航空航天大学硕士，是东方瑞通创始人之一。20多年IT行业从业经验，17年IT服务管理经验，12年高校工作经验。全球ITIL 4开发小组成员，国内首批ITIL 4 初、中级课程认证讲师，曾主持海信集团、链接地产、北京地税、中航技、用友集团等单位的ITSM咨询项目，对IT服务管理和DevOps体系有很深入的理解。
