1. 以前“计划内的停机”很正常，现在则不被接受
2. 高可用性架构
2.1. CF系统不会遇到任何常见的单点失效问题
2.1.1. 硬件的每一部分都有冗余
2.1.1.1. CPU
2.1.1.2. 驱动器
2.1.1.3. 网卡
2.1.1.4. 电源
2.1.1.5. 网络交换机
2.1.1.6. 风扇
2.1.2. 为了防止某个机架受到损坏或破坏，服务器甚至被分散安装到不同的机架上
2.1.3. 如果发生火灾、洪水、炸弹袭击，位于48千米外的第2个机房可以随时把系统接管过去
3. 集群配置的常见问题
3.1. 没有足够的心跳
3.2. 心跳数据和生产数据由相同的交换机传输
3.3. 服务器设置为使用物理IP地址而不是虚拟IP地址
3.4. 设计的软件包之间混乱的依赖关系
4. 遭遇停机
4.1. 首要的任务都是恢复服务
4.2. 要先恢复服务，之后才是调查原因
4.2.1. 数百种疾病都能引起发烧
4.2.2. 为了判断可能的病因，需要进行化验或观察，了解更多信息
5. 事后分析
5.1. 谁最后动的就赖谁
5.1.1. post hoc, ergo propter hoc
5.1.2. 由于在数据库故障切换和维护之后，系统很快就失效了，因此疑点自然聚焦在故障切换操作上
5.2. 可靠的线索
5.2.1. 在停机事故发生时复制下来的服务器日志
5.2.1.1. 软件事故的事后分析实际上更难完成，因为事件结束了，没有留下可供分析的实物
5.2.2. RMI使得跨机器之间的通信方式就像在本机内部通信，但这种方式无法为通信调用设置超时时间，所以有一定的风险
5.2.2.1. 调用方很容易被其调用的远程服务器中的问题拖垮
5.3. 不可靠的线索
5.3.1. 人们对所见之事的陈述
6. 原因
6.1. JDBC规范允许java.sql.Statement.close()抛出一个SQLException异常，所以代码必须处理该异常
6.1.1. 如果在关闭statement时抛出异常，则数据库连接不会被关闭，从而导致资源泄漏
6.1.2. 这个异常在正常情况下几乎是不会被抛出来的
6.1.2.1. 当Oracle驱动程序在遇到IOException的情况下尝试关闭数据库连接时，例如执行数据库故障切换，SQLException异常就会抛出
6.1.2.2. 在执行该statement语句进行一些网络I/O操作时，会抛出SQLException异常。而在关闭该statement语句时也会抛出SQLException异常，因为驱动程序会尝试告诉数据库服务器释放与该语句相关的资源
