只有在知道问题的情况下，编写发现问题的测试才会变得简单
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异常，因为驱动程序会尝试告诉数据库服务器释放与该语句相关的资源
6.2. 假设JDBC连接是在故障切换之前创建的
6.2.1. 当数据库服务器执行故障切换时，用于创建连接的数据库服务器IP地址将从一台主机变成另一台主机，但TCP连接的当前状态不会将数据库主机地址转变为第二个主机地址
6.2.2. 任何对套接字的写入操作，最终都会抛出一个IOException异常
6.2.3. 意味着资源池中的每个JDBC连接都是能引发事故的“地雷”
6.3. 被迫停飞的原因只是一个未被捕获的SQLException异常
7. 预防管用吗
7.1. 指望着每一个像这样的软件缺陷最终都能被揪出来，就是天方夜谭
7.2. 除非其中一位代码评审员知道Oracle JDBC驱动程序的内部实现细节，或者代码评审团队对每个Java方法都花费几个小时来评审，否则是不会发现的
7.3. 只有在知道问题的情况下，编写发现问题的测试才会变得简单
7.3.1. 在定位了问题之后，该团队在压力测试环境中进行了测试，确实重现了同样的差错
7.4. 系统中的一个软件缺陷可能会传播到所有其他受影响的系统中
7.4.1. 每个企业内部都有相互关联和相互依赖的系统
7.4.2. 不能允许软件缺陷导致一连串的系统失效
