职业定义
SRE是站点可靠性工程师，与运维不同之处是，运维更多是在别人开发好的系统上当流水线工人，而SRE需要自己开发系统，所以SRE需要有更加强的脚本开发技能，同时也要具备强有力的沟通能力、领导能力和丰富的排错经验。开发技能表现在需要开发一些工具帮助我们监控、事故追踪和压测。而沟通能力是因为我们需要经常与开发人员和产品经理交流，无论是优化环节还是故障排查环节。领导能力是建立在排错经验基础上的，当出现了线上故障，我们要第一时间的迅速定位故障点，同时领导整个团队高效解决故障。
注意！SRE并不负责部署，但是要负责发布！这里发布的概念要比部署大多了，虽然不负责机械化的部署操作，但是SRE更着眼于整个流程，而且更要有流程化思维。
SRE，我个人认为它是与用户站在同一个角度思考问题的，开发人员关注的是功能是否会实现，实现了那就OK了。而SRE关注的是用户用的爽不爽，若用户使用的时候出现了错误，那么SRE就要出场解决问题。
SRE也要注意推动问题解决，SRE不是server reboot engineering…重启大法虽然好，但是治标不治本。
平台稳定与SLO
谷歌对系统稳定性有一个比较人性的看法：天底下没有100%不出故障的系统，出故障是正常情况，而如果判断一个系统的健康程度，主要看它是否满足预期的SLO。
SLO是一个重要概念,它中文意思是服务质量目标.服务的故障由于种种原因是无法避免的，每个服务的级别不同，不可能所有服务都是99.999999%，要针对业务的不通特性制定不同的SLO。如果是稳定性要求很高,即与客户有高强度的赔偿协议的服务,那么SLO的级别必须很高，那么付出的代价就是发布变动频率不高或者每一次发布都要严谨评审；而如果是相对冷门涟源的服务，那么SLO可以适度放低。
SLO的制定通常是产品经理、开发团队、SRE一起协商完成，大家根据业务的规模，产品特性，产品处于的阶段制定。当出现了“稳定”与“创新”的矛盾的时候，那么就要产品经理、开发团队、SRE再一次坐到一起修正SLO。
而年度总结的时候，是否满足SLO也是判断SRE的工作业绩的一个考核标准。
值班问题
SRE有on-call制度的，即值班制度。这里的值班并不是广义的值班，而是在某个周期，某个成员会成为故障的第一接口人。这段时间里，这位同学保证内网VPN和工作电脑时刻在身边。值班范围可以先从一个小系统开始，然后随着对业务的熟悉而逐渐扩大。
值班同学切记不要搞“个人英雄主义”，该汇报汇报，该求助求助，同时其他同学也不可以“事不关己”的态度，同是一个团队的战友，“解决问题”是大家的共同责任。但是辩证法的看，如果平台太稳定，会导致on-call人员产生惰性，所以有些时候需要“人为制造麻烦”—-不断的演习；
但是总而言之，值班是一个很苦逼的工作，如何让值班变得轻松且成功，也是一个制度改进的问题。
故障排查
不要一天到晚盯着“大屏”，而是编写合适的监控与报警规则，让我们能快速找到故障根源；
出故障第一时间先快速恢复（回滚、部分服务降级限流或者是其他方法），可以将流量转移到其他节点去，保留一台服务器作为事故现场，用于事后分析（这里可以看出虽然SRE不用实际手动去部署，但是有权利直接回滚）
故障排查不是一门玄学，平时经验积累是很重要的一环，经验的积累有助于在模糊不清的旁人描述中提高判断力，但是也要注意结合实际环境和最后一次改动，怀疑的范围逐渐缩小最后得到“真凶”。
事后总结要遵循“对事不对人”的原则，这样大家就不惧怕写事后总结了，而且会让事后总结质量提高，可以对新入职的同学有帮助；
结合实际的工作目标
首要任务：有效性和覆盖率
具体工作内容（☆越多代表优先级越高）：
1.对现有的系统二次开发或者利用开源软件搭建环境，得到符合自己业务需要的监控系统（分布式，高可用），监控是SRE的眼睛；☆☆
1.1 监控系统要从更高的服务质量和链路通讯层面告警，通过API或者是CURL等技术获取整体细节，但是也要能快速定位到具体的颗粒；
1.2 告警分级系统，兼顾覆盖率的前提下要突出重点；
1.3 准备一个文档，可以给开发或者其他同事讲述如何应对各种告警；
1.4 即可以tcp又可以udp的探测系统；
1.5 事故根源被跟踪恢复，可能还需要一个基线式的事故跟踪系统；
2.需求预测与规划容量，一些大型促销时需要正确计算出扩容的规模；☆☆
3.保障大促期间平台的正常运行，处理紧急运维事件，注意满足“1510法则”；☆☆☆
4.建立一套完整的on-call值班机制；☆
5.当熟悉了系统以及与开发人员交流增多的前提下，参与延迟优化和性能优化等工作；☆
6.学习并参与全链路压测；☆☆
7.参与各种演习，如故障演习，攻防演习等等，将平时演习得分提升上去；☆☆☆
书中金句分享
1.备份就像纳税一样，是一个服务需要持久而付出的代价，来保障其数据的可用性；
2.失败是正常现象，没有100%正常的系统，但是要主动的去寻找失败的可能性；
3.用排除法定位故障不是不可以，但是要快速定位，就要平时有对比环境是否一致性的习惯，这就是推动容器化的主要原因；
4.SRE通过创造流程、实践以及工具，来提高软件的可靠性；
5.一个需要人工阅读邮件和分析报警来决定目前是否需要采取某种行动的系统从本质上是错误的，没有不需要采取行动的警报，如果您遇到一个自己认为不需要执行操作的警报，您需要采用自动化的手段来修复该警报；
6.不应该盲目的追求高可用性，从99.99% –>99.999%付出的成本是巨大的，但是收益仅仅是0.009%而已。
