大家晚上好！ 我们急于分享有关2月份我们将在
Devops-实践和工具课程上发布新消息的消息，这意味着现在该完成我们的内容并发布文章的第三部分：
“为什么SRE文档很重要” 。 走吧
用于管理SRE命令的文档SRE团队需要可靠且价格合理的文档才能有效地工作。
团队现场注意：您可以在Confluence / Wiki中使用单独的空格或部分来代替站点。
团队的网站很重要，因为它可以协调与SRE团队及其项目有关的信息和文档。 例如，在Google上，许多SRE团队使用g3doc（内部的Google文档平台，其中的码头停靠在带有相关代码的源代码中），而一些团队则使用g3doc和Google网站：在这种情况下，g3doc页面与实现代码/详细信息密切相关。
团队章程
SRE团队应支持已发布的章程，其中概述了工作动机并记录了持续的参与。 该章程对于确立整个公司团队的身份，主要目标和价值是必不可少的。
该章程通常包含以下内容：
- 团队职责范围的高级描述。 包括团队支持的服务类型（以及如何），相关系统，示例。
- 团队支持的几个最重要的服务的简要说明。 本节还重点介绍了关键技术以及使用它们的挑战，涉及SRE的好处及其职责。
- 团队的主要原则和价值观。
- 链接到团队网站和文档。
它还假定存在愿景声明（对未来的愿景概念-对团队长期目标的鼓舞性描述）和几个阶段的路线图。
集成新SRE的文档为新员工投资培训工具和材料对员工融入工作流程的速度产生积极影响。 对于SRE团队来说，尽快培训新来者具备所有必要的轮班工作技能是有益的。 佐伊（Zoe）的故事清楚地表明，缺乏对新员工的全职培训如何使轻微事件成为严重的故障。
许多SRE团队都使用清单来为新员工准备轮班。 轮班检查表通常涵盖团队成员应理解的高级区域（分为小节）。 这些领域的示例包括生产概念，前端和后端，自动化和仪器仪表，监视和日志记录。 而且，清单中可以包括用于准备轮班的指令和在轮班期间执行的任务。
为了准备SRE团队的新成员，他们还使用角色扮演练习（在Google中，他们被称为“不幸之轮”-“失败之轮”）。 此练习是一个失败场景，具有一组特定的数据和信号，假设SRE可能需要在轮班期间解决问题。 团队成员轮流扮演值班工程师的角色，以磨练他们对灾难恢复的掌握和调试系统的能力。 不幸之轮检查团队的每个成员是否知道在哪里可以找到解决问题的文档以及如何处理故障。
仓储管理SRE团队的所有信息都可以分散在多个站点，本地存储库和Google云端硬盘文件夹中，这使搜索正确的站点变得非常复杂。 正如前面的示例中所发生的那样，Zoe（值班SRE）无法获得关键的操作工具和使用说明，因为它们被隐藏在她的技术负责人的个人目录中，并且无法找到它们大大增加了服务故障的持续时间。 为了消除此类问题，您需要对所有信息进行结构化处理，并确保团队成员知道在哪里可以找到和存储它们以及如何维护它们。 完善的结构将帮助团队更快地找到信息。 新的团队成员将更快地保持最新状态，而值班的工程师将更快地解决问题。
以下是有关如何创建和维护文档存储库的一些准则：
- 确定主要的利益相关者，并进行简短的访谈以识别所有需求。
- 找到尽可能多的文档并分析内容上的空白。
- 根据您的站点结构在正确的位置创建新文档。
- 将现有文档移到新位置。
- 存档并拆除旧文档。
- 进行定期检查，以确保受支持文档的质量/一致性。
- 确保标准搜索查询在搜索结果列表的最顶部返回必要的文档。
- 使用信号（例如Google Analytics（分析））来衡量标准做法。
关于存储库支持的注意事项：定期检查和更新文档很重要。 所有者的姓名和最后检查的日期应该可见-此信息有助于验证所选文档的准确性。 Zoe历史上仅能找到关键工具的过时文档，从而失去了快速解决问题的能力。 不可靠且过时的文档使SRE的效率降低，从而对托管服务的可靠性产生负面影响。
储存库可用性SRE团队应确保即使标准存储库崩溃且不可用，文档也仍然可用。 每个Google SRE都拥有其关键文档的副本。 该副本可在加密的紧凑型存储设备上或每个SRE都有的类似的可移动但安全的物理介质上找到。
停用服务的文档服务的生命周期结束时，SRE将以可预测的方式将其停用。 本节提供有关停止服务的文档的建议。
重要的是要在服务停用之前通知用户并提供时间表和步骤。 您的广告应说明何时终止新用户注册，将如何处理现有的和将来发现的错误以及何时最终停止服务。 清楚地确定所有重要日期以及减少对SRE的支持的过程，并在进行过程中发送临时公告。
简单的电子邮件分发是不够的-您需要更新文档，剧本和代码实验室的主页。 另外，如果可能，请对头文件进行注释。 在用户可以参考的文档（除了信函中）中描述公告的详细信息。 该信函应尽可能简短，但同时应提供信息，并反映所有要点。 描述其他详细信息：关闭该服务的商业动机，用户可使用哪些工具迁移到另一服务，迁移过程中可获得哪些支持。 创建FAQ页面也很值得，随着时间的推移，它会向用户填充有关用户提出的问题的新信息。
技术文档编辑者的作用技术编辑（或技术作家）提供的服务可以使SRE更加高效和高效。 任务范围不仅限于根据SRE团队指定的要求编写单独的文档。
这是技术编辑与SRE团队合作的一些实用建议。
- 技术编辑人员与SRE合作创建用于运行服务的操作文档以及SRE产品和工具的生产文档。
- 他们创建和更新文档存储库，根据用户的需求对它们进行结构化和重新组织，并改善单个文档，将其作为整体存储库管理的一部分。
- 编辑者帮助确定文档和信息管理所需的改进。 这包括评估文档以收集需求，改进工程师创建的文档和站点，为团队提供有关创建，组织，重新设计，搜索和维护文档的规则的建议。
- 编辑者应该评估和改进文档工具，以提供更好的SRE解决方案。
模式技术编辑人员还提供简化SRE文档创建和使用的模板。 模板执行以下操作：
- 通过为工程师提供用于创建新文档的清晰结构，简化文档的创建。
- 添加所有必要文档的部分，以完整完成文档。
- 它们帮助读者快速理解文档的主题，信息的类型以及其组织方式。
站点可靠性工程包含几个样本文档模板。 在本节中，我们将提供更多示例，以显示模板如何提供结构以及如何为工程师填充内容的指南。
服务面试复习这是什么 他在做什么？ 高层描述了提供给客户的功能（最终用户，组件等）。
建筑学解释架构的工作原理。 描述组件之间的数据移动。 考虑添加关键的依赖系统图，并流程查询和数据。
客户和依存关系列出所有依赖它的客户（属于其他团队）和所有依赖它的服务（属于其他团队）。 （这也可以以系统图的形式演示。）
代码和配置解释生产结构。 它在哪里运行？ 列出二进制文件，作业，数据中心和配置文件设置，或指示它们的全部位置。 还提供代码的位置，并在必要时提供有关构建的信息。
列出并描述操作此产品或服务所需的配置文件，更改和端口。
描述以下内容：此产品或服务已更改了哪些配置文件？ 设置如何完成？
流程描述以下内容：服务必须运行哪些守护程序和其他进程？ 创建了哪些控制脚本来管理服务？
印记列出并描述组件创建的日志文件以及进行的观察。 描述以下内容：该组件生成哪些日志？ 每个文件中都有什么？ 研究这些文件有什么建议？ 应该监视组件的哪些方面以确保可靠的服务操作？
仪表板和工具将链接粘贴到相关的仪表板和工具。
威力指示单个实例的功能； 全球数据中心：QPS，带宽和延迟值。
服务水平协议提供辅助功能目标。
标准程序添加到过程的链接，包括负载测试，更新/推送/标志状态等。 在警报手册中添加指向警报文档的链接。
参考文献添加通常由开发团队编写的指向组件或相关组件的设计文档的链接，以及其他相关信息。
剧本职称在名称中，指定警报的名称（例如，NormalAlert_AlertVery Very Normal）。
复习描述以下内容：此警报是什么意思？ 它是传呼机还是只发邮件？ 哪些因素会触发警报？ 服务的哪些部分受到影响？ 哪些警报与之相关？ 谁需要通知？
危险等级警报证明通知的危险程度以及受影响部件对服务总体状况的影响。
确认书提供有关检查和验证状态的明确说明。
故障排除列出并描述调试方法和相关信息源。 不要忘记指向相应仪表盘的链接。 打开警报。 描述以下内容：触发警报后，日志中将显示什么？ 有哪些调试处理程序？ 有有用的脚本和命令吗？ 它们产生什么输出？ 消除警报后，是否还有其他需要解决的任务？
解决方案描述并列出导致警报的问题的所有可能解决方案。 描述以下内容：如何解决问题并解决警报？ 要运行哪些命令以重新引导？ 如果由于用户操作触发了警报，应该通知谁？ 谁有调试类似问题的经验？
升级列出并描述升级路径。 指出要通知的个人或团队以及何时通知。 如果不需要升级，请写下来。
相关连结提供指向相关警报，过程和审阅文档的链接。
季度服务报告
引言
描述团队负责的服务。
能力计划包括：
- 从最近6到8个季度开始的服务实际需求，以与服务最相关的指标（例如QPS或DAU）表示。
- 未来8个季度的预测。
- 在所需的冗余级别上满足计划需求的容量计划-指定不足和/或容量计划风险。
我们还建议添加过去2-4个季度的预测，以便读者可以评估预测的稳定性和准确性。
SLA实施/可用性SRE支持的所有服务都必须具有书面的SLA，以评估每个季度的性能。
SLA部分应包含用于衡量SLA条件的季度可行性的服务主要组件的参数，以及与书面SLA团队的链接。
伴随事件（可选）每季度列出3-5个主要事件或失败。
成就（可选）列出该季度的主要成就。
SLA更改（所需）SLA的最新更改。
服务详细信息（理想）该部分可能包括增长，延迟统计信息等。
团队信息（可选）可能包括有关团队组成，状态，项目，轮班统计的信息。
数据源（必填）描述用于获取可访问性值的来源，计算方法，并提供指向相应仪表板的链接。
团队宪章我们是谁用一句话（〜1行）描述技术环境，客户和团队建议，以及SRE参与的程度和特殊专业知识。
支援服务为了进一步阐明工作范围，请描述团队支持的服务（或其小组）。
我们如何花费时间范围界定有助于创建路线图并实现和支持长期目标。
团队价值观清楚地描述值。 这会影响团队成员彼此交互的方式以及他人对您的团队的看法。
结论无论您是SRE，SRE经理还是技术编辑，现在您都知道文档对于有效的SRE团队的生命至关重要。 好的文档可以使SRE团队发展壮大，并遵循清晰的方法来管理新服务和现有服务。
因此，我们发布了本文的最后一部分，通过单击超链接可以阅读
第一部分和
第二部分，您将在2月19日举行的
公开课中获得更多有用的信息。 我们在等大家！