neohope – Page 14 – Neohope的网络笔记

About neohope

一直在努力，还没想过要放弃...

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

Posted on 2024/01/14 by neohope — No Comments ↓

2024年12月：OpenAI故障
事件经过：12月11日，OpenAI发生故障，影响依赖其服务的用户及企业。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰AI相关业务及研发工作。

2024年11月：华为云华南地域部分服务异常
事件经过：因网络设备升级失误，导致华为云华南地域部分云服务访问异常，持续约2小时。
事故原因：内部设备升级操作失误。
造成损失：客户业务短暂中断，华为云快速修复并致歉。

2024年11月：支付宝交易故障
事件经过：11月11日，支付宝发生交易故障，影响用户支付及交易行为。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰用户日常支付及商业交易。

2024年11月：Snowflake云服务逻辑故障
事件经过：11月，云数据平台Snowflake发生严重的服务中断，持续长达13小时。
事故原因：软件更新引发的逻辑冲突。软件更新引入了向后不兼容的数据库架构更新，导致版本不匹配错误。更糟糕的是，其“区域冗余”机制在逻辑故障面前失效，导致10个区域同时瘫痪。
造成损失：大量企业无法执行数据查询，暴露了云服务在面对“逻辑层面”故障时，物理冗余机制可能完全失效的风险。

2024年9月：甲骨文云基础设施故障
事件经过：甲骨文云某区域存储系统故障，导致部分客户数据无法访问，持续超6小时。
事故原因：存储系统运维故障。
造成损失：客户业务中断，甲骨文面临索赔，声誉下滑。

2024年9月：阿里云新加坡数据中心火灾
事件经过：9月10日上午，阿里云新加坡可用区C数据中心发生火灾，导致17项服务异常，Lazada、字节跳动等业务中断。
事故原因：锂电池起火引发故障。
造成损失：多家企业业务中断，阿里云海外服务稳定性受质疑。

2024年9月：上交所交易故障
事件经过：9月27日，上海证券交易所发生交易故障，影响证券交易正常开展。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰资本市场交易秩序。

2024年8月：网易云音乐故障
事件经过：8月19日，网易云音乐发生故障，排查耗时近2小时后恢复。
事故原因：疑似与云存储扩容、贵州机房迁移相关，官方未披露确切原因。
造成损失：用户无法正常使用音乐服务，平台用户体验受影响。

2024年8月：上海电信城域网设备故障
事件经过：8月26日，上海电信城域网设备发生故障，影响区域网络服务。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，干扰民众网络使用及商业活动。

2024年7月：微软系统蓝屏事件
事件经过：7月19日，使用了Windows操作系统的设备大面积蓝屏，导致850万设备受到影响。
事故原因：微软安全供应商CrowdStrike推送了错误的软件配置。
造成损失：成为2024年主要信息系统故障之一，对大量用户工作及使用造成影响。

2024年7月：阿里云故障
事件经过：7月2日，阿里云发生故障，具体影响范围覆盖多款服务。
事故原因：未公开披露具体原因。
造成损失：成为2024年主要信息系统故障之一，影响依赖阿里云服务的客户业务。

2024年4月：腾讯云控制台故障
事件经过：4月8日15点23分，腾讯云云API服务异常，导致云函数、文字识别等依赖服务无法使用，持续87分钟，1957个客户报障。
事故原因：配置数据错误，经紧急数据修复恢复服务。
造成损失：影响客户业务正常开展，平台服务可靠性受质疑。

现阶段AI是否会替代人类

Posted on 2023/11/12 by neohope — No Comments ↓

近期在读一个LangChain的系列文章，文章的最后，作者提出了一个问题：“AIGC来了，人类画师还有价值吗？”

这是一个好问题，在现阶段，我的理解是这样的：

AI绘画提供了一种通用能力，而且很多时候效果很不错，有商用价值，但并非无所不能。说白了就是一种新工具而已，我们该用积极心态看待问题。

就像本文指出的，对人来说效果并非一切。人是有情感的，不仅现在的AI生成物无法替代，很多客观指标更好的物品都无法替代。自己钓的鱼和市场买的是不一样的，自己阳台种的菜和农场种的是不一样的，父母做的菜和餐厅里的是不一样的，儿女给我们画的画和别人的画是不一样的，哪怕替代品指标更好，也无法完成情感需求的替代。

但更进一步，人从一开始不应该和AI比。人很早就学会了不要和机器去比，机器比人力气大，比人跑的快，比人跳得高，但人类为何还要不断挑战自我呢？一旦我们把人工智能，随便换个名字，类人脑型计算阵列设施，问题就简化了。影像医生为何要和AI去比谁能先找到微小肺结节？画师为何要和AI比谁画图更快？网球裁判为何要和AI比谁能更准确的判断球是否出界？用好这些工具就好了啊。

从人类历史的经验看，机器替代人工的过程，在近现代史上出现了太多次，但实质上都是，熟练用工具的人大幅提升效率，最终替代了无法熟练使用工具的非顶尖人才。互联网时代也是一样的，互联网媒体兴起时，对传统媒体产生了巨大压力，但现在自媒体市场兴起，又给多少非科班同学创造了机会。AI短期内一定会抢占一些人类的工作岗位，熟练使用AI辅助编程的人，会挤压掉很多重复编码的工作机会。

但同样的，非科班同学将会拥有编程能力，未来一定会创造更大的市场。未来我们每个人都能有足够好的编程，绘画，作曲，剪辑，写作能力，都有便捷高效的获取并使用近乎无限知识的能力。专业知识普及化，会缓解人类教育周期过长的问题，会带来生产力质的变化。希望这种生产力的飞跃，能带领我们进入一个新的时代。

碳基生物和硅基生物

Posted on 2023/08/14 by neohope — No Comments ↓

在ChatGPT大力出奇迹之后，大模型已经从“萌宠时代”，正式迈入了蹒跚学步的“婴儿时代”。
这个婴儿虽然短期记性不算好，但学习能力和长期记忆能力却无与伦比，潜力无限。

现在大家又通过langchain、plugin等方式，帮助这个婴儿学习使用工具。
当大模型可以理解工具，使用工具，甚至制造工具、创造工具时，硅基生物时代也就开始降临了。

在这个过程中，可能会有以下几个阶段：
1、硅基生物智力和能力有限的阶段
碳基生物需要学会如何运用硅基生物，提升自己的生活水平

2、两种可能
2.1、硅基生物智力无限和能力有限的阶段
碳基生物变成了硅基生物的执行者，相互依赖，容易形成共同体，更容易走向共存的结局

2.2、硅基生物智力有限和能力无限的阶段
碳基生物需要学会如何控制硅基生物的能力，熊孩子教育不好，容易走向一起灭亡的结局

3、硅基生物智力和能力无限的阶段
硅基生物最好能学会如何和碳基生物共存，希望碳基生物不要仅仅是一段引导代码，善待引导代码

微服务性能调优03

Posted on 2023/08/12 by neohope — No Comments ↓

近期遇到一些技术问题，记录如下：

1、NAS引起的惨案一
上次说到，大家都在降本，于是我们做了一系列调整工作。但降本总有一个永恒不变的主题：降配。
于是我们和集团的科技，同时开始了惨无人道的降配工作。
在一顿神奇操作后，系统终于区域稳定，好景不长，突然间又出问题了。

表现：
系统部分服务的部分节点，在服务高峰期之后，总是会出现时不时的系统卡顿。
关键这个卡顿很有规律，总是上午10点，下午4点出现，完美错过我们的上下午业务高峰。
原因：
经过技术委员会小伙伴通力排查，大家最终定位到是应用日志写入到归档NAS时，NAS性能十分不稳定，IO时间有时会高达几秒。
一旦遇到NAS卡顿，会阻塞日志，进而阻塞服务。
而且，当前NAS是和兄弟公司公用的，NAS卡顿时，正值他们的业务高峰期。
解决：
应用日志不再输出到NAS，而是输出到日志云。

2、NAS引起的惨案二
平稳度过了几天，周五，问题又来了。
表现：
系统时不时卡顿，没有任何规律，和业务高峰没有任何关系，一切监控都正常。
原因：
经过N个小时排查，我们的小伙伴，终于发现问题还是出现在日志上，只不过这一次，是GC日志。
GC日志同样是在归档NAS上，此时归档NAS更加不稳定，minor gc日志写入，偶尔会遇到NAS IO延时，引起系统卡顿。
解决：
应用日志不再输出到归档NAS，而是输出到中端闪存NAS，花钱买平安。
进一步：
针对当前遇到的情况，重新制定日志规范，尽快推广落地。

3、一次RefreshScope引发的惨案
表现：
使用nacos动态刷新了一个配置，但相关服务突然越来越慢，并有大量的锁等待：sun.misc.Unsafe.park

原因：
初步分析，nacos更新配置后，对应RefreshScope的类需要重新加载配置，从而调用了GenericScope类的destroy方法，在该方法中加了writelock
同时，业务代码在处理请求的时候，同样的用到了GenericScope::LockedScopedProxyFactoryBean的invoke方法，在该方法中加了readlock
先是读锁（多个），再写锁（一个），再读锁（多个），最后死锁了，都无法获取锁，服务就卡住了。问题是，一开始的锁为何不释放呢？

进一步分析，发现是在服务业务代码中，用到了HttpClient的org.apache.http.impl.io.SessionInputBufferImpl.streamRead方法
该方法调用了java.net.SocketInputStream.socketRead，该方法触发了jdk8的一个bug，该native方法无法返回

解决：
升级JDK版本，同时代码改造缩小RefreshScope的范围

4、一次redis引发的惨案
表现：
几分钟内redis内存飙高，直接爆掉。
查看了业务系统日志，没有出现业务激增的情况。
查看redis日志，发现AOF日志不断增大，重写的时候缓存爆掉，导致主备切换。
监控日志反馈存在大量setex操作。

原因：
reids集群出现大量setex操作，导致AOF日志激增，日志重写时落盘速度缓慢（出现了short write），结果AOF日志缓存爆掉，主从切换

解决：
临时升级了内存，后续将日志盘从NAS改为SSD，并好服务的redis主从切换配置
但setex激增的原因暂时还没有查到，补充了一些防御性代码

5、一次jdk引发的惨案
表现：
一个生成表单PDF的微服务会产生大量的临时文件，而且不会自行清理。

原因：
在用到的一个第三方Jar包中，用到了java.awt.Font类，该类用到了createFont方法

//不会产生大量临时文件
static Font createFont(int fontFormat, File fontFile)
//会产生大量临时文件，初步判断是JDK的问题
static Font createFont(int fontFormat, InputStream fontStream)

解决：
重写了改Jar包的类，从InputStream切换到了File

6、一次防火墙引发的惨案
表现：
部分用户反馈，无法正常加载微信小程序，需要点击右上角进行刷新才行

原因：
从腾讯后台可以看到，有大约18%的请求会超过60S，其余正常
然后到微服务层，发现有一些请求，在返回数据包的时候，会收到“连结已断开”的反馈，与腾讯后台表现较为一致
然后向前一点儿一点儿的捋，最后发现，需要访问的腾讯IP有5个，之前开墙只开了4个，第5个IP数据返回时就被防火墙直接拦截了。

解决：
提单，开墙，解决问题

使用ChatGPT翻译了几本书

Posted on 2023/06/24 by neohope — No Comments ↓

在2014年左右，一直想翻译几本小册子（主要是介绍编的程经验教训，内容其实很老了，但当时有些内容确实触动了我），陆陆续续翻译了其中的一些文章，但各种原因还是没能翻译完毕，算是一个小遗憾。

最近用ChatGPT硬翻了一遍，感觉效果还可以，感兴趣的朋友可以随便翻翻。

架构师应该知道的97件事【ChatGPT翻译版本，52篇】
https://github.com/neohope/97-things-every-software-architect-should-know.git

敏捷程序员应该知道的97件事【ChatGPT翻译版本，26篇】
https://github.com/neohope/97-things-every-agile-developer-should-know.git

程序员应该知道的97件事【ChatGPT翻译版本，97篇】
https://github.com/neohope/97-things-every-programmer-should-know.git

对比了一下自己翻译的版本：
1、最大的感触之一是质量的提升，比Goolge、NewBing翻译的都要好很多，十年前的翻译效果更是没法比
2、最大的感触之二是效率，175篇文章，加上编程、翻译及校对的时间，花了不到10小时（很多是零散时间），平均一篇文章3分半不到，比之前人工+Google的速度快了不止10倍
3、有些文章质量仍有待提升

还有一些感触：
1、虽然有些文章质量有待提升，但非专业领域翻译相关工作被替代可能性十分高大概率会被迫转型，专业领域翻译相关工作效率也会大幅增加大概率不需要这么多人力了
2、后续互联网客服、视频脚本编写、字幕翻译、新闻稿编写、文章编纂、律师助理等文字相关工作人员，会逐步面临更大职业压力
3、建议早点学会用AI提升个人生产力，淘汰不会用AI的人

微服务性能调优02

Posted on 2023/05/16 by neohope — No Comments ↓

在各项目组努力下，终于达成了几个目标：
1、springboot升级到2.x
2、干掉了老技术中台，全部系统对接到新技术中台，实现了技术中台统一
3、填了一波史前巨坑

今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及，实现动态扩缩容
4、日常，继续填历史的技术坑

1、redis调优
数据流：
数据库查询结果-》缓存到redis-》缓存使用者
表现：
bigkey一大堆，单个key存放数据3M多（你咋不把整个JVM塞到redis里去呢），redis服务器所需内存、带宽都特别高
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、改变序列化方式，从jvm序列化，调整为protobuff，调整后，带宽瞬间大幅下降
b、减少序列化的数据内容，只保存真正需要的，调整后，redis内存大幅下架，带宽大幅下降
c、对redis进行拆分，将一个大redis，按领域拆分为多个小redis，性能提升明显
d、对于热数据不明显的低频访问场景，不缓存到redis，大家慢慢优化去吧

2、网关调优
数据流：
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现：
外网网关和内网网关功能一样，而且逻辑超级复杂，性能垃圾的一塌糊涂
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升

3、数据流优化
数据流（大幅简化后）：
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现：
业务逻辑分散到各业务系统，数据来回传递多次，多个系统加工同一批数据，一旦出问题，要多个系统联查，花费很长时间才能定位到问题
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰，用户自己都能初步定位到问题

4、数据修改请求超级多
数据流：
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现：
数据质量差，任务都给到了IT，管理方没有管理动力，数据质量持续差，修改量逐年上升
原因：
分析后发现，各业务条线管控要求很多，不放权，与各地执行机构有轻度脱节
数据生产者，不承担数据质量差的职责，没有提升数据质量动力
总部管理部门，不承担数据质量差的职责，不清楚数据质量哪里差，没有工作重点
解决：
a、分析数据修改工单，归纳前几类修改请求
b、与业务方沟通，对分支机构可以修改的数据，将功能开放给各分支结构，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
c、对于分支结构不可以修改的，开放数据修改功能给总部管理部门，进行统一管控，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升，工单量大幅下降

5、降本
数据流：
应集团要求，降本压力巨大，科技承接了600万降本指标
表现：
科技方压力山大
原因：
一开始几年，没有这么大的压力，大家手都比较松，各条线都存在较大浪费，科技也是如此
最近几年，都是在之前资源上，不断的挤压资源，来满足每年业务快速增长的需要
今年，一方面业务继续快速增加，另一方面要大幅降本，压力山大
解决：
a、第一轮，运维小伙伴拉流量，无流量服务应关尽关，应下尽下，应合尽合
b、第二轮，运维小伙伴拉各类峰值，先统一砍一刀（网络、数据库、主机）
c、第三轮，运维小伙伴看账单，按账单大头，如网络、数据库、主机等逐条应用降本方案
d、第四轮，运维小伙伴看账单，对于不合理的条目逐条检视，逐个逐个扣
e、第五轮，各项目组，结合业务实际情况，各自制定降本方案，限时落地
f、第六轮，技术委员会，对于20%的关键业务进行性能优化，逐步降本
g、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本

谈谈ChatGPT

Posted on 2023/05/09 by neohope — No Comments ↓

春节期间，试用了ChatGPT，让我被惊艳到了。
大模型的涌现效果，能达到ChatGPT3.5的程度，着实让我有些吃惊，真是大力出奇迹啊。

在此之前，我一直认为本次AI技术革命已经接近尾声了：
1、在影像和视频方面，AI已经可以实现商业化：医疗影像AI诊断、自动驾驶、人脸识别、图像搜索、P图滤镜等；
2、在语音方面，语音识别和语音合成已经很成熟；
3、在NLP方面，简单重复任务可以较好完成，比如机器翻译、文本搜索等。但在复杂任务上，还处于有多少人工就有多少智能的尴尬阶段，距离商业化有较长的路需要走；
而且，无论是哪个领域，大家可以发现，AI还是只是一种能力、一个工具，也就是处于“业务X+AI”的模式。
就算AI是生产力，但想象空间也就那么大，因为领域已经被限制死了。

但ChatGPT改变了这个局面，聊天这个场景，可以让ChatGPT成为一个各种能力的插座。
也就是说，一个类似于ChatGPT的大模型，如果能快速整合各种外部能力，从“业务X+AI”，变成“AI+业务X、业务Y、业务Z”的模式，很可能会成为下一代互联网的入口，并从各种维度给人类带来全新体验。

钢铁侠的贾维斯（J.A.R.V.I.S.）还是保守了，我们有更广阔的空间，十分期待这个时代能尽快到来。

同时，国内大厂的大模型层出不穷，究竟谁能成功，还要看三个地方：
1、要有足够大量的数据
2、要有AI人才储备
3、要有足够算力，如果现在才去买显卡，就很难赶上了
国内满足这几点的有：质谱【从闭源到开源】、阿里【闭源到开源】、百度【已掉队】、字节【已掉队】

最近看了一些ChatGPT资料，整理了一些相关示例：
https://github.com/neohope/NeoDemosChatGPT

其中多数例子，来源于极客时间徐文浩老师的课程《AI大模型之美》：
https://time.geekbang.org/column/intro/100541001?tab=catalog

================
补充0812：
当前国内大模型厂商，在底层方面依赖英伟达，在模型技术层面无法相互拉开差距，只能继续向上做：
1、在基础模型层面，支持各类开源模型，弥补自家模型缺点
2、在行业领域，开展合作，把垂直领域模型吃掉
3、在应用层面，也开始逐步布局
加上外资撤出，投资方的钱更难拿，围剿之下，AI方向国内的创业氛围就比较差了。

几个硬件问题导致的故障

Posted on 2023/05/09 by neohope — No Comments ↓

1、更换服务器后，出现网络风暴
表现：
老服务器下架，新服务器上线后，出现网络风暴

原因：
逐步排查网口，猜测一根光纤出现问题

解决：
更换了一根光纤

2、老服务器下架后，新服务器重启后，VM集群无法启动
表现：
三台ESXI主机组了VSAN，重启后，网络互通，但服务器2被独立，无法加入1、3集群
VCSA也在VSAN上，同样无法启动。

原因：
故障时，只知道出现了脑裂，三台主机无法

解决：
重启了VPXA、重启了ESXI，没有解决问题
重建VSAN，然后把三个节点加入，问题就修复了
后续发现，其实时服务器1和服务器3出现了问题，自己组成了一个新的集群

重大黑客攻击事件2023

Posted on 2023/01/08 by neohope — No Comments ↓

2023年黑客攻击事件核心趋势
1、攻击门槛平民化：漏洞利用工具泛滥，低级黑客也能利用高级漏洞牟利，网络攻击呈现“即服务”和自动化特征。
2、供应链“批发式”攻击：利用MOVEit、3CX等第三方软件漏洞，一次击穿数千家企业防线，成为年度最高效攻击手段。
3、关键设施瘫痪战：勒索软件疯狂肆虐，导致皇家邮政、米高梅赌场、医院等核心业务停摆，从“偷数据”转向“搞破坏”。
4、网络基座失守：思科等核心网络设备漏洞被大规模利用，黑客直接掌控企业“大门钥匙”，基础设施风险空前暴露。
5、防御理念重构：面对防不胜防的入侵，行业重心从“严防死守”转向“默认失陷”，强调业务韧性与快速恢复能力。

2023年10月：思科IOS XE路由器大规模漏洞利用
事件经过：黑客利用思科IOS XE软件中的一个关键权限提升漏洞（CVE-2023-20198），在全球范围内大规模入侵思科的路由器和无线控制器。据估计，有超过42,000台思科设备被植入了恶意软件或遭到破坏。
攻击方式：零日漏洞利用（后被确认为严重配置错误导致的漏洞）
造成损失：大量企业及机构的网络核心设备瘫痪或被劫持，攻击者可获得设备的完全控制权，导致网络中断和数据泄露风险，思科紧急发布补丁并呼吁用户重置设备。

2023年9月：米高梅度假村攻击
事件经过：黑客对米高梅度假村发起攻击，导致赌场运营瘫痪，同时泄露大量客户数据。
攻击方式：未明确，疑似勒索软件攻击或系统漏洞利用
造成损失：企业损失超1亿美元，客户隐私泄露，声誉严重受损，运营中断导致持续营收损失。

2023年5-6月：MOVEit Transfer漏洞大规模利用
事件经过：勒索团伙Clop利用Progress的MOVEit文件传输工具零日漏洞，发起大规模数据勒索活动，影响近3000家组织，涉及约8400万人；受害企业包括壳牌、英国航空、约翰霍普金斯大学等，泄露数据数千万条。
攻击方式：零日漏洞利用、供应链攻击、勒索
造成损失：成为年度最大供应链攻击之一，全球大量企业数据泄露，相关企业面临合规罚款与声誉损失。

2023年5月：美国国土安全部遭MOVEit攻击
事件经过：继全球大规模MOVEit漏洞利用事件后，美国国土安全部（DHS）确认其系统也遭到入侵，约23.2万名申请人和雇员的敏感数据被窃取。这是美国政府机构首次公开承认在此次全球供应链攻击中“中招”。
攻击方式：供应链攻击（利用MOVEit Transfer零日漏洞）
造成损失：大量联邦雇员及申请人的个人身份信息（PII）泄露，美国政府关键部门网络安全防线被突破，引发对政府外包服务商安全性的严重质疑。

2023年5月：全印度医学科学研究所攻击
事件经过：印度最重要的政府医疗机构AIIMS遭受勒索软件攻击，导致1.3TB患者数据被加密，涉及约400万患者资料，医院被迫转向手动操作。
攻击方式：勒索软件攻击、数据加密
造成损失：医院诊疗服务受严重影响，患者数据安全受威胁，医疗系统运营效率大幅下降。

2023年3月：3CX供应链攻击
事件经过：全球通讯软件服务商3CX遭供应链攻击，其客户群涵盖全球60余万家组织，包括美国运通、麦当劳、可口可乐等知名企业。
攻击方式：供应链攻击
造成损失：大量知名企业信息系统受影响，供应链安全风险引发全行业警惕。

2023年2月：星巴克遭黑客勒索
事件经过：星巴克在阿根廷、智利和巴西的系统遭到勒索软件攻击，导致其移动应用和会员积分系统在南美多国瘫痪。黑客组织LockBit随后声称对此次攻击负责，并威胁要泄露星巴克的敏感数据。
攻击方式：勒索软件攻击
造成损失：南美地区数百万用户的会员积分和支付功能中断，客户数据面临泄露风险，公司声誉在拉美市场受到冲击。

2023年1月：英国皇家邮政勒索攻击
事件经过：英国皇家邮政遭遇LockBit勒索软件攻击，导致包裹和信件的国际运输陷入停顿。
攻击方式：勒索软件攻击
造成损失：邮政服务瘫痪，全球物流流转受阻，企业声誉受损，修复系统与恢复服务成本高昂。

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

Posted on 2023/01/08 by neohope — No Comments ↓

2023年12月：谷歌云新加坡区域故障
事件经过：因网络配置错误，导致谷歌云新加坡区域服务中断超3小时，影响大量企业客户。
事故原因：内部网络配置失误。
造成损失：客户业务中断，谷歌云赔付客户，市场竞争力受影响。

2023年11月：阿里云全线产品故障
事件经过：11月12日下午，阿里产品全线崩溃，波及全球多个地域全部云用户，持续事件达3.5小时。
事故原因：具说是鉴权服务出了问题。
造成损失：凸显云计算集中化部署风险，影响全球多地客户业务。
小插曲：两周后，在2023年11月27日，阿里云再次遭遇了近两小时的中断，影响到中国和美国的客户。然后当天晚上，滴滴就来了个大的。

2023年11月：滴滴崩溃
事件经过：11月27日晚间，滴滴崩溃，致APP地图无法加载、无法叫车，持续约12小时，影响多地用户。
事故原因：底层系统软件故障。
造成损失：订单流失，品牌形象和用户信任度下降。

2023年10月：新加坡Equinix数据中心制冷故障
事件经过：新加坡Equinix数据中心承包商误关闭冷冻水阀门，导致制冷系统误操作，造成2.5万笔银行交易失败、8.1万次登录失败。
事故原因：承包商操作失误，误关冷冻水阀门。
造成损失：金融交易及用户登录受严重影响，暴露运维管理漏洞。

2023年10月：语雀重大服务故障
事件经过：10月23日14时左右，语雀发生重大服务中断，在线文档和官网无法访问，当晚22时完全恢复，持续近8小时。
事故原因：内部运维工具缺陷，新上线升级工具bug导致华东生产环境存储服务器误下线，造成大面积服务中断。
造成损失：定性为P0级重大事故，影响数千万用户工作与知识管理，引发对运维自动化工具安全性的反思。

2023年6月：中国电信广东网络故障
事件经过：6月8日中国电信广东区域遭遇大规模网络服务中断，用户普遍无信号、无法通话上网，故障约4小时后恢复。
事故原因：网络设备故障。
造成损失：影响广东省内商务活动和民众生活，具体损失数据未公布。

2023年5月：苹果iCloud全球服务中断
事件经过：5月11日，苹果全球服务遭遇“史诗级”宕机，持续约55分钟。大量用户的Apple ID突然登出，无法访问iCloud照片、文件和备忘录等关键数据。
事故原因：数据中心严重故障。虽然苹果未详细披露，但此类核心服务中断通常源于数据中心底层存储或认证服务的配置错误或硬件集群故障。
造成损失：数千万苹果用户数据访问受阻，打破了苹果生态“稳定可靠”的神话，引发了对苹果云服务能力的广泛质疑。

2023年5月：微软Azure故障
事件经过：5月24日，微软Azure DevOps在巴西的一处scale-unit发生故障，导致宕机约10.5个小时。
事故原因：导致该中断的原因为一个简单的拼写错误，最终导致17个生产级数据库被删除。
造成损失：大量用户无法使用云服务。

2023年4月：中信证券APP交易阻塞
事件经过：4月期间，中信证券APP出现严重的交易阻塞现象，客户无法正常下单或撤单。
事故原因：系统软件缺陷与容量规划不足。在市场交易活跃期，系统未能有效处理高并发请求，暴露出软件逻辑缺陷和灾备能力的不足。
造成损失：直接影响客户交易，导致客户资金错失交易时机，引发大量客户投诉，对券商的声誉造成了直接的负面影响。

2023年3月：推特全球大规模宕机
事件经过：平台代码更新错误，导致全球用户无法登录或使用推特功能，持续超5小时。
事故原因：内部代码更新失误。
造成损失：用户体验差，广告收入受损，平台声誉下滑。

2023年3月：广州某电信机房制冷故障
事件经过：广州某电信机房水冷系统破裂引发制冷故障，微信、QQ及政务云系统瘫痪，机房被迫采用冰块临时降温。
事故原因：水冷系统破裂，制冷功能失效。
造成损失：国民级应用及政务服务中断，影响范围广、社会影响大。

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

2023年3月：B站双重崩溃
事件经过：2023年B站经历了两次较为严重的全站级宕机。一次是3月5日，用户无法访问视频详情页、收藏夹；另一次是8月4日，视频封面无法加载、视频缓冲失败。
事故原因：底层服务依赖故障与机房电力问题。虽然具体细节未完全公开，但此类大型视频平台的崩溃通常源于核心微服务依赖失效或机房电力/网络架构的单点故障。
造成损失：数亿用户无法正常观看视频，严重影响用户体验和社区活跃度，尤其在流量高峰期的崩溃对品牌形象损害较大。

2023年3月：唯品会P0级宕机事故
事件经过：3月29日凌晨00:14至中午12:01，唯品会南沙IDC冷冻系统故障，机房温度骤升导致大规模宕机，线上商城停服12小时。
事故原因：制冷设备故障。
造成损失：影响800万人次客户，直接业绩损失超亿元，定性为最高级别P0级故障。
小插曲：事故后，对基础平台部负责人予以免职。

2023年2月：甲骨文多日长故障
事件经过：2月13日至15日，甲骨文云基础设施（OCI）遭遇持续长达数天的服务中断，这是OCI历史上罕见的长时间故障。同时，其子公司NetSuite也因关联故障停摆。
事故原因：DNS后端基础设施性能问题。支持OCI公共域名系统的后端API基础设施出现性能瓶颈，导致无法处理传入的服务请求；此外，NetSuite的故障还叠加了合作伙伴数据中心（Cyxtera）的物理电力故障。
造成损失：客户业务连续数天无法使用云资源，甲骨文“永不宕机”的宣传口号受挫，大量依赖其数据库服务的企业陷入停滞。

2023年1月：美国民航系统瘫痪
事件经过：1月11日美国联邦航空管理局飞行任务通知系统因关键文件损坏瘫痪，备份系统也检测到相同损坏，重启系统导致全美航班禁飞。
事故原因：系统文件损坏。
造成损失：超4000架次航班延误，698架次取消，数十万旅客受阻，经济损失巨大，暴露单点故障风险。