Learn and share.
在ChatGPT大力出奇迹之后，大模型已经从“萌宠时代”，正式迈入了蹒跚学步的“婴儿时代”。
这个婴儿虽然短期记性不算好，但学习能力和长期记忆能力却无与伦比，潜力无限。
现在大家又通过langchain、plugin等方式，帮助这个婴儿学习使用工具。
当大模型可以理解工具，使用工具，甚至制造工具、创造工具时，硅基生物时代也就开始降临了。
在这个过程中，可能会有以下几个阶段：
1、硅基生物智力和能力有限的阶段
碳基生物需要学会如何运用硅基生物，提升自己的生活水平
2、两种可能
2.1、硅基生物智力无限和能力有限的阶段
碳基生物变成了硅基生物的执行者，相互依赖，容易形成共同体，更容易走向共存的结局
2.2、硅基生物智力有限和能力无限的阶段
碳基生物需要学会如何控制硅基生物的能力，熊孩子教育不好，容易走向一起灭亡的结局
3、硅基生物智力和能力无限的阶段
硅基生物最好能学会如何和碳基生物共存，希望碳基生物不要仅仅是一段引导代码，善待引导代码
近期遇到一些技术问题，记录如下：
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数据返回时就被防火墙直接拦截了。
解决：
提单，开墙，解决问题
在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的人
在各项目组努力下，终于达成了几个目标：
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，让我被惊艳到了。
大模型的涌现效果，能达到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方向国内的创业氛围就比较差了。
1、更换服务器后，出现网络风暴
表现：
老服务器下架，新服务器上线后，出现网络风暴
原因：
逐步排查网口，猜测一根光纤出现问题
解决：
更换了一根光纤
2、老服务器下架后，新服务器重启后，VM集群无法启动
表现：
三台ESXI主机组了VSAN，重启后，网络互通，但服务器2被独立，无法加入1、3集群
VCSA也在VSAN上，同样无法启动。
原因：
故障时，只知道出现了脑裂，三台主机无法
解决：
重启了VPXA、重启了ESXI，没有解决问题
重建VSAN，然后把三个节点加入，问题就修复了
后续发现，其实时服务器1和服务器3出现了问题，自己组成了一个新的集群
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年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架次取消，数十万旅客受阻，经济损失巨大，暴露单点故障风险。
咱们做技术的人，都喜欢起名字：信息化、数字化、数字平台、数字化转型、数智平台等，让很多人一开始觉得好高大上，然后又开始发懵，这些词之间有什么区别呢？试着通俗解释一下：
1、信息化
把组织线下业务流程，放到线上的过程。
比如，咱们学校上线了考勤系统、选课系统，这就是一个信息化的过程
2、数字化赋能阶段一：数字报表
在信息化的过程中，产生了部分的数据，对这部分数据进行挖掘提炼，得到一些报表，对组织经营起到了一定的提升作用。
比如，大家经常能看到的各类系统报表，通过经营分析报表，指导管理经营行为。
3、数字化赋能阶段二：数字平台
信息化建设后，各个系统之间是割裂的，各系统之间数据是互不相通的。
如何将数据打通，让组织运营者，可以对企业状况一览无余。
比如各类数据平台项目、数字平台项目，一般都会为运营者提供各类“驾驶舱”或Dashboard。
其实就是为管理者开了天眼，有了全局视角。
4、数字化赋能阶段三：自动化平台
当企业数字化建设到一定程度的时候，很多管理规则可以抽象并固化为系统规则，不需要人干预即可处理事情。
比如自动化制造、自动化质控、自动化风控、甚至量化交易等等。
5、数字化赋能阶段四：智能数字化平台，或数智平台
在3的基础上，引入了一些物联网技术、智能终端技术等，一方面让运营者可以快速感知一线情况，一方面可以快速决策反馈。
比如电商平台发现交易异常的时候，会触发智能平台的规则，自动止血；或者一些智能可穿戴设备，实时监控患者病情，及时进行干预。
6、数字化转型
但组织到了一定的发展阶段，传统的运营方式，已经无法支撑组织进一步的快速发展。
需要自上而下的去调整思路，用数字化运营的方式，重塑组织的运营方式，这其中数字化技术只是一个手段。
以华为为例，他们建立了基础IT架构（华为云），打造了统一的数据底座，提供了统一的数字服务，使用了大数据、AI、IoT等技术，最终通过数字化重构了业务运营方式，包括数字化作业、数字化交易、数字化运营、数字化办公等，从而造就了了华为近10年的飞速发展。
对于咱们老年人慢病管理，我们同样需要技术架构，同样需要统一的数据底座，同样需要封装统一的数字服务，同样可以使用大数据、AI、IoT等技术，但最终要重构哪些业务的运营方式，要重构成什么样子，就是咱们课题组要考虑的了。
比如，我们通过数据分析，可以主动为各类患者提供各类服务（比如糖尿病患者），比如：量身定制适合各自的治疗及追踪方式，量身匹配到不同的家庭医生，提前把患者需要的药帮患者准备好，提前把社区医院的耗材准备好等等等等。
7、数字化赋能与数字化转型的区别
7.1、数字化赋能
业务V1.0+数字技术=》业务A V1.1
7.2、数字化转型
业务 V1.0+自上而下的数字化运营体系+技术体系支持=》业务 V2.0
Transformer模型的核心是自注意力机制（Self-Attention），它允许模型在处理序列时，能够捕捉序列内部不同位置之间的依赖关系。自注意力机制的计算过程可以概括为以下几个步骤：
1. 查询（Query）、键（Key）、值（Value）的生成：
对于输入序列中的每个元素，模型会分别生成对应的查询（Q）、键（K）和值（V）。这通常是通过输入序列与三个不同的权重矩阵相乘来实现的。
2. 注意力分数的计算：
对于序列中的每个元素，计算其查询（Q）与序列中所有元素的键（K）的点积，然后除以一个缩放因子（通常是键向量维度的平方根），得到一个注意力分数。
其中，（Q）和（K）分别是查询和键的向量，\(d_k\) 是键向量的维度。
3. Softmax归一化：
使用Softmax函数对注意力分数进行归一化处理，使得所有元素的注意力分数之和为1。这表示每个元素对其他元素的注意力贡献是相对的。
4. 加权求和：
将归一化后的注意力权重与对应的值（V）相乘，然后将所有元素的加权值相加，得到最终的输出。
5. 多头注意力：
Transformer模型中的自注意力通常不是只计算一次，而是通过多头注意力（Multi-Head Attention）来实现。这意味着模型会并行地执行多次自注意力机制，每个头都有自己的查询、键和值权重矩阵。最后，这些头的输出会被拼接起来，并通过一个线性层来整合信息。
6. 残差连接和层归一化：
在自注意力层之后，通常会有一个残差连接，它将自注意力层的输入直接添加到输出上，然后通过一个层归一化（Layer Normalization）来稳定训练过程。
整个自注意力机制使得Transformer能够并行处理序列中的所有元素，并且能够捕捉到元素之间的长距离依赖关系，这是它在处理序列数据时非常有效的原因之一。
让我们通过一个简单的例子来说明自注意力机制的计算过程。假设我们有一个由3个词组成的序列：[“I”, “love”, “coding”]，并且每个词的词嵌入维度是4。
步骤1: 词嵌入
首先，我们将每个词转换为词嵌入向量。假设词嵌入矩阵已经预先训练好，我们可以直接获取每个词的词嵌入向量：
– “I” -> [0.1, 0.2, 0.3, 0.4]
– “love” -> [0.5, 0.6, 0.7, 0.8]
– “coding” -> [0.9, 1.0, 1.1, 1.2]
步骤2: 添加位置编码
接下来，我们为每个词嵌入向量添加位置编码。假设我们使用标准的正弦和余弦函数生成位置编码，并且序列的最大长度是3。位置编码向量如下：
– 位置1的编码：[sin(0), cos(0), sin(8), cos(8)] （这里8是4*2，因为每个词嵌入维度是4）
– 位置2的编码：[sin(1), cos(1), sin(9), cos(9)]
– 位置3的编码：[sin(2), cos(2), sin(10), cos(10)]
将位置编码向量与词嵌入向量相加：
– “I” (位置1): [0.1+sin(0), 0.2+cos(0), 0.3+sin(8), 0.4+cos(8)]
– “love” (位置2): [0.5+sin(1), 0.6+cos(1), 0.7+sin(9), 0.8+cos(9)]
– “coding” (位置3): [0.9+sin(2), 1.0+cos(2), 1.1+sin(10), 1.2+cos(10)]
步骤3: 自注意力计算
现在我们开始自注意力的计算过程。首先，我们需要为每个词生成查询（Q）、键（K）和值（V）向量。假设我们使用相同的词嵌入向量作为Q、K和V的初始输入，并通过不同的权重矩阵进行转换：
– Q = W^Q * 输入向量
– K = W^K * 输入向量
– V = W^V * 输入向量
这里W^Q、W^K和W^V是模型的可学习参数。
步骤4: 计算注意力分数
对于序列中的每个词，我们计算其查询向量与序列中所有词的键向量的点积，然后除以键向量维度的平方根进行缩放：
– 对于词”I”，其注意力分数是它自己的Q与所有词的K的点积：
步骤5: Softmax归一化
使用Softmax函数对每个词的注意力分数进行归一化处理：
– 对于词”I”，归一化后的注意力权重是：
步骤6: 加权求和
最后，将归一化后的注意力权重与对应的值向量相乘，并求和得到最终的输出：
– 对于词”I”，其输出是：
这个过程对于序列中的每个词都要重复执行，以计算整个序列的输出。自注意力机制允许模型在处理每个词时，都能够考虑到序列中其他所有词的信息，从而捕捉词与词之间的复杂关系。
请注意，这个例子是一个简化的版本，实际的Transformer模型可能会使用多头自注意力机制，并且会有多个层来进一步处理信息。此外，词嵌入和位置编码通常是通过预训练得到的，而不是从头开始训练。