Transformer02:词嵌入及位置编码的计算

一句话经过分词和嵌入之后,输入到Transformer模型的过程如下:

1. 构建输入序列:
将分词后得到的词或字符序列转换为对应的词嵌入向量。每个词或字符都有一个对应的嵌入向量,这些向量通常通过预训练的词嵌入模型获得。

2. 添加位置编码:
由于Transformer模型本身不包含递归或卷积结构,因此它无法直接捕捉序列中的位置信息。为了解决这个问题,需要为每个词嵌入向量添加一个位置编码。位置编码通常是根据词在序列中的位置生成的,它与词嵌入向量相加,使得模型能够利用位置信息。

3. 输入到Transformer:
将包含位置编码的词嵌入向量作为输入序列送入Transformer模型。在Transformer模型中,输入序列被处理为一系列向量,每个向量对应序列中的一个元素(词或字符)。

4. 多头自注意力:
Transformer模型使用多头自注意力机制来处理输入序列。在自注意力层中,每个元素的嵌入向量都会与序列中所有其他元素的嵌入向量进行比较,以计算注意力权重。这个过程在多个“头”中并行进行,每个头都有自己的查询(Q)、键(K)和值(V)权重矩阵。

5. 层归一化和前馈网络:
自注意力层的输出会经过层归一化,然后送入前馈神经网络。前馈网络通常由两个线性变换和一个非线性激活函数组成。这个过程在每个Transformer层中重复进行。

6. 堆叠多个Transformer层:
Transformer模型通常由多个相同的层堆叠而成,每个层都包含自注意力机制和前馈网络。通过这种方式,模型可以在不同层捕捉不同级别的特征和依赖关系。

7. 输出处理:
经过多个Transformer层处理后,模型的输出可以用于各种NLP任务,如语言翻译、文本摘要、问答等。对于特定的任务,可能还需要在Transformer模型的顶部添加额外的层,如线性层或分类层。

总之,每个嵌入向量并不是有自己的Transformer,而是所有嵌入向量一起作为输入序列,被送入同一个Transformer模型中进行处理。通过多头自注意力机制,模型能够捕捉序列内部不同位置之间的依赖关系,从而实现对输入句子的深入理解。

通过一个简单的例子来说明词嵌入和位置编码的计算过程。

### 词嵌入(Word Embedding)

假设我们有一个句子:”I love natural language processing”。首先,我们需要将这个句子分词成单词列表:[“I”, “love”, “natural”, “language”, “processing”]。

接下来,每个单词将通过一个词嵌入矩阵转换成一个固定维度的向量。假设我们的词嵌入维度是4,那么每个单词将被映射到一个4维空间中。例如:

– “I” -> [0.1, 0.2, 0.3, 0.4]
– “love” -> [0.5, 0.6, 0.7, 0.8]
– “natural” -> [0.9, 1.0, 1.1, 1.2]
– “language” -> [1.3, 1.4, 1.5, 1.6]
– “processing” -> [1.7, 1.8, 1.9, 2.0]

这里的数字是随机生成的,实际的词嵌入向量是通过训练得到的,能够捕捉单词的语义信息。

### 位置编码(Positional Encoding)

Transformer模型不包含递归或卷积结构,因此无法直接捕捉序列中单词的顺序信息。为了解决这个问题,我们需要为每个词嵌入向量添加位置编码。

位置编码通常是通过正弦和余弦函数的组合来生成的,以确保不同维度的位置编码具有不同的频率。假设我们的词嵌入维度是4,我们可以为每个位置生成一个4维的位置编码向量:

– 位置1的编码:[sin(1/10000), cos(1/10000), sin(2/10000), cos(2/10000)]
– 位置2的编码:[sin(2/10000), cos(2/10000), sin(4/10000), cos(4/10000)]
– 以此类推…

将位置编码向量与相应的词嵌入向量相加,得到最终的输入向量:

– “I” (位置1): [0.1+sin(1/10000), 0.2+cos(1/10000), 0.3+sin(2/10000), 0.4+cos(2/10000)]
– “love” (位置2): [0.5+sin(2/10000), 0.6+cos(2/10000), 0.7+sin(4/10000), 0.8+cos(4/10000)]
– 以此类推…

这样,每个单词的嵌入向量都包含了其在句子中的位置信息,使得Transformer模型能够在处理序列时考虑到单词的顺序。

### 注意事项

– 词嵌入和位置编码的具体计算方法可能因不同的模型和实现而有所不同。
– 实际应用中,词嵌入通常是通过预训练模型(如Word2Vec、GloVe或BERT)得到的,而不是从头开始训练。
– 位置编码的生成方法在不同的Transformer变体中可能有所不同,例如Transformer-XL和XLNet采用了不同的方法来处理长序列。

这个例子展示了词嵌入和位置编码的基本计算过程,以及它们如何帮助Transformer模型理解和处理自然语言序列。

在实际应用中,词嵌入和位置编码可以预先计算并缓存,以提高效率。下面是一些具体的情况:

1. 词嵌入的缓存:
– 词嵌入通常是通过预训练语言模型得到的,这些模型在大规模语料库上训练,学习到的词嵌入向量能够捕捉丰富的语义信息。
– 一旦词嵌入矩阵训练完成,对于任何给定的单词,其对应的词嵌入向量就可以直接从预训练的模型中获取,而不需要每次重新计算。

2. 位置编码的缓存:
– 位置编码的生成方式是固定的,例如使用正弦和余弦函数的组合,这意味着对于给定的维度和最大序列长度,位置编码向量可以预先计算出来。
– 在模型初始化阶段,可以生成一个位置编码矩阵,其中每一行对应一个位置的位置编码。在处理输入序列时,只需根据序列中单词的位置索引来选择相应的位置编码向量。

3. 缓存的优势:
– 缓存词嵌入和位置编码可以显著减少模型在每次前向传播时的计算量,特别是对于大型模型和长序列。
– 缓存还可以减少模型的延迟,因为从内存中读取预先计算好的向量比实时计算要快得多。

4. 实际应用:
– 在实际的深度学习框架中,如TensorFlow或PyTorch,词嵌入和位置编码通常作为模型的参数或静态变量存储,以便在模型训练和推理过程中重复使用。

5. 灵活性:
– 虽然位置编码通常是固定的,但在某些情况下,如果模型需要处理可变长度的序列,位置编码也可以动态生成。但即使如此,对于常见的序列长度,位置编码的计算可以预先完成,并存储在查找表中以供快速访问。

通过这种方式,词嵌入和位置编码的预先计算和缓存,可以使得Transformer模型更加高效地处理输入数据,特别是在处理大量数据或需要快速响应的应用场景中。

Transformer01:总论

在处理自然语言处理(NLP)任务时,输入一句话通常需要经过以下步骤:

1. 分词(Tokenization):
首先,输入的句子需要被分词,即将句子拆分成更小的单元,这些单元可以是单词、字符或者其他语言单位。分词是处理自然语言的第一步,因为大多数模型都是基于离散的词或字符进行操作的。

2. 词嵌入(Embedding):
分词之后,每个词或字符会被转换成词嵌入(Word Embedding)。词嵌入是将离散的词或字符映射到连续的向量空间中的一种表示方法。这些向量能够捕捉词的语义信息,并且通常通过预训练模型(如Word2Vec、GloVe或BERT等)来获得。

3. 位置编码(Positional Encoding):
对于Transformer模型,由于其自注意力机制无法捕捉序列中元素的顺序信息,因此需要添加位置编码。位置编码是一种向量,它与词嵌入相加,以提供序列中每个元素的位置信息。

4. 序列化(序列化处理):
在某些情况下,如果输入序列超过了模型的最大长度限制,可能还需要进行序列化处理,如截断或填充。

5. 模型处理:
经过上述步骤处理后,得到的序列化、嵌入化和编码后的输入数据就可以被送入模型进行进一步的处理和学习了。

因此,当输入一句话时,通常是先进行分词,然后计算词嵌入,最后将分词后的词嵌入与位置编码相结合,形成模型的输入。这个过程使得模型能够理解句子的结构和语义信息,并在此基础上进行各种NLP任务。

微服务性能调优01

近期遇到一些技术问题,记录如下:

1、kafka并发处理量上不去
数据流:
数据生产服务-》kafka-》数据消费服务
表现:
数据消费服务加了很多个实例,但总感觉多数实例不工作
原因:
分析后发现,原来开发小伙伴把所有消息都扔到了同一个topic中,而分区只有3,消费者再多这并发量也上不去啊
解决:
按不同业务,拆分topic,同时增加分区数
同时,建议把一堆操作拆分为多个步骤进行,不要都放到一个方法里全部做掉,宁可多流转几次各司其职

2、数据上报并发处理量上不去
数据流:
DB-》轮询-》HTTP提交数据到数据上报网站【ZF】
表现:
要求4小时上传60W,实际1小时上传5K
原因:
问题很多,主要有两个,一是每次只上传一条数据,二是没有做并发
解决:
一开始准备做很大的调整,但后面项目组怕把开并发把数据上报网站压挂,最后没敢使用
最后,只是改造为批量上传数据,轮询时根据id做了一下简单的并发
数据上报网站,各地接口及要求各不一样,也是各种不容易吧

3、莫名奇妙的403
数据流:
浏览器-》网关-》鉴权服务
表现:
网关偶尔返回403
原因:
一开始日志输出太少,都没有定位到哪里的问题,只能临时在网关补充了一些日志【建议加了开关,定位问题后关闭】
加日志后,发现是一段上古代码,使用信号量进行了并发控制,超出了并发就获取不到用户权限。
而这个Bug暴漏出来,据反馈,居然是升级组件导致的。
遗留系统都是坑啊。
解决:
优化鉴权服务,定位到问题,问题也就解决了

4、无法提升的微服务性能
数据流:
浏览器-》网关-》N个服务来回调用
表现:
服务性能差,有时要几十秒才返回,一堆告警邮件
原因:
微服务拆分粒度太细,形成环状调用链路
开发同学无脑调用微服务,能调用一次的,居然会循环调用N次
解决:
重构,按业务领域合并微服务,微服务数量少了60%,同时干掉环状调用链
评审,找到不合理的循环调用,抓典型,整改

5、批量导出
数据流:
浏览器-》网关-》导出服务-》DB
表现:
批量查询、批量导出性能很差,要按分钟返回的,一堆告警邮件
原因:
数据量太大,DB拉取速度慢,数据回传也慢
解决:
根据业务情况,部分批量查询功能改到只读库查询,大批量导出功能迁移到了数据中台

6、数据批量下发
数据流:
数据中台-》kafka-》数据下发接收服务
表现:
数据中台下发数据,无法更新到下游业务系统
原因:
因安全需求,上游业务系统批量刷新数据库,导致数据中台下发大量数据,数据下发服务处理不及时,积累了大量数据待处理
下游业务系统把一堆业务逻辑放到了接收服务中,处理单条业务数据要按秒计算,数据越积越多
你没想错,kafka并发上不去,和之前原因一样一样的
解决:
接收服务简化,拆分不必要的业务逻辑,服务性能提高了几百倍
优化kafka配置
制定了批量刷新数据库的相关流程,都是泪
历史数据咋处理?和上游系统沟通后,99.9%的数据不必处理,于是忽略了历史积累数据,晚上将0.1%的数据进行了重推,解决了问题

7、Kafka卡顿
数据流:
系统A-》kafka-》系统B
表现:
kafka在半夜性能下降明显,从日志上看,就是工作2分钟,卡5分钟
原因:
kafka的消费者每次取了太多消息去消费,半夜为业务高峰期,部分消费者获取消息无法及时处理完毕,导致kafka会出发rebalance,你懂的
解决:
每次少取一些数据

8、HTTPS通讯失败
数据流:
前置系统A-》云-》云上系统B
表现:
有两家用户的数据无法连通云服务,HTTPS通讯失败
原因:
前置服务的服务器器时间错误,数据包被云的安全策略直接丢弃,被当成重放攻击了
解决:
开启前置服务自动时间同步服务

9、组件升级导致服务性能下降
表现:
系统组件升级后,系统整体服务性能下降,会有部分请求阻塞5S以上
CPU、内存、IO看起来都比较正常
生产环境才有问题,测试环境下无法复现
原因:
通过打印线程信息,发现存在大量网络IO阻塞
后定位到了一个可疑的点,日志同时输出到log文件和命令行时,命令行也发送到了log文件,会有阻塞
解决:
只输出到命令行,有待观察

整体经验:
1、微服务粒度不能太细,也不能一个服务啥都干,最好按业务领域进行拆分。业务量小的领域可以适当合并,业务逻辑复杂的考虑拆分。
2、微服务也应该分层次,不要出现环状调用链路
3、日志要足够判断问题所在,太多影响性能,太少没啥用
4、中间件不能熟练配置,不要随便上生产
5、批量操作要用特殊处理方式,没事别刷库

重大黑客攻击事件2022

2022年黑客攻击事件核心趋势
1、地缘政治网络化:俄乌冲突引爆全球网络对抗,卫星通信、能源、电信等关键基础设施成攻击首选,网络战正式成为现代战争的标准配置。
2、国家级APT攻击“常态化”:具有政府背景的黑客组织(如美国NSA)频繁针对他国军工、科研机构(如西工大)实施长期潜伏与窃密,意图获取战略情报与核心技术。
3、基础配置漏洞“致命化”:弱口令(如TransUnion)、错误配置(如Akasa Air)等低级失误频发,却导致数千万人数据泄露或公共服务中断,暴露了企业安全基线的脆弱。
4、勒索软件“武器化”:勒索攻击频发且破坏力剧增,从单纯加密数据升级为“加密+窃取”双重勒索,甚至导致哥斯达黎加宣布国家紧急状态、丰田停产等国家级或行业级瘫痪事件。
5、供应链风险“实体化”:攻击者通过渗透HR软件(Kronos)、零部件供应商(小岛工业)等薄弱环节,引发下游企业(如彪马、丰田)的大范围连锁数据泄露与生产中断。

2022年12月:彪马(Puma)数据泄露
事件经过:由于人力资源管理公司Kronos遭受勒索软件攻击,运动品牌彪马的员工数据被泄露,包括6000多名员工的社会安全号码等敏感信息。
攻击方式:供应链攻击
造成损失:员工隐私泄露,企业面临合规风险和信任危机。

2022年8月:卢森堡能源巨头数据泄露
事件经过:欧洲能源管道与电力网络运营商Creos Luxembourg S.A.遭到勒索软件团伙ALPHV(BlackCat)的攻击,大量内部数据被窃取。
攻击方式:勒索软件攻击、双重勒索(加密+窃取)。
影响:涉及欧盟五个国家的能源经营业务,数据泄露对区域能源安全造成了潜在威胁。

2022年8月:印度阿卡萨航空数据泄露
事件经过:阿卡萨航空因登录与注册服务的技术配置错误,导致34,533条用户信息暴露。数据包含客户全名、性别、邮箱及手机号码,所幸未涉及支付或旅行记录。
攻击方式:系统配置错误(技术漏洞)、非蓄意黑客攻击
造成损失:用户隐私泄露,增加遭遇网络钓鱼与精准诈骗的风险,公司需进行安全加固并向监管机构报告。

2022年7月:伊朗铁路系统攻击
事件经过:黑客篡改伊朗铁路系统车站显示屏信息,诱导乘客拨打所谓“投诉电话”,该电话实为政府热线,造成社会混乱。
攻击方式:系统入侵+信息篡改
造成损失:公共交通秩序混乱,政府热线被大量占用无法正常服务,损害公共服务公信力。

2022年7月:美国情报机构攻击中国军工企业
事件经过:自2022年7月起,美国情报机构利用微软Exchange邮件系统的零日漏洞(0-day),对中国一家大型重要军工企业实施了长达近一年的网络攻击。攻击者控制了该企业的域控服务器,并以此为跳板,控制了内网50余台重要设备。
攻击方式:零日漏洞利用、隐蔽通道(Websocket+SSH隧道)、多层流量转发。
造成损失:攻击者窃取了包括企业高层在内的11人邮件,涉及军工产品的设计方案、系统核心参数等高度敏感的国家机密。

2022年6月:西北工业大学遭受境外攻击
事件经过: 西北工业大学发布声明,遭受来自境外(后经调查指向美国NSA)的黑客组织攻击。攻击者发送带有木马程序的钓鱼邮件,企图窃取师生邮件数据和科研机密。
影响: 这是一起典型的针对中国重点科研机构的APT(高级持续性威胁)攻击,引发了国内对高校和科研单位网络安全防护的高度重视。

2022年6月:超星学习通数据库泄露
事件经过: 国内高校广泛使用的“超星学习通”APP数据库疑遭泄露,在黑市上被叫卖。涉及数据高达 1.7亿 条,包含学生的姓名、手机号、学号、甚至辅导员信息。
影响: 这是2022年影响最广的教育数据泄露事件,导致大量学生面临精准诈骗的风险。

2022年5月:印度香料航空(SpiceJet)勒索攻击
事件经过:印度第二大航空公司香料航空遭遇勒索软件攻击,内部系统被迫离线,导致多个航班延误数小时,大量乘客滞留机场。
攻击方式:勒索软件攻击
造成损失:航班运营混乱,乘客行程受阻,公司面临巨大的经济损失和声誉危机。

2022年5月:富士康(墨西哥工厂)勒索攻击
事件经过:富士康位于墨西哥蒂华纳的工厂遭受勒索软件攻击,黑客加密了约1200台服务器,删除了20-30TB的备份数据,并索要约2.3亿元人民币的巨额赎金。
攻击方式:勒索软件攻击(LockBit变种)
造成损失:生产线一度中断,业务运营受阻,且面临巨额赎金压力。

2022年4-5月:哥斯达黎加政府勒索软件危机
事件经过:Conti勒索软件攻击哥斯达黎加政府系统,导致系统瘫痪,新总统宣布国家进入紧急状态,多个部门服务中断数周。
攻击方式:勒索软件攻击
造成损失:国家级基础设施服务瘫痪,政府行政效率大幅下降,社会公共服务受阻,修复成本高昂。

2022年4月:巴西里约财政系统遭勒索攻击
事件经过: 巴西里约热内卢州的财政系统遭到 LockBit 勒索软件团伙的攻击。黑客不仅加密了系统,还窃取了约 420GB 的政府办公数据,并威胁如果不支付赎金就公开数据。
影响: 政府税务和财政办公系统一度瘫痪,严重干扰了公共财政的正常运转。

2022年4月:保加利亚国家邮政系统瘫痪
事件经过:保加利亚国家邮政系统遭到勒索软件攻击,导致柜台养老金发放业务被迫中断,许多老年人无法按时领取生活费。
攻击方式:勒索软件攻击
造成损失:关键民生服务中断,社会秩序受到冲击。

2022年4月:阳翼航空系统中断
事件经过: 加拿大阳翼航空(Swoop)的第三方系统供应商遭受攻击,导致其内部系统中断。
影响: 机场值机和登机功能瘫痪,导致多伦多皮尔逊机场连续 5天 出现大规模航班延误和乘客滞留,无数旅客被困机场

2022年3月:南非全民征信数据泄露
事件经过: 国际信贷巨头 TransUnion 的南非分公司服务器被黑客攻破。原因是服务器密码设置过于简单(弱口令),导致黑客如入无人之境。
影响: 这是一次灾难性的数据泄露,涉及约 5400万 南非公民(占全国人口近90%)的敏感信息,包括身份证号、信用评分等。这几乎等同于泄露了半个国家的“底账”。

2022年3月:丰田汽车供应商攻击
事件经过:丰田的零部件供应商小岛工业(Kojima Industries)遭受网络攻击,导致其无法向丰田发送零部件。这直接迫使丰田暂停了日本国内14家工厂的28条生产线。
攻击方式:供应链攻击
造成损失:约1.3万辆汽车的生产计划受阻,暴露了制造业供应链的脆弱性

2022年3月:英国眼镜制造商Specsavers数据泄露
事件经过:黑客组织“ShinyHunters”攻击了英国知名眼镜连锁店Specsavers,窃取了约860万客户的个人数据,并在暗网论坛上公开出售。
攻击方式:网络入侵、数据窃取
造成损失:大量客户的姓名、地址、出生日期甚至验光记录泄露,面临严重的身份盗用风险

2022年2月起:俄乌冲突相关网络攻击潮
事件经过:乌克兰政府、银行、能源设施遭持续网络攻击,同时全球卫星通信系统Viasat在冲突首日遭攻击,影响中欧数万用户。
攻击方式:DDoS攻击、数据擦除恶意软件(如CaddyWiper、HermeticWiper)
造成损失:乌克兰多项公共服务中断,Viasat用户通信受阻,体现网络攻击作为战争工具的趋势,加剧地区动荡。

2022年2月:乌克兰关键基础设施攻击(Kyivstar电信攻击)
事件经过:俄乌冲突期间,乌克兰最大电信运营商Kyivstar遭Sandworm黑客组织攻击,导致全国网络服务中断。
攻击方式:针对性关键基础设施攻击、系统破坏
造成损失:乌克兰全国通讯瘫痪,民生与战时信息传递受严重影响,地缘政治驱动的网络攻击危害加剧。

2022年2月:美国卫星网络攻击(Viasat)
事件经过:Viasat卫星网络遭攻击,攻击者通过VPN设备入侵管理后台,导致数千乌克兰用户和数万欧洲用户断网。
攻击方式:VPN设备入侵、管理后台渗透
造成损失:跨境卫星通讯服务中断,大量用户正常通讯受阻,卫星网络安全防护漏洞凸显。

2022年2月:英伟达和三星数据泄露
事件经过:黑客组织Lapsus$攻击英伟达,窃取约1TB机密数据;同时攻击三星电子,泄露近190GB源代码。
攻击方式:组织化网络攻击、数据窃取
造成损失:科技企业核心技术与商业机密泄露,研发优势受影响,面临知识产权风险。

2022年2月:丰田供应链攻击
事件经过:丰田因零部件供应商小岛工业遭网络攻击,被迫暂停日本14家工厂28条生产线。
攻击方式:供应链攻击(通过供应商渗透)
造成损失:影响约13000辆汽车生产,汽车产业链中断,企业生产计划受阻,营收受损。

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

2022年12月:阿里云香港Region大规模宕机
事件经过:12月18日,阿里云香港Region可用区C发生大规模服务中断,持续数小时,为其运营十多年来最长大规模故障,新购ECS等管控操作全部失败,整个处置过程超过15小时。
事故原因:机房冷却系统失效,现场包间温度逐渐升高,导致一机房包间温度达到临界值触发消防系统喷淋,电源柜和多列机柜进水,部分机器硬件损坏。
造成损失:严重影响香港及澳门客户业务,品牌信誉受损,事后发布事故说明及改进措施。
小插曲:事故后,阿里云总裁、CTO都被更换。

2022年12月:达美航空(Delta)行李系统故障
事件经过:12月28日,达美航空的行李处理系统突发严重故障,导致全球多个主要机场的行李传送带停摆,大量行李无法被正确分拣和装载。
事故原因:硬件维护不当与软件集成失效。由于行李处理系统的物理传感器和分拣机械臂出现故障,且后台管理系统未能及时切换至备用模式,导致系统“死锁”。
造成损失:数千名旅客的行李丢失或延误,圣诞节假期返程高峰受阻,达美航空被迫手动处理行李,运营陷入混乱。

2022年12月:腾讯云北京地域部分服务器故障
事件经过:因网络设备故障,导致北京地域部分云服务器、数据库等服务访问异常,持续约3小时。
事故原因:网络设备故障引发的运维事故。
造成损失:部分企业业务中断,腾讯云紧急修复并赔付客户。

2022年8月:谷歌爱荷华州数据中心电气爆炸
事件经过:谷歌美国爱荷华州数据中心发生电气爆炸,造成3名电工严重烧伤,全球1338台服务器中断,谷歌地图、搜索服务宕机。
事故原因:电弧闪光引发爆炸。
造成损失:人员受伤,设施损毁,核心服务中断影响全球用户。

2022年7月:Twitter全球大规模宕机
事件经过:7月14日上午8:10左右开始,Twitter突发全球性大规模服务中断,持续约1小时。
事故原因:内部系统配置与软件故障,引发了连锁反应。
造成损失:全球数万用户受影响。
小插曲:正值Twitter起诉马斯克违约的敏感时期,加剧了外界对其内部管理混乱的猜测。

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

2022年7月:Oracle Cloud(甲骨文)核心故障
事件经过:7月19日,甲骨文云服务(Oracle Cloud Infrastructure, OCI)发生严重故障,导致其核心金融、ERP等SaaS服务在全球范围内无法访问。
事故原因:关键配置错误。运维人员在对核心网络基础设施进行配置更新时,引入了错误的路由策略,导致控制平面(Control Plane)瘫痪,客户无法管理或访问其云端资源。
造成损失:依赖甲骨文系统的大型企业财务和运营流程中断,凸显了传统企业级云服务在运维操作上的风险。

2022年3月~5月:招商证券交易系统连环崩溃
事件经过:3月14日开盘后系统突发故障,用户无法成交、撤单;5月16日系统再次崩溃,电脑端、手机端均无法登录。
事故原因:交易系统技术缺陷。
造成损失:严重扰乱交易秩序,引发投资者不满和监管关注,母公司对相关负责人问责,质疑券商IT系统稳定性。

2022年3月:富途证券(Futu)全球大宕机
事件经过:3月14日,互联网券商富途证券(牛牛APP)发生全球范围内的服务中断。用户无论是通过网页端还是手机APP,都无法登录交易系统,也无法查看持仓和进行交易,故障持续了数小时。
事故原因:底层架构扩容引发的连锁故障。在进行系统扩容升级时,运维团队对流量预估不足,且核心网关组件未能正确处理扩容带来的配置变更,导致负载均衡失效,流量无法分发至后端服务器。
造成损失:正值美股交易时段,大量投资者无法操作,引发用户强烈不满和投诉,对券商口碑造成负面影响。

为何互联网大厂不做医院的信息系统

一、从经济角度
1、付款能力
互联网大厂,大家看下财报,年营收上万亿,人均营收在400万以上。
而医院呢,除去顶尖几家,很好的医院一年营收也就几十亿、十几亿,人均营收几十万。随着疫情,很多医院营收更加困难。

2、付款意愿
互联网大厂中,研发费用投入占比远远高于医院在软件方向投入,大家去看下财报就懂了。

3、产品价格
从经济学角度观察,医疗信息化行业,长期低价值竞争,已经把行业利润搞到快养不起现在的开发了。
大厂进入,势必要引入更多更贵的开发资源入场,一定是个亏本买卖。
行业的强监管导致了没有什么新的花样可以搞,大厂不可能干亏本且没其他收益的买卖。

4、运维成本
大厂2C的高并发架构,在医院
1)是用不到
医院系统一天登录用户最多几千人
2)是成本太高
无论是硬件还是运维成本,医院都接不住:一台服务器能跑起来的项目,不要部署在五台服务器的K8S集群上。
如果服务器挂了,可以重启。但K8S挂了,很多医院自己都重启不了。
不要打炮打蚊子,没有最好的架构,只有在限定经济情况下,局部最优的架构。

经济学角度出发,这个事情就不成立。
所以现状大厂的做法是,赚云的钱,但利润低、受苦受累的医院信息化,是直接做集成的。

二、从技术和产品的角度
大厂对比医院,更像是2C对2B,2B和2C软件逻辑差异很大:

(一)技术困难点不一样
1、互联网大厂技术难度高的多,以并发量来说,医院一天门诊量1万多,住院几千张床,登录用户最多几千人,和双11没法比

2、医院信息化系统,以HIS为例,难度在于,业务需求的复杂度高,如果一位开发同学即对接过微信支付,又对接过医保支付,应该很能理解,微信支付的对接就和玩一样,因为医保支付会从根本上要求医院重构
举个例子:12306初期请了不少大厂专家,解决并发问题,但购票逻辑比网络购物复杂的多,这么多高手,也没有能快速拿下,崩了两年。不是这些专家能力差,而是需求复杂度更高。

(二)需求掌控能力
1、互联网大厂,是有强大的产品和运营的,他们有很清晰的目标,服务和讨好客户,把客户就在平台,并创业更高的商业价值。产品好不好,客户也就是最终用户有一票否决权

2、多数医院没有专职运营,能把业务流程,服务流程,系统流程说清楚的,全医院就没几个人。产品最终用户,医生护士,对于流程没有话语权,只能提出点状要求

3、更可怕的是,外行指导内行的情况,在2B领域更加可怕,很难拒绝一些不靠谱的需求
举个例子:当年IE特别慢,微软有团队准备从一个飞快的开源浏览器改一版替代IE。但当这个团队把一堆IE需求加上去之后,反而比IE还慢,项目就结束了。

三、从组织架构
1、执行力
互联网大厂组织结构更优化,目标十分清晰,执行力强的可怕
医院更偏事业单位风格,需要强大政策导向,才能爆发真正的执行力

2、变革意愿
互联网大厂,从开始就在不停的变革,大家对于失败容忍度较高
医院要抽取资源,做个什么新的项目,太难了:成功不一定有功,失败一定是过

四、为何越升级越难用
1、从经济学角度观察
很大的一个原因是,买单方和使用方不是同一波人,且使用方没有话语权。
买单方花钱升级系统为的是搞管理搞成绩,从来不是为了使用方体验更好。
搞管理,管的越来越多,越来越细,被管理的使用方自然越来越难受,就会憎恶这个带来苦恼的系统。
搞成绩,就要多做事,使用方工作就更多,同样会憎恶这个带来更多工作的系统。
工作多,管得细,发挥空间自然就少了,创新就更难了。
举个例子:钉钉打卡功能其实产品层面并不差,但被管理的人不爽,有人会说钉钉好用吗?

2、什么样的考核,带来什么样的结果,铸就什么样的团队。
系统升级,以管理为导向,时间短任务重,最终用户承担了越来越多的工作,会有人说你好吗?

一次数据库字段加密升级记录

今年个保法发布了,根据安全团队要求,需要对数据库的敏感字段进行加密处理。

当前数据库连接已经加密了,只需要对数据加密。有两种代价较小的方式:
1、在数据库存储引擎层面加密,这样对全部业务系统是无感的。
2、退而求其次,可以在数据库中间件或在驱动层面做加密,这样全部业务系统修改量也是比较小的。
但由于种种原因,这两种方式都没有能推行。

最后采用的方式是,安全团队提供加解密SDK,各业务系统对接。
业务系统启动,通过加解密SDK从密钥分发服务器获取密钥-》写入数据库前加密、读取数据后解密
加密算法都是国密算法,包括对称加密及摘要算法。
这样全部业务系统都需要改造,而且批量操作效率也比较低。
优点是,即使别人攻破数据库,也拿不到明文数据。

改造过程也很痛苦:
1、注册APP ID,申请密钥
2、研发刷库工具
3、在数据库表中增加加密字段,通过刷库工具,将历史敏感数据进行加密,存放到加密字段
4、基于加解密SDK,研发适用于个团队的切面SDK
5、使用切面SDK,对服务进行改造,读明文,写明文+密文(可跳过)
6、使用切面SDK,对服务进行改造,读密文,写明文+密文(可跳过)
7、使用切面SDK,对服务进行改造,读密文,写密文(可跳过)
8、删除明文字段
整个过程十分痛苦。

稳定性保障:
整个密钥下发服务器,是全局的一个大故障点,必须保障可用性。
密钥分发服务器,用到了密码机,提供了同城容灾及异地容灾环境。
支持DC单独部署,也支持云访问。

对应用系统影响:
1、改造量大,且无直接业务收益,资源投入受限
2、性能下降,尤其是批量加解密时,性能下降较多
3、模糊查询受影响较大,只能通过提前计算的摘要信息进行查询了
4、遗留系统、外购系统,改造难度太大,成本太高,无法承受

对数据中台的冲击:
所有依赖于数据库日志的系统,都会受到影响,尤其是数据中台
有两种方式,一是不使用,二是用同样的key

一次技术中台升级记录

由于历史原因,我们有两套技术架构:
基于SpringBoot1.X的老框架、老技术中台、老数据中台。
基于SpringBoot2.X的新框架、新技术中台、新数据中台。

老技术中台研发的时候,整个生产环境都是我们自己搭建的,很多功能需要自研。
到了新技术中台时,已经迁移到了集团的云上,之前设计的很多功能也就用不到了。
而且,随着时间的推移,老中台人员都去参与了其他项目,长期处于支持维护状态,无论研发、运维还是安全同事,都感到压力山大。
由于云端环境时不时会做调整,运维同学都不敢轻易重启老中台服务,怕一重启,就再也起不来了。
安全扫描策略也不断升级,扫描出来的问题一次比一次多,很快就千疮百孔了,但大家也只能缝缝补补。

之前由于业务压力异常巨大,大家一直在忙着做各种新的业务功能,虽然一直想升级,但一直没有狠下心来。
到了今年四季度,遇到了几次生产事故后,大家痛定思痛,决定还是干吧,把老中台下掉。

整体步骤大体如下:
1、找了两位对老技术中台比较熟悉的同事,对全部服务进行了梳理
2、各技术团队,也对老中台的依赖关系重新进行了梳理
3、大家坐下来,对服务进行了分类
A、对于网关类服务,按领域拆分
B、对于调用中转类服务,已经不符合当前要求,改为K8S的微服务直连
C、先看调用量小的服务;没有调用量的服务及接口,尽早下线
D、其余调用量很少的服务,与业务方沟通,能下线下线,不能下线合并等待下线
E、新老技术中台都有的服务,新中台进行适配,下线老中台服务
F、老中台有,新中台没有的中台类服务,功能迁移,下线老中台服务
G、非中台类服务,拆分到业务系统,下线老中台服务
H、其余服务,一事一议
4、对新老平台都保持的数据,进行数据治理,统一数据标准
5、在服务迁移改造的过程中,要求按新框架规范,将服务升级到SpringBoot2
6、由于没有业务上的直接收益,所以整个改造周期排了很久,各团队根据实际情况,在每次迭代中把工作量消化掉
7、及时与测试同学沟通,确保每次测试覆盖到
8、与运维同学沟通,服务全部升级完成后,切换nacos到最新版本(之前受限于SpringBoot1,无法升级nacos)
9、这样框架、技术中台就升级完毕了,后面每半年升级一次框架就可以了
10、数据中台的小伙伴,因形势所迫,直接抛弃了原有技术栈和工具,拥抱了新技术栈,最后技术债务居然是最小的。

任务已排期,各团队都表示坚决支持。但你以为这样就能顺利推进吗?我感觉比较难哦。
过半年,再续写一下,推进情况究竟如何,敬请期待。

记录一个卡券系统漏洞

大概三年前,遇到过这样一个系统需求,被安全团队及时发现,避免了引起大规模的问题。

事情是这样的,我们有一个比较老的外购卡券管理系统,之前都是实体卡直接核销的。
后来逐步上线了各大电商平台,就需要通过虚拟卡的方式,通过短信将激活地址、卡号、卡密直接发送给客户,客户可以直接注册、激活。

但这时遇到了两个问题:
1、客户需要复制卡号、卡密到激活地址,操作比较繁琐
2、卡号、卡密都很长,会造成一个短信无法成功发送,需要拆分成两个短信发送,同样是不方便

业务方希望客户操作更加方便,与供应商沟通,供应商提供了这样一个方案:
1、客户下单完成后,将激活地址+卡号+卡密,一起生成一个短链
2、直接将短链通过短信发给客户
3、客户点击短链,一键绑定

听起来一起都很美好是不是?

但很快就被安全团队质疑了,攻击思路是这样的:
1、暴力枚举短链,批量获取短链实际地址
2、匹配地址,批量抓取卡号卡密
3、申请账号,绑定卡号卡密,攻击成功

于是这个需求被判定为高危风险,直接就被否定了。