软件测试:预生产环境
我最近写了一篇关于为什么现在我们都是分布式系统工程师的文章 。 令我惊讶的是,许多人反对您必须在生产中测试大型分布式系统的观点。
尽管我们所有人一直都在进行生产测试,但似乎在生产中的测试还是很糟糕。
也许我们将其与牛仔工程联系起来。 我们听到“正在生产中进行测试”,并假设这意味着没有单元测试,功能测试或持续集成。
尝试在生产之前抓东西是一件好事,我们也应该这样做! 但是这些事情并不互相排斥。 这是有关生产中测试的一些注意事项。
1.您已经做到了
您已经在产品中测试了很多东西-因为没有其他方法可以测试它们。 当然,您可以旋转各种系统组件或整个系统的克隆,并捕获实际流量以脱机重放(系统测试的黄金标准)。 但是,许多系统太大,太复杂且无法克隆,因此成本高昂。
想象一下,如何尝试创建一个Facebook副本进行测试(及其多个全球分布的数据中心)。 想象一下,试图扩大国家电网的副本。 即使您成功了,接下来您也需要相同数量的客户端,相同的并发,相同的流水线和使用模式等。用户流量的不可预测性使其无法模拟。 即使您可以完美地再现昨天的流量,也仍然无法预测明天的流量。
很容易陷入克隆环境的混乱之中,而错过了真正的重点: 只有 生产就是生产 ,每次部署到那里,您都在测试部署代码+软件+环境的独特组合。 (请问曾经自信地部署到“暂存”,然后再部署“ Producktion”(原文如此)的任何人。)
2.其他人也一样
您无法启动Facebook副本。 您无法提升国家电网的副本。 有些事情不适合克隆。 很好。 您根本无法有效地模仿大小和混乱的品质,这些品质和混乱会弄乱您关心的错误或行为的长长而细小的尾巴。
而且你不应该尝试。
Facebook也不会尝试增加Facebook的副本。 他们对工具进行了投资,这些工具可以使成千上万的工程师每天安全地部署到生产环境中,并观察人们与他们编写的代码进行交互。 Netflix也是如此。 因此,每个有幸克服这个妄想问题的幻想的人,也都应该这样做。
3.可能很好
在某种程度上,测试具有很多价值。 但是,如果您可以用10%到20%的精力来捕获80%到90%的错误( 并且可以) ,那么其余部分将更有用地投入到使系统具有弹性上,而不是防止故障。
你应该定期练习失败 。 理想情况下,每个有权访问生产的人都知道如何进行部署和回滚,或者如何快速进入已知良好状态。 他们应该知道普通操作系统是什么样子,以及如何调试基本问题。 知道如何处理失败并不罕见。
如果您在生产中进行测试,处理失败的情况将很少见。 我说的是这样的事情:“这有没有内存泄漏?” 也许一夜之间将它作为金丝雀在五台主机上运行。 “此功能按计划工作吗?” 在某个时候,只需将其带有功能标记发送出去,这样只有某些用户才能使用它。 类似的东西。 练习运输和解决许多小问题,而不是发布一些大而引人注目的版本。
4.你有更大的问题
您每天都在发送代码,并定期对代码造成自残的损害,并且您无法分辨代码在执行之前,之中或之后的工作。 问题不在于破坏性的东西。 您可以安全地破坏事物。 这是第二部分-不知道它在做什么-这是不正确的。 这个更大的问题可以通过以下方法解决:
- 金丝雀。 自动金丝雀。 带有自动升级功能的自动分级的金丝雀。 多个金丝雀同时飞行!
- 使部署更加自动化,可靠和快速(上限为5分钟是很好的)
- 快速可靠地还原回滚
- 使用分阶段的金丝雀的仪表,可观察性和其他预警信号
- 对关键端点进行端到端运行状况检查
- 选择良好的默认设置,功能标志,开发人员工具
- 教育,分享最佳做法,标准化做法,以简单/快速的方式成为正确的方式
- 从关键路径中取出尽可能多的代码和尽可能多的后端组件
- 限制任何给定用户或更改的爆炸半径
- 探索生产,验证预期的变化是实际发生的情况。 知道正常的样子
这些东西都极大地利用了您的时间。 与暂存和测试环境不同,暂存和测试环境非常脆弱且易碎,并且很难与产品保持同步。
做那些事
对于拥有50人以上的公司,发布工程是系统地投资不足的技能。 您的部署几乎是所有故障的原因,因为它们会给系统注入混乱。 拥有生产的暂存副本将无济于事,它并没有做很多改变(它通俗地称为“看起来就像生产,所以我只是放下了这张桌子……”而添加了一大类问题)。
拥抱失败。 混乱和失败是你的朋友。 问题不在于你是否会失败,这是当你会失败,你是否会注意到。 在这之间是否会因为整个站点都关闭而使所有用户烦恼,还是只会惹恼少数用户,直到第二天早晨您休闲修复它。
从前,这些是可选技能,甚至是专业技能。 不再。 这些是您作为分布式系统工程师的新职业的重要赌注。
精益求精。 可能还好
软件测试:预生产环境