合成谬误(为何部署到生产环境如此困难)

F5生态系统 | 2017年4月24日

确保DevOps高效交付软件的一项基本原则是“尽早测试,频繁测试”。事实上,构建以及对构建版本进行自动化测试是CI/CD(持续集成/持续交付)的一部分。测试对象不仅包括各个组件,还包括整个应用。

测试驱动开发(TDD)是一种方法,另一种方法则是将单元测试和系统测试直接纳入构建与发布流程。功能测试和回归测试必不可少;在高度敏捷的环境中,通常只需向代码仓库执行一次“提交”即可触发这些测试。

因此,当软件“交付”给负责将其部署到生产环境的人员时,理应已经对其就绪程度有充分信心。

当然,如果真能如此,我也就不会写这篇文章了,不是吗?

软件交付到生产环境时需要跨越一道壁垒(毫无疑问,这道壁垒依然存在),而我们往往正是在这里陷入哲学上所谓的“合成谬误”。这种逻辑谬误通常用于分析论证和证明,但有趣的是,作者 Ali Almossawi 在 《The Book of Bad Arguments》 中恰恰以软件为基础,对这种“错误论证”作出了简单解释(我强烈推荐所有年龄段有志于钻研哲学或成为辩论高手的读者阅读此书):

非形式谬误、无根据的假设、合成谬误与分割谬误

该软件系统中的每个模块都经过了一组单元测试,并全部通过。因此,集成这些模块后,软件系统不会违反这些单元测试所验证的任何不变量。但实际情况是,各个部分集成后,依赖关系会给系统带来新的复杂性,进而可能增加潜在的故障途径。; https://bookofbadarguments.com/ 第46页

现在,在CI/CD流程的最后阶段,软件不一定会陷入这种谬误。它不仅经过了单元测试,还经过了集成测试,以验证这些单元集成为完整“系统”或应用后的表现。

<p>然而,一旦进入生产环境,我们又回到了第三步。不能仅凭这些测试就认为系统会继续按预期运行。这是因为应用的定义已经发生变化:它不仅包括软件和平台,还涵盖了应用正常运行并交付到消费者和企业用户屏幕所需的网络及应用服务组件。</p>

网络和应用服务会影响请求和响应必须经过的数据路径。其中许多服务(但并非全部)实际上可能会以开发人员未曾预料的方式修改这些请求和响应。因此,应用进入生产环境后,即使每项服务和应用组件都经过了严格测试,也仍有可能(而且往往很可能)出现故障、失效或错误。

这是因为,我们在生产环境中陷入了合成谬误。虽然应用开发人员(和DevOps团队)理解这一谬误,并在预生产测试中加以应对,但我们仍常常没有意识到,网络层的集成本质上也是集成,实际上可能会影响整个系统的运行完整性。

答案似乎显而易见:那就在生产环境中测试吧!

但我们不会这么做,你我都心知肚明。因为生产环境是共享环境,在其中进行严格测试会增加共享资源和系统受到连带影响的风险,并可能导致服务中断。服务中断意味着利润和生产力下降,没人愿意为此负责。更省事的做法是,只在生产环境中执行可行的单项测试,等到日后出现故障或实际表现与宣传不符时,再把责任推给开发人员。

归根结底,这正是软件革命逐步席卷生产网络的潜在驱动力之一。过去,要复制并维护一个与生产环境相匹配的测试环境,不仅难度太大,成本也过高。部分共享基础设施价格昂贵,而且占用大量空间。无论从财务还是运营角度来看,复制这样的网络都并非明智之举。

但随着云计算和虚拟化推动软件的引入和广泛采用,人们开始认识到,借助基础设施即代码等理念,复制软件定义的网络不仅成本可控,而且更加容易。不仅如此,还可以复制网络、在其中进行测试,然后将其拆除,从而重复利用资源,为其他应用执行相同的操作。

我们尚未完全实现这一目标,但正在逐步接近。将基于虚拟化(软件)的网络和应用服务集成到CI/CD流水线中,其实际应用程度远超一些人的想象。传统上基于基础设施(网络)的服务,包括负载均衡、应用路由和Web应用安全,正通过集成到容器架构等环境中,与软件构建周期实现高度融合。作为软件解决方案,它们至少可以纳入构建流程的测试阶段,从而增强信心,降低生产环境部署引入故障或错误的可能性。

在此类软件的基础上,应用“基础设施即代码”可进一步推进这一进程。如果能在构建和发布周期中设计并微调策略与配置,随后只需少量更改或无需更改即可将其部署到生产环境,我们无疑将更接近于消除生产环境中存在的组合谬误。

这些服务是应用服务中最以应用为中心的服务。将其更深入地集成到CI/CD测试阶段,各方就越有信心成功部署到生产环境。

因为当前还存在另一个误区,即针对“生产环境”进行测试就等同于测试“生产系统”。这类测试通常并不包括在生产环境中构成数据路径的应用服务,但应当将其纳入测试。这样,我们就能将错误减少到仅剩真正罕见且难以发现的问题,并有足够的时间和资源加以解决。

分享
标签: 2017

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

F5纪念2021年世界艾滋病日
F5生态系统 | 2021/12/01

F5纪念2021年世界艾滋病日

值此世界艾滋病日,F5郑重承诺,将与员工、客户、社区和合作伙伴共同努力,消除社会对HIV感染者仍然存在的污名与偏见。

Thingbot正转变为攻击平台
F5生态系统 | 2018/11/29

Thingbot正转变为攻击平台

Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究,并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用,还被转变为攻击平台,这意味着攻击者可以更充分地利用这个必然增长的市场。

借助F5全新Quick Start,在AWS上快速开展业务
F5生态系统 | 2018/11/20

借助F5全新Quick Start,在AWS上快速开展业务

在AWS re:Invent开幕前,我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。

为什么声明式模型对NetOps自动化至关重要?
F5生态系统 | 2018/04/30

为什么声明式模型对NetOps自动化至关重要?

为什么声明式模型对NetOps自动化至关重要?阅读F5博客,了解基础设施即代码如何简化网络扩展。

开源聚焦:F5基础设施即代码与多云可管理性
F5生态系统 | 2017/11/16

开源聚焦:F5基础设施即代码与多云可管理性

开源聚焦:基础设施即代码与多云。阅读博客,了解模板和Terraform如何简化F5应用服务的部署。

破解IT“无解困局”的答案:私有云
F5生态系统 | 2016/09/12

破解IT“无解困局”的答案:私有云

破解IT“无解困局”的答案:私有云。阅读F5博客,了解本地部署的敏捷性如何化解安全与速度难以兼顾的问题。