D. Google SRE 管理 - SRE参与模式

SRE为了保证该服务的可靠性，需要考虑的方面

• 系统的体系结构和跨服务依赖
• 指标的选择，度量和监控
• 紧急事件处理
• 容量规划
• 变更管理
• 性能：可用性，延迟和资源效率

对于未支持的服务，可以提供：

• 文档
• 咨询工作

SRE参与模式演进

• PRR评审目标
  • 验证该服务符合公认的标准的生产部署方式和运维方式，同时该服务负责人已经准备好与SRE一起工作，利用SRE的知识改进服务。
  • 提升服务生产环境中的可靠性，并最小化可预见的故障的数量和严重程度。PRR会关注SRE关注的生产环境的所有方面。
• 简单PRR模型
  • 步骤
    • 参与
      • 目标
        • 为该服务建立一个SLO/SLA
        • 为可能的，为了提高可靠性的破坏性计划变更制定计划
        • 指定交接计划和培训计划
    • 分析
      • 学习该服务的一切知识，开始对其生产方面的缺陷进行分析。
      • 基于该服务特别指定的检查列表，一般是基于领域专业知识，以及相关或类似系统的经验，加上“生产指南”中的最佳实践得出的
        • 对于服务进行的更新是否立刻影响到系统中大比例的部分？是否合理？
        • 服务的依赖是否合理？例如，直接面向用户请求的服务不应该依赖于一个主要用于批处理的系统
        • 该服务在连接关键的远程服务时，是否需要较高的网络服务质量（QoS）?
        • 该服务是否会将错误报告传送到中央日志记录系统进行分析？该服务是否报告所有的会造成降级回复，或者会造成最终用户请求失败的特殊情况？
        • 所有用户可见的请求失败情况都有质量和监控吗？报警策略是否合适？
    • 改进和重构
      • 将每个改进建议按照其对服务可靠度的影响而排序，指定一个优先级顺序。
      • 与研发团队讨论和协商这些建议，达成一个共识
      • SRE和产品研发团队同时参与，并且协助对方进行重构，或者实现额外的功能
    • 培训
      • 有负责该服务的SRE主导：
        • 设计概要
        • 对系统中各种请求的处理流尽心深入探讨
        • 生产环境部署模式的描述
        • 对系统运维各个方面的手动练习
    • “接手”服务
    • 持续改进
  • 适用对象：服务已经发布，已经规模化，SRE的参与是在生命周期的后期才进行的
• 早期参与模型
  • 适用对象
    • 该服务实现了一个显著的新功能，并将成为一个现存的SRE运维的系统的一部分
    • 该服务是一个针对现有系统的大幅度重写或者替代品，服务目标一致
    • 研发团队曾经寻求过SRE的建议，或在发布之后就需要SRE接管
  • 早期参与模型的优势
    • 设计阶段：了解设计的初衷，最小化服务进入生产后出现的设计分歧
    • 构建和实现
    • 发布
    • 发布之后
    • 从服务脱离
• 框架和SRE平台模型
  • 结构化的解决方案：框架
    • 最佳实践代码化 — 将功能良好的代码通用化
    • 可重复使用的解决方案常见并易于共享的技术实现，用于改善可扩展性和可靠性的问题
    • 带有通用控制界面的通用生产操作平台生产设施的统一接口，统一的运维控制机制，以及统一的监控，日志以及服务配置
    • 更简易的自动化和更智能的系统通用的控制接口使自动化和智能化达到一个以前不可能达到的水平