数字技术 数据爆炸_大爆炸部署的风险和逐步部署的技术

数字技术 数据爆炸

如果您需要说服管理层，为什么最好在多个阶段中部署更大的更改并将其逐步推向客户，请继续阅读。

部署许多更改是有风险的。 因此，我们希望以最小化对客户和公司造成伤害的风险的方式来部署它们。 部署可以一次全部（也称为大爆炸）方式进行，也可以逐步进行。 在这里，我们将争辩为更渐进（“逐步”）的方法。

大爆炸还是分步部署？

大规模部署似乎是自然而然的事情：开发和测试完整的解决方案，然后立即替换当前系统。 但是，它有两个关键缺陷。

首先，它假定可以通过测试发现大多数缺陷。 但是，由于测试/产品环境的差异，未知的依赖性以及典型的大型系统的庞大规模，总会有直到生产部署甚至应用程序在生产中运行一段时间后才发现的问题（ 甚至适用于飞机 ）。 更改的零件越多，这些生产缺陷将同时发生的越多。 逐步部署使得可以逐一发现并处理它们。

其次，部署越复杂，人为错误的可能性就越高，即部署本身很可能是严重缺陷的根源。

大规模部署的一些缺点更加详细：

1. 复杂性：大爆炸部署要求互相依赖的“可移动部件”，提供人类的错误（即会有错误）一个巨大的机会，许多人的协调和。
2. 大量时间：这样的部署需要大量时间（通常还比计划/预期的时间还要长），因此，当用户无法使用系统时，将导致大量的停机时间。
3. 艰苦的故障排除：相互依赖的零件网络会同时发生变化，同时可能还会更改基础架构（即它们之间的连接），因此很难找出缺陷的来源，从而大大增加了检测时间并纠正缺陷，同时也增加了人们互相踩踏和“紧急修复”的风险，这些问题可能引起更多的问题，而不能消除或不够好（因为回滚加速了Knight的垮台 ）。
4. 回滚可能是不可能的，或者与部署本身一样既费时又冒险，从而增加了缺陷的影响并引发了更多的人为错误。
5. 影响：将所有内容同时部署到所有用户意味着每个人都会受到潜在缺陷/错误/错误的影响。
6. 长期冻结：所有开发完成后，所有所有组件都需要一起测试，这需要花费大量时间冻结代码，并且数周之内无法进行任何修复和更改。

风险缓解

良好的部署计划的目标是减轻部署的风险并使之达到可接受的水平。 风险有两个方面：缺陷的可能性和缺陷的影响 。 下表显示了可能的措施如何影响它们：

减少缺陷概率	减少缺陷影响
测试	逐步部署 逐步将用户迁移到新版本（每1000个中的f.ex.1个版本或特定子集） 回滚机制
	=>这些也可以减少发现和修复缺陷的时间

逐步部署的实践

启用逐步部署：使用并行更改和其他持续交付技术，可以彼此独立地部署更新的组件，并打开/关闭新功能，以及切换当前使用的组件依赖的版本。 （并行更改–保留旧代码和新代码，并能够使用其中的一个和另一个–至关重要。另外请注意，并行更改也适用于数据–您将需要逐渐发展数据模式，并同时保留新旧数据。在一段时间内同时）。

启用回滚。 之前的措施（逐步部署）使切换到先前版本的依赖项或切换回旧代码也可以轻松地回滚更改。

逐步将用户迁移到新版本，即最初仅向一小部分用户公开新版本，然后增加该子集，直到每个人都使用它为止。 可以这样做。 通过仅部署到一部分服务器并将随机的/特定的用户子集发送到新服务器，但是如果您只有一台计算机，则还有其他方法。 （参见f.ex.我的文章Webapp蓝绿色部署，不中断会话/具有HAProxy的后备功能 。）

监视–确保您能够监视整个系统中的用户流，并在企业发出愤怒呼叫之前很久就及早发现任何异常和错误。 Logstash ，Google Analytics（分析）（带有来自JavaScript的自定义事件），通过现有服务之一或自定义解决方案进行的客户端错误日志记录等工具非常宝贵。

参考： The Holy Java博客上的JCG合作伙伴 Jakub Holy提出了大规模 部署的风险和逐步部署的技术 。

翻译自: https://www.javacodegeeks.com/2014/02/the-risks-of-big-bang-deployments-and-techniques-for-step-wise-deployment.html

数字技术 数据爆炸