叶正盛，玖章算术CEO，NineData创始人，曾担任阿里云数据库产品管理与解决方案部总经理，是阿里巴巴去IOE、异地多活、云计算多次技术变革的核心技术专家。
以下文章根据视频内容整理
最近出现了许多大规模故障事件，如AWS、语雀、ChatGPT、阿里云故障等。这些平台几个小时都无法使用。在大型平台上避免故障是非常困难的，如果一个技术人员没有经历过大规模故障，我觉得是不可思议的。要么是你的系统不够核心，要么是线上操作很少。工作量并不是很大，因此常常会遇到问题。
近期大规模故障事件频发，如AWS、语雀、ChatGPT、阿里云故障等。
常常在河边行走，哪有不湿鞋的道理呢？今天我想与大家分享我在阿里的第一个大规模故障，那是在2010年。我负责阿里国际站的数据库，当时我们的业务需要在商品表中增加一个字段。这个操作对我来说已经非常熟悉，因为我每周都要做几次类似的操作。
那次，由于商品表是我们的核心表，我对操作格外谨慎，选择在较晚的时间进行。我准备好了变更脚本，并经过了审批流程。审批通过后，我登录到数据库的小型机上进行操作。
但是当我执行完指令并检查了变更字段后，发现负载突然飙升，我感到有些慌张。紧接着，业务团队传来消息，说我们的商品库已经不可用了。我感到很迷惑，只是增加一个字段，怎么会引发这么严重的问题？
我将这个信息同步到了我们团队的群里，师兄指出了问题所在。哦，原来这是一个数据库缺陷。在Oracle 9i时，如果变更表上存在触发器或存储过程，加字段或索引都会触发重新编译表对象、触发器和存储过程。
在Oracle 9i版本中，这个重新编译没有锁阻塞。当大量并发同时到来时，会发生并发等待编译和锁竞争的情况。如果负载很高，问题就会更加严重，很难解决。要么停止业务等待编译完成，要么重启数据库。我们当时选择了重启数据库，感觉非常尴尬。最后才恢复了故障。
这个故障之前我们团队的某人也遇到过，而我却犯了同样的错误。当时我们的老板非常气愤，差点解雇我。还是要感谢老板没有解雇我。
我觉得系统故障很难系统化解决，但有两个重要点是关键的。第一，规范的线上操作和变更流程。第二，完善的应急处理预案。我认为这两点可以有效避免故障或减少故障对系统的影响。
今天就分享到这里，希望大家都能保持系统的稳定。欢迎评论！
