我们只用绿色的食品原料
yobo体育全站app下载零食加工厂,只为您的健康着想
2022-09-28 00:13上一篇:简朴快乐的心态句子,句句唯美走心 |下一篇:没有了
赵亚楠 编译 漫衍式实验室本文内容来自 2015 年的一本小册子 Everything is distributed(下载 Free-OReilly-Books[1]), 其中荟萃了 5篇与性能和运维相关的文章,本文翻译其中第二篇 Everything is distributed[2]。这篇文章思考有一定深度,但部门看法恐怕失之颇偏,好比作者认为漫衍式系统中的故障没有基础原因(There is no root cause)、查找 root cause 多数是徒劳等等。人们应该感应惊讶的并不是天天都有这么多故障,而是天天只有这么少故障。你不应该惊 讶于自己的系统偶然会瓦解,而应该惊讶于它竟然能长时间不堕落地运行。
——Richard Cook2007 年 9 月,76 岁的 Jean Bookout 正在 Oklahoma 一条生疏的门路上驾驶着她的丰田凯美瑞,她的朋侪 Barbara Schwarz 坐在副驾驶的位置。突然,这辆汽车自己开始加速。
Bookout 实验了踩刹车、拉手刹,但都不管用,汽车还是继续加速。最后这辆车撞上了路堤,造成 Bookout 受伤,Schwarz 死亡。
在随后的执法法式中,丰田的状师将事故原因指向此类事故最常见的罪魁罪魁:人为失误(human error)。“人们有时会在开车时犯错” ,其中一位状师宣称。
Bookout 年龄很大了,而且也不是她熟悉的路,因此造成了这场悲剧。然而,近期一个针对丰田的产物可靠性测试却令这件事情有了一个 180 度的大转弯:凯美瑞中的一个软件 bug 导致的栈溢堕落误( stack overflow error)才是此次事故的罪魁罪魁。
下面两方面原因使得这一事件很是重要:此类事故最常见的背锅侠 —— 人为失误 —— 最后确认并不是造成这次事故的原因(这个假设自己就是有问题的[3])这件事展示了我们如何从 一个软件错误导致的小故障或(潜在更大的) 公司营收损失,无缝跨越到了人身宁静的领域要将这件事情往小里说可能也容易:(现在)在某款特定车型搭载的软件中似乎发现了一个常见 bug。但这件事的外延要有趣地多。思量一下现在生长地如火如荼的自动驾驶汽车。自动驾驶消除了人为失误这个背锅侠,那我们获得的结论将是:在许多方面,自动驾驶汽车要比传统汽车越发宁静。
但事实真是这样吗?思量下面的情况:如果发生了完全在汽车自动驾驶系统控制之外的事将会怎样?如果训练汽车识别红绿灯的数据有错误怎么办?如果 Google 舆图让它去做一些显着很愚蠢的事,而且这些事很危险怎么办?我们已经到达了软件开发中的一个特殊点 —— 不管是在技术上还是在社会/组织上,到了这个点我们不再能明白、看到、或控制系统的所有组件 —— 我们的软件正在变得越来越庞大和漫衍式。软件行业自己已经酿成一个漫衍式的、庞大的系统。
我们如何开发和治理那些庞大到无法明白、庞大到无法控制、堕落方式也无法预测的系统?拥抱故障漫衍式系统曾经只是盘算机科学博士和软件架构师的领地,受众很是小。但现在差别了。仅仅因为你在条记本电脑上写法式、无需体贴消息如何通报和锁问题,并不意味着你不需要体贴漫衍式系统:你写的法式提倡了几多对外部服务的 API 挪用?你的代码是跑在 PC 上还是移动设备上——你确切地知道所有可能的设备类型吗?当你的应用正在运行时,它可能遇到哪些网络方面的限制,关于这些你知道几多?当软件到达特定规模时,它会遇到哪些瓶颈,关于这些你又知道几多?在经典漫衍式盘算理论中,我们学到的一件事情是:漫衍式系统经常会发生故障,而且多数是局部而非全局故障。
这些故障不仅难于诊断和预测,而且很难复现——可能是某个特定的第三方数据流没数据了,可能是位于某个你从未听说过的地方的路由器挂掉 了。你永远在同短时故障(intermittent failure)作斗争,这注定是一场失败的战役吗?应对庞大漫衍式系统的方法并不是简朴地增加测试,或者接纳敏捷开发流程,也不是接纳 DevOps 或者连续交付(continuous delivery)。
任何单一的技术或方法都无法阻止类似丰田汽车事故这样的事情再次发生。实际上,类似这样的事情肯定会再次发生。
解决这类问题我们需要拥抱这样一种看法:无法预知的故障种类太多了——我们面临的是一 片庞大而未知的未知海洋;此外,还需要改变我们构建系统时——以及运维现有系统时——的思考方式。漫衍式设计,当地化开发好了,现在我们可以确定的一点是:每个编写或开发软件的人都需要像漫衍式系统工程师一样去思考。
但这句话到底意味着什么?在实际中,它意味着:抛弃那种单盘算机(节点)的思考模式(single-computer mode of thinking)。直到最近,我们才可以将盘算机视为一个相对确定性的工具(a relatively deterministic thing)。
当编写一个在某台机械上运行的代码时,我们能够确定性地假设许多工具,例如,内存查询的方式。但现在已经没有应用还运行在单台机械上了——云就是这个时代的盘算机(the cloud is the computer now),它就像一个生命系统(living system),一直在连续不停地变化,尤其是在越来越多的公司开始接纳连续交付这种新范式的历程中。因此,你必须开始:接受这样的假设:支撑你的软件运行的系统一定会发生故障对为什么会发生故障以及故障可能会以怎样的形式发生做出预案针对这些预案设计数据收集方案这并不是像说一句“我们需要更多测试”那么简朴。
传统的测试哲学中,假定 所有测试用例都是能够形貌出来的,但在漫衍式系统中这一点不再建立。(这并不是说 测试不重要了,而是说测试不再是万仙丹。)当处于一个漫衍式情况、而且大部门故障模式都是无法提前预测也无法测试时,监控就成了唯一的明白应用行为的方式。数据是漫衍式系统的通用语言如果对适才的比喻(庞大系统就像一个生命系统)举行延伸,那在诊断出一小我私家中风后才去寻找病因与在中风前就能及早发现问题显着是两种方式。
你固然可以翻阅病例上的就诊记载,从中看出其实早有中风的苗头,但你更需要的是一个早期告警系统,以及一种在问题刚发生时就能看到并尽可能快地介入处置惩罚的方式。另外,历史数据只能告诉你那里出了问题,而且是局限在特定时间段内的问题。
但在处置惩罚漫衍 式系统相关的问题时,需要体贴的事情要比仅仅 ping 一下服务器通不通多多了。与丈量和监控相关的工具现在已经有许多,这里不会就详细工具展开讨论,而是要告诉你:在检察自己的应用和系统的监控数据的历程中,你会对“直方图通常比平均值更能说明问题”有越来越深的明白,在这个历程中开发者不会再将监控视为纯粹是系统治理员的领域。庞大系统中人的角色无论何等庞大的软件最终都是人写出来的。
任何对漫衍式系统和庞大度治理的讨论最终都必须认可人在我们设计和运行的系统中的角色。人是我们缔造出来的庞大系统中不行支解的一部门,而且很大水平上我们要对他们的多样性(variability )和适应性(resilience )卖力(或对他们缺乏这两种特性卖力)。作为庞大系统的设计者、制作者和运营者,我们受一种厌恶风险(risk-averse)文化的影响,不管我们是否意识到这一点。
在试图(在历程、产物或大型系统中)制止故障的过 程中,为了使自己能够有更多“把控”(control),我们倾向于粗细不分地列出需求(exhaustive requirements)和建立紧耦合(tight couplings),但这种方式经常更容易导致故障,或者发生更懦弱的系统。当系统发生故障时,我们的方式是责备(blame)。我们卤莽地寻找所谓的故障“原因”——实际上,相比于寻找真正原因以制止未来再泛起类似问题,这种所谓的寻找故障“原因”的历程经常只是一个减轻负罪感和寻求心田平静的运动。
这类运动通常会导致人们继续增强对系统的“把控”,而效果是最终的系统越发懦弱。这里的现实是:大部门大故障都是一连串小故障叠加的效果,最终触发了某个事件(most large failures are the result of a string of micro-failures leading up to the final event)。这些故障并没有基础原因(There is no root cause)。我们最好不要再去试图寻找基础原因了,这样做只是在攀缘文化期望(cultural expectations)和强大且根深蒂固的心理本能(psychological instincts)的悬崖峭壁。
20 世纪 80 年月奏效的流程和方法论,到了 90 年月已略显落伍,现在更是完全不适用了。我们正在探索新的领地和模型,以构建、部署和维护软件——以及开发软件的组织自身( organizations themselves)。相关链接:https://vikaskyadav.github.io/Free-OReilly-Books/https://www.oreilly.com/ideas/everything-is-distributedhttps://humanisticsystems.com/2013/09/21/human-error-the-handicap-of-human-factors-safety-and-justice/原文链接:https://arthurchiao.github.io/blog/everything-is-distributed-zh/。
本文来源:yobo体育全站app下载-www.sxcsxhj.com