导致惨重代价的运维事故02

导致惨重代价的运维事故02

OVH数据中心失火
2021年3月10日,欧洲云计算巨头OVH位于法国斯特拉斯堡的机房近日发生严重火灾,该区域总共有4个数据中心。
火灾持续6个小时才被扑灭,发生起火的SBG2数据中心被完全烧毁,共360万个网站下线。

Salesforce全球大宕机
2021年5月11日,Salesforce的服务宕机,持续5个小时。
事故原因,官方反馈为“工程师尝试通过脚本变更DNS配置,但脚本执行超时失败。但不幸的是,这个脚本一直在各节点扩散,最终导致全线崩溃”

访问量激增,导致各类一码通服务宕机
2021年12月20日,西安“一码通”崩溃。
2022年1月4日,西安“一码通”崩溃。
2022年1月10日,广州“粤康码”崩溃。
2022年3月11日,上海“随申码”崩溃。

Facebook严重宕机
2021年10月5日,Facebook旗下应用出现大面积故障,波及到Facebook、Messenger、Instagram和WhatsApp等几乎所有产品。
此次宕机长达7个小时,影响到全球数十个国家和地区的几十亿用户。
官方给出的事故原因为:“协调数据中心之间网络流量的主干路由器的配置变化导致了通信中断,由此对我们数据中心的通信方式产生了连带影响,使我们的服务陷入停顿”

小插曲:
Facebook股价盘中暴跌6%,市值减少数百亿美元,扎克伯格个人财富一日蒸发逾60亿美元。
宕机期间,大量用户涌向了Twitter、Telegram等其他应用,又进一步导致这些应用程序的服务器崩溃。

B站713事故
2022年7月13日,B站崩了5个小时。
根据B站的事故分析报告,是SLB故障导致
本次SLB故障,是OpenResty中,计算gcd的lua代码传入了0值,被lua判定为nan,陷入了死循环
这段lua代码已经稳定运行了一段事件,但一个新发布模式,却触发了这个bug

Twitter事故
2022年7月14日,Twitter崩了1个小时。

小插曲:
其实对于Twitter的崩溃,大家都已经习惯了,每年不崩溃几次,都感觉不正常。

阿里云香港机房重大事故
2022年12月18日,由于香港可用区C机房冷却系统失效,现场包间温度逐渐升高,导致一机房包间温度达到临界值触发消防系统喷淋,电源柜和多列机柜进水,部分机器硬件损坏,整个处置过程超过15小时。
事故后,阿里云总裁、CTO都被更换。

唯品会机房宕机事故
2023年3月29日凌晨,唯品会南沙IDC冷冻系统故障,导致机房设备温度快速升高宕机,造成线上商城停止服务
宕机事件达到12小时,损失超亿元,影响客户达800万,唯品会将此次故障判定为P0级故障。
事故后,基础平台部门负责人被免职。

腾讯云机房事故
23年3月29日凌晨,腾讯云广州五区部分云服务异常,导致微信、QQ、支付等核心功能受到影响,故障在当天中午基本恢复。
事故原因,官方反馈为“本次事故由广州电信机房冷却系统故障导致”。

微软Azure故障
2023年5月24日,微软Azure DevOps在巴西的一处scale-unit发生故障,导致宕机约10.5个小时。
导致该中断的原因为一个简单的拼写错误,最终导致17个生产级数据库被删除。

语雀重大服务故障
2023年10月23日,语雀出现重大服务故障,持续7个多小时才完全恢复。
故障原因为新的运维升级工具bug,导致华东地区生产环境存储服务器被误下线,造成大面积服务中断。

阿里云全球故障
2023年11月12日,阿里云爆发全球故障,阿里产品全线崩溃,几乎影响全部云用户,持续事件达3.5小时。
故障原因,具说是鉴权服务出了问题。

小插曲:
两周后,在2023年11月27日,阿里云再次遭遇了近两小时的中断,影响到中国和美国的客户。
然后当天晚上,滴滴就来了个大的。

滴滴故障
2023年11月27日晚间,滴滴崩溃,APP功能无法使用,直至第二天才陆续恢复,故障事件超过12小时。
故障原因,官方反馈说是“底层系统软件发生故障”。

腾讯云崩溃事件
24年4月8日,由于API服务新版本向前兼容性考虑不够和配置数据灰度机制不足,导致1957个客户报障,故障持续90分钟

微软蓝屏事件
24年7月19日,使用了Windows操作系统的设备大面积蓝屏,导致850万设备受到影响。
故障原因是,微软安全供应商CrowdStrike推送了错误的软件配置。

阿里云新加坡机房火灾
24年9月10日上午,阿里云新加坡可用区C数据中心发生火灾,导致主要科技公司服务中断。
火灾原因已确定为锂电池爆炸,持续36小时以上。
此故障,影响到了TikTok、Lazada等多家用户。

============================================================
注:本文主要是整理了运维导致的惨痛代价,并没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)

故障恢复

故障恢复
之前做个一个折中的处理方案,类似于快速接收,批处理,反馈处理状态。之所以这样处理,是因为合作机构IT水平参差不齐,而且配合程度不高,如果把数据接收+处理+反馈放到一起的话,一旦有错误,就要麻烦对方重新推送最新数据,或者自己脚本重新处理数据,而且一天峰值十分明显,峰值时根本来不及处理数据。
1、数据接收阶段,采用了快速失败策略。一旦数据落库文件落盘,就返回成功,反之失败。
2、数据处理阶段,会进行重试,三次后进入失败队列
3、进入失败队列后,会通知运维和开发,去看下数据什么问题。有时会把文件手工处理一下,再重试。如果实在无法处理,就线下通知合作方相关人员如何修改数据。
4、数据处理成功后或彻底失败后,发送处理结果给合作方。

这种方式,在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时,可以尝试一下。后面自己做起来后,就可以要求对方,做一些统一要求了。

限流和降级
之前在一个大量读写小文件服务的入口处,用过令牌桶限制访问量,防止IO过高。问题是每秒要发放发放多少令牌,最后是慢慢试出来的。

后面微服务时代就是中规中矩的限流,降级和熔断了。但降级和熔断,是通过HTTP状态码进行判断的,有些后知后觉了。

零信任网络
一个团队去完成一个任务,如果彼此信任,相互配合就会很流畅,沟通成本会很低,任务推进也会很顺畅。比如几个知根知底的伙伴去创业,一个眼神可能就懂了。
一群互不信任的人去完成一个任务,哪怕每个人都很努力,但经常感觉别人掣肘,吵来吵去,任务止步不前。一个流动率高,甩锅成风的组织,便是如此。

代码也是如此,如果我们假设代码是可信的,直接拉取镜像就行了。
如果假设代码是不可信的,开发提交代码后,要各种引擎扫描,扫描通过后,流水线打包镜像。同时还要提交各类材料如测试报告,越权测试报告,渗透测试报告,压力测试报告,代码审核报告等等相互佐证代码没有问题,然后发布。
这样先不说要多少资源支持,单说发布,就从十几秒变成了十几分钟,甚至几十分钟。

服务也是如此,如果假设服务是可信的,不要加任何控制,就可以相互访问。
如果假设服务不可信,就要各种验证,网络端口是否允许访问,token是否正确,双向证书过了没,是否有服务访问权限,是否有数据权限,是否符合流量控制要求等等。
先不说做需要多少资源支持,单说服务性能,从几十毫秒一下到了几百毫秒。

那做这些值吗?值!
但要符合自己的情况,不能太过,绑了自己的手脚!

零信任网络安全
我认为边界安全模型和零信任模型会长期共存,边界安全模型毕竟更成熟,而且在资源隔离程度上,远高于零信任模型。istio们并没有提供边界模型的一些组件,比如杀毒,比如入侵检测,比如蜜罐,比如上帝视角的规则控制等。而且istio们本身也有被入侵的可能,所以不能只依赖这一个层面的安全管控,而是立体的安全管控。

可观测性
单体程序时代,类似于一个办公大楼,有了问题,告诉管理员门牌号和具体事情就行了,管理员就可以乘电梯过来解决问题。
只要在日志里输出一下,哪个方法,做了哪个任务或出了什么问题,用日志工具就可以统计到处理速度或快速定位到问题了。

微服务时代,类似于管理城市物流。要提出问题,我们必须说明,那条街,哪个门牌号,几单元,有什么需求。工作人员上门时,要看下地图,什么路线过去最快,遇到堵车怎么办,小区不让进怎么办,然后才能到顾客这边提供服务。数据链路就像城市地图,监控就像地图上的流量,而日志必须还原到这张地图上,才知道哪个交叉口或哪个大楼哪里出了问题。
所以,我们要花必要的精力,去做全链路,绘制这个地图。所以我们要收集度量信息,去监控哪里流量红了,哪里彻底堵车了。只凭日志,是无法快速定位问题的,这个交叉口堵车,问题可能出在三公里之外,一个交叉口一个交叉口查过去,太慢了。

流量大了,堵车是必然的。只有做好可观测性,才能快速疏导交通,做到事半功倍。

日志
个人觉得,如何正确的记录日志,用何规则做日志分级,要记录哪些东西,比用什么技术栈分析日志重要的多。老师能否分享一下,日志规范如何在团队中落地呢?

有两种情况,多记录一些日志有好处的。一类是部署于第三方的系统,宕机时要多记录日志,最好有dump文件,利于排查问题。第二类是跨公司做集成对接,输入输出一般都会记得很清楚,为了防止扯皮。

聚合度量
主要监控了服务请求,JVM,服务器的一些指标。但服务请求方面,做的还很基础,有较大提升空间。

导致惨重代价的运维事故01

导致惨重代价的运维事故01

光大证券事件
2013年8月,光大证券在向客户演示时连接了正式数据库,导致股市震荡,被罚款5.2亿。

宁夏银行删库事件
2014年7月,宁夏银行在季末结算业务量较大的情况下,因备份系统异常导致备份存储磁盘读写处理严重延时,备份与主存储数据不一致。工程师在采取中断数据备份录像操作后,造成生产数据库损坏并宕机。造成38小时,700多定点医疗机构和定点零售药无法使用医保支付。

小插曲,2014年5月宁夏银行使用CDP软件进行了一场容灾演练,曾完成800公里的容灾切换。

携程删库事件
2015年5月,携程无法访问。官方反馈是由于运维工程师误操作,误删生产环境,而且重新部署后还是会被删除。经过十几小时努力,最终恢复成功。

小插曲,携程挂掉后,导流给了艺龙,结果艺龙也挂了。

Gitlab删库事件
2017年2月,Gitlab运维人员,在应对前一晚的DDOS攻击后,发现备库复制数据缓慢,并无法解决。最终决定删除备库,重新开始复制。但在十分疲倦的情况下,工程师误删了300G的生产数据,由于备份机制设置不合理,最终导致20多小时系统宕机,707位用户丢失数据,5,037项目丢失,受事故影响的用户基数不到1%。
我们可以看到的问题有:
1、审核和监控全部备份策略:虽然Gitlab号称有五重备份机制:常规备份24小时做一次、自动同步、LVM快照24小时做一次、Azure备份对数据库无效、S3备份。但没有一个可靠地运行或设置,而且备份失败也没有良好的预警机制。最终只能基于LVM的备份(最近6小时以前),还原了6 小时前的备份。
2、积极演练应对重大问题,保证备库是随时可用的,应急时也应该有序进行
3、数据中心之间数据传输要考虑好,本次数据传输也花费了较长时间
4、防止人肉运维,谨防开夜车,脚本工具化自动化。人总归会出错,而且总是在最不该发生的时候出错。
5、Gitlab本次事故发生后,公开透明的处理方式,值得大家借鉴和尊重。

AWS删服务器事件
2017年3月,AWS服务异常,经过4个多小时才恢复正常。
原因为:一名S3工程师根据预先编写的playbook执行一条命令时,输入命令时输错了一个字母,结果删除了一大批本不该删除的服务器。

verelox.com删库事件
2017年6月,荷兰云主机厂商verelox.com,一前任管理员,恶意报复公司,删除全部用户数据,并擦出了多数服务器上面的内容。

链家删库事件
2018年6月4日,链家网财务系统数据被删,这9TB数据,包括了该公司成立以来所有的财务数据。
经过紧急修复,该批数据最终得以恢复。
事件原因:由于管理制度漏洞百出,一名数据库运维人员轻易获得了不应有的高权限。该工程师与公司起了争执,修改MAC地址后,直接删库。

小插曲:
该工程师,只改了MAC地址,但并未变更主机名、IP,被系统日志记录。
修改MAC地址,也用了第三方软件,该软件日志几乎坐实了其攻击行为。
而且删除的数据,很容易就被恢复了,只花了18万。技术方面,及其不专业。
最终,该工程师拒不配合调查,也不认罪,最终被判刑7年。

广西移动扩容事件
2017年9月,华为工程师在进行广西移动扩容时,误将HSS设备的用户数据格式化,导致广西移动损失80万用户数据。

顺丰删库事件
2018年9月,顺丰一个高级工程误删线上库,然后跑路。导致部分服务无法使用并持续近10小时。

郑大附一数据库事件
2018年12月24日,郑大附一的一名工程师,由于操作不当导致HIS库被锁表,让该医院门诊业务停止2小时。
该工程师被判刑5年6个月。

微盟删库事件
2020年2月,微盟删库事件,导致系统6六天无法访问,市值蒸发28亿,预计赔偿金1.5亿,官方反馈是内部员工恶意行为导致。
数据最后在腾讯云的帮助下得以恢复。

小插曲:
小道消息,该工程师欠了网贷无力偿还,而且当天喝了不少酒。
该工程师被判刑6年月。

============================================================
注:本文主要是整理了系统运维导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)

导致惨重代价的Bug

导致惨重代价的Bug

纪念“瞳”解体事件

千年虫事件
在上个世纪,软件行业初期,计算机硬件资源十分昂贵,很多软件为了节省内存会省略掉代表年份的前两位数字”19”,或默认前两位为”19”。按这个规则,1999年12月31日过后,系统日期会更新为1900年1月1日而不是2000年1月1日,这样可能意味着无数的灾难事件,导致数据丢失,系统异常或更加严重的灾难。

幸好大家发现的早,最终全球花了上亿的美元用来升级系统,没有引起毁灭性后果。

水手1号探测器
1962年7月28日,水手1号空间探测器发射升空,但由于程序编码中的轨道计算公式是错误的,导致火箭轨道偏离预定路线。最终在大西洋上空自爆。

南极臭氧层测绘事件
1978年,NASA启动臭氧层测绘的计划。但在设计时,用于该计划的数据分析软件忽略了和预测值有很大差距的数据。直到1985年,才发现南极洲上方的臭氧层空洞,但是英国科学家先发现的。直到NASA重新检测它们的数据,才发现这一错误。在修正错误后,NASA证实南极臭氧层的确有个很大的空洞。

反导系统误报事件
1980年,北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报。

1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。

幸亏这些误报没有激活“核按钮”。在上述两个案例中,如果对方真的发起反击,核战争将全面爆发,后果不堪设想。

辐射治疗超标事件
1985到1987年,Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故,其罪魁祸首是医疗设备软件的Bug。据统计,大量患者接受高达100倍的预定剂量的放射治疗,其中至少5人直接死于辐射剂量超标。

AT&T网络终端事件
1990年1月15日,纽约60万用户9个小时无法使用电话服务。原因是,AT&T交换机从故障中恢复后,就会发送一条特殊的小时给临近的设备,但在新版本软件中,这条消息会导致电话交换机重启。于是,每6秒,所有交换机都会重启一次。最后,将程序换回了上一个版本,解决了问题。

宰赫兰导弹事件
在1991年2月的第一次海湾战争中,一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地,当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。

在后来的调查中发现,由于一个简单的计算机bug,使基地的爱国者反导弹系统失效,未能在空中拦截飞毛腿导弹。当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。

对一般人人来说,0.33秒是微不足道的。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说,这是灾难性的——侯赛因飞毛腿导弹空速达4.2马赫(每秒1.5公里),这个“微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中,雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。

Intel奔腾处理器浮点错误
1993年。Intel奔腾处理器在计算特定范围的浮点数除法时,会发生技术错误。Intel最终花费了4.75亿美元来为用户置换处理器。

飞行事故
1993年,瑞典的一架JAS 39鹰狮战斗机因飞行控制软件的Bug而坠毁。

1994年,苏格兰一架吉努克型直升飞机坠毁,29名乘客全部罹难。然而最初指责声都指向飞行员,但后来有证据表明,直升飞机的系统错误才是罪魁祸首。

死Ping
1995-1996年,由于没有进行足够的校验,在收到特殊构造的Ping包时,会导致Windows设备蓝屏并重启。

阿丽亚娜5型运载火箭事件
1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。(原计划将运送4颗太阳风观察卫星到预定轨道)

阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,4亿美元变成一个巨大的烟花。

火星气候探测者号事件
1999年9月,火星气候探测者号在火星坠毁。火星气候探测者号的目的为研究火星气候,花费3亿多美元。探测者号在太空中飞行几个月时间,接近火星时,探测器的控制团队使用英制单位来发送导航指令,而探测器的软件系统使用公制来读取指令。这一错误导致探测器进入过低的火星轨道(大约100公里误差),在火星大气压力和摩擦下解体。

火火星极地登陆者号件
1999年12月,火星极地登录者号在火星坠毁,原因是设计缺陷导致其在达到行星地表之间就关闭了主引擎,最终撞毁。

辐射治疗超标事件
2000年11月,巴拿马美国国家癌症研究所,从美国Multidata公司引入了放射治疗设备及软件,但其辐射剂量计算值有误(软件本身运行医生画四个方块来保护患者健康组织,但医生需要五块,于是医生自己想办法欺骗了软件,殊不知该操作方式将放射剂量进行了加倍处理)。部分患者接受了超标剂量的治疗,至少有5人死亡。后续几年中,又有21人死亡,但很难确定这21人中到底有多少人是死于本身的癌症,还是辐射治疗剂量超标引发的不良后果。

北美大停电事件
2003年8月,由于GE的一个监控软件,没有有效的通知操作人员有一个地方电站断掉了,电力缺口导致了多米诺骨牌效应,最终导致了加拿大安大略州和美国八个州断电,影响到了5千万人,总损失达60亿美元。

丰田普锐斯混合动力汽车召回事件
2005年10月,丰田宣布召回16000辆锐斯混合动力汽车。这次召回的原因是“发动机熄火意外”及“警示灯无故开启”。本次召回的根本原因不是硬件问题,而是汽车嵌入式编程代码的问题。

东京证券交易所事件
2005年12月,J-COM公司上市,开盘价格61.2万日元一股,日本瑞穗证券的一个交易员接到了客户委托“请以61万日元的价格,卖出1股J-Com的股票”。但交易员输入成了“以每股1日元的价格,卖出61万股”。由于交易系统限制,交易系统自动调整为“以57万日元,出售61万股”。

2分钟后,操作员发现操作失误,执行了3次撤单操作全部失败。J-COM股票一路狂跌,瑞穗证券拼命拉高到77.2万日元,仅此一项,瑞穗证券一共损失了约270亿日。但仍引起了很大的连锁效应。

更大的问题是,J-COM的股票一共只发行了14000多股,但卖出去的可远不止这么多。最后经过协商,瑞穗证券用每股91万日元的价格,现金清算了股民手上的9万多股,全部损失,扩大到400多亿日元。

然后瑞穗证券状告东京证券和富士通,官司打了十年。最后判定,以当日瑞穗证券电话联络东京证券的时间点为分界线,之前全部由瑞穗证券承担,之后产生的损失由东京证券承担70%瑞穗证券承担30%。富士通及程序员没有收到罚款。

恩,痛定思痛,决定开始开发了新的交易系统,开发商仍然是富士通。

Gmail故障
2009年2月份Google的Gmail故障,导致用户几个小时内无法访问邮箱。据Google反馈,故障是因数据中心之间的负载均衡软件的Bug引发的。

温州7.23动车事故
2011年7月23日,甬温线浙江省温州市境内,由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故,造成40人死亡、172人受伤,中断行车32小时35分,直接经济损失近2亿元。

上海铁路局事后反馈,“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯。

骑士资本事件
2012年8月1日,骑士资本的技术人员,在1台设备中部署了错误版本的应用(一共8台,7台正常),该设备触发了n年前的代码,在一个小时内就执行完了原本应该在几天内完成的交易,导致错误的买入卖出,直接将公司推向了破产的边缘,投资人紧急注资4亿美元才得以幸免,最终损失高达5亿美元。

12306订票助手拖垮GitHub
2013年1月15日,GitHub受到中国大陆的DDOS攻击,网站几乎被拖垮。

最后发现,是由于春运期间,各大浏览器厂商集成了一位网友iFish(木鱼)的“订票助手”插件,帮助春运大军抢票回家。但该软件的早期版本,直接引用了GitHub的Raw File而不是静态文件,并且在访问文件失败时,每5S会重试一次。这样,抢票大军的每一个人,没5S都会向GitHub发送一次请求,造成对GitHub的DDOS攻击。

OpenSSL Bleeding Heart漏洞
2014年4月,谷歌和芬兰安全公司Codenomicon分别报告了OpenSSL存在重大缓冲区溢出漏洞。在OpenSSL心跳扩展的源码中,没有去校验缓冲区的长度,导致攻击者可以直接获取网站的私钥信息。这次漏洞的影响面很广,几乎所有厂商都在打补丁和更新私钥及证书。

Twitter丢失400万活跃用户
2015年2月,Twitter在在季度财报中指出,苹果iOS8升级后出现的漏洞让Twitter至少损失了400万用户。首先是iOS8和 Twitter的兼容性问题流失了100万用户,Safari流览器升级后的共用链接功能无法自动升级,这一问题流失了300万用户,另外还有100万iPhone使用者在升级系统后忘记了Twitter密码,导致无法使用而离开了Twitter。

日本天文卫星“瞳”解体事件
2016年03月,日本天文卫星升空不到一个月(仅正常工作3天),就解体了,该卫星造价约19亿人民币,并搭载了多国的观测设备。
首先,由于干扰,追星仪发生了故障,启用了备用的陀螺仪。
但是,陀螺仪也有故障,导致没有旋转的卫星开始加速旋转,并达到阀值。
然后,为了阻止卫星旋转,卫星开始反向喷气,但程序员把喷气的方向搞反了,卫星越转越快,最终解体。

============================================================
注:本文主要是整理了系统Bug导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)
*从计算机诞生以来,众多失败的软件项目,没有加到列表中
*1982年,苏联天然气管道爆炸事件,涉及植入恶意代码,没有加到列表中