你认为保护数据流水线只需要做一些测试，那样所有的数据问题就都解决了？不幸的是，事情没有那么简单。。。

恭喜，你已经在自己的流水线上成功实现了一些数据测试！无论是否是用的现成的或者自研的工具，对于保证高质量的可靠数据，通过数据测试来保证数据是非常重要的，而且你也已经做了一些必要的步骤了。现在数据的所有问题都解决了，也可以愉快的睡觉了，因为你知道你的数据流水线会发布完美、高质量的数据。但是，似乎没有这么快。有一个细节你可能遗失了：你的测试如果失败的话会发生什么事情？如何报警？有人监控报警吗？谁会响应他们呢？你怎么告诉别人哪里出错啦？你如何去修复产生的数据问题呢？

跟数据团队一样的兴奋，关于在流水线里实现数据验证 - 数据测试的实际的挑战不只是你如何发现数据问题，还有你如何做响应。这片文章中，我们谈一下响应数据测试问题的关键步骤，并且列举出一些关键的条目，供我们在开发一个数据质量策略的时候作为参考。下面的图是我们要讲的一些点：

1. 系统响应错误
2. 日志和报警
3. 报警响应
4. 根因的定位
5. 问题解决
6. 协作讨论

系统响应

首先，对于一个失败数据测试，在通知到人之前，系统对失败测试用例的自动响应，决定了是否以及怎样继续运行流水线。它可能会如此响应：

1. 什么也不做。继续运行流水线，只是简单的记录一下失败或者直接发报警。
2. 将错误数据隔离，比如把错误那行移动到一个单独的表或者文件中，其余的流水线继续运行。
3. 停止流水线运行。

系统也会根据发现问题的严重级别而产生不同的响应，如下所示，如果遇到“warning”级别的错误，流水线继续运行也没问题，但是如果遇到了“critical”、“error”级别的问题就绝对不能再运行了。

日志和报警

数据结果验证很可能只是简单的写在一些日志中，我们假设测试用例中有一些很严重问题需要报警。我们可能需要做以下几点：

1. 什么样的错误需要报警？什么样的错误只是记录一下log就可以了呢？一定要给报警定义一个正确的严重级别，并且只通知相关人，并且在绝对必要的时候再报警，避免报警疲劳。
2. 用什么作为报警通知的工具？你会给一个超忙的群组或者邮箱发报警吗？也许他们都无法注意到。把严重级别报警混在每日报告中，也许被看到的机会更少？使用像PagerDuty一样的工具，能让你调整报警，使其与严重级别和需要做的响应匹配。
3. 什么是报警的及时性？报警时一直发送还是在一天中的某些时间点来发呢？有一个很重要的考量因素，当你报警失败了-会有人注意到吗？

现在你的报警已经建立起来了，下一件事：谁会真正的响应通知？有些因素需要考虑：

1. 什么人什么时间会收到通知？上游的数据生产者，下游的数据消费者，数据流水线的所属团队，还有别人吗？确保你对那些用了你的数据的人、并且出现问题后需要了解问题的人，有一个清晰的认知。
2. 谁对确认和排查报警负责？这有可能是一个最重要的决定性因素去考虑和构建数据测试：必须有人对结果负责。也许对于不同类型的测试，不是同一个人，但是你最好有一个明确的计划，避免报警不被注意到或者被忽略，如果被忽略，相关人可能会很沮丧。我不是说一定要on-call，但也许真的需要一个on-call。就像之前说的，调整报警的严重级别：on-call不意味着你会在半夜收到通知，它只是让大家知道他们负责报警的处理，相关人和他的团队也知道谁在负责这件事。
3. 你的通知认识足够的清晰吗？相关者可以知道他们需要什么吗？尤其是，你的数据消费者知道报警的含义并且知道如何获取到问题的更多的信息或者潜在的解决方案吗？（提示：可以提供明确的联系人，比如安排一个人on-call，来对这些问题提供帮助）

相关者的联络

根因的定位

我们认为数据测试失败的根因来源于以下几类：

1. 数据实际上正确，但是我们测试需要兼容。比如，有一些不寻常但正确的异常值。
2. 数据实际是错误的，但可以被修复。直观的例子，格式错误的日期或者电话号码。
3. 数据崩溃了，并且不可以修复。比如，数据缺失。

一个非常普遍的数据问题，发生在数据加载或者数据获取阶段，数据发生了变化，数据的团队就无法控制。在我做第三方医疗数据时，我看到无处不在的各种各样的数据问题。一些普遍的例子，包含数据不被更新（数据发布延迟导致），表属性的变化（比如列名和类型），或者值和范围与预期偏离（生成数据方法变化）。另一个主要的原因在数据获取时的问题是在实际的数据获取或链路中，经常会出现（标记为）旧数据。这种经常经常发生在处理hang、crash或者获取备份时，因为长时间的运行。

现在，你怎样去定位数据获取问题的根因？关键且有条理的步骤：

1. 确认实际发生的、精确的问题
2. 确认是什么引起了这个问题

考虑到模板，我的建议不要把问题归咎于表面的数据。例如，对NULL值的测试可能会失败，因为有些行实际上就是NULL，或者因为那一列不存在。确保你看到了所有的失败，然后定位问题的所在。一旦问题清晰了，那么你就可以开始定位是什么原因导致的。当然，我们不能罗列所有潜在的原因，但是一些普遍的原因如下：

1. 代码的变化（可以问一下团队的人或者看下版本控制记录）
2. 处理崩溃或者连接中断（日志文件）
3. 数据发布延迟（确认你的数据源是否及时发布）
4. 上游的数据变化（检查源数据，与数据生产者确认）。最后，当数据经常获取失败，测试失败经常是由于代码的变化。一种消除非预期值的影响的办法是使数据流水线作为发布过程和CI/CD过程的一部分。让工程师和数据科学家自动化的测试他们的代码，例如，对于the golden data set，如果实际结果与期望不符，那么将不会发布到生产环境。

现在，如何修复问题呢？当然，没有一个统一的方法去修复数据问题，修复问题极度依赖他的实际原因。回头看一下我们对于测试失败的三种根因，我们可以使用下述三种方式来使我们的测试能够通过：

1. 如果你确定数据绝对正确，但是测试却失败了，你需要调整你的用例。
2. 如果数据可修复，一些已知的解决方案是，重新执行你的流水线，可以在遇到连接超时或者资源限制等问题上提高鲁棒性，或者修复你的流水线代码，理论上可以加一些机制，让工程师测试代码来避免相同的问题再次发生。
3. 如果数据崩溃了，你可能要去联系数据生产者来确认。无论如何，直到这个问题被解决，一定有需要你去剔除掉的记录，数据集或者分区。尤其是当你要处理第三方数据时，有时候数据被删了、被改了，不再更新了，也没法在你的测试用例中使用了。

哈哈，真棒。今天又是美好的一天，但你又开始担心你测试通过了，是因为你只是没有测试到正确的东西。相信我，我们不可能对每个可能的数据问题都写成测试用例，在我们遇到它之前，你可能会遗漏一些用例，不论是小的边界用例，还是比较明显的用例。我很高兴的承认，我一旦做一个日常的数据获取流水线，就会发报警，如果记录数显著的下降，那是我们最大的问题。我知道我们流水线的bug是数据bug的两倍，有人抱怨说：“今天流水线执行非常慢”，直到有人看到结果面板上我们今天用户数量飙升。

所以，对于很多未知的问题，我们该做点什么，来是我们的测试更加鲁棒呢？老实说，我们也没有一个很好的办法，但是可以提供一些建议：

1. 用自动的分析工具去生成数据测试用例，为了提升测试的覆盖率，那也许对你不可见。例如，你可能无法考虑到一个数值列的含义，但是一个自动生成的测试会使你的数据更加的鲁棒，对非预期的变化，不直接的断言那一列的最小和最大值。一种选择是将中间的测试放到一个单独的测试套件里，降低报警级别，所以你就能得到有意义的变化通知。
2. 确保团队成员都了解数据测试用例，然后当用例增加或者发生变化的时候，对用例做code review，就像你对待流水线代码一样。这会使关于数据流水线的不确定变得容易并且可以突出出任何用例中的缺陷。
3. 对你的数据做人工检查，可能也是一个办法。自动化测试是很棒，但是我需要声明，对数据的熟悉程度也是一个重要的因素，在如何快速的定位问题上。甚至在没有做测试的时候。最后一步在你数据质量策略中，可以对数据集实现一个定期的认证，来保证运行良好，测试是完整的并且精确的（实际运行）

<测试窝原创译文：译者binger>