大家晚上好！
我们发射的强度每个月都有所不同。 在9月的学生完成
“开发-实践和工具”课程的第二个月之前，我们将开放下一个课程。 因此，我们再次准备与您共享有关该主题的有用材料，并在等待同样有用的
公开课程 。
今天，我们将讨论有关文档如何使SRE团队管理新服务和现有服务的文章的第一部分。
SRE（站点可靠性工程，大致翻译为“确保信息系统的可靠性”，该领域的专家使用相同的缩写）-一种特殊的学科，思想和一套旨在确保Web产品和服务平稳运行的技术方法。 SRE处于软件开发和系统工程的十字路口，解决操作问题并为大规模分布式系统的设计，创建和操作开发可扩展，可靠和高效的解决方案。
SRE的主要目标：
- 监视和收集指标 -确定服务的期望行为，研究服务的实际行为并消除差异。
- 事件响应-检测并有效响应服务故障，以使服务可用性与其SLA（服务级别协议）保持一致。
- 容量规划 -预测未来需求，并在适当的位置提供必要数量的计算资源以满足此需求。
- 服务扩展 -数据中心中服务的计算能力的可预测部署和取消，通常是容量规划的结果。
- 变更管理 -改变服务的行为而不会失去其可靠性。
- 性能 -与扩展，隔离，延迟，吞吐量和效率有关的设计，开发和工程。
SRE的重点是服务生命周期：从构思和设计到部署，运营，性能改进以及最终退役。
在启动SRE服务之前，他们通过在系统架构，开发软件平台，框架和容量计划以及进行启动审查方面的咨询来为它提供支持。
当服务已经在运行时，SRE支持它如下：
- 他们测量和监视系统的可用性，延迟和整体状况。
- 检查计划的系统更改。
- 他们使用某些机制（例如自动化）来扩展系统的稳定性。
- 通过促进旨在提高可靠性和速度的更改来改进系统。
- 进行事件响应和“无辜”验尸。
当服务寿命即将结束时，SRE将以可预测的方式将其停用，并提供清晰的说明和完整的文档。
一个成熟的SRE团队对于每个SRE功能始终拥有完整的文档。 如果您管理SRE团队或计划组织它，则本文将帮助您了解团队所需的文档类型，这将帮助您与团队的其他任务并行地计划文档工作并确定其优先级。
SRE的历史
在讨论SRE文档的细微差别之前，让我们看一下新制作的SRE Zoe生命中的一天。
Zoe担任SRE角色的第二个转变是在AcmeSale在Acme Inc.的旗舰项目中进行的。 当她只适应团队时，她观察同事的工作并做笔记。 但是现在她仍然有传呼机。
幸运的是，寻呼机在凌晨2:30打电话。 消息说“ Job Ragnarok向后倾斜”，Zoe不知道那是什么意思。 她翻阅笔记，找到指向仪表板主页面的链接。 一切看起来都很好。 她尝试在Acme内联网上找到一些参考Ragnarok的文档，几分钟后，她发现了有关服务体系结构的过时文档，事实证明这是AcmeSale的关键依赖项。
幸运的是，在迪斯科中有一个指向“ Ragnarok Ops”页面的链接，该页面找到了带有有用图形的仪表板的链接。 该页面还提到了ragtool脚本，该脚本可能能够帮助解决问题，但是Zoe第一次听到了它。 因此，她向具有该服务和工具多年经验的SRE发送了一个寻呼机帮助请求。 不幸的是，没有答案。 Zoe检查邮件，并看到一条消息，说她的同事由于健康问题而离线了一个小时。 在权衡了所有利弊之后，她给自己的技术人员打了电话，但电话进入了语音邮件。 一切都表明您必须自己解决此问题。
在花了一些时间搜索有关神秘的ragtool脚本的信息之后，她找到了一个文档，其中对该文档的命令行参数以及可在何处找到了简短描述。 她启动了一把ragtool-重新启动并用手指交叉以期盼望。 一切都没有改变，流量下降得更多。 她拼命地看着其余的命令行选项，但不确定它们是否会危害更大。 最后，她决定使用ragtool –rebalance e – dc = atlanta，因为从图中可以清楚地看出，该问题在亚特兰大的数据中心特别明显。 交通图开始慢慢爬起来，佐伊为胜利感到高兴。 MTTR（平均修复时间）为45分钟。
第二天，佐伊对该事件进行了事后讨论。 这是因为问题特别严重，导致收入损失，此外，经理要求进行更多的验尸。 她问团队其他参与者如何解决这个问题，她听到了三种不同的方法。 事实证明，根本不存在单个故障排除过程。 她的同事还承认，“向后倾斜”通知不是最好的名字，而失败是由于已知的bug引起的，而该bug根本不是优先事项。
最后，她的技术专家史蒂夫（Steve）问：“您获得了ragtool的哪个版本？”，然后指出所使用的版本非常旧。 一周前发布了一个新版本，以及描述所有功能，甚至解释如何解决“ Job Ragnarok靠背”问题的全新文档。 此版本会将MTTR减少到五分钟。
ragtool的新版本的存在使团队的一半感到惊讶，而另一半则或多或少地意识到了新版本和指南。 该脚本的最新版本位于Steve的主目录中，很明显位于bin /文件夹中。 佐伊（Zoe）将其添加到她的笔记中以备将来使用，希望能够平静地完善其余的转变。 她想知道Techlide或团队中的一员是否将解决事后讨论的问题，或者将来所有的SRE是否必须经历这种痛苦的经历。
当天晚些时候，Zoe参加了一次会议，SRE团队与开发团队就服务转移进行了沟通。 史蒂夫（Steve）主持了会议，询问了先前提出的有关操作程序和当前服务可靠性问题的几个问题，并要求开发人员在SRE团队对服务负责之前进行更改。 佐伊（Zoe）已经参加过史蒂夫（Steve）和其他资深SRE举行的几次集会。 她了解开发人员提出的问题和分配的任务有很大不同，这取决于谁举行会议以及SRE团队上周处理的问题。
佐伊（Zoe）暗自梦想着制定更一致的标准和程序，但还不了解如何实现这一目标。 后来，她听到两个开发人员嘲笑咖啡机，说很多问题与传呼机有松散的联系，他们通常不知道它们来自何处。 Zoe希望开发人员了解SRE不仅随身携带寻呼机。 回到工作场所，佐伊发现了几张需要整理的票，不再考虑。
幸运的是，这个故事中的所有人物和事件都是虚构的。 但是，请考虑一下这是否类似于您在现实中遇到的东西。 这个虚构团队的问题的解决方案非常明显，在下一节中，我们将对其进行详细讨论。
文件的重要性
在SRE团队成立的早期，组织高度依赖团队中各个高素质个人的工作。 团队将重要的开发概念和原则存储为“部落知识”的内容，并通过语言将其传播给团队的新成员。 如果这些原则没有统一并且没有记录在案，很可能在某些时候必须通过反复试验来痛苦地再次教导它们。 有时，团队成员将操作程序作为严格的步骤序列来执行，这些步骤由其前辈在很久以前定义，甚至没有理解这些步骤的因果关系。 如果不停止这一步，流程将变得支离破碎和退化，这只会使团队开始成长以解决新问题。
SRE团队可以通过创建高质量的文档（这些文档将为此类团队的成长奠定基础）并引入系统的方法来管理新的和陌生的服务来防止此过程。 这些文档以易于查找，维护和搜索的形式保存了部落知识。 通过系统，周到的计划对新团队成员进行培训。 这些是成熟的SRE团队的标志。
本文的其余部分描述了SRE在受支持服务的生命周期内创建的各种类型的文档。
结束
在下一部分中，我们将详细考虑所有这些类型，但是现在我们正在等待您的评论和问题，我们还邀请您参加
公开课程 。