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