sre培训课程
以下均为选自《sre google运维解密》一书。
培训步骤
- 设计一个具体的，有延续性的学习体验，以便学员跟进。
- 鼓励反向工程，利用统计学来思考问题，以及多思考问题的本质。
- 鼓励学员分析失败的案例，分享好的事后总结来阅读。
- 创造一些受控的，但是逼真的场景让学员利用真是的监控环境和工具来修复。
- 在团队内以角色扮演的形式演习理论上可能发生的问题，让大家在这个过程中交流彼此的解决问题的方式。
- 给学员创造条件让他们参与间隙on-call，和实际轮值的on-call工程师交流经验。
- 让学员与sre老手一起共同修订培训计划中的某个部分。
- 帮学员一起找到一个具有一定复杂度的项目，帮助他们在整个技术栈内建立自己的地位。
培训初期：重体系，而非混乱
从我个人的角度来看，一个新入职的sre，不可能直接就扔到线上去做事。而对于新人来说，那样就完全是盲人摸象一样。
我们首先要告知的是：
- 我们做的是什么工作？
- 应用部署图
- 应用架构图
- 研发框架是什么？
- 业务流程是怎么样的？
- 系统的用户群是什么？
- 系统的高峰和低谷。
- 我们工作中使用的工具都有哪些？
- 使用的中间件
- 使用的编程语言
- 编程语言使用的框架
- 如何使用这些工具？
- 如何操作的文档。
- 如何阅读这些文档。
- 我们现有的问题是哪些？
- 系统的瓶颈点是什么？
- 系统的稳定性的问题在哪里？
- 快速扩容和缩容会碰到的问题。
- 实际中有哪些坑点。
- 某某组件的问题。
- 操作某某东西需要更细某部分的缓存。
我们最终要把这些形成对应的新人文档，这些文档需要后面的新人逐步去更新完善。
目标性强的项目工作，而非琐事
sre是天生的问题解决者，所以我们需要给予他们问题去解决。
- 比如我们上面说的快速扩容和缩容中碰到的问题如何进行自动化解决。
- 我们现有监控中有哪些盲点，并如何去解决。
以上问题都需要sre很好的了解整个系统，整个监控系统，并将这些异常的问题和原先的知识进行结合。而一旦做出成就来，那新sre立刻就会受到团队的欢迎。
培养反向工程能力和随机应变的能力
这个其实是我个人最看重的部分，也是一个工程师自学水平的完美体现。
在sre这种复杂度和规模下，工程师仅仅做到关注运维、传统的系统管理员模式是不够的，不光要有大规模海量工程化思维，sre同时也应该具有如下特点：
- 在日常工作中，他们会遇到从未见过的系统，必须要有很强的反向工程能力。（其实就是从系统的入口开始，逐步摸索出整个系统的数据流和架构。）
- 在海量规模下，很多异常情况都很难检测，他们必须具有统计学知识，用统计学而不是流程化的方式去发现问题。（这种需要很强的知识储备和发散性思维和推理能力）
- 当标准的流程不工作时，他们必须能够随机应变、解决问题。
反向工程：弄明白系统如何工作
统计学和比较性思维：在压力下坚持科学方法论
当有一堆高层站你后面查看故障情况的时候，如何保持清醒的头脑，排除不可能的原因，用经验来构造自己的假设。反之，运维团队必须保证这些因子是可控的，同时保证的系统的统一性很重要。不然到时候变量太多会导致判断和处理时间变长。
随机应变的能力：当意料之外的事情发生时怎么办
当你对着手册做着做着发现返回结果不是手册上说的，出错了，这个时候你又联系不到其他人，这个时候应该如何进行处理呢？
将知识串联起来：反向工程某个生产环境服务
与其让其他人传授知识给你，不如自己动手–利用反向工程手段自己了解服务，让其他人纠正他的错误和补充遗漏的部分，这样的效果会更好。
有抱负的on-call工程师的5个特点
对事故的渴望：事后总结的阅读和书写
这个是每个资深工程师成长的路径。
故障处理分角色演习
指定某个成员来现场处理某个故障场景，该成员需要向主持人提出问题，或者告知目前要采取的行动，主持会告知问题，以及该行动的结果，sre成员需要在各种监控图表中，找出用户请求延迟高的问题。
破坏真的东西，并且修复它们
维护文档是学徒任务的一部分
尽早尽快见习on-call
毕竟演习和培训材料不能代表真正出的问题。