异常测试之错误注入

  异常测试是保障大规模分布式系统稳定运行的重要手段。对于大规模部署的云计算物理环境，硬件出错将是一种常态。

比如我们的一些故障记录，3月初短短4天内就有5起磁盘故障：

  当然在软件设计阶段，我们就要充分考虑异常处理逻辑来避免硬件故障导致的系统可靠性问题。在测试的时候，我们要尽可能的模拟异常，覆盖代码的异常分支以及确保在一些硬件故障的情况下，保证系统的可用性、可靠性等。

  异常测试可以通过机房操作物理设备完成，比如断电、拔盘、拔网线等；但是显而易见，这样做的效率很低，也无法自动化，错误模型也比较单一，与实际的硬件故障也很难吻合；比如曾经我们发现过一个bug，其中一块ssd故障的时候（可能是ssd内部死锁导致，没有及时返还错误，scsi层面还在做一些重试），导致操作系统迟迟没有发现，而往这块ssd写的io全部被hang住超过2分钟，层层重试、反馈后导致上层用户的io被卡了将近5分钟。如下图所示，用户侧监控显示io卡了将近5分钟。

  所以怎样做好异常测试非常关键，这里一方面我们可以考虑模拟磁盘、网卡等硬件设备，然后考虑在系统的路径上注入各种错误。这样才可以充分控制这些硬件设备，让它们想怎么坏就怎么坏。比如我可以制造随机hang io 0-30秒的场景，并且作为异常测试框架下的一种错误，能够自动化的触发；然后再去监测系统的表现。

  真正模拟这些物理设备还是比较有挑战的，需要对底层的一些特性有清晰的认识；比如跑在虚拟机中的一些业务，对于这些业务来说，虚拟机就是底层，而虚拟机中的磁盘、网络等设备就是软件模拟出来的，哪怕是整个虚拟机，也仅仅是物理机上的一个qemu进程，掌握一些管理命令以及一些用户态的错误注入工具就可以模拟异常；而对于真正的底层软件，直接打交道的就是真实的磁盘和网络，这时候想要注入就比较难，有时候我们更需要在这些硬件的上层，比如设备驱动、内核、文件系统等路径上去找注入错误的入口，当然也会有办法来模拟这些设备。

  比如我们在搜索"how to simulate disk failure"的时候，我们发现其实已经有一些不错的方法了。

  我们以第一项libfiu为例，libfiu可以从用户态注入错误，可以不改被测程序的源代码直接使用；我们从原理和使用方法上详细介绍一下（后面几个方法是在设备驱动层、内核层注入）。

原理：

  libfiu是一个c库，可以用来模拟posix接口，使posix接口返回错误。这也是libfiu实现的原理：当用户使用libfiu来测试程序时，libfiu把其中的一些posix接口mock掉，比如测试程序需要调用系统的open()函数，libfiu会将这个open()指向自己库里面的函数，然后直接返回posix错误码抛给测试程序。这时候我们可以观测被测程序的表现来判断异常处理能力。

 官方例子：

 比如我们有个程序是查看磁盘是否有足够剩余空间

size_t free_space() {
        [code to find out how much free space there is]
        return space;
}

bool file_fits(FILE *fd) {
        if (free_space() < file_size(fd)) {
                return false;
        }
        return true;
}

  而测试的时候，我们需要考虑free_space返回0的时候，也就是磁盘被写满的时候这个场景；但是真正写满磁盘是非常难的，就算能写满，每次写满也会耗费非常长的时间。而fiulib就可以使用下面的方法让free_space在需要的时候返回0.

size_t free_space() {
        fiu_return_on("no_free_space", 0);

        [code to find out how much free space there is]
        return space;
}

bool file_fits(FILE *fd) {
        if (free_space() < file_size(fd)) {
                return false;
        }
        return true;
}

其实上面的方法就是你在free_space中加了一个注入点，通过下面的方法来触发注入的异常，然后进行测试。当然不触发的情况下是不会产生作用的。

fiu_init();
fiu_enable("no_free_space", 1, NULL, 0);
assert(file_fits("tmpfile") == false);

使用方法：

1.比如我们测试ls这个命令，我们可以直接使用下面的命令，其中 -x 参数是告诉fiu-run当程序调用posix api的时候注入错误，name指向了具体的模块，可以通过随机的方法，控制错误发生的概率。

fiu-run -x  -c "enable_random name=posix/io/*,probability=0.05" ls

下面是调大概率后和将概率调成0后的一些测试结果，可以看出ls这个系统命令在各种posix错误下都有错误提示返回，也没有导致崩溃等情况，概率调成0后，也能正确返回结果：

2.也可以通过下面的方法进行测试：

比如需要测试top命令：

可以在一个session中启动被测程序

fiu-run -x top

然后再另一个session中启动错误注入

fiu-ctrl -c "enable name=posix/io/oc/open" `pidof top`

这时候我们可以观测到top已经没有输出了；

然后停止错误注入，

fiu-ctrl -c "disable name=posix/io/oc/open" `pidof top`

top又能正常输出了。

其实原理也很简单，前面已经提到了，top需要读取一些文件来展示信息，必然会调用open()这个函数，而fiulib将系统的open()指向自己库里面的open(),然后返回错误给top，这样top就没法输出了。这也是符合预期的。

libfiu支持的posix api错误注入有很多，看官方介绍原来还能通过-i参数指定错误类型，现在取消了这个功能（原因没写，随机模式下实际作用也不大）。

 当然，上面2个例子你可能觉得这个工具作用不是很大，只能测测简单的程序，但实际上对于复杂程序也能测试的。比如测试ceph。

root@pubt1-ceph64:~# fiu-run -x -c "enable_random name=posix/io/*,probability=0.8" /etc/init.d/ceph start osd.3
/etc/init.d/ceph: error reading input file: Input/output error
root@pubt1-ceph64:~# fiu-run -x -c "enable_random name=posix/io/*,probability=0.8" /etc/init.d/ceph start osd.3
/bin/sh: /etc/init.d/ceph: No such file or directory

 libfiu具体支持哪些库我们也可以通过下面命令看到。类似于malloc() read() write() fork() mmap()以及一些 socket相关的都能模拟。

cat /root/libfiu-0.96/preload/posix/function_list

 回到错误注入这个话题，提供一些常见的错误注入方法

 附录：

大规模分布式系统的测试的话题很大，难度也很高；可能随着硬件环境的规模或者业务逻辑的差异，系统会走到不同的代码分支。曾经 看到阿里云飞天测试的时候，他们的系统里会加入Log Coverage工具，能够通过程序在运行过程中输出的log进行比对，看看测试是否覆盖了各个分支，同时也会拿到线上的log进行比对，补充各种各样的测试场景。

在后期的稳定性和异常测试中，最有效的保障还是让测试框架随机的挑选各种错误触发，校验系统的可靠性及数据的正确性。