当我们想到可靠性工具时，我们可能忽略了简陋的清单。而像这样的工具SLOS代表SRE的前沿，清单已在许多行业中被推荐，例如外科学和航空差不多有一个世纪了。但是，清单之所以被广泛采用，是因为它们是有用的。
当将代码部署到生产中时，检查列表可以帮助限制错误。在这篇博文中，我们将介绍：
- 如何制作生产清单
- 为什么生产检查表是有用的？
- 保持最新的检查清单
如何制作生产检查表
生产清单应该是整体的。他们应该涵盖一切，从启动后勤到应急计划失败。让我们详细分析一下你需要什么才能得到一份完整的清单。
1.确定您正在启动的服务级别
要确定您的清单应该有多详细，请考虑客户需要的可靠程度。你可能会倾向于尽可能全面地检查每一份清单，但这可能会耗费时间，也可能是不必要的。在默卡里，服务级别是根据服务的SLO确定的。对业务成功至关重要的服务比特定服务受到更多的关注。
2.绘制所有核对清单地区的地图
列出您服务的所有主要组件。这些组件可能属于不同的团队所有。例如，您可能需要咨询服务器管理团队、测试团队和许多其他人员。尽快知道你需要咨询谁是很重要的。需要考虑的一些领域包括：
- 服务器端：这项服务将在哪些机器上运行？如果您是基于云的，您的计划会覆盖新服务的负载吗？
- 客户端：您的服务对所有潜在客户可用吗？
- 监测：你有办法从你的新服务中收集数据吗？
- 增长：您是否有一个路线图，您将如何维护或改进服务的未来？如果使用量增加了呢？如果您需要扩展功能呢？
- 依赖性：您的服务还依赖于哪些内部服务和第三方服务？它们能顺利整合吗？
- 测试：新服务是否在镜像生产环境中进行了测试？
- 安保：您的新服务会通过您的安全审核吗？
- 可靠性：您的用户期望的可靠度是多少？当你无法满足这些期望时，你有什么计划吗？
- 事故反应：如果事故导致服务中断或退化，您将做什么？你有运行手册来报道这些事件吗？
- 法律：您有保证可用性的SLA吗？该服务是否处理必须保密的个人信息？
- 后勤：发射时间表是什么？你需要什么资源？
有关需要考虑的领域的更多示例，请查看谷歌的发布协调核对表, Gruntwork.io的AWS清单，或默卡里核对表.
3.编制核对清单项目
这些领域中的每一个都包含许多问题，需要数据来回答。你的清单应该要求每一块数据。下面是一个如何分解某些部分的示例：
您还可能想要包括信息，关于谁应该咨询，以检查每一项，以及能够检查它的时间框架。建立您的清单，并检查项目，随着开发的进展。再次检查，以确保项目准备就绪，并在发射前，对整个列表做最后的检查，以防万一。
检查清单
随着你的发展，你可能会发现更多的领域，你想要审查在发射之前。为了防止您的检查表变得太长，您将需要一个系统，以确保新的添加是有帮助的。在谷歌，团队有两个标准可以将项目添加到清单中：
- “每个问题的重要性都必须得到证实，最好是之前的发射灾难。”
- 每一条指令都必须是具体的、实用的和合理的，以供开发者完成。
可以根据所分配的服务级别确定标准。与其缺少必要的东西，不如有一件不必要的东西。可以从一个大清单开始，并在每次启动后根据需要删除项目。
为什么生产清单是有用的？
生产清单似乎会增加工程师工作的开销。然而，前期工作可以避免团队未来的问题，并确保成功启动。生产清单帮助：
- 消除必须记住一切的认知劳累
- 提前找出可能出现的问题
- 提前准备资源
- 激励开发完成必要的项目
- 优先考虑关键需求而不是不必要的增加
- 确保应急计划，提高可靠性
- 让每个人在整个开发过程中处于循环状态，作为一个集中式进度表。
如何保持生产检查表的最新更新
您将需要定期检查和修改您的清单，以保持它们的有用性。一定要在这些时候重新审视他们：
新服务开发启动时
在规划新服务时，请考虑在启动时使用哪种生产检查表。根据服务类型和服务级别，找到最接近的检查表。检查它以确保它遵循当前使用的流程和体系结构。在开发过程中添加任何特定于服务的需求。
发射后
启动新服务后，请查看生产清单。发射有什么问题吗？他们能事先检查一下吗？查找被误解和填写错误的核对表项目。修订这些项目，以确保核对表符合发展的实际情况。
事发后
如果事件影响到新的服务，看看是否有任何促成因素可以用清单解决。如果是这样的话，尝试在未来的检查列表中捕获这些项目。可以将此任务合并到您的事件回顾.
作为定期审查周期的一部分
设置一个检查工具(如Runbook和产品清单)的时间表。确保邀请所有需要使用这些运行簿或检查列表的团队成员。这些人中的每一个人都能提供关于如何改进前进方向的洞察力。
