D. Google SRE 管理 - 培训SRE
培训课程
正确的方式
设计一个具体的，有延续性的学习体验，以便学员跟进
鼓励反向工程，利用统计学来思考问题，以及多思考问题本质
鼓励学员分析失败的案例，分享好的事后总结来阅读
创造一些受控的，但是逼真的场景让学员利用真实的监控环境和工具来修复
在团队内以角色扮演的形式演习理论上可能发生的问题，让大家在这个过程中交流彼此的解决问题的方式
给学员创造条件让他们参与见习on-call，和实际轮值的on-call工程师交流经验
让学员和SRE老手一起共同修订培训计划中的某个部分
帮学员一起找到一个具有一定复杂度的项目，帮助它们在整个技术栈内建立自己的地位
错误的方式
通过给学员安排一些烦琐的工作（处理警报/工单）来培训
要求按照现有的操作过程，检查列表，或者手册来执行命令进行训练
将故障掩盖起来，以便躲避指责
在学员加入on-call之后，第一次遇到问题时才会去尝试修复
在团队中将只是隔离起来，创造出一些只在某个领域内的专家
在学员还没有对服务有全面认识的情况下，就要求它们成为主on-call
认为on-call培训素材是静态的，非专家不可更改
将新项目全部分配给SRE老手，新手SRE只能做一些零工
培训计划
集中精力学习
第一阶段
阅读事后总结
反向工程/随机应变
第二阶段
灾难演习角色扮演
破坏并修复真的东西
第三阶段
修改文档
见习on - call
加入on-call --- 项目工作与责任感
持续学习
具体执行
培训初期：重体系，而非混乱
系统性，累计型的学习方式
案例一：负责一个实时，直接面向用户的服务系统培训顺序
1. 请求是如何进入系统中网络和数据中心的一些基本概念，前端的负载均衡系统，代理等
2. 前端服务应用程序前端，日志记录，用户体验SLO等
3. 中层服务缓存，后端负载均衡系统
4. 基础设施后端，基础设施，计算资源管理等
5. 整体调试的一些技巧，问题升级的流程，紧急情况的演练
目标性强的项目，而非琐事
目标明确：希望SRE在项目中获得什么样的能力
案例
通过增加监控点，了解监控逻辑
选择一个没有自动化的痛点，从而减轻团队负担，帮组融入团队
通过在技术栈中增加一个小，用户可见的功能点，跟随修改一起发布到线上，了解整个发布流程
培养反向工程能力和随机应变能力
反向工程：弄明白系统如何工作了解原理，调试工具
统计学和比较性思维：在压力下坚持科学方法论
随机应变能力：当意料之外的事情发生时怎么办
将知识串联起来：反向工程某个生产环境服务
好的SRE工程师的特点
对事故的渴望：事后总结的阅读和书写
故障处理分角色演习
破坏真的东西，并且修复它们
维护文档是学徒任务的一部分
对学员来说
了解运维系统的边界
了解系统重要的组件，以及背后的原因
对导师和管理者来说
了解学员学习进度可以通过检查列表来反映比如说学到了哪一节
对其他团队成员来说
文档成为一种社会契约，只有掌握了这个文档的员工才能加入on-call
尽早，尽快见习on-call
on-call之后：通过培训的仪式感