C. Google SRE 实践 - 产品发布

C. Google SRE 实践 - 产品发布

组织结构：发布协调工程师

• 工作内容
  • 审核新产品和内容服务，确保它们和Google的可靠性标准以及最佳实践一致，同时提供一些具体的建议来提升可靠性
  • 在发布过城中为多个团队之间的联系人
  • 跟进发布所需任务的进度，负责发布过程中所有技术相关的问题
  • 作为整个发布过程中的一个守门员，决定某项发布是不是“安全的”
  • 针对Google的最佳实践和各项服务的集成来培训开发者，充分利用内部的文档和培训资源来加速开发
• 优势
  • 广泛的经验
  • 跨职能的视角
  • 客观性

发布流程

• 好的发布流程的特征
  • 轻量级：占用很少的开发时间
  • 鲁棒性：能够最大限度地避免简单的错误
  • 完整性：完整地，一直地在各个环节内跟踪重要的细节问题
  • 可扩展性：可以应用在很多简单的发布上，也可以用在复杂的发布过程中
  • 适应性：可以使用于大多数常见的发布，以及可以适应全新的发布类型
• 措施
  • 简化：确保基本信息正确。不需要为所有的可能性做准备
  • 高度定制化：有经验的工程师会针对每次发布定制流程
  • 保证通用路径快速完成：识别出几类发布流程具有的共同模式，针对这类发布提供一个快速简化通道。

具体工作

• 发布检查列表，这个列表需要不断更新，有些问题可能不在，有些是新增的
  • 核心标准
    • 每一个问题的重要性必须非常高，理想情况下，都必须有之前发布的经验教训来证明
    • 每个指令必须非常具体，可行，开发者可以在合理的时间内完成。
  • 起草一个检查列表
    • 架构与依赖
      • 示范问题
        • 从用户到前端再到后端，请求流的顺序是什么样的？
        • 是否存在不同延迟要求的请求类型？
      • 待办事项
        • 将非用户请求与用户请求进行隔离
        • 确认预计的请求数量。单个页面请求可能会造成后端多个请求
    • 集成
      • 示范问题
        • 给服务建立一个新的DNS
        • 为服务配置负载均衡器
        • 为服务配置监控系统
    • 容量规划
      • 示范问题
        • 本次发布是否与新闻发布会，广告，博客文章或者其他类型的推广活动有关
        • 发布过程中和之后预计的流量和增速是多少？
        • 是否已经获取到该服务需要的全部计算资源？
    • 故障模式
      • 示范问题
        • 系统设计中是否包括单点故障源？
        • 该服务是如何处理依赖系统的不可用性的？
      • 待办事项
        • 为请求设置截止时间，防止由于请求持续时间过长导致资源耗尽？
        • 加入负载丢弃功能，在过载情况中可以尽早开始丢弃新请求？
    • 客户端行为
      • 示范问题
        • 该服务是否实现了自动保存/自动完成（输入框）/心跳功能？
      • 待办事项
        • 确保客户端在请求失败之后按指数型增加重试延时。
        • 保证在自动请求中实现随机延时抖动
    • 流程与自动化
      • 示范问题
        • 维持服务运行是否需要某些手动执行的流程？
      • 待办事项
        • 将所有需要手动执行的流程文档化
        • 将迁移到另外一个数据中心的流程文档化
        • 将构建和发布新版本的流程自动化
    • 开发流程
      • 待办事项
        • 将所有的代码和配置文件都存放到版本控制系统中
        • 为每个发布版本创建一个新的发布分支
    • 外部依赖
      • 示范问题
        • 这次发布依赖哪些第三方代码，数据/服务/或者事件？
        • 是否有任何合作伙伴依赖于你的服务？发布时是否需要通知他们？
        • 当我们或者第三方提供商无法在指定截止日期前完成工作时，会发生什么？
    • 发布计划
      • 待办事项
        • 为该服务发布制定一个发布计划，将其中每一项任务对应到具体的人
        • 针对发布计划中的每一步分析危险性，并制定对应的备用方案
• 推动融合和简化
  • 比如说使用基础设施作为服务的基础构建单元：不是所有的工程师都熟悉现有的基础设施
• 发布未知的产品，需要跟领域专家合作

可靠发布所需要的方法论

• 灰度和阶段性发布
• 功能开关框架
  • 要求
    • 可以同时发布多个改动，每个改动仅针对一部分服务器，用户，实体，或者数据中心起作用
    • 灰度式发布到一定数量的用户，一般在1% ～ 10%之间
    • 将流量根据用户，对话，对象和位置等信息发送到不同的服务器上
    • 设计中可以自动应对新代码出现的问题，不会影响到用户
    • 在严重Bug发生，或者其他副作用场景下可以迅速单独屏蔽某个改变
    • 度量每个改变对用户体验的提升
  • 功能
    • 主要面向用户界面的修改
      • 无状态的HTTP重新器，只对某些Cookies起作用
      • 将新代码和一个标识符关联
    • 可以支持任意服务器端和逻辑修改的
• 应对客户端的滥用行为
  • 场景
    • 故意的或者不是故意的自动请求的同步性会造成惊群效应
    • 设定夜里2点下载更新等等
  • 措施
    • 引起延迟抖动（加入随机性）
    • 通过配置文件控制新功能的使用（一旦出现问题，就通过配置文件关闭该新功能，客户端定时跟服务器端同步配置文件）
• 过载行为和压力测试