C. Google SRE 实践 - 产品发布
组织结构：发布协调工程师
工作内容
审核新产品和内容服务，确保它们和Google的可靠性标准以及最佳实践一致，同时提供一些具体的建议来提升可靠性
在发布过城中为多个团队之间的联系人
跟进发布所需任务的进度，负责发布过程中所有技术相关的问题
作为整个发布过程中的一个守门员，决定某项发布是不是“安全的”
针对Google的最佳实践和各项服务的集成来培训开发者，充分利用内部的文档和培训资源来加速开发
优势
广泛的经验
跨职能的视角
客观性
发布流程
好的发布流程的特征
轻量级：占用很少的开发时间
鲁棒性：能够最大限度地避免简单的错误
完整性：完整地，一直地在各个环节内跟踪重要的细节问题
可扩展性：可以应用在很多简单的发布上，也可以用在复杂的发布过程中
适应性：可以使用于大多数常见的发布，以及可以适应全新的发布类型
措施
简化：确保基本信息正确。不需要为所有的可能性做准备
高度定制化：有经验的工程师会针对每次发布定制流程
保证通用路径快速完成：识别出几类发布流程具有的共同模式，针对这类发布提供一个快速简化通道。
具体工作
发布检查列表，这个列表需要不断更新，有些问题可能不在，有些是新增的
核心标准
每一个问题的重要性必须非常高，理想情况下，都必须有之前发布的经验教训来证明
每个指令必须非常具体，可行，开发者可以在合理的时间内完成。
起草一个检查列表
架构与依赖
示范问题
从用户到前端再到后端，请求流的顺序是什么样的？
是否存在不同延迟要求的请求类型？
待办事项
将非用户请求与用户请求进行隔离
确认预计的请求数量。单个页面请求可能会造成后端多个请求
集成
示范问题
给服务建立一个新的DNS
为服务配置负载均衡器
为服务配置监控系统
容量规划
示范问题
本次发布是否与新闻发布会，广告，博客文章或者其他类型的推广活动有关
发布过程中和之后预计的流量和增速是多少？
是否已经获取到该服务需要的全部计算资源？
故障模式
示范问题
系统设计中是否包括单点故障源？
该服务是如何处理依赖系统的不可用性的？
待办事项
为请求设置截止时间，防止由于请求持续时间过长导致资源耗尽？
加入负载丢弃功能，在过载情况中可以尽早开始丢弃新请求？
客户端行为
示范问题
该服务是否实现了自动保存/自动完成（输入框）/心跳功能？
待办事项
确保客户端在请求失败之后按指数型增加重试延时。
保证在自动请求中实现随机延时抖动
流程与自动化
示范问题
维持服务运行是否需要某些手动执行的流程？
待办事项
将所有需要手动执行的流程文档化
将迁移到另外一个数据中心的流程文档化
将构建和发布新版本的流程自动化
开发流程
待办事项
将所有的代码和配置文件都存放到版本控制系统中
为每个发布版本创建一个新的发布分支
外部依赖
示范问题
这次发布依赖哪些第三方代码，数据/服务/或者事件？
是否有任何合作伙伴依赖于你的服务？发布时是否需要通知他们？
当我们或者第三方提供商无法在指定截止日期前完成工作时，会发生什么？
发布计划
待办事项
为该服务发布制定一个发布计划，将其中每一项任务对应到具体的人
针对发布计划中的每一步分析危险性，并制定对应的备用方案
推动融合和简化
比如说使用基础设施作为服务的基础构建单元：不是所有的工程师都熟悉现有的基础设施
发布未知的产品，需要跟领域专家合作
可靠发布所需要的方法论
灰度和阶段性发布
功能开关框架
要求
可以同时发布多个改动，每个改动仅针对一部分服务器，用户，实体，或者数据中心起作用
灰度式发布到一定数量的用户，一般在1% ～ 10%之间
将流量根据用户，对话，对象和位置等信息发送到不同的服务器上
设计中可以自动应对新代码出现的问题，不会影响到用户
在严重Bug发生，或者其他副作用场景下可以迅速单独屏蔽某个改变
度量每个改变对用户体验的提升
功能
主要面向用户界面的修改
无状态的HTTP重新器，只对某些Cookies起作用
将新代码和一个标识符关联
可以支持任意服务器端和逻辑修改的
应对客户端的滥用行为
场景
故意的或者不是故意的自动请求的同步性会造成惊群效应
设定夜里2点下载更新等等
措施
引起延迟抖动（加入随机性）
通过配置文件控制新功能的使用（一旦出现问题，就通过配置文件关闭该新功能，客户端定时跟服务器端同步配置文件）
过载行为和压力测试