Category Archives: 运维事故

2026年1月：英雄联盟全球停服事件
事件经过：2026年1月5日凌晨，腾讯旗下游戏英雄联盟突发全球停服故障，停服10小时才陆续恢复。
事故原因：SSL证书管理失误，2016年签发的十年期SSL证书到期后遗忘续签，加密通信中断，导致系统瘫痪。
造成损失：引发玩家对技术漏洞和补偿的争议，暴露缺乏自动提醒机制，损害游戏品牌信誉。
小插曲：为避免在此出现类似事件，腾讯公司直接续期了100年，证书从2026年1月5日，一直到2125年12月12日才会失效。但问题是，届时如果游戏没有停服，由于人员更替，会不会由于太长事件没有替换证书，导致问题再次出现呢？

2026年1月：罗技鼠标失灵事件
事件经过：2026年1月6日，MACOS平台下，罗技logi options+程序突然无法启动，导致大量罗技鼠标无法正常工作。
事故原因：据悉是因为logi options+程序的签名证书过期导致的。
造成损失：大量罗技鼠标在MACOS平台下失灵，引发大量用户不满，损坏品牌声誉。

2025年11月：Cloudflare大规模故障
事件经过：11月18日，Cloudflare CDN、安全服务等多款产品宕机，团队误判为DDoS攻击，回滚旧文件后，于19日凌晨01:06全部恢复。
事故原因：数据库权限调整后生成错误配置文件，引发核心代理系统异常。
造成损失：全球大量依赖Cloudflare服务的网站及业务受影响，平台承诺加速系统韧性升级。

2025年11月：亚马逊云服务重大事故
事件经过：美国太平洋时间凌晨2:01，AWS因运营问题导致近70项自有服务受影响，亚马逊、迪士尼+、Canva等平台及多款云游戏瘫痪。
事故原因：未公开披露具体技术原因，确认与美国东部1号区域相关。
造成损失：全球多家知名平台服务中断，影响用户使用及企业业务营收。

2025年10月：亚马逊AWS北弗吉尼亚区域崩溃
事件经过：AWS US-EAST-1区域中断长达15小时，波及全球。
事故原因：核心依赖服务失效，DynamoDB DNS解析异常引发连锁故障。
造成损失：数千个服务瘫痪，潜在经济损失高达百亿美元。

2025年10月 微软Azure配置错误，导致全球中断
事件经过：Azure Front Door错误配置变更，Azure全网瘫痪，引发Office 365、Teams等核心服务全球性中断，持续数小时。
事故原因：网络配置变更失误，触发底层逻辑缺陷致级联故障。
造成损失：全球用户无法使用核心服务，企业远程办公中断，微软赔付客户，声誉受损。

2025年9月：韩国政府数据中心火灾
事件经过：数据中心锂离子电池迁移维护时爆炸起火，858TB核心数据丢失，160多项公共服务受影响，一周仅恢复18%系统。
事故原因：运维操作引发的基础设施事故。
造成损失：政府服务瘫痪，修复成本高，公信力受损。

2025年8月：上海医保系统故障
事件经过：8月11日，上海医保系统因电信云平台机房供电故障无法正常结算，应急备份系统接管后，本地门急诊结算恢复，大病、住院及异地结算受影响。
事故原因：电信运营管理的云平台机房供电系统故障。
造成损失：患者就医结算受阻，异地参保人需自费后报销，影响民生服务。

2025年6月：谷歌云全球性服务中断
事件经过：6月12日，谷歌云遭遇全球性服务中断，持续约13小时。期间，谷歌工作空间（Google Workspace）、安全运营产品等外部API请求大量失败。
事故原因：服务控制组件高负载处理失效。“服务控制”组件是谷歌云策略检查系统的核心，负责读取配额和政策信息。该组件未能有效应对高负载情况，导致API请求处理堵塞，进而引发了全局性的服务中断。
造成损失：大量企业客户业务受阻，谷歌为此向客户致歉并推出了服务控制改进计划，重建客户信任。

2025年3月：华金期货交易系统长达7.5小时宕机
事件经过：3月10日，华金期货的交易系统突发异常，客户无法通过文华财经等主流交易端登录账户。故障持续了整整7小时26分钟，直到半日过去才被修复。
事故原因：软件故障与应急处置不当。虽然具体技术原因因“证据灭失”未能完全查清，但监管调查发现其在应急处置中未妥善保护现场，且暴露出灾备系统性能不足、过度依赖外部供应商等问题。
造成损失：达到“一般网络安全事件”标准；期货市场瞬息万变，长时间的交易中断导致客户面临巨大的穿仓风险和亏损，公司也因此收到监管罚单。

2025年1月：埃隆·马斯克旗下X公司数据中心火灾
事件经过：X公司租用的俄勒冈州希尔斯伯勒数据中心发生火灾。
事故原因：储能设备管理问题，电池房间存在运维漏洞。
造成损失：影响X平台部分服务稳定性。

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

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架次取消，数十万旅客受阻，经济损失巨大，暴露单点故障风险。

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，都无法登录交易系统，也无法查看持仓和进行交易，故障持续了数小时。
事故原因：底层架构扩容引发的连锁故障。在进行系统扩容升级时，运维团队对流量预估不足，且核心网关组件未能正确处理扩容带来的配置变更，导致负载均衡失效，流量无法分发至后端服务器。
造成损失：正值美股交易时段，大量投资者无法操作，引发用户强烈不满和投诉，对券商口碑造成负面影响。

2021年12月：微软Azure日本东部地区故障
事件经过：因电力设备故障，导致Azure日本东部地区服务中断超5小时，影响大量企业客户业务。
事故原因：基础设施运维事故，电力设备故障。
造成损失：客户业务中断，微软按SLA赔付，声誉受损。

2021年12月：西安“一码通” 短短半月崩溃两次
事件经过：12月20日及次年1月4日，西安“一码通”系统在半个月内连续两次崩溃。特别是在全员核酸检测期间，系统无法显示健康码，导致检测点排起长龙。
事故原因：系统架构无法承载峰值流量。虽然有疫情压力，但从运维角度看，是缺乏有效的弹性扩容机制和流量削峰设计，系统在面对突增的并发访问时直接“熔断”。
造成损失：疫情防控关键环节“掉链子”，严重影响了城市的防疫效率和秩序。
相关事故：
2022年1月10日，广州“粤康码”崩溃。
2022年3月11日，上海“随申码”崩溃。

2021年11月：网易游戏机房过热宕机
事件经过：网易游戏机房温度过高触发报警，部分服务器过热宕机，空调重启后仍无法解决，多款游戏无法登录、断连，3小时后服务器恢复正常。
事故原因：机房制冷系统故障，温度失控。
造成损失：干扰玩家游戏体验，影响游戏运营口碑。

2021年10月：Facebook史上最严重宕机
事件经过：10月4日，Meta旗下Facebook、Instagram、WhatsApp等服务全球中断近7小时，创2008年以来最长纪录，员工门禁卡、邮箱也无法使用。
事故原因：内部运维操作失误，修改BGP路由规则时误删域名服务器IP地址块路由配置。
造成损失：影响全球数十亿用户，Facebook市值蒸发约600亿美元，险些引发第三方服务连锁崩溃。
小插曲：宕机期间，大量用户涌向了Twitter、Telegram等其他应用，又进一步导致这些应用程序的服务器崩溃。

2021年10月：微软Azure 虚拟机全球故障
事件经过：10月13日，微软Azure云服务发生长达6小时的严重中断。全球范围内的用户无法启动、创建或更新Windows虚拟机，甚至连管理界面都打不开。
事故原因：服务管理操作期间的调用故障。在进行后台维护操作时，系统内部的调用机制失效，导致控制平面（Control Plane）失灵，用户失去了对服务器的“控制权”。
造成损失：企业无法管理核心云资产，业务扩展和维护受阻，再次打击了企业对公有云稳定性的信心。

2021年10月：Roblox 历史最长宕机
事件经过：10月28日，全球热门游戏平台Roblox发生了一次长达73小时的严重宕机。作为“元宇宙”概念的代表，这次长时间的停服让数千万玩家无法登录。
事故原因：负载均衡器过载与架构瓶颈。由于平台流量激增，负责分配流量的负载均衡器不堪重负，引发了内部网络的拥塞。Roblox坚持自建数据中心而非完全上云的策略，在应对突发流量洪峰时暴露了弹性不足的问题。
造成损失：平台信誉受损，玩家流失，且引发了关于“关键业务是否该上公有云”的行业大讨论。

2021年8月：英国Telstra数据中心火灾
事件经过：澳大利亚电信巨头Telstra伦敦数据中心因UPS故障发生火灾，导致一半大楼断电，部分区域受损。
事故原因：UPS故障引发火灾，烧毁供电组件。
造成损失：严重影响依赖该数据中心的金融及企业客户业务运转。

2021年6月：Fastly 内容分发网络崩溃
事件经过：6月8日，CDN服务商Fastly出现严重故障，导致全球大量依赖其加速的网站（包括Amazon、Reddit、CNN、PayPal等）在近1小时内无法访问。
事故原因：服务配置修改触发系统漏洞。Fastly工程师在进行一项常规的“服务配置”修改时，意外触发了系统底层的一个未被发现的软件漏洞，导致其全球节点瞬间瘫痪。
造成损失：互联网“基础设施”级故障，大量主流网站同时“消失”，凸显了互联网供应链的脆弱性。

2021年5月：Salesforce 全球大规模宕机
事件经过：5月11日，全球最大的CRM服务商Salesforce遭遇长达5小时的服务中断。这次故障波及全球，导致大量销售和客服人员无法访问客户数据。
事故原因：运维人员“走捷径”引发连锁故障。一名工程师在进行配置变更时，使用了有缺陷的脚本去绕过标准流程。该脚本在重启服务器时发生超时失败，但由于自动化部署机制未停止后续操作，导致故障在各个数据中心不断扩散，最终压垮了系统。
造成损失：全球数百万依赖Salesforce的企业用户业务停摆，作为“云服务标杆”的可靠性形象受损。

2021年4月：美国WebNX犹他州数据中心火灾
事件经过：美国WebNX犹他州数据中心发生火灾，导致超360万个网站故障，约1.5万名客户资料受影响。
事故原因：UPS故障引发火灾，缺乏物理隔离导致火势蔓延。
造成损失：部分数据永久丢失，客户权益受损，企业声誉受创。

2021年3月：法国OVH斯特拉斯堡数据中心火灾
事件经过：3月10日，欧洲云计算巨头OVH位于法国斯特拉斯堡的数据中心发生火灾，燃烧6小时后被扑灭，4个数据中心中1座完全烧毁。
事故原因：疑似UPS故障或电力室逆变器周围湿气引发短路。
造成损失：发生起火的SBG2数据中心被完全烧毁，360万个法国政府及企业网站瘫痪，OVH面临巨额赔偿和客户流失。

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

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

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

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

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

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

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

那做这些值吗？值！
但要符合自己的情况，不能太过，绑了自己的手脚！

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

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

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

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

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

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

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

2020年12月：Google Cloud全球服务中断
事件经过：12月14日，Google旗下的多项核心服务（包括YouTube、Gmail、Google Drive、Google Search）在全球范围内发生大规模宕机，持续约1小时。这是近5个月内Google发生的第3次全球性故障。
事故原因：内部基础设施组件故障（据推测为身份验证或负载均衡服务）。
造成损失：全球数亿用户无法访问关键生产力工具和娱乐内容，再次引发了企业界对公有云巨头服务稳定性的担忧。

2020年11月：亚马逊AWS美国东部区域宕机
事件经过：AWS Kinesis数据流式处理服务软件错误，引发连锁故障，导致大量依赖该服务的网站和应用瘫痪，持续超4小时。
事故原因：软件缺陷引发的运维故障。
造成损失：大量企业业务中断，AWS声誉受损，面临客户索赔。

2020年9月：特斯拉全球性宕机
事件经过：9月23日上午11点起，特斯拉系统遭遇全球性宕机，持续约4小时，多国车主无法通过手机App连接车辆，太阳能及储能电池用户无法监控系统状态，部分车主被锁车外、有人在充电桩处被困近两小时。
事故原因：系统级故障。
造成损失：具体经济损失未公布，严重影响车主正常用车体验，品牌形象和用户信任度遭受显著打击。

2020年8月：CenturyLink配置错误导致全球互联网中断
事件经过：美国互联网服务提供商CenturyLink因数据中心错误配置引发连锁反应，全球互联网流量下降3.5%，受影响服务包括Cloudflare、AWS、Garmin等，7小时后故障解决。
事故原因：BGP路由配置错误。
造成损失：成为有史以来最大互联网中断之一，全球大量服务无法正常访问。

2020年8月：Zoom视频会议中断
事件经过：8月24日，正值全球远程办公和在线教学高峰期，Zoom发生了部分服务中断，导致用户无法访问离线会议和在线视频会议，中断持续了3小时。
事故原因：Zoom仅在状态页面表示“找到并解决了问题”，未详细披露是代码缺陷还是容量规划问题。
造成损失：在用户依赖度最高的时期掉链子，严重影响了全球企业的线上会议、学校教学以及商务谈判的正常进行

2020年6月：T-Mobile 美国全国通信中断
事件经过：6月15日，T-Mobile美国网络遭遇了长达13个小时的全国性瘫痪。这是T-Mobile历史上持续时间最长、影响范围最广的一次中断，导致数百万用户无法拨打语音电话或发送短信。
事故原因：网络配置变更失误。起因是东南部一个第三方供应商的光纤电路故障，但由于T-Mobile自身的网络冗余设计失效，加上后续的负载均衡配置问题，导致IP池过载，最终引发全网崩溃。
造成损失：全美范围内的语音和短信服务中断；由于正值疫情期间，严重影响了用户的紧急通讯和正常生活，公司声誉受损。

2020年5月：AWS大规模服务中断
事件经过：AWS发生严重故障，影响Amazon.com等众多网站和服务。
事故原因：路由表配置错误，更新骨干网络时错误路由表形成流量黑洞。
造成损失：全球大量网站和APP数小时无法访问，重创电商及在线服务。

2020年4月：华为云大面积宕机
事件经过：4月10日，华为云登录及管理后台无法访问，北京、广州、上海等地用户受影响，宕机持续约3小时，故障修复后部分客户业务逐步恢复。
事故原因：部分主机异常，具体技术细节未公开。
造成损失：多家公司业务无法正常维持，影响业务连续性。

2020年4月：GitHub服务中断
事件经过：4月21日，微软旗下GitHub多个服务访问异常，持续一个半小时，是当月多次宕机事件之一。
事故原因：未公开披露具体原因。
造成损失：影响开发者源代码存储、提交及协作工作，干扰项目推进。

2020年3月：微软Azure美东数据中心服务中断
事件经过：3月3日，微软美国东部数据中心服务中断6小时，美国北部客户无法使用Azure云服务，最终通过重置冷却系统控制器、重启硬件恢复。
事故原因：冷却系统故障，楼宇自动化控制功能失灵导致气流减少，数据中心温度飙升影响设备性能。
造成损失：计算和存储实例无法访问，影响依赖该区域云服务的企业业务运转。

2020年3月：微软Teams服务中断
事件经过：3月16日，新冠疫情期间Teams平台涌入大量新用户，导致欧洲地区服务宕机2小时。
事故原因：服务支持能力不足，无法承载突发用户量激增压力。
造成损失：对依赖远程办公的企业造成较大影响，干扰正常办公秩序。

2020年3月：谷歌云平台服务中断
事件经过：3月26日，谷歌多个云服务无法访问，用户频繁遇到500、502错误代码，美国东部沿海地区用户受影响最严重。
事故原因：基础设施组件故障。
造成损失：大量用户无法正常使用谷歌云服务，业务推进受阻。

2020年3月：腾讯课堂系统崩溃
事件经过：3月4日，腾讯课堂出现登录失败问题，因凌晨系统升级时部分机器故障引发，当日8:30经紧急抢修恢复正常。
事故原因：系统升级操作不当，部分机器升级过程中出现故障。
造成损失：影响在线教育课程开展，干扰师生教学进度。

2020年2月：微盟员工恶意删库事故
事件经过：2月23日，微盟研发中心运维部核心人员贺某通过个人VPN登入内网跳板机，4分钟内删除服务器全部数据，致300余万用户无法使用SaaS产品，故障持续8天14小时。
事故原因：员工因个人精神、生活问题恶意破坏，滥用运维权限执行高危删除操作。数据最后在腾讯云的帮助下得以恢复。
造成损失：市值蒸发28亿，预计赔偿金1.5亿，直接经济损失2260余万元，含数据恢复费、商户赔偿费等。
小插曲：据悉，该工程师欠了网贷无力偿还，而且当天喝了不少酒，该工程师被判刑6年月。

千年虫事件
在上个世纪，软件行业初期，计算机硬件资源十分昂贵，很多软件为了节省内存会省略掉代表年份的前两位数字”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年，苏联天然气管道爆炸事件，涉及植入恶意代码，没有加到列表中