限制部署的爆炸半径

复杂的应用程序环境通常需要进行部署，以使事情顺利运行。但部署，尤其是微服务更新，可能会有风险，因为你永远不知道会出什么问题。

在本文中，我们将解释部署中可能出现的问题，以及如何限制爆炸半径。

什么是爆炸半径？

爆炸半径是爆炸周围可能发生损坏的区域。在部署环境中，爆炸半径是部署可能产生潜在影响的区域。

例如，如果你将一个新功能部署到网站，爆炸半径可能是网站本身。但如果你正在部署一个新的数据库模式，爆炸半径可能是数据库和所有使用它的应用程序。部署的问题是，它们通常具有无限的爆炸半径。

爆炸半径几乎不可避免，但无限的爆炸半径意味着任何事情都可能出错并引发问题。这很糟糕。

什么导致爆炸伤害？

规划不力——仓促开发和计划部署往往是爆炸半径无限大的主要原因。当你匆忙部署时，你更容易犯错误。这些错误可能包括忘记更新文档、在生产过程中意外破坏了某些内容，或者没有给其他相关方（如从属服务所有者）一个反映和响应部署的机会。

沟通不畅——你是否有过这样的经历，应用程序无法正常工作，另一个团队却进行了计划外部署，并且没有通知你正在进行？告诉某人正在部署而没有给他们足够的时间来准备是另一个麻烦的来源。不沟通是灾难的根源。

缺乏测试——要限制部署的爆炸半径，最重要的事情之一是在将其推向生产之前对其进行彻底测试。这意味着在配置为尽可能接近生产环境的登台环境中进行测试。它还意味着要进行单元测试和端到端测试。

通过在部署代码之前对其进行彻底测试，可以发现任何潜在问题，并在它们在生产中造成问题之前进行修复。

需求不完整或不明确——如果开发人员不得不猜测需求是什么，他们很可能也没有明确的测试计划。不明确的需求可能导致代码在开发中有效，但在生产中失效。此外，它还可能导致代码与其他系统不兼容，以及导致功能无法满足用户的需求。

为了避免这种情况，请确保在开始开发之前有一套清晰完整的需求。精确的需求将有助于确保开发人员了解他们需要构建什么，并且他们可以在部署之前正确测试它。

配置错误——部署出错的最常见方式是发生配置更改。例如，你可能会更改数据库设置并忘记更新应用程序。或者你可能会改变服务网站的方式，并断开所有其他网站的链接。配置更改通常是部署出错的原因，因为它们会影响系统的许多不同部分。

人为失误——人会累，会犯错，会忘记事情。在部署复杂系统时，存在很大的错误空间。即使是最有经验的工程师也会犯错。

环境均等问题——有时，事情会在生产中发生变化，并且不会影响到测试和开发环境。当你去部署时，环境不平等可能会导致问题。应用程序可能无法在新环境中工作，或者可能没有所有必要的文件和配置。或者，环境中有一些可怕的东西没有经过测试，没有人知道它们为什么会出现。

软件问题——最后，软件本身可能会出错。软件很复杂，通常很难预测它在不同环境中的行为。例如，你可以在开发环境中测试软件，并且工作正常。但当将其部署到生产环境中时，可能会产生意想不到的后果。例如，如果代码是“意大利面”，并且紧耦合或难以维护，那么可能会遇到部署问题。

很多事情都可能出错！但是否有办法限制爆炸半径呢？

如何限制爆炸半径

有几种方法可以限制爆炸半径。

计划和时间表——通过建立定期的部署节奏和流程，让团队取得成功。一致性将最大限度地减少人为错误的可能性。

当每个人都知道什么时候需要部署，或者在特定情况下需要什么时，部署将更加顺利。你还应该计划出问题时该怎么办。能回滚吗？是否有备份？

尽量沟通——规划部署的一部分是确保所有责任方和受影响方得到充分的信息，并有时间进行审查、反思和回应。沟通包括向所有用户发送一封电子邮件，通知他们即将进行的部署，并告诉他们会发生什么。此外，这意味着要与部署人员进行沟通。给他们足够的时间来准备、复习、练习和清理日历。宁可提供太多信息，也不要提供太少信息。

了解风险——最重要的准备方法是了解风险。首先，需要知道什么可能出错，以及它会如何影响系统。只有这样，你才能采取措施防止这种情况发生。

自动化——限制爆炸半径的另一种方法是尽可能多地自动化部署过程。如果有什么东西可以自动化，那就去做吧。例如，自动化部署将有助于确保一致性和准确性。这样，可以确保所有内容都被覆盖，正确完成，并且不会忘记任何事情。

有许多不同的工具可帮助自动化部署。选择最适合需求的一个，然后尽可能多地自动化流程。

使用内部开发人员门户——内部开发人员门户组织了可能需要的许多信息，以帮助限制爆炸半径。

例如，它可以帮助你了解依赖于你的服务的下游服务，识别这些服务的所有者，查找相关文档，并将有关这些服务的关键指标可视化。这使你能够知道在部署之前与谁进行通信以及如何联系，提供有关这些下游服务如何工作的上下文，并提供在测试期间监视这些服务的场所（假设内部开发人员门户在环境级别上具有基础设施意识）。

内部开发人员工具还可以通过提供对版本控制信息的访问来帮助你了解风险，这些信息使你能够访问更改的内容、更改的时间以及更改者。通过这种方式，你可以识别可能引入风险的任何更改，并采取措施减轻风险。

原文链接：

https://thenewstack.io/limiting-the-deployment-blast-radius/