生产准备就绪审查（PRR）是一个起源于谷歌的过程，在该公司著名的SRE书中被描述为现场可靠性工程参与的第一步。在交出传呼机之前彻底审查一个产品的想法真的很好，但除了谷歌规模的公司，没有那么多组织能够负担得起专门的SRE团队。
在Grafana实验室，我们的产品团队经常扮演着SRE团队的角色。此外，由于有很多技术上的相似之处，我们有一个负责多个产品的轮值制度--由不同产品团队的工程师组成。由于没有正式的SRE入职培训，我们把生产准备审查作为一个完全独立的过程，通过让有经验的工程师，最好是产品团队之外的工程师来审查有关产品，努力增加价值。产出是一个已确定的问题清单，从长远来看，这应该减少产品可能面临的劳累和风险。
我就这一主题发表了演讲，"生产准备情况审查。为SLO提供一个坚实的基础"，在今年的SLOConf上。在这篇博文中，我将介绍我们的PRR过程以及我们在这一过程中形成的一些最佳实践。
检查表
一份写得很好的检查表是PRR的一个重要组成部分。这份清单并不是要一丝不苟地涵盖所有的内容，而是要运用常识和过去的经验来确定要谈论的关键话题。我们的目标是填补会造成重大风险的空白，而不是设计一份无懈可击的检查清单。
在设计PRR核对表时，需要考虑的主要因素之一是不要过于超前于当前的现状。在制作检查表时，应始终考虑到当前的最佳实践和产品状况，以提供具体的、可操作的、具有明确附加价值的反馈。这两个要素在这里至关重要--过多地进入最佳实践和建议的领域（例如，讨论所使用的代码设计模式）可能会成为一个滑坡，慢慢地将PRR变成一个没有什么实际建议的架构审查。
一旦制定了检查表，检查表本身就远不是一成不变的。随着公司和工具的发展，检查表将需要更新。更不用说PRR检查表的初稿可能远非完美。
在Grafana实验室，我们已经对我们的PRR检查表做了一些更新。0版是一个集思广益的原始清单，包括我们认为足够重要的主题和问题，需要解决。然而，这对于产品利益相关者来说，是相当难以填写的。因此，第1版对其形式进行了改进，包括例子和澄清。这被用于PRR的金丝雀回合，这也导致了大量的反馈和PRR检查表的增量改进。
审查
审查分多个步骤进行:
- 一个产品团队的成员被选来领导这一过程，并与PRR团队联系，要求进行审查。PRR团队从审查员库中选择一名审查员，他将成为此次审查的主要联络人。
- 产品利益相关者填写PRR检查表。如果需要任何指导（无论是对PRR核对表的澄清还是一般的过程问题），审查员会在那里提供帮助。
- 产品利益相关者和评审员之间的定期1:1会议得到安排。我们已经尝试过每周和每两周一次的30分钟会议。通常需要10次或更多的会议来彻底检查核对表，这导致这个过程需要2-3个月才能完成。根据我们的经验，将时间划分为30分钟的会议有利于保持对较小范围内的问题的关注。超过两星期的会议间隔通常意味着失去了背景。PRR的总时间不应该太长--随着产品的发展，核对表上的答案可能开始迅速变化。这对于上市前的PRR来说尤其如此。
- 在会议期间，我们有时发现让审查者扮演一个试图破坏审查中系统的攻击者的角色是很有用的。我们发现的任何问题都作为产品缺陷归档。
- 一旦整个检查表被审查完毕，重点就会从发现问题转变为修复问题。没有严格意义上的定期1:1的需要，但审查员和产品利益相关者之间的沟通（较低频率的会议或异步）是至关重要的，以确保在关闭已确定的问题上继续取得进展。
- 一旦这些问题被解决，产品就通过了PRR。
展望未来
不过，PRR不一定就此结束。我们已经确定了一些未来要关注的领域:
- 我们才开始做PRR，但即使在PRR运行的时候，检查表和产品都在不断发展。我们正在研究定期和/或增量的PRR，作为我们持续产品改进的一部分。
- 一旦我们收集到足够的数据，对PRR文件进行交叉对比，看看哪些地方问题较多，可能会帮助我们找出工程流程中的弱点。
- 到目前为止，对PRR清单的任何更新都是有机地发生的（即，当审查过程中发现一个问题时）。想办法更系统地处理反馈和更新PRR可以带来巨大的改进。
结论
Grafana实验室的PRR金丝雀是成功的--我们已经成功地发现了一些重要的问题（比如缺失的索引文件可能会导致服务瘫痪，以及可以轻松修复的工具），当然也可以看到更多的改进。
