现代应用程序开发的一大优点是硬件故障或如何设置RAID等问题是云提供商的担忧。好的云提供商不太可能丢失您的应用程序数据，所以有时有人问我为什么现在备份？这里有一些真实世界的故事。其中一个故事第一个故事来自一个数据科学项目：它基本上是一个庞大而复杂的管道，从正在进行的研究中收集数据，然后以各种方式处理这些数据以提供一些尖端模型。面向用户的应用程序尚未推出，但数据科学家和开发人员团队已经为构建模型及其数据集工作了数月之久。从事该项目的人员有自己的实验工作开发环境。他们将在终端中执行类似exportENVIRONMENT=simonsdev的操作，然后在终端中运行的所有软件都将在该环境中运行，而不是在生产环境中运行。该团队迫切需要推出面向用户的应用程序，以便那些花钱的人可以在几个月内真正看到他们的投资回报。在星期六，一位工程师正试图赶上一些工作。他深夜完成了一个实验，决定收拾东西回家。他启动了一个清理脚本来删除他开发环境中的所有内容，但奇怪的是，这比平时花费了更长的时间。就在那时，他意识到自己忘记了哪个终端被配置为指向哪个环境。（LCTT译注：生产环境删减。）故事二第二个故事来自一个商业网络和移动应用程序。后端有一个由工程师团队运行的微服务架构。这意味着需要协调部署，但使用正式的发布流程和自动化可以稍微简化事情。新代码准备就绪后会被审查并合并到主干中，上层开发人员通常会为每个微服务标记版本，然后自动部署到暂存环境。暂存环境中的版本会定期收集到一个元版本中，在自动部署到生产环境之前由不同的个人签名（这是一个合规环境）。有一天，一名开发人员正在开发一项复杂的功能，而其他开发该微服务的开发人员都同意将他们正在开发的代码提交到主干，因为他们知道它实际上还不能发布。长话短说，并非团队中的每个人都收到了消息，代码进入了发布管道。更糟糕的是，该实验代码需要一种新的方式来表示用户配置文件数据，因此它在推出生产时运行了一个临时数据迁移，破坏了所有用户配置文件。故事三第三个故事来自另一个网络应用程序。这个有一个更简单的架构：大部分代码在应用程序中，数据在数据库中。然而，这个应用程序也是在很大的截止日期压力下编写的。事实证明，添加一个功能来检测此类更改并清理旧数据实际上在发布之前的开发早期很有用，此时彻底更改数据库模式很常见，并且始终只是作为开发环境的临时功能。不幸的是，我们在匆忙构建应用程序的其余部分并将其推出时忘记了这段代码。当然，直到有一天它在生产中被触发。事后分析对任何故障进行事后分析，很容易忽视大局，而最终将其归咎于一些小细节。一个特例是发现某人犯了一些错误，然后责怪那个人。这些故事中的所有工程师实际上都是优秀的工程师（聘请SRE顾问的公司不是那些偷工减料长期聘用的公司），所以解雇他们并更换他们并不能解决任何问题。即使你有100倍的开发人员数量，它仍然是有限的，所以如果有足够的复杂性和压力，错误就会发生。最重要的解决方案是备份，无论您如何丢失数据（包括最近新闻中的热门话题恶意软件），它都可以帮助您。如果你无法忍受没有副本，那就不要只拥有一个。其中一个故事结局很糟糕：没有后援。该项目六个月的数据收集被浪费了。顺便说一句，有些地方只保留每天的快照作为备份，这个故事就是一个很好的例子，说明这可能会出错：如果数据丢失发生在星期六，而你打算在星期一尝试恢复它,那么day的备份只能得到一个星期天的空数据备份。故事二没有那么好，但事实证明要好得多。备份可用，但数据迁移也是可逆的。不好的部分是发布是在推出之前完成的，并且必须在生产站点关闭时对修复进行编码。我讲这个故事的主要原因是要提醒大家，备份不仅仅是灾难性的数据丢失。部分数据损坏也会发生，而且可能会更加混乱。第三个故事不错。尽管有少量数据永久丢失，但大部分数据都可以从备份中恢复。团队中的每个人都为没有标记出极其明显的危险代码而感到非常难过。我没有参与早期开发，但我为恢复数据花费的时间比平时长得多感到难过。通过经过充分测试的恢复过程，我认为该站点应该在总共不到15分钟的时间内恢复在线。但是第一次恢复没有用，我不得不调试它为什么不能用，然后再试一次。当生产站点出现故障并且您需要重新启动它时，每10秒感觉就像一个世纪。值得庆幸的是，老板们比某些人更了解我们。他们实际上松了一口气，因为一场本可以让公司沉没的一次性灾难只导致几分钟的数据丢失和不到一小时的停机时间。在实践中，备份“成功”但恢复失败的情况极为常见。很多时候，恢复测试在小型数据集上运行良好，但在生产规模的大型数据集上却失败了。当每个人都压力重重时，灾难最有可能发生，而生产现场的故障只会增加压力。在适当的时候测试和记录完整的恢复过程是一个很好的主意。
