A. Google SRE概述
概述
开发与运维的关注点
开发：如何能够更快速地构建和发布新功能
运维：如何提高可用性，降低故障率
Google SRE团队组成
前提
所有的SRE团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的运维问题。
团队组成
第一类：团队中50%～60%是标准的软件工程师，具体来说，就是那些能够正常通过Google软件工程师招聘流程的人
第二类：其他40%～50%则是一些基本满足Google软件工程师标准（具备85%～99%所要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX系统内部实现细节和1~3层网络知识是Google最看重的两类额外的技术能力。
项目团队组成
通用型人才：可以很快地开始工作
领域专家：提供更广阔的知识和经验
Google SRE管理
核心
传统运维50%工作量：工单处理，手工操作等等
研发工作50%工作量：运维系统，运维平台，自动化运维
管理应该根据实际情况不断的演变
技术的发展，有可能促使管理产生变化，管理的变化，也有可能促使技术进一步发展
措施
首先，不断度量每个团队的工作时间分配
其次，如果开发时间低于50%，SRE管理层会要求该团队将一些常见的运维工作交换给产品研发部门操作，或者从产品研发部门抽调人力参与团队轮值值班工作。此外，还可以停止该SRE团队的一切新增运维工作。
Google SRE 方法论
Google SRE职责
可用性改进
延迟优化
性能优化
效率优化
变更管理
监控
紧急事务处理
容量规划与管理
核心方法论
确保长期关注研发工作
运维工作限制在50%以内，保证开发工作
每8～12小时的on-call轮值器件最多只处理两个紧急事件
在保障服务SLO的前提下最大化迭代速度
使用工具：错误预算，通过错误预算，统一研发团队和SRE团队的目标。
核心思想：任何产品都不是（除了心脏起博器和防抱死刹车系统邓），也不应该做到100%可靠。对于很多用户来说，99.9999%和100%是没有实质区别的。
制定合理的保障目标包括
基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意
如果这项服务可靠性不够，用户是否有其他的替代选择
服务的可靠程度是否会影响用户对这项服务的使用模式
监控系统
应急事件处理
运维手册：Google SRE将大部分工作重心放在运维手册的维护上，同时通过故障演习等项目不断培训团队成员
变更管理
问题：70%的生产事故是由某种部署的变更而触发的。
措施：自动化
采用渐进式发布机制
迅速而准确地检测到问题的发生
当出现问题时，安全迅速地回退改动
需求预测和容量规划
核心：保障一个业务有足够的容量和冗余度去服务预测中的未来需求
步骤
必须有一个准确的自然增长预期需求预测模型，需求预测的时间应该超过资源获取的时间。
规划中必须有明确的非自然增长的需求来源的统计
必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来
资源部署
效率与性能
Google生产环境：SRE视角
硬件服务器（硬件资源）：google并不会使用专门的硬件服务器运行软件服务器
服务器组织形式
约10台物理服务器组成一个机柜
数台机柜组成一个机柜排
一排或多排机柜组成一个集群
一般来说，一个数据中心包含多个集群
多个相邻的数据中心组成一个园区
网络
交换机：数百台交换机组成虚拟网络交换机（CLOSl连接方式），这个交换机有数万个虚拟端口
网络连接：全球覆盖的骨干网B4，基于SDN网络技术
全球负载均衡器：GSLB
利用地理位置信息进行负载均衡DNS请求
在用户服务层面进行负载均衡
在远程调用层面进行负载均衡
软件服务器（软件资源）
管理物理服务器：Borg，类似Kubernetes
存储：存储介质是磁盘，也可以是SSD
文件服务器
基于文件服务器的分布式文件系统
基于分布式文件系统的数据库
Bigtable
Spanner：提供SQL接口以及满足一致性要求的全球数据库
其他，类似Blobstore
其他软件
分布式锁服务
监控和报警系统
研发环境
提交代码需要代码评审
自动化测试工具，持续集成、持续部署
部署
需要根据大区域部署，尽量避免跨区域访问（如果特定区域有问题或者负载过高，需要导流，就无法避免这个问题）
对于数据库，比如说Bigtable，会在各个区域都存放有副本