构建+测试开源监控工具

在2018年的Monitorama，我分享了一些很酷的过程和知识，我从为自己以外的人开发产品中学到了这些知识。在花了六年电话后，我现在构建的软件可以让人们在夜间醒来 - AKA，基础设施以及用于系统监控和性能分析的工具。作为一个去过那里的人，我很认真地建立了人们乐于使用的优质软件。即使该软件的工作是唤醒它们，至少可能是有充分理由的。

在这篇文章中，我将回顾一下这个话题，分享构建开源软件背后的动机，我们的测试方法，以及社区在构建更好的软件中扮演的关键角色。

构建开源软件的动机
首先，定义：开源是公开可用的代码，具有使用，修改和共享的权限。我还将其扩展到包含许可证; 任何人都可以将代码公之于众，但为了能够使用它，您需要能够告诉人们如何使用它，为它做出贡献以及在哪里找到它。

是什么激励人们开发开源软件？对于许多人来说，事实上我们的日常工作很大程度上依赖于它。甚至我们付出的工具都是基于开源技术。就个人而言，我也有动力建立和维护工具，使人们的工作更轻松。作为一名随叫随到的退伍老兵，我不想在半夜不必要地叫醒别人因为我没有正确地写东西。最后，看到您的代码在您无法控制的基础架构中运行，看到其他人正在使用（并从中受益）您创建的工具，这是非常有益的。

测试OSS：确保代码是高性能的
构建开源软件一切都很好，但确保它正常工作也很重要。我们今年早些时候发布了（和开源）Sensu 2.0作为Alpha ; 我们在etcd的顶部重写了我们的产品。虽然我们仍然使用pub / sub模型，但它现在嵌入在etcd之上。您只运行一个二进制文件，与v1相比，设置和开始使用更快。我们的Alpha远非抛光或完美，但我们想让我们的用户知道疼痛点，人们失踪的东西以及他们喜欢什么。

一旦我们获得了Alpha - 以及我们用户的一些信息 - 我们就开始计划QA测试的样子。由于我们不是我们软件的主要消费者 - 而且我们不在内部基础设施上运行 - 因此了解我们的软件是否正常工作非常棘手。我们在开发过程中的测试仅限于单元，集成和端到端测试，这些测试有其自身的挑战，并且在某些情况下往往会变得脆弱（稍后会详细介绍）。这些对于确定代码是否在开发过程中起作用很有用，但是 - 因为我们没有在真实环境中进行测试 - 它们在确定功能需求，可用性或系统行为时没有用。我们没有在真实环境中进行测试。当您不是产品的核心用户时，可用性测试也很困难，特别是在这种可塑性框架的情况下。

在测试软件时，我们要记住以下问题：

该软件的行为是否符合我们的预期？
它能解决问题还是需要？
我们可以在用户之前找到错误吗？
为了回答这些问题，我们需要进行不同类型的测试来衡量我们的系统执行情况：

代码质量。我们使用Code Climate的Velocity来跟踪PR大小，合并时间和复杂性风险，并提醒我们PR的大小。我们的公关目标是200行代码，我们在50％的时间内实现了这一目标。但是，与去年的这个时间相比，这是一个完全不同的故事。
图片标题

资料来源：Code Climate的速度

虽然这是一个简洁的指标，但并非总而言之; 它无法确定您的代码库是否能够保持一致的质量，因为功能和错误周期会随着时间而变化。

代码分析，或我们的构建成功率。
图片标题

正如您所看到的，我们正在努力获得稳定的CI测试套件。而且，如果我们遇到这个问题，我们的用户也会这样，因为我们没有及时得到东西。我们发现我们的端到端测试策略很脆弱，我们不得不重新编写一些构建测试以使其更可靠。再次，稍后会有更多内容。

用户测试，或者我喜欢叫暴徒QA。你不可能涵盖软件测试的所有可能性; 你需要实际使用才能发现错误。
图片标题

我们在Zoom调用中聚在一起，找出了我们试图测试的功能，并确定了验收标准。每个人都选择了一两个功能来测试他们没有工作过，我们开始左右分解。我们发现了一些非主要的软件错误 - 更重要的是 - 加深了我们对代码库和功能的理解。

负载测试。为了对推荐使用和开发新功能充满信心，我们需要一些数据点来说明客户将要遇到的负载类型。
图片标题

我们的计划是在Google Cloud Platform中设置一个运行sensu-backend的VM，并运行一个Kubernetes集群，每个pod有五个代理。我们假设GKE会自动缩放，直到我们需要多少代理（10,000），但实际上，我们最终加载测试GKE！因为我们一次启动了这么多pod，所以API限制了我们，因此我们不得不重新考虑我们的负载测试策略。我们采用更简单的方法在Go中编写脚本来启动10,000个代理并将它们连接到单个后端。

这些测试帮助发现了一些有趣的错误，包括性能问题（涉及etd自动压缩错误），奇怪的UTC时序错误和检查调度失败。我在谈话中详细介绍了这些错误 - 以及我们如何修复它们。

我之前提到过，我们的一些测试揭示了我们理解中的差距（或错误）; 我无法强调文档的重要性。我喜欢Jordan Sissel的这句话：“如果一个新用户有一个糟糕的时间，这是一个错误。”我有很多不好的时间，文档似乎是错误，但实际上只是糟糕的文档。我们希望通过Sensu 2.0避免这种情况，并决定对Beta版本的文档进行改进。我们甚至创建了一个关于如何编写文档的文档，并提供了适当的指南应该包括的建议：

为什么要使用此功能
这是什么
一种快速而肮脏的方式来设置
功能API的参考指南
有文档的指南（用于文档）可以更轻松地围绕特定功能编写一致的故事，以了解您的工作方式。现在，我们的文档是有组织的，可搜索的和开源的 - 用户在看到问题时可以做出贡献。

社区的重要性（以及我们如何从中学习）
现在Sensu 2.0已经在野外，我们依靠Sensu社区来使用它并提供反馈。我们通过多种方式与社区互动，包括社区松弛，加速反馈计划和社区聊天。

我们还在探索从Go社区了解到的经验报告，其中包括诸如“您希望此功能如何工作，它如何实际工作以及您在特定环境中使用它做什么？ ”

我们的社区将继续为我们的决策提供信息，并加深我们对产品使用方式的理解。构建开源软件最终是非常有益的 - 无论是个人还是专业 - 还有一个额外的好处，即拥有一个可以帮助改善它的大型用户社区。