需要做到哪些才能成为一支优秀的SRE团队
本帖最后由 monicazhang 于 2020-12-18 13:58 编辑新的 SRE 已经招到了，接下来怎么办？已经招聘到了新的 SRE 雇员，接下来我们必须要在工作中培训他们。在工作初期的 教育与技术培训上投入足够的力量，有助于将新加入的 SRE 培养成更好的工程师。合适 的培训计划可以使他们更快地进入工作状态，同时保证他们的工程技能更加平衡与可靠。
成功的 SRE 团队离不开信任——为了维持全球化的服务的正常运转，我们必须信任 on-call 团队了解系统如何运行，可以诊断系统的异常情况，善于利用资源和寻求帮助，以及可以在压力下保持镇静快速解决问题。那么，仅仅考虑“新手需要学习哪些知识才能参与 on-call”是不够的，根据上述需求，我们还需要考虑以下问题：
[*]现有的 on-call 工程师如何能够评估新手是否已经准备好参加 on-call ？
[*]我们如何能够更好地利用新员工带来的激情与好奇心，使老员工也能从中获利 ？
[*]组织哪些活动不仅可以丰富团队知识，还能够获得大家的喜爱 ？
作为一个学员，每个人的学习习惯都不一样。首先我们要认清的是，新招聘到的学员一定是学习习惯各有不同，如果只针对某一种学习习惯制定培训计划肯定是不够的。
因此，没有一种教育方式是最优的，也没有一种教育方式是适用于所有 SRE 团队的。（见下表）列出了Google SRE熟悉并推荐的一些培训方式(以及对应的注意要点)。这些培训课程是Google SRE内部多种培训课程的一个代表，通过它们，团队可以保障自己拥有足够 的知识，以及将这些知识传递下去。
这张图内包含了 SRE 团队可以采用的几个培训新员工的最佳实践，同时保证老员工不会 落伍。从下面描述的很多个工具中，我们可以从中选择最适合团队的几个来使用。
这张图中包含两个轴 :
[*]X 轴代表了工作类型的范围，从抽象的，一直到具体的工作。
[*]Y 轴代表了时间。从上至下，新加入的 SRE 通常对系统和服务知识了解很少，阅读之前故障的事后总结对他们很有帮助。新的 SRE 也可以试图从基本元素出发反向工程整个系统，因为他们本来对系统也没有任何了解。当学员对系统有一定程度的了解，并且已经进行了一些实际操作时，SRE 就可以参与见习 on-call 了， 同时可以修订文档中不完善或者过时的部分。
[*]
阅读上述图表的一些建议 :
[*]正式参加 on-call 是 SRE 新员工的一个重要里程碑，在这之后，学习过程将基本 靠自己主导，是未定义的——所以 SRE 参与 on-call 之后的培训计划都是用虚线 标注的。
[*]“三角形的“项目工作”意味着新项目刚开始都很小，随着时间推移复杂程度逐渐 增大，所需投入也在增加，很有可能在参与 on-call 之后还会继续。
[*]这里的某些活动是抽象性的，还有些是被动性的。其他的一些活动，则是非常具体和非常具有主动性的。还有一些活动则是混合型的。这样的安排是为了满足不同学习方式的人，让他们都能找到合适自己的活动。
[*]为了使培训效果最优，培训课程应该节奏合理:有些可以立即开始，有些则应该 在 SRE 正式参见 on-call 之前开始，而其他的则应该是持续性的，同时要求 SRE 老员工也参与的。在 SRE 正式参加 on-call 之前，应该处于持续不断的学习过程中。
培训初期 :重体系，而非混乱
正如本书其他部分所描述的那样，在 SRE 团队的职责中，主动性任务和被动性任务兼有。
主动性 SRE 工作包括: 软件自动化，架构设计咨询，发布流程协调等。
被动性 SRE 工作包括: 在线调试，故障排除，处理 on-call 情况等。每个 SRE 团队都应该具有的一个重要目标是利用积极主动的办法去减少和限制被动性工作的产生，在培训的过程中也应该体现出这一点。
下面提到的是一个非常常见， 但是比较差的培训经历 :John 刚刚加入了 FooServer SRE 团队。这个团队的老手们每人都负担了很多琐事， 例如回复工单、处理报警，以及进行琐碎的二进制文件发布等工作。John 入职的第一天，所有新的工单就全部指派给了他。同时，主管告诉 John 可以寻求任何一个有经验的 SRE 成员的帮助来了解每个工单的背景知识，以便处理。“当然了，你会有很多东西要学习，这个只能靠你自己了”，主管说道，“最后你一定会学会快速处理这些工单的。某一天你就会突然开窍，发现你已经掌握了我们全部的工具，全部的流程，以及全部的系统知识”，这时候一个老成员补充了一句，“我们这里都是摸着石头过河的。”这种“浴火重生”式的学习方式一般都反映了团队的目前状况 ，关注于运维，被动性的 SRE 团队一般采用这种“被动式”的教育方式来培训新员工。如果幸运的话，新招来的、习惯在未知中探索的工程师最后能够从这种大坑里爬出来。但是更常见的是，很多很有能力的工程师都没法在这个环境中成长。虽然这种培训最终可能能够培养出一些不错的运维工程师，但实际效果肯定也不会太好。这种培训方式同时假设该团队的大部分知识都可以靠“动手实践”来获得，而不是靠逻辑推理得出。如果这个职位只需要处理工单就够了，那么这个职位其实并不是一个 SRE 职位。
SRE 学员肯定会存在以下问题 :
[*]我现在正在做的是什么工作？
[*]我现在的进度如何？
[*]什么时候我能积累到足够的经验参加 on-call ？
新的 SRE 成员通常刚刚从另外一个公司跳槽，或者是刚刚毕业，或者刚从传统的软件工程师或系统管理员职位转换成没那么清晰的 SRE 职位，这已经足够打击他们的自信了。
对很多比较内省型性格的成员来说(尤其是面临上面的问题 2 和 3 时)，培训过程中的混乱或者不确定性会导致他们学习速度变慢，甚至无法适应。
所以，我们应该考虑使用下一节所描述的方法。这些建议、处理工单和报警有同样的效果，但是更加系统化、阶段化也更加适合培训。
系统性、累积型的学习方式
在系统中加入某种顺序性，以便新的 SRE 成员可以建立某种学习路径。任何类型的系统性培训都要比直接处理随机出现的工单和琐事要好，但是我们应该有选择性地将一些理 论性和实践性的学习组合到一起：一些新成员经常会用到的、系统的抽象概念应该优先， 而学员也应该尽早进行真实的实践操作。
了解任何一个技术栈，或者子系统都需要一个起始点。我们应该考虑将培训按照类似作用分组，还是按照常用的执行顺序将系统分组。例如，如果团队负责的是一个实时、直面用户的服务系统，可以按以下课程顺序进行培训。
[*]请求是如何进入系统中的网络和数据中心的一些基本概念，前端的负载均衡系统，代理等。
[*]前端服务，应用程序前端，日志记录，用户体验 SLO 等。
[*]中层服务，缓存，后端负载均衡系统。
[*]基础设施，后端，基础设施，计算资源管理等。
[*]整体 调试的一些技巧，问题升级的流程，紧急情况的演练。
究竟如何实际教授这些课程(可以是非正式的白板讨论，也可以是正式的培训，以及实际操作练习等)是需要团队主管以及负责设计和进行培训的SRE讨论的。
Google 搜索 SRE 团队利用一个“on-call学习检查列表”来组织自己的培训资源。简化版的检查列表可能如下所示 :
注意，上述章节并没有直接将流程、调试步骤以及手册嵌入其中;而是将专家的联系方式罗列出来，指出最有用的文档资源，以及一些服务的基本知识，最后还提供了一些简单的问题以便自检。
该文档同时提供了一些实际的操作性环节，这样学员可以知道他们 完成这个检查列表可以学到哪些知识和技能。
最好能够让所有参与的人都能大概了解某个学员究竟记住了多少知识。这种反馈机制的 建立虽然不一定用正式的考试来进行，但是最好能包括一些问答形式的家庭作业。培训讲师通过检查学员的答案可以了解他们目前的学习进度，以及是否应该进入下一阶段。 关于服务内部工作原理的问题和下面列出的比较类似 :
[*]哪些后端服务器是“关键路径”中涉及的，以及为什么？
[*]该服务的哪些方面可以简化，或者自动化？
[*]你认为该架构的第一个瓶颈在哪里？如果该瓶颈确实出现问题，哪些步骤可以缓解问题？
可以考虑在服务访问权限控制配置中实现一种分层模式。第一层访问权限允许学员只读访问组件的内部信息。接下来则允许修改生产环境状态。
随着检查列表项目的完成，学员将会逐步拥有系统的更高权限。搜索 SRE 团队将这称为“升级”，所有的学员最后都 会被赋予系统最高权限。
目标性强的项目工作，而非琐事
SRE 是天生的问题解决者，所以我们应该给予他们一个难题去解决！在学习过程中，允许新成员向整个服务中加入一点点新东西是很有激励性的。这也是鼓励团队之间构建信任的好方法，因为老员工需要和新员工进行交流，了解新的组件，或者新的流程。
在 Google 内有标准方式：所有的工程师都会被分配一个初始项目，给他们提供足够的基础设施知识，同时让他们可以为服务做一点小的但是有意义的贡献。
让新的 SRE 成员将时间同时分配在学习和项目工作中可以给他们一种参与感和效率感，这比他们专攻两者中的任意一个都好。常见的新手项目类似于：
[*]在服务技术栈中增加一个小的，但是用户可见的功能修改，接下来跟随这个修改一直到发布到生产环境中。了解开发环境的配置和二进制文件的发布流程可以确保他们和开发团队联系密切。
[*]针对现有的服务监控盲点增加新的监控。新手需要了解监控逻辑，同时将这些异 常情况与系统知识相结合。
[*]选择一个还没有被自动化的痛点进行自动化，使得新的 SRE 可以给团队成员减 轻一些日常负担，从而受到团队的欣赏。
培养反向工程能力和即兴思维能力
我们可以提出一系列“如何”培训 SRE 的意见，但是究竟应该培训 SRE “什么”呢？具体的培训材料当然要取决于工作中需要用到的技术，但是这里关注的更重要的问题是 : 我们究竟需要培养什么样的工程师？
在 SRE 这种复杂度和规模下，工程师仅仅做到关注运维、传统的系统管理员模式是不够的。不光要有大规模海量工程化思维，SRE 同时也 应该具有如下特点 :
[*]在日常工作中，他们会遇到从未见过的系统，必须要具有很强的反向工程能力。
[*]海量规模下，很多异常情况都很难检测，他们必须具有统计学知识，用统计学而不是流程化的方式去发现问题。
[*]当标准的流程不工作时，他们必须能够即兴发挥，解决问题。
接下来我们会详细讨论这些特点，这样我们才能知道如何培训 SRE 来获取这些知识和技能。
反向工程 :弄明白系统如何工作
工程师对他们从未见过的系统都很好奇——工作原理是什么。通过对系统工作原理的基 本理解，同时愿意深入研究调试工具、RPC 框架，以及系统的二进制文件来理解其中的 数据流动，SRE 就能够在陌生环境中更高效地处理始料未及的额外难题。
教授 SRE 成员 如何调试和诊断应用程序，同时让他们练习利用这些调试信息进行推断，可以使他们在日后的工作中更习惯用这种方式工作。
统计学和比较性思维 :在压力下坚持科学方法论
我们可以将 SRE 处理大规模系统紧急情况的方式理解为他们在实时展开的决策树中不断 决策的过程。在紧急情况处理的有限时间中，SRE 只能在几百个可能的选择中选择几个动作进行执行，缓解故障。
因为时间通常是有限的，SRE 必须能够有效地在决策树中抉 择。这种能力的获得通常要靠经验积累，而经验只能通过有效和真实的实践获得。这种经验必须同时和一系列精心构造的假设结合，当这些假设被证实，或者证伪时，可以更进一步地减少决策空间。
用另外一种说法，进行系统故障调试的过程很像是一种游戏:“下列哪一个东西与其他不同”？这里的“东西”可能是内核版本、CPU 架构、二进制文件版本、地区性的流量区别，或者其他几百种因素。
从架构层面来讲，该运维团队必须要保证这些因子是可控的，每个因子都应该是进行独立分析和比较过的。然而，我们也应该培训 SRE 新员工从一入职就成为好的数据分析者。
随机应变的能力：当未预料的事情发生时怎么办
假设某 SRE 试着按照手册修复某个问题，但是没有成功。该故障系统的开发团队无法联系，这时候怎么办呢？当然要临场发挥!通过学习多种解决不同问题的工具可以保障工程师有多种手段处理问题。
在故障发生时固守陈规而不去做现场分析，可能会导致无法找到问题根源。在非常复杂的故障排除过程中，SRE 通常需要利用很多未经验证的假设来进行决策。
在 SRE 培训初期加入一些关于决策“陷阱”的描述，以及关于如何能够及 时抽身，从更高的层面换一个角度去思考问题的解决方案，是非常有价值的。
那么，哪些课程和实践可以将新手 SRE 培养成具有这些特性的高效率人才呢？需要针对上述这些特点因地制宜，因材施教，以下是一个覆盖了上述所有要点的课程例子。
将知识串联起来：反向工程某个生产环境服务
“新SRE需要学习Google Map 生产服务的一部分时，与其让其他人传授知识给他，不如自己动手——利用反向工程手段自己了解服务，让其他人纠正他的错误和补充遗漏的部分。”这样做的结果是——这可能比我亲自授课效果还要好，虽然我已经为这个服务 on-call 超过 5 年了!”——Paul Cowan，Google SRE
Google 内部最受欢迎的一门课程是“如何反向工程某个生产环境服务”。这门课程提出的场景初看起来比较简单：整个Google 新闻团队——包括 SRE 、开发工程师、产品管理团队等——都去参加团建了 : 目的地是百慕大三角区。我们已经 30 天没有他们的消 息了。
课程学员作为新组建的 Google 新闻SRE团队成员，需要自行搞清楚整个服务端到端的工作原理，以便能够保障它继续运行。背景介绍过后，学员会经过一系列交互性的、目的性很强的练习，在 Google 基础设施中跟踪他们浏览器发出的某个请求。
在整个过程中的每一段，我们强调学习利用多种方式来发现生产服务之间的连接关系的重要性，这样可以防止某些连接关系被遗漏。
在课程过程中，我们还会让学员跟踪另外一个来源请求，这会展示出我们一些最初的假设范围太窄，产生的是错误的结果。接着还会让学员学习通过其他方式了解服务原理。
我们利用 Google 内部高度集成的调试信息，展示互相之间的 RPC 连接关系，以及现有的白盒与黑盒监控系统来决定用户请求的数据路径。在这个过程中，我们构造了一个系统组件图，同时讨论了学员未来将会经常见到的共享基础设施服务。
在课程末尾，会给每人分配一个任务。每个学员需要和自己团队的资深 SRE 共同选择未 来 on-call 系统的一部分。利用课程中学到的知识，该学员需要自行构建出整个技术栈的 组件图，同时与资深 SRE 共同讨论。
学员肯定会在这个过程中忽略一些小的但是很关键 的细节问题，这些恰恰是最好的讨论话题。资深 SRE 在这个过程中很有可能也会学到一些知识，因为系统不断变化，任何人都可能出现理解上的偏差。整个 SRE 团队都应该抓 住一切机会学习系统的新变化，而最好的方式恰恰是与团队中最新的成员，而不是最资 深的成员交流。
页:
[1]