一、什么是站点可靠性工程师 ?
1、确保站点在线 – 无论发生什么
1.1 站点：google.com
1.2 站点不可用？无论什么原因，都是我们的问题。
2、 SRE是工程师，关注焦点是可靠性，运维具体业务服务；
二、SRE的团队是怎么构成的？
1、50%以上是合格的Google软件工程师；
2、40%以上是85分以上的Google软件工程师，同时具有其他技术能力；
三、SRE的基本原则是什么？
1、SRE团队必须将50%精力花在开发上；
2、为了保障运维有时间跟进紧急事件，每8 – 12小时oncall时最多处理2个事件；
3、针对事件进行总结，对事不对人；
4、不追求100%可靠，建立合理的错误预算，最大化迭代速度；
5、监控系统：输出告警、工单和日志
6、将MTTR（平均恢复时间）作为评价团队系统恢复正常的指标，尽量自动恢复，写好《运维手册》
7、在变更管理方面，自动化渐进式发布、自动化检测定位问题、自动化回退；
8、合理的规划系统容量，并周期性进行压力测试
9、资源部署和配置必须快速完成
10、高效的利用各种资源，与研发团队一起监控和优化整个系统的性能；
四、SRE的组织结构是怎么样的？
1、产品SRE，嵌入在产品开发团队
如：Search、Photos
2、技术设施SRE，嵌入在开发团队
如： Bigtable、Spanner、Borg
3、共享平台SRE，跟开发团队一样，专注SRE工具开发。
如：监控、事件管理工具、发布平台
所有这三种SRE团队都在相同的组织！
五、Google 生产环境，SRE视角
（一）硬件
1、物理服务器 （Machine） - 具体的硬件或VM虚拟机
2、软件服务器 （Server） - 对外提供服务的软件系统
3、网络 Jupiter [ˈdʒupɪtɚ] 虚拟交换机 / CLOS / SDN技术 / 骨干网 B4
（二）将硬件组织起来的系统软件
1、管理物理服务器 - Borg
2、存储系统
3、网络系统
（三）网络
1、路由
SDN / OpenFlow / 简单网络硬件 + 智能软路由
2、带宽
带宽控制器 / 可用带宽最大化
3、负载均衡 / GLSB
域名解析 / 用户服务 / 远程过程调用（RPC）
（四）其他系统软件 - 分布式锁服务
1、Chubby [ˈtʃʌbi]
2、使用Paxos 协议
3、可用于Master选举
4、可用于BNS 解析
（五）其他系统软件 – 监控与告警系统
1、对严重的问题触发告警；
2、对比行为：一个新版本是否让服务变得更快了？
3、检查各个时点的资源消耗情况，这是容量规划的基础
（六）软件基础设施
1、多线程
2、内置HTTP采集点
3、RPC – Stubby
4、ProtoBuffer
