大家晚上好！
因此，
在DevOps实践和工具课程流开始之前，已经一无所有（即一天），这意味着我们需要在这段时间内完成本文
“为什么SRE文档很重要”的其余部分。
我们继续。
启用新服务的文件SRE进行PRR（生产准备情况审查）以验证服务是否符合操作准备标准，并确保服务所有者了解如何使用SRE知识来管理大型系统。
该服务在投入生产之前需要经过此测试。 （在发布之前，SRE不支持它，但开发团队本身不支持。）PRR在此阶段的目标是确保服务在发布时达到最低可靠性标准。
下一个PRR发生在SRE服务的传输之前，即启动后可能要花费很多时间。 当SRE团队决定采用新服务时，将对生产状态和使用的服务实践进行全面分析。 目的是在可靠性和操作稳定性方面简化服务转移过程，并帮助SRE更好地处理它。
通过在移交服务之前进行PRR，与在启动之前进行PRR相比，SRE可以提出更多的问题并设置更高的可靠性和易用性标准。 发布前的PRR可以“轻量级”，以免减慢开发团队的速度。
从佐伊的故事来看，该团队没有标准化的流程或PRR检查表，这意味着他们在转移服务时可能会错过非常重要的问题。 因此，存在与大量问题相冲突的风险，在承担管理服务的责任之前，这些问题很容易预见并解决。
PRR /服务转移需要创建PRR模板和流程文档（流程doc），这些文档描述SRE团队将如何使用新服务并使用PRR模板。 传输过程中使用的模式可能比启动期间使用的模式更全面。
PRR模板涵盖多个领域，需要检查关键问题的答案。 表1显示了模板涵盖的一些领域和相关问题。
| 面积 | 问题 |
|---|
| 架构和依存关系 | 从客户端到前端再到后端的请求路径是什么？ 是否存在具有不同延迟要求的不同类型的请求？ |
| 能力计划 | 发射期间和发射后对流量和增长率的期望如何？ 您是否具备支持此流量所需的计算能力？ |
| 故障类型 | 您的架构中是否存在单点故障？ 如何消除依赖项不可用？ |
| 过程与自动化 | 支持服务是否需要任何手动流程？ |
| 外部依赖 | 哪些第三方数据，代码，服务或事件取决于服务和启动？ 您的任何合作伙伴都依赖该服务吗？ 如果是这样，是否需要通知他们发射情况？ |
表1. PRR模板的示例区域流程文档还应指出SRE应向产品开发团队索取的文档，作为转移的前提条件。 例如，他们可能要求开发团队为常见问题创建剧本。
此外，SRE组织将需要创建一个审查文档，向开发团队简要说明SRE的作用和职责范围。 这对于形成现实的期望是必要的。 第一个文档应解释什么是SRE，涵盖上一部分和本文开头所涉及的所有主题，包括主要功能，服务生命周期，支持/维护职责。 本文档的主要目的是确保开发人员不要将SRE与OPS团队混淆，也不要将寻呼机响应视为SRE的唯一职责。 如前所述，如果开发人员在转让服务时不完全了解SRE在做什么，那么这将导致通信问题和误解。
此外，有必要创建一个参与模型文档，以澄清期望并解释服务转移期间和之后SRE团队与产品开发团队之间的交互过程。 文档中涉及的主题可能包括：
- 服务转移标准和PRR流程。
- 讨论服务级别目标的报告（简称SLO）和错误计算的过程。
- 新的启动条件和启动冻结策略（如果可能）。
- SRE团队提供的服务状态报告的内容和频率。
- 人员要求SRE。
- 计划新功能路线图的过程以及与新产品功能相比提高可靠性（由SRE要求）的功能优先级。
服务运营文档为了支持该服务，SRE团队主要依赖于主要的操作文档：服务的一般说明（采访），手册和过程，验尸，指令和SLA。 （注意：本节在“寻求SRE”的“使文档更优质”一章中介绍。）
服务面试对服务的一般描述对于了解SRE支持的服务类型至关重要。 SRE需要了解系统的体系结构，其组件和依赖性，服务的联系人及其所有者。 服务的一般描述是开发团队和SRE团队共同努力的结果，旨在指导和确定SRE任务的优先级，并确定需要进一步研究的领域。 此类采访通常是PRR的结果，应随服务的更改而更新（例如，如果出现新的依存关系）。
一次简单的采访即可为SRE提供足够的信息，以进一步探索该服务。 完整的采访将对服务及其与周围世界的交互方式进行全面描述，并提供仪表板，指标以及SRE解决不可预见问题所需的所有信息的链接。
剧本
有时也称为Runbook，它是基本文档，可让工程师在轮班期间响应服务监视系统的通知。 例如，如果Zoey的团队有一部剧本解释了“ Job Ragnarok向后倾斜”警报的含义以及在收到警报的情况下需要做什么，那么该事件将在几分钟内得到解决。 剧本减少了事件恢复时间，并提供了指向控制台和过程的有用链接。
手册包含有关检查，消除和升级网络监视过程的任何已生成通知的说明。 剧本中的通知名称通常与系统生成的名称一致。 它们包含需要测试准确性的命令和步骤。 当发现解决问题的新方法时，以及确定新的故障类型并添加依赖项时，需要定期更新它们。
剧本不是专门为通知而创建的。 它们还可能包含发布发行版，监视和故障排除的生产过程。 生产过程的其他示例包括打开/关闭服务，维护服务以及事故/升级。
验尸SRE与大规模，复杂的分布式系统一起工作，并借助新功能和添加新系统来改善服务。 因此，鉴于变化的规模和速度，事件和中断是不可避免的。 验尸是一种重要的SRE工具，可以使我们从错误中吸取教训的过程正式化。 在佐伊的假设故事中，团队没有正式的验尸程序，因此没有正式的程序来记录事件的结论以防止事件再次发生。 因此，团队注定要一次又一次地重复同样的错误。
SRE团队需要创建标准化的验尸模板，其中包含捕获有关故障的重要信息的部分。 理想情况下，应该对模板进行结构设计，以便可以通过数据分析工具轻松地对其进行解析。 它使用事后分析作为数据源发送崩溃动态报告。 使用此模板创建的每个验尸都描述了生产失败，包括以下信息（最低要求）：
- 事件的时间顺序（时间轴）。
- 对用户的影响的描述。
- 根本原因
- 行动要点/经验教训。
验尸是由遇到故障的团队成员编写的，理想情况下，是对那些参加了该工作的成员，并且可以对改进负责的。 验尸应以无辜的方式写。 它应该包含了解发生了什么情况所必需的信息，以及为减少重复发生的可能性，减少后果和/或简化恢复而需要采取的决策清单。
指令在策略文档中，指示了特定的技术和非技术规则以及生产指令。 技术规则可能适用于例如记录生产中的更改，维护日志，命名内部服务（工程师在实现服务时必须遵循的命名规则）以及紧急情况识别数据的使用和可用性。
指令也可以针对过程。 升级规则可帮助工程师将故障分为紧急事件和非紧急事件，并了解在特定情况下应采取的措施； 轮班期望指令描述了团队的结构及其每个成员的职责范围。
服务水平协议服务水平协议（Service Level Agreement，简称：SLA）-与客户就所提供的服务工作以及在未履行义务时所采取的措施达成的正式协议。 SRE团队记录服务可用性和延迟，并监视与SLA相关的服务性能。
SLA的文档和发布，以及对用户体验的全面分析及其与SLA的比较，使SRE团队可以更快地进行创新，而不会降低用户体验质量。 支持具有清晰SLA的服务的SRE可以更快地发现故障，从而更快地对其进行修复。 SLA还减少了SRE和SWE团队（软件开发人员）之间的摩擦，使团队能够客观地讨论目标和结果，避免对风险进行主观判断。
值得注意的是，存在外部合法有效协议可能不适用于大多数SRE团队。 在这种情况下，SRE团队可能仅限于服务级别的目标（简称SLO）。 SLO-确定特定指标所需的服务级别，例如，可用性或延迟。
产品文件SRE团队努力将其50％的时间用于项目，开发可自动执行手动工作的软件或提高服务可靠性。 本节介绍与SRE开发的产品和工具有关的文档。
这些文档很重要，因为它们使用户能够了解该产品是否适合他们，如何开始使用它以及如何获得支持。 它们还提供正确的用户体验，并使产品采用更加容易。
产品简介页描述页面可帮助SRE和产品开发工程师了解什么是产品或工具，其用途以及使用方法。
概念手册概念指南或词汇表定义了产品独有的所有概念。 概念的定义允许在用户界面，API和CLI（命令行界面）的文档和元素中保持一致性。
入门指南
入门指南的目的是使工程师迅速更新，并尽量减少延迟。 这对于想试用该产品的新用户很有用。
代码实验室工程师可以使用这些教程，结合理论解释，代码示例和练习，以快速了解产品。 Codelabs还提供了详细的脚本，可引导工程师逐步完成一系列任务。 这些教程通常比入门指南更长。 如果涉及到某件事，它们可以涵盖多个产品或工具。
实用指南对于想要解决特定问题的用户来说，这种指导是必要的。 这些指南通常是您必须遵循的分步指南。
常见问题
在FAQ页面上，用户可以获得最流行问题的答案，了解可能遇到的困难和限制，找到文档的链接以及其他页面，以获取更多详细信息。
技术支持在支持页面上，工程师可以学习如何解决他们面临的问题。 您还可以找到升级计划，故障排除信息，组链接，仪表板和SLO以及班次信息。
API说明本指南介绍功能，类和方法，通常至少附带一些文字。 此类文档通常是基于代码中的注释创建的，有时是由技术作家编写的。
开发人员指南通过本指南，开发人员可以学习如何使用产品API进行编程。 如果SRE创建向开发人员提供API的产品，则通常需要这些指南，这使您可以创建混合的工具来调用彼此的API来执行更复杂的任务。
报告服务状态的文件本节介绍SRE团队创建的文档，以描述受支持服务的状态。
季度服务审查有关服务状态的信息以两种格式表示：SRE负责人同意的季度报告（在整个SRE组织中分发）以及产品开发负责人和团队的演示。
SRE领导者对季度报告感兴趣，因为他们提供有关以下方面的信息：
- 支持问题（班次，票证，验尸）。 SRE领导者知道，如果支持问题开始占用SRE团队资源的50％以上，则有必要做出响应并更改优先级。 目标是尽早发现问题。
- SLA的执行。 SRE领导者想知道SLA是否一切正常，生态系统中是否存在构成威胁的不健康成分。
- 风险性 SLA领导者想了解SRE已知的可能会干扰产品和业务目标的风险。
季度报告使SRE团队有机会：
- 强调SRE为产品开发团队带来的好处以及SRE团队的工作。
- 请求优先级以解决干扰SRE（弹性）命令的问题。
- 请求有关SRE团队优先级的反馈。
- 强调团队的广泛贡献。
成功技术概述该审查有助于采用成功的技术并达到稳定状态，在此状态下操作需要最少的时间。 为了准备此类报告，SRE团队提供了现场和团队章程，轮班状态详细信息，项目与 中断，容量计划等。
对成功实践的回顾有助于SRE团队与SRE组织的其他成员进行比较，并在以下关键方面提高绩效：轮班状态，项目与中断，SLO和容量规划。
第二部分结束。
阅读下一部分。我们将像往常一样等待您的问题和评论。