D. Google SRE 管理 - 培训SRE

培训课程

• 正确的方式
  • 设计一个具体的，有延续性的学习体验，以便学员跟进
  • 鼓励反向工程，利用统计学来思考问题，以及多思考问题本质
  • 鼓励学员分析失败的案例，分享好的事后总结来阅读
  • 创造一些受控的，但是逼真的场景让学员利用真实的监控环境和工具来修复
  • 在团队内以角色扮演的形式演习理论上可能发生的问题，让大家在这个过程中交流彼此的解决问题的方式
  • 给学员创造条件让他们参与见习on-call，和实际轮值的on-call工程师交流经验
  • 让学员和SRE老手一起共同修订培训计划中的某个部分
  • 帮学员一起找到一个具有一定复杂度的项目，帮助它们在整个技术栈内建立自己的地位
• 错误的方式
  • 通过给学员安排一些烦琐的工作（处理警报/工单）来培训
  • 要求按照现有的操作过程，检查列表，或者手册来执行命令进行训练
  • 将故障掩盖起来，以便躲避指责
  • 在学员加入on-call之后，第一次遇到问题时才会去尝试修复
  • 在团队中将只是隔离起来，创造出一些只在某个领域内的专家
  • 在学员还没有对服务有全面认识的情况下，就要求它们成为主on-call
  • 认为on-call培训素材是静态的，非专家不可更改
  • 将新项目全部分配给SRE老手，新手SRE只能做一些零工

培训计划

• 集中精力学习
  • 第一阶段
    • 阅读事后总结
    • 反向工程/随机应变
  • 第二阶段
    • 灾难演习角色扮演
    • 破坏并修复真的东西
  • 第三阶段
    • 修改文档
    • 见习on - call
• 加入on-call — 项目工作与责任感
• 持续学习

具体执行

• 培训初期：重体系，而非混乱
  • 系统性，累计型的学习方式
    • 案例一：负责一个实时，直接面向用户的服务系统培训顺序
      • 请求是如何进入系统中网络和数据中心的一些基本概念，前端的负载均衡系统，代理等
      • 前端服务应用程序前端，日志记录，用户体验SLO等
      • 中层服务缓存，后端负载均衡系统
      • 基础设施后端，基础设施，计算资源管理等
      • 整体调试的一些技巧，问题升级的流程，紧急情况的演练
• 目标性强的项目，而非琐事
  • 目标明确：希望SRE在项目中获得什么样的能力
  • 案例
    • 通过增加监控点，了解监控逻辑
    • 选择一个没有自动化的痛点，从而减轻团队负担，帮组融入团队
    • 通过在技术栈中增加一个小，用户可见的功能点，跟随修改一起发布到线上，了解整个发布流程
• 培养反向工程能力和随机应变能力
  • 反向工程：弄明白系统如何工作了解原理，调试工具
  • 统计学和比较性思维：在压力下坚持科学方法论
  • 随机应变能力：当意料之外的事情发生时怎么办
  • 将知识串联起来：反向工程某个生产环境服务

好的SRE工程师的特点

• 对事故的渴望：事后总结的阅读和书写
• 故障处理分角色演习
• 破坏真的东西，并且修复它们
• 维护文档是学徒任务的一部分
  • 对学员来说
    • 了解运维系统的边界
    • 了解系统重要的组件，以及背后的原因
  • 对导师和管理者来说
    • 了解学员学习进度可以通过检查列表来反映比如说学到了哪一节
  • 对其他团队成员来说
    • 文档成为一种社会契约，只有掌握了这个文档的员工才能加入on-call
• 尽早，尽快见习on-call

on-call之后：通过培训的仪式感