您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    理想中的运用顺序是如何丧失数据?
    时间:2021-08-04 21:00 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    理想中的运用顺序是如何丧失数据?

    现代运用顺序开发的一大优点是,像硬件缺点或如何设置 RAID 这类成绩是由云提供商操心的。优秀的云供应商不太能够丧失你的运用数据,所以有时我会被讯问如今为什么还要备份?下面是一些理想世界的故事。

    故事之一

    第一个故事来自一个数据迷信项目:它基本上是一个从正在停止的研讨中来搜集数据的庞大而复杂的管道,然后用各种不同的方式处置以满足一些尖端模型的需求。这个面向用户的运用顺序还没有推出,但是一个由数据迷信家和开发人员组成的团队曾经为树立这个模型和它的数据集任务了好几个月。

    在项目中任务的人有他们本人的实验任务的开发环境。他们会在终端中做一些相似 export ENVIRONMENT=simonsdev 的事情,然后一切在终端上运转的软件都会在那个环境下运转,而不是在消费环境下。

    该团队迫切需求推出一个面向用户的运用顺序,以便那些花钱的人可以从他们几个月的投资中真正看到一些报答。在一个星期六,一位工程师试图赶工一些任务。他在早晨很晚的时分做完了一个实验,决议收拾东西回家。他启动了一个清算脚本来删除他的开发环境中的一切内容,但奇异的是,这比往常破费了更长的时间。这时他看法到,他曾经遗忘了哪个终端被配置为指向哪个环境。(LCTT 译注:意即删除了消费环境。)

    故事之二

    第二个故事来自于一个商业的网页和手机运用。后端有一个由一组工程师担任的微效劳体系结构。这意味着部署需求协调,但是运用正式的发布进程和自动化简化了一些。新代码在预备好后会被审查并兼并到主干中,并且高层开发人员通常会为每个微效劳标记版本,然后自动部署到暂时环境。暂时环境中的版本会被活期搜集到一个元版本中,在自动部署到消费环境之前,该版本会失掉各团体的签署(这是一个合规环境)。

    有一天,一位开发人员正在开发一个复杂的功用,而其他开发该微效劳的开发人员都赞同将他们正在开发的代码提交到主干,也都知道它还不能被实践发布。长话短说,并不是团队中的每团体都收到了音讯,而代码就进入了发布管道。更蹩脚的是,那些实验性代码需求一种新的方式来表示用户配置文件数据,因此它有一个暂时数据迁移,它在推出到消费环境时运转,损坏了一切的用户配置文件。

    故事之三

    第三个故事来自另一款网页运用。这个有一个更复杂的架构:大部分代码在一个运用顺序中,数据在数据库中。但是,这个运用顺序也是在很大的截止日期压力下编写的。理想证明,在开发初期,当彻底更改的数据库架构很常见时,添加一项功用来检测此类更改并清算旧数据,这实践上对发布前的早期开发很有用,并且一直只是作为开发环境的暂时功用。不幸的是,在匆忙构建运用的其他部分并推出时,我们遗忘了这些代码。当然,直到有一天它在消费环境中被触发了。

    预先剖析

    关于任何缺点的预先剖析,很容易无视大局,最终将一切归咎于一些小细节。一个特例是发现某人犯了一些错误,然后责怪那团体。这些故事中的一切工程师实践上都是优秀的工程师(雇佣 SRE 参谋的公司不是那些在长期雇佣中偷工减料的公司),所以解雇他们,换掉他们并不能处置任何成绩。即使你拥有 100 倍的开发人员,它依然是有限的,所以在足够的复杂性和压力下,错误也会发作。最重要的处置方案是备份,无论你如何丧失数据(包括来自恶意软件,这是最近旧事中的一个抢手话题),它都能协助你。假设你无法容忍没有正本,就不要只要一个正本。

    故事之一的结局很蹩脚:没有备份。该项目的六个月的数据搜集白干了。特地说一句,有些中央只保留一个每日快照作为备份,这个故事也是一个很好的例子,阐明了这也会出错:假设数据丧失发作在星期六,并且你预备在星期一尝试恢复,那么一日备份就只能失掉星期日的一个空数据备份。

    故事之二并不算好,但结果要好得多。备份是可用的,但数据迁移也是可逆的。不好的部分是发布是在推出前完成的,并且修复任务必须在消费站点封锁时停止编码。我讲这个故事的主要缘由是为了提示大家,备份并不只仅是灾难性的数据丧失。部分数据损坏也会发作,而且能够会愈加混乱。

    故事之三还好。虽然大批数据永世丧失,但大部分数据可以从备份中恢复。团队中的每团体都对没有标记极端清楚的风险代码感到十分忧伤。我没有参与早期的开发,但我觉得很蹩脚,由于恢双数据所需的时间比正常状况要长得多。假设有一个经过良好测试的恢复进程,我以为该站点应该在总共不到 15 分钟的时间内重新上线。但是第一次恢复没有成功,我不得不调试它为什么不能成功,然后重试。当一个消费站点宕机了,需求你重新启动它,每过 10 秒钟都觉得过了一个世纪。值得庆幸的是,老板们比某些人更能了解我们。他们实践上松了一口吻,由于这一场能够使公司沉没的一次性灾难只招致了几分钟的数据丧失和不到一个小时的停机时间。

    在实际中,备份“成功”但恢复失败的状况极为普遍。很多时分,小型数据集上停止恢复测试是可以正常任务的,但在消费规模的大数据集上就会失败。当每团体都压力过大时,灾难最有能够发作,而消费站点的缺点只会添加压力。在时间适宜的时分测试和记载残缺的恢复进程是一个十分好的主意。

    【编辑引荐】

    大数据“杀熟” 今先行不通了

    在线考试管理系统【附源码】【附开发工具】

    零基础入门学习Python web前端开发视频教程 (三)

    Oracle数据库晋级解密视频课程【李全新讲师地下课】

    WSL:在 Windows 系统中开发 Linux 顺序的又一神器

    (责任编辑:admin)