现在很多公司都对业务连续性不断提出要求，当然最好是不间断，实在不行的话尽可能减少中断时间。从前很多系统都是上班了使用，下班了就关闭的。这种系统都是可以停机做备份的，从前的数据库可能都没有高可用。
而现在不一样了，不管大公司还是小公司都对这个很看重。我从业20年来，发现影响业务连续性的有这些因素（以下说的可能受个人能力有关，未必能涵盖所有）：
1、机房断网断电。这种是非常致命的，只能靠灾备机房发挥作用。
2、数据库硬件故障，需要靠数据库高可用发挥作用。（当然前提是应用也有高可用，自动或者手动进行切换）。分布式数据库节点硬件故障不影响全局。
3、数据库锁、CPU满负荷、IO满负荷、连接数满等等数据库实例级别重大问题。如果仅仅是数据库无响应，重启数据库就行。这里就看数据库是多活还是主备。如果RAC这样的无需切换，如果是主备情况如果是ADG这样的，涉及到数据库的切换。MySQL PG这种也一样。如果是分布式数据库（需要看运维能力判断先重启哪个组件）。其实造成这种主要是应用程序造成。
4、删库、误操作等人为事件。
仅从以上的因素而言，1和2是非常严重的，但是这种发生概率十年九不遇，我经历的频率比我工作以来地球上发生的8级地震的次数都要少。这个重要吗？绝对重要，不能不防。就像灾备机房哪怕浪费的也需要，不能因为没有不可抗拒力就不要了。但是这不是我们日常每时每刻要关注的。4是要靠管理的，如果管理不到位，4也是致命的，而且什么技术都解决不了。
那么我们谈谈3，这个其实是我们每天都发生的，非常容易发生这种问题。这个才是我们每时每刻都要关注的。这些应用程序的问题能避免吗？在当下中国看起来，好像很难。我无论在Oracle的群，MySQL的群，PG的群还是TiDB的群，时不时能看到大家发出来的问题的SQL。就看看这些烂SQL就知道为什么我们的数据库经常会遇到各种各样的问题。用一句话来概括，不正确使用数据库是企业最大的成本。为什么这么说，如果感兴趣看看我以前写的一篇，《你没有大数据》
多少场景下就因为没有好好写SQL，就上了大数据系统。结果还是一地鸡毛。我以上想表达的意思还是说应用程序质量不高导致业务连续性是占比重极高的，而且是反复发生的。如果能重视起来，那么业务连续性的压力就会小很多。甚至可能在一个公司从入职到离职都不曾遇到过一次。毕竟以现在运营商的能力，不至于经常断网。以现在的硬件能力，不至于经常硬件损坏。一个操作系统运行3000多天不重启也不是没有过。