About neohope

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

分布式一致性算法01:Paxos

分布式一致性算法01 Paxos算法

一、基本概念
Paxos是分布式一致性的经典算法,由Leslie Lamport在1990年提出。

二、Paxos算法通常涉及三种角色:
Proposer(提议者) :负责提出提议(Proposal),即向系统中提出一个值。Proposer通常是客户端,负责发起提议并分配一个不重复的自增ID给每个提议。
Acceptor(接受者) :参与决策过程,负责接收并回应Proposer的提议。每个Acceptor只能接受一个值,并且为了保证最多只有一个值被选定(Chosen),Proposal必须被超过一半的Acceptors所接受。
Learner(学习者) :负责学习最终被选定的值。Learner不参与协商过程,只是接收并记录最终被选定的值。
在实际过程中,一个节点可以同时承担1~3个角色。

三、Paxos算法的基本过程
1、准备阶段(Prepare Phase):
提议者(Proposer)选择一个提议编号(ballot number),并将其发送给所有接受者(Acceptor)。
接受者在接收到提议者的准备请求后,如果当前编号大于其已承诺的最高编号,则更新其承诺编号,并返回一个承诺(promise)给提议者,承诺中包含当前已接受的最高编号和值。

2、提议阶段(Proposal Phase):
提议者收集到多数接受者的承诺后,选择一个值(value),并结合最新的提议编号,生成提议(propose)消息发送给接受者。
接受者在接收到提议消息后,如果提议编号大于其已有的承诺编号,则接受该提议,并返回确认消息给提议者。

3、决定阶段(Decide Phase):
提议者收集到多数接受者的确认消息后,可以决定该值为最终值,并将其写入日志或状态机中。
学习者(Learner)从提议者处获取并学习最终决定的值,确保所有节点都有一致的状态。

四、举例说明:
假设我们有一个分布式系统,包含10个节点:P1、P2是提议者,A1、A2、A3、A4、A5是接受者,L1、L2、L3是学习者。

1、准备阶段:
P1提出一个提议编号,编号为1。
P1向所有接受者A1~A5发送询问,询问P1将发起编号为1提议是否可以。
A1收到提议时,并没有反馈过任何一次提议,于是反馈可以接受,并承诺,后续不会接受编号比1小的提议。A2~A4类似。

几乎同时,P2提出一个提议,编号为5。
P2向所有接受者A1~A5发送询问,询问P2将发起编号为5提议是否可以。
A1收到提议时,承诺的最小编号为1,于是反馈可以接受,并承诺,后续不会接受编号比5小的提议。A2~A4类似。

到这里,P1和P2的提议,前后都被允许提交了。当然,也有情况可能是,部分节点先收到了P2,这种情况下,P1的提议编号就无效了,需要重新拟定编号,这个编号必须单调增加。

2、提议阶段
P1收到了过半节点的提议编号反馈,向所有接受者A1~A5发送提议,告知提议编号为1的提议值为V1。
接受者收到提交消息时,已经无法接收比5小的提议,于是就拒绝P1,提议不通过。

P2收到了过半节点的提议编号反馈,向所有接受者A1~A5发送提议,告知提议编号为5的提议值为V5。
接受者收到提交消息时,反馈P2同意了5号提议。

3、决定阶段
当提议5收到过半同意反馈时(5个节点中3个以上同意),认为提议通过,各节点并将V5写入日志。
此时,学习者L1、L2、L3也会学习到V5的结果,并写入日志。

五、Paxos算法的特点
多数同意:在Paxos算法中,只有当提议者收到超过半数接受者的同意时,提议才可能被提交。
唯一性:Paxos算法保证了在任何给定的一轮中,只有一个提议可以被接受。
容错性:即使在一些节点失败的情况下,Paxos算法也能够工作。
Paxos算法的实现和理解都相当复杂,但它是许多现代分布式系统一致性协议的基础,如Raft算法等。

将被大模型+机器人严重冲击的行业

这里说的冲击严重,指的是可能导致从业人员大规模失业,而不是单纯的提升工作效率。
现在看起来,下面的部分行业从业人员,会受到较大冲击:

文字处理
1、客服人员(聊天机器人、语音机器人)
2、翻译人员(普通文件翻译)
3、文员(部分工作机会会被替代)
4、内容审核人员
5、内容创作人员(新闻转发、内容创作)
6、部分开发人员(部分代码编写人员)
7、部分法律从业者(文档整理、案例分析、合同审查)
8、部分保险从业者(部分业务员、部分核保任务)
9、部分财务人员(部分财务审计任务)

自动驾驶
1、网约车驾驶员
2、长途运输司机
3、物流人员(自动配送)

产业自动化
1、流水线工人(机器人)
2、仓库管理(无人仓储)
3、养殖人员
4、农业人员

NEOHOPE大模型发展趋势预测2405

NEOHOPE大模型发展趋势预测2405
1、规模化遇到瓶颈,资源陷阱效应愈发明显,GPT5未能按时发布,估计遇到不小的技术问题
2、垂直化趋势明显,完全通用的大模型投产比不高,而垂直化的大模型可以在一定领域内保障效果的情况下,有效降低模型训练及推理成本,
3、移动化趋势明显,以苹果为首的各厂商在努力缩减模型规模,努力提升设备推理性能,通过大模型赋能移动终端
4、具身化初现效果,无论是人形机器人,还是机器人训练,效果显著
5、多模态大模型投产低,远不如多个模态的模型整合
6、部分整合类应用已经可以赚钱,比如Perplexity等
7、下半年没有盈利能力的大模型厂商财务压力会很大
8、美国对外大模型技术封锁会更加严格

一线厂商【主观】:
1、国外闭源:ChatGPT、Gemini、Claude
2、国外开源:Llama3、Mistral
3、国内闭源:月之暗面Kimi、智谱清言ChatGLM
4、国内开源:阿里通义千问

PS:
补充其他几个不错的模型
1、绘画方向,Midjourney,SD
2、视频生成,Sora
3、文字转音频,ChatTTS

英伟达也有几个不错的模型平台
1、药物研发,BioNeMo
2、基因分析,Parabricks
3、医学影像,MONAI

换行符引发的惨案

最近在读go源码。

本来环境都搭建好了,源码也上传git了。
但从另一台电脑下载源码后,报了一堆神奇的错误。
最后发现是go.env文件中,回车换行是按windows系统设定上传到git的,改为linux系统设定就好了。

想起入行以来,因为字符集、换行符、正斜杠反斜杠、tab还是空格,遇到的那堆坑,唏嘘不已。
希望UTF-8早日一统天下,希望各大平台别再特立独行。
非标准化害死人,多套标准更是害死人啊。

qwen.cpp简明教程

1、下载并编译qwen.cpp

git clone --recursive https://github.com/QwenLM/qwen.cpp
cd qwen.cpp
cmake -B build
cmake -B build -DGGML_OPENBLAS=ON
cmake -B build -DGGML_CUBLAS=ON
cmake --build build -j --config Release

2、下载模型,转化为ggml格式

#从hf下载模型,下载完成后,本地地址为 ~/.cache/huggingface/hub/模型名称
#部分代码文件会有缺失,可以到hf上对比下载
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen-7B-Chat",trust_remote_code=True)
#模型转化为ggml格式
#同时进行量化,降低资源需求
python3 qwen_cpp/convert.py -i PATH_TO_MODEL -t q4_0 -o qwen7b-q40-ggml.bin

3、运行模型

./build/bin/main -m qwen7b-q40-ggml.bin --tiktoken PATH_TO_MODEL/qwen.tiktoken -i

chatglm.cpp简明教程

1、下载并编译chatglm.cpp

git clone --recursive https://github.com/li-plus/chatglm.cpp.git
cd chatglm.cpp
git submodule update --init --recursive
#cmake -B build
cmake -B build -DGGML_OPENBLAS=ON
#cmake -B build -DGGML_CUBLAS=ON
cmake --build build -j --config Release

2、下载模型,转化为ggml格式

#从hf下载模型,下载完成后,本地地址为 ~/.cache/huggingface/hub/模型名称
#部分代码文件会有缺失,可以到hf上对比下载
from transformers import AutoModel
model = AutoModel.from_pretrained("THUDM/chatglm-6b",trust_remote_code=True)
#模型转化为ggml格式
#同时进行量化,降低资源需求
pip install torch tabulate tqdm transformers accelerate sentencepiece
python3 chatglm_cpp/convert.py -i PATH_TO_MODEL -t q4_0 -o chatglm-6b-q40-ggml.bin

3、运行模型

./build/bin/main -m chatglm-6b-q40-ggml.bin -i

4、常见问题

#下面的错误,是transformers版本太高导致
AttributeError: 'ChatGLMTokenizer' object has no attribute 'sp_tokenizer'. Did you mean: '_tokenize'?
#需要降低transformers版本
pip uninstall transformers
pip install transformers==4.33.2

大语言模型资料汇总

一、之前整理了一些大模型的Demo,汇总如下
1、ChatGPT
https://github.com/neohope/NeoDemosChatGPT

2、Llama2
https://github.com/neohope/NeoDemosLlama2
可同步看一下中文版Llama2
https://github.com/ymcui/Chinese-LLaMA-Alpaca-2

3、阿里千问
https://github.com/neohope/NeoDemosQwen

4、清华ChatGLM
https://github.com/neohope/NeoDemosChatGLM

二、建议看一下llama.cpp
1、llama.cpp
https://github.com/ggerganov/llama.cpp

2、python的llama.cpp封装
https://github.com/abetlen/llama-cpp-python

3、千问的qwen.cpp实现
https://github.com/QwenLM/qwen.cpp

4、ChatGLM的chatglm.cpp实现
https://github.com/li-plus/chatglm.cpp

三、还有量化
https://github.com/AutoGPTQ/AutoGPTQ

四、当然还有langchain
https://github.com/langchain-ai/langchain

五、如果有余力,看一下Transformer实现
https://github.com/huggingface/transformers

llama.cpp简要教程

1、下载并编译llama.cpp

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make

2、下载llama-2-7b-chat
a、可以从fb或hf下载
b、可以使用脚本下载工具,比如llama-dl
c、可以使用Chinese-LLaMA-2-7B
d、可以使用其他三方源

3、模型转换为ggml格式

python3 convert.py ../llama/llama-2-7b-chat/ 
Loading model file ../llama/llama-2-7b-chat/consolidated.00.pth
params = Params(n_vocab=32000, n_embd=4096, n_layer=32, n_ctx=2048, n_ff=11008, n_head=32, n_head_kv=32, n_experts=None, n_experts_used=None, f_norm_eps=1e-06, rope_scaling_type=None, f_rope_freq_base=None, f_rope_scale=None, n_orig_ctx=None, rope_finetuned=None, ftype=None, path_model=PosixPath('../llama/llama-2-7b-chat'))
Found vocab files: {'tokenizer.model': PosixPath('../llama/tokenizer.model'), 'vocab.json': None, 'tokenizer.json': None}
Loading vocab file '../llama/tokenizer.model', type 'spm'
Vocab info: <SentencePieceVocab with 32000 base tokens and 0 added tokens>
Special vocab info: <SpecialVocab with 0 merges, special tokens unset, add special tokens unset>
tok_embeddings.weight                            -> token_embd.weight                        | BF16   | [32000, 4096]
norm.weight                                      -> output_norm.weight                       | BF16   | [4096]
output.weight                                    -> output.weight                            | BF16   | [32000, 4096]
layers.0.attention.wq.weight                     -> blk.0.attn_q.weight                      | BF16   | [4096, 4096]
...
layers.31.ffn_norm.weight                        -> blk.31.ffn_norm.weight                   | BF16   | [4096]
skipping tensor rope_freqs
Writing ../llama/llama-2-7b-chat/ggml-model-f16.gguf, format 1
Ignoring added_tokens.json since model matches vocab size without it.
gguf: This GGUF file is for Little Endian only
[  1/291] Writing tensor token_embd.weight                      | size  32000 x   4096  | type F16  | T+   3
...
[291/291] Writing tensor blk.31.ffn_norm.weight                 | size   4096           | type F32  | T+ 314
Wrote ../llama/llama-2-7b-chat/ggml-model-f16.gguf

4、模型量化,减少资源使用

./quantize ../llama/llama-2-7b-chat/ggml-model-f16.gguf  ../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf q4_0 
main: build = 2060 (5ed26e1f)
main: built with cc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 for x86_64-linux-gnu
main: quantizing '../llama/llama-2-7b-chat/ggml-model-f16.gguf' to '../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf' as Q4_0
llama_model_loader: loaded meta data with 15 key-value pairs and 291 tensors from ../llama/llama-2-7b-chat/ggml-model-f16.gguf (version GGUF V3 (latest))
llama_model_loader: Dumping metadata keys/values. Note: KV overrides do not apply in this output.
llama_model_loader: - kv   0:                       general.architecture str              = llama
llama_model_loader: - kv   1:                               general.name str              = llama
llama_model_loader: - kv   2:                       llama.context_length u32              = 2048
llama_model_loader: - kv   3:                     llama.embedding_length u32              = 4096
llama_model_loader: - kv   4:                          llama.block_count u32              = 32
llama_model_loader: - kv   5:                  llama.feed_forward_length u32              = 11008
llama_model_loader: - kv   6:                 llama.rope.dimension_count u32              = 128
llama_model_loader: - kv   7:                 llama.attention.head_count u32              = 32
llama_model_loader: - kv   8:              llama.attention.head_count_kv u32              = 32
llama_model_loader: - kv   9:     llama.attention.layer_norm_rms_epsilon f32              = 0.000001
llama_model_loader: - kv  10:                          general.file_type u32              = 1
llama_model_loader: - kv  11:                       tokenizer.ggml.model str              = llama
llama_model_loader: - kv  12:                      tokenizer.ggml.tokens arr[str,32000]   = ["<unk>", "<s>", "</s>", "<0x00>", "<...
llama_model_loader: - kv  13:                      tokenizer.ggml.scores arr[f32,32000]   = [0.000000, 0.000000, 0.000000, 0.0000...
llama_model_loader: - kv  14:                  tokenizer.ggml.token_type arr[i32,32000]   = [2, 3, 3, 6, 6, 6, 6, 6, 6, 6, 6, 6, ...
llama_model_loader: - type  f32:   65 tensors
llama_model_loader: - type  f16:  226 tensors
llama_model_quantize_internal: meta size = 740928 bytes
[   1/ 291]                    token_embd.weight - [ 4096, 32000,     1,     1], type =    f16, quantizing to q4_0 .. size =   250.00 MiB ->    70.31 MiB | hist: 0.037 0.016 0.025 0.039 0.057 0.077 0.096 0.111 0.116 0.111 0.096 0.077 0.057 0.039 0.025 0.021 
...   
[ 291/ 291]               blk.31.ffn_norm.weight - [ 4096,     1,     1,     1], type =    f32, size =    0.016 MB
llama_model_quantize_internal: model size  = 12853.02 MB
llama_model_quantize_internal: quant size  =  3647.87 MB
llama_model_quantize_internal: hist: 0.036 0.015 0.025 0.039 0.056 0.076 0.096 0.112 0.118 0.112 0.096 0.077 0.056 0.039 0.025 0.021 
main: quantize time = 323302.84 ms
main:    total time = 323302.84 ms

5、使用模型

./main -m ../llama/llama-2-7b-chat/ggml-model-f16-q4_0.gguf -n 256 --repeat_penalty 1.0 --color -ins

重大黑客攻击事件2024

2024年黑客攻击事件核心趋势
1、AI应用泛滥化:生成式AI被大规模用于制造深度伪造内容操纵舆论,以及自动生成恶意代码和钓鱼邮件。
2、关键设施被勒索攻击常态化:医疗、航空、能源等关键基础设施频繁中招,导致社会运转停摆。
3、防御体系脆弱化:不仅软件漏洞被频繁利用,硬件供应链的植入和内部人员的勾结也让传统防御形同虚设。
4、攻击物理化:网络攻击直接造成现实伤害,黎巴嫩通信设备被武器化引爆,打破了虚拟与现实的边界。
5、云与供应链成为重灾区:黑客通过攻陷第三方SaaS平台窃取数据,利用“信任链”进行横向移动。

2024-2025年:Salesforce生态系统连环攻击
事件经过:ShinyHunters等勒索团伙通过被攻陷的账号和OAuth令牌窃取客户数据,同时通过入侵Salesloft、Drift等第三方SaaS平台,窃取可访问Salesforce的OAuth令牌,波及谷歌、Cloudflare、Zscaler、Palo Alto Networks等数十家科技巨头,涵盖科技、航空、保险、奢侈品等多个行业。
攻击方式:第三方账号攻陷、OAuth令牌窃取、供应链渗透
造成损失:大量企业客户数据泄露,显示SaaS平台供应链风险,即便Salesforce自身安全,其庞大的第三方生态也成为攻击者的捷径。

2024年(大选期年):AI生成的深度伪造(Deepfake)图像泛滥
事件经过:在美国大选期间,网络上出现了大量利用AI生成的虚假图像和误导性内容。其中包括声称展示副总统哈里斯年轻时穿着麦当劳制服的伪造图片,以及比尔·盖茨支持特定候选人的虚假宣传。
攻击方式:生成式AI(GenAI)滥用、深度伪造、社会工程学
造成损失:严重干扰了公众视听,加剧了社会舆论的撕裂,标志着AI技术被大规模用于政治操纵和舆论战的新阶段。

2024年12月:门罗大学数据泄露事件
事件经过:门罗大学(Monroe University)披露了一起发生在2024年末的重大数据泄露事件。攻击者在2024年12月9日至23日期间入侵其网络,窃取了超过32万名学生、教职工的敏感个人信息,包括社会安全号码和财务数据。
攻击方式:系统入侵、数据窃取
造成损失:影响逾32万人,是美国高校近期遭受的最严重网络攻击之一,凸显了教育行业在数据保护方面的薄弱环节。

2024年9月:PlayDapp加密货币私钥泄露事件
事件经过:韩国知名区块链游戏平台PlayDapp因私钥管理失误,导致黑客成功窃取其私钥。黑客随后增发了29亿枚PLA代币进行抛售,迫使项目方不得不迁移合约以止损。
攻击方式:私钥窃取、代币增发攻击
造成损失:直接经济损失高达2.9亿美元,是2024年加密货币领域损失最惨重的单一事件之一,再次暴露了中心化交易所和项目方在私钥管理上的致命缺陷。

2024年9月:黎巴嫩寻呼机(BP机)及对讲机爆炸事件
事件经过:黎巴嫩多地发生寻呼机和对讲机大规模爆炸。调查指出,这是全球首起将通信设备武器化的实战案例。攻击者在设备生产环节植入了含有炸药的改装电路板,通过远程发送特定代码触发爆炸,造成大量人员伤亡。
攻击方式:供应链硬件改装、物理设备武器化、远程遥控引爆
造成损失:造成数百人死伤,打破了网络攻击仅限于“虚拟世界”的界限,直接导致了现实世界的物理伤害,被定义为“网络战与物理战的结合”。

2024年8月:美国情报机构攻击中国大型科技企业事件
事件经过:国家互联网应急中心(CNCERT)披露,美国情报机构对中国某先进材料设计研究院及某智慧能源和数字信息高科技企业实施了长达数月的网络攻击。攻击者利用电子文档系统漏洞和微软Exchange漏洞,植入内存木马,窃取了大量商业秘密和知识产权文件(共计数GB数据)。
攻击方式:APT攻击、零日漏洞利用、内存马植入、供应链渗透
造成损失:大量核心商业机密和科研数据泄露,暴露了高科技企业在面对国家级黑客组织时的脆弱性,引发全球对科技商业间谍活动的关注。

2024年8月:西雅图机场勒索攻击
事件经过:西雅图机场遭受勒索攻击,导致登机手续延误、WiFi瘫痪、显示屏黑屏。
攻击方式:勒索软件攻击
造成损失:严重扰乱假期旅客出行秩序,机场运营效率大幅下降,声誉受影响。

2024年7月:CrowdStrike更新故障引发全球IT中断
事件经过:CrowdStrike的Falcon Sensor安全软件更新错误,导致全球数百万Windows系统崩溃。
攻击方式:软件更新故障(非恶意攻击,属重大安全事故)
造成损失:约100亿美元经济损失,成为史上最大的IT中断事件之一,全球各行业企业运营广泛受影响。

2024年7月:美国摩根大通银行数据泄露
事件经过:黑客通过贿赂银行外包技术人员,非法获取约1.5亿名客户的账户信息、交易记录等敏感数据。
攻击方式:社会工程学+内部人员勾结
造成损失:银行面临超20亿美元的潜在赔偿与监管罚款,客户信任度大幅下降,引发金融行业对内部人员与外包团队安全管理的重视。

2024年7月:AT&T大规模数据泄露
事件经过:AT&T遭遇重大数据泄露,暴露近1.09亿客户敏感信息,几乎覆盖所有无线客户;公司向攻击者支付约37万美元加密货币以删除数据。
攻击方式:数据窃取、勒索
造成损失:大量客户隐私泄露,企业经济受损,声誉受严重影响。

2024年6月:Snowflake云数据平台攻击
事件经过:云数据平台Snowflake遭大规模攻击,导致Live Nation、桑坦德银行等多家公司数据泄露,影响波及电信巨头AT&T的用户。
攻击方式:云平台入侵、数据窃取
造成损失:多家企业核心数据泄露,云数据平台安全防护漏洞凸显,波及范围广,引发行业对云服务数据安全的担忧。

2024年6月:NHS Synnovis医疗服务攻击
事件经过:英国国家医疗服务体系关键供应商Synnovis遭攻击。
攻击方式:针对性医疗服务供应商攻击
造成损失:导致数千次手术和预约被取消,英国医疗系统陷入危机,患者诊疗服务受严重影响。

2024年2月:Change Healthcare勒索软件攻击
事件经过:美国医疗支付巨头Change Healthcare遭攻击,导致全美数千家药房和诊所运营瘫痪,约1亿人数据泄露;母公司UnitedHealth支付2200万美元赎金。
攻击方式:勒索软件攻击(数据窃取与系统加密并行)
造成损失:联合健康集团损失约24.5亿美元,美国医疗结算网络大规模中断,倒逼医疗行业加速混合云灾备与勒索防护建设。

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

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个客户报障。
事故原因:配置数据错误,经紧急数据修复恢复服务。
造成损失:影响客户业务正常开展,平台服务可靠性受质疑。