Learn and share.
近期发版，要修复一个并发引起的主键冲突报警。
运维要求没有此类报警，组里同事顺手就改了。
结果第二天一早服务高峰期，服务直接卡死没有反应了。
快速定位到是这段代码的问题，回滚，解决问题。
然后分析了一下，开发、测试、架构都有问题：
原始逻辑：
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L2
4、服务B调用数据库服务入库
由于加锁逻辑比较特殊，并发时，会造成主键冲突。
问题逻辑：
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L1
4、服务B调用数据库服务入库
服务直接卡死，要么服务超时，要么锁超时，服务能不卡死吗
解决问题并不复杂，在这里就不罗嗦了。
问题是很简单，但暴漏的问题十分多：
1、开发对程序逻辑、分布式锁理解明显不够
2、在开发、测试、UAT环境下，开发和测试其实都发现了性能下降的问题，但都没有重视
3、架构和资深开发，代码审核工作问题也很大
其实很多时候，工具是一回事，但人员的专业性思维，其实更重要。
我们伟大的云提供商告诉我们，他们廊坊机房要关停了，要求我们迁移到其他机房，春节前一定要迁移完毕。
和运维、架构沟通后，做了迁移计划，做了演练，虽然时间仓促，问题特别多，但还是扛过去了。
迁移后，不少用户受到了影响，比如有一个省由于网络供应商问题，整个省的用户无法解析DNS。
这其中，印象最深的是，我们一个用户，服务、配置、权限各种都是正确的。但就是无法登录。
分析了几个小时，最后发现，原来是用户机器时间不对，时差有几个小时，在HTTPS请求到达防火墙时，就被干掉了。
设好时间，一切正常。
其实，之前也遇到过两三次类似问题，频率太低了，一开始根本就没考虑这种可能。
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面临巨额赔偿和客户流失。
当时看到《阿里巴巴Java编码规范》时，我感觉这里面说的不是大家都该知道的事情吗？真有必要汇总个规范出来？
出来混，总要还的，最近在老项目上就遇到了。
我们有两个服务，遗留项目，代码写的实在是不敢恭维。
用量其实不大，或者说偏小，但很默契的每两周挂一次，到今天是第三次了。
第一次OOM（没定位到根本问题）：
K8S网络组件异常，DNS解析失败，和架构一起排查后，发现问题如下：
1、系统原来使用过RabbitMQ，后来代码注释了
2、但POM中，还是有MQ的引用，别的不会做，但会启动MQ的监听
3、结果有一天K8S网络组件异常，DNS解析失败
4、MQ的心跳包瞬间起了几千个线程，连接找不到的MQ Server
5、服务挂了
推断的问题链路为：
DNS无法解析-》MQ心跳包不断起线程，而且没有连接池-》线程耗尽内存-》OOM-》服务挂掉
解决方法：
在POM中，干掉了MQ的引用，以为问题被修复了。
第二次OOM（大意了）：
1、表现仍是K8S网络组件异常，DNS解析失败
2、架构感觉容器DNS解析不了应该运维去查
3、只好拉上运维查，运维也比较给力，很快把日志给出来了
4、但是系统OOM时，并没有生成镜像，架构建议添加JVM参数，结果和运维排查后发现JVM参数已经加了，OOM应该有Dump啊
5、最后的结论是，非常规问题，等下次发生再解决
6、这个时候，已经感觉怪怪的了，问题根源根本没有找到啊，但大家都忙着机房搬迁，就没能跟下去（我的问题）
推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题
解决方法：
碰运气，等下一次OOM生成Dump文件？我当时咋想的呢
第三次OOM（真的解决问题了吗？）：
1、感觉不对劲啊，为什么总是两周挂，于是拉取了日志
2、日志上没看出什么来
3、仍然没有OOM的Dump
4、jstack一看线程，傻眼了，一堆线程在waiting on condition
5、赶快看相关源码，居然是用了Excutor，然后线程和队列都是默认的
6、你懂的，线程数和队列默认几乎都是无限的，参数设置错误，导致线程池根本不会服用原来的工作线程
7、服务挂掉是早晚的事情
推断的问题链路为：
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题
解决方法：
修改Executor默认配置
咋说呢，再次认识到规范强制推行也是必要的，全靠人的个人水平，是不行的。他们的规范，恐怕也是各种坑汇总成的结晶吧。
前几天，突然收到报修，一个文件接收服务突然宕了。
我们运维同事很快就进行了重启，此时怪异的事情发生了：
重启服务后，服务一会儿就没响应了，端口可以通，文件全部上传失败，没有任何异常日志输出。
那就排查吧：
1、PG数据库连接正常，无死锁，表空间正常，数据查询秒回
2、服务配置几个月都没人改过，CPU、内存、存储、IO、网络，全部正常
3、上传客户端日志输出，显示其工作正常
4、只有文件接收服务，没有响应，也没有日志输出
初步判断，文件接收服务出问题了。
于是，新开一个云主机，重新安装服务，仍然无响应。
然后，拷贝了一个正常工作的主机，修改配置后，仍然无响应。
来来回回折腾了几个小时，还是不行。
无奈之余，试了一下向PG数据库插入数据，我去，几十秒都没有响应。
赶快问DBA，原来是做了高可用，主从库数据同步，从库异常了，导致主库可读不可写。
众人皆表示无奈，重启从库，问题解决。
其实，一开始就排查数据库了，但由于是生产库，只试过查询，没有试过写入。
但是，我们都大意了：
1、服务日志，输出不够详细，就算DEBUG打开，也不知道数据进行到哪一步了，这个最坑
2、没有正确的设置超时时间，原因是接收文件后，写入数据库一直在等待，服务日志没有任何数据库异常
3、数据库监视软件，只做了主库监视，根本没做从库监视
4、数据库主从配置，本应该是异步，但现在配置成了同步
5、没有监视主从库同步的情况
6、生产库，不敢轻易进行写操作，只看了查询效率及死锁，没有看慢语句
就这样一个小问题，绕过了层层监控机制，让问题排查十分困难，花费了大量的人力。
反思起来，如果只是为了记录日志而记录日志，但日志不能反应服务状态，那不如不记；如果只是为了监控而监控，但监控不到位，那不如不监控。
我们日常做事情，也是同样的道理，细节是魔鬼，把该把控的把控好了，才能提升效率，得到想要的结果。
最近到新公司，接手了几十个老项目。由于项目特殊需要，需要快速将一个模块的单元测试覆盖率提升到80%以上。
怀着忐忑的心情看了一下，该模块居然还有一个单元测试，整体覆盖率为0，欲哭无泪啊。
手工写是来不及了，那就想办法自动生成吧。找了一下，最终决定采用EvoSuite。
EvoSuite有多种方式可以配置，包括命令行模式、Maven插件模式以、Eclipse插件模式、IDEA插件模式等。
一、maven模式
1、修改POM文件，在对应位置添加相关内容
<properties>
<evosuiteVersion>1.0.6</evosuiteVersion>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.evosuite</groupId>
<artifactId>evosuite-standalone-runtime</artifactId>
<version>${evosuiteVersion}</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<versionRange>[2.5,)</versionRange>
<goals>
<goal>prepare</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore />
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.evosuite.plugins</groupId>
<artifactId>evosuite-maven-plugin</artifactId>
<version>${evosuiteVersion}</version>
<executions>
<execution>
<goals>
<goal>prepare</goal>
</goals>
<phase>process-test-classes</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<properties>
<property>
<name>listener</name>
<value>org.evosuite.runtime.InitializingListener</value>
</property>
</properties>
</configuration>
</plugin>
<!--plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>add-test-source</id>
<phase>generate-test-sources</phase>
<goals>
<goal>add-test-source</goal>
</goals>
<configuration>
<sources>
<source>.evosuite/evosuite-tests</source>
</sources>
</configuration>
</execution>
</executions>
</plugin-->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
2、生成单元测试
mvn -DmemoryInMB=4000 -Dcores=4 evosuite:generate test #生成的单元测试在 #.evosuite/best-tests #拷贝到正确的路径就可以了
二、命令行模式
1、下载evosuite-1.0.6.jar包
2、收集项目依赖，把evosuite-1.0.6.jar也放入target/dependency文件夹
mvn dependency:copy-dependencies
3、生成单元测试
cd target/dependency java -jar evosuite-1.0.6.jar -help java -Duse_separate_classloader=false -jar evosuite-1.0.6.jar -projectCP YOUR_CLASS_PATH -generateSuite -target ..\classes #生成的单元测试在 #target/dependency/evosuite-tests #拷贝到正确的路径就可以了
三、Eclipse插件模式
在eclipse中安装evosuite插件，需要额外的插件地址：
http://www.evosuite.org/update
四、单元覆盖率
1、插件安装
在eclipse中搜索并安装EclEmma Java Code Coverage插件，直接搜索即可
2、修改class loader配置
#默认使用单独的class loader，覆盖率会为0 separateClassLoader = true #全局替换为 separateClassLoader = false
3、然后在项目上，右键，Coverage as-》JUnit Test
就可以看到覆盖率了哦。
我试过两个项目，一个简单的项目，覆盖率为95以上。
一个复杂一些的Web项目，覆盖率仅为30%左右。
五、总结
生成的单元测试，实际上没有什么维护性，如何用于生产环境，待探索。
故障恢复
之前做个一个折中的处理方案，类似于快速接收，批处理，反馈处理状态。之所以这样处理，是因为合作机构IT水平参差不齐，而且配合程度不高，如果把数据接收+处理+反馈放到一起的话，一旦有错误，就要麻烦对方重新推送最新数据，或者自己脚本重新处理数据，而且一天峰值十分明显，峰值时根本来不及处理数据。
1、数据接收阶段，采用了快速失败策略。一旦数据落库文件落盘，就返回成功，反之失败。
2、数据处理阶段，会进行重试，三次后进入失败队列
3、进入失败队列后，会通知运维和开发，去看下数据什么问题。有时会把文件手工处理一下，再重试。如果实在无法处理，就线下通知合作方相关人员如何修改数据。
4、数据处理成功后或彻底失败后，发送处理结果给合作方。
这种方式，在对合作方约束很小、合作方缺乏技术支持、项目前期阶段、以快速开展业务为优先考量时，可以尝试一下。后面自己做起来后，就可以要求对方，做一些统一要求了。
限流和降级
之前在一个大量读写小文件服务的入口处，用过令牌桶限制访问量，防止IO过高。问题是每秒要发放发放多少令牌，最后是慢慢试出来的。
后面微服务时代就是中规中矩的限流，降级和熔断了。但降级和熔断，是通过HTTP状态码进行判断的，有些后知后觉了。
零信任网络
一个团队去完成一个任务，如果彼此信任，相互配合就会很流畅，沟通成本会很低，任务推进也会很顺畅。比如几个知根知底的伙伴去创业，一个眼神可能就懂了。
一群互不信任的人去完成一个任务，哪怕每个人都很努力，但经常感觉别人掣肘，吵来吵去，任务止步不前。一个流动率高，甩锅成风的组织，便是如此。
代码也是如此，如果我们假设代码是可信的，直接拉取镜像就行了。
如果假设代码是不可信的，开发提交代码后，要各种引擎扫描，扫描通过后，流水线打包镜像。同时还要提交各类材料如测试报告，越权测试报告，渗透测试报告，压力测试报告，代码审核报告等等相互佐证代码没有问题，然后发布。
这样先不说要多少资源支持，单说发布，就从十几秒变成了十几分钟，甚至几十分钟。
服务也是如此，如果假设服务是可信的，不要加任何控制，就可以相互访问。
如果假设服务不可信，就要各种验证，网络端口是否允许访问，token是否正确，双向证书过了没，是否有服务访问权限，是否有数据权限，是否符合流量控制要求等等。
先不说做需要多少资源支持，单说服务性能，从几十毫秒一下到了几百毫秒。
那做这些值吗？值！
但要符合自己的情况，不能太过，绑了自己的手脚！
零信任网络安全
我认为边界安全模型和零信任模型会长期共存，边界安全模型毕竟更成熟，而且在资源隔离程度上，远高于零信任模型。istio们并没有提供边界模型的一些组件，比如杀毒，比如入侵检测，比如蜜罐，比如上帝视角的规则控制等。而且istio们本身也有被入侵的可能，所以不能只依赖这一个层面的安全管控，而是立体的安全管控。
可观测性
单体程序时代，类似于一个办公大楼，有了问题，告诉管理员门牌号和具体事情就行了，管理员就可以乘电梯过来解决问题。
只要在日志里输出一下，哪个方法，做了哪个任务或出了什么问题，用日志工具就可以统计到处理速度或快速定位到问题了。
微服务时代，类似于管理城市物流。要提出问题，我们必须说明，那条街，哪个门牌号，几单元，有什么需求。工作人员上门时，要看下地图，什么路线过去最快，遇到堵车怎么办，小区不让进怎么办，然后才能到顾客这边提供服务。数据链路就像城市地图，监控就像地图上的流量，而日志必须还原到这张地图上，才知道哪个交叉口或哪个大楼哪里出了问题。
所以，我们要花必要的精力，去做全链路，绘制这个地图。所以我们要收集度量信息，去监控哪里流量红了，哪里彻底堵车了。只凭日志，是无法快速定位问题的，这个交叉口堵车，问题可能出在三公里之外，一个交叉口一个交叉口查过去，太慢了。
流量大了，堵车是必然的。只有做好可观测性，才能快速疏导交通，做到事半功倍。
日志
个人觉得，如何正确的记录日志，用何规则做日志分级，要记录哪些东西，比用什么技术栈分析日志重要的多。老师能否分享一下，日志规范如何在团队中落地呢？
有两种情况，多记录一些日志有好处的。一类是部署于第三方的系统，宕机时要多记录日志，最好有dump文件，利于排查问题。第二类是跨公司做集成对接，输入输出一般都会记得很清楚，为了防止扯皮。
聚合度量
主要监控了服务请求，JVM，服务器的一些指标。但服务请求方面，做的还很基础，有较大提升空间。
一、申请证书
各大云厂商均有销售，如果没有特殊需求买最便宜的或免费的，需要做域名验证，按指引做好验证即可
申请后会得到三个文件，保管好，不要给别人
ca.crt、server.crt、server.key
将这三个文件拷贝到/etc/apache2/ssl/
二、启用https
1、apache2启用ssl模块
sudo apt-get install openssl sudo a2enmod ssl
2、配置ssl虚拟站点
# 建立软连接 sudo ln -s /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-enabled/001-default-ssl.conf # 编辑https配置文件 sudo vi /etc/apache2/sites-enabled/001-default-ssl.conf # 修改下面三行 SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key SSLCertificateChainFile /etc/apache2/ssl/ca.crt
3、重启apache服务
# 重启服务 sudo systemctl apache2 restart # 查看状态 sudo systemctl status apache2.service
4、登录wordpress后台，修改网站地址为https地址
5、此时应该就可以用https进行访问了
三、设置http重定向到https
1、启动重定向模块
sudo a2enmod rewrite
2、设置http重定向
# 编辑http配置文件
sudo vi /etc/apache2/sites-available/000-default.conf
# 在需要重定向的VirtualHost中，增加下面三行
<VirtualHost *:80>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{SERVER_NAME}$1 [L,R]
<\VirtualHost>
3、重启apache服务
# 重启服务 sudo systemctl apache2 restart # 查看状态 sudo systemctl status apache2.service
4、现在访问http地址，就会自动跳转到https地址了
1、查看gitlab版本
gitlab-rake gitlab:env:info System information ... GitLab information Version: 12.2.8 ... GitLab Shell Version: 9.3.0 ...
2、备份gitlab
gitlab-rake gitlab:backup:create #会在这个路径生成新的备份文件 /var/opt/gitlab/backups/XXX_gitlab_backup.tar
3、准备新服务器
在新服务器上安装相同版本的gitlab，并将备份文件拷贝到新服务器相同路径
4、还原
gitlab-ctl stop unicorn gitlab-ctl stop sidekiq gitlab-rake gitlab:backup:restore BACKUP=XXX gitlab-ctl start
5、验证
gitlab-rake gitlab:check SANITIZE=true
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年月。